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

> 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

Like

A ns1.+ B

And since you have no direct visibility you have a problem with prefix
notation.

ns1.A.Print ()

Why Print is visible?

I do not want to explain further, I am not a language lawyer, but there
exit massive problems with your approach if you have generic and other
polymorphic bodies. In essence all methods must be visible in order to
prevent calling wrong a method, since you implicitly convert to the
parent if the overriding is not visible. Ada had such issues until 2005.

> 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.

You can use fully qualified name to disambiguate.

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

Consider a linear algebra modules. The client should be able to use all
modules without mental gymnastics. There is a type Matrix, and I can
multiply them, just out of the box.

> 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.

This is a totally unrelated issue.

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

On 21/11/2021 17:19, James Harris wrote:
> On 17/11/2021 14:01, Bart wrote:

>> 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.

That's an easy one. Just declare like any other.

> 2. Searching. The order in which to search scopes for a name.

I'm working on related matters right now. First I'm revising my module
schemes across two languages, which also affects how namespaces work.

But there was also the issue of finding a module or support file within
the file system. I had had a stack of possible search paths, but I've
dropped that in order to have more confidence in exactly what version of
a file will be found, and where.

So usually there is one choice, at most two.

Scopes within source code are similar. I don't have block scopes, so it
will be:

* In this function
* In this module
* In this subprogram
* In this program

Names can exist within namespaces created by, say, record (class)
definitions. Those can accessed from outside via a qualified name which
is found in one of the above.

(There is also the case of code inside such a class definition; I don't
do much on those lines, but it would add these, or replace the function
line above:

* In this record definition
* In the next outer if nested

but I stop there. I don't have enough experience of using those to have
a definitive way of doing it.)

On 21/11/2021 18:19, Dmitry A. Kazakov wrote:
> On 2021-11-21 18:57, James Harris wrote:
>
>> 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
>
> Like
>
>    A ns1.+ B

I doubt it. But you could have qualified names such as

ns1.A + ns1.B

>
> And since you have no direct visibility you have a problem with prefix
> notation.
>
>    ns1.A.Print ()
>
> Why Print is visible?

Good example.

>
> I do not want to explain further, I am not a language lawyer, but there
> exit massive problems with your approach if you have generic and other
> polymorphic bodies. In essence all methods must be visible in order to
> prevent calling wrong a method, since you implicitly convert to the
> parent if the overriding is not visible. Ada had such issues until 2005.

OK.

>
>> 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.
>
> You can use fully qualified name to disambiguate.

If the names (the contents of the namespaces) cannot be intermixed then
conflicts would become impossible and disambiguation would be the norm.

--
James Harris

On 21/11/2021 19:32, Bart wrote:
> On 21/11/2021 17:19, James Harris wrote:

....

>> 2. Searching. The order in which to search scopes for a name.
>
> I'm working on related matters right now.

If you find a really good scheme ... be sure to share! ;-)

> First I'm revising my module
> schemes across two languages, which also affects how namespaces work.
>
> But there was also the issue of finding a module or support file within
> the file system. I had had a stack of possible search paths, but I've
> dropped that in order to have more confidence in exactly what version of
> a file will be found, and where.

I am unsure about resolving names by search paths. In some ways they
make a lot of sense but in others they introduce uncertainty.

One option I have in mind is for names which are to be imported to use
search paths (and yet names as used in a function to go the other way
and be very explicit). The first entry in the search path would normally
be the folder the source file sits in (the base folder) so an import of
A.B would, by default, look in the base folder for a file called
A.<language-extension> and then expect to find a name B in the outer
scope in that file.

If no file A were to be found there then the search would continue with
the next namespace in the search path.

The search path could be manipulated under program control between one
import and the next.

You may have already thought of this but in some cases it can be
convenient to have a reserved name to represent any namespace itself -
in this case to represent the file. For example, say you wanted to write
a factorial function and your language extension was xx. You might
create a file called

factorial.xx

That's fairly normal. But then say within it that you create a function
to compute the factorial. You would naturally call it 'factorial' but
then its name from the outside of the file would be factorial.factorial
which could be a bit irritating. :-(

It would be better for a caller simply to refer to the function
'factorial' yet you cannot drop the function header and begin
factorial.xx in function mode because, for example, you need to specify
a parameter or two. That's why I say an option is to have a reserved
name such as underscore. Then factorial.xx can include

function _ (parameter)
... function body ...
endfunction

and that function could be invoked simply as function(...) from the
outside.

--
James Harris

On 21/11/2021 22:43, James Harris wrote:

....

> That's why I say an option is to have a reserved
> name such as underscore. Then factorial.xx can include
>
>   function _ (parameter)
>     ... function body ...
>   endfunction
>
> and that function could be invoked simply as function(...) from the
> outside.

Oops. That's wrong. It should have said it could be invoked as
factorial(...) from the outside - where 'factorial' is the file name
(without the extension).

Similarly a function with the same name, _, in a file called

fib.xx

would be invocable as fib(...).

Just some ideas.

--
James Harris

On 21/11/2021 22:43, James Harris wrote:
> On 21/11/2021 19:32, Bart wrote:
>> On 21/11/2021 17:19, James Harris wrote:
>
> ...
>
>>> 2. Searching. The order in which to search scopes for a name.
>>
>> I'm working on related matters right now.
>
> If you find a really good scheme ... be sure to share! ;-)
>
>
>> First I'm revising my module schemes across two languages, which also
>> affects how namespaces work.
>>
>> But there was also the issue of finding a module or support file
>> within the file system. I had had a stack of possible search paths,
>> but I've dropped that in order to have more confidence in exactly what
>> version of a file will be found, and where.
>
> I am unsure about resolving names by search paths. In some ways they
> make a lot of sense but in others they introduce uncertainty.

No that was about finding source files. The similarity was in using a
list of search folders, and trying each of them in turn, and using a
list of scopes.

While files are not limited to one or two folders, top-level names are
limited to a fixed number of scopes, perhaps 3 or 4.

>
> You may have already thought of this but in some cases it can be
> convenient to have a reserved name to represent any namespace itself -
> in this case to represent the file. For example, say you wanted to write
> a factorial function and your language extension was xx. You might
> create a file called
>
>   factorial.xx
>
> That's fairly normal. But then say within it that you create a function
> to compute the factorial. You would naturally call it 'factorial' but
> then its name from the outside of the file would be factorial.factorial
> which could be a bit irritating. :-(
>
> It would be better for a caller simply to refer to the function
> 'factorial' yet you cannot drop the function header and begin
> factorial.xx in function mode because, for example, you need to specify
> a parameter or two. That's why I say an option is to have a reserved
> name such as underscore. Then factorial.xx can include
>
>   function _ (parameter)
>     ... function body ...
>   endfunction
>
> and that function could be invoked simply as function(...) from the
> outside.

I don't quite get this (I've seen your follow-up correction).

If I create such a file called fact.m:

global function fact(int n)int = {(n<=1 | 1 | n*fact(n-1))}

And I call it from the lead module:

module fact # (new module scheme uses 'module')

proc start=
println(fact.fact(12))
println(fact(12))
end

Either of those designations will work.

fact() will first resolve to the exported fact.fact routine before the
module name.

But fact.fact will resolve first to the module name.

So there is no ambiguity since there is only one actual fact function,
and the rules say that module names are resolved first, for the A in A.B.

But if there is a local version of fact():

fact() resolves to that local version.

fact.fact() is an error: the first 'fact' resolves to that local
function, which does not contain a definition of 'fact'.

Generaly, module names that match function names etc are a nuisance
(especially in my dynamic languages where a standalone module name not
followed by "." is a valid expression term).

But there is a workaround for this example:

module fact as ff

function fact(int n)int = {n*2}

