Re: question about linker

On 08/12/2024 22:52, Waldek Hebisch wrote:

Bart <bc@freeuk.com> wrote:

It is suitable for a vast number of programs. I'm sure it could be used
for multi-developer projects too. After all, don't your projects also
place all project-structure info into /one/ makefile? Which developer
has editing rights on that file?

 There are _many_ possible organizations.  Rather typical is one
Makefile _per directory_.  Most 'make'-s seem to be able to do
file inclusion, so you may have a single main Makefile that
includes whatever pieces are necessary.  For example, if somebody
wanted to add support for your language to gcc, that would need
creating a subdirectory and putting file called 'Make-lang.in'
inside.  Make-lang.in is essentially Makefile for your language,
but it is processed to substitute crucial variable and included
as part of gcc Makefile.  Of course, you will need more, but
this covers Makefile part.
 

Who decides what the modules are going to be? If one developer decided
they need a new module, what is the procedure to get that added to the
makefile?

 In open source project normal thing is a patch or a Git pull
request.  This specifies _all_ needed changes, including Makefile-s
if there is a need for new module it gets added where needed.
I one "my" project there can be multiple module in a file, so
a new module may go to existing file (if it is closely related
to other module in the file) or to a separate file.  I also needs
changes to Makefile.
 The above is technical part.  Other is governace of a project.
If there are multiple developers, then there may be some form
of review.

In every such endeavour, you can work at a small scale or on a big, industrial scale.
I generally work on a personal scale.
For example, there is considerable industry in publishing, manufacturing and distributing books. But the author of any one book can work in the garden shed with either a word processor, or pen and paper.
There are similarities also with people creating meals in their own kitchen, compared to being a chef in a busy restaurant, or working in mass food production. There are other such examples (eg home DIY).
I've only ever worked in a very small company, and for most of the time I worked from home.
So what I do suits me perfectly. I don't think I'm the only one like that either.

The design IS better in 100 ways, at least compared to C. Other modern,
higher level languages have 100 things I don't have, don't understand,
or would find impossible to use.
>
However a language at the level of C still appears to be extremely
popular. I guess people like something that is not so intimidating and
that they can feel in command of.

 Hmm, the only language at C level that I know and is popular
is C.  Ada, COBOL, Fortran, Modula 2, Pascal, PL/I are languages
that I consider to be at level similar to C.  But AFAIK no of them
is really popular and in modern time they aim to be higher-level
than C.  Forth is at lower level and really not that popular.
 Can you name a language that is at level of C, is popular and
is not C?

No, there is only C at that level that is mainstream. My point is that there is still a strong need for such a language, but the only practical choice for most people is C.
But this demand also shows that a language like mine, which I had been thinking of abandoning 20+ years ago, is still meaningful. /I/ like to use it too.

The alternative is to have 50 modules of a project, where each module
contains its own subset of 0 to 49 imports. That's up to 950 possible
imports to maintain across up to 50 files. It sounds a maintenance
nightmare. A dependency graph would need a pretty big sheet of paper!

 You discard posibility of re-export.  Lazy programmer may write
"utility" module that imports every needed interface and re-exports
it.  And then in each implementation import this single module.

My interfaces occur between programs. Then I do have modules that do exactly that. For example I have a module called mclib.m that contains stuff like this:
    importdll msvcrt =      # special name, becomes libc.so.6 on Linux
        func puts(ichar)int32
    end
'puts' is imported into this module from an external library, and at the same time exported to other modules in my program. Elsewhere I can just write:
    puts("abc")
but I can also write X.puts() (if for example puts was part of two different DLLs), where X is not 'msvcrt', but is either the name of the containing module, or the name of the containing subprogram.
(In the case of my puts, it is the latter, so 'msyslib.puts()` also works. The name of the imported DLL does not form a namespace in my scheme. I can create an alias for that name:
    macro clib = msyslib
so that I can write 'clib.puts'. These macros have proper scope and can be exported. Macro expansion also only applies to top level names.)

And yes, import statements need maintenance, IME it was not a
problem as import statements were small part of source.  Normally
I would import a module if I need to use at least twice something
from the module and usually number of uses were higher.
And module import tended to change slower than normal code.

A module scheme simply needs to work. Given that C has no such scheme at all, then pretty much anything is an improvement. My current version (probably the fourth major overhaul since the 1980s), works fine all my projects.
Where it doesn't, there are workarounds.

Would it even allow mutual imports? If not then that's another
nightmare, which is likely to generate lots of extra dummy modules which
only exist to get around the restriction.
>
I'm sorry, but I tried such a scheme, and decided it was awful.

 One can do better than Turbo Pascal or Modula 2.  But IME both
had quite resonable module systems.

The only Pascal I used had no modules at all that I remember. All programs had to be one giant source file. (I remember seeing the source for the Pascal compiler for PDP10, as a 2-3"-thick listing of green-lined printout.)
I'm not sure that Algol68/A68G has modules either; if it does, then I've no idea how they work.
FORTRAN IV programs could at least comprise multiple modules, but they were independently compiled then linked, much like C. Interfaces were done manually.
   You may follow Oberon and

instead of separtate interface text just mark exported things.
But explictit imports, more precisely programmer ability to
restrict imports only to those which are explicitely specified
is essential.

I find Wirth languages now too opinionated, and too strict for my style of coding.

Turbo Pascal and I think also Modula 2 distinguish import in
interface form import in implementation.  Imports in interface
part must form a tree (no cycles allowed).

This is exactly what I mean. I had such a scheme too, but I also retained the ability to have manual declarations that cut across the hierarchy. This was when I still used independent compilation of modules.

 Imports in
implementation part allow arbitrary dependencies.  One could
allow weaker restrictions, for example during compilation you
may allow patially defined things and only require that there
are no cycles when you try to fill needed information.
For example module A could define a type depending on constant
from module B and module B could define a type depending on
module A.

The problem was this, for independent compilation:
* For any module, there was the implementation, and its interface
* For a module A, you wrote the implementation, and the compiler
   generated the interface, or the 'exports file', of exported
   entities
* If module A imported B, then the compiler would need B's
   interface face in order to compile A
* This means that B had to be compiled first to create that file
* But if B also imports A, THEN you had a problem!
There were also issues when A was updated, then modules importing A need to be recompiled.
Those problems don't exist in my current scheme. Not within the modules of any one program. The updating one exists across programs. But I don't allow cycles between programs.