On 6/7/2021 12:13 AM, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 06/06/2021 20:12, David Brown wrote:
>>> On 06/06/2021 18:58, Manfred wrote:
>>>> On 6/6/2021 5:05 PM, Kaz Kylheku wrote:
>>>>>    typedef struct Nodetag Node;
>>>>>
>>>>>    struct Nodetag {
>>>>>      Nodetag *next; //  error: unknown type name ‘Nodetag’
>>>>>    };
>>>>>
>>>>>
>>>>
>>>> typedef struct Nodetag Node;
>>>>
>>>> struct Nodetag {
>>>>   int data;
>>>>   Node *next;
>>>> };
>>>
>>>
>>> Or even:
>>>
>>> typedef struct Node Node;
>>>
>>> struct Node {
>>> int data;
>>> Node *next;
>>> };
>>>
>>> There's no need for an extra name here.
>>
>> Unless you want to avoid any confusion. Since you can come across this:
>>
>> Node* A;
>> struct Node* B;
>>
>> Does one of those lines have a 'struct' missing, or does the other
>> have a 'struct' that shouldn't be there?
>>
>> The eye picks up such inconsistencies; it creates a distraction.
>>
>> Allowing two ways of denoting the same user-type is also sloppy.
>
> Which is a great argument for not bothering with the typedef:
>
> struct Node {
> int data;
> struct Node *next;
> };
>
> struct Node obj;
> struct Node *ptr;
> // ...
>
> (Bart will argue that having to type "struct" again is a heavy burden.
> I will not respond.)
>

Since I am no Bart, I am going to argue about that.
Not that's a heavy burden at all. My view is about consistent syntax
instead:
In C the canonical object declaration is:

type_name object_name;

One of the great strengths of the language is the possibility of
defining user defined types, by means of structs and unions (leaving out
typedefs that are aliases as you say)
From this perspective, after I have defined my type Foo as
struct Foo { int a; int b; };

I think it should be enough for the compiler to understand the correct
meaning when I write
Foo foo;

Now, I know you say (strictly according to the standard) that the type
name is "struct Foo" instead of "Foo", however from the pure syntactical
perspective this is a combination of a keyword and a name, so in C user
defined type names are required to include a keyword in their name; this
is not consistent with other type names.

I know that in practice it's no big deal, it's just something you have
to learn early on and you get used to it.
It's just that I am somewhat of a fan of language theory, syntax and
semantics.
That's why I like the C++ syntax for this considerably better.

I think this is one matter that falls under the category of "hangover"
from obsolete compiler weaknesses, to use David's terms.
Obviously all of this is now carved in stone, so no one is expecting C
to change this "feature" - I'm just expressing my taste about it.

On 07/06/2021 15:25, Malcolm McLean wrote:
> On Monday, 7 June 2021 at 13:00:30 UTC+1, Bart wrote:
>>
>> So, you don't take the same advantage of being able to use Foo and foo?
>>
>> If that case, why do you need a case-sensitive language?
>>
> If the language is case-insensitive, you don't want the same identifier to
> appear in the source in different cases.

Why is that a problem? You think that, because a syntax is
case-insensitive, that coders will delight is applying random
combinations of case in their identifiers? In any case, you will /know/
they are all the same.

In my own coding style, I mainly use all-lower-case except when
highlighting debug or temporary code, then I might use all upper case.

In also allows me to import functions such as 'MessageBox' and call them
as 'messagebox' (ie. not need to remember the exact capitalisation). Or
C's printf as PRINTF if it is temporary code.

In C however, once someone decides the pattern of capitalisation, then
you have to use exactly that pattern. With a danger that, if you get it
wrong, it may inadvertently match the same identifier from an outer
scope with a different pattern.

> That confuses anyone who doesn't
> know that the language is case insensitive,

Fortran, Ada, Pascal and the Algols are case-insensitive. Nim for
something more recent. But one prerequisite when using a language is
knowing something about it! Including knowing it if is case insensitive
or not.

> or who doesn't know that the
> programmer who wrote the code knows that the language is case
> insensitive, or who hasn't been told why such an odd practice is followed
> (there might be reasons, such as attaching metadata to an identifier).

Why do people think it is odd all of a sudden?

One of the most ridiculous things is case-senstivity in a CLI. So you
can't type COPY, it has to be copy, because COPY means something else.
(What does it mean? What does Copy or CoPy mean?)

The next most ridiculous thing is case-sensititivity in file names. Just
remember the exact capitalisation and don't accidentally use the wrong
one. (Imagine 64 versions of hello.c in your directory.)

> So in fact what you want is not a case insensitive language, but a language
> which disallows identifiers which are identical except in case. Alternatively
> a language which enforces rules such as "local variables must be lower case,
> functions must start with an uppercase letter".

Guidelines can be enforced in a case-insensitive language too.

What you can't do however is use Foo for a function name, and foo for a
local variable in the same scope (as well as foo for a struct tag /and/
label name, plus fOO, fOo and foO variations for those, and FoO, FOo and
FOO for functions) as C does.

