[Aldor-l] Compiling setup

Sat Aug 12 09:24:08 EDT 2006

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

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