[Aldor-l] Compiling setup

[Ralf Hemmecke]

> | local a:String == "abc";
> | In the second it would be quite questionable.
... what the value of a is after assignment
    a.3 := char "X";

> You can't define a programming language semantics in terms of
> "questionable".

I did not define the language. In fact, what I wanted to say is, that I 
know how the current compiler behaves in that case, but not how the 
Aldor language defines it.

 > You have to say whether it is well-formed with
> well-defined behaviour, or it has no defined behaviour.  If the latter,
> we just declare the program is ill-formed.  In a strongly typed
> language, it is an error that should be either caught at compile time 
> or at runtime.

> | But then
> | 
> | a.3 := char "X";
> | 
> | is the same as
> | 
> | set!(a, 3, char "X);
> | 
> | It's a BANG function and by convention destructive so one might expect
> | strange behaviour even if a is a constant.

For the compiler the above assignment is syntactic sugar for the 
function call to set!. That destructive functions should have a name 
that ends in ! is a convention that is not known to the compiler. So I 
guess a compiler would have hard times to figure out that

set!(a, 3, char "X)

actually modifies the constant a. Am I wrong? I guess, that is the 
reason why the Aldor compiler doesn't try. I think the program is 
well-formed (sorry I am not really familiar with this concept), but its 
behaviour is probably undefined. set! is a side effecting function that 
modifies something in memory that is related to its first argument.

I cannot say that I like it very much if I cannot rely on the fact that 
a constant is constant. But on the other hand, using a BANG function 
warns me that I cannot rely on what strange side effect I get.

Just being curious... is there a legal C program that defines a constant 
array, and a pointer (or whatever) to on element of that array and then 
modifies that entry in-place? If that is possible then there would be 
non-constant constants in C.

> | > There is no "bad style" excuse to invoke.  If the proram cannot work
> | > correctly, then either the language is defective or the compiler is
> | > buggy -- FWIW, I conisder the runtime system part of the compiler.
> | 
> | Hmm, until someone proves me wrong, I would claim that String is not
> | part of the Aldor language. And it is also not a part of the
> | runtime. It is defined in the Aldor library "libaldor". And I don't
> | count libaldor as part of the compiler stuff.
> 
> That is a fine distinction.  However, it does not work in practice: I
> can't test any useful program coming with the AUG without having
> libaldor.

Yes, you can. Take axllib. That also ships with the Aldor compiler and 
also has a type which is called String. You probably guess rightly that
String$LibAldor is not the same as String$AxlLib. Of course they are 
quite similar. As a library writer you would not want to confuse people 
too much.

Or, if you like, take libaxiom... yet another String type.

If you look at the sources you find that the representation of String is

PackedPrimitiveArray Character

in libaldor and BArr in axllib. One can certainly track down what
PackedPrimitiveArray or BArr is in terms of more primitive types of 
FOAM, but you see, String is a library thing.

In fact, I quite like that Aldor has a quite limited set of things that 
are built into the language.

> For all practical purposes, libaldor is part of the compiler.  You can
> distinguish the front-end from the supporting runtime system, but you
> cannot usefully, meaningfully, and practically dissociate it from the
> compiler. 

Hmm, when I came in contact with Aldor, I compiled against libaxiom. 
Since I realised that the compilation took too long and there was a 
light-weight library that was sufficient for me, I compiled against 
axllib. Then Bronstein wrote salli (standard aldor library) which is 
different from and incompatible with axllib. Salli basically became 
libaldor (after a few modifications). That is the history of the basic 
libraries of Aldor. I really cannot say that I believe that the compiler 
and this library are too attached. And if the libaldor and libalgebra 
don't become free enough, I'll think about writing my own GPL'ed one.

> Among other languages that have tried similar distinctions, you will
> find the C programming language.

[...]

>>From my other experience contributing to implement the C++ standard
> library, we (the libstdc++ team) have come to appreciate that there is
> no absolute meaningful way to separate the compiler from the runtime
> support systems.  Here, I won't spend time on the pains my
> co-maintainers and I went through.

Oh, please... I am all for standards. And I would even like to have a 
standard aldor library that is open source, well tested and a literate 
program, but still, I would call it a library. It is not part of the 
actual (aldor) language.

If you call libaldor "runtime system", OK, but currently it is not.
libaldor is shipped with the compiler, but for example in order to 
extend Axiom, you can happily do it without libaldor. (You even must do 
it without libaldor.) So if we end up with a standard aldor library and 
remove all the mess of the currently existing base libraries, I am all 
for it. If that even results in better optimization, the better.

> I was quite happy to see that the Aldor distribution did not get into
> that trap.

Hmm, really? Do you take libaldor.al or libaxllib.al? They are both 
provided with the compiler. ;-)

Ralf