I've been following with interest many of the threads started
by James Harris over the year and frequently the topic of
namespaces and modularity come up. Most recently in the
"Power operator and replacement..." thread.

And I tend to find myself on James' side through unfamiliarity
with the other option. What's the big deal about namespaces
and modules? What do they cost and what do they facilitate?

On 16/11/2021 16:16, luserdroog wrote:
> I've been following with interest many of the threads started
> by James Harris over the year and frequently the topic of
> namespaces and modularity come up. Most recently in the
> "Power operator and replacement..." thread.
>
> And I tend to find myself on James' side through unfamiliarity
> with the other option. What's the big deal about namespaces
> and modules? What do they cost and what do they facilitate?
>

"namespaces" are just a way to collect identifiers in a group. In C,
all global (external linkage) identifiers in a program are in the same
namespace. So you have to make your own namespaces for your code:

void timers_init();
void timers_enable();
int timers_get_current();
void timers_set_frequency(double);

etc.

With namespaces, you could have this all in a namespace:

namespace timers {
void init();
void enable();
int get_current();
void set_frequency(double);
}

You can use them as "timers::init();" or by pulling them into the
current scope with "using timers; enable();".

The cost is that the identifiers (functions and objects) no longer match
the source code name and the assembly level name - you need some kind of
mangling (it could be as simple as $timers$init, if you don't need
mangling for overloads or other purposes).

The benefit is that it is easier to structure the code. You can have
nice long namespace identifiers that are clear and explicit when you
only need them occasionally, but in parts of the code that use the
identifiers a lot you can have a "using" clause and avoid cluttering the
code with the namespace. This is all a big improvement over having to
use long identifier names all the time, or having cryptic abbreviations.
All in all, you get nicer code and far less risk of identifier collisions.

There is not a lot of difference between having a namespace, and having
a class containing only static methods and objects.

(I've used the C++ syntax here, but other languages have much the same
idea though they may use slightly different syntax.)

"modules" are a way of having a pre-compiled unit of code. Typically
languages have separate "interface" and "implementation" parts. A
module may or may not correspond to a namespace - that varies by
language. Basically, modules are more formalized and more restrictive
than C's header and C file setup, which means you can have a safer,
clearer and more efficient approach. A compiled module may also contain
more information than just the assembly/object code and identifiers - it
can have code in internal formats so that you can do cross-module
optimisation or static error checking.

On 16/11/2021 15:16, luserdroog wrote:
> I've been following with interest many of the threads started
> by James Harris over the year and frequently the topic of
> namespaces and modularity come up. Most recently in the
> "Power operator and replacement..." thread.
>
> And I tend to find myself on James' side through unfamiliarity
> with the other option. What's the big deal about namespaces
> and modules? What do they cost and what do they facilitate?
>

There's no runtime overhead (depending on how dynamic a language is).

Typical characterics of modules (as I implement them in my):

* Names (functions, variables, named constants, types, enums, macros)
are usually local to a module

* To share them with other modules, they are marked as 'global'.

* To import names from a specific module A, use:

import A

* This then makes visible, say, a function F in A provided it is 'global'

* The name of the module creates a namespace 'A'. To call F, use A.F().

* However (in my stuff, others may frown upon this), I don't need the
qualifier 'A'; I just use F().

* I only need A.F() if I import modules A and B, and they both export F.
Then I need A.F() or B.F() to disambiguate

* Namespaces are also created with (in my languages) records (used as
classes) and functions, which can both be used to encapsulate data. But
I use this rarely.

The above describes my older module scheme, which I'm just replacing
with a newer one. All my schemes are described in more depth here,
although it is for those already familiar with modules:

https://github.com/sal55/langs/tree/master/Modules2021

The above corresponds to scheme III, and I've just moved to IV, which
goes a little beyond individual modules.

On 16/11/2021 16:11, David Brown wrote:
> On 16/11/2021 16:16, luserdroog wrote:

>> I've been following with interest many of the threads started
>> by James Harris over the year and frequently the topic of
>> namespaces and modularity come up. Most recently in the
>> "Power operator and replacement..." thread.
>>
>> And I tend to find myself on James' side through unfamiliarity
>> with the other option. What's the big deal about namespaces
>> and modules? What do they cost and what do they facilitate?

....

> namespace timers {
> void init();
> void enable();
> int get_current();
> void set_frequency(double);
> }
>
> You can use them as "timers::init();" or by pulling them into the
> current scope with "using timers; enable();".

As this is about namespaces, I'd suggest some problems with that "using
timers" example:

* AIUI it mixes the names from within 'timers' into the current
namespace. If that's right then a programmer taking such an approach
would have to avoid having his own versions of those names. (I.e. no
'enable' or 'init' names in the local scope.)

* If multiple namespaces are imported in the same way then there's
another potential for name conflicts. It's especially bad for names
imported from external files.

* There could be a stable situation with no name conflicts, but then an
upgrade to an imported module which is not directly under the
programmer's control could introduce a new name which /does/ conflict.

Therefore namespace support needs to be more extensive and more
restrictive, IMO. For example,

namespace T = lib.org.timers

then

T.enable()

In that, T would be a name in the local scope that the programmer could
control and ensure it doesn't conflict with any other names. The import
could be

namespace timers = lib.org.timers

Then the name 'timers' would be local. The programmer would still be
/required/ to specify the namespace name as in

timers.enable()

>
> The cost is that the identifiers (functions and objects) no longer match
> the source code name and the assembly level name - you need some kind of
> mangling (it could be as simple as $timers$init, if you don't need
> mangling for overloads or other purposes).

Interesting point. Can you give an example?

--
James Harris

On 2021-11-17 10:43, James Harris wrote:
> On 16/11/2021 16:11, David Brown wrote:

>> namespace timers {
>>     void init();
>>     void enable();
>>     int get_current();
>>     void set_frequency(double);
>> }
>>
>> You can use them as "timers::init();" or by pulling them into the
>> current scope with "using timers; enable();".
>
> As this is about namespaces, I'd suggest some problems with that "using
> timers" example:
>
> * AIUI it mixes the names from within 'timers' into the current
> namespace. If that's right then a programmer taking such an approach
> would have to avoid having his own versions of those names. (I.e. no
> 'enable' or 'init' names in the local scope.)
>
> * If multiple namespaces are imported in the same way then there's
> another potential for name conflicts. It's especially bad for names
> imported from external files.

You mean making simple names inside the namespace directly visible in
the scope? Because there are two kind of imports:

1. Making the namespace visible without direct visibility of its names.
So you must qualify the simple name Foo from My_Namespace:

My_Namespace.Foo
[ My_Namespace::Foo in C++ ]

2. Making simple names directly visible. So you can omit all parents:

Foo

> * There could be a stable situation with no name conflicts, but then an
> upgrade to an imported module which is not directly under the
> programmer's control could introduce a new name which /does/ conflict.

You are talking about #2. There are two approaches to that:

2.1. Allow direct visiblity so long there is no conflicts inside the
scope. E.g. let both Namespace_1 and Namespace_2 have Foo, but the code
does not refer to Foo, then is OK.

2.2. Disallow it even if there is no conflicts inside the scope. This
would prevent surprises so long the namespaces are stable. Of course a
modification of a namespace can break an existing program. However this
is not a problem from the SW development POV, because you must review
the client code anyway if you change any namespace it uses.

> Therefore namespace support needs to be more extensive and more
> restrictive, IMO. For example,
>
>   namespace T = lib.org.timers
>
> then
>
>   T.enable()
>
> In that, T would be a name in the local scope that the programmer could
> control and ensure it doesn't conflict with any other names. The import
> could be
>
>   namespace timers = lib.org.timers
>
> Then the name 'timers' would be local. The programmer would still be
> /required/ to specify the namespace name as in
>
>   timers.enable()

These are "fully qualified names," i.e. #1. Note that T and Timers are
simple names and may still conflict with some other T's and Timers'. You
have further choices:

A. You allow overloading of Timers. Let only one of Timers has Enable:

Timers.Enable

This is OK, if another Timers has no Enable

B. You do not allow it regardless.

Ada has both #1 and #2. It uses #2.1(A). The predefined package Standard
is the root namespace. So, qualified names may use it to disambiguate,
e.g. like

