On 2021-06-08, Guillaume <message@bottle.org> wrote:
> 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, ...)

It may feel "weird", but the underlying compile-time object model is
quite very clear.

There is a single namespace for declared identifiers in which typedef
names live along with functions and variables.

There is a separate tag namespace which holds only struct/union/enum
types. This has different, useful properties from the regular namespace.

Only typedef links aliases to types into the regular namespace, nothing else.

Even if you have it so that structs are entered into the regular
namespace automatically without typedef, you still needs structs to have
a name property.

When the compiler is looking at some type object, it needs to be able
to ask what its name is.

If we have ethis situation:

struct foo { int x; };
// foo is now a type, without typedef
typedef foo bar;
// bar is now an alias for foo

When bar is used for defining and declaring, the compiler needs
to know that the underlying type that bar refers to is actually
a structure with name foo: a struct foo.

E.g. for diagnostics. If you reference "a.z" where a has been declared
as a bar, you want something like:

parser.c:13: bar has no member z.
foo.h:5: bar is a typedef for foo, defined here.

If a were declared as foo, that might be:

parser.c:13: foo has no member z.
foo.h:5: foo is defined here.

The idea of a tag in the model itself will not go away so easily;
C just lacks the syntactic sugar to conceal it. The model is explicit
to the programmer. Structures have names, and you have to wire those
names into the regular namespace yourself with typedef, if you
want them there.

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

On 2021-06-08, Joe Pfeiffer <pfeiffer@cs.nmsu.edu> wrote:
> 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).

You don't want to eliminate struct tags, because a struct type should
know what its name is. It's just a matter of forwarding that
information to the ordinary namespace.

struct foo; // effectively a forward declaration

// foo is now in the regular identifier namespace as if introduced
// by typedef. It refers to an incomplete type.

struct bar {
foo *pfoo;
};

struct foo {
bar *pbar;
struct xyzzy { // xyzzy introduced into surrounding name space
int plop;
} x;
};

// foo now refers to a complete type

xyzzy *px; // xyzzy known here

When "struct xyzzy" is introduced in the middle of a struct, the
declared identifier x is entered into that struct as a member, and the
typedef name "xyzzy" is introduced into the closest enclosing ordinary
lexical scope or file scope.

Note that this is different from C++, in which xyzzy would be
foo::xyzzy. Anyone who has ever prepared a C API header with nested
structures for C++ use would have run into this.

In other regards, it resembles the C++ solution.

("struct foo" doesn't introduce a typedef name in C++. It introduces a
class name, which has a baggage around it. Class names have linkage and
are subject to the one definition rule and such.)

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

On 08/06/2021 17:00, Kaz Kylheku wrote:
> On 2021-06-08, Guillaume <message@bottle.org> wrote:
>> 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, ...)
>
> It may feel "weird", but the underlying compile-time object model is
> quite very clear.
>
> There is a single namespace for declared identifiers in which typedef
> names live along with functions and variables.
>
> There is a separate tag namespace which holds only struct/union/enum
> types. This has different, useful properties from the regular namespace.
>
> Only typedef links aliases to types into the regular namespace, nothing else.
>
> Even if you have it so that structs are entered into the regular
> namespace automatically without typedef, you still needs structs to have
> a name property.
>
> When the compiler is looking at some type object, it needs to be able
> to ask what its name is.
>
> If we have ethis situation:
>
> struct foo { int x; };
> // foo is now a type, without typedef
> typedef foo bar;
> // bar is now an alias for foo
>
> When bar is used for defining and declaring, the compiler needs
> to know that the underlying type that bar refers to is actually
> a structure with name foo: a struct foo.
>
> E.g. for diagnostics. If you reference "a.z" where a has been declared
> as a bar, you want something like:
>
> parser.c:13: bar has no member z.
> foo.h:5: bar is a typedef for foo, defined here.
>
> If a were declared as foo, that might be:
>
> parser.c:13: foo has no member z.
> foo.h:5: foo is defined here.
>
> The idea of a tag in the model itself will not go away so easily;
> C just lacks the syntactic sugar to conceal it. The model is explicit
> to the programmer. Structures have names, and you have to wire those
> names into the regular namespace yourself with typedef, if you
> want them there.

It sounds as though you are trying to retrospectively justify C's tag
names, simply because the language has them, and you don't want to admit
that they don't belong.

The fact is that if C had had typedef right from the start, tags would
never have existed, and nobody would have thought it was a good idea to
add them.

You /don't/ need a separate tag namespace where even anonymous structs
live. (If you did, pointers and arrays and function pointers would live
there too.)

If an implementation requires that anonymous structs 'belong' to a
symbol table entry, to match named ones, then an anonymous /typedef/,
not user-accessible, can be created. It doesn't need a separate name-space.

The struct will additionally belong to the collection of user-specified
types, which includes pointers, arrays and function pointers.

Bart <bc@freeuk.com> writes:
> 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 interpretation of the h-char-sequence or q-char-sequence in a
#include directive is implementation-defined. The standard says nothing
about case sensitivity. (A conforming Windows C compiler could reject
<STDIO.H>.)

You're right, C is not entirely case-sensitive. I don't recall anyone
claiming otherwise.

[...]

