[Aldor-l] Compiling setup

[Gabriel Dos Reis]

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

[...]

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

[...]

| > | > "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.
| 
| According to the Aldor programming language (which is not entangled
| with  the library Aldor), I am very sure, it is valid.

Good.

[...]

| I do not think, the String translation is wrong, but the initialization.
| I'll probably have to step down a bit to show you why. Down to the
| more  gory parts of Aldor -- it's C translation.
| (hopefully you noted the "something equivalent" in my previous mail)
| because that is very important.

I hoped you understood that I was talking of "equivalent" translation,
but apparently it was  misplaced hope.

[...]

| 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. :-/

| >  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.  It *exposes an existing problem.*

[...]

| > | > 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.
| 
| I fully agree. But I am not in charge of the language.
| I never claimed, that I like the generated code...
| The only thing I claimed is, that you oversimplified the problem and
| that  I do not think the compiler is the main problem.

Stephen seems to say the problem is not as simple as it strikes eyes
and may need fixing that is not just on the library side. 

-- Gaby