[Aldor-l] Compiling setup

[Christian Aistleitner]

Hello,

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


Ok, omit terms like "bad style" and "questionable". The following code is  
a nice and cosy C program (for my compiler on my machine ... see below):

#include <stdio.h>
int main( int argc, char * argv[] )
{
   char str0[]="QRST";
   char str1[]="ABCDEFGHIJKLMNO";
   str1[strlen(str1)]='P';
   printf( "%s\n", str1 );
   return 0;
}

. Its not very portable -- but portable is again one of those vague term.  
We do not use it. It's a valid C program (for this gcc an my machine).  
Seeing my intention, I am sure you guessed the output

____________________________________________
tmgisi at spencer
cwd: ~/aldor
$ nano test.c && gcc -o test test.c && ./test
ABCDEFGHIJKLMNOPQRST

on my machine
____________________________________________
tmgisi at spencer
cwd: ~/aldor
$ gcc --version
x86_64-pc-linux-gnu-gcc (GCC) 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0,  
pie-8.7.9)
Copyright (C) 2006 Free Software Foundation, Inc.
Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es
gibt KEINE Garantie; auch nicht für VERKAUFBARKEIT oder FÜR SPEZIELLE  
ZWECKE.

____________________________________________
tmgisi at spencer
cwd: ~/aldor
$ uname -a
Linux spencer 2.6.16-gentoo-r8 #1 Sun Jul 23 06:47:56 CEST 2006 x86_64 AMD  
Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux

I relied on several specifics of the compiled code, which you can  
(probably) not find in the C specification or is defined to give undefined  
behaviour. Yet it works. So it's more than valid to use on *this* gcc on  
*my* machine. It's not portable. It's not robust. I would not want to use  
such code and consider it "bad style" although it's valid code for *this*  
gcc on *my* machine.
I would not want to use such code, but you do not want to reason in those  
vague terms -- You should be more than happy to use that code with *this*  
gcc on *my* machine.

Maybe this example showed you, that the issue is also related to what you  
choose as reference. I chose "C as accepted by my gcc on my machine".  
Aldor did not choose the current C specification, but maybe the "C as  
accepted by (the then current) gcc".

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

There are equivalent libraries. I wrote one myself when experimenting with  
the semantics of Aldor's categories. In my base library, the domain  
Category had a completely different signature. I did not have a domain  
String at all.

Compare it to C++ and the STL. You can code C++ without using the STL.  
Admittedly, you'd have a rough start without using STL.
You can compile Java sources with either Sun's library or the GNU  
Classpath.

It is a crucial point to separate the language from the base library. I  
really love the Aldor language, but I do not like the aldor library at all.

> For all practical purposes, libaldor is part of the compiler.

No. What about the Axiom people using the Aldor compiler? What about  
BasicMath?
(I have not worked yot with Axiom using the Aldor compiler. Someone who  
has may please correct me if I am wrong)

> You can
> distinguish the front-end from the supporting runtime system, but you
> cannot usefully, meaningfully, and practically dissociate it from the
> compiler.

I fully agree that the runtime system is closely coupled with the  
compiler. But the Aldor library is _not_ part of the runtime system.

The aldor library is not part of the Run-time System. Aldor's runtime  
system has types like HInt and SInt and expects Category and Type to be  
some domain valued constants (to give an example of the connection between  
the front-end and the run-time system).
But the Aldor library is not in the scope of this. The Aldor libarry is  
separated from the run-time system.

--
Kind regards,
Christian