[Aldor-l] Compiling setup

[Christian Aistleitner]

Hello,

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

> "Christian Aistleitner" <tmgisi at gmx.at> writes:
>
> [...]
>
> | > | 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.
> |
> | Define what you mean by "valid".
>
> A programming language defines a language and a collection of programs
> it says well-defined and gives meaning to.

Never seen anything coming close to doing this for Aldor :) (Yes, I read  
chapter 22 of the AUG)

> [...]
>
> | > 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.
> |
> | No! You fail to have the correct tools at hand. If you have a too new
> | gcc,  you do not meet Aldor's criteria.
>
> Do you take as premisse that "Aldor specification is its compiler  
> behaviour?"

No. But you are not using Aldor. You are using the Aldor compiler.
If you use the Aldor compiler, it's up to you to provide the appropriate  
tools for using it.
gcc in version >= 4 is not compatible with the current Aldor compiler. You  
can read this on
http://www.aldor.org/faqs.html
. This is no reason to despair, as we've heard, the situation will change.
Until then, it's your fault if you use a too new gcc.

> | Hence it must  _not_ simply return the (FiWord) "abcdefghij" but has
> | to assure, it uses  read-write memory.
>
> That is essentially what I said with my C code examples; but thanks for
> taking a longer route, but equivalent route, to agree. :-/

I did not and do not agree with your point of view (telling us the Aldor  
compiler *obviously* performs faulty Aldor to C translations).
IIRC we both agreed from the start that there is a problem with current  
gcc.
You said it is a Aldor compiler problem. I said it needn't be.

And if you agree to my quoted "Hence ..." statement (that's what you did  
if I read your statement correctly), you actually agree that it is not a  
compiler problem.
The "it" refers to the string$String (Unfortunately you did not quote that  
part) function. Hence the problem is in the library and _not_ in the  
compiler.
And if you agree to my quoted "Hence ..." statement, you also agree that  
the compiler correctly uses (FiWord) "abc" to refer to string literals.

> | >  Not that -fwritable-strings has
> | > disappears.
> |
> | Still "removing the -fwritable-strings" triggered the problem.
>
> Don't confuse the medium with the message.  If you use
> -fwritable-strings, you're expected to have a grasp of what it does,
> i.e. have read the documentation.  Failure to read the documentation
> is no excuse. -fwritable-strings is not the cause of the problem, it
> does not triggered the problem.

So you assume, the Aldor people did not read the documentation ... then  
they had a very, very lucky guess when they wrote "-fwritable-strings" :)
The man of gcc (the one I use with aldor) page says:
  -fwritable-string
   Store string constants in the writable data segment and don't uniquize  
them.  This is for compatibility with old programs which assume they can  
write into string constants.

This perfectly fits the need of Aldor. Doesn't it? Where is the problem.  
Of course it also says
    Writing into string constants is a very bad idea; ``constants''
    should be constant.
    This option is deprecated.

But that only means "Use it only if you really need it, and you probably  
won't find it in future versions".

> It *exposes an existing problem.*

Assuming the Aldor compiler's sole purpose is to fit the C standard you  
chose today. Yes.
If they'd chose this from the start, they wouldn't have relied on writable  
strings in first place.

--
Kind regards,
Christian