--
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 2021-06-08, Bart <bc@freeuk.com> wrote:
> On 08/06/2021 17:00, Kaz Kylheku wrote:
>> On 2021-06-08, Guillaume <message@bottle.org> wrote:
>>> 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, ...)
>>
>> It may feel "weird", but the underlying compile-time object model is
>> quite very clear.
>>
>> There is a single namespace for declared identifiers in which typedef
>> names live along with functions and variables.
>>
>> There is a separate tag namespace which holds only struct/union/enum
>> types. This has different, useful properties from the regular namespace.
>>
>> Only typedef links aliases to types into the regular namespace, nothing else.
>>
>> Even if you have it so that structs are entered into the regular
>> namespace automatically without typedef, you still needs structs to have
>> a name property.
>>
>> When the compiler is looking at some type object, it needs to be able
>> to ask what its name is.
>>
>> If we have ethis situation:
>>
>> struct foo { int x; };
>> // foo is now a type, without typedef
>> typedef foo bar;
>> // bar is now an alias for foo
>>
>> When bar is used for defining and declaring, the compiler needs
>> to know that the underlying type that bar refers to is actually
>> a structure with name foo: a struct foo.
>>
>> E.g. for diagnostics. If you reference "a.z" where a has been declared
>> as a bar, you want something like:
>>
>> parser.c:13: bar has no member z.
>> foo.h:5: bar is a typedef for foo, defined here.
>>
>> If a were declared as foo, that might be:
>>
>> parser.c:13: foo has no member z.
>> foo.h:5: foo is defined here.
>>
>> The idea of a tag in the model itself will not go away so easily;
>> C just lacks the syntactic sugar to conceal it. The model is explicit
>> to the programmer. Structures have names, and you have to wire those
>> names into the regular namespace yourself with typedef, if you
>> want them there.
>
> It sounds as though you are trying to retrospectively justify C's tag
> names, simply because the language has them, and you don't want to admit
> that they don't belong.

Indeed, if sounds that way if you're only lightly skimming through
my paragraphs in order to confirm that belief.

Though I didn't say that here, do I like languages with multiple
namespaces. Not necessarily the way C does it though. I'd be quite okay
with types, variables and functions all being in separate namespaces.
However, I appreciate the point that types don't have to be split up
further into tags and typedefs.

> The fact is that if C had had typedef right from the start, tags would
> never have existed, and nobody would have thought it was a good idea to
> add them.

My point, if you read more carefully, is that structure types would
still internally hold a reference to a symbol which gives their name,
but that this would not be entered into a separate tag name space that
is visible in the program semantics.

With that, the compiler would be able to dereference a typedef name to a
structure type, and then obtain that type's name in order to know the
original name under which the structure had been introduced, which can
be used as a key into the typedef space again.

That could be useful for diagnostics.

At no point is a tag namespace involved in my description of this.

> If an implementation requires that anonymous structs 'belong' to a
> symbol table entry, to match named ones, then an anonymous /typedef/,
> not user-accessible, can be created. It doesn't need a separate name-space.

That gensym could still be attached to the structure type itself, not
only entered into the type namespace.

I'm mostly here to discuss C. There are a lot of would-be, could-be
debates exactly like this in the comp.std.c newsgroup. I've never
participated there, other than by some cross-posting activity.

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

On 6/6/21 7:16 AM, James Harris wrote:
> Does C, as a language, need to allow its structs to have tags?
>

You can ask the same question of enum and union types - the answer
in all three cases is "yes".

> 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 this is why tags exist. That's how you refer to the specific
struct/union/enum type after its definition.

> And there is
> a more general feature for that in typedef.
>

To reiterate a point I make a lot - typedef on its own creates leaky
abstractions. If I need to know that I have to use the `.` or `->`
operator on something, I'd rather have it declared as `struct A foo;` or
`struct B *ptr;` instead of a type name that doesn't convey struct-ness
at all. Same reason I don't like it when people hide pointers behind
typedefs - I once spent half a day chasing my tail because somebody
created a typedef name for a pointer type and used that as a template
parameter for a vector in C++, such that when I was using an iterator
I needed to write

(*it)->do_something();

However, since the typedef name didn't indicate pointer-ness *at all*, I
wound up writing

it->do_something();

and g++ vomited up hundreds of incomprehensible error messages that
basically boiled down to "you need to use a * here, dummy".

Either create an API that completely abstracts out the struct-ness of
the type (such that you don't have to explicitly use the `.` or `->`
operators), or don't bother with a 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?
>
>

On 08/06/2021 19:59, Kaz Kylheku wrote:
> On 2021-06-08, Bart <bc@freeuk.com> wrote:

>> It sounds as though you are trying to retrospectively justify C's tag
>> names, simply because the language has them, and you don't want to admit
>> that they don't belong.
>
> Indeed, if sounds that way if you're only lightly skimming through
> my paragraphs in order to confirm that belief.
>
> Though I didn't say that here, [I do like?] languages with multiple
> namespaces. Not necessarily the way C does it though. I'd be quite okay
> with types, variables and functions all being in separate namespaces.

That will make some dynamic languages tricky. You write:

A = B

B exists as a type, function and variable; which one is assigned here?
(Probably not a problem in Python however, where everything can be a
considered a variable.)

> However, I appreciate the point that types don't have to be split up
> further into tags and typedefs.
>
>> The fact is that if C had had typedef right from the start, tags would
>> never have existed, and nobody would have thought it was a good idea to
>> add them.
>
> My point, if you read more carefully, is that structure types would
> still internally hold a reference to a symbol which gives their name,
> but that this would not be entered into a separate tag name space that
> is visible in the program semantics.
>
> With that, the compiler would be able to dereference a typedef name to a
> structure type, and then obtain that type's name in order to know the
> original name under which the structure had been introduced, which can
> be used as a key into the typedef space again.

These are examples of user-speciefied-types in C, built using primitives:

int**

float[10]

int(*)(void) (Some sort of function pointer I hope)