> There are good arguments against allowing C's free for all. Virtually every coding
> standard is more restrictive than C in the identifiers that it allows. However
> backwards compatibility is all.
>

All my languages can interface with case-senstitive FFI names. Even if
they clash when case is ignored.

On 07/06/2021 15:00, Thiago Adams wrote:
> On Sunday, June 6, 2021 at 10:28:10 AM UTC-3, David Brown wrote:
> [...]
>> But in general if you have two "struct" declarations, these define
>> different types - even if they contain the same members. So if you want
>> to use the type more than once, you need to give it a name - either
>> using a tag or by making it part of a typedef.
>
> In some cases creating a name just make the code more complex.
>
> I wish I could create template structs using macros.
>
> #define vector(T) { T * data; int size, capacity; }
>
> void F(struct vector(Card) * v);
>
> this convention has more information associated than a typedef using
> plural name for instance.
>
> void F(struct Cards * v);
>
> Similar of "struct Card cards[] " it brings the information about
> the characteristics of the type.
>
> Imagine in C if each time we need array of something
> we have to assign a name to it.
>
> int a[10]; //error you need to create a name for it first.
>
> or each compound literal had to have a name...
>
> C also doesn't have unnamed functions (like C++ lambdas) and
> sometimes the name is artificially created and used in just one place like
> callbacks.
>
>

Sure. There is a reason C++ has lambdas, templates, etc. But C is kept
as a simpler language, and does not have these features - if you want
them, C++ is your obvious choice.

On 2021-06-07, Bart <bc@freeuk.com> wrote:
> On 07/06/2021 15:25, Malcolm McLean wrote:
>> On Monday, 7 June 2021 at 13:00:30 UTC+1, Bart wrote:
>>>
>>> So, you don't take the same advantage of being able to use Foo and foo?
>>>
>>> If that case, why do you need a case-sensitive language?
>>>
>> If the language is case-insensitive, you don't want the same identifier to
>> appear in the source in different cases.
>
> Why is that a problem? You think that, because a syntax is
> case-insensitive, that coders will delight is applying random
> combinations of case in their identifiers? In any case, you will /know/
> they are all the same.

When you say case insensitivity, what does that mean? Are these
considered the same identifier?

δέλτα

Δέλτα

How about Japanese katakana vs. hiragana. Are these the same
identifier?

スウジ すうじ

すうジ スウじ

They both say "suuji"; can you declare using one and reference elsewhere
using the others?

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On 07/06/2021 17:15, Kaz Kylheku wrote:
> On 2021-06-07, Bart <bc@freeuk.com> wrote:
>> On 07/06/2021 15:25, Malcolm McLean wrote:
>>> On Monday, 7 June 2021 at 13:00:30 UTC+1, Bart wrote:
>>>>
>>>> So, you don't take the same advantage of being able to use Foo and foo?
>>>>
>>>> If that case, why do you need a case-sensitive language?
>>>>
>>> If the language is case-insensitive, you don't want the same identifier to
>>> appear in the source in different cases.
>>
>> Why is that a problem? You think that, because a syntax is
>> case-insensitive, that coders will delight is applying random
>> combinations of case in their identifiers? In any case, you will /know/
>> they are all the same.
>
> When you say case insensitivity, what does that mean? Are these
> considered the same identifier?
>
> δέλτα
>
> Δέλτα
>
> How about Japanese katakana vs. hiragana. Are these the same
> identifier?
>
> スウジ すうじ
>
> すうジ スウじ
>
> They both say "suuji"; can you declare using one and reference elsewhere
> using the others?

I'm mainly talking about language source code which uses the ASCII
alphabet for keywords and user-identifiers.

I'm not concerned with other elements of source code such as comments,
or string literals, or any data used by the program. Or elements
representing file names (eg. names of include files).

That means considering A-Z and a-z in keywords and identifiers as
interchangable.