proc start=
println(ff.fact(12))
println(fact(12))
end

Here, I've provided an alias for the module name 'fact', so that I can
use 'ff' to remove the ambiguity.

On Saturday, November 20, 2021 at 9:48:06 PM UTC-6, luserdroog wrote:
> 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...
[snip]
> 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.

Erhm. That was not the meat of the situation, just the surface syntax. sigh.
The real issue is how to implement the directive. I have support for
Weizenbaum environment chains, although so far there are only ever two
environments: global or local to a (DEL) function.

On function entry, a local symbol table is linked to the global table and
this chain is used to resolve any names in the function (dynamically,
in the interpreter's runtime code). So a "using" directive could (I think)
just add a new symbol table to the chain, just behind the locals.

That feels too easy. I must have missed something. Or Weizenbaum was
even wiser than I thought.

On 22/11/2021 01:54, Bart wrote:
> On 21/11/2021 22:43, James Harris wrote:
>> On 21/11/2021 19:32, Bart wrote:

....

>>> But there was also the issue of finding a module or support file
>>> within the file system. I had had a stack of possible search paths,
>>> but I've dropped that in order to have more confidence in exactly
>>> what version of a file will be found, and where.
>>
>> I am unsure about resolving names by search paths. In some ways they
>> make a lot of sense but in others they introduce uncertainty.
>
> No that was about finding source files. The similarity was in using a
> list of search folders, and trying each of them in turn, and using a
> list of scopes.
>
> While files are not limited to one or two folders, top-level names are
> limited to a fixed number of scopes, perhaps 3 or 4.

One good thing about discussing such topics is that they force me to
think about some of the harder choices. Where that's got me in this case
is as follows.

I'd like to scrap the idea of searching for names in a search path. That
may be fine for users running code but programmers can - and probably
should - be more precise. As a programmer I'd rather specify exactly
which import I want than to have the vagueness of something (such as a
compiler, linker or loader) searching for it in a series of locations.

Now I think about it the system we normally use for finding headers and
other object files is woeful! "Look through these folders and pick the
first match." What??? I'd rather say "import this specific name from
this specific module".

That's easy when there's only one possible module to import but what if
we want one from a number of choices? To illustrate, imagine there are
modules which are distinct per CPU type as in

an x86-32 module
an x86-64 module
an arm-hf-64 module
etc

and our code is generic enough to work with any of them. In that case
ISTM best to have the CPU type as a parameter and say something like

import lib.${CPUTYPE}.modname

where CPUTYPE will have been defined as a build parameter.

That avoids the vagueness of searching and gives the programmer full
control.

What do you think?

I'll reply to the other part of your reply separately.

--
James Harris

On 22/11/2021 01:54, Bart wrote:
> On 21/11/2021 22:43, James Harris wrote:

....

>>
>> You may have already thought of this but in some cases it can be
>> convenient to have a reserved name to represent any namespace itself -
>> in this case to represent the file. For example, say you wanted to
>> write a factorial function and your language extension was xx. You
>> might create a file called
>>
>>    factorial.xx
>>
>> That's fairly normal. But then say within it that you create a
>> function to compute the factorial. You would naturally call it
>> 'factorial' but then its name from the outside of the file would be
>> factorial.factorial which could be a bit irritating. :-(
>>
>> It would be better for a caller simply to refer to the function
>> 'factorial' yet you cannot drop the function header and begin
>> factorial.xx in function mode because, for example, you need to
>> specify a parameter or two. That's why I say an option is to have a
>> reserved name such as underscore. Then factorial.xx can include
>>
>>    function _ (parameter)
>>      ... function body ...
>>    endfunction
>>
>> and that function could be invoked simply as function(...) from the
>> outside.
>
> I don't quite get this (I've seen your follow-up correction).
>
>
> If I create such a file called fact.m:
>
>   global function fact(int n)int = {(n<=1 | 1 | n*fact(n-1))}
>
> And I call it from the lead module:
>
>
>     module fact             # (new module scheme uses 'module')
>
>     proc start=
>         println(fact.fact(12))
>         println(fact(12))
>     end
>
> Either of those designations will work.
>
> fact() will first resolve to the exported fact.fact routine before the
> module name.
>
> But fact.fact will resolve first to the module name.
>
> So there is no ambiguity since there is only one actual fact function,
> and the rules say that module names are resolved first, for the A in A.B.

As I just wrote in another reply to the same post perhaps we should get
away from the idea of a name being resolved to the first match from
multiple places. That may work for human convenience when typing things
in to a command line but there's no need for it when a programmer
prepares a source file and can specify in it exactly what he's referring
to.

It's well illustrated in your example about imports. Why would you want

fact.fact
fact

both to resolve to the same thing?

External names could potentially be long with many parts but I'd still
have the ability to define a local alias for anything external so that
it could be referred to by a short name in program code.

As I say, the above is about imports. What of names within nested scopes
in our code? I don't know, yet. Jury's out!

>
> But if there is a local version of fact():
>
>    fact() resolves to that local version.
>
>    fact.fact() is an error: the first 'fact' resolves to that local
> function, which does not contain a definition of 'fact'.
>
> Generaly, module names that match function names etc are a nuisance
> (especially in my dynamic languages where a standalone module name not
> followed by "." is a valid expression term).
>
> But there is a workaround for this example:
>
>     module fact as ff
>
>     function fact(int n)int = {n*2}
>
>     proc start=
>         println(ff.fact(12))
>         println(fact(12))
>     end
>
> Here, I've provided an alias for the module name 'fact', so that I can
> use 'ff' to remove the ambiguity.

I prefer that. It's clearer. In the call, ff clearly relates to the ff
defined above.

Alternatively, what about fact.m including reserved function name _ as in

global function _(int n)int = {(n<=1 | 1 | n*fact(n-1))}

such that the caller's code would by naming the module refer to the _
function within it as in

module fact # (new module scheme uses 'module')

proc start=
println(fact(12))
end

?

--
James Harris

On 23/11/2021 01:58, luserdroog wrote:
> On Saturday, November 20, 2021 at 9:48:06 PM UTC-6, luserdroog wrote:

....

>> 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.
>
> Erhm. That was not the meat of the situation, just the surface syntax. sigh.
> The real issue is how to implement the directive. I have support for
> Weizenbaum environment chains, although so far there are only ever two
> environments: global or local to a (DEL) function.

What are "Weizenbaum environment chains"?? Most of Google's suggestions
don't seem to relate.

--
James Harris

On 23/11/2021 17:52, James Harris wrote:
> On 22/11/2021 01:54, Bart wrote:

>> So there is no ambiguity since there is only one actual fact function,
>> and the rules say that module names are resolved first, for the A in A.B.
>
> As I just wrote in another reply to the same post perhaps we should get
> away from the idea of a name being resolved to the first match from
> multiple places. That may work for human convenience when typing things
> in to a command line but there's no need for it when a programmer
> prepares a source file and can specify in it exactly what he's referring
> to.
>
> It's well illustrated in your example about imports. Why would you want
>
>   fact.fact
>   fact
>
> both to resolve to the same thing?

Suppose you're in a directory 'fact' (now talking about files not
identifiers!), and you have a file called 'fact'. It might be poor
practice, but it happens.

Then there are all these multiple ways of refering to that file from
within folder fact:

C:\fact>type fact
This is FACT.

C:\fact>type \fact\fact
This is FACT.

C:\fact>type .\fact
This is FACT.

C:\fact>type .\.\.\.\.\.\.\.\.\fact
This is FACT.

Further, on Windows, if the file 'fact' was a program, then if folder
'fact' was one of the search paths (SET PATH=, equivalent to USING),
then program 'fact' could be accessed from anywhere:

C:\demo>set path=%PATH%;C:\fact

C:\demo>fact
Program FACT

The difference is that here, it will settle for the first match; it will
no report an ambiguity if there are multiple fact.exe files accessible.

They both resolve to the same thing because they do. A file system gives
you the choice of an absolute or relative path, when it is possible.

So can a langage. The advantage of an absolute path, like fact.fact, is
that it will work from anywhere.

Just fact() will see the local function 'fact' first. fact.fact() will
always use the one inside module fact, from any module.

>
> External names could potentially be long with many parts but I'd still
> have the ability to define a local alias for anything external so that
> it could be referred to by a short name in program code.
>
> As I say, the above is about imports. What of names within nested scopes
> in our code? I don't know, yet. Jury's out!

I don't have many nested scopes. My language will not peek inside them,
only inside the outermost scope of a module.

>>
>> But if there is a local version of fact():
>>
>>     fact() resolves to that local version.
>>
>>     fact.fact() is an error: the first 'fact' resolves to that local
>> function, which does not contain a definition of 'fact'.
>>
>> Generaly, module names that match function names etc are a nuisance
>> (especially in my dynamic languages where a standalone module name not
>> followed by "." is a valid expression term).
>>
>> But there is a workaround for this example:
>>
>>      module fact as ff
>>
>>      function fact(int n)int = {n*2}
>>
>>      proc start=
>>          println(ff.fact(12))
>>          println(fact(12))
>>      end
>>
>> Here, I've provided an alias for the module name 'fact', so that I can
>> use 'ff' to remove the ambiguity.
>
> I prefer that. It's clearer. In the call, ff clearly relates to the ff
> defined above.

I have to use this when there are ambiguites! But also if gives a
shorter, less cluttery name, and more immune from changes of module name.

(Or, sometimes, there is a choice of module X or Y, both aliased as A,
so I just write A whatever the actual module.)

>
> Alternatively, what about fact.m including reserved function name _ as in
>
>   global function _(int n)int = {(n<=1 | 1 | n*fact(n-1))}