struct{int x,y;}

All are anonymous. All can be assigned a typedef to represent each type.
But each exists in a collection of such types within the implementation.

The only difference between struct and the rest, is two different
instances of the same type-spec (say int** in one place and int** in
another) are considered compatible. Less need to tie them together with
a typedef.

But two lots of struct{int x,y;} are considered separate types. Here you
/need/ a typedef to allow multiple instances of that same type. [My
languages don't allow anonymous struct types; they have to be formally
named.]

Apart from a typedef, there's no need for any internal /named/ identifer
here.

Bart <bc@freeuk.com> writes:
[...]
> These are examples of user-speciefied-types in C, built using primitives:
>
> int**
>
> float[10]
>
> int(*)(void) (Some sort of function pointer I hope)

Yes.

> struct{int x,y;}
>
> All are anonymous. All can be assigned a typedef to represent each
> type. But each exists in a collection of such types within the
> implementation.

I wouldn't necessarily call them "anonymous". "Anonymous" usually means
"not having a name", and each of those is syntactically a *type-name*.

> The only difference between struct and the rest, is two different
> instances of the same type-spec (say int** in one place and int** in
> another) are considered compatible. Less need to tie them together
> with a typedef.
>
> But two lots of struct{int x,y;} are considered separate types. Here
> you /need/ a typedef to allow multiple instances of that same
> type. [My languages don't allow anonymous struct types; they have to
> be formally named.]

No, you don't *need* a typedef. You can use a tag instead.
(Yes, you can use a typedef if you don't like tags.)

> Apart from a typedef, there's no need for any internal /named/
> identifer here.

--
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 6/8/21 10:45 AM, Malcolm McLean wrote:
> 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.
>

Actually, you can do:

typedef struct Foo Foo;

struct Foo {
Foo* nextFoo;
};

and not need to use the struct foo in the structure, just in the typedef
and the actual struct definition.

As has been mentioned, the tag namespace existed before typedefs were
created. C could have defined that the struct put its tag into the
normal namespace, but then before typedefs were created it complicates
the parser, as then it needs to look up the name to see if it is a type
or not. Before the typedef, all type names began with a reserved identifier.

When typedefs were invented, there was probably already existing code
that did things like struct foo foo; which would have become an error if
the tag suddenly got promoted to the base namespace.

C++ could do it as they chose to do it early before there was existing
C++ code that did it.

On 6/8/21 11:09 AM, Guillaume wrote:
....
> 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, ...)

Almost: struct, union, and enumeration tags all share a single name
space. Typedefs shares the "ordinary identifier" name space with the
names of objects, functions, macro names and macro parameters (6.2.3).

On 09/06/2021 16:40, James Kuyper wrote:
> On 6/8/21 11:09 AM, Guillaume wrote:
> ...
>> 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, ...)
>
> Almost: struct, union, and enumeration tags all share a single name
> space. Typedefs shares the "ordinary identifier" name space with the
> names of objects, functions, macro names and macro parameters (6.2.3).

Labels bizarrely have their own name space too.

On 2021-06-09, Bart <bc@freeuk.com> wrote:
> On 09/06/2021 16:40, James Kuyper wrote:
>> On 6/8/21 11:09 AM, Guillaume wrote:
>> ...
>>> 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, ...)
>>
>> Almost: struct, union, and enumeration tags all share a single name
>> space. Typedefs shares the "ordinary identifier" name space with the
>> names of objects, functions, macro names and macro parameters (6.2.3).
>
> Labels bizarrely have their own name space too.

It's the same in Common Lisp.

> (block foo (let ((foo 3)) (return-from foo foo)))
3

The block named foo isn't shadowed by the variable foo. Why would it be;
it's a completely different kind of thing.

In C, labels are visible function wide, whereas lexical scope follows
blocks. So that alone calls for a separate namespace.

A primary C expression would never refer to a goto label; there is no
such syntax. Labels are referenced only by goto, which requires a label
name argument; so if labels intefered with lexical variable references,
it would only be a source of gratuitous syntactic clashes with no
underlying semantic clashes.

But ... I'm dying to hear how it's all done nicely in a single namespace
in some shitty language that nobody uses.

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

On 09/06/2021 18:48, Kaz Kylheku wrote:
> On 2021-06-09, Bart <bc@freeuk.com> wrote:
>> On 09/06/2021 16:40, James Kuyper wrote:
>>> On 6/8/21 11:09 AM, Guillaume wrote:

>> Labels bizarrely have their own name space too.
>
> It's the same in Common Lisp.
>
> > (block foo (let ((foo 3)) (return-from foo foo)))
> 3
>
> The block named foo isn't shadowed by the variable foo. Why would it be;
> it's a completely different kind of thing.
>
> In C, labels are visible function wide, whereas lexical scope follows
> blocks. So that alone calls for a separate namespace.

Nonsense. One of my languages uses some 20 categories of identifiers;
should each exist in its private namespace?

>
> A primary C expression would never refer to a goto label; there is no
> such syntax. Labels are referenced only by goto, which requires a label
> name argument; so if labels intefered with lexical variable references,
> it would only be a source of gratuitous syntactic clashes with no
> underlying semantic clashes.

Nonsense. That would be remarkably short-sighted. In GNU C, you can have
expressions like this:

void* p = cond ? &&L1 : &&L2;

where L1 and L2 are labels. But because they exist in a private
namespace, you need to use && instead of &, for the highly dubious
benefit of being able to to have both a label and a function, variable
etc with the same name:

void* L1 = &&L1;

Brilliant; no room for confusion there at all!

C already detects semantic errors like this:

typedef int T;
int a = T;

with it requiring that variables and usertypes are in separate
namespaces. It would be no different with labels.

> But ... I'm dying to hear how it's all done nicely in a single namespace
> in some shitty language that nobody uses.

So you're sticking up for some weird quirk of C that probably 99% of C
programmers don't know about, which only exists because some /shitty/
early compiler couldn't figure out how to implement proper symbol
tables, because.....?

It's somewhat worrying that people make so much of accidents of design.
I mean, it's not as though the designers as C specifically set out to
have a separate name space for labels.

And it they hadn't had that, I doubt you would be here know lamenting
the lack of that feature! It wouldn't have occurred to anyone to have
it. It is completely pointless.

On 2021-06-09, Bart <bc@freeuk.com> wrote:
> On 09/06/2021 18:48, Kaz Kylheku wrote:
>> On 2021-06-09, Bart <bc@freeuk.com> wrote:
>>> On 09/06/2021 16:40, James Kuyper wrote:
>>>> On 6/8/21 11:09 AM, Guillaume wrote:
>
>>> Labels bizarrely have their own name space too.
>>
>> It's the same in Common Lisp.
>>
>> > (block foo (let ((foo 3)) (return-from foo foo)))
>> 3
>>
>> The block named foo isn't shadowed by the variable foo. Why would it be;
>> it's a completely different kind of thing.
>>
>> In C, labels are visible function wide, whereas lexical scope follows
>> blocks. So that alone calls for a separate namespace.
>
> Nonsense. One of my languages uses some 20 categories of identifiers;
> should each exist in its private namespace?

Possibly, yes. Twenty categories of identifiers might legitimately
belong to a single namespace, or two two namespaces, or three, ...
anywhere up to twenty namespaces.

Quite likly, some intermediate number may be reasonable, if the
categories can be grouped into related sub-categories.

Multiple namespaces is nice.

Common Lisp

(defmethod foo ((list list))
(block list
(return-from list (list list)))

Here we have a method parameter list, specialized to class type list:
an object of list type called list. The expression (list list) calls the
list function, passing it the list, to produce a list of it.
This is returned from the block named list.

Perfectly readable to me, without so much as a pause.

>> A primary C expression would never refer to a goto label; there is no
>> such syntax. Labels are referenced only by goto, which requires a label
>> name argument; so if labels intefered with lexical variable references,
>> it would only be a source of gratuitous syntactic clashes with no
>> underlying semantic clashes.
>
> Nonsense. That would be remarkably short-sighted. In GNU C, you can have
> expressions like this:
>
> void* p = cond ? &&L1 : &&L2;
>
> where L1 and L2 are labels. But because they exist in a private
> namespace, you need to use && instead of &, for the highly dubious
> benefit of being able to to have both a label and a function, variable
> etc with the same name:
>
> void* L1 = &&L1;

That's actually a good name for the variable, if it always points to L1.

If L1 is reassigned to point to L2, then L1 is not a good name on that
account.

> Brilliant; no room for confusion there at all!

In the same namespace, we can have confusion via shadowing:

L1:
// ...
{
int L1;
}

There is no design choice in which some people can't write something
which later confuses someone (possibly themselves).

> C already detects semantic errors like this:
>
> typedef int T;
> int a = T;

That's pretty dumb; typedefs should have their own namespace.

I would not make a career of ranting about this on Usenet, though.

The thing I value most in C is staying the same, and being widely
portable. No matter how much I believe in some improvement, I would
rather it not be made. If it were made, I wouldn't use it.

>> But ... I'm dying to hear how it's all done nicely in a single namespace
>> in some shitty language that nobody uses.
>
> So you're sticking up for some weird quirk of C that probably 99% of C
> programmers don't know about, which only exists because some /shitty/
> early compiler couldn't figure out how to implement proper symbol
> tables, because.....?

I believe that labels in their own namespace is a good design.
Very well thought out.

> And it they hadn't had that, I doubt you would be here know lamenting
> the lack of that feature!

Of course, that would be your prerogative.

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

On 09/06/2021 18:48, Kaz Kylheku wrote:
> On 2021-06-09, Bart <bc@freeuk.com> wrote:
>> On 09/06/2021 16:40, James Kuyper wrote:
>>> On 6/8/21 11:09 AM, Guillaume wrote:
>>> ...
>>>> 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, ...)
>>>
>>> Almost: struct, union, and enumeration tags all share a single name
>>> space. Typedefs shares the "ordinary identifier" name space with the
>>> names of objects, functions, macro names and macro parameters (6.2.3).
>>
>> Labels bizarrely have their own name space too.
>
> It's the same in Common Lisp.
>
> > (block foo (let ((foo 3)) (return-from foo foo)))
> 3
>
> The block named foo isn't shadowed by the variable foo. Why would it be;
> it's a completely different kind of thing.
>
> In C, labels are visible function wide, whereas lexical scope follows
> blocks. So that alone calls for a separate namespace.

It calls for different scoping rules. Labels are assigned to the
outermost block of a function.

That's if you wanted similar behaviour with labels always having
function-wide scope.

Non-label identifiers either are not allowed to shadow label names, or are.

Alternatively, label names follow exactly the same rules as other
identifiers in a function, with label names inside blocks able to shadow
each other. This is how it works with Algol68 that also has block scopes.

I've never implemented block scopes in a language of mine (only in C),
and there the rules are very simple: a function has exactly one scope,
and there is one namespace.