Standard.Timers.Enable

You can mix #1 and #2. I.e. if a fully qualified name is Standard.A.B.C,
then A.B.C is OK because Standard is directly visible #2. If you make
Standard.A directly visible, then B.C would be also OK. If you make
Standard.A.B directly visible, then you could use just C.

>> The cost is that the identifiers (functions and objects) no longer match
>> the source code name and the assembly level name - you need some kind of
>> mangling (it could be as simple as $timers$init, if you don't need
>> mangling for overloads or other purposes).
>
> Interesting point. Can you give an example?

See C++ name mangling. GNAT Ada compiler does it too, but it uses a
different schema.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 17/11/2021 10:43, James Harris wrote:
> On 16/11/2021 16:11, David Brown wrote:
>> On 16/11/2021 16:16, luserdroog wrote:
>
>>> I've been following with interest many of the threads started
>>> by James Harris over the year and frequently the topic of
>>> namespaces and modularity come up. Most recently in the
>>> "Power operator and replacement..." thread.
>>>
>>> And I tend to find myself on James' side through unfamiliarity
>>> with the other option. What's the big deal about namespaces
>>> and modules? What do they cost and what do they facilitate?
>
> ...
>
>> namespace timers {
>>     void init();
>>     void enable();
>>     int get_current();
>>     void set_frequency(double);
>> }
>>
>> You can use them as "timers::init();" or by pulling them into the
>> current scope with "using timers; enable();".
>
> As this is about namespaces, I'd suggest some problems with that "using
> timers" example:
>
> * AIUI it mixes the names from within 'timers' into the current
> namespace. If that's right then a programmer taking such an approach
> would have to avoid having his own versions of those names. (I.e. no
> 'enable' or 'init' names in the local scope.)

That is exactly correct. The benefit of "using" is that by importing an
identifier into the current scope, you can use that identifier without
the full namespace qualification. It is precisely so that you can use
"enable();" without having to write "timers::enable();". The
disadvantage, of course, is that if you have other "enable" identifiers,
there will be an ambiguity or conflict.

