[Aldor-l] Compiling setup

[Gabriel Dos Reis]

Ralf Hemmecke <ralf at hemmecke.de> writes:

| > | However, you where trying to tell me, it is not an issue of the
| > source  | code and thereby did not consider
| > |    local a:String = "abc";
| > |    a.3 := char "X";
| > | bad style.
| > *If* the declaration of a above is valid and makes 'a' a modifiable
| >  string, *then* the program is correct and *should function correctly*.
| 
| I consider it bad style! But probably for another reason. It contains
| a syntax error.

:-)

| Christian should have written
| 
| local a:String := "abc";
| 
| or
| 
| local a:String == "abc";
| 
| In the first case, modification should be allowed.

OK.

| In the second it would be quite questionable.

You can't define a programming language semantics in terms of
"questionable".  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.

So back to my question: Is is a well-formed program with well-defined
behavior?  That is all that counts.  I can't compute the behavior of
a program with consideration like "bad style" -- the computer does not
know that.

[...]

| > 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.   AUG says, page 12:

   #include "aldor" is the general include statement that will allow
   the types and functions from libaldor to be visible. It is
   necessary to use it (or an equivalent library) in order to write
   programs. 



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. 

Among other languages that have tried similar distinctions, you will
find the C programming language.  The C programming language defines
two families of C implementations:

   * freestanding implementations, and
   * hosted implementations.

A freestanding implementation is one where you don't necessarily have
_all_ of the C library (you may view GCC/gcc as a freestanding
implementation, but the actual issue is more complicated than that).
In a freestanding implementation, the function "main()" is not
required for starting up the program (it is up to the implementation).

A hosted implementation is one which is required to provide all of the
C library and the function "main()" is required as entry point.  You
may view GCC/gcc as not being a hosted implementation.  However, the
actual issue is more complicated than that.  For example, GCC/gcc in a
non-freestanding-mode assumes that any symbol with external linkage
that is also defined by the C standard library actually has the
semantics of the C library.  It thus proceed to apply many
transformations and optimizations based on the standard semantics.
As you see, GCC/gcc does not provide you with a C library but it does
assume all standard semantics and acts as if the runtime library is
part of it.  That, in effect, mirrors the spirit of the standard.

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

Granted, all of the above examples come from personal experience so
may constitute biased examples, but you can see that they started out
as distinguishing between the "pure" compiler and the supporting
runtime system.  It is a theory that does not work well in practice.
The runtime system has to make assumptions about the front-end, andthe
front-end has to make assumptions about the library.  Of course, we
all want those set of assumptions to be as minimal as possible.

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

Even if you succeeded in providing an alternate, independent,
implementation of libaldor, it will still remain as an essential part
needed to have any useful Aldor program running.  It is

-- Gaby