Bart <bc@freeuk.com> writes:
> On 09/06/2021 18:48, Kaz Kylheku wrote:
[...]
>> In C, labels are visible function wide, whereas lexical scope follows
>> blocks. So that alone calls for a separate namespace.
>
> It calls for different scoping rules. Labels are assigned to the
> outermost block of a function.
>
> That's if you wanted similar behaviour with labels always having
> function-wide scope.
[...]

Label names have function scope, not block scope. They're the only
kind of identifier that has function scope.

I suppose they could have been described as being scoped to the
outermost block of the function (since goto statements and labeled
statements can only appear within that block), but then you'd still
have to describe the special rule that a label name is visible
before the labeled statement that creates 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 09/06/2021 22:28, Kaz Kylheku wrote:
> On 2021-06-09, Bart <bc@freeuk.com> wrote:

> Possibly, yes. Twenty categories of identifiers might legitimately
> belong to a single namespace, or two two namespaces, or three, ...
> anywhere up to twenty namespaces.

All that can occur as top-level names in an expression (not following
"." or other special syntax) are in one namespace, which is most of them.

Each also belongs inside a real namespace, one created by a module,
record or function. There is no need for artificial namespaces just so I
can use A, A and A for different purposes inside the same scope.

I would call that an anti-feature.

> Quite likly, some intermediate number may be reasonable, if the
> categories can be grouped into related sub-categories.
>
> Multiple namespaces is nice.
>
> Common Lisp
>
> (defmethod foo ((list list))
> (block list
> (return-from list (list list)))

The 'spam spam spam and spam' school of coding.

> Here we have a method parameter list, specialized to class type list:
> an object of list type called list. The expression (list list)

(There are two (list list)s in the example.)

> calls the
> list function, passing it the list, to produce a list of it.
> This is returned from the block named list.
>
> Perfectly readable to me, without so much as a pause.

To /you/. I expect your example could also be tweaked to be:

(List lIst ((list list))
(liSt list
(lisT list (list list)))

To do away altogether with that pesky problem of needing to think up
distinct identifiers for your 100,000-line application.

On 2021-06-09, Bart <bc@freeuk.com> wrote:
> On 09/06/2021 18:48, Kaz Kylheku wrote:
>> On 2021-06-09, Bart <bc@freeuk.com> wrote:
>>> On 09/06/2021 16:40, James Kuyper wrote:
>>>> On 6/8/21 11:09 AM, Guillaume wrote:
>>>> ...
>>>>> 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, ...)
>>>>
>>>> Almost: struct, union, and enumeration tags all share a single name
>>>> space. Typedefs shares the "ordinary identifier" name space with the
>>>> names of objects, functions, macro names and macro parameters (6.2.3).
>>>
>>> Labels bizarrely have their own name space too.
>>
>> It's the same in Common Lisp.
>>
>> > (block foo (let ((foo 3)) (return-from foo foo)))
>> 3
>>
>> The block named foo isn't shadowed by the variable foo. Why would it be;
>> it's a completely different kind of thing.
>>
>> In C, labels are visible function wide, whereas lexical scope follows
>> blocks. So that alone calls for a separate namespace.
>
> It calls for different scoping rules. Labels are assigned to the
> outermost block of a function.

Unfortunately, then if they are in the same namespace, then what
it means that identifiers are not added to the scope in lexical order.

{ int x; // 0
{ int x; // 1
x: ; } } // 3

The level 1 x shadows level 0 x, but then the level 3 x is shadowed by
both of them; effectively it doesn't exist.

When x: is seen, the compiler grabs the function-level lexical
environment, and slides x into there, rather than the current
environment.

It's a workable design, to be sure, and programmers can learn the
rules. Though nobody cares about this and it will never happen.

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

On 10/06/2021 00:47, Bart wrote:
> On 09/06/2021 22:28, Kaz Kylheku wrote:
>> On 2021-06-09, Bart <bc@freeuk.com> wrote:
>
>> Possibly, yes. Twenty categories of identifiers might legitimately
>> belong to a single namespace, or two two namespaces, or three, ...
>> anywhere up to twenty namespaces.
>
> All that can occur as top-level names in an expression (not following
> "." or other special syntax) are in one namespace, which is most of them.
>
> Each also belongs inside a real namespace, one created by a module,
> record or function. There is no need for artificial namespaces just so I
> can use A, A and A for different purposes inside the same scope.
>
> I would call that an anti-feature.

I would look at the other way round. There is no language reason why,
say, type names, variables and functions should share the same namespace
- they are different concepts, for different purposes. There is no
advantage to them sharing the same namespace. Separate namespaces for
different types of identifiers makes sense. (And it does not /force/
people to abuse them to write confusing code.) Of course hierarchical
namespaces based on modules, classes, etc., is also a good thing - it is
one of the major advantages of C++ over C when dealing with larger code
bases.

The namespacing choices in C were based primarily on having a direct
mapping from identifiers in the language to identifiers in the generated
assembly. And after that, like most aspects of C things were not
changed unless there was overwhelming reason to change them.

If you want a tool to give warnings that re-using the same name is a
poor idea, that's fine - but there are endless choices of names that are
allowed in pretty much any language that are confusing. I don't read
Lisp, but I'm happy to believe Kaz sees "list (list list)" as clear. I
am less happy to believe you find "int all, al1, a1l, a11;" as clear -
yet those names are fine in your language and almost any other language.

On 10/06/2021 10:14, David Brown wrote:
> On 10/06/2021 00:47, Bart wrote:
>> On 09/06/2021 22:28, Kaz Kylheku wrote:
>>> On 2021-06-09, Bart <bc@freeuk.com> wrote:
>>
>>> Possibly, yes. Twenty categories of identifiers might legitimately
>>> belong to a single namespace, or two two namespaces, or three, ...
>>> anywhere up to twenty namespaces.
>>
>> All that can occur as top-level names in an expression (not following
>> "." or other special syntax) are in one namespace, which is most of them.
>>
>> Each also belongs inside a real namespace, one created by a module,
>> record or function. There is no need for artificial namespaces just so I
>> can use A, A and A for different purposes inside the same scope.
>>
>> I would call that an anti-feature.
>
> I would look at the other way round. There is no language reason why,
> say, type names, variables and functions should share the same namespace
> - they are different concepts, for different purposes.

What would:

print(A)

mean when A could exist in half a dozen different namespaces?

I can see how it would be terribly attractive to people to have
different namespaces for types, functions, and even arrays, structs,
pointers and *keywords* because they might be distinguished by syntax
and/or context.

Personally I view it all as crazy (plenty of wacko ideas like this on
reddit).

Being theoretically possible doesn't mean it is a good idea. Whatever
arcane algorithms a compiler has to apply to sort out the mess, the
reader of the code has to do the same.

> There is no
> advantage to them sharing the same namespace.

Yes there is. But I'm not going to convince you.

> Separate namespaces for
> different types of identifiers makes sense.

No there isn't.

Remember my print(A) example? See my dynamic language example at the end
where 10 different categories of A in the same scope (but they need
different names) are printed. All exist in the same namespace.

What would it look like when there are multiple namespaces?

> If you want a tool to give warnings that re-using the same name is a
> poor idea, that's fine - but there are endless choices of names that are
> allowed in pretty much any language that are confusing. I don't read
> Lisp, but I'm happy to believe Kaz sees "list (list list)" as clear. I
> am less happy to believe you find "int all, al1, a1l, a11;" as clear -
> yet those names are fine in your language and almost any other language.

These aren't fine in mine because they clash:

int all, alL, aLl, aLL, All, AlL, ALl, ALL

Meanwhile C allows:

int all, all, all, all;

====================================================================

proc d={}

proc fn(i)=
type a = int32
type b = record(var x)
type c = struct(int32 x)
e::
importdll msvcrt=clang proc f end
const g=100
enum (h)
static var j=20
var k:=30

println =A
println =B, tab, B.$, (new(b).basetype)
println =C, tab, C.$, (new(c).basetype)
println =D
println =E
println =F
println =G, tab, G.$
println =H, tab, H.$
println =I, tab, I.$
println =J, tab, J.$
println =K, tab, K.$
end

fn(10)

------------------------------

The X.$ construct gives info about the symbol itself, when print doesn't
display that anyway. The output is:

A= int32
B= b <type:"b"> record
C= c <type:"c"> struct
D= <proc:"d">
E= <label:"e">
F= <dllproc:"f">
G= 100 <const:"g">
H= 1 <enum:"h">
I= 10 <param:"i">
J= 20 <static:"j">
K= 30 <frame:"k">

Not included because I can't print them are named operators like 'abs',
but they are all in the one namespace too.

However I do use alternate namespaces in certain very limited cases:

println 3 million
million := 777

'million' is a 1000000x scaling factor in the first context, but can
otherwise be a normal identifier.

On 10/06/2021 13:38, Bart wrote:
> On 10/06/2021 10:14, David Brown wrote:
>> On 10/06/2021 00:47, Bart wrote:
>>> On 09/06/2021 22:28, Kaz Kylheku wrote:
>>>> On 2021-06-09, Bart <bc@freeuk.com> wrote:
>>>
>>>> Possibly, yes. Twenty categories of identifiers might legitimately
>>>> belong to a single namespace, or two two namespaces, or three, ...
>>>> anywhere up to twenty namespaces.
>>>
>>> All that can occur as top-level names in an expression (not following
>>> "." or other special syntax) are in one namespace, which is most of
>>> them.
>>>
>>> Each also belongs inside a real namespace, one created by a module,
>>> record or function. There is no need for artificial namespaces just so I
>>> can use A, A and A for different purposes inside the same scope.
>>>
>>> I would call that an anti-feature.
>>
>> I would look at the other way round.  There is no language reason why,
>> say, type names, variables and functions should share the same namespace
>> - they are different concepts, for different purposes.
>
> What would:
>
>    print(A)
>
> mean when A could exist in half a dozen different namespaces?

That would depend on how "print" is defined. For most possible kind of
identifiers, printing makes no sense - you don't "print" a label, a
function, or a type. You only print things with values, and those would
be in the same namespace.

>
> I can see how it would be terribly attractive to people to have
> different namespaces for types, functions, and even arrays, structs,
> pointers and *keywords* because they might be distinguished by syntax
> and/or context.

Different namespaces make sense for things that can't be used in the
same way or in the same kind of context. In a C-like language, arrays,
structs, and scalers are all objects with values that can be used
similarly - so you'd have them in the same namespace. A type definition
(struct declaration, typedef, etc.) is totally different. So is a
function (but not a function pointer or the address of a function). So
they could happily be in different namespaces.

In a functional programming language, functions can be treated as
objects so they might be in the same namespace.

No one (but you) is suggesting having different namespaces for things
that may be used in the same way.

>
> Personally I view it all as crazy (plenty of wacko ideas like this on
> reddit).

Having listened to your ideas about programming languages over the
years, your misconceptions and misunderstandings about C, and your
attempts to take language design and coding styles back to the 1970's,
you'll forgive me if I don't place any weight on what you think is
"crazy" or "wacko". (I'm quite happy for you to describe things that
way, I just don't assume it is an opinion I or anyone else would share.)
I've seen some outstandingly bad ideas from your languages and coding
style, and some excellent ideas - enough variation to know that I don't
trust your judgement here.

>
> Being theoretically possible doesn't mean it is a good idea. Whatever
> arcane algorithms a compiler has to apply to sort out the mess, the
> reader of the code has to do the same.
>

"Arcane algorithms" ? The compiler - and the programmer - needs to be
able to parse the code enough to tell if an identifier is a type, a
function or a variable (or something else). The compiler keeps track by
having three hashmaps for the symbol tables instead of one. That really
is not rocket science.

>> There is no
>> advantage to them sharing the same namespace.
>
> Yes there is. But I'm not going to convince you.

Try it.

Start from "You see an identifier in the code, and you know from the
context and grammar of the language that it is a type." Explain what
advantages there are to the programmer that this is in the same
namespace as function names and object names.

>
>> Separate namespaces for
>> different types of identifiers makes sense.
>
> No there isn't.
>
> Remember my print(A) example? See my dynamic language example at the end
> where 10 different categories of A in the same scope (but they need
> different names) are printed. All exist in the same namespace.
>
> What would it look like when there are multiple namespaces?

Your "print(A)" example? You mean, when you said "what would print(A)
mean" ? Was that supposed to be an example of something relevant?

If you have a language for which it makes sense to "print" a function or
a type, then in such a language you would view both functions and types
as things with a value, and you'd then want them in the same namespace.
If it doesn't make sense (and usually it doesn't), then different
namespaces are fine.

The only time separate namespaces can be a disadvantage is if you might
want to use items from the different namespaces in the same context,
/and/ it is likely that there would be a conflict of names, /and/ there
is no other convenient way to resolve the ambiguity. If you expect
"print(A)", given a type, to print the type's name, then you could say
the "print" function takes an object, not a type - and in the rare cases
where you want to print a type's name, you write "print(typename(A))".
Problem solved (if there ever was a problem).

>
>> If you want a tool to give warnings that re-using the same name is a
>> poor idea, that's fine - but there are endless choices of names that are
>> allowed in pretty much any language that are confusing.  I don't read
>> Lisp, but I'm happy to believe Kaz sees "list (list list)" as clear.  I
>> am less happy to believe you find "int all, al1, a1l, a11;" as clear -
>> yet those names are fine in your language and almost any other language.
>
> These aren't fine in mine because they clash:
>
>   int all, alL, aLl, aLL, All, AlL, ALl, ALL

But you still allow "int all, al1, a1l, a11;" as four different
identifiers that are easily confused. Stop trying to wiggle out of it
by bringing up straw men.

>
> Meanwhile C allows:
>
>   int all, all, all, all;

It does indeed - but that is the same as just "int all;". It is not
declaring or defining multiple objects - you are again bringing up straw
men.

Face it. Your language allows confusing code and identifiers, just like
/every/ other programming language. Your language does not /force/
people to use confusing identifiers - nor do any other languages (baring
the intentionally esoteric ones). There may be minor differences in
detail regarding what different languages allow or do not allow, but the
principle is the same.

On 10/06/2021 14:30, David Brown wrote:
> On 10/06/2021 13:38, Bart wrote:

> That would depend on how "print" is defined. For most possible kind of
> identifiers, printing makes no sense - you don't "print" a label, a
> function, or a type. You only print things with values, and those would
> be in the same namespace.

> If you have a language for which it makes sense to "print" a function

You mean like C:

#include <stdio.h>
#include <stdint.h>

void fn(void){}

int main(void){
printf("%p\n",(void*)(intptr_t)fn);
}

In any case, a function name without () is considered a value.

or
> a type, then in such a language you would view both functions and types
> as things with a value, and you'd then want them in the same namespace.
> If it doesn't make sense (and usually it doesn't), then different
> namespaces are fine.
>
> The only time separate namespaces can be a disadvantage is if you might
> want to use items from the different namespaces in the same context,
> /and/ it is likely that there would be a conflict of names, /and/ there
> is no other convenient way to resolve the ambiguity. If you expect
> "print(A)", given a type, to print the type's name, then you could say
> the "print" function takes an object, not a type - and in the rare cases
> where you want to print a type's name, you write "print(typename(A))".

