[Aldor-l] Compiling setup

[Christian Aistleitner]

Hello,

On Sun, 13 Aug 2006 16:00:04 +0200, Gabriel Dos Reis  
<gdr at integrable-solutions.net.integrable-solutions.net> wrote:

> "Christian Aistleitner" <tmgisi at gmx.at> writes:
>
> [...]
>
> | #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).
>
> What makes you believe that is a valid C program?

I did not claim "The code conforms to Standard xxx". I claimed it is a  
valid C program for my gcc on my machine.

> It invokes
> undefined behaviour.  From there you can prove everything you want.

No the behaviour is not undefined for this very gcc. It most likely is  
undefined according to most C standards, but for this very gcc I use, the  
behaviour is defined. I *know* where the variables are stored in memory  
and how they are connected. It's repeatable and always the same. It is  
defined for my gcc.

I did not claim it's portable. I do not like such code myself. But it's  
valid code for my gcc on my machine. It runs and works. Not be adhering to  
any C standard, but by design.

In the same spirit, string$String from the aldor libarry is valid -- for  
old enough gccs.

> | 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".
>
> But even with K&R, you have rubbish.

I never said to do K&R.

> | > 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 have no doubt that you can find *different implementations* of the
> Aldor libary.  However, they will be _equivalent_.  That equivalence
> classes (i.e. semamtics) is part of the compiler.

They are not equivalent. They'll most probably share some things, but they  
are not equivalent.

They'll probably all define Type, Category and these things. But the rest  
is not needed.

> | 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.
>
> That sounds like "you can code in C++ without while".  That is
> true, but that hardly implies that "while" is not part of the C++
> language.

I am sorry, but I just have to accept we a quite different view of what  
constitues the Aldor language. I do not know what other arguments I should  
give.

> However, you have many implementations of the C++ standard library.
> That does not mean the standard library is not part of the language.
>
> [...]
>
> | 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.
>
> OK.

This "OK" puzzles me.
Do you mean "Let's accept we have different points of view" or "I feel  
convinced"?

--
Kind regards,
Christian