[Aldor-l] Compiling setup

[Christian Aistleitner]

Hello,

On Fri, 11 Aug 2006 12:52:33 +0200, Gabriel Dos Reis  
<gdr at integrable-solutions.net> wrote:

> "Christian Aistleitner" <tmgisi at gmx.at> writes:
>
> [...]
>
> | However, you might also consider my test.as to be of extremely
> | miserable  style.
> | After all, I am assigning a constant ("abcdefghij") to a variable (a).
> | Afterwards I use a destructive function( set! via a.3) on the variable
> | (actually, the constant "abcdefghij"). Replacing
> |    local a: String := "abcdefghij";
> | by
> |    local a: String := copy "abcdefghij";
> | gives code that's working even without -fwritable-strings.
>
> But, in the face of it, the issue is not that of "bad style" versus
> "good style".  It is a pure bug in the translation the compiler does.

I guess you simplify the problem to much.
First off, I am not a fan of the fact that you cannot use current gcc's  
with Aldor. I would like everything to work out of the box.

True is: everything works with old enough gcc's.
True is: The Aldor compiler relied on gcc's behaviour in a part where it  
should not have.
True is: gcc changed its behaviour in this part.

However, there are more possible scenarios of why writable strings are  
needed:
- faulty compiler,
- faulty library, or
- faulty user source code.

Faulty compiler:
----------------
That's the part you try to defend.

Faulty library:
---------------
the Aldor literal "abcdefghij" is a constant:
"There are three styles of literal constants in Aldor: quoted strings,  
integers, and floating point numbers ...) (AUG §5.2)
Therefore, the correct type in C for Aldor's string literals *is* (char *).

Aldor's domain String however is _not_ meant for read-only strings (For  
read-only strings, we have the domain Symbol from the Algebra library) and  
therefore, String shourd not use (char *) as representation (and indeed  
its representation is PackedPrimitiveArray Character and not Pointer!). So  
string$String is responsible to prepare the Literal to be modifyable. For  
example its current implementation
   string(l:Literal):%             == string(l pretend Pointer);
needs to be changed to something like
   string(l:Literal):%             == copy string(l pretend Pointer);
.
When viewing "abcdefghij" as constant (just as the AUG does), the problem  
is _not_ a compiler problem, but a library problem.

Faulty user source code:
------------------------

Maybe the user is doing something he/she is not supposed to do. And maybe  
that's just what the file I provided did, because as I already wrote in my  
last email, it effectively tries to modify a constant. The compiler could  
mock about it, you are right, but the modification is hidden in the Aldor  
library ...

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.

Assume,
   local a: String = "abc"
is considered bad style and
   local a: String = copy "abc"
is considered good style, then the whole problem *is* a style problem.
And it is valid to declare things to be bad style. Even gcc treats the  
problem the same way in C:

#include <stdio.h>
int main( int argc, char *argv[] )
{
   char * str = "abcdefghij";
   str[ 4 ] = 'X';
   return 0;
}

I am rather confident, you'd mock about the use of char * in above piece  
of C code (which happily compiles and works with -fwritable strings but  
segfaults without)


> "a" above is not a constant -- or else the language could have
> forbidden its modification.

Refer to §5.2 AUG. It is a constant. IIRC, there is *no* function to  
modify a literal directly. Whet else could the compiler do?
The modification is hidden in the Aldor library. The compiler only links  
this library, so he has no chance to realize the modification of the  
constant.

> The declaration above *initializes* the
> variable with a certain (immutable) value. Consequently, it is a
> plain erroneous translation that the compiler compiles the code to
> modify the immutable value.

No. The error is in the Aldor library (for this very problem).

> Given that the language allows modification of a, consider that the
> declaration
>
>      local a: String := "abcdefghij";
>
> should have been translated to the equivalent of
>
>      char a[] = "abcdefghij";
>
> and *NOT*
>
>      char *a = "abcdefghij";

Yes. But you completely omit the domain String. From my point of view
   local litA: Literal := "abcdefghij";
   local strA: String  := "abcdefghij";
should be translated to
   char * litA = "abcdefghij";
   char strA[] = "abcdefghij";
or _something equivalent_ (as things get more complicated).

> aldor.conf is a workaround about an erroneous translation.  It has
> proven to be quite fragile and non-scalable.

Well ... no. "-fwritable-stirngs" makes the life of library developers  
easier. And the library (possible) more performant (no superfluous copying  
of strings) but (possible) more insecure (more writable data sections).
So it may even have been a design decision to use this behaviour.

> I'm quite amazed that such a plain error in the translation is
> being hidden by "bad or good style of programming" rhetorics.

Hopefully you now see, that it may not just be a "plain translation error".

--
Kind regards,
Christian