So you need special syntax - 'typename', which cannot be a regular
function - to disambiguate. A kind of Hungarian notation.

> Problem solved (if there ever was a problem).

The problem doesn't exist yet. It will do if you introduce these namespaces.

>>
>>> If you want a tool to give warnings that re-using the same name is a
>>> poor idea, that's fine - but there are endless choices of names that are
>>> allowed in pretty much any language that are confusing.  I don't read
>>> Lisp, but I'm happy to believe Kaz sees "list (list list)" as clear.  I
>>> am less happy to believe you find "int all, al1, a1l, a11;" as clear -
>>> yet those names are fine in your language and almost any other language.
>>
>> These aren't fine in mine because they clash:
>>
>>   int all, alL, aLl, aLL, All, AlL, ALl, ALL
>
> But you still allow "int all, al1, a1l, a11;" as four different
> identifiers that are easily confused. Stop trying to wiggle out of it
> by bringing up straw men.
>
>>
>> Meanwhile C allows:
>>
>>   int all, all, all, all;
>
> It does indeed - but that is the same as just "int all;". It is not
> declaring or defining multiple objects - you are again bringing up straw
> men.
>
> Face it. Your language allows confusing code and identifiers, just like
> /every/ other programming language.

For every 6-letter variable name, C allows 64 distinct variations in the
same scope, or 192 across the 3 namespaces, by using case differences.