Often you will have the "using" clauses in a local scope (within a
function, for example, rather than at file scope). And languages often
support abbreviations or aliasing (in C++, you can use "namespace tmrs =
timers;", though clearly it makes most sense for long or nested namespaces).

This is standard stuff for any programming language that supports a
significant level of nested scopes - whether by modules, sub-modules,
classes, namespaces, units, or whatever the language supports and
whatever terminology it uses.

>
> * If multiple namespaces are imported in the same way then there's
> another potential for name conflicts. It's especially bad for names
> imported from external files.
>

Yes - again, that's why you typically keep the "using" clause in a local
scope. In C++, you are advised not to put a "using" clause at file
scope in a header, for example (putting it within definitions of
functions is fine).

> * There could be a stable situation with no name conflicts, but then an
> upgrade to an imported module which is not directly under the
> programmer's control could introduce a new name which /does/ conflict.
>
> Therefore namespace support needs to be more extensive and more
> restrictive, IMO. For example,
>
>   namespace T = lib.org.timers
>
> then
>
>   T.enable()

Such aliases and abbreviations are definitely a useful feature. But the
key to avoiding name conflicts is to have hierarchical namespaces (of
some sort - possibly modules, units, etc.) and to have something like a
"using" feature that you can have in local scopes to balance
convenience, clarity and avoiding conflicts.

>
> In that, T would be a name in the local scope that the programmer could
> control and ensure it doesn't conflict with any other names. The import
> could be
>
>   namespace timers = lib.org.timers
>
> Then the name 'timers' would be local. The programmer would still be
> /required/ to specify the namespace name as in
>
>   timers.enable()
>

Sure. Support both full namespace imports and aliases, at local scopes
and wider scopes. I wasn't trying to give a complete list of all the
features of namespaces and "using" in C++, merely a few key points. If
you want them all, this site is an excellent reference for C and C++:

<https://en.cppreference.com/w/cpp/language/namespace>

I am not suggesting that C++ is necessarily the model or syntax to copy
- its separation of namespaces and modules has its advantages and
disadvantages, and other languages may choose a different path. And as
always, if you pick the syntax and keywords at the start of language
design, you'll be able to get nicer choices than a language that has
evolved over time.

>>
>> The cost is that the identifiers (functions and objects) no longer match
>> the source code name and the assembly level name - you need some kind of
>> mangling (it could be as simple as $timers$init, if you don't need
>> mangling for overloads or other purposes).
>
> Interesting point. Can you give an example?
>
>

Yes, sure.

extern "C" int foo0(int x) { return x + 1; }

int foo1(int x) { return x + 1; }

namespace space {
int foo2(int x) { return x + 1; }
}

With gcc (identifier mangling in C++ is compiler-specific), you get :

foo0:
lea eax, [rdi+1]
ret
_Z4foo1i:
lea eax, [rdi+1]
ret
_ZN5space4foo2Ei:
lea eax, [rdi+1]
ret

With C, there is no mangling - a function name corresponds directly to
the label at assembly level. C++ includes the types of the parameters
(but not the return type) in a mangled name - the "i" at the end of
"_Z4foo1i" indicates a single "int" parameter, so that you can have
function overloads. When you have namespaces, these need to be included
in the name too. You also need the mangling to include class names for
methods if you support OOP.

If you know your assembler/linker support characters that are not
allowed in the source language - such as $ - then you can probably make
a neater and more compact name-mangling scheme.

It may also be of interest to generate multiple versions or clones of
functions, and have mangled names for them too.

If you have some kind of module system so that compiling one source
module generates a binary "import module" that is needed by users of the
module, then you could have an almost random mangling scheme with a
translation table in the generated import module. There are many
possibilities.

On 17/11/2021 09:43, James Harris wrote:
> On 16/11/2021 16:11, David Brown wrote:
>> On 16/11/2021 16:16, luserdroog wrote:
>
>>> I've been following with interest many of the threads started
>>> by James Harris over the year and frequently the topic of
>>> namespaces and modularity come up. Most recently in the
>>> "Power operator and replacement..." thread.
>>>
>>> And I tend to find myself on James' side through unfamiliarity
>>> with the other option. What's the big deal about namespaces
>>> and modules? What do they cost and what do they facilitate?
>
> ...
>
>> namespace timers {
>>     void init();
>>     void enable();
>>     int get_current();
>>     void set_frequency(double);
>> }
>>
>> You can use them as "timers::init();" or by pulling them into the
>> current scope with "using timers; enable();".
>
> As this is about namespaces, I'd suggest some problems with that "using
> timers" example:
>
> * AIUI it mixes the names from within 'timers' into the current
> namespace. If that's right then a programmer taking such an approach
> would have to avoid having his own versions of those names. (I.e. no
> 'enable' or 'init' names in the local scope.)

It depends on how you make it work. Languages already work with multiple
instances of the same name within nested scopes; it will match the name
in the nearest surrounding scope.

With 'using', it could just introduce an extra scope beyond the ones
that are already known.

With two 'using's in two nested scopes, it gets a bit more involved:

{ using ns1;
{ using ns2;
enable();

If 'enable' exists in both ns1 and ns2, will there be a conflict, or
will it use ns2?

I don't have a 'using' statement. My namespaces are only linked to
module names. And all modules in a program (now, a subprogram) are
visible at the same time. Then there can be a conflict:

import A # both export 'enable'
import B

proc enable = {}

enable()

This is OK; 'enable' is found within the normal set of scopes. But
delete the proc definition, and then there is a conflict.

> * If multiple namespaces are imported in the same way then there's
> another potential for name conflicts. It's especially bad for names
> imported from external files.

Yes, there's a conflict. The same as if you declared 'abc' then declared
another 'abc' in the same scope. Or removed braces so that two 'abc's
are now in the same block scope.

> * There could be a stable situation with no name conflicts, but then an
> upgrade to an imported module which is not directly under the
> programmer's control could introduce a new name which /does/ conflict.

There are all sorts of issues, but most of them already occur with
nested scopes:

{
double abc;
{
int abc;
printf(fmt, abc);

Here, the 'int abc;' could be deleted or commented out. Now 'abc'
matches the other definition, with no detectable error.

On 17/11/2021 10:51, David Brown wrote:
> On 17/11/2021 10:43, James Harris wrote:
>> On 16/11/2021 16:11, David Brown wrote:

....

>>> The cost is that the identifiers (functions and objects) no longer match
>>> the source code name and the assembly level name - you need some kind of
>>> mangling (it could be as simple as $timers$init, if you don't need
>>> mangling for overloads or other purposes).
>>
>> Interesting point. Can you give an example?

....

> If you know your assembler/linker support characters that are not
> allowed in the source language - such as $ - then you can probably make
> a neater and more compact name-mangling scheme.

Where would such namespace mangling be needed? AFAICS only in two cases.

The first is where tools (compiler, linker, debugger, and so on) were
not hierarchy-aware (HA) so that multipart names would need to be
concatenated into a single name.

The second is where another language is not HA and code written in it
needs to refer to a symbol in one in which names /can/ be hierarchical.
References in the converse direction, from an HA language to one which
is not HA, would not be a problem.

So AISI if a language and its toolchain are HA then programs written in
that language would have full access to symbols exported from other
modules whatever language those modules were written in.

For example, if there's an assembly module called fred which exports a
name joe then a language which supported hierarchical namespaces could,
perhaps, refer to that symbol as

fred.joe

AISI all languages and build tools should be able to work with multipart
names. But I suspect that few are!

--
James Harris

On 17/11/2021 17:16, James Harris wrote:
> On 17/11/2021 10:51, David Brown wrote:
>> On 17/11/2021 10:43, James Harris wrote:
>>> On 16/11/2021 16:11, David Brown wrote:
>
> ...
>
>>>> The cost is that the identifiers (functions and objects) no longer
>>>> match
>>>> the source code name and the assembly level name - you need some
>>>> kind of
>>>> mangling (it could be as simple as $timers$init, if you don't need
>>>> mangling for overloads or other purposes).
>>>
>>> Interesting point. Can you give an example?
>
> ...
>
>> If you know your assembler/linker support characters that are not
>> allowed in the source language - such as $ - then you can probably make
>> a neater and more compact name-mangling scheme.
>
> Where would such namespace mangling be needed? AFAICS only in two cases.
>
> The first is where tools (compiler, linker, debugger, and so on) were
> not hierarchy-aware (HA) so that multipart names would need to be
> concatenated into a single name.
>
> The second is where another language is not HA and code written in it
> needs to refer to a symbol in one in which names /can/ be hierarchical.
> References in the converse direction, from an HA language to one which
> is not HA, would not be a problem.
>
> So AISI if a language and its toolchain are HA then programs written in
> that language would have full access to symbols exported from other
> modules whatever language those modules were written in.
>
> For example, if there's an assembly module called fred which exports a
> name joe then a language which supported hierarchical namespaces could,
> perhaps, refer to that symbol as
>
>   fred.joe
>
> AISI all languages and build tools should be able to work with multipart
> names. But I suspect that few are!
>

All of what you write here sounds perfectly reasonable - but that last
part is a big issue. You typically have to interact with other tools in
a system - writing /everything/ yourself is not practical. So at some
point you have to switch to "flat" names - and if you still need to
encode hierarchical information there, you need some kind of mangling.

One way to make this easier is to have a "foreign function interface",
or some way of declaring non-mangled names. In C++, you can use extern
"C" to declare that a symbol should be in "plain C" format. It is then
considered as outside any namespaces in regard to the name, has no
mangling, etc. That also means it cannot support overloading. But it
is useful for linking (in either direction) against object code modules
made by other tools.

Some languages - like C++ and Ada - support function overloading. In
that case, you cannot have a simple HA identifier scheme such as you
proposed as the mangled names also have to encode the parameter types.
You could have a more advanced method and keep it within tools
specifically written to handle them.

But the point of using name mangling schemes here is that your ordinary
assembler, linker, debugger, etc., can work as though it were HA by
simply encoding the hierarchy within mangled symbol names. Now all you
need from these tools is that they can work with long symbol names (as
they can get very long) - everything else stays exactly the same.
Although name mangling may seem like a hack and a workaround at first,
it is in fact quite a convenient and elegant solution.

(Think of it a little like using Base64 encoding to be able to send
binary files via text-only email. It may look a mess when you try to
read it, but it simply and conveniently solves the problem without
needing to re-do the entire email system.)

On 2021-11-17 20:32, David Brown wrote:

> Some languages - like C++ and Ada - support function overloading. In
> that case, you cannot have a simple HA identifier scheme such as you
> proposed as the mangled names also have to encode the parameter types.

There are also non-functions like constructors/destructors and utility
subprograms created by the compiler, e.g. instances of generic/template
bodies. GCC generates a huge number of such stuff when creating a
dynamic library.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On Tuesday, November 16, 2021 at 10:11:30 AM UTC-6, David Brown wrote:
[the thing that was requested]

Well, dang that does seem mighty useful. Of my various language projects
the only one where I'm truly designing it (albeit backburnered) is `olmec`,
my APL variant. But I may (or may not) have a problem with incorporating
namespaces.

For starters, it's APL. Arrays, Characters (21bit unicode), Integers, Multiprecision
Floating Point, infix functions and operators (or verbs and adverbs). But here's
the weird part:

Any contiguous string of non-numeric, non-whitespace, non-bracket characters
is an <identifier-string> which then gets peeled apart by scanning left-to-right
for the longest defined prefix.

This enable extremely stupid golfing tricks, like making the letter 'b' be the
addition function and then the expression 'abc' becomes an addition if
'a' and 'c' are suitably defined.

So I kind of have long identifiers and "free" scope-resolution operators.
You can just pick any crazy character you like to be a separator and define
a long name of whatever symbols.

The piece I'm missing then, is a "using" directive. I suppose this would be
scoped to whole functions, because I don't really have any kind of <statement>
syntax. It's just <expression><expression><expression>...<End-of-function>.
Returns are either by Fortran-style copy from a named variable or the value
of the last expression if you didn't a specify a return variable.

I don't even have "if(){}". So far, you have to build it out of lambdas if you want
to do that. Maybe that should be on the high priority list, too.

On Saturday, November 20, 2021 at 9:19:14 PM UTC-6, luserdroog wrote:
> On Tuesday, November 16, 2021 at 10:11:30 AM UTC-6, David Brown wrote:
> [the thing that was requested]
>
> Well, dang that does seem mighty useful. Of my various language projects
> the only one where I'm truly designing it (albeit backburnered) is `olmec`,
> my APL variant. But I may (or may not) have a problem with incorporating
> namespaces.
>
> For starters, it's APL. Arrays, Characters (21bit unicode), Integers, Multiprecision
> Floating Point, infix functions and operators (or verbs and adverbs). But here's
> the weird part:
>
> Any contiguous string of non-numeric, non-whitespace, non-bracket characters
> is an <identifier-string> which then gets peeled apart by scanning left-to-right
> for the longest defined prefix.
>
> This enable extremely stupid golfing tricks, like making the letter 'b' be the
> addition function and then the expression 'abc' becomes an addition if
> 'a' and 'c' are suitably defined.
>
> So I kind of have long identifiers and "free" scope-resolution operators.
> You can just pick any crazy character you like to be a separator and define
> a long name of whatever symbols.
>
> The piece I'm missing then, is a "using" directive. I suppose this would be
> scoped to whole functions, because I don't really have any kind of <statement>
> syntax. It's just <expression><expression><expression>...<End-of-function>.
> Returns are either by Fortran-style copy from a named variable or the value
> of the last expression if you didn't a specify a return variable.
>
> I don't even have "if(){}". So far, you have to build it out of lambdas if you want
> to do that. Maybe that should be on the high priority list, too.

I take that back. Maybe I do have something like an "if". But it's weird.
I seem to recall implementing the syntax from Ken Iverson's "tool of thought"
Turing award paper. which is like

(true expression):(condition):(false expression)

with 2 embedded colons separating the parts. I forgot about that part.
I suppose it doesn't affect namespacing except that colons are taken.
So I can't use colons.

On Saturday, November 20, 2021 at 9:19:14 PM UTC-6, luserdroog wrote:
> On Tuesday, November 16, 2021 at 10:11:30 AM UTC-6, David Brown wrote:
> [the thing that was requested]
[snip]
> The piece I'm missing then, is a "using" directive. I suppose this would be
> scoped to whole functions, because I don't really have any kind of <statement>
> syntax. It's just <expression><expression><expression>...<End-of-function>.
> Returns are either by Fortran-style copy from a named variable or the value
> of the last expression if you didn't a specify a return variable.
[snip]

Into the meat of the situation...

There are 2 basic ways to define a function, short or long. The long way has
a bunch of variations.

For the short way, I don't think "using" directive are practical. It's supposed
to be for one-liners. I guess I can have an expression separator like semicolon
maybe (old APL literature seems to like <diamond>), but not urgent.

The long way is IBM APL style DEL definitions. You start a line with DEL
(the downward pointing big triangle) and then a preamble or prototype
on the rest of the line and hit enter. BTW you're typing all this into the
interactive editor bc I insist on handling all the unicode internally and maybe
throwing in extra characters from the VT220 graphics sets.

Then you're in a separate mode, entering lines (expressions) for the function
to execute sequentially. The del-function-definition mode ends when you
give it a single DEL by itself on a line.

So the question is, stuff it (the "using" directive) into the preamble, which
already specifies

(<optional return variable><left arrow>)(optional left arg)(function)(optional right arg);(optional local variables)

Or make it a "statement" or special expression, a directive.

I don't know. Maybe I haven't given enough information for help, but that's
what I got.

On Saturday, November 20, 2021 at 9:19:14 PM UTC-6, luserdroog wrote:
> On Tuesday, November 16, 2021 at 10:11:30 AM UTC-6, David Brown wrote:
> [the thing that was requested]
>
> Well, dang that does seem mighty useful. Of my various language projects
> the only one where I'm truly designing it (albeit backburnered) is `olmec`,
> my APL variant. But I may (or may not) have a problem with incorporating
> namespaces.
>
> For starters, it's APL. Arrays, Characters (21bit unicode), Integers, Multiprecision
> Floating Point, infix functions and operators (or verbs and adverbs).

Oh yeah, and there's a Unicode symbol table type. And a dynamic chain of these
attached to functions to provide variable scoping. I have somewhat "canonical"
versions of the implementation of each of these datatypes posted at
codereview.stackexchange.com. I'm pretty proud of the multidimentional array
stuff, but still humbled by the critique. I still make a lot of those same mistakes.

> But here's
> the weird part:
>
> Any contiguous string of non-numeric, non-whitespace, non-bracket characters
> is an <identifier-string> which then gets peeled apart by scanning left-to-right
> for the longest defined prefix.
>

Unless you're inside of a (long form) function definition, then you're typing
expressions at the console to be evaluated. So there's just a single global
symbol table holding all the definitions you can use directly at the prompt.

> This enables extremely stupid golfing tricks, like making the letter 'b' be the
> addition function and then the expression 'abc' becomes an addition if
> 'a' and 'c' are suitably defined.
>
> So I kind of have long identifiers and "free" scope-resolution operators.
> You can just pick any crazy character you like to be a separator and define
> a long name of whatever symbols.
>
> The piece I'm missing then, is a "using" directive. I suppose this would be
> scoped to whole functions, because I don't really have any kind of <statement>
> syntax. It's just <expression><expression><expression>...<End-of-function>.
> Returns are either by Fortran-style copy from a named variable or the value
> of the last expression if you didn't a specify a return variable.
>
> I don't even have "if(){}". So far, you have to build it out of lambdas if you want
> to do that. Maybe that should be on the high priority list, too.

On Saturday, November 20, 2021 at 9:48:06 PM UTC-6, luserdroog wrote:

> The long way is IBM APL style DEL definitions. You start a line with DEL
> (the downward pointing big triangle) and then a preamble or prototype
> on the rest of the line and hit enter. BTW you're typing all this into the
> interactive editor bc I insist on handling all the unicode internally and maybe
> throwing in extra characters from the VT220 graphics sets.
>
> Then you're in a separate mode, entering lines (expressions) for the function
> to execute sequentially. The del-function-definition mode ends when you
> give it a single DEL by itself on a line.
>
> So the question is, stuff it (the "using" directive) into the preamble, which
> already specifies
>
> (<optional return variable><left arrow>)(optional left arg)(function)(optional right arg);(optional local variables)

Incidentally this bit of weirdness still seems pretty awesome to me,
but I'm not entirely sure how practical it actually is. You can specify
a "niladic" function that takes no arguments. But then you have to
have a very close understanding of the execution behavior of
expressions to know exactly where in there the thing will get called.

It also lets you define monadic or dyadic (ie. unary or binary) functions
by filling in the right (+left) arguments, of course. But you also
can define "sinister" verbs. These have a left argument but no right argument.
So you can make a dang=ol' factorial n! that fercrissakes looks like
for real-ass factorial notation. It screws up the whole strict right-to-left
deal that APL does, but it's awesome that's why. It's weird and that's the
dilly-o.

> Or make it a "statement" or special expression, a directive.
>
> I don't know. Maybe I haven't given enough information for help, but that's
> what I got.

On 17/11/2021 10:40, Dmitry A. Kazakov wrote:
> On 2021-11-17 10:43, James Harris wrote:
>> On 16/11/2021 16:11, David Brown wrote:
>
>>> namespace timers {
>>>     void init();
>>>     void enable();
>>>     int get_current();
>>>     void set_frequency(double);
>>> }
>>>
>>> You can use them as "timers::init();" or by pulling them into the
>>> current scope with "using timers; enable();".
>>
>> As this is about namespaces, I'd suggest some problems with that
>> "using timers" example:
>>
>> * AIUI it mixes the names from within 'timers' into the current
>> namespace. If that's right then a programmer taking such an approach
>> would have to avoid having his own versions of those names. (I.e. no
>> 'enable' or 'init' names in the local scope.)
>>
>> * If multiple namespaces are imported in the same way then there's
>> another potential for name conflicts. It's especially bad for names
>> imported from external files.
>
> You mean making simple names inside the namespace directly visible in
> the scope? Because there are two kind of imports:
>
> 1. Making the namespace visible without direct visibility of its names.
> So you must qualify the simple name Foo from My_Namespace:
>
>    My_Namespace.Foo
>  [ My_Namespace::Foo in C++ ]
>
> 2. Making simple names directly visible. So you can omit all parents:
>
>    Foo

Yes, as you surmise below, it's option 2 which I am saying is a bad idea.

>
>> * There could be a stable situation with no name conflicts, but then
>> an upgrade to an imported module which is not directly under the
>> programmer's control could introduce a new name which /does/ conflict.
>
> You are talking about #2. There are two approaches to that:
>
> 2.1. Allow direct visiblity so long there is no conflicts inside the
> scope. E.g. let both Namespace_1 and Namespace_2 have Foo, but the code
> does not refer to Foo, then is OK.
>
> 2.2. Disallow it even if there is no conflicts inside the scope. This
> would prevent surprises so long the namespaces are stable. Of course a
> modification of a namespace can break an existing program. However this
> is not a problem from the SW development POV, because you must review
> the client code anyway if you change any namespace it uses.

I would prohibit option 2 (making imported names directly visible)
altogether (although I would allow names to be searched for in different
scopes - but that's getting in to another topic).

If the language allows hierarchical names and aliases as in

namedef T = long.complex.path.timers

where T becomes an alias of the name on the RHS then a programmer could
refer to any name A within timers as

T.A

That's no hardship. Further, the name T would defined locally so would
not have any surprising conflicts.

For full disclosure (!) I would like to go slightly further and allow
imported names to follow a prefix - i.e. without the dot. For example,
say the syntax allowed something like

namedef P* = long.complex.path.timers.*

where P became a prefix to all the names in timers. Then timers.enable
could be invoked as

Penable()

In a sense, P would replace "timers." including the dot.

In such a case, no identifiers in the local scope would be able to begin
with P.

That latter approach (allowing a prefix without the dot) is far from
necessary. It's a convenience to the programmer. But AISI there are
cases where code which has a dot before every imported name would be
annoying to work with. So I think it's worth including.

>
>> Therefore namespace support needs to be more extensive and more
>> restrictive, IMO. For example,
>>
>>    namespace T = lib.org.timers
>>
>> then
>>
>>    T.enable()
>>
>> In that, T would be a name in the local scope that the programmer
>> could control and ensure it doesn't conflict with any other names. The
>> import could be
>>
>>    namespace timers = lib.org.timers
>>
>> Then the name 'timers' would be local. The programmer would still be
>> /required/ to specify the namespace name as in
>>
>>    timers.enable()
>
> These are "fully qualified names," i.e. #1. Note that T and Timers are
> simple names and may still conflict with some other T's and Timers'. You
> have further choices:
>
> A. You allow overloading of Timers. Let only one of Timers has Enable:
>
>    Timers.Enable
>
> This is OK, if another Timers has no Enable

Overloading is a big topic but I think there would have to be only one
name such as Timers in each scope. Remember that such a name would be
local to the source file that the programmer is editing. Just as a C
programmer should not declare

int i, i;

it ought to be wrong to declare Timers twice in the same scope.

>
> B. You do not allow it regardless.
>
> Ada has both #1 and #2. It uses #2.1(A). The predefined package Standard
> is the root namespace. So, qualified names may use it to disambiguate,
> e.g. like
>
>    Standard.Timers.Enable
>
> You can mix #1 and #2. I.e. if a fully qualified name is Standard.A.B.C,
> then A.B.C is OK because Standard is directly visible #2. If you make
> Standard.A directly visible, then B.C would be also OK. If you make
> Standard.A.B directly visible, then you could use just C.

Exactly.

--
James Harris

On 2021-11-21 11:11, James Harris wrote:

> I would prohibit option 2 (making imported names directly visible)
> altogether (although I would allow names to be searched for in different
> scopes - but that's getting in to another topic).

You cannot, otherwise you will have to name all local scopes:

void Foo ()
{
int X;

X := 1; // Illegal!
}

Should be

void Foo ()
{
Local : {
int X;

Root.Foo.Local.X := 1; // OK
}
}

Having different sets of rules for naming is an awful idea.

A related issue is hiding:

{
int X;
{
int X; // Hides directly visible X

X := 1; // The nested X
}
}

Children hide, siblings conflict? (:-))

> If the language allows hierarchical names and aliases as in
>
>   namedef T = long.complex.path.timers
>
> where T becomes an alias of the name on the RHS then a programmer could
> refer to any name A within timers as
>
>   T.A

Which is worse than the original problem. Renaming is a dangerous thing
and you are asking for overusing it because otherwise the code would be
unreadable with extremely long names.

> That's no hardship. Further, the name T would defined locally so would
> not have any surprising conflicts.

It is. Basically instead of resolving the issue you burden the
programmer with renaming and invoke havoc in maintenance because who
would manage and document all these renamings, if not the language?

A problem related to visibility and renaming is transitivity of using.

Consider B that uses or renames things in A. If C uses B will it see the
uses and renamings of B?

In Ada it will see no uses but all remanings. Before you say it is good,
it is not straightforward, because there is no way to maintain derived
namespaces like B. If B uses a lot of other namespaces there is no
simple way to shape the effect using B will have in C. Again, renaming
is not a solution in the real-world projects.

> For full disclosure (!) I would like to go slightly further and allow
> imported names to follow a prefix - i.e. without the dot. For example,
> say the syntax allowed something like
>
>   namedef P* = long.complex.path.timers.*
>
> where P became a prefix to all the names in timers. Then timers.enable
> could be invoked as
>
>   Penable()
>
> In a sense, P would replace "timers." including the dot.

Abhorrent.

> Overloading is a big topic but I think there would have to be only one
> name such as Timers in each scope. Remember that such a name would be
> local to the source file that the programmer is editing. Just as a C
> programmer should not declare
>
>   int i, i;
>
> it ought to be wrong to declare Timers twice in the same scope.

Except that you cannot control it unless you rename each and every
entity of each namespace manually.

The problem is with means supporting manipulation of namespaces as a
*whole*, like using does. These impose problems. Individual renamings is
not a solution, it makes things much worse.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 21/11/2021 11:05, Dmitry A. Kazakov wrote:
> On 2021-11-21 11:11, James Harris wrote:
>
>> I would prohibit option 2 (making imported names directly visible)
>> altogether (although I would allow names to be searched for in
>> different scopes - but that's getting in to another topic).

Throughout your post you seem to be talking about something other than
what I proposed. I cannot work out what model you have in mind but I'll
reply as best I can.

>
> You cannot, otherwise you will have to name all local scopes:
>
>    void Foo ()
>    {
>       int X;
>
>       X := 1; // Illegal!
>    }

I didn't suggest that. In your example your reference to X would use the
X declared above it.

....

>> If the language allows hierarchical names and aliases as in
>>
>>    namedef T = long.complex.path.timers
>>
>> where T becomes an alias of the name on the RHS then a programmer
>> could refer to any name A within timers as
>>
>>    T.A
>
> Which is worse than the original problem. Renaming is a dangerous thing
> and you are asking for overusing it because otherwise the code would be
> unreadable with extremely long names.

The name was long to illustrate a point.

>
>> That's no hardship. Further, the name T would defined locally so would
>> not have any surprising conflicts.
>
> It is. Basically instead of resolving the issue you burden the
> programmer with renaming and invoke havoc in maintenance because who
> would manage and document all these renamings, if not the language?

There's no renaming. If you mean aliasing then that depends on the
details of the scheme. Consider

int Outer;
void F(void)
{
int Inner;
X
}

Under 'nominal' schemes that we are all familiar with, at point X the
names Inner and Outer would be visible. If we stick to that and add an
alias such as

int Outer;
alias External = A.B.C.D.E; <=== line added to the prior example
void F(void)
{
int Inner;
X
}

Are you saying that at point X name External should not be visible? If
so, why should it not?

>
> A problem related to visibility and renaming is transitivity of using.
>
> Consider B that uses or renames things in A. If C uses B will it see the
> uses and renamings of B?

Let me check what you mean. Say we were to have

module A
public name A1
endmodule

module B
public alias B1 = A.A1
endmodule

Are you saying that another module, C, should not refer to the B.B1 name?

>
> In Ada it will see no uses but all remanings. Before you say it is good,
> it is not straightforward, because there is no way to maintain derived
> namespaces like B. If B uses a lot of other namespaces there is no
> simple way to shape the effect using B will have in C. Again, renaming
> is not a solution in the real-world projects.

Say module B presents a certain interface. Why should it not collect
together and present names from other modules?

>
>> For full disclosure (!) I would like to go slightly further and allow
>> imported names to follow a prefix - i.e. without the dot. For example,
>> say the syntax allowed something like
>>
>>    namedef P* = long.complex.path.timers.*
>>
>> where P became a prefix to all the names in timers. Then timers.enable
>> could be invoked as
>>
>>    Penable()
>>
>> In a sense, P would replace "timers." including the dot.
>
> Abhorrent.

:-) Do you have a semantic objection to it or is it purely that you
don't think a programmer should be offered such a facility - perhaps
because you think it's too close to having names require the dot?

Consider a case where lots of names are imported. For example, say an
external module had the tens or hundreds of mnemonics for an assembly
language. In the context of this discussion one could consider that
there are three choices:

1. Import all mnemonics into the current scope - which would cause the
problems mentioned in my prior post.

2. Give them all a common name as with the x in

x.add
x.and
x.call
etc

3. Use a prefix as in the x in

xadd
xand
xcall

For sure, you could say that the latter is not necessary. But try
reading aloud a lot of code which contains loads of dotted names and you
might come to see the suggestion differently.

I am interested in your opinion but I cannot see why you would object to
that. It would be clear and manifest in the importing module that the
prefix x or the alias x had been defined.

>
>> Overloading is a big topic but I think there would have to be only one
>> name such as Timers in each scope. Remember that such a name would be
>> local to the source file that the programmer is editing. Just as a C
>> programmer should not declare
>>
>>    int i, i;
>>
>> it ought to be wrong to declare Timers twice in the same scope.
>
> Except that you cannot control it unless you rename each and every
> entity of each namespace manually.

It's typically only external namespaces which would have to be given an
alias. Within a single module normal scope resolution could apply -
although I may take a different approach which I'll not go in to just
now as it would muddy the waters.

>
> The problem is with means supporting manipulation of namespaces as a
> *whole*, like using does. These impose problems. Individual renamings is
> not a solution, it makes things much worse.
>

To be clear, what would normally be aliased would be entire namespaces,
not individual symbols (although they could be aliased if required).

--
James Harris

On 17/11/2021 19:32, David Brown wrote:
> On 17/11/2021 17:16, James Harris wrote:

....

>> For example, if there's an assembly module called fred which exports a
>> name joe then a language which supported hierarchical namespaces could,
>> perhaps, refer to that symbol as
>>
>>   fred.joe
>>
>> AISI all languages and build tools should be able to work with multipart
>> names. But I suspect that few are!
>>
>
> All of what you write here sounds perfectly reasonable - but that last
> part is a big issue. You typically have to interact with other tools in
> a system - writing /everything/ yourself is not practical. So at some
> point you have to switch to "flat" names - and if you still need to
> encode hierarchical information there, you need some kind of mangling.

Agreed, although I'd add that once the tools are available they should
be able to work with any number of languages - as long as they agree on
the file and name formats.

--
James Harris

On 2021-11-21 14:55, James Harris wrote:
> On 21/11/2021 11:05, Dmitry A. Kazakov wrote:
>> On 2021-11-21 11:11, James Harris wrote:
>>
>>> I would prohibit option 2 (making imported names directly visible)
>>> altogether (although I would allow names to be searched for in
>>> different scopes - but that's getting in to another topic).
>
> Throughout your post you seem to be talking about something other than
> what I proposed. I cannot work out what model you have in mind but I'll
> reply as best I can.
>
>>
>> You cannot, otherwise you will have to name all local scopes:
>>
>>     void Foo ()
>>     {
>>        int X;
>>
>>        X := 1; // Illegal!
>>     }
>
> I didn't suggest that. In your example your reference to X would use the
> X declared above it.

You said no directly visible names. Now you have directly visible X,
instead of Foo.X.

>> Which is worse than the original problem. Renaming is a dangerous
>> thing and you are asking for overusing it because otherwise the code
>> would be unreadable with extremely long names.
>
> The name was long to illustrate a point.

Most names are, because of deep nesting.

>>> That's no hardship. Further, the name T would defined locally so
>>> would not have any surprising conflicts.
>>
>> It is. Basically instead of resolving the issue you burden the
>> programmer with renaming and invoke havoc in maintenance because who
>> would manage and document all these renamings, if not the language?
>
> There's no renaming.

OK, call it alias name, if you do not like the term "renaming."

> If you mean aliasing then that depends on the
> details of the scheme. Consider
>
>   int Outer;
>   void F(void)
>   {
>     int Inner;
>     X
>   }
>
> Under 'nominal' schemes that we are all familiar with, at point X the
> names Inner and Outer would be visible.

Why different rules for nesting?

> If we stick to that and add an
> alias such as
>
>   int Outer;
>   alias External = A.B.C.D.E;  <=== line added to the prior example
>   void F(void)
>   {
>     int Inner;
>     X
>   }
>
> Are you saying that at point X name External should not be visible? If
> so, why should it not?

Not only it. Outer and Inner must not be visible either. Inner is not a
proper name. They actually are:

Root.Outer
Root.External
Root.F.Inner

Again, provided you hold to your proposal not to allow direct
visibility. Otherwise, you have a problem of irregularity of the rules.

Since Ada has such rules, I can tell you that this is quite annoying and
the source of a rift between people favoring fully qualified names vs
ones who prefer the direct names. Note that the choice directly
influences the design, since you must name things differently if you are
a true Lilliputian vs a treacherous Blefuscudian... (:-))

Anyway, the point is that direct visibility exist for a reason. That
reason is valid for both nested and imported scopes.

>> A problem related to visibility and renaming is transitivity of using.
>>
>> Consider B that uses or renames things in A. If C uses B will it see
>> the uses and renamings of B?
>
> Let me check what you mean. Say we were to have
>
>   module A
>     public name A1
>   endmodule
>
>   module B
>     public alias B1 = A.A1
>   endmodule
>
> Are you saying that another module, C, should not refer to the B.B1 name?

No. I am saying this:

module A
public name A1
endmodule

module B
use A
-- A1 is directly visible here?
endmodule

module C
use B
-- Is A1 directly visible here?
endmodule

>> In Ada it will see no uses but all remanings. Before you say it is
>> good, it is not straightforward, because there is no way to maintain
>> derived namespaces like B. If B uses a lot of other namespaces there
>> is no simple way to shape the effect using B will have in C. Again,
>> renaming is not a solution in the real-world projects.
>
> Say module B presents a certain interface. Why should it not collect
> together and present names from other modules?

Because "use" is non-transitive in Ada. [You want to prohibit "use"
altogether.]

Arguably one could have

1. non-transitive alias/rename (stays inside the module)

2. transitive alias/rename (propagates upon use)

3. non-transitive use

A non-transitive use creates a non-transitive alias for each name of the
module *except* the non-transitive aliases.

4. transitive use

A transitive use creates a transitive alias for *each* name of the module

>>> For full disclosure (!) I would like to go slightly further and allow
>>> imported names to follow a prefix - i.e. without the dot. For
>>> example, say the syntax allowed something like
>>>
>>>    namedef P* = long.complex.path.timers.*
>>>
>>> where P became a prefix to all the names in timers. Then
>>> timers.enable could be invoked as
>>>
>>>    Penable()
>>>
>>> In a sense, P would replace "timers." including the dot.
>>
>> Abhorrent.
>
> :-) Do you have a semantic objection to it or is it purely that you
> don't think a programmer should be offered such a facility - perhaps
> because you think it's too close to having names require the dot?

No. One could err on ethics, but not on aesthetics. (:-)) It is abhorrent!

> Consider a case where lots of names are imported. For example, say an
> external module had the tens or hundreds of mnemonics for an assembly
> language. In the context of this discussion one could consider that
> there are three choices:
>
> 1. Import all mnemonics into the current scope - which would cause the
> problems mentioned in my prior post.
>
> 2. Give them all a common name as with the x in
>
>   x.add
>   x.and
>   x.call
>   etc
>
> 3. Use a prefix as in the x in
>
>   xadd
>   xand
>   xcall

.... and have all alleged problems.

The proper solution is for the language to provide means to maintain
namespaces at the *module* side. The designer of the module chooses the
way mnemonics to be used in the client code. Note, not otherwise. The
client code may only apply some emergency exceptional rules to resolve
problems, but there should be none with *properly designed* modules.

>> Except that you cannot control it unless you rename each and every
>> entity of each namespace manually.
>
> It's typically only external namespaces which would have to be given an
> alias. Within a single module normal scope resolution could apply -
> although I may take a different approach which I'll not go in to just
> now as it would muddy the waters.

The ratio between external namespaces and the nested namespaces is kind
of 1000 to 1. You are barking on the wrong tree.

>> The problem is with means supporting manipulation of namespaces as a
>> *whole*, like using does. These impose problems. Individual renamings
>> is not a solution, it makes things much worse.
>
> To be clear, what would normally be aliased would be entire namespaces,
> not individual symbols (although they could be aliased if required).

That changes little as namespaces (modules, classes etc) are deeply
nested themselves. If you think that the problem is "the last mile," you
are wrong.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

luserdroog <mijoryx@yahoo.com> writes:
> What's the big deal about namespaces

They are like drawers that help maintain order and clarity.
They help to avoid name clashes and to organize code and
its documentation.

If a programming language does not support namespaces but
does support long names, it might be possible to emulate
namespaces somewhat using prefixes for names.

Technically, a namespace is a function that maps a name
to something (an object, a function, a module, something
else, or even another namespace).

When more features than just mere name resolution are
added to a namespace, it may become a module or an object.
So, many software entities can be described as enhanced
namespaces.

If there would be a world without namespaces, modules,
or objects, the moment someone would start to use a common
prefix for related names, the course would be set on all
those things, eventually including run-time polymorphism.

On 21/11/2021 15:06, Dmitry A. Kazakov wrote:
> On 2021-11-21 14:55, James Harris wrote:
>> On 21/11/2021 11:05, Dmitry A. Kazakov wrote:
>>> On 2021-11-21 11:11, James Harris wrote:
>>>
>>>> I would prohibit option 2 (making imported names directly visible)
>>>> altogether (although I would allow names to be searched for in
>>>> different scopes - but that's getting in to another topic).
>>
>> Throughout your post you seem to be talking about something other than
>> what I proposed. I cannot work out what model you have in mind but
>> I'll reply as best I can.
>>
>>>
>>> You cannot, otherwise you will have to name all local scopes:
>>>
>>>     void Foo ()
>>>     {
>>>        int X;
>>>
>>>        X := 1; // Illegal!
>>>     }
>>
>> I didn't suggest that. In your example your reference to X would use
>> the X declared above it.
>
> You said no directly visible names. Now you have directly visible X,
> instead of Foo.X.

I was talking about /imported/ names. I said I would prohibit "making
*imported* names directly visible". It's in the text, above!

Consider

namespace Bases
int Oct = 8
int Dec = 10
int Hex = 16
namespace-end

enum WinterMonths(Nov. Dec, Jan)

Although the name Dec appears twice the two could never conflict because
they would /always/ require qualification. For example,

Bases.Dec
Months.Dec

If they were in external modules they could be imported as in

alias B = external_1.Bases
alias M = external_2.Months

then the names would be B.Dec and M.Dec. IOW the two could still not
conflict.

Note that if a programmer wrote

alias Dec = Bases.Dec
alias Dec = Months.Dec

then there would be a conflict but it would be clear in the client code.

....

>>    int Outer;
>>    void F(void)
>>    {
>>      int Inner;
>>      X
>>    }
>>
>> Under 'nominal' schemes that we are all familiar with, at point X the
>> names Inner and Outer would be visible.
>
> Why different rules for nesting?

I am not suggesting different rules. See the next comment, below.

>
>> If we stick to that and add an alias such as
>>
>>    int Outer;
>>    alias External = A.B.C.D.E;  <=== line added to the prior example
>>    void F(void)
>>    {
>>      int Inner;
>>      X
>>    }
>>
>> Are you saying that at point X name External should not be visible? If
>> so, why should it not?
>
> Not only it. Outer and Inner must not be visible either. Inner is not a
> proper name. They actually are:
>
>    Root.Outer
>    Root.External
>    Root.F.Inner
>
> Again, provided you hold to your proposal not to allow direct
> visibility. Otherwise, you have a problem of irregularity of the rules.

As above, that wasn't what I proposed. In the example, at point X the
following would all be accessible

Inner
Outer
External

In fact, with normal scope resolution they wouldn't just be accessible
but would all be accessible /as plain names/.

Feasibly, one could decide to make Inner directly accessible but not the
other two, although that's probably a separate discussion. Either way,
the key point is that External and Outer would be treated in the same
way. Both names appear in the file outside a function and both would be
at file scope.

>
> Since Ada has such rules, I can tell you that this is quite annoying and
> the source of a rift between people favoring fully qualified names vs
> ones who prefer the direct names. Note that the choice directly
> influences the design, since you must name things differently if you are
> a true Lilliputian vs a treacherous Blefuscudian... (:-))

For Blefuscudian my newsreader's spell checker suggests "Undiscussable"!
:-)

>
> Anyway, the point is that direct visibility exist for a reason. That
> reason is valid for both nested and imported scopes.

Sure. As above, if Outer is directly visible then External would be too.

And in case it's not clear, External would allow access to any names
within it. For example,

alias External = A.B.C.D.E;
void F(void)
{
int inner = External.baseval;
}

where baseval is a name within E.

....

> No. I am saying this:
>
>    module A
>      public name A1
>    endmodule
>
>    module B
>      use A
>              -- A1 is directly visible here?
>    endmodule
>
>    module C
>      use B
>              -- Is A1 directly visible here?
>    endmodule

OK. I wouldn't allow the "use" statements so the issue would not apply.

>
>>> In Ada it will see no uses but all remanings. Before you say it is
>>> good, it is not straightforward, because there is no way to maintain
>>> derived namespaces like B. If B uses a lot of other namespaces there
>>> is no simple way to shape the effect using B will have in C. Again,
>>> renaming is not a solution in the real-world projects.
>>
>> Say module B presents a certain interface. Why should it not collect
>> together and present names from other modules?
>
> Because "use" is non-transitive in Ada. [You want to prohibit "use"
> altogether.]

Yes.

....

>> Consider a case where lots of names are imported. For example, say an
>> external module had the tens or hundreds of mnemonics for an assembly
>> language. In the context of this discussion one could consider that
>> there are three choices:
>>
>> 1. Import all mnemonics into the current scope - which would cause the
>> problems mentioned in my prior post.
>>
>> 2. Give them all a common name as with the x in
>>
>>    x.add
>>    x.and
>>    x.call
>>    etc
>>
>> 3. Use a prefix as in the x in
>>
>>    xadd
>>    xand
>>    xcall
>
> ... and have all alleged problems.
>
> The proper solution is for the language to provide means to maintain
> namespaces at the *module* side. The designer of the module chooses the
> way mnemonics to be used in the client code. Note, not otherwise.

I accept that that is your view but I cannot agree with it. AISI it's
important for the client to remain in control. That is so that such
choices would be visible to any programmer reading the code.

If, by contrast, such choices were made in the module providing the
service then the propagation of names would be invisible to the client
code.

> The
> client code may only apply some emergency exceptional rules to resolve
> problems, but there should be none with *properly designed* modules.

--
James Harris

On 17/11/2021 14:01, Bart wrote:
> On 17/11/2021 09:43, James Harris wrote:
>> On 16/11/2021 16:11, David Brown wrote:
>>> On 16/11/2021 16:16, luserdroog wrote:
>>
>>>> I've been following with interest many of the threads started
>>>> by James Harris over the year and frequently the topic of
>>>> namespaces and modularity come up. Most recently in the
>>>> "Power operator and replacement..." thread.
>>>>
>>>> And I tend to find myself on James' side through unfamiliarity
>>>> with the other option. What's the big deal about namespaces
>>>> and modules? What do they cost and what do they facilitate?
>>
>> ...
>>
>>> namespace timers {
>>>     void init();
>>>     void enable();
>>>     int get_current();
>>>     void set_frequency(double);
>>> }
>>>
>>> You can use them as "timers::init();" or by pulling them into the
>>> current scope with "using timers; enable();".
>>
>> As this is about namespaces, I'd suggest some problems with that
>> "using timers" example:
>>
>> * AIUI it mixes the names from within 'timers' into the current
>> namespace. If that's right then a programmer taking such an approach
>> would have to avoid having his own versions of those names. (I.e. no
>> 'enable' or 'init' names in the local scope.)
>
> It depends on how you make it work. Languages already work with multiple
> instances of the same name within nested scopes; it will match the name
> in the nearest surrounding scope.

AISI there are two issues:
1. Definition. How to declare a name within a certain scope.
2. Searching. The order in which to search scopes for a name.

>
> With 'using', it could just introduce an extra scope beyond the ones
> that are already known.
>
> With two 'using's in two nested scopes, it gets a bit more involved:
>
>   {  using ns1;
>      { using ns2;
>          enable();
>
> If 'enable' exists in both ns1 and ns2, will there be a conflict, or
> will it use ns2?

That's the 'searching' issue: how to find a plain name. For me the jury
is still out on that. IME most languages search outwards one scope at a
time until they find a matching name. Is that the best approach? I don't
know.

Incidentally, consider

A.B

How would that find the relevant name? One option is for it to search
for the name A in scopes in some defined order and then require B to be
in the first A that it comes across.

Another option is to search for the first A in which there is a B.

ATM I prefer the first option - only the most-significant name would be
searched for - but I'm keeping it as an open question.

>
> I don't have a 'using' statement. My namespaces are only linked to
> module names. And all modules in a program (now, a subprogram) are
> visible at the same time. Then there can be a conflict:
>
>     import A          # both export 'enable'
>     import B
>
>     proc enable = {}
>
>     enable()
>
> This is OK; 'enable' is found within the normal set of scopes. But
> delete the proc definition, and then there is a conflict.

Good example. As you say below, if a programmer deletes the definition
of an inner name he may not notice that there's still a reference to it.
Then if the same name exists in an outer scope the compiler may not be
able to report a problem.

At the moment I don't know if I want to allow inner names to hide outer
ones. An alternative is to say that inner names must not be the same as
any name in an outer scope but that may not scale well.

Another option is to say that all names have to be unique within a
function or within a file.

A further option once a language supports hierarchical names is to treat
levels of the hierarchy like a file tree and say that names in inner
scopes can hide names in outer scopes but that there's still a way to
refer to a 'parent' scope much as one can refer to a parent directory -
something equivalent to

name - searches scopes in some predefined order
./name - the name must be in the current scope
../name - the name must be in the parent scope

>
>> * If multiple namespaces are imported in the same way then there's
>> another potential for name conflicts. It's especially bad for names
>> imported from external files.
>
> Yes, there's a conflict. The same as if you declared 'abc' then declared
> another 'abc' in the same scope. Or removed braces so that two 'abc's
> are now in the same block scope.
>
>> * There could be a stable situation with no name conflicts, but then
>> an upgrade to an imported module which is not directly under the
>> programmer's control could introduce a new name which /does/ conflict.
>
> There are all sorts of issues, but most of them already occur with
> nested scopes:
>
>     {
>         double abc;
>         {
>             int abc;
>             printf(fmt, abc);
>
> Here, the 'int abc;' could be deleted or commented out. Now 'abc'
> matches the other definition, with no detectable error.
>

The thing is, if all the names we are talking about are present in the
source file how burdensome would it be for a programmer to have to use
different names in inner scopes? I suspect it would not be too much of a
problem and it would solve a number of problems so it may be worth
considering.

--
James Harris

On 2021-11-21 17:43, James Harris wrote:

> And in case it's not clear, External would allow access to any names
> within it. For example,
>
>   alias External = A.B.C.D.E;
>   void F(void)
>   {
>     int inner = External.baseval;
>   }
>
> where baseval is a name within E.

Sure, unless it gets hidden due to name conflicts. As I said aliases
solve nothing. E.g. your example is valid in Ada and represents renaming
a package:

package External renames A.B.C.D.E;

It is used rarely and not for the purpose you are talking. The most
frequent use case is platform-dependent packages. E.g. you would have

package Real_Time_Extensions renames Win32.A.B.C.E;

and another compilation unit

package Real_Time_Extensions renames Linux.A.B.C.E.D;

All through the client code you refer on

with Real_Time_Extensions;

and swap files using the project target. Of course the public interfaces
must be same.

>> No. I am saying this:
>>
>>     module A
>>       public name A1
>>     endmodule
>>
>>     module B
>>       use A
>>               -- A1 is directly visible here?
>>     endmodule
>>
>>     module C
>>       use B
>>               -- Is A1 directly visible here?
>>     endmodule
>
> OK. I wouldn't allow the "use" statements so the issue would not apply.

Yes, you would alias all 1000+ functions and objects manually. "use" is
merely a tool to automate the process of creating aliases. If you ever
worked with C++ you would know how difficult to build a C++ DLL
exporting classes. This is basically same problem. There are modifiers
you can apply to a class to export everything required. Unfortunately in
produces a huge tail of errors. A newly designed language must address
such automation problems, if you do that afterwards.

>> The proper solution is for the language to provide means to maintain
>> namespaces at the *module* side. The designer of the module chooses
>> the way mnemonics to be used in the client code. Note, not otherwise.
>
> I accept that that is your view but I cannot agree with it. AISI it's
> important for the client to remain in control.

No, it is important to protect clients from stupid mistakes. Because
here you have a bug multiplier. Each client can introduce a bug to fix.
If the interface is stable and that includes which names the client may
use *by safe default*, you reduce that to a single fault point.

> If, by contrast, such choices were made in the module providing the
> service then the propagation of names would be invisible to the client
> code.

Yes, if the client should not see them, that would be the module
interface designer's choice.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 21/11/2021 17:25, Dmitry A. Kazakov wrote:
> On 2021-11-21 17:43, James Harris wrote:
>
>> And in case it's not clear, External would allow access to any names
>> within it. For example,
>>
>>    alias External = A.B.C.D.E;
>>    void F(void)
>>    {
>>      int inner = External.baseval;
>>    }
>>
>> where baseval is a name within E.
>
> Sure, unless it gets hidden due to name conflicts. As I said aliases
> solve nothing. E.g. your example is valid in Ada and represents renaming
> a package:
>
>    package External renames A.B.C.D.E;
>
> It is used rarely and not for the purpose you are talking. The most
> frequent use case is platform-dependent packages. E.g. you would have
>
>    package Real_Time_Extensions renames Win32.A.B.C.E;
>
> and another compilation unit
>
>    package Real_Time_Extensions renames Linux.A.B.C.E.D;
>
> All through the client code you refer on
>
>    with Real_Time_Extensions;
>
> and swap files using the project target. Of course the public interfaces
> must be same.

Yes, that's all good.

>
>>> No. I am saying this:
>>>
>>>     module A
>>>       public name A1
>>>     endmodule
>>>
>>>     module B
>>>       use A
>>>               -- A1 is directly visible here?
>>>     endmodule
>>>
>>>     module C
>>>       use B
>>>               -- Is A1 directly visible here?
>>>     endmodule
>>
>> OK. I wouldn't allow the "use" statements so the issue would not apply.
>
> Yes, you would alias all 1000+ functions and objects manually.

No need! The programmer would usually refer to the namespace (or an
alias thereof). For example, if there was a namespace ns1 which had many
names within it:

namespace ns1
name A
name B
name C
1000 other names
end namespace

and the programmer imported it with

alias ns1 = whereever.ns1

then the name "ns1" would be entered into the current scope and the
program could refer to names within that namespace with such as

ns1.A

but he would not be able to refer to plain

A

The only way to refer to A as a plain name would be to define an alias
for it as in

alias A = ns1.A

but then it would be manifest in the source code that the name A was
being added to the current scope. Yet that would be rare. With 1000+
names it would be easiest for the programmer to just refer to them as

ns1.name

where 'name' is one of the thousand.

IOW there would be no need to alias all 1000+ functions and objects.
Just alias the namespace within which they exist.

> "use" is
> merely a tool to automate the process of creating aliases. If you ever
> worked with C++ you would know how difficult to build a C++ DLL
> exporting classes. This is basically same problem. There are modifiers
> you can apply to a class to export everything required.

I don't know Windows but I think there's something similar in Python
where one can write

from my_module import *

IMO that's a bad feature. It imports all names in my_module into the
current scope. That has at least two problems:

1. The names can conflict with names the programmer enters into the
scope - along with all the attendant problems already mentioned.

2. When names are imported from two or more modules there's no way for a
programmer to be able to tell where a certain name is referring to. For
example,

from mod1 import *
from mod2 import *

print a_name

there's no way to tell whether a_name comes from mod1 or mod2. IMO the
"import *" facility pollutes the namespace which is the current scope.

> Unfortunately in
> produces a huge tail of errors. A newly designed language must address
> such automation problems, if you do that afterwards.

As I say, I don't know about DLLs but I wouldn't allow the "import *"
approach so maybe that would avoid the problem you have in mind.

>
>>> The proper solution is for the language to provide means to maintain
>>> namespaces at the *module* side. The designer of the module chooses
>>> the way mnemonics to be used in the client code. Note, not otherwise.
>>
>> I accept that that is your view but I cannot agree with it. AISI it's
>> important for the client to remain in control.
>
> No, it is important to protect clients from stupid mistakes. Because
> here you have a bug multiplier. Each client can introduce a bug to fix.
> If the interface is stable and that includes which names the client may
> use *by safe default*, you reduce that to a single fault point.

Maybe I am misunderstanding what you mean. Could you illustrate it with
a small example?

>
>> If, by contrast, such choices were made in the module providing the
>> service then the propagation of names would be invisible to the client
>> code.
>
> Yes, if the client should not see them, that would be the module
> interface designer's choice.

Under the scheme I have in mind names would still have protections such
as being private or public. Private names would not be visible to
another module.

--
James Harris