[Aldor-l] Compiling setup

[Stephen Watt]

The Aldor compiler does indeed need to be fixed to not rely on
implementation dependencies of the C compiler in this respect.

We will look into this without waiting until the open source release.

-- Stephen


On Sat, Aug 12, 2006 at 03:24:08PM +0200, Gabriel Dos Reis wrote:
> "Christian Aistleitner" <tmgisi at gmx.at> writes:
> 
> | 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.
> 
> What value would you put in a theorem whose sole known proof is incorrect?
> 
> | 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.
> 
> GCC enforced the standard definition of C, and gave warning telling
> people they were relying on undefined behaviour.  
> 
> [...]
> 
> | 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.
> 
> *If* the declaration of a above is valid and makes 'a' a modifiable
>  string, *then* the program is correct and *should function correctly*.
> 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.
> 
> 
> | 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.
> 
> 
> I am sorry to strongly disagree.  This is not theology.  You can't
> define a programming language semantics in terms of "bad style".
> Either a construct is well-defined and have a meaning, or it does not.
> What is "bad" varies from people to people.  
> I, for one, consider the verbose 
> 
>     local a: String = copy "abc"
> 
> very silly, but correct.  It is probably the only way to write it to
> have a correct program, behaving correctly because the only known Aldor
> compiler fails to do its job.
> 
> | 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;
> | }
> 
> That is comparing orange and apple.  The above program is
> *explicitly ruled by the C definition* as invoking undefined
> beahviour.  First, you would have to say whether the Aldor program you
> presented has a well-defined semantics of not.  You can't hide behing
> "bad style", I'm sorry to say. 
> 
> [...]
> 
> | > "a" above is not a constant -- or else the language could have
> | > forbidden its modification.
> | 
> | Refer to ?5.2 AUG. It is a constant.
> 
> Back to my question: Is the program you presented correct or not?
> Here, I mean correct accordinig to the Aldor programming language.
> 
> Second, you said that
> 
>   # Aldor's domain String however is _not_ meant for read-only strings
> 
> which implies that it is modifiable.  If that is correct, then 'a' is
> NOT constant.
> 
> | IIRC, there is *no* function to modify a literal directly.
> 
> But, the type of 'a' is not a literal; it is String.
> 
> | 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.
> 
> I don't quite follow this reasoning.
> 
> | > 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).
> 
> We are in violent agreement there.  The failure is translated String
> properly is the cause of the error.  Not that -fwritable-strings has
> disappears. 
> 
> | > 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.
> 
> How good is a quick but wrong translation.
> 
> GCC is widely used and has become quite a "standard" C compiler, used
> to compile quite a large base or source programs.  The flag went away
> a long time ago; I have not seen a complaint that it should be
> resurected. 
> 
> | > 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".
> 
> Many thanks for elaborating.  I still maintain that it is a plain
> translation error.  Whethere or not the error is in the front-end or
> in the supporting runtime system.
> 
> -- Gaby
> 
> _______________________________________________
> Aldor-l mailing list
> Aldor-l at aldor.org
> http://www.aldor.org/mailman/listinfo/aldor-l