As for the answers to your questions; in my languages they are not
identifiers. Some more unusual identifiers are allowed using a "`"
prefix, for example, keywords, or numbers, which can be tweaked for utf8
sequences, but ` makes it case-sensitive in that case.

Then, they are considered equivalent when the byte-sequences match, not
glyphs nor meanings.

In languages such as Fortran and Ada, you'd have to ask experts on those.

On 06/06/2021 20:03, Richard Damon wrote:
> On 6/6/21 8:16 AM, James Harris wrote:
>> Does C, as a language, need to allow its structs to have tags?
>>
>> AIUI a fragment such as "struct A {....};" reserves no storage but
>> declares a template which can be used later, e.g. to declare a variable
>> as in
>>
>>   struct A var;
>>
>> to declare a parameter as in
>>
>>   void f(struct A parm) {....}
>>
>> to effect a cast as in
>>
>>   (struct A *) p
>>
>> etc but in all such cases struct A is being used as a type. And there is
>> a more general feature for that in typedef.
>>
>> So could C's struct tags be omitted from the language? If not, what does
>> a struct tag add? Is it something to do with forward declarations or
>> syntactic consistency with union tags, etc?
>>
>>
>
> The biggest need is for referencing a struct whose definition hasn't
> been given, especially as a pointer type.
>
> You can say 'struct A' to reference that type without ever having seen
> the actual definition of what that structure looks like.
>
> You can NOT do this with a typedef. You CAN say
> typedef struct A Astruct; to make Astruct a typedef for that unknown
> struct type, but even that requires the struct tag to be specified, so
> it can possible be linked later when the struct is actually defined.
>
> Except by using this sort of tag, there is no way in C to say that a
> name is to some type that may be defined later.
>
> I suppose C could be extended to allow a statement like typedef A; to
> define that A was a type, that later might get connected to some defined
> type. This would allow you to define pointers to that type.

If I understand you then yes, but that's a design choice.

I wonder if a language could, instead, allow statements to refer to
types which come anywhere in the same scope, i.e. allow /implicit/
forward references?

For example, the self referential:

typedef A = struct {
A *next;
int data;
}

or the indirectly referential:

typedef P = struct {
Q *firstchild;
int data;
}

typedef Q = struct {
P *parent;
float data;
}

The hardest part of that for a compiler to parse would be

Q *firstchild;

because no mention of Q would have even been seen by the time the
compiler got to that line.

Could an implicit forward reference such as the above be parsed?
Perhaps. As long as the compiler skipping that line and coming back to
it later did not prevent recognition of later types then it looks as
though the above would be parseable without requiring a programmer to
code an explicit forward reference. If the line could be a declaration
then proper recognition of it could be carried out in a second pass.

If that would remove the need for a struct tag and also remove the
slightly ugly and annoying requirement of having to include explicit
forward references then it would be a small but welcome step forward, IMO.

--
James Harris

On 06/06/2021 23:55, Bart wrote:

....

> C++ actually allows this:
>
>   typedef struct T {int x,y;} U;
>
> so that you can use T, struct T or U (but not struct U). So C
> compatibility has given it /three/ ways of denoting the same user-type!
>
> I declare such a struct like this (in one language):
>
>   type T = struct (int x,y)
>
> It declares exactly one user type, denoted always as just 'T'.

Does that language cope with /later/ type definitions such as

type T = struct (int x, y; Q q)
type Q = int

If so, how do you handle compilation of something (Q) which has not yet
been seen?

--
James Harris

On 07/06/2021 11:06, Bart wrote:
> On 07/06/2021 07:52, David Brown wrote:
>> On 06/06/2021 22:02, Bart wrote:
>
>>> Unless you want to avoid any confusion. Since you can come across this:
>>>
>>> Node* A;
>>> struct Node* B;
>>>
>>> Does one of those lines have a 'struct' missing, or does the other have
>>> a 'struct' that shouldn't be there?
>>>
>>> The eye picks up such inconsistencies; it creates a distraction.
>>>
>>> Allowing two ways of denoting the same user-type is also sloppy.
>>>
>>
>> What you call "sloppy", others might call "flexible".  You are, IIRC, a
>> fan of case-insensitive languages.  Are they sloppy for letting you
>> write "foo" and "Foo" to mean the same thing?
>
> You mean in the same way that "bart", "Bart" or "BART" all refer to me?

So does bartc. So does whatever your real name is. But they would be
different if used as identifiers. IOW I don't think you can use "refers
to me" as a justification for case insensitivity.

>
> Or the fact that if I say them out loud, they all sound identical too?

Similar could be said for

lastchild

and

last_child

also for

index2

and

index_2

and even

index_two

>
>> Or are you just engaging
>> in your favourite hobby - taking something that other people see as a
>> convenient way to write clearer code and using it for yet another
>> meaningless rant against C?
>
> No. For me case sensitivity means code that ISN'T clearer because people
> exploit that subtle difference in case between otherwise identical
> names: to use them for different purposes not just within the same
> scope, but across a program, where you have to keep doing a double-take.

I have some sympathy for your position but IMO a language which uses
case-insensitive identifiers really needs an IDE to convert all
instances of an identifier to the casing used where the identifier is
defined. E.g. if you'd defined

int Bartc

then anywhere else where you typed

bartc

should be autoconverted to the casing used in the definition.

The problem with that is that not everyone wants to use a
language-specific or even language-aware IDE. Some of us prefer source
files to be plain text.

--
James Harris

On 07/06/2021 17:53, Bart wrote:
> On 07/06/2021 17:15, Kaz Kylheku wrote:

....

>> When you say case insensitivity, what does that mean? Are these
>> considered the same identifier?
>>
>>    δέλτα
>>
>>    Δέλτα
>>
>> How about Japanese katakana vs. hiragana. Are these the same
>> identifier?
>>
>>    スウジ   すうじ
>>
>>    すうジ   スウじ
>>
>> They both say "suuji"; can you declare using one and reference elsewhere
>> using the others?

....

> As for the answers to your questions; in my languages they are not
> identifiers. Some more unusual identifiers are allowed using a "`"
> prefix, for example, keywords, or numbers, which can be tweaked for utf8
> sequences, but ` makes it case-sensitive in that case.

If you want to include unusual characters in identifiers (perhaps in
order to interface with external routines which allow then) is there any
reason not to use \ rather than the ` character? That would at least be
consistent with how backslash is often used in strings.

--
James Harris

On 07/06/2021 18:42, James Harris wrote:
> On 06/06/2021 23:55, Bart wrote:
>
> ...
>
>> C++ actually allows this:
>>
>>    typedef struct T {int x,y;} U;
>>
>> so that you can use T, struct T or U (but not struct U). So C
>> compatibility has given it /three/ ways of denoting the same user-type!
>>
>> I declare such a struct like this (in one language):
>>
>>    type T = struct (int x,y)
>>
>> It declares exactly one user type, denoted always as just 'T'.
>
> Does that language cope with /later/ type definitions such as
>
>  type T = struct (int x, y; Q q)
>  type Q = int
>
> If so, how do you handle compilation of something (Q) which has not yet
> been seen?

Yes, it handles that as it can deal with out-of-order definitions in
general.

But I also make it a bit harder than it need be because I allow
non-hierarchical module imports (ie. allows cyclic and mutual imports)
so that in your example, Q might be defined in a imported module, which
might not be processed until after this one (perhaps because it itself
imported this, so module-processing order is indeterminate).

However you don't need to do it that way.

The key here is for the syntax to recognise two consecutive identifiers:

A B ...

as a probable declaration of variable B with type A. Alternatively you
can use a syntax like this:

var A B
var B:A

Here you know that B needs to be a type. In all cases, it will require
an extra pass, for example:

T A[N];
char B[sizeof(A)];

If T (and even N) are defined later, it will not be able to determine
the dimensions of B (sizeof(T)*N) on the first pass.

So you have to work with everything being tentative.

On 07/06/2021 18:54, James Harris wrote:
> On 07/06/2021 11:06, Bart wrote:

>> You mean in the same way that "bart", "Bart" or "BART" all refer to me?
>
> So does bartc. So does whatever your real name is.

I think you know what I'm getting at here. If I signed a card bart, Bart
or BART, they would know who it's from (apart from there being not many
people called Bart).

If I used BART instead of Bart, nobody would wonder who on earth that
might be. So in real life, case is ignored, unless it is for some
special emphasis or special meaning (like Bay Area Rapid Transit).

I can translate a poem to all caps, or all lower case, or every word
capitalised, and people can still understand it. Random capitalisation
might be a bit more work though!

But they would be
> different if used as identifiers. IOW I don't think you can use "refers
> to me" as a justification for case insensitivity.
>
>>
>> Or the fact that if I say them out loud, they all sound identical too?
>
> Similar could be said for
>
>  lastchild
>
> and
>
>  last_child
>
> also for
>
>  index2
>
> and
>
>  index_2
>
> and even
>
>  index_two

Most of those use underscores that I'm not that keen on either. In some
languages (I think Nim) underscores are not significant: A_B and AB are
the same. It's just used for readability.

I don't use underscores much.

>> No. For me case sensitivity means code that ISN'T clearer because
>> people exploit that subtle difference in case between otherwise
>> identical names: to use them for different purposes not just within
>> the same scope, but across a program, where you have to keep doing a
>> double-take.
>
> I have some sympathy for your position but IMO a language which uses
> case-insensitive identifiers really needs an IDE to convert all
> instances of an identifier to the casing used where the identifier is
> defined. E.g. if you'd defined
>
>  int Bartc
>
> then anywhere else where you typed
>
>  bartc
>
> should be autoconverted to the casing used in the definition.

They way it usually works is that "bartc" is used everywhere, or the
same consistent name, But even when mixed, it doesn't matter because
they are the same name. You're still thinking in case-sensitive terms.

Have a go with Windows which is a case-insensitive OS. Create a file
called Hello. Then type:

> dir HELLO

it will still find it. Now edit a file called hello; it will edit the
same file.

Now, the file system works a little like you say because file names
retain their original case of when they were created, so here will list
the file as Hello.

I don't do that except for FFI names or ones starting with `; names are
usually converted to lower case.

Manfred <noname@add.invalid> writes:
> On 6/7/2021 12:13 AM, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 06/06/2021 20:12, David Brown wrote:
>>>> On 06/06/2021 18:58, Manfred wrote:
>>>>> On 6/6/2021 5:05 PM, Kaz Kylheku wrote:
>>>>>>    typedef struct Nodetag Node;
>>>>>>
>>>>>>    struct Nodetag {
>>>>>>      Nodetag *next; //  error: unknown type name ‘Nodetag’
>>>>>>    };
>>>>>>
>>>>>>
>>>>>
>>>>> typedef struct Nodetag Node;
>>>>>
>>>>> struct Nodetag {
>>>>>   int data;
>>>>>   Node *next;
>>>>> };
>>>>
>>>>
>>>> Or even:
>>>>
>>>> typedef struct Node Node;
>>>>
>>>> struct Node {
>>>> int data;
>>>> Node *next;
>>>> };
>>>>
>>>> There's no need for an extra name here.
>>>
>>> Unless you want to avoid any confusion. Since you can come across this:
>>>
>>> Node* A;
>>> struct Node* B;
>>>
>>> Does one of those lines have a 'struct' missing, or does the other
>>> have a 'struct' that shouldn't be there?
>>>
>>> The eye picks up such inconsistencies; it creates a distraction.
>>>
>>> Allowing two ways of denoting the same user-type is also sloppy.
>> Which is a great argument for not bothering with the typedef:
>> struct Node {
>> int data;
>> struct Node *next;
>> };
>> struct Node obj;
>> struct Node *ptr;
>> // ...
>> (Bart will argue that having to type "struct" again is a heavy
>> burden.
>> I will not respond.)
>
> Since I am no Bart, I am going to argue about that.
> Not that's a heavy burden at all. My view is about consistent syntax
> instead:
> In C the canonical object declaration is:
>
> type_name object_name;
>
> One of the great strengths of the language is the possibility of
> defining user defined types, by means of structs and unions (leaving
> out typedefs that are aliases as you say)
> From this perspective, after I have defined my type Foo as
> struct Foo { int a; int b; };
>
> I think it should be enough for the compiler to understand the correct
> meaning when I write
> Foo foo;

Ideally, I agree. The reasons for requiring the struct keyword are
historical.

> Now, I know you say (strictly according to the standard) that the type
> name is "struct Foo" instead of "Foo", however from the pure
> syntactical perspective this is a combination of a keyword and a name,
> so in C user defined type names are required to include a keyword in
> their name; this is not consistent with other type names.

A type name in C isn't just an identifer optionally preceded by keyword.
It can be a sequence of keywords (unsigned long long int), or a
combination of keywords and punctuation (void(*)(void)), and can even
include expressions (unsigned char[2*x+y][time()%60]). The only way a C
type name can be a single identifier is via a typedef -- a feature that
was added to the language relatively late, and that has required parsers
to be a bit more complicated.

In the absence of typedefs, every type name in C has a syntactic marker
to indicate whether it's an integer or floating-point type (one of
several keywords), a pointer (*), a function (()), an array ([]), or a
struct, union, or enum (struct, union, and enum keywords).

Recall that C evolved from a language that didn't have types. The idea
of *naming* types was added, and the idea of naming types with a single
identifier was added even later.

> I know that in practice it's no big deal, it's just something you have
> to learn early on and you get used to it.
> It's just that I am somewhat of a fan of language theory, syntax and
> semantics.
> That's why I like the C++ syntax for this considerably better.

C++ still has all of C's syntactic quirks. I agree that being able to
use the tag (what C calls a "class name") as a type name is an
improvement -- and that it couldn't be adopted in C without breaking
existing code.

Given C's rules, my personal preference is to write out "struct foo"
rather than creating a typedef -- unless the type is intended to be
opaque, meaning that client code shouldn't know that it's a struct.
(But if I were working on a project that had a convention of using
typedefs, I'd follow that.) In C++, I just use the class name.

> I think this is one matter that falls under the category of "hangover"
> from obsolete compiler weaknesses, to use David's terms.
> Obviously all of this is now carved in stone, so no one is expecting C
> to change this "feature" - I'm just expressing my taste about it.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

On 07/06/2021 20:03, Keith Thompson wrote:
> Manfred <noname@add.invalid> writes:

>> Now, I know you say (strictly according to the standard) that the type
>> name is "struct Foo" instead of "Foo", however from the pure
>> syntactical perspective this is a combination of a keyword and a name,
>> so in C user defined type names are required to include a keyword in
>> their name; this is not consistent with other type names.
>
> A type name in C isn't just an identifer optionally preceded by keyword.
> It can be a sequence of keywords (unsigned long long int), or a
> combination of keywords and punctuation (void(*)(void)), and can even
> include expressions (unsigned char[2*x+y][time()%60]). The only way a C
> type name can be a single identifier is via a typedef -- a feature that
> was added to the language relatively late, and that has required parsers
> to be a bit more complicated.
>
> In the absence of typedefs, every type name in C has a syntactic marker
> to indicate whether it's an integer or floating-point type (one of
> several keywords), a pointer (*), a function (()), an array ([]), or a
> struct, union, or enum (struct, union, and enum keywords).

You're missing the point a little.

One purpose of a user-type is mop up all that mess into single
identifer, which can be used without any other keywords or other syntax.

That doesn't happen with the user-identifier assigned to a struct tag.
You have to prefer it with 'struct', to indicate it has to look into the
right namespace.

It's a different kind of named entity than a typedef, and unique in that
it /requires/ the combination of keyword and user-identifier.

>
> Recall that C evolved from a language that didn't have types. The idea
> of *naming* types was added, and the idea of naming types with a single
> identifier was added even later.
>
>> I know that in practice it's no big deal, it's just something you have
>> to learn early on and you get used to it.
>> It's just that I am somewhat of a fan of language theory, syntax and
>> semantics.
>> That's why I like the C++ syntax for this considerably better.
>
> C++ still has all of C's syntactic quirks. I agree that being able to
> use the tag (what C calls a "class name") as a type name is an
> improvement -- and that it couldn't be adopted in C without breaking
> existing code.
>
> Given C's rules, my personal preference is to write out "struct foo"
> rather than creating a typedef

So? Just name the type 'struct_T' instead of 'T'.

On 07/06/2021 21:55, Bart wrote:
> On 07/06/2021 20:03, Keith Thompson wrote:
>> Manfred <noname@add.invalid> writes:
>
>>> Now, I know you say (strictly according to the standard) that the type
>>> name is "struct Foo" instead of "Foo", however from the pure
>>> syntactical perspective this is a combination of a keyword and a name,
>>> so in C user defined type names are required to include a keyword in
>>> their name; this is not consistent with other type names.
>>
>> A type name in C isn't just an identifer optionally preceded by keyword.
>> It can be a sequence of keywords (unsigned long long int), or a
>> combination of keywords and punctuation (void(*)(void)), and can even
>> include expressions (unsigned char[2*x+y][time()%60]).  The only way a C
>> type name can be a single identifier is via a typedef -- a feature that
>> was added to the language relatively late, and that has required parsers
>> to be a bit more complicated.
>>
>> In the absence of typedefs, every type name in C has a syntactic marker
>> to indicate whether it's an integer or floating-point type (one of
>> several keywords), a pointer (*), a function (()), an array ([]), or a
>> struct, union, or enum (struct, union, and enum keywords).
>
> You're missing the point a little.
>
> One purpose of a user-type is mop up all that mess into single
> identifer, which can be used without any other keywords or other syntax.
>

No, that would be the purpose of having type aliases - "typedef" in C.
The purpose of user-defined types is to be able to make types that are
different from existing types in some aspect.

> That doesn't happen with the user-identifier assigned to a struct tag.
> You have to prefer it with 'struct', to indicate it has to look into the
> right namespace.
>

Or you combine the two features - the creation of a new type with
"struct", and the convenient aliasing with "typedef".

> It's a different kind of named entity than a typedef, and unique in that
> it /requires/ the combination of keyword and user-identifier.

It's different in that it serves a different purpose.

>
>>
>> Recall that C evolved from a language that didn't have types.  The idea
>> of *naming* types was added, and the idea of naming types with a single
>> identifier was added even later.
>>
>>> I know that in practice it's no big deal, it's just something you have
>>> to learn early on and you get used to it.
>>> It's just that I am somewhat of a fan of language theory, syntax and
>>> semantics.
>>> That's why I like the C++ syntax for this considerably better.
>>
>> C++ still has all of C's syntactic quirks.  I agree that being able to
>> use the tag (what C calls a "class name") as a type name is an
>> improvement -- and that it couldn't be adopted in C without breaking
>> existing code.
>>
>> Given C's rules, my personal preference is to write out "struct foo"
>> rather than creating a typedef
>
> So? Just name the type 'struct_T' instead of 'T'.

People have different choices here. Some people prefer to view their
types with a little more abstraction, and would tend to use "T" (and
there's a fair correlation with preferring "char* p"). Others prefer to
think more in terms of how values of the type are used, and like "struct
T" because structs are used in different ways from scalers (programmers
with those preferences are perhaps more likely to write "char *p"). C
caters for both preferences - and both are in common use.

Bart <bc@freeuk.com> writes:
> On 07/06/2021 20:03, Keith Thompson wrote:
>> Manfred <noname@add.invalid> writes:
>>> Now, I know you say (strictly according to the standard) that the type
>>> name is "struct Foo" instead of "Foo", however from the pure
>>> syntactical perspective this is a combination of a keyword and a name,
>>> so in C user defined type names are required to include a keyword in
>>> their name; this is not consistent with other type names.
>> A type name in C isn't just an identifer optionally preceded by
>> keyword.
>> It can be a sequence of keywords (unsigned long long int), or a
>> combination of keywords and punctuation (void(*)(void)), and can even
>> include expressions (unsigned char[2*x+y][time()%60]). The only way a C
>> type name can be a single identifier is via a typedef -- a feature that
>> was added to the language relatively late, and that has required parsers
>> to be a bit more complicated.
>> In the absence of typedefs, every type name in C has a syntactic
>> marker
>> to indicate whether it's an integer or floating-point type (one of
>> several keywords), a pointer (*), a function (()), an array ([]), or a
>> struct, union, or enum (struct, union, and enum keywords).
>
> You're missing the point a little.

I'm not missing the point. I just disagree with you.

C does not have a convention of using a single identifier as a type
name. See N1570 6.7.7 for more information on C type names. I do not
choose to impose such a convention using typedefs (unless the existing
code I'm working on does so).

[...]

>> Given C's rules, my personal preference is to write out "struct foo"
>> rather than creating a typedef
>
> So? Just name the type 'struct_T' instead of 'T'.

Or I can just use a space instead of an underscore.

I understand that the need to use the struct keyword bothers you.
There's no need to repeat yourself.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

On Monday, 7 June 2021 at 21:22:55 UTC+1, Keith Thompson wrote:
>
> C does not have a convention of using a single identifier as a type
> name. See N1570 6.7.7 for more information on C type names. I do not
> choose to impose such a convention using typedefs (unless the existing
> code I'm working on does so).
>
I suspect that a lot of house style guides say that structs must be typedefed.
A lot will also mandate the stdint defines for fixed width integers, which has
the effect of reducing the use cases for types like "unsigned long" almost
to nothing.

On 07/06/2021 21:17, David Brown wrote:
> On 07/06/2021 21:55, Bart wrote:

>> One purpose of a user-type is mop up all that mess into single
>> identifer, which can be used without any other keywords or other syntax.

They all do the same thing. C allows anonymous structs (with struct{})
in a similar way to anonymous arrays ([]) and pointers (*). Or you can
name then, using typedef.

But structs additionally have the concept of a type-tag to do the same
thing, with their own namespace and their own special syntax to
distinguish such a name from a regular typedef name.

The only reason anyone has come up with for such a useless feature is
that it was there first. But when did typedef come along? It must be 40
years ago.

But since the language didn't also provide a way around the
self-referential struct problem, and compilers wouldn't deprecate it
anyway, people continued using these two parallel schemes.

>> It's a different kind of named entity than a typedef, and unique in that
>> it /requires/ the combination of keyword and user-identifier.
>
> It's different in that it serves a different purpose.

Which is? I still don't get it. Any struct can have:

typedef? Tag? Declare vars using:

No No struct {...} a,b,c;
Yes No T a,b,c;
No Yes struct Tag a,b,c;
Yes Yes T a,b,c; OR struct Tag a,b,c;

Someone please tell why the language needs such a table with two
columns, or why it is desirable, instead of:

typedef?
No struct {...} a,b,c;
Yes T a,b,c;

or (if I made it like mine) just:

typedef?
Yes T a,b,c;

On 2021-06-07, Bart <bc@freeuk.com> wrote:
> On 07/06/2021 17:15, Kaz Kylheku wrote:
>> On 2021-06-07, Bart <bc@freeuk.com> wrote:
>>> On 07/06/2021 15:25, Malcolm McLean wrote:
>>>> On Monday, 7 June 2021 at 13:00:30 UTC+1, Bart wrote:
>>>>>
>>>>> So, you don't take the same advantage of being able to use Foo and foo?
>>>>>
>>>>> If that case, why do you need a case-sensitive language?
>>>>>
>>>> If the language is case-insensitive, you don't want the same identifier to
>>>> appear in the source in different cases.
>>>
>>> Why is that a problem? You think that, because a syntax is
>>> case-insensitive, that coders will delight is applying random
>>> combinations of case in their identifiers? In any case, you will /know/
>>> they are all the same.
>>
>> When you say case insensitivity, what does that mean? Are these
>> considered the same identifier?
>>
>> δέλτα
>>
>> Δέλτα
>>
>> How about Japanese katakana vs. hiragana. Are these the same
>> identifier?
>>
>> スウジ すうじ
>>
>> すうジ スウじ
>>
>> They both say "suuji"; can you declare using one and reference elsewhere
>> using the others?
>
> I'm mainly talking about language source code which uses the ASCII
> alphabet for keywords and user-identifiers.

But you're convinced that your perspective is broader than that of
anyone else here, right?

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On 07/06/2021 23:26, Kaz Kylheku wrote:
> On 2021-06-07, Bart <bc@freeuk.com> wrote:

>> I'm mainly talking about language source code which uses the ASCII
>> alphabet for keywords and user-identifiers.
>
> But you're convinced that your perspective is broader than that of
> anyone else here, right?
>

No, but you seem to be convinced that yours is.

Mine is a pragmatic approach: many languages do only support this
restricted subset of characters for identifiers, like C.

Programmers don't care as much as you seem to think. Unicode is a
complete minefield, and I think it's best to keep it out of the core
parts of a programming language, and allow it mainly in source comments,
source string literals, file names relevant to the compiler, program
data, and libraries.

But every language makes its own choice.

Long ago I did provide facilities in one of my script languages for
keywords and such to use an extended alphabet (then, for western
european languages), but users weren't bothered; they got on fine with
the English!

Besides, there is an awful lot more to it than just allowing Unicode in
identifiers, or even those aspects I mentioned above. Suppose I did
support the Japanese alphabet for identifiers in my language implementation:

* Keywords would still be in English

* Named operators are still in English

* Standard type names are in English

* As would be the names of standard library functions, types, macros,
structs, enums and variables

* As would be the case with the vast majority of third party libraries

* Compiler error messages would be in English

* Compiler options would be based on English

* Entry point names would still be 'main' or 'start'. Etc.

So any programmer will still need to encounter English in many places.
If they really want to use their native language for identifiers (and
can deal with the problem of many distinct characters having identical
glyphs among many others), there are languages that will do that.

Including mine with a tweak, in a bit that you snipped, and where I said
it would be case-sensitive as case-insensitivity only applies for A-Z/a-z.

So, what is your point? That the existence of alphabets where letter
case is poorly defined, or meaningless, means we shouldn't be able to
define it for our A-Z? What would you do about languages such as Fortran
and Ada that are still used, but are case-insensitive?

Note that even C is case-insensitive is a few places:

0xABC or 0xabc

1.2e3 or 1.2E3

100ull or 100ULL

u'A' or U'A'

Bart <bc@freeuk.com> writes:
[...]
> Note that even C is case-insensitive is a few places:
>
> 0xABC or 0xabc
>
> 1.2e3 or 1.2E3
>
> 100ull or 100ULL
>
> u'A' or U'A'

u'A' is of type char16_t. U'A' is of type char32_t.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

On 08/06/2021 01:06, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> Note that even C is case-insensitive [in] a few places:
>>
>> 0xABC or 0xabc
>>
>> 1.2e3 or 1.2E3
>>
>> 100ull or 100ULL
>>
>> u'A' or U'A'
>
> u'A' is of type char16_t. U'A' is of type char32_t.
>

OK. So:

0x123 or 0X123

0x123p3 or 0x123P3

#include <stdio.h> or #include <STDIO.H> (on Windows)

The point is, in such contexts, 'A' and 'a' for example are deemed to be
interchangeable. This is the case even though there exist alphabets
where such equivalences don't exist for some or all of the letters.

People are trying to use the latter examples as reasons to banish the
concept of case equivalence in computer systems even for alphabets where
it is perfectly well-defined.

James Harris <james.harris.1@gmail.com> writes:

> Does C, as a language, need to allow its structs to have tags?

<snip example>

> etc but in all such cases struct A is being used as a type. And there
> is a more general feature for that in typedef.
>
> So could C's struct tags be omitted from the language? If not, what
> does a struct tag add? Is it something to do with forward declarations
> or syntactic consistency with union tags, etc?

structs (with tags) predate typedefs. I expect you're right that they
are no longer necessary, but they cause no harm that I know of and
removing them now would break lots of code written by people who don't
like typedefs.

On Tuesday, 8 June 2021 at 15:06:45 UTC+1, Joe Pfeiffer wrote:
> James Harris <james.h...@gmail.com> writes:
>
> > Does C, as a language, need to allow its structs to have tags?
> <snip example>
> > etc but in all such cases struct A is being used as a type. And there
> > is a more general feature for that in typedef.
> >
> > So could C's struct tags be omitted from the language? If not, what
> > does a struct tag add? Is it something to do with forward declarations
> > or syntactic consistency with union tags, etc?
> structs (with tags) predate typedefs. I expect you're right that they
> are no longer necessary, but they cause no harm that I know of and
> removing them now would break lots of code written by people who don't
> like typedefs.
>
You need a tag when a struct contains a pointer to its own kind. Which is quite
common for graph nodes.
In other situations, you have the option - either typedef the struct or use the
"struct mytag" syntax. This isn't really desireable. Programming languages
shouldn't provide two ways to do essentially the same thing. It just
leads to gratuitious inconsistencies, sometimes even incompatibilities.

Le 08/06/2021 à 16:45, Malcolm McLean a écrit :
> On Tuesday, 8 June 2021 at 15:06:45 UTC+1, Joe Pfeiffer wrote:
> You need a tag when a struct contains a pointer to its own kind. Which is quite
> common for graph nodes.

Yep. This is akin to a forward type definition.

> In other situations, you have the option - either typedef the struct or use the
> "struct mytag" syntax. This isn't really desireable. Programming languages
> shouldn't provide two ways to do essentially the same thing. It just
> leads to gratuitious inconsistencies, sometimes even incompatibilities.

I think this just has historical reasons for C, but it's kind of weird
indeed. Especially since, not only does it give two ways of defining and
using struct types, but it also implies separate namespaces. (structs
have their own namespace, as well as enums, unions, then typedefs, ...)

Now as you mentioned above, to get rid of that, C would need to have
another way of declaring a forward type definition. You can define a
forward typedef for structs actually, but it still requires a struct
tag, so that doesn't solve much.

If I'm not mistaken, you can do the following:

typedef struct foo foo_t;

struct foo { ... foo_t *next; };

which would be similar to:

typedef struct foo { ... struct foo *next; } foo_t;

In both cases, you still need a struct tag.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Tuesday, 8 June 2021 at 15:06:45 UTC+1, Joe Pfeiffer wrote:
>> James Harris <james.h...@gmail.com> writes:
>>
>> > Does C, as a language, need to allow its structs to have tags?
>> <snip example>
>> > etc but in all such cases struct A is being used as a type. And there
>> > is a more general feature for that in typedef.
>> >
>> > So could C's struct tags be omitted from the language? If not, what
>> > does a struct tag add? Is it something to do with forward declarations
>> > or syntactic consistency with union tags, etc?
>> structs (with tags) predate typedefs. I expect you're right that they
>> are no longer necessary, but they cause no harm that I know of and
>> removing them now would break lots of code written by people who don't
>> like typedefs.
>>
> You need a tag when a struct contains a pointer to its own kind. Which is quite
> common for graph nodes.
> In other situations, you have the option - either typedef the struct or use the
> "struct mytag" syntax. This isn't really desireable. Programming languages
> shouldn't provide two ways to do essentially the same thing. It just
> leads to gratuitious inconsistencies, sometimes even incompatibilities.

Ah, you are correct. Though if we were eliminating struct tags, we
could modify typedefs so they could have what amounts to a forward
reference (as we can with tagged structs).