I allow exactly one. So while I can't eliminate all misguided
identifiers, I can do something about an awful lot of them.

With a longer name like LabelOffsetTable, C allows nearly 192K
variations (64K variables etc, 64K tags, 64K labels) ...

.... per block (labels are limited to 64K across a function).

I still allow exactly one.

I really don't understand the preoccupation of some people with reusing
the same identifier over and over again:

* abc is not enough, you need 8 variations via case differences

* 8 is not enough, you need 24 across variable, tag and label namespaces

* 24 is still not enough, you additionally need function and type namespaces

* 40 is STILL not enough, you need to resuse the same ones (or 32 of
them) inside every {} block!

*That* is not crazy?

On 10/06/2021 16:18, Bart wrote:
> On 10/06/2021 14:30, David Brown wrote:
>> On 10/06/2021 13:38, Bart wrote:
>
>> That would depend on how "print" is defined.  For most possible kind of
>> identifiers, printing makes no sense - you don't "print" a label, a
>> function, or a type.  You only print things with values, and those would
>> be in the same namespace.
>
>> If you have a language for which it makes sense to "print" a function
>
> You mean like C:
>
>  #include <stdio.h>
>  #include <stdint.h>
>
>  void fn(void){}
>
>  int main(void){
>      printf("%p\n",(void*)(intptr_t)fn);
>  }