(What about the 'fact' in the body of the function? Actually what would
this function be called? They can't all be _!)

> such that the caller's code would by naming the module refer to the _
> function within it as in
>
>   module fact             # (new module scheme uses 'module')
>
>   proc start=
>     println(fact(12))
>   end

I don't get this. Module 'fact' might contain 1000 functions, all with
different names.

Is this still about the module and that one function of many sharing the
same name?

What problem is this solving?

On 23/11/2021 20:38, Bart wrote:
> On 23/11/2021 17:52, James Harris wrote:
>> On 22/11/2021 01:54, Bart wrote:

....

>   C:\fact>type \fact\fact
>   This is FACT.

....

> The difference is that here, it will settle for the first match; it will
> no report an ambiguity if there are multiple fact.exe files accessible.

Yes, IMO that's not ideal. A program should be able to invoke a specific
external function - rather than the first one which matches. :-o

>
> They both resolve to the same thing because they do. A file system gives
> you the choice of an absolute or relative path, when it is possible.
>
> So can a langage. The advantage of an absolute path, like fact.fact, is
> that it will work from anywhere.

Have to say I would call that a relative path. Wouldn't an absolute path
be one which begins at somewhere fixed such as your \fact\fact, above,
starting at the root directory (assuming that \ means the root dir).

....

>> Alternatively, what about fact.m including reserved function name _ as in
>>
>>    global function _(int n)int = {(n<=1 | 1 | n*fact(n-1))}
>
> (What about the 'fact' in the body of the function? Actually what would
> this function be called? They can't all be _!)

Good point. As I said in my earlier post I am not sure what would be
best to do about resolving internal references. If the language
specifies that the compiler is to search for a name in successively
surrounding scopes (as in probably most HLLs) then the program could be

global function _(int n)int = {(n <= 1 | 1 | n * _(n - 1))}

(If the language specifies that all references to names begin at file
level then the code would be the same because _ is at the file level.)

However, if the language specifies that references made within a
function are rooted at the function level then there would have to be
some way to go 'up' a level to where the function is defined. Something
where the @@ is in

global function _(int n)int = {(n <= 1 | 1 | n * @@/_(n - 1))}

>
>> such that the caller's code would by naming the module refer to the _
>> function within it as in
>>
>>    module fact             # (new module scheme uses 'module')
>>
>>    proc start=
>>      println(fact(12))
>>    end
>
> I don't get this. Module 'fact' might contain 1000 functions, all with
> different names.

Yes, there could be any number of other functions in the same file.
Ignoring overloading, only one would take the name of the file. For
example, if the main _ function came with other functions Convert and
Reduce (say) then the file would have the following functions.

function _
function Convert
function Reduce

Only one, the _ function, would represent the file itself. If the file were

calc.xx

then from outside the file the three functions would be invocable as

calc(....)
calc.Convert(....)
calc.Reduce(....)

And, yes, I am wary of the potential for that to cause problems!

>
> Is this still about the module and that one function of many sharing the
> same name?

No, overloading aside, only one function in the file would have that name.

>
> What problem is this solving?

It's just an idea I am exploring in the context of hierarchical
namespaces. It would not always be relevant. For example, if one had a
file called

utils.xx

(where xx is the programming language extension) then one could imagine
that the functions within it would all have their own names such as

utils.advance(....)

with none having the name of the file. But as above if the programmer
created a file such as

discriminant.xx

then it could look a bit awkward to give the primary or only function
within that file the same name if it had to be invoked as

discriminant.discriminant(....)

That's not nice! :-(

Maybe this will turn out to be just aesthetics but I am thinking of it
applying to any namespace, not just files so I'll see where it goes.

--
James Harris

On 23/11/2021 22:36, James Harris wrote:
> On 23/11/2021 20:38, Bart wrote:
>> On 23/11/2021 17:52, James Harris wrote:
>>> On 22/11/2021 01:54, Bart wrote:
>
> ...
>
>>    C:\fact>type \fact\fact
>>    This is FACT.
>
> ...
>
>> The difference is that here, it will settle for the first match; it
>> will no report an ambiguity if there are multiple fact.exe files
>> accessible.
>
> Yes, IMO that's not ideal. A program should be able to invoke a specific
> external function - rather than the first one which matches. :-o
>
>>
>> They both resolve to the same thing because they do. A file system
>> gives you the choice of an absolute or relative path, when it is
>> possible.
>>
>> So can a langage. The advantage of an absolute path, like fact.fact,
>> is that it will work from anywhere.
>
> Have to say I would call that a relative path. Wouldn't an absolute path
> be one which begins at somewhere fixed such as your \fact\fact, above,
> starting at the root directory (assuming that \ means the root dir).

Yes, that's true. I tend not to use the names of modules for anything
else, so when a qualified name starts with a module, then I think of it
as absolute.

There /is/ a special top-level name in my ST, that I give the internal
name $prog, but my name resolver is not set up to deal with that.

Then a fully absolute name would be:

$prog.fact.fact()

Although a snappier alias would be needed if I was going to use that
(I'm not).

> ...
>
>>> Alternatively, what about fact.m including reserved function name _
>>> as in
>>>
>>>    global function _(int n)int = {(n<=1 | 1 | n*fact(n-1))}
>>
>> (What about the 'fact' in the body of the function? Actually what
>> would this function be called? They can't all be _!)
>
> Good point. As I said in my earlier post I am not sure what would be
> best to do about resolving internal references. If the language
> specifies that the compiler is to search for a name in successively
> surrounding scopes (as in probably most HLLs) then the program could be
>
>   global function _(int n)int = {(n <= 1 | 1 | n * _(n - 1))}
>
> (If the language specifies that all references to names begin at file
> level then the code would be the same because _ is at the file level.)
>
> However, if the language specifies that references made within a
> function are rooted at the function level then there would have to be
> some way to go 'up' a level to where the function is defined. Something
> where the @@ is in
>
>   global function _(int n)int = {(n <= 1 | 1 | n * @@/_(n - 1))}

This is getting elaborate.

I simply do not want to deal with the hassle, or the clutter, so I do as
much as I can to hardly ever need to use qualified names.

It's just one big happy family with everyone on first name terms.

However, my recent module change means I can split my program into
several families in separate houses (but in the same compound), with
people on first name terms in each, and also with selected
representatives of other houses.

It's rare that I'd need to use a 'surname'.

(This analogy means that program=compound; subprogram=house, and
module=room.

Unsurprisingly I tend to do the same thing with files in folders:
everything is usually on one level, I hate nested directories.)

>
>>
>>> such that the caller's code would by naming the module refer to the _
>>> function within it as in
>>>
>>>    module fact             # (new module scheme uses 'module')
>>>
>>>    proc start=
>>>      println(fact(12))
>>>    end
>>
>> I don't get this. Module 'fact' might contain 1000 functions, all with
>> different names.
>
> Yes, there could be any number of other functions in the same file.
> Ignoring overloading, only one would take the name of the file. For
> example, if the main _ function came with other functions Convert and
> Reduce (say) then the file would have the following functions.
>
>   function _
>   function Convert
>   function Reduce
>
> Only one, the _ function, would represent the file itself. If the file were
>
>   calc.xx
>
> then from outside the file the three functions would be invocable as
>
>   calc(....)
>   calc.Convert(....)
>   calc.Reduce(....)
>
> And, yes, I am wary of the potential for that to cause problems!

I think I know what you're getting at.

In my static language, I don't have executable code outside a function;
in the dynamic language, I do, but mainly to make quick, short programs
easier to write.

There are also two special function names (dynamic code):

* start(); this is called automatically for each module if present.

* main(); this is only called if it's in the main module.

Putting 'module' code in start() is recommended instead of writing it
openly. (There are issues with scope in doing so.)

So I think that what you call "_", I deal with as "start". Except your
"_" is only called on demand; my start() is used to initialise a module.

>> What problem is this solving?
>
> It's just an idea I am exploring in the context of hierarchical
> namespaces. It would not always be relevant. For example, if one had a
> file called
>
>   utils.xx
>
> (where xx is the programming language extension) then one could imagine
> that the functions within it would all have their own names such as
>
>   utils.advance(....)
>
> with none having the name of the file. But as above if the programmer
> created a file such as
>
>   discriminant.xx
>
> then it could look a bit awkward to give the primary or only function
> within that file the same name if it had to be invoked as
>
>   discriminant.discriminant(....)
>
> That's not nice! :-(

Pythn programs do that all the time; no one cares. But it also has, if
I've got it right:

from discriminant import discriminant
discriminant()

However, with this:

from discriminant import discriminant
from discriminant2 import discriminant
discriminant()

where two modules export it, it calls the last one seen. It just
overwrites the first. Actually 'import discriminant' overwrites the
module of that name also.

That's a bad show, but typical of Python:

from math import sqrt
sqrt = 42

(This is a language that runs major banking corporations!)

On 24/11/2021 01:02, Bart wrote:
> On 23/11/2021 22:36, James Harris wrote:

....

> There /is/ a special top-level name in my ST, that I give the internal
> name $prog, but my name resolver is not set up to deal with that.
>
> Then a fully absolute name would be:
>
>    $prog.fact.fact()

Cool. I have a similar idea - mnemonics indicating predefined places in
the name hierarchy. For example, the folder in which the current source
file sits would be something like

&base

so a factorial program in the same folder could be invoked as

&base.fact()

....

> Unsurprisingly I tend to do the same thing with files in folders:
> everything is usually on one level, I hate nested directories.)

Would you still hate nested directories if they were simply part of the
name hierarchy? For example, say you had

folderA
prog.xx
folderB
folderC
sub.xx

Then prog.xx would be able to invoke the code in sub.xx even though it's
two folders deeper by

&base.folderB.folderC.sub()

or as with any name prog could define an alias for it and invoke that.

That's OK, isn't it?

....

> So I think that what you call "_", I deal with as "start". Except your
> "_" is only called on demand; my start() is used to initialise a module.

They are not quite the same - for the reasons you mention.

....

>>    discriminant.discriminant(....)
>>
>> That's not nice! :-(
>
> Pythn programs do that all the time; no one cares.

You surprise me. You dislike the repetition of i in

for (i = 0; i < LEN; i++)

but you don't mind the repetition in

discriminant.discriminant

?

--
James Harris

On 24/11/2021 08:52, James Harris wrote:
> On 24/11/2021 01:02, Bart wrote:
>> On 23/11/2021 22:36, James Harris wrote:
>
> ...
>
>> There /is/ a special top-level name in my ST, that I give the internal
>> name $prog, but my name resolver is not set up to deal with that.
>>
>> Then a fully absolute name would be:
>>
>>     $prog.fact.fact()
>
> Cool. I have a similar idea - mnemonics indicating predefined places in
> the name hierarchy. For example, the folder in which the current source
> file sits would be something like
>
>   &base
>
> so a factorial program in the same folder could be invoked as
>
>   &base.fact()
>
> ...
>
>> Unsurprisingly I tend to do the same thing with files in folders:
>> everything is usually on one level, I hate nested directories.)
>
> Would you still hate nested directories if they were simply part of the
> name hierarchy? For example, say you had
>
>   folderA
>     prog.xx
>     folderB
>       folderC
>         sub.xx
>
> Then prog.xx would be able to invoke the code in sub.xx even though it's
> two folders deeper by
>
>   &base.folderB.folderC.sub()
>
> or as with any name prog could define an alias for it and invoke that.
>
> That's OK, isn't it?

I just wouldn't do it. I've seen folder hierarchies 9-11 levels deep (eg
in VS installations). They are not meant for use by humans.

In a language, I already have long dotted sequences for member selection
in records. For mere name resolution. I usually have 0 dots, or at most 1.

I like things flat!

Note that A.B.C.D for member selection is not necessarily a hierarchy.
If P is the head of a linear linked list, then P.next.next.data just
accesses a member of a node futher than the chain.

>> Pythn programs do that all the time; no one cares.
>
> You surprise me. You dislike the repetition of i in
>
>   for (i = 0; i < LEN; i++)
>
> but you don't mind the repetition in
>
>   discriminant.discriminant

I didn't say I liked it; it's just common in Python, eg:

import dis # byte-code disassembler

dis.dis(fn)

However, Python does allow an alias:

dasm = dis.dis
dasm(fn)

I actually allow the same in dynamic code:

ff := fact.fact
print ff(12)

On Tuesday, November 23, 2021 at 11:57:05 AM UTC-6, James Harris wrote:
> On 23/11/2021 01:58, luserdroog wrote:
> > On Saturday, November 20, 2021 at 9:48:06 PM UTC-6, luserdroog wrote:
> ...
> >> 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.
> >
> > Erhm. That was not the meat of the situation, just the surface syntax. sigh.
> > The real issue is how to implement the directive. I have support for
> > Weizenbaum environment chains, although so far there are only ever two
> > environments: global or local to a (DEL) function.
> What are "Weizenbaum environment chains"?? Most of Google's suggestions
> don't seem to relate.
>

It's the solution to the FUNARG problem described in:

http://www.softwarepreservation.org/projects/LISP/MIT/Weizenbaum-FUNARG_Problem_Explained-1968.pdf

He calls it a "symbol table tree". But I quibble whether it's really a tree like we
usually define them. All the links go from leaves back up toward the root.
I learned about them from /Anatomy of Lisp/, and I think my implementation
in olmec copies what I understood from that book. IIRC Anatomy of Lisp
describes them as chains instead of a tree.

On 24/11/2021 11:37, Bart wrote:
> On 24/11/2021 08:52, James Harris wrote:

....

>> Would you still hate nested directories if they were simply part of
>> the name hierarchy? For example, say you had
>>
>>    folderA
>>      prog.xx
>>      folderB
>>        folderC
>>          sub.xx
>>
>> Then prog.xx would be able to invoke the code in sub.xx even though
>> it's two folders deeper by
>>
>>    &base.folderB.folderC.sub()
>>
>> or as with any name prog could define an alias for it and invoke that.
>>
>> That's OK, isn't it?
>
> I just wouldn't do it. I've seen folder hierarchies 9-11 levels deep (eg
> in VS installations). They are not meant for use by humans.
>
> In a language, I already have long dotted sequences for member selection
> in records. For mere name resolution. I usually have 0 dots, or at most 1.
>
> I like things flat!

I don't mind up to one level of depth, and that can be achieved by
aliasing a name (zero levels) or its parent (one level). For example,

alias gui = &base.folderB.folderC

then the subroutine could be invoked with

gui.sub()

>
> Note that A.B.C.D for member selection is not necessarily a hierarchy.
> If P is the head of a linear linked list, then P.next.next.data just
> accesses a member of a node futher than the chain.

I don't think I would have that problem. If a node of the list had the form

ui64 next
ui64 data

and P referred to a node then

P would refer to the node
P* would be the node
P*.next would refer to the next node
P*.data would be the data in the node

--
James Harris

On 25/11/2021 00:22, luserdroog wrote:
> On Tuesday, November 23, 2021 at 11:57:05 AM UTC-6, James Harris wrote:
>> On 23/11/2021 01:58, luserdroog wrote:

....

>>> The real issue is how to implement the directive. I have support for
>>> Weizenbaum environment chains, although so far there are only ever two
>>> environments: global or local to a (DEL) function.

>> What are "Weizenbaum environment chains"?? Most of Google's suggestions
>> don't seem to relate.
>>
>
> It's the solution to the FUNARG problem described in:
>
> http://www.softwarepreservation.org/projects/LISP/MIT/Weizenbaum-FUNARG_Problem_Explained-1968.pdf
>
> He calls it a "symbol table tree". But I quibble whether it's really a tree like we
> usually define them. All the links go from leaves back up toward the root.
> I learned about them from /Anatomy of Lisp/, and I think my implementation
> in olmec copies what I understood from that book. IIRC Anatomy of Lisp
> describes them as chains instead of a tree.
>

Thanks for the info. It seems to be related to partial function
application and/or currying.

https://en.wikipedia.org/wiki/Partial_application
https://en.wikipedia.org/wiki/Currying

Have to say, all such 'clever' approaches seem to me to make a program
unnecessarily hard to understand. I've never needed any of them.

--
James Harris

On Friday, November 26, 2021 at 11:55:27 AM UTC-6, James Harris wrote:
> On 25/11/2021 00:22, luserdroog wrote:
> > On Tuesday, November 23, 2021 at 11:57:05 AM UTC-6, James Harris wrote:
> >> On 23/11/2021 01:58, luserdroog wrote:
> ...
> >>> The real issue is how to implement the directive. I have support for
> >>> Weizenbaum environment chains, although so far there are only ever two
> >>> environments: global or local to a (DEL) function.
>
> >> What are "Weizenbaum environment chains"?? Most of Google's suggestions
> >> don't seem to relate.
> >>
> >
> > It's the solution to the FUNARG problem described in:
> >
> > http://www.softwarepreservation.org/projects/LISP/MIT/Weizenbaum-FUNARG_Problem_Explained-1968.pdf
> >
> > He calls it a "symbol table tree". But I quibble whether it's really a tree like we
> > usually define them. All the links go from leaves back up toward the root.
> > I learned about them from /Anatomy of Lisp/, and I think my implementation
> > in olmec copies what I understood from that book. IIRC Anatomy of Lisp
> > describes them as chains instead of a tree.
> >
> Thanks for the info. It seems to be related to partial function
> application and/or currying.
>
> https://en.wikipedia.org/wiki/Partial_application
> https://en.wikipedia.org/wiki/Currying
>
> Have to say, all such 'clever' approaches seem to me to make a program
> unnecessarily hard to understand. I've never needed any of them.
>

It's important for those tricks, but also for closures. Like in javascript,

function something( myarray ){
var thing = 12;
return myarray.Map( elem=>elem+thing );
}

The closure allows the "thing" in "elem=>elem+thing" to access
the "thing" defined in the outer function.

James Harris <james.harris.1@gmail.com> 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.)

I did not check C++ rules here. But other languages have simple rule:
local name wins. That is to access global one you either should
not declare local one or use qualified version.

If you think about this for a while you should see that this is
the only sensible rule: imported modules can change without
programmer of "client" module knowing this. And breakning clients
by merely adding new export is in most cases not acceptable.

OTOH client should know which imported functions will be used.
So avoiding local use of imported names usually is not a big
burden. And when client thinks that some local name is extremally
good and can not be reasonably replaced by different name, then
client can still use imported name as qualified name.

--
Waldek Hebisch

On 2022-01-29 03:35, antispam@math.uni.wroc.pl wrote:

> I did not check C++ rules here. But other languages have simple rule:
> local name wins. That is to access global one you either should
> not declare local one or use qualified version.

The rules most languages deploy are rather quite complicated. There are
three choices:

1. Silent hiding of external entities with conflicting names
2. Overloading the entities with conflicting names
3. Signaling error

The rule #2 is interesting as it can create mutually hiding names when
overloading cannot be resolved.

Languages tend to have a mixture of all three from case to case.

> If you think about this for a while you should see that this is
> the only sensible rule: imported modules can change without
> programmer of "client" module knowing this. And breakning clients
> by merely adding new export is in most cases not acceptable.

Well, it is not that simple.

The first point is that from the SW development POV, if the imported
module's interface changes, the client code must be reviewed anyway.

The second point is that the rule #1 does not actually protect clients.
As an example consider two modules used by the client. If one of the
modules introduces a name conflict with another module, that breaks the
client anyway, because this case cannot be handled by the rule #1 anymore.

> OTOH client should know which imported functions will be used.
> So avoiding local use of imported names usually is not a big
> burden.

In practice it is. Ada even introduced partial visibility of imported
names. For example you can say:

use Linear_Algebra;

This will make all names from Linear_Algebra publicly visible and
potentially conflicting with other stuff. But you could write:

declare
X, Y, Z : Matrix; -- Linear_Algebra.Matrix
begin
...
Z := X + Y; -- Operation "+" of Linear_Algebra.Matrix

Now if you wanted to use only the Matrix type in your code without
importing anything else, you could do:

use type Linear_Algebra.Matrix;

This would make operations of Matrix directly visible, but nothing else.
So the code would look like:

declare
X, Y, Z : Linear_Algebra.Matrix; -- Qualified name
begin
...
Z := X + Y; -- Operation "+" of Linear_Algebra.Matrix

Without either the code would be:

declare
X, Y, Z : Linear_Algebra.Matrix; -- Qualified name
begin
...
Z := Linear_Algebra."+" (X, Y);

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

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On 2022-01-29 03:35, antispam@math.uni.wroc.pl wrote:
>
> > I did not check C++ rules here. But other languages have simple rule:
> > local name wins. That is to access global one you either should
> > not declare local one or use qualified version.
>
> The rules most languages deploy are rather quite complicated. There are
> three choices:
>
> 1. Silent hiding of external entities with conflicting names
> 2. Overloading the entities with conflicting names
> 3. Signaling error
>
> The rule #2 is interesting as it can create mutually hiding names when
> overloading cannot be resolved.

Overloading creates its own complexities. First, with overloading
what matters is really not name but full signature: name + types
of arguments and result. If language requires exact match for
signature than the rule above works with name replaced by
signature. If there are automatic type convertions or return
type is needed to resolve overloading then things indeed one
needs extra rules.

One language that I use has following extra rules:
- when interface inherists from two different interfaces each
having "the same" signature this resuls in single inherited
signature
- when overloading allows more than one function choice is
"arbitrary"

Note: in case of exact match local signature wins. Overloading
only plays role when there are multiple alternatives leading to
different types.

Both rules work under assumption that design has right names,
so functons with the same signatur do equivalent work.
Expirience with 200 thousend lines codebase shows that
this works well. However, it is not clear how this would work
with bigger codebase (say 20 million lines) or in less regular
problem domain.

Arguably, signaling error when overloading can not be resolved
in unique way would be safer.

> Languages tend to have a mixture of all three from case to case.
>
> > If you think about this for a while you should see that this is
> > the only sensible rule: imported modules can change without
> > programmer of "client" module knowing this. And breakning clients
> > by merely adding new export is in most cases not acceptable.
>
> Well, it is not that simple.
>
> The first point is that from the SW development POV, if the imported
> module's interface changes, the client code must be reviewed anyway.

Well, if your coding rules say the review is in place, do what rules
say. However, adding new signature without changing behaviour of
existing signatures may be "safe" change. Namely, it is safe
for languages without overloading. With overloading I consider
calling a different function with "the same" contract as sefe
change.

> The second point is that the rule #1 does not actually protect clients.
> As an example consider two modules used by the client. If one of the
> modules introduces a name conflict with another module, that breaks the
> client anyway, because this case cannot be handled by the rule #1 anymore.

Sure. But there is important difference: global object must be
coordinated to avoid conflicts. With say "error when names are
equal" rule there will be conflicts with local routines which
would significanlty increase number of conflicts.

> > OTOH client should know which imported functions will be used.
> > So avoiding local use of imported names usually is not a big
> > burden.
>
> In practice it is. Ada even introduced partial visibility of imported
> names. For example you can say:
>
> use Linear_Algebra;
>
> This will make all names from Linear_Algebra publicly visible and
> potentially conflicting with other stuff. But you could write:
>
> declare
> X, Y, Z : Matrix; -- Linear_Algebra.Matrix
> begin
> ...
> Z := X + Y; -- Operation "+" of Linear_Algebra.Matrix
>
> Now if you wanted to use only the Matrix type in your code without
> importing anything else, you could do:
>
> use type Linear_Algebra.Matrix;
>
> This would make operations of Matrix directly visible, but nothing else.
> So the code would look like:
>
> declare
> X, Y, Z : Linear_Algebra.Matrix; -- Qualified name
> begin
> ...
> Z := X + Y; -- Operation "+" of Linear_Algebra.Matrix
>
> Without either the code would be:
>
> declare
> X, Y, Z : Linear_Algebra.Matrix; -- Qualified name
> begin
> ...
> Z := Linear_Algebra."+" (X, Y);
>

Well, there are many ways. Extended Pascal have selective import
(only names that you specify are imported) and interfaces, that
is module may have several export lists and client decides which
one to use. And there is possiblity of renaming at import time.
All of those means that client has several ways of resolving
conflict. Extended Pascal significanly decreases chance of
artificial conflict, that is accidentally importing name that
client do not want to use. OTOH explicit import/export lists
are less attractive when there is overloading (to get equivalent
effect they require repeating type information).

Concerning Ada way, it is not clear for me how this is supposed
to work when there are multiple intersecting subsets of functions.

--
Waldek Hebisch

On 2022-02-03 20:24, antispam@math.uni.wroc.pl wrote:
> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>> On 2022-01-29 03:35, antispam@math.uni.wroc.pl wrote:
>>
>>> I did not check C++ rules here. But other languages have simple rule:
>>> local name wins. That is to access global one you either should
>>> not declare local one or use qualified version.
>>
>> The rules most languages deploy are rather quite complicated. There are
>> three choices:
>>
>> 1. Silent hiding of external entities with conflicting names
>> 2. Overloading the entities with conflicting names
>> 3. Signaling error
>>
>> The rule #2 is interesting as it can create mutually hiding names when
>> overloading cannot be resolved.
>
> Overloading creates its own complexities. First, with overloading
> what matters is really not name but full signature: name + types
> of arguments and result. If language requires exact match for
> signature than the rule above works with name replaced by
> signature. If there are automatic type convertions or return
> type is needed to resolve overloading then things indeed one
> needs extra rules.
>
> One language that I use has following extra rules:
> - when interface inherists from two different interfaces each
> having "the same" signature this resuls in single inherited
> signature

Inheritance is dynamic polymorphism. Overloading is ad-hoc polymorphism.
As such they are unrelated.

> - when overloading allows more than one function choice is
> "arbitrary"

Arbitrary? That sound like a very poorly designed language.

> Note: in case of exact match local signature wins.

= #1

> Overloading
> only plays role when there are multiple alternatives leading to
> different types.

= #2

> Both rules work under assumption that design has right names,
> so functons with the same signatur do equivalent work.

Well, this is the Liskov's substitutability principle (LSP). Whether to
apply it to ad-hoc polymorphism is a question of program semantics.

In any case, the language does not interfere with the semantics, that
would be incomputable. LSP is not not enforceable, it is only a design
principle.

> Expirience with 200 thousend lines codebase shows that
> this works well. However, it is not clear how this would work
> with bigger codebase (say 20 million lines) or in less regular
> problem domain.

Large projects are split into weakly coupled modules.

> Arguably, signaling error when overloading can not be resolved
> in unique way would be safer.

That is the only way. The question is different. Whether visibility
rules should allow programs with *potentially* unresolvable overloading.
E.g. both M1 and M2 declare conflicting Foo. M3 uses both M1 and M2 but
does not reference Foo. Is M3 legal? Or just the fact of using
conflicting M1 and M2 should make M3 illegal.

>> The first point is that from the SW development POV, if the imported
>> module's interface changes, the client code must be reviewed anyway.
>
> Well, if your coding rules say the review is in place, do what rules
> say. However, adding new signature without changing behaviour of
> existing signatures may be "safe" change. Namely, it is safe
> for languages without overloading.

It is never safe. The change can always introduce a conflict. The only
choice is between flagging it as an error always or only when a client
actually uses it.

This is comparable with the choices made in C++ templates vs choices in
Ada generics.

C++ templates are not checked. So long you do not instantiate the
template with parameters provoking an error you are good.

Ada generics are [partially] checked so that potential instantiation
errors are signaled even if never instantiated in the program.

>> The second point is that the rule #1 does not actually protect clients.
>> As an example consider two modules used by the client. If one of the
>> modules introduces a name conflict with another module, that breaks the
>> client anyway, because this case cannot be handled by the rule #1 anymore.
>
> Sure. But there is important difference: global object must be
> coordinated to avoid conflicts.

There should be no global objects, for the start.

> With say "error when names are
> equal" rule there will be conflicts with local routines which
> would significanlty increase number of conflicts.

and reduce surprises. Any choice has drawbacks and name spaces is a
method of damage control.

> Well, there are many ways. Extended Pascal have selective import
> (only names that you specify are imported) and interfaces, that
> is module may have several export lists and client decides which
> one to use. And there is possiblity of renaming at import time.
> All of those means that client has several ways of resolving
> conflict.

There is a difference. For example, if M1 and M2 have Foo and

with M1; use M1;
with M2, use M2;

procedure M3 is
begin
Foo; -- Conflict
end M3;

Renaming:

with M1; use M1;
with M2, use M2;

procedure M3 is
procedure Bar renames M1.Foo;
procedure Baz renames M2.Foo;
begin
Bar; -- No conflict
end M3;

Resolving:

with M1; use M1;
with M2, use M2;

procedure M3 is
begin
M1.Foo; -- Resolved per a fully qualified name
end M3;

> Extended Pascal significanly decreases chance of
> artificial conflict, that is accidentally importing name that
> client do not want to use.

You cannot accidentally import anything. The module interface must be
designed rationally to be useful for the clients. There is no defense
against poorly designed interfaces.

However interfaces can be designed in favor of clients deploying fully
qualified names vs clients deploying direct visibility. Unfortunately
one should choose one.

The former tends to choose same names for everything. So that the client
does something like:

IO.Integers.Put;

The latter would rather do

IO.Integer_IO.Put_Integer

which with direct visibility becomes

Put_Integer

> OTOH explicit import/export lists
> are less attractive when there is overloading (to get equivalent
> effect they require repeating type information).

Why? Explicit import in Ada is very popular. I gave example of

use type T;

clause which is that thing. Usually such types are numeric which leads
to massive overloading of +,-,*,/. Nobody cares as these are all resolvable.

> Concerning Ada way, it is not clear for me how this is supposed
> to work when there are multiple intersecting subsets of functions.

I am not sure what you mean. Overloading works pretty well Ada because
of types. Languages shy of overloading are ones with weak type system
when everything gets lumped into something unresolvable. E.g. if there
is no distinct numeric types or when the result is not a part of the
signature etc.

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

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On 2022-02-03 20:24, antispam@math.uni.wroc.pl wrote:
> > Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> >> On 2022-01-29 03:35, antispam@math.uni.wroc.pl wrote:
> >>
> >>> I did not check C++ rules here. But other languages have simple rule:
> >>> local name wins. That is to access global one you either should
> >>> not declare local one or use qualified version.
> >>
> >> The rules most languages deploy are rather quite complicated. There are
> >> three choices:
> >>
> >> 1. Silent hiding of external entities with conflicting names
> >> 2. Overloading the entities with conflicting names
> >> 3. Signaling error
> >>
> >> The rule #2 is interesting as it can create mutually hiding names when
> >> overloading cannot be resolved.
> >
> > Overloading creates its own complexities. First, with overloading
> > what matters is really not name but full signature: name + types
> > of arguments and result. If language requires exact match for
> > signature than the rule above works with name replaced by
> > signature. If there are automatic type convertions or return
> > type is needed to resolve overloading then things indeed one
> > needs extra rules.
> >
> > One language that I use has following extra rules:
> > - when interface inherists from two different interfaces each
> > having "the same" signature this resuls in single inherited
> > signature
>
> Inheritance is dynamic polymorphism. Overloading is ad-hoc polymorphism.
> As such they are unrelated.

You are making unwarranted assumptions here. I am writing about
language which is probably unknown to you. In this language
interface inheritance is mostly static (some folks would say
purely static). Interfaces are useful for polymorphism, but
in _this_ case polymorphism is parametric and would be useful
even without any dynamic aspect. You could have similar (but
more clumsy) language with interfaces without inheritance:
interface inheritace allows nice expression of common parts and
by name test for interface (in)compatibility (otherwise one
would be forced to use structural tests). One could use
interface inheritance without polymorphism. For example in
language somewhat similar to Modula2 or UCSD Pascal one could
have modules with separate interfaces and use inheritance for
common parts (but have no OO nor overloading).

Interfaces are related to overloading: visible interfaces decide
which signatures are visible. And in language that I am writing
above overloading means choice of _signature_. Actual function
to be run is determined at runtime.

>
> > - when overloading allows more than one function choice is
> > "arbitrary"
>
> Arbitrary? That sound like a very poorly designed language.
>
> > Note: in case of exact match local signature wins.
>
> = #1
>
> > Overloading
> > only plays role when there are multiple alternatives leading to
> > different types.
>
> = #2
>
> > Both rules work under assumption that design has right names,
> > so functons with the same signatur do equivalent work.
>
> Well, this is the Liskov's substitutability principle (LSP). Whether to
> apply it to ad-hoc polymorphism is a question of program semantics.
>
> In any case, the language does not interfere with the semantics, that
> would be incomputable.

Well, theorem proving is uncomputable, but proof checking is computable.
Arguably, program should be deemed correct only when programmer
can justify its correctness. So, at least in theory you could have
language that requires programmer to include justification (that is
proof) of correctnes...

> LSP is not not enforceable, it is only a design
> principle.
>
> > Expirience with 200 thousend lines codebase shows that
> > this works well. However, it is not clear how this would work
> > with bigger codebase (say 20 million lines) or in less regular
> > problem domain.
>
> Large projects are split into weakly coupled modules.

This 200 thousend lines is split into about 1000 modules. But
there is cluster of about 600 mutually connected modules. From
one point of view many of those modules are "independent", but
there are subtle connections and if you transitively track them there
is largish cluster...
> > Arguably, signaling error when overloading can not be resolved
> > in unique way would be safer.
>
> That is the only way. The question is different. Whether visibility
> rules should allow programs with *potentially* unresolvable overloading.
> E.g. both M1 and M2 declare conflicting Foo. M3 uses both M1 and M2 but
> does not reference Foo. Is M3 legal? Or just the fact of using
> conflicting M1 and M2 should make M3 illegal.

Word "potentially" have many different meanings. In my case
types are hairy enough that there are 3 cases:

- compiler can decide that there is only one applicable signature
- compiler can decide that there is conflict
- compiler can not decide and only at runtime it possible to
decide if there is a conflict.

The core of problem may be illustrated using Extended Pascal.
Namely, one can define schema type:

type T(i : integer) = 0..100;

above type discriminant 'i' is otherwise unused but ensures
that later w get incompatible types.

We can have procedure taking argument of schema type:

function foo(a : T) : integer;
.....

But we can also use discriminanted version of type:

function foo(a : T(42)) : integer;
.....

We can have another function taking integer parameters:

function bar(i : integer) : integer;
var a : T(i) = 0;
begin
bar := foo(a);
end;

Extended Pascal does not have overloading, so you can not have both
foo-s in the same context. But suppose that we add overloading
keeping other rules. Then, if i is different than 42 only
general (schematic) version is applicable, so there is unique
applicable siganture. But when i = 42, then both calls would
be valid, so there is conflict. As a little variation one
could write:

function bar(i : integer) : integer;
var a : T(i*i) = 0;
begin
bar := foo(a);
end;

Since 42 is not a square the second case can not occur, so there
would be no conflict at runtime.

Of course, in Ada spirit it would be to disallow both versions.
OTOH even in Ada some checks are delayed to runtime...

> >> The first point is that from the SW development POV, if the imported
> >> module's interface changes, the client code must be reviewed anyway.
> >
> > Well, if your coding rules say the review is in place, do what rules
> > say. However, adding new signature without changing behaviour of
> > existing signatures may be "safe" change. Namely, it is safe
> > for languages without overloading.
>
> It is never safe. The change can always introduce a conflict. The only
> choice is between flagging it as an error always or only when a client
> actually uses it.

Well, assuming that there are no conflict between two different
imported signatures, but only imported signature gets shadowed by
local one you will get the same code. Of course, after adding
new export compilation may discover that added signature is
in conflict with other imported signature, but this is different
case.

> >> The second point is that the rule #1 does not actually protect clients.
> >> As an example consider two modules used by the client. If one of the
> >> modules introduces a name conflict with another module, that breaks the
> >> client anyway, because this case cannot be handled by the rule #1 anymore.
> >
> > Sure. But there is important difference: global object must be
> > coordinated to avoid conflicts.
>
> There should be no global objects, for the start.

Sorry, you are attaching different meaning to words that I am.
To have meaningful disscussion we need common (global to the
disscussion) understanding of "global" and "object". To put
it differently common words should be global objects. Similarly
to be able to program you need global objects. For example
in C++ everything at source level is in some namespace. Eliminate
global namespace and you can no longer program in C++ (you would
probably consider this a good thing, but equvalent thing applies
to Ada). In particular some interfaces must be global.

> > Extended Pascal significanly decreases chance of
> > artificial conflict, that is accidentally importing name that
> > client do not want to use.
>
> You cannot accidentally import anything. The module interface must be
> designed rationally to be useful for the clients. There is no defense
> against poorly designed interfaces.

On 2022-02-04 23:28, antispam@math.uni.wroc.pl wrote:
> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>> On 2022-02-03 20:24, antispam@math.uni.wroc.pl wrote:
>>> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>>>> On 2022-01-29 03:35, antispam@math.uni.wroc.pl wrote:
>>>>
>>>>> I did not check C++ rules here. But other languages have simple rule:
>>>>> local name wins. That is to access global one you either should
>>>>> not declare local one or use qualified version.
>>>>
>>>> The rules most languages deploy are rather quite complicated. There are
>>>> three choices:
>>>>
>>>> 1. Silent hiding of external entities with conflicting names
>>>> 2. Overloading the entities with conflicting names
>>>> 3. Signaling error
>>>>
>>>> The rule #2 is interesting as it can create mutually hiding names when
>>>> overloading cannot be resolved.
>>>
>>> Overloading creates its own complexities. First, with overloading
>>> what matters is really not name but full signature: name + types
>>> of arguments and result. If language requires exact match for
>>> signature than the rule above works with name replaced by
>>> signature. If there are automatic type convertions or return
>>> type is needed to resolve overloading then things indeed one
>>> needs extra rules.
>>>
>>> One language that I use has following extra rules:
>>> - when interface inherists from two different interfaces each
>>> having "the same" signature this resuls in single inherited
>>> signature
>>
>> Inheritance is dynamic polymorphism. Overloading is ad-hoc polymorphism.
>> As such they are unrelated.
>
> You are making unwarranted assumptions here. I am writing about
> language which is probably unknown to you. In this language
> interface inheritance is mostly static (some folks would say
> purely static).

Static inheritance is still dynamic polymorphism. The point is that in
dynamic polymorphism everything is controlled and any overloading that
occur is always resolvable.

[...]

> Interfaces are related to overloading: visible interfaces decide
> which signatures are visible.

Yes, and irrelevant because in dynamic polymorphism the fundamental
principle is that a method is reachable regardless its visibility. So
overloading simply does no matter, or else the language is broken.

> Well, theorem proving is uncomputable, but proof checking is computable.
> Arguably, program should be deemed correct only when programmer
> can justify its correctness. So, at least in theory you could have
> language that requires programmer to include justification (that is
> proof) of correctnes...

Yes, you can put a meta language on top of the object language, e.g.
SPARK on top of Ada (and move the problem to the meta language).

However, when you do so, you usually prove the program correctness
rather than much weaker substitutability of types. Substitutability is
meant to ensure certain grade of correctness. If you can prove
correctness directly you care less. Of course you get fragile design if
you choose to ignore LSP completely, but that is a different story.

>>> Expirience with 200 thousend lines codebase shows that
>>> this works well. However, it is not clear how this would work
>>> with bigger codebase (say 20 million lines) or in less regular
>>> problem domain.
>>
>> Large projects are split into weakly coupled modules.
>
> This 200 thousend lines is split into about 1000 modules. But
> there is cluster of about 600 mutually connected modules. From
> one point of view many of those modules are "independent", but
> there are subtle connections and if you transitively track them there
> is largish cluster...

Right, which is why I did not say they were independent. Experience with
larger Ada projects shows that overloading is never a problem.

>>> Arguably, signaling error when overloading can not be resolved
>>> in unique way would be safer.
>>
>> That is the only way. The question is different. Whether visibility
>> rules should allow programs with *potentially* unresolvable overloading.
>> E.g. both M1 and M2 declare conflicting Foo. M3 uses both M1 and M2 but
>> does not reference Foo. Is M3 legal? Or just the fact of using
>> conflicting M1 and M2 should make M3 illegal.
>
> Word "potentially" have many different meanings. In my case
> types are hairy enough that there are 3 cases:
>
> - compiler can decide that there is only one applicable signature

= no conflict.

BTW, to be precise, compiler cannot decide anything, it must follow the
language rules, compile all correct programs (impossible of course) and
reject all incorrect ones.

> - compiler can decide that there is conflict

= conflict

> - compiler can not decide and only at runtime it possible to
> decide if there is a conflict.

= poorly designed language.

> The core of problem may be illustrated using Extended Pascal.
> Namely, one can define schema type:
>
> type T(i : integer) = 0..100;
>
> above type discriminant 'i' is otherwise unused but ensures
> that later w get incompatible types.
>
> We can have procedure taking argument of schema type:
>
> function foo(a : T) : integer;
> ....
>
> But we can also use discriminanted version of type:
>
> function foo(a : T(42)) : integer;
> ....

> Of course, in Ada spirit it would be to disallow both versions.

Right. In Ada you cannot overload these within the same context because
that is not statically resolvable. A discriminant constraint [T(42)]
produces in Ada a constrained subtype, no new type. Subtypes cannot be
used in resolution. It same as with arrays. Constrained arrays with
fixed bounds are subtypes and considered interchangeable, thus useless
for resolution purpose.

Note that you still can overload on subtypes using different modules:

package M1 is
type T (I : Integer) is null record;
subtype S is T (42);
end M1;
-------------------- In the same context ---------------
with M1; use M1;
package M2 is
function Foo (A : T) return Integer;
function Foo (A : S) return Integer; -- Illegal
end M2;
--------------------------------------------------------
But you can
-------------------- Two different packages ------------
with M1; use M1;
package M3 is
function Foo (A : T) return Integer;
end M3;

with M1; use M1;
package M4 is
function Foo (A : S) return Integer;
end M4;
--------------------------------------------------------
and then
-------------------- Import from both ------------------
with M3; use M3;
with M4; use M4;
package M5 is
-- Here Foo is overloaded and unresolvable
end M4;
--------------------------------------------------------

> OTOH even in Ada some checks are delayed to runtime...

Checks yes, resolution no.

> Well, assuming that there are no conflict between two different
> imported signatures, but only imported signature gets shadowed by
> local one you will get the same code. Of course, after adding
> new export compilation may discover that added signature is
> in conflict with other imported signature, but this is different
> case.

This case I meant.

>>>> The second point is that the rule #1 does not actually protect clients.
>>>> As an example consider two modules used by the client. If one of the
>>>> modules introduces a name conflict with another module, that breaks the
>>>> client anyway, because this case cannot be handled by the rule #1 anymore.
>>>
>>> Sure. But there is important difference: global object must be
>>> coordinated to avoid conflicts.
>>
>> There should be no global objects, for the start.
>
> Sorry, you are attaching different meaning to words that I am.
> To have meaningful disscussion we need common (global to the
> disscussion) understanding of "global" and "object". To put
> it differently common words should be global objects. Similarly
> to be able to program you need global objects.

No, you do not. There is a root namespace (in Ada it is the package
Standard). What you suggest is modifying the root namespace, which is by
the way inconsistent with the idea of a module interface.

Anyway, in Ada you cannot modify Standard. There is no way to place an
object into it.

What you can is to create a library-level package P (which fully
qualified name is Standard.P). P is a child package of Standard as such
it directly see anything from Standard.