That is not "printing" a function. It is taking the /address/ of a
function - something entirely different (the address of your house is
not the same thing as your house). Then you are casting it to a pointer
(in a way that is not actually defined by the C standards - but let's
skip that for now). All in all, you are printing an object that refers
to a function, you are not printing the function.

>
> In any case, a function name without () is considered a value.

In C, it is considered the address of the function.

This means that in C, you could not make functions and objects have
separate namespaces. But that's fine - no one is suggesting changing C.

In a hypothetical new language, you could easily have the function name
referring to the function, not its address, and it could be in a
separate namespace. "Printing" the function would not make sense. If
you really wanted to show its address (rarely a useful thing to do), you
could write "print(function_address(foo))", or something like that.

>
>
>  or
>> a type, then in such a language you would view both functions and types
>> as things with a value, and you'd then want them in the same namespace.
>>   If it doesn't make sense (and usually it doesn't), then different
>> namespaces are fine.
>>
>> The only time separate namespaces can be a disadvantage is if you might
>> want to use items from the different namespaces in the same context,
>> /and/ it is likely that there would be a conflict of names, /and/ there
>> is no other convenient way to resolve the ambiguity.  If you expect
>> "print(A)", given a type, to print the type's name, then you could say
>> the "print" function takes an object, not a type - and in the rare cases
>> where you want to print a type's name, you write "print(typename(A))".
>
> So you need special syntax - 'typename', which cannot be a regular
> function - to disambiguate. A kind of Hungarian notation.
>

No, it would be a function which takes a type and returns its name. I
see nothing special about that (even though you can't write such
functions in C.) It would be silly to create a new modern language that
does not have at least that level of introspection.

And no, it is not a "kind of Hungarian notation" - that comment makes no
sense to anyone who knows what "Hungarian notation" means.

>> Problem solved (if there ever was a problem).
>
> The problem doesn't exist yet. It will do if you introduce these
> namespaces.
>

No, it would not.

<snip>

Look, we know you don't like people to use a variety of names - you'd
really be happier if we stuck to an old Fortran-era convention of
all-caps identifiers of no more than 6 letters. We know you don't like
structured programming. You don't like macros, you don't like types,
you don't like generic programming, you don't like object oriented
programming, you don't like strong typing, you don't like anything
popularised since the ZX Spectrum was at its peak.

Basically, you want a cross between assembly and BASIC.

That's okay - you make whatever language suits you. Just don't expect
anyone else to think you've got the perfect language, or that you can
judge what features of a language would be practical or useful to others.

On 2021-06-10, Bart <bc@freeuk.com> wrote:
> On 10/06/2021 10:14, David Brown wrote:
>> On 10/06/2021 00:47, Bart wrote:
>>> On 09/06/2021 22:28, Kaz Kylheku wrote:
>>>> On 2021-06-09, Bart <bc@freeuk.com> wrote:
>>>
>>>> Possibly, yes. Twenty categories of identifiers might legitimately
>>>> belong to a single namespace, or two two namespaces, or three, ...
>>>> anywhere up to twenty namespaces.
>>>
>>> All that can occur as top-level names in an expression (not following
>>> "." or other special syntax) are in one namespace, which is most of them.
>>>
>>> Each also belongs inside a real namespace, one created by a module,
>>> record or function. There is no need for artificial namespaces just so I
>>> can use A, A and A for different purposes inside the same scope.
>>>
>>> I would call that an anti-feature.
>>
>> I would look at the other way round. There is no language reason why,
>> say, type names, variables and functions should share the same namespace
>> - they are different concepts, for different purposes.
>
> What would:
>
> print(A)
>
> mean when A could exist in half a dozen different namespaces?

Print the value of variable A.

On 6/10/2021 4:55 PM, David Brown wrote:
> No, it would be a function which takes a type and returns its name. I
> see nothing special about that (even though you can't write such
> functions in C.) It would be silly to create a new modern language that
> does not have at least that level of introspection.

I'm going to make a note about this, although extrapolated from context.

I don't think it would be silly.
I mean, introspection is well known, and quite popular in /some/ kind of
programming, but IMO it is not a "must have" feature that would be silly
to miss.
Nor makes a language modern per se - it is rather a feature that comes
cheap with interpreted and JIT languages, which have gotten popular
because of their perception of being easy to use.