From tmgisi at gmx.at  Tue Aug  1 03:00:21 2006
From: tmgisi at gmx.at (Christian Aistleitner)
Date: Tue, 01 Aug 2006 09:00:21 +0200
Subject: [Aldor-l] Current version of Aldor
Message-ID: <op.tdle2vu0u6j4vy@spencer.aistleitner.info>

Hello,

in a private Email I have been asked, about the current version of Aldor.  
As it probably apllies to other people as well, I decided to answer to the  
list.

As of today (2006-08-01), I guesss the current version is 1.0.3 (quietly  
released some manths ago), although the homepage claims the current  
version is 1.0.2.

You can download 1.0.3 via the aldor homepage -- Just try to download  
Aldor and you'll get a file carrying 1.0.3 in the filename.
Quick Link:
http://www.aldor.org/downl.html

--
Kind regards,
Christian


From tmgisi at gmx.at  Tue Aug  1 03:52:17 2006
From: tmgisi at gmx.at (Christian Aistleitner)
Date: Tue, 01 Aug 2006 09:52:17 +0200
Subject: [Aldor-l] Reading from stdin
Message-ID: <op.tdlhhfkyu6j4vy@spencer.aistleitner.info>

Hello,

in a private Email I have been asked, about reading from stdin. As it  
probably applies to other people as well, I decided to answer to the list.

The naive approach via

#include "aldor"

import from TextReader;
import from TextWriter;
import from String;
import from Character;

local str: String := << stdin;

stdout << "Received: " << str << newline;

Gives problems, as it does not necessarily give the whole line:

____________________________________________
tmgisi at spencer
cwd: ~
$ LC_ALL=C /opt/aldor/bin/aldor -M no-abbrev -C args=-Wopts=-m32 -Ffm \
-Fx -lalgebra -laldor test2.as && ( echo 3/4 | ./test2 )
cc1: note: -fwritable-strings is deprecated; see documentation for details
cc1: note: -fwritable-strings is deprecated; see documentation for details
Received: 3


You'll have to use quotes to achive this:

____________________________________________
tmgisi at spencer
cwd: ~
$ LC_ALL=C /opt/aldor/bin/aldor -M no-abbrev -C args=-Wopts=-m32 -Ffm \
-Fx -lalgebra -laldor test2.as && ( echo \"3/4\" | ./test2 )
cc1: note: -fwritable-strings is deprecated; see documentation for details
cc1: note: -fwritable-strings is deprecated; see documentation for details
Received: 3/4

Forcing users to quote things is nasty. For the CharSet library I used the  
following function:

readString():String == {
	import from Character;
	import from MachineInteger;

	local ret : String := empty;
	local ch : Character;
	
	ch := <<$Character stdin;
	while ch ~= newline repeat
	{
		ret := ret + ch::String;
		ch := <<$Character stdin;
	}
	ret;
}

It reads _every_ character until a newline occurs. The returned string  
does not contain a trailing newline:

____________________________________________
tmgisi at spencer
cwd: ~
$ LC_ALL=C /opt/aldor/bin/aldor -M no-abbrev -C args=-Wopts=-m32 -Ffm -Fx  
-lalgebra -laldor test3.as && ( echo 3/4 | ./test3 )
cc1: note: -fwritable-strings is deprecated; see documentation for details
cc1: note: -fwritable-strings is deprecated; see documentation for details
Received: 3/4

On systems with suitable readline support (Every 32-bit GNU/Linux system  
should do), you can use something like:

#include "aldor"

import from TextReader;
import from TextWriter;
import from String;
import from Character;

Readline: with {
     (<<): ( prompt: String == "" ) -> String;
} == add {

     import {
	readline: String -> String;
     } from Foreign C;

     (<<)( prompt ): String == {
	readline( prompt );
     }
}

import from Readline;

local str: String := <<();

stdout << "Received: " << str << newline;


to take advantage readline. I could not test the readline snippet, as I do  
not have 32-bit version of readline -- still waiting for 64-bit Aldor.

--
Kind regards,
Christian



From ldragan at uwo.ca  Thu Aug  3 15:41:45 2006
From: ldragan at uwo.ca (Laurentiu Dragan)
Date: Thu, 03 Aug 2006 15:41:45 -0400
Subject: [Aldor-l] Announcement: www.aldor.org updates
Message-ID: <44D25179.9030106@uwo.ca>

Hi,

I have made two additions to www.aldor.org:

1. the FOAM reference manual in the documentation page

2. a compiler for the older Linux distributions (glibc 2.2).

--
Laurentiu


From antoine.hersen at gmail.com  Fri Aug  4 08:48:02 2006
From: antoine.hersen at gmail.com (Antoine Hersen)
Date: Fri, 4 Aug 2006 14:48:02 +0200
Subject: [Aldor-l] Mac version
Message-ID: <c281860e0608040548i2d1c11ct72dad312db4767b7@mail.gmail.com>

Hello,

I will like to know if it will be possible to have a Mac OSX/PPC version of
the Aldor compiler ?

XCode ship with gcc4.0 and 3.3.

I will be happy to help if needed.


Regards,
Antoine Hersen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://aldor.org/pipermail/aldor-l_aldor.org/attachments/20060804/4b83a783/attachment.html 

From bill.page1 at synthesis.anikast.ca  Mon Aug  7 11:52:58 2006
From: bill.page1 at synthesis.anikast.ca (Bill Page)
Date: Mon, 7 Aug 2006 11:52:58 -0400
Subject: [Aldor-l] Mac version
In-Reply-To: <c281860e0608040548i2d1c11ct72dad312db4767b7@mail.gmail.com>
Message-ID: <00d101c6ba39$94661ca0$6900a8c0@asus>

Antoine,

On August 4, 2006 8:48 AM you wrote to Laurentiu Dragan
aldor-l at aldor.org

> I will like to know if it will be possible to have a Mac OSX/PPC
> version of the Aldor compiler ?
>
> XCode ship with gcc4.0 and 3.3.
>
> I will be happy to help if needed.

My experience is that aldor.org does not really have sufficient
resources to support multiple versions of Aldor on different
platforms. For example, there is no current Windows version of
Aldor either.

Of course all of this would change immediately if/when Aldor
is licensed as open source. But while we continue to wait for
that much anticipated event, you might want to proceed anyway by
working with the currently closed sources. As explained at
http://aldor.org this source code is available on request.
I compiled an x64 version of Aldor from these sources. See

http://wiki.axiom-developer.org/Aldor

Regards,
Bill Page.




From pcr at pcrt.com  Thu Aug 10 18:39:21 2006
From: pcr at pcrt.com (PCR)
Date: Thu, 10 Aug 2006 16:39:21 -0600
Subject: [Aldor-l] Compiling setup
Message-ID: <44DBB599.2020100@pcrt.com>

I was trying a first problem in Aldor, and got this result.  Mayhap I 
set things up wrong?  Thanks for any help.

pcr1 at Delta:~/aldor$ aldor -fx -laldor sieve.as
cc1: error: unrecognized command line option "-fwritable-strings"
#1 (Fatal Error) C compile failed.  Command was: unicl 
-I/usr/local/aldor/linux/1.0.3/include -c sieve.c
#1 (Warning) Removing file `sieve.c'






From Bill.Page at drdc-rddc.gc.ca  Thu Aug 10 20:16:45 2006
From: Bill.Page at drdc-rddc.gc.ca (Page, Bill)
Date: Thu, 10 Aug 2006 20:16:45 -0400
Subject: [Aldor-l] Compiling setup
In-Reply-To: <44DBB599.2020100@pcrt.com>
Message-ID: <CAE9B164E720CE4D8727792DF8F28AE376742F@corporateex02.Corporate.drdc-rddc.gc.ca>

On Thursday, August 10, 2006 6:39 PM PCR wrote:
> 
> I was trying a first problem in Aldor, and got this result.
> Mayhap I set things up wrong?  Thanks for any help.
> 
> pcr1 at Delta:~/aldor$ aldor -fx -laldor sieve.as
> cc1: error: unrecognized command line option "-fwritable-strings"
> #1 (Fatal Error) C compile failed.  Command was: unicl 
> -I/usr/local/aldor/linux/1.0.3/include -c sieve.c
> #1 (Warning) Removing file `sieve.c'
> 

You don't say what computer and version of operating
system you are using (you should in any error report or
request for help), but the problem seems to be that you
are using a version of the gcc C compiler that is "too new".

The -fx option tells Aldor to compile a native C runtime
program but the curent version of the Aldor compiler
generated intermediate C code that will only work with
a C compiler that supports "writable strings". Newer
versions of C (since gcc 4.0) do not support modification
of string constants.

You can revert to an earlier version of C.

It is also possible to get around this limitation by
compiling to intermediate lisp and then using a lisp
compiler such as GCL that works with the newer C compilers.

Regards,
Bill Page.



From gdr at integrable-solutions.net  Thu Aug 10 20:56:00 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 11 Aug 2006 02:56:00 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <44DBB599.2020100@pcrt.com>
References: <44DBB599.2020100@pcrt.com>
Message-ID: <m38xlwoztr.fsf@zeus.integrable-solutions.net>

PCR <pcr at pcrt.com> writes:

| I was trying a first problem in Aldor, and got this result.  Mayhap I 
| set things up wrong?  Thanks for any help.
| 
| pcr1 at Delta:~/aldor$ aldor -fx -laldor sieve.as
| cc1: error: unrecognized command line option "-fwritable-strings"

I suspect you must be using a recent version of GCC -- the Aldor
configuration file that ships with the RPM is for a very old GCC.  
What you have to do is that you need to modify the variable gcc-hacks
from section [gcc] of /usr/local/aldor/linux/1.0.3/aldor.conf
not to include -fwritable-strings.  There is an obscure comment about
why that flags is needed.  

Mine now reads:

  # On some platforms string literals are stored in read-only segments.
  # This causes problems when users write Aldor programs in which a
  # string literal is used as a buffer. The result is a segfault that
  # is extremely hard to track down, even for experienced Aldor coders.
  # GDR: Well, either that is a bug in Aldor, or a bug in those experienced
  # GDR: aldor coders' programs.  At any rate, that option is no
  # longer supported.
  #  gcc-hacks = -fwritable-strings
     gcc-hacks = 

-- Gaby


From gdr at integrable-solutions.net  Thu Aug 10 20:57:21 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 11 Aug 2006 02:57:21 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <CAE9B164E720CE4D8727792DF8F28AE376742F@corporateex02.Corporate.drdc-rddc.gc.ca>
References: <CAE9B164E720CE4D8727792DF8F28AE376742F@corporateex02.Corporate.drdc-rddc.gc.ca>
Message-ID: <m33bc4ozri.fsf@zeus.integrable-solutions.net>

"Page, Bill" <Bill.Page at drdc-rddc.gc.ca> writes:

[...]

| You can revert to an earlier version of C.

For many people, that is not an option.

-- Gaby


From Bill.Page at drdc-rddc.gc.ca  Thu Aug 10 21:13:38 2006
From: Bill.Page at drdc-rddc.gc.ca (Page, Bill)
Date: Thu, 10 Aug 2006 21:13:38 -0400
Subject: [Aldor-l] Compiling setup
In-Reply-To: <m38xlwoztr.fsf@zeus.integrable-solutions.net>
Message-ID: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>

On Thursday, August 10, 2006 8:56 PM Gabriel Dos Reis wrote:

> ...
> What you have to do is that you need to modify the variable
> gcc-hacks from section [gcc] of /usr/local/aldor/linux/
> 1.0.3/aldor.conf not to include -fwritable-strings.  There
> is an obscure comment about why that flags is needed.  
> 
> Mine now reads:
> 
>   # On some platforms string literals are stored in read-only 
>     segments.
>   # This causes problems when users write Aldor programs in
>     which a
>   # string literal is used as a buffer. The result is a
>     segfault that
>   # is extremely hard to track down, even for experienced 
>     Aldor coders.
>   # GDR: Well, either that is a bug in Aldor, or a bug in 
>     those experienced
>   # GDR: aldor coders' programs.  At any rate, that option
>     is no
>   # longer supported.
>   #  gcc-hacks = -fwritable-strings
>      gcc-hacks = 
> 

Rather than "bug" I think it would be more fair to call
this a "design flaw"... :)

Does your change to aldor.conf actually work?? If so great!
But this does contradict a statement made recently by one
of (the only?) Aldor compiler developer here on this list.
How much testing have you done?

I presumed that the gcc developers removed rewritable-strings
because this "feature" of the C language is no longer
supported -- not just because they are "purists", right? ;)
So if Aldor can generate C code that violates this restriction,
it is probably not such a good idea to remove this "gcc-hack"
until the Aldor developers say it is no longer required. No?

Regards,
Bill Page.



From gdr at integrable-solutions.net  Thu Aug 10 21:46:47 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 11 Aug 2006 03:46:47 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
Message-ID: <m3ejvo2ge0.fsf@zeus.integrable-solutions.net>

"Page, Bill" <Bill.Page at drdc-rddc.gc.ca> writes:

| On Thursday, August 10, 2006 8:56 PM Gabriel Dos Reis wrote:
| 
| > ...
| > What you have to do is that you need to modify the variable
| > gcc-hacks from section [gcc] of /usr/local/aldor/linux/
| > 1.0.3/aldor.conf not to include -fwritable-strings.  There
| > is an obscure comment about why that flags is needed.  
| > 
| > Mine now reads:
| > 
| >   # On some platforms string literals are stored in read-only 
| >     segments.
| >   # This causes problems when users write Aldor programs in
| >     which a
| >   # string literal is used as a buffer. The result is a
| >     segfault that
| >   # is extremely hard to track down, even for experienced 
| >     Aldor coders.
| >   # GDR: Well, either that is a bug in Aldor, or a bug in 
| >     those experienced
| >   # GDR: aldor coders' programs.  At any rate, that option
| >     is no
| >   # longer supported.
| >   #  gcc-hacks = -fwritable-strings
| >      gcc-hacks = 
| > 
| 
| Rather than "bug" I think it would be more fair to call
| this a "design flaw"... :)

Sorry, I can't call it a "design flaw" :-)

| Does your change to aldor.conf actually work?? If so great!

For the little programs I've tried, yes it *seems* to work.
It is either that, or no Aldor program at all. 

| But this does contradict a statement made recently by one
| of (the only?) Aldor compiler developer here on this list.
| How much testing have you done?

| I presumed that the gcc developers removed rewritable-strings
| because this "feature" of the C language is no longer
| supported -- not just because they are "purists", right? ;)

it never was a "feature" of the C language.  

The C language explicitly says that it is undefined behaviour to modify
string literals.  For many reasons, including security, it is
better for the compiler to honor the spirit and the letter of the C
definition: literal strings cannot be modified.

| So if Aldor can generate C code that violates this restriction,
| it is probably not such a good idea to remove this "gcc-hack"
| until the Aldor developers say it is no longer required. No?

I don't quite understand why this really is a problem.  Surely, one
can have string buffers in C programs.  So, why is it that Aldor needs
the buffer to be *string literal*?  That sounds to me like an internal
logical inconsistency.  The generated program cannot be correct.


>From the C standard, section "6.4.5  String literals"
      
       [...]

       [#6] It is unspecified whether  these  arrays  are  distinct
       provided their elements have the appropriate values.  If the
       program attempts to modify such an array,  the  behavior  is
       undefined.


-- Gaby


From ralf at hemmecke.de  Fri Aug 11 03:46:14 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Fri, 11 Aug 2006 09:46:14 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <CAE9B164E720CE4D8727792DF8F28AE376742F@corporateex02.Corporate.drdc-rddc.gc.ca>
References: <CAE9B164E720CE4D8727792DF8F28AE376742F@corporateex02.Corporate.drdc-rddc.gc.ca>
Message-ID: <44DC35C6.1010003@hemmecke.de>

See

http://article.gmane.org/gmane.comp.lang.aldor/10/match=fwritable+strings
Date: 2005-02-08 19:48:53 GMT (1 year, 26 weeks, 1 day, 5 hours and 51 
minutes ago)

In a recent mail from one of the Aldor maintainers (which unfortunately 
wasn't copied to aldor-l) I can read

   All I said is that aldor cannot use the new version of the GNU C
   compiler because FSF decided to create the string literals as
   read-only.  Because of this, aldor no longer works with gcc 4 and
   above.  I tried again to compile aldor with gcc 4 and after some
   "standard compliance" changes I managed to compile the compiler, but
   it failed to compile the aldor runtime.  If it would have been a
   simple change to replace the writable literals (like the suggested
   char a[] ="a"), it would have been done by now.  If you look at the
   comments related to gcc-hacks in aldor.conf, you will see that it was
   used to avoid a bug.

There is still some bug in the Aldor compiler sources, and unfortunately 
we must wait until the sources are open to fix that.

Ralf


From ralf at hemmecke.de  Fri Aug 11 04:05:34 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Fri, 11 Aug 2006 10:05:34 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <CAE9B164E720CE4D8727792DF8F28AE376742F@corporateex02.Corporate.drdc-rddc.gc.ca>
References: <CAE9B164E720CE4D8727792DF8F28AE376742F@corporateex02.Corporate.drdc-rddc.gc.ca>
Message-ID: <44DC3A4E.9090601@hemmecke.de>

See http://www.aldor.org/faqs.html
When I compile an Aldor source file, it doesn't find gcc32?

It says:
Answer:Aldor compiler is not compatible with latest version of gcc 
(version 4). New linux distributions use version 4 of gcc as the default 
C compiler. If that is the case in your distribution, using gcc will not 
work. That is the reason we replaced gcc with gcc32 in aldor.conf. If 
you use an older Linux distribution you should comment those two lines 
from aldor.conf that contain gcc32. The current setting should work for 
Fedora Core 4 and 5, for other linux distributions find the name of the 
older C compiler and use that instead of gcc32.

Ralf


From ralf at hemmecke.de  Fri Aug 11 04:25:07 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Fri, 11 Aug 2006 10:25:07 +0200
Subject: [Aldor-l] automatic dependency generation was: Re:
	[Axiom-developer] lattice
In-Reply-To: <m3lkpw2h83.fsf@zeus.integrable-solutions.net>
References: <200608101947.k7AJlx4K011635@axiom-developer.org>
	<m3lkpw2h83.fsf@zeus.integrable-solutions.net>
Message-ID: <44DC3EE3.8060802@hemmecke.de>

> A project might be to have the compiler output spad dependencies --
> just like GCC is able to output dependencies, which greatly
> facilitates the tedious part of writing Makefiles and keeping them in
> sync; Automake uses it.

That would be a nice feature, but even if it probably will not happen 
that often, Aldor's "extend" might complicate that process (I don't say 
it makes it impossible).

Look at the files given below.
My intention is to compile them via

--aldor         aaaf1.as;  ar rv libmyprj.al aaaf1.ao;  rm aaaf1.ao
--aldor -lmyprj aaaf2.as;  ar rv libmyprj.al aaaf2.ao;  rm aaaf2.ao
--aldor -lmyprj aaaf3.as;  ar rv libmyprj.al aaaf3.ao;  rm aaaf3.ao

Assume the compiler first gets aaaf3.as. It sees either #library or 
"extend" and gives up, since no library is existing.
So it takes aaaf2.as and delays it for the same reason.
It can, however, compile aaaf1.as. Fine. But it really has to produce 
the .ao file and the library in order to be able to go on. So it is not 
just a lightweight compilation without producing code.
Then it starts again by looking at aaaf3.as. No compilation possible, 
since the function "bar" cannot be found. Now, is this just because 
there is a spelling mistake in "bar" or because the compiler has not yet 
seen aaaf2.as? OK, the compiler delays aaaf3.as and compiles aaaf2.as 
(with which options?). That works. Again the compiler must produce code 
so that aaaf3.as can compile.

One can easily setup several more extensions and finding the 
dependencies just explodes combinatorially.

A simple workaround would be to introduce a CONVENTION. One library may 
only extend a domain once. If there is need to extend another time, then 
that should happen in another library. In this way one gets a (more or 
less) natural layered structure and the library structure becomes easier 
to understand for a human.

There already happen several "extend"s in libalgebra (distributed with 
Aldor) and it is quite hard to find your way through the sources. One 
constantly has to check what the Makefile says.

Ralf

---BEGIN aaaf1.as
#include "aldor"
define CatA: Category == with {foo: () -> ()}
Dom: with {foo: () -> ()} == add {foo(): () == {}}
---END aaaf1.as

---BEGIN aaaf2.as
#include "aldor"
#library MyPrj "myprj"
import from MyPrj
extend Dom with {bar: () -> ()} == add {bar(): () == foo()}
---END aaaf2.as

---BEGIN aaaf3.as
#include "aldor"
#library MyPrj "myprj"
import from MyPrj
extend Dom with {ans: () -> ()} == add {ans(): () == bar()}
---END aaaf3.as


From tmgisi at gmx.at  Fri Aug 11 05:59:26 2006
From: tmgisi at gmx.at (Christian Aistleitner)
Date: Fri, 11 Aug 2006 11:59:26 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
Message-ID: <op.td351cpau6j4vy@spencer.aistleitner.info>

Hello,

On Fri, 11 Aug 2006 03:46:47 +0200, Gabriel Dos Reis  
<gdr at integrable-solutions.net> wrote:

> "Page, Bill" <Bill.Page at drdc-rddc.gc.ca> writes:
>
> | On Thursday, August 10, 2006 8:56 PM Gabriel Dos Reis wrote:
> |
> | > ...
> | > What you have to do is that you need to modify the variable
> | > gcc-hacks from section [gcc] of /usr/local/aldor/linux/
> | > 1.0.3/aldor.conf not to include -fwritable-strings.  There
> | > is an obscure comment about why that flags is needed.
> | >
> | > Mine now reads:
> | >
> | >   # On some platforms string literals are stored in read-only
> | >     segments.
> | >   # This causes problems when users write Aldor programs in
> | >     which a
> | >   # string literal is used as a buffer. The result is a
> | >     segfault that
> | >   # is extremely hard to track down, even for experienced
> | >     Aldor coders.
> | >   # GDR: Well, either that is a bug in Aldor, or a bug in
> | >     those experienced
> | >   # GDR: aldor coders' programs.  At any rate, that option
> | >     is no
> | >   # longer supported.
> | >   #  gcc-hacks = -fwritable-strings
> | >      gcc-hacks =
> | >
> |
[...]
>
> | Does your change to aldor.conf actually work?? If so great!
>
> For the little programs I've tried, yes it *seems* to work.
> It is either that, or no Aldor program at all.

Just consider the attached test.as. It does just the dangerous thing (as  
described in the aldor.conf) -- modifying an Aldor String constant.  
Consider the following output with writable strings:

____________________________________________
tmgisi at spencer
cwd: ~/aldor
$ grep gcc-hacks.*= /opt/aldor/include/aldor.conf ; LC_ALL=C  
/opt/aldor/bin/aldor \
-M no-abbrev -C args=-Wopts=-m32 -Fx -laldor test.as && ./test
   gcc-hacks = -fwritable-strings
cc1: note: -fwritable-strings is deprecated; see documentation for details
cc1: note: -fwritable-strings is deprecated; see documentation for details
abcdefghij
abcXefghij

And now without writable strings

____________________________________________
tmgisi at spencer
cwd: ~/aldor
$ grep gcc-hacks.*= /opt/aldor/include/aldor.conf ; LC_ALL=C  
/opt/aldor/bin/aldor \
-M no-abbrev -C args=-Wopts=-m32 -Fx -laldor test.as && ./test
   gcc-hacks =
abcdefghij
Speicherzugriffsfehler


So at least for this simple file, it does not work. Of course you can  
rewrite the Aldor code to make it work. The provided test.as shows  
"-fwritable-strings" is not just a relict in the aldor.conf file, but it  
is actually needed.

*Please* do *not* omit "-fwritable-strings", for your own sake.
Instead:
1. get an old enough compiler (wherever this is possible), so you can  
compile the programs and
2. keep mocking about the issue.

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.

On another layer the test.as's "abcdefghij" is a constant. However,  
implicitly, the constant is fed to the
   string: Literal -> String
function from the String domain. Actually (ignoring the implementation of  
the string function), the constant "abcdefghij" is not used directly, but  
only the result of passing the constant to a function is used and modified  
via "a.3". (Of course, due to the implementation of string$String,  
"abcdefghij" and the variable a are the same thing, but that's a different  
issue) So shouldn't string$String declare it generates memory aliases?

The question is about "What is considered bad style?".
aldor.conf explicitly deals with the issue of whether string literals are  
read-only or not, so I doubt that Aldor compiler developers consider it  
bad style.


--
Kind regards,
Christian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.as
Type: application/octet-stream
Size: 182 bytes
Desc: not available
Url : http://aldor.org/pipermail/aldor-l_aldor.org/attachments/20060811/cb4d178f/attachment.obj 

From gdr at integrable-solutions.net  Fri Aug 11 06:52:33 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 11 Aug 2006 12:52:33 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <op.td351cpau6j4vy@spencer.aistleitner.info>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
Message-ID: <m3u04j8rym.fsf@zeus.integrable-solutions.net>

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


You are however correct that, given that the erroneous translation
(from the only compiler available) is known  and documented, it is not
just bad style but actually a programming error.


"a" above is not a constant -- or else the language could have
forbidden its modification.  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. 

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

If you initialize an integer variable with the integer literal 1, and
you subsequently modify that variable to hold 2, do you expect the aldor
compiler to pretend that the *integer literal 1* is actually 2?

[...]

| The question is about "What is considered bad style?".
| aldor.conf explicitly deals with the issue of whether string literals
| are  read-only or not, so I doubt that Aldor compiler developers
| consider it  bad style.

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

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

-- Gaby


From pcr at pcrt.com  Fri Aug 11 15:25:34 2006
From: pcr at pcrt.com (PCR)
Date: Fri, 11 Aug 2006 13:25:34 -0600
Subject: [Aldor-l] Compiling setup
In-Reply-To: <CAE9B164E720CE4D8727792DF8F28AE376742F@corporateex02.Corporate.drdc-rddc.gc.ca>
References: <CAE9B164E720CE4D8727792DF8F28AE376742F@corporateex02.Corporate.drdc-rddc.gc.ca>
Message-ID: <44DCD9AE.5040507@pcrt.com>

Page, Bill wrote:
> On Thursday, August 10, 2006 6:39 PM PCR wrote:
>   
>> I was trying a first problem in Aldor, and got this result.
>> Mayhap I set things up wrong?  Thanks for any help.
>>
>> pcr1 at Delta:~/aldor$ aldor -fx -laldor sieve.as
>> cc1: error: unrecognized command line option "-fwritable-strings"
>> #1 (Fatal Error) C compile failed.  Command was: unicl 
>> -I/usr/local/aldor/linux/1.0.3/include -c sieve.c
>> #1 (Warning) Removing file `sieve.c'
>>
>>     
>
> You don't say what computer and version of operating
> system you are using (you should in any error report or
> request for help), but the problem seems to be that you
> are using a version of the gcc C compiler that is "too new".
>
> The -fx option tells Aldor to compile a native C runtime
> program but the curent version of the Aldor compiler
> generated intermediate C code that will only work with
> a C compiler that supports "writable strings". Newer
> versions of C (since gcc 4.0) do not support modification
> of string constants.
>
> You can revert to an earlier version of C.
>
> It is also possible to get around this limitation by
> compiling to intermediate lisp and then using a lisp
> compiler such as GCL that works with the newer C compilers.
>
> Regards,
> Bill Page.
>
>
>   
I am trying the detour. aldor -flsp -laldor sieve.as gave me a file 
sieve.lsp. Running gcl and typing (load "sieve.lsp") at the promt gave me:

 >(load "sieve.lsp")

Loading sieve.lsp

Error: "FOAM" is not of type (OR SYMBOL STRING ...).
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by IN-PACKAGE.
Broken at IN-PACKAGE. Type :H for Help.
 >>

This has to be my mistake somehow!



From bill.page1 at synthesis.anikast.ca  Sat Aug 12 01:47:15 2006
From: bill.page1 at synthesis.anikast.ca (Bill Page)
Date: Sat, 12 Aug 2006 01:47:15 -0400
Subject: [Aldor-l] Compiling setup
In-Reply-To: <44DCD9AE.5040507@pcrt.com>
Message-ID: <021801c6bdd2$d7833580$6900a8c0@asus>

On August 11, 2006 3:26 PM PCR wrote:
> 
> Bill Page wrote:
> > ...
> > It is also possible to get around this limitation by
> > compiling to intermediate lisp and then using a lisp
> > compiler such as GCL that works with the newer C compilers.
> >

> I am trying the detour. aldor -flsp -laldor sieve.as gave me a
> file sieve.lsp. Running gcl and typing (load "sieve.lsp") at the 
> promt gave me:
> 
>  >(load "sieve.lsp")
> 
> Loading sieve.lsp
> 
> Error: "FOAM" is not of type (OR SYMBOL STRING ...).
> Fast links are on: do (si::use-fast-links nil) for debugging
> Error signalled by IN-PACKAGE.
> Broken at IN-PACKAGE. Type :H for Help.
>  >>
> 
> This has to be my mistake somehow!
> 

I am sorry that I mislead you about how easy this was to do.
It turns out that although Aldor can compile to lisp, apparently
there is currently no stand alone runtime environment for lisp
like the C runtime library for Aldor. :( I was sure I actually
had an example of Aldor used with GCL this way at one time, but
I can't seem to find it now. )

There is however a lisp runtime for running Aldor inside Axiom.

See the example here:

http://wiki.axiom-developer.org/SandBoxAldorSieve

Note that the example has to be changed a little to be compatible
with the Axiom library.

It is also possible to use Aldor outside of Axiom as described
here:

http://www.aldor.org/docs/HTML/chap18.html#12

to compile Aldor to lisp code. Then you just need Axiom to compile
and run the lisp code:

  $ AXIOMsys
  (1) -> )compile sieve.lsp
  (1) -> sieve 2000

But in the current binary distribution of Axiom+Aldor to get
stand alone Aldor to compile for Axiom, you most copy the file
libaxiom.al from Axiom .../mnt/linux/algebra/libaxiom.al to
...aldor/linux/1.0.3/lib

And all of this will work on a linux system with an up to date
gcc compiler.

I hope this helps.

Regards,
Bill Page.




From tmgisi at gmx.at  Sat Aug 12 06:20:57 2006
From: tmgisi at gmx.at (Christian Aistleitner)
Date: Sat, 12 Aug 2006 12:20:57 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <m3u04j8rym.fsf@zeus.integrable-solutions.net>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
Message-ID: <op.td51o72eu6j4vy@spencer.aistleitner.info>

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


From gdr at integrable-solutions.net  Sat Aug 12 09:24:08 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 12 Aug 2006 15:24:08 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <op.td51o72eu6j4vy@spencer.aistleitner.info>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
Message-ID: <m3slk22ikn.fsf@zeus.integrable-solutions.net>

"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



From watt at scl.csd.uwo.ca  Sat Aug 12 10:19:42 2006
From: watt at scl.csd.uwo.ca (Stephen Watt)
Date: Sat, 12 Aug 2006 10:19:42 -0400
Subject: [Aldor-l] Compiling setup
In-Reply-To: <m3slk22ikn.fsf@zeus.integrable-solutions.net>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
Message-ID: <20060812141942.GA30663@ptibonum.scl.csd.uwo.ca>

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


From gdr at integrable-solutions.net  Sat Aug 12 10:39:47 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 12 Aug 2006 16:39:47 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <20060812141942.GA30663@ptibonum.scl.csd.uwo.ca>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<20060812141942.GA30663@ptibonum.scl.csd.uwo.ca>
Message-ID: <m37j1enhl8.fsf@zeus.integrable-solutions.net>

Stephen Watt <watt at scl.csd.uwo.ca> writes:

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

Many thanks!

I hope there will be a version for GNU/Linux systems working with the
most current glibc (e.g. glibc-2.4 and higher).

-- Gaby


From ralf at hemmecke.de  Sat Aug 12 12:32:49 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Sat, 12 Aug 2006 18:32:49 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <op.td51o72eu6j4vy@spencer.aistleitner.info>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>	<op.td351cpau6j4vy@spencer.aistleitner.info>	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
Message-ID: <44DE02B1.4030704@hemmecke.de>

Christian's mail was quite hard to read due to strange line breaks, but 
I think he made an important point. If the compiler sees something like

   "blah"

in general it is even impossible to guess the type of that thing.

See my posts to axiom-developer from
14-Feb-2005 (Subject: "The symbol 4 (was Re: Aldor and Axiom)") and
22-Feb-2006 (Subject: "1: %").

Or simply let me repeat the program...

---file crazy.as--
#include "aldor"
CrazyInteger: IntegerType with {string: Literal -> %} == Integer add {
     Rep == Integer;
     import from Rep;
     integer(l: Literal): % == per(integer(l)$Integer + 1);
     string(l: Literal): % == per 42;
}

main(): () == {
     import from TextWriter, Character;
     import from CrazyInteger;
     stdout << "This is crazy :" << space << 1 << newline;
     stdout << "This is crazy :" << space << 2 << newline;
     stdout << "Fourtytwo" + 4 << newline;
}

main();
---end crazy.as

For me it says.
 >aldor -grun -laldor crazy.as
42 1
42 3
47

I cannot believe that Christian meant:
 >   local litA: Literal := "abcdefghij";    -- (*)
should be translated to
 >   char * litA = "abcdefghij";

First of all, the line (*) does not compile at all with libaldor. And I 
even don't know of a way to create a thing of type Literal.
And also the C code is probably not right.

As I see it, the things of type Literal are the true constants, since 
they cannot change as they are character strings that appear in the .as 
file. The type String, however, is a library thing (as Christian pointed 
out). Now, how a literal constant appears as a string is completely up 
to the library. So I guess, we are actually talking about whether or not
things of type Literal should be put into a non-writable data section by 
the compiler.

You should not be misled by the fact that a library (like libaldor) 
provides a type String. And the Aldor library, makes it implicitly clear 
that strings are writeable, by providing a function

   set!: (String, MachineInteger, Character) -> String

So if the (future) compiler puts literals into read-only memory, then 
the library definition

   string(l:Literal):% == string(l pretend Pointer);

is the bug and must be changed.

Ralf


From ralf at hemmecke.de  Sat Aug 12 12:57:31 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Sat, 12 Aug 2006 18:57:31 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <m3slk22ikn.fsf@zeus.integrable-solutions.net>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>	<op.td351cpau6j4vy@spencer.aistleitner.info>	<m3u04j8rym.fsf@zeus.integrable-solutions.net>	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
Message-ID: <44DE087B.6040904@hemmecke.de>

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

I consider it bad style! But probably for another reason. It contains a 
syntax error. Christian should have written

local a:String := "abc";

or

local a:String == "abc";

In the first case, modification should be allowed. In the second it 
would be quite questionable. But then

a.3 := char "X";

is the same as

set!(a, 3, char "X);

It's a BANG function and by convention destructive so one might expect 
strange behaviour even if a is a constant.

It becomes interesting to ask what the semantics of the following 
program should be.

---BEGIN aaavarconst.as
#include "aldor"
a: String := "a";   c: String == "c";
b: String := "a";   d: String == "c"
a.1 := char "X";    c.1 := char "Y";
---END aaavarconst.as

Clearly one expects b = "a". But would be d="Y" also be OK?

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

Hmm, until someone proves me wrong, I would claim that String is not 
part of the Aldor language. And it is also not a part of the runtime. It 
is defined in the Aldor library "libaldor". And I don't count libaldor 
as part of the compiler stuff.

Ralf


From gdr at integrable-solutions.net  Sat Aug 12 13:08:43 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 12 Aug 2006 19:08:43 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <44DE02B1.4030704@hemmecke.de>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<44DE02B1.4030704@hemmecke.de>
Message-ID: <m3d5b5hof8.fsf@zeus.integrable-solutions.net>

Ralf Hemmecke <ralf at hemmecke.de> writes:

| Christian's mail was quite hard to read due to strange line breaks, but 
| I think he made an important point. If the compiler sees something like
| 
|    "blah"
| 
| in general it is even impossible to guess the type of that thing.

To my eyes, that is a literal string.

[...]

| I cannot believe that Christian meant:
|  >   local litA: Literal := "abcdefghij";    -- (*)
| should be translated to
|  >   char * litA = "abcdefghij";
| 
| First of all, the line (*) does not compile at all with libaldor. And I 
| even don't know of a way to create a thing of type Literal.
| And also the C code is probably not right.

Why would  the C code not right?

[...]

| You should not be misled by the fact that a library (like libaldor) 
| provides a type String. And the Aldor library, makes it implicitly clear 
| that strings are writeable, by providing a function
| 
|    set!: (String, MachineInteger, Character) -> String
| 
| So if the (future) compiler puts literals into read-only memory, then 
| the library definition
| 
|    string(l:Literal):% == string(l pretend Pointer);
| 
| is the bug and must be changed.

That is essentially the difference betweenn

   char *litA = "abcdefghij";

and

   char strA[] = "abcdefghij";

litA points to a storage where resides string literal.  strA is an
array whose elementss  can be freely modified.

The first morally corresponds to Literal, and the second to String.

All major programming languages I know of that provide a modifiable
string type behave correctly when a string is initialized with a literal.

-- Gaby


From gdr at integrable-solutions.net  Sat Aug 12 13:45:43 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 12 Aug 2006 19:45:43 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <44DE087B.6040904@hemmecke.de>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<44DE087B.6040904@hemmecke.de>
Message-ID: <m3veoxg854.fsf@zeus.integrable-solutions.net>

Ralf Hemmecke <ralf at hemmecke.de> 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*.
| 
| I consider it bad style! But probably for another reason. It contains
| a syntax error.

:-)

| Christian should have written
| 
| local a:String := "abc";
| 
| or
| 
| local a:String == "abc";
| 
| In the first case, modification should be allowed.

OK.

| In the second it would be quite questionable.

You can't define a programming language semantics in terms of
"questionable".  You have to say whether it is well-formed with
well-defined behaviour, or it has no defined behaviour.  If the latter,
we just declare the program is ill-formed.  In a strongly typed
language, it is an error that should be either caught at compile time 
or at runtime.

| But then
| 
| a.3 := char "X";
| 
| is the same as
| 
| set!(a, 3, char "X);
| 
| It's a BANG function and by convention destructive so one might expect
| strange behaviour even if a is a constant.

So back to my question: Is is a well-formed program with well-defined
behavior?  That is all that counts.  I can't compute the behavior of
a program with consideration like "bad style" -- the computer does not
know that.

[...]

| > 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.
| 
| Hmm, until someone proves me wrong, I would claim that String is not
| part of the Aldor language. And it is also not a part of the
| runtime. It is defined in the Aldor library "libaldor". And I don't
| count libaldor as part of the compiler stuff.

That is a fine distinction.  However, it does not work in practice: I
can't test any useful program coming with the AUG without having
libaldor.   AUG says, page 12:

   #include "aldor" is the general include statement that will allow
   the types and functions from libaldor to be visible. It is
   necessary to use it (or an equivalent library) in order to write
   programs. 



For all practical purposes, libaldor is part of the compiler.  You can
distinguish the front-end from the supporting runtime system, but you
cannot usefully, meaningfully, and practically dissociate it from the
compiler. 

Among other languages that have tried similar distinctions, you will
find the C programming language.  The C programming language defines
two families of C implementations:

   * freestanding implementations, and
   * hosted implementations.

A freestanding implementation is one where you don't necessarily have
_all_ of the C library (you may view GCC/gcc as a freestanding
implementation, but the actual issue is more complicated than that).
In a freestanding implementation, the function "main()" is not
required for starting up the program (it is up to the implementation).

A hosted implementation is one which is required to provide all of the
C library and the function "main()" is required as entry point.  You
may view GCC/gcc as not being a hosted implementation.  However, the
actual issue is more complicated than that.  For example, GCC/gcc in a
non-freestanding-mode assumes that any symbol with external linkage
that is also defined by the C standard library actually has the
semantics of the C library.  It thus proceed to apply many
transformations and optimizations based on the standard semantics.
As you see, GCC/gcc does not provide you with a C library but it does
assume all standard semantics and acts as if the runtime library is
part of it.  That, in effect, mirrors the spirit of the standard.

>From my other experience contributing to implement the C++ standard
library, we (the libstdc++ team) have come to appreciate that there is
no absolute meaningful way to separate the compiler from the runtime
support systems.  Here, I won't spend time on the pains my
co-maintainers and I went through.

Granted, all of the above examples come from personal experience so
may constitute biased examples, but you can see that they started out
as distinguishing between the "pure" compiler and the supporting
runtime system.  It is a theory that does not work well in practice.
The runtime system has to make assumptions about the front-end, andthe
front-end has to make assumptions about the library.  Of course, we
all want those set of assumptions to be as minimal as possible.

I was quite happy to see that the Aldor distribution did not get into
that trap.

Even if you succeeded in providing an alternate, independent,
implementation of libaldor, it will still remain as an essential part
needed to have any useful Aldor program running.  It is

-- Gaby


From ralf at hemmecke.de  Sat Aug 12 16:26:55 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Sat, 12 Aug 2006 22:26:55 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <m3d5b5hof8.fsf@zeus.integrable-solutions.net>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>	<op.td351cpau6j4vy@spencer.aistleitner.info>	<m3u04j8rym.fsf@zeus.integrable-solutions.net>	<op.td51o72eu6j4vy@spencer.aistleitner.info>	<44DE02B1.4030704@hemmecke.de>
	<m3d5b5hof8.fsf@zeus.integrable-solutions.net>
Message-ID: <44DE398F.1070005@hemmecke.de>

> | If the compiler sees something like
> | 
> |    "blah"
> | 
> | in general it is even impossible to guess the type of that thing.

> To my eyes, that is a literal string.

That seems to be true, but what does "literal string" actually mean?

It is definitely not something of the libaldor type String (my base 
library might be something else where String does not even exist). And 
as you saw from the program I gave, it could mean the Integer 4.

I guess the Aldor type Literal is probably the closest we can get.

> |  >   char * litA = "abcdefghij";

> Why would  the C code not right?

>    char *litA = "abcdefghij";
>    char strA[] = "abcdefghij";

> litA points to a storage where resides string literal.  strA is an
> array whose elementss  can be freely modified.

Sorry, my knowledge of C is mainly non-existing.

> All major programming languages I know of that provide a modifiable
> string type behave correctly when a string is initialized with a literal.

I think the libaldor type String ought to do that. But as I said, I 
actually don't consider String as part of the Aldor language.

Ralf


From ralf at hemmecke.de  Sat Aug 12 17:25:36 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Sat, 12 Aug 2006 23:25:36 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <m3veoxg854.fsf@zeus.integrable-solutions.net>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>	<op.td351cpau6j4vy@spencer.aistleitner.info>	<m3u04j8rym.fsf@zeus.integrable-solutions.net>	<op.td51o72eu6j4vy@spencer.aistleitner.info>	<m3slk22ikn.fsf@zeus.integrable-solutions.net>	<44DE087B.6040904@hemmecke.de>
	<m3veoxg854.fsf@zeus.integrable-solutions.net>
Message-ID: <44DE4750.9070704@hemmecke.de>

> | local a:String == "abc";
> | In the second it would be quite questionable.
... what the value of a is after assignment
    a.3 := char "X";

> You can't define a programming language semantics in terms of
> "questionable".

I did not define the language. In fact, what I wanted to say is, that I 
know how the current compiler behaves in that case, but not how the 
Aldor language defines it.

 > You have to say whether it is well-formed with
> well-defined behaviour, or it has no defined behaviour.  If the latter,
> we just declare the program is ill-formed.  In a strongly typed
> language, it is an error that should be either caught at compile time 
> or at runtime.

> | But then
> | 
> | a.3 := char "X";
> | 
> | is the same as
> | 
> | set!(a, 3, char "X);
> | 
> | It's a BANG function and by convention destructive so one might expect
> | strange behaviour even if a is a constant.

For the compiler the above assignment is syntactic sugar for the 
function call to set!. That destructive functions should have a name 
that ends in ! is a convention that is not known to the compiler. So I 
guess a compiler would have hard times to figure out that

set!(a, 3, char "X)

actually modifies the constant a. Am I wrong? I guess, that is the 
reason why the Aldor compiler doesn't try. I think the program is 
well-formed (sorry I am not really familiar with this concept), but its 
behaviour is probably undefined. set! is a side effecting function that 
modifies something in memory that is related to its first argument.

I cannot say that I like it very much if I cannot rely on the fact that 
a constant is constant. But on the other hand, using a BANG function 
warns me that I cannot rely on what strange side effect I get.

Just being curious... is there a legal C program that defines a constant 
array, and a pointer (or whatever) to on element of that array and then 
modifies that entry in-place? If that is possible then there would be 
non-constant constants in C.

> | > 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.
> | 
> | Hmm, until someone proves me wrong, I would claim that String is not
> | part of the Aldor language. And it is also not a part of the
> | runtime. It is defined in the Aldor library "libaldor". And I don't
> | count libaldor as part of the compiler stuff.
> 
> That is a fine distinction.  However, it does not work in practice: I
> can't test any useful program coming with the AUG without having
> libaldor.

Yes, you can. Take axllib. That also ships with the Aldor compiler and 
also has a type which is called String. You probably guess rightly that
String$LibAldor is not the same as String$AxlLib. Of course they are 
quite similar. As a library writer you would not want to confuse people 
too much.

Or, if you like, take libaxiom... yet another String type.

If you look at the sources you find that the representation of String is

PackedPrimitiveArray Character

in libaldor and BArr in axllib. One can certainly track down what
PackedPrimitiveArray or BArr is in terms of more primitive types of 
FOAM, but you see, String is a library thing.

In fact, I quite like that Aldor has a quite limited set of things that 
are built into the language.

> For all practical purposes, libaldor is part of the compiler.  You can
> distinguish the front-end from the supporting runtime system, but you
> cannot usefully, meaningfully, and practically dissociate it from the
> compiler. 

Hmm, when I came in contact with Aldor, I compiled against libaxiom. 
Since I realised that the compilation took too long and there was a 
light-weight library that was sufficient for me, I compiled against 
axllib. Then Bronstein wrote salli (standard aldor library) which is 
different from and incompatible with axllib. Salli basically became 
libaldor (after a few modifications). That is the history of the basic 
libraries of Aldor. I really cannot say that I believe that the compiler 
and this library are too attached. And if the libaldor and libalgebra 
don't become free enough, I'll think about writing my own GPL'ed one.

> Among other languages that have tried similar distinctions, you will
> find the C programming language.

[...]

>>From my other experience contributing to implement the C++ standard
> library, we (the libstdc++ team) have come to appreciate that there is
> no absolute meaningful way to separate the compiler from the runtime
> support systems.  Here, I won't spend time on the pains my
> co-maintainers and I went through.

Oh, please... I am all for standards. And I would even like to have a 
standard aldor library that is open source, well tested and a literate 
program, but still, I would call it a library. It is not part of the 
actual (aldor) language.

If you call libaldor "runtime system", OK, but currently it is not.
libaldor is shipped with the compiler, but for example in order to 
extend Axiom, you can happily do it without libaldor. (You even must do 
it without libaldor.) So if we end up with a standard aldor library and 
remove all the mess of the currently existing base libraries, I am all 
for it. If that even results in better optimization, the better.

> I was quite happy to see that the Aldor distribution did not get into
> that trap.

Hmm, really? Do you take libaldor.al or libaxllib.al? They are both 
provided with the compiler. ;-)

Ralf


From ldragan at aldor.org  Sat Aug 12 18:46:38 2006
From: ldragan at aldor.org (ldragan at aldor.org)
Date: Sat, 12 Aug 2006 18:46:38 -0400
Subject: [Aldor-l] Compiling setup
In-Reply-To: <20060812141942.GA30663@ptibonum.scl.csd.uwo.ca>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<20060812141942.GA30663@ptibonum.scl.csd.uwo.ca>
Message-ID: <20060812224638.GA5946@aquarium.aldor.org>

On Sat, Aug 12, 2006 at 10:19:42AM -0400, Stephen Watt wrote:
> The Aldor compiler does indeed need to be fixed to not rely on
> implementation dependencies of the C compiler in this respect.

I think this issue should be fixed in the library.  The Aldor compiler
only deals with literals, which are constant like in C.  The library
implementing String should know that string literals are constant
and either make them constant or copy them when a new String is
initialized.

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

The solution proposed by Christian is very reasonable and
should work with the current compiler.

--
Laurentiu



From watt at scl.csd.uwo.ca  Sat Aug 12 18:55:29 2006
From: watt at scl.csd.uwo.ca (Stephen Watt)
Date: Sat, 12 Aug 2006 18:55:29 -0400
Subject: [Aldor-l] Compiling setup
In-Reply-To: <20060812224638.GA5946@aquarium.aldor.org>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<20060812141942.GA30663@ptibonum.scl.csd.uwo.ca>
	<20060812224638.GA5946@aquarium.aldor.org>
Message-ID: <20060812225529.GC11239@ptibonum.scl.csd.uwo.ca>

Laurentiu, I think there is more to this than meets the eye.

The Aldor system developers are not the only ones to write libraries -- 
the compiler should have correct behaviour for any legitimate Aldor code
and not break depending on the underlying C compiler.

-- Stephen


On Sat, Aug 12, 2006 at 06:46:38PM -0400, ldragan at aldor.org wrote:
> On Sat, Aug 12, 2006 at 10:19:42AM -0400, Stephen Watt wrote:
> > The Aldor compiler does indeed need to be fixed to not rely on
> > implementation dependencies of the C compiler in this respect.
> 
> I think this issue should be fixed in the library.  The Aldor compiler
> only deals with literals, which are constant like in C.  The library
> implementing String should know that string literals are constant
> and either make them constant or copy them when a new String is
> initialized.
> 
> > 
> > We will look into this without waiting until the open source release.
> 
> The solution proposed by Christian is very reasonable and
> should work with the current compiler.
> 
> --
> Laurentiu


From gdr at integrable-solutions.net  Sat Aug 12 20:02:25 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 13 Aug 2006 02:02:25 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <44DE4750.9070704@hemmecke.de>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<44DE087B.6040904@hemmecke.de>
	<m3veoxg854.fsf@zeus.integrable-solutions.net>
	<44DE4750.9070704@hemmecke.de>
Message-ID: <m37j1da4fi.fsf@zeus.integrable-solutions.net>

Ralf Hemmecke <ralf at hemmecke.de> writes:

| > | local a:String == "abc";
| > | In the second it would be quite questionable.
| ... what the value of a is after assignment
|     a.3 := char "X";

Stephen gave me an explanation and if I did understand correctly, that
assignment is also OK.

[...]

| Just being curious... is there a legal C program that defines a
| constant array, and a pointer (or whatever) to on element of that
| array and then modifies that entry in-place?

If I understand the question correctly, the answer is "no".

[...]

| > I was quite happy to see that the Aldor distribution did not get into
| > that trap.
| 
| Hmm, really? 

Yes, for all practical pruposes, I find the distinction artificial.

-- Gaby


From gdr at integrable-solutions.net  Sat Aug 12 20:15:52 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 13 Aug 2006 02:15:52 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <44DE398F.1070005@hemmecke.de>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<44DE02B1.4030704@hemmecke.de>
	<m3d5b5hof8.fsf@zeus.integrable-solutions.net>
	<44DE398F.1070005@hemmecke.de>
Message-ID: <m31wrla3t3.fsf@zeus.integrable-solutions.net>

Ralf Hemmecke <ralf at hemmecke.de> writes:

| > | If the compiler sees something like
| > | |    "blah"
| > | | in general it is even impossible to guess the type of that thing.
| 
| > To my eyes, that is a literal string.
| 
| That seems to be true, but what does "literal string" actually mean?

s/literal string/string literal/

The meaning is whatever the Aldor definition says it is.  See section
5.2, page 38.

| It is definitely not something of the libaldor type String (my base
| library might be something else where String does not even exist). And
| as you saw from the program I gave, it could mean the Integer 4.

I appreciate all that.  The issue under discussion, is what should be
the proper translation of 

    a : String == "vlndoffmnelcfeeqmeejfoie";

into C.

| I guess the Aldor type Literal is probably the closest we can get.

The way literals are treated in Aldor is not very different from what
Haskell does for integer literals for example.  If you're not happy
with the appearant type "string literal", you can view it as having
type (borrowing notation from Haskell):

    "blah" : forall a. () -> a

-- Gaby


From tmgisi at gmx.at  Sun Aug 13 03:01:53 2006
From: tmgisi at gmx.at (Christian Aistleitner)
Date: Sun, 13 Aug 2006 09:01:53 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <m37j1enhl8.fsf@zeus.integrable-solutions.net>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<20060812141942.GA30663@ptibonum.scl.csd.uwo.ca>
	<m37j1enhl8.fsf@zeus.integrable-solutions.net>
Message-ID: <op.td7m5fu7u6j4vy@spencer.aistleitner.info>

Hello,

On Sat, 12 Aug 2006 16:39:47 +0200, Gabriel Dos Reis  
<gdr at integrable-solutions.net> wrote:

> I hope there will be a version for GNU/Linux systems working with the
> most current glibc (e.g. glibc-2.4 and higher).

I am puzzled ... is there already some glibc-2.5 or glibc-3.0? According to
http://www.gnu.org/software/libc/
glibc-2.4 is the current version of glibc.

I have glibc-2.4 installed on my gentoo box (and no glibc-2.3 or other  
version of glibc) and it just works very well with aldor.
I know that on the webpage, you can only download the aldor compiler for  
glibc-2.3 (and glibc-2.2) for GNU/Linux OSes.
Is it a coincidence that everything works with glibc-2.4, or is it  
supposed to work (and the webpage provides wrong information once again)?

Did anyone experience difficulties using glibc-2.4 with Aldor?

____________________________________________
tmgisi at spencer
cwd: ~/aldor
$ ldd `which aldor`
         linux-gate.so.1 =>  (0xffffe000)
         libm.so.6 => /lib32/libm.so.6 (0xf7f42000)
         libc.so.6 => /lib32/libc.so.6 (0xf7e25000)
         /lib/ld-linux.so.2 (0xf7f89000)

____________________________________________
tmgisi at spencer
cwd: ~/aldor
$ ls -l /lib32/libc.so.6
lrwxrwxrwx 1 root root 11  1. Aug 13:02 /lib32/libc.so.6 -> libc-2.4.so*

--
Kind regards,
Christian



From tmgisi at gmx.at  Sun Aug 13 03:28:20 2006
From: tmgisi at gmx.at (Christian Aistleitner)
Date: Sun, 13 Aug 2006 09:28:20 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <44DE02B1.4030704@hemmecke.de>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<44DE02B1.4030704@hemmecke.de>
Message-ID: <op.td7odiypu6j4vy@spencer.aistleitner.info>

Hello,

> ---file crazy.as--
> #include "aldor"
> CrazyInteger: IntegerType with {string: Literal -> %} == Integer add {
>      Rep == Integer;
>      import from Rep;
>      integer(l: Literal): % == per(integer(l)$Integer + 1);
>      string(l: Literal): % == per 42;
> }
>
> main(): () == {
>      import from TextWriter, Character;
>      import from CrazyInteger;
>      stdout << "This is crazy :" << space << 1 << newline;
>      stdout << "This is crazy :" << space << 2 << newline;
>      stdout << "Fourtytwo" + 4 << newline;
> }
>
> main();
> ---end crazy.as
>
> For me it says.
>  >aldor -grun -laldor crazy.as
> 42 1
> 42 3
> 47

Just what I'd expect... Nothing fancy or crazy from my point of view.

> I cannot believe that Christian meant:
>  >   local litA: Literal := "abcdefghij";    -- (*)
> should be translated to
>  >   char * litA = "abcdefghij";
>
> First of all, the line (*) does not compile at all with libaldor. And I
> even don't know of a way to create a thing of type Literal.
> And also the C code is probably not right.

However, it really *is* what I meant. The line (*) compiles very well.  
However, the compiler does not allow to use Literal directly. Every  
Literal has to be converted using a string, integer, ... function. I  
omittet it for brevity, but consider
   #include "aldor"
   string( l: Literal ): Literal == l;
   local litA: Literal := "abcdefghij";
. It compiles and runs without any problems...
I cannot see any problems in the Aldor code I gave (of course I did not  
specify the string function, but the mail was about conversion of a  
Literal to C code. Therefore, I considered the trivial string function not  
necessary to jot down.).
Just as Gaby, I cannot see any problems with the C code.

Are there any open issues with the code I gave?

> So if the (future) compiler puts literals into read-only memory, then
> the library definition
>
>    string(l:Literal):% == string(l pretend Pointer);
>
> is the bug and must be changed.

Ja. Just as I said before.

--
Kind regards,
Christian



From tmgisi at gmx.at  Sun Aug 13 04:46:14 2006
From: tmgisi at gmx.at (Christian Aistleitner)
Date: Sun, 13 Aug 2006 10:46:14 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <m3slk22ikn.fsf@zeus.integrable-solutions.net>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
Message-ID: <op.td7rzcytu6j4vy@spencer.aistleitner.info>

Hello,

On Sat, 12 Aug 2006 15:24:08 +0200, Gabriel Dos Reis  
<gdr at integrable-solutions.net> wrote:

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

Yes. And indeed I like the way gcc handles the issue. No doubt about that.  
Nevertheless:

True is: gcc changed its behaviour in this part.

> | Faulty user source code:
[...]
> | 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".
We do not have a grammar of the Aldor language used by the current Aldor  
compiler. So it's hard to discuss validity ...
To me it is valid, as the compiler swallows it and produces working code  
with old enough gccs.


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

Never heard a preacher talking about bad style ;)

> Either a construct is well-defined and have a meaning, or it does not.

I assume it is well-defined from the compiler point of view.
a of type String is assigned the value of applying string$String to the  
literal "abc".
No syntax problems.
No *compiler* semantics problem.
It also has a well defined meaning for the compiler.

> 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.
When working with bleeding edge software, you are often in the situation  
that some of your libraries are too new to work with other tools.
However, typically things get sorted out over time as new versions go  
mainstream.
For Aldor the problem is known for *some* time and it is still not solved.
However, if Aldor tells you "your compiler is too new" it is you not  
meeting their requirements.

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

I am not comparing apples and oranges.
The C program defines this behaviour to be undefined.
The string$String functions behaviour is not defined.
This gives an undefined behaviour in both cases.

However, the semantics of the Aldor program is well defined from the  
compiler point of view, as described above. From the library point of view  
it is not.
So it might be, it is not a compiler problem, but a library problem.

And I do not consider it to be wrong to use functions that work but are  
not documented well enough. However, I might consider it bad style to use  
them.

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

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

Good thing.

> The failure is translated String
> properly is the cause of the error.

And the agreement ends here :(
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.
Did you actually ever try to read the C code generated from Aldor?
Aldor does not care about what domain is represented in C code. (Mostly)  
everything is represented by FiWord -- which is unsigned long int. These  
FiWords are used as pointers to the data structures of interest.
(You might mock about lacking type information and improper use of  
"unsigned long int", but that's not important right now -- Besides I would  
join you if you camplain about it.)
Strings are represented by FiWord as well. So defining a variable to be of  
type String, gives you a FiWord -- So no specification of whether char *  
or char ..[] is meant. The Literal "abcdefghij" is passed as (FiWord)  
"abcdefghij" to the string$String function. So the string$String function  
cannot control whether or not the Literal is in read-only memory or not.
However, it is supposed to return a character sequence in read-write  
memory. (Note the "supposed", as the semantics of the stirng$String  
function, mapping a Literal to a String, is not defined). Hence it must  
_not_ simply return the (FiWord) "abcdefghij" but has to assure, it uses  
read-write memory.

>  Not that -fwritable-strings has
> disappears.

Still "removing the -fwritable-strings" triggered the problem.
Nevertheless I strongly agree, that Aldor should never have relied on  
gcc's behaviour, as it is undefined. I defended this position against  
Aldor compiler people some time ago. So we are both on the same side.

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

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

IIRC I read some complaints, back when it has been decided, that  
writable-strings is not the way to go. These things mostly occur in legacy  
code...
But the problem should have been dealt with years ago. No doubt.
But whining about these issues helps no one. The Aldor people agree that  
there is a problem with current gccs. And they are working on making  
things work for current gcc for some months now (at least some months ago,  
a compiler developer told me, he's working on it).

We should help them to track the problem down and fix it.

--
Kind regards,
Christian


From tmgisi at gmx.at  Sun Aug 13 04:47:20 2006
From: tmgisi at gmx.at (Christian Aistleitner)
Date: Sun, 13 Aug 2006 10:47:20 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <44DE087B.6040904@hemmecke.de>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<44DE087B.6040904@hemmecke.de>
Message-ID: <op.td7r06aeu6j4vy@spencer.aistleitner.info>

Hello,

>> | 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*.
>
> I consider it bad style! But probably for another reason. It contains a
> syntax error. Christian should have written
>
> local a:String := "abc";
>
> or
>
> local a:String == "abc";

Sorry for that. Of course I meant it in the spirit of my previous mails,  
so my intention has been:
  local a:String := "abc";
.

--
Kind regards,
Christian



From tmgisi at gmx.at  Sun Aug 13 05:38:11 2006
From: tmgisi at gmx.at (Christian Aistleitner)
Date: Sun, 13 Aug 2006 11:38:11 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <m3veoxg854.fsf@zeus.integrable-solutions.net>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<44DE087B.6040904@hemmecke.de>
	<m3veoxg854.fsf@zeus.integrable-solutions.net>
Message-ID: <op.td7udxt0u6j4vy@spencer.aistleitner.info>

Hello,

> | In the second it would be quite questionable.
>
> You can't define a programming language semantics in terms of
> "questionable".  You have to say whether it is well-formed with
> well-defined behaviour, or it has no defined behaviour.  If the latter,
> we just declare the program is ill-formed.  In a strongly typed
> language, it is an error that should be either caught at compile time
> or at runtime.


Ok, omit terms like "bad style" and "questionable". The following code is  
a nice and cosy C program (for my compiler on my machine ... see below):

#include <stdio.h>
int main( int argc, char * argv[] )
{
   char str0[]="QRST";
   char str1[]="ABCDEFGHIJKLMNO";
   str1[strlen(str1)]='P';
   printf( "%s\n", str1 );
   return 0;
}

. Its not very portable -- but portable is again one of those vague term.  
We do not use it. It's a valid C program (for this gcc an my machine).  
Seeing my intention, I am sure you guessed the output

____________________________________________
tmgisi at spencer
cwd: ~/aldor
$ nano test.c && gcc -o test test.c && ./test
ABCDEFGHIJKLMNOPQRST

on my machine
____________________________________________
tmgisi at spencer
cwd: ~/aldor
$ gcc --version
x86_64-pc-linux-gnu-gcc (GCC) 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0,  
pie-8.7.9)
Copyright (C) 2006 Free Software Foundation, Inc.
Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es
gibt KEINE Garantie; auch nicht f?r VERKAUFBARKEIT oder F?R SPEZIELLE  
ZWECKE.

____________________________________________
tmgisi at spencer
cwd: ~/aldor
$ uname -a
Linux spencer 2.6.16-gentoo-r8 #1 Sun Jul 23 06:47:56 CEST 2006 x86_64 AMD  
Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux

I relied on several specifics of the compiled code, which you can  
(probably) not find in the C specification or is defined to give undefined  
behaviour. Yet it works. So it's more than valid to use on *this* gcc on  
*my* machine. It's not portable. It's not robust. I would not want to use  
such code and consider it "bad style" although it's valid code for *this*  
gcc on *my* machine.
I would not want to use such code, but you do not want to reason in those  
vague terms -- You should be more than happy to use that code with *this*  
gcc on *my* machine.

Maybe this example showed you, that the issue is also related to what you  
choose as reference. I chose "C as accepted by my gcc on my machine".  
Aldor did not choose the current C specification, but maybe the "C as  
accepted by (the then current) gcc".

> | > 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.
> |
> | Hmm, until someone proves me wrong, I would claim that String is not
> | part of the Aldor language. And it is also not a part of the
> | runtime. It is defined in the Aldor library "libaldor". And I don't
> | count libaldor as part of the compiler stuff.
>
> That is a fine distinction.  However, it does not work in practice: I
> can't test any useful program coming with the AUG without having
> libaldor.   AUG says, page 12:
>
>    #include "aldor" is the general include statement that will allow
>    the types and functions from libaldor to be visible. It is
>    necessary to use it (or an equivalent library) in order to write
>    programs.

There are equivalent libraries. I wrote one myself when experimenting with  
the semantics of Aldor's categories. In my base library, the domain  
Category had a completely different signature. I did not have a domain  
String at all.

Compare it to C++ and the STL. You can code C++ without using the STL.  
Admittedly, you'd have a rough start without using STL.
You can compile Java sources with either Sun's library or the GNU  
Classpath.

It is a crucial point to separate the language from the base library. I  
really love the Aldor language, but I do not like the aldor library at all.

> For all practical purposes, libaldor is part of the compiler.

No. What about the Axiom people using the Aldor compiler? What about  
BasicMath?
(I have not worked yot with Axiom using the Aldor compiler. Someone who  
has may please correct me if I am wrong)

> You can
> distinguish the front-end from the supporting runtime system, but you
> cannot usefully, meaningfully, and practically dissociate it from the
> compiler.

I fully agree that the runtime system is closely coupled with the  
compiler. But the Aldor library is _not_ part of the runtime system.

The aldor library is not part of the Run-time System. Aldor's runtime  
system has types like HInt and SInt and expects Category and Type to be  
some domain valued constants (to give an example of the connection between  
the front-end and the run-time system).
But the Aldor library is not in the scope of this. The Aldor libarry is  
separated from the run-time system.

--
Kind regards,
Christian


From tmgisi at gmx.at  Sun Aug 13 05:52:01 2006
From: tmgisi at gmx.at (Christian Aistleitner)
Date: Sun, 13 Aug 2006 11:52:01 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <m37j1da4fi.fsf@zeus.integrable-solutions.net>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<44DE087B.6040904@hemmecke.de>
	<m3veoxg854.fsf@zeus.integrable-solutions.net>
	<44DE4750.9070704@hemmecke.de>
	<m37j1da4fi.fsf@zeus.integrable-solutions.net>
Message-ID: <op.td7u0zpuu6j4vy@spencer.aistleitner.info>

Hello,

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

> Ralf Hemmecke <ralf at hemmecke.de> writes:
>
> | > | local a:String == "abc";
> | > | In the second it would be quite questionable.
> | ... what the value of a is after assignment
> |     a.3 := char "X";
>
> Stephen gave me an explanation and if I did understand correctly, that
> assignment is also OK.

sadly enough, this seems to have been a private discussion and has not  
been posted to aldor-l -- Or did I miss it?

> [...]
>
> | Just being curious... is there a legal C program that defines a
> | constant array, and a pointer (or whatever) to on element of that
> | array and then modifies that entry in-place?
>
> If I understand the question correctly, the answer is "no".

For those being not familiar with C or C++:
These languages also provide a modifier const (just doing what its name  
suggests), which Aldor (currently) lacks.

--
Kind regards,
Christian



From tmgisi at gmx.at  Sun Aug 13 06:06:13 2006
From: tmgisi at gmx.at (Christian Aistleitner)
Date: Sun, 13 Aug 2006 12:06:13 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <20060812225529.GC11239@ptibonum.scl.csd.uwo.ca>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<20060812141942.GA30663@ptibonum.scl.csd.uwo.ca>
	<20060812224638.GA5946@aquarium.aldor.org>
	<20060812225529.GC11239@ptibonum.scl.csd.uwo.ca>
Message-ID: <op.td7vonx2u6j4vy@spencer.aistleitner.info>

Hello Stephen,

On Sun, 13 Aug 2006 00:55:29 +0200, Stephen Watt <watt at scl.csd.uwo.ca>  
wrote:

> Laurentiu, I think there is more to this than meets the eye.

you are probably right. We cannot judge, as we do not have access to the  
sources.
However, according to the AUG, a Literal is a constant. According to the  
discussion, we all agree constants are correctly modelled by
   char * str = "my_fancy_literal".
To my understanding, this is basically, what Aldor does at the moment.  
This is a sound behaviour -- No one wants to change the representation of  
string literals.

The aldor library currently assumes that the literal is in a read-write  
memory location and can be modified in-place. Assuming that a constant  
(i.e.: the literal) is in read-write memory is a bad choice. Assuming to  
modify a constant in-place is even further off.
However, the aldor library should/has to assure that the returned value is  
in read-write memory.
Its no big deal to implement this behaviour in the string$String function  
by adding a "copy" (as I showed).

> The Aldor system developers are not the only ones to write libraries --
> the compiler should have correct behaviour for any legitimate Aldor code
> and not break depending on the underlying C compiler.

If other libraries make the same assumption, it should be the problem of  
these libraries, and not of the Aldor compiler.

The current compiler has correct behaviour for legitimate Aldor code.  
However, the aldor library makes assumptions that do not hold for current  
gccs.

However, we cannot inspect the run-time system. Maybe there the assumption  
can be found as well...

--
Kind regards,
Christian



From ralf at hemmecke.de  Sun Aug 13 07:32:56 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Sun, 13 Aug 2006 13:32:56 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <op.td7u0zpuu6j4vy@spencer.aistleitner.info>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<44DE087B.6040904@hemmecke.de>
	<m3veoxg854.fsf@zeus.integrable-solutions.net>
	<44DE4750.9070704@hemmecke.de>
	<m37j1da4fi.fsf@zeus.integrable-solutions.net>
	<op.td7u0zpuu6j4vy@spencer.aistleitner.info>
Message-ID: <44DF0DE8.80609@hemmecke.de>

>> | Just being curious... is there a legal C program that defines a
>> | constant array, and a pointer (or whatever) to on element of that
>> | array and then modifies that entry in-place?
>>
>> If I understand the question correctly, the answer is "no".
> 
> For those being not familiar with C or C++:
> These languages also provide a modifier const (just doing what its name 
> suggests), which Aldor (currently) lacks.

Ooops. What is then

str: String == anotherString;

supposed to mean?

Ralf


From ralf at hemmecke.de  Sun Aug 13 07:40:03 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Sun, 13 Aug 2006 13:40:03 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <m31wrla3t3.fsf@zeus.integrable-solutions.net>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>	<op.td351cpau6j4vy@spencer.aistleitner.info>	<m3u04j8rym.fsf@zeus.integrable-solutions.net>	<op.td51o72eu6j4vy@spencer.aistleitner.info>	<44DE02B1.4030704@hemmecke.de>	<m3d5b5hof8.fsf@zeus.integrable-solutions.net>	<44DE398F.1070005@hemmecke.de>
	<m31wrla3t3.fsf@zeus.integrable-solutions.net>
Message-ID: <44DF0F93.6050700@hemmecke.de>

> I appreciate all that.  The issue under discussion, is what should be
> the proper translation of 
> 
>     a : String == "vlndoffmnelcfeeqmeejfoie";
> 
> into C.

That completely depends on how you define the type String (in a library) 
and how the function

string: Literal -> String

is implemented in that library. Without a library the compiler has to 
reject that line, since it is not Aldor code (String is not known).

Ralf


From gdr at integrable-solutions.net  Sun Aug 13 09:30:27 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 13 Aug 2006 15:30:27 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <op.td7m5fu7u6j4vy@spencer.aistleitner.info>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<20060812141942.GA30663@ptibonum.scl.csd.uwo.ca>
	<m37j1enhl8.fsf@zeus.integrable-solutions.net>
	<op.td7m5fu7u6j4vy@spencer.aistleitner.info>
Message-ID: <m3wt9c4vbg.fsf@zeus.integrable-solutions.net>

"Christian Aistleitner" <tmgisi at gmx.at> writes:

| Hello,
| 
| On Sat, 12 Aug 2006 16:39:47 +0200, Gabriel Dos Reis
| <gdr at integrable-solutions.net> wrote:
| 
| > I hope there will be a version for GNU/Linux systems working with the
| > most current glibc (e.g. glibc-2.4 and higher).
| 
| I am puzzled ... is there already some glibc-2.5 or glibc-3.0? According to
| http://www.gnu.org/software/libc/
| glibc-2.4 is the current version of glibc.

Yes, glibc-2.4 is the currently released version.  However, I don't
know how long it will take to produce a new Aldor compiler.  My hope
is that when it is released it will work with the most recently
released glibc (maybe 2.4, if it is soon, or higher it takes at least
six months).

| I have glibc-2.4 installed on my gentoo box (and no glibc-2.3 or other
| version of glibc) and it just works very well with aldor.
| I know that on the webpage, you can only download the aldor compiler
| for  glibc-2.3 (and glibc-2.2) for GNU/Linux OSes.
| Is it a coincidence that everything works with glibc-2.4, or is it
| supposed to work (and the webpage provides wrong information once
| again)?

Is there any reason to believe that there need to be two different
versions: one for glibc-2.2, and another for glibc-2.3, but everything
should be OK with higher versions of glibc?

-- Gaby


From gdr at integrable-solutions.net  Sun Aug 13 09:44:22 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 13 Aug 2006 15:44:22 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <op.td7u0zpuu6j4vy@spencer.aistleitner.info>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<44DE087B.6040904@hemmecke.de>
	<m3veoxg854.fsf@zeus.integrable-solutions.net>
	<44DE4750.9070704@hemmecke.de>
	<m37j1da4fi.fsf@zeus.integrable-solutions.net>
	<op.td7u0zpuu6j4vy@spencer.aistleitner.info>
Message-ID: <m3r6zk4uo9.fsf@zeus.integrable-solutions.net>

"Christian Aistleitner" <tmgisi at gmx.at> writes:

| Hello,
| 
| On Sun, 13 Aug 2006 02:02:25 +0200, Gabriel Dos Reis
| <gdr at integrable-solutions.net> wrote:
| 
| > Ralf Hemmecke <ralf at hemmecke.de> writes:
| >
| > | > | local a:String == "abc";
| > | > | In the second it would be quite questionable.
| > | ... what the value of a is after assignment
| > |     a.3 := char "X";
| >
| > Stephen gave me an explanation and if I did understand correctly, that
| > assignment is also OK.
| 
| sadly enough, this seems to have been a private discussion and has not
| been posted to aldor-l -- Or did I miss it?

You're correct that it was a private message.  He just reminded me
that since a is defined as

    a : String == "abc";

therefore with type String, and a String is modifiable, the
modification 

  a.3 := char "X" 

is OK.

| > [...]
| >
| > | Just being curious... is there a legal C program that defines a
| > | constant array, and a pointer (or whatever) to on element of that
| > | array and then modifies that entry in-place?
| >
| > If I understand the question correctly, the answer is "no".
| 
| For those being not familiar with C or C++:
| These languages also provide a modifier const (just doing what its
| name  suggests), which Aldor (currently) lacks.

OK, let me expand a little bit on this.

First of all, K&R lacks "const" -- it was an invention for "C with
Classes" (the precursor of C++) that the ANSI C committee adopted
later, sadly with a slightly different semantics.  However, given

     char *a = "hqdfnoioffe";

you can't modify what a points to -- though you're free to modify the
pointer a.  Notice that no const is involved there.

The reason is that in C, therefore in C++, modifiability really is a 
*property of the object*, not just that of the expression used to
access the object.  However, you are right that C++ does enforce those
properties more often than C by lifting most of them directly into the
static semantics.  For example the string literal

   "hqdfnoioffe"

has type

   const char[12]

in C++. The proper way to write the above declaration in C++ is

     const char *a = "hqdfnoioffe";

However, the declaration

     char *a = "hqdfnoioffe";

is also accepted for C-compatibility reasons, but deprecated.  The
semantics however remains that you can't modify what a points to.

-- Gaby


From gdr at integrable-solutions.net.integrable-solutions.net  Sun Aug 13 10:00:04 2006
From: gdr at integrable-solutions.net.integrable-solutions.net (Gabriel Dos Reis)
Date: 13 Aug 2006 16:00:04 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <op.td7udxt0u6j4vy@spencer.aistleitner.info>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<44DE087B.6040904@hemmecke.de>
	<m3veoxg854.fsf@zeus.integrable-solutions.net>
	<op.td7udxt0u6j4vy@spencer.aistleitner.info>
Message-ID: <m3lkps4ty3.fsf@zeus.integrable-solutions.net>

"Christian Aistleitner" <tmgisi at gmx.at> writes:

[...]

| #include <stdio.h>
| int main( int argc, char * argv[] )
| {
|    char str0[]="QRST";
|    char str1[]="ABCDEFGHIJKLMNO";
|    str1[strlen(str1)]='P';
|    printf( "%s\n", str1 );
|    return 0;
| }
| 
| . Its not very portable -- but portable is again one of those vague
| term.  We do not use it. It's a valid C program (for this gcc an my
| machine).

What makes you believe that is a valid C program?  It invokes
undefined behaviour.  From there you can prove everything you want.

[...]

| Maybe this example showed you, that the issue is also related to what
| you  choose as reference. I chose "C as accepted by my gcc on my
| machine".  Aldor did not choose the current C specification, but maybe
| the "C as  accepted by (the then current) gcc".

But even with K&R, you have rubbish.


| 
| > | > 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.
| > |
| > | Hmm, until someone proves me wrong, I would claim that String is not
| > | part of the Aldor language. And it is also not a part of the
| > | runtime. It is defined in the Aldor library "libaldor". And I don't
| > | count libaldor as part of the compiler stuff.
| >
| > That is a fine distinction.  However, it does not work in practice: I
| > can't test any useful program coming with the AUG without having
| > libaldor.   AUG says, page 12:
| >
| >    #include "aldor" is the general include statement that will allow
| >    the types and functions from libaldor to be visible. It is
| >    necessary to use it (or an equivalent library) in order to write
| >    programs.
| 
| There are equivalent libraries.

I have no doubt that you can find *different implementations* of the
Aldor libary.  However, they will be _equivalent_.  That equivalence
classes (i.e. semamtics) is part of the compiler.

| I wrote one myself when experimenting
| with  the semantics of Aldor's categories. In my base library, the
| domain  Category had a completely different signature. I did not have
| a domain  String at all.
| 
| Compare it to C++ and the STL. You can code C++ without using the STL.

That sounds like "you can code in C++ without while".  That is
true, but that hardly implies that "while" is not part of the C++
language. 

STL is part of the *hosted implementation* specification of ISO C++ --
though a freestanding implementation can offer too, but is not
required too.  Most certainly the "STL" -- what most people call STL today
is not the real STL -- is part of the ISO C++ specification.  It is
part of the language. There is no real distinction, and certainly the
ISO C++ definition does not make any formal distintion.

However, you have many implementations of the C++ standard library.
That does not mean the standard library is not part of the language.

[...]

| The aldor library is not part of the Run-time System. Aldor's runtime
| system has types like HInt and SInt and expects Category and Type to
| be  some domain valued constants (to give an example of the connection
| between  the front-end and the run-time system).
| But the Aldor library is not in the scope of this. The Aldor libarry
| is  separated from the run-time system.

OK.

-- Gaby


From gdr at integrable-solutions.net  Sun Aug 13 10:20:08 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 13 Aug 2006 16:20:08 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <op.td7rzcytu6j4vy@spencer.aistleitner.info>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<op.td7rzcytu6j4vy@spencer.aistleitner.info>
Message-ID: <m3fyg04t0n.fsf@zeus.integrable-solutions.net>

"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



From ralf at hemmecke.de  Sun Aug 13 13:34:06 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Sun, 13 Aug 2006 19:34:06 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <m3lkps4ty3.fsf@zeus.integrable-solutions.net>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>	<op.td351cpau6j4vy@spencer.aistleitner.info>	<m3u04j8rym.fsf@zeus.integrable-solutions.net>	<op.td51o72eu6j4vy@spencer.aistleitner.info>	<m3slk22ikn.fsf@zeus.integrable-solutions.net>	<44DE087B.6040904@hemmecke.de>	<m3veoxg854.fsf@zeus.integrable-solutions.net>	<op.td7udxt0u6j4vy@spencer.aistleitner.info>
	<m3lkps4ty3.fsf@zeus.integrable-solutions.net>
Message-ID: <44DF628E.2060803@hemmecke.de>

> I have no doubt that you can find *different implementations* of the 
> Aldor libary.  However, they will be _equivalent_.  That equivalence 
> classes (i.e. semamtics) is part of the compiler.

Gaby, can you show me a definition of THE Aldor library?

All I can find is an API description of what happens to be an
implementation that leads to libaldor.al + libaldor.a and is distributed
with the compiler.

And if you actually mean that implementation should be called THE Aldor
library, then there is currently no equivalent one existing.

In fact, I believe that the current libaldor should be improved or 
rewritten to become a standard.

Ralf


From tmgisi at gmx.at  Mon Aug 14 02:21:02 2006
From: tmgisi at gmx.at (Christian Aistleitner)
Date: Mon, 14 Aug 2006 08:21:02 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <44DF0DE8.80609@hemmecke.de>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<44DE087B.6040904@hemmecke.de>
	<m3veoxg854.fsf@zeus.integrable-solutions.net>
	<44DE4750.9070704@hemmecke.de>
	<m37j1da4fi.fsf@zeus.integrable-solutions.net>
	<op.td7u0zpuu6j4vy@spencer.aistleitner.info>
	<44DF0DE8.80609@hemmecke.de>
Message-ID: <op.td9fxcmnu6j4vy@spencer.aistleitner.info>

Hello,

On Sun, 13 Aug 2006 13:32:56 +0200, Ralf Hemmecke <ralf at hemmecke.de> wrote:

>>> | Just being curious... is there a legal C program that defines a
>>> | constant array, and a pointer (or whatever) to on element of that
>>> | array and then modifies that entry in-place?
>>>
>>> If I understand the question correctly, the answer is "no".
>>
>> For those being not familiar with C or C++:
>> These languages also provide a modifier const (just doing what its name
>> suggests), which Aldor (currently) lacks.
>
> Ooops. What is then
>
> str: String == anotherString;
>
> supposed to mean?

Sorry, I did not make myself clear enough.

Gaby already elaborated on the "const" modifier. However, I meant it more  
in the direction of passing parameters. For example type "man strcat" at  
your command line and you'll probably get a description of the C function  
strcat. Already from its signature
   char *strcat(char *dest, const char *src);
you can read off, that src is not meant to be changed, while dest probably  
will be modified (indeed the string it points to is modified). That's the  
concept Aldor lacks. We just have the "!"-convention. But that's not a  
hard requirement but simply a convention. The compiler cannot use it to  
perform checks. Furthermore, the "!" does not specify, which parameters  
act constant and which may be modified.

--
Kind regards,
Christian



From tmgisi at gmx.at  Mon Aug 14 02:41:22 2006
From: tmgisi at gmx.at (Christian Aistleitner)
Date: Mon, 14 Aug 2006 08:41:22 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <m3lkps4ty3.fsf@zeus.integrable-solutions.net>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<44DE087B.6040904@hemmecke.de>
	<m3veoxg854.fsf@zeus.integrable-solutions.net>
	<op.td7udxt0u6j4vy@spencer.aistleitner.info>
	<m3lkps4ty3.fsf@zeus.integrable-solutions.net>
Message-ID: <op.td9gu8j0u6j4vy@spencer.aistleitner.info>

Hello,

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

> "Christian Aistleitner" <tmgisi at gmx.at> writes:
>
> [...]
>
> | #include <stdio.h>
> | int main( int argc, char * argv[] )
> | {
> |    char str0[]="QRST";
> |    char str1[]="ABCDEFGHIJKLMNO";
> |    str1[strlen(str1)]='P';
> |    printf( "%s\n", str1 );
> |    return 0;
> | }
> |
> | . Its not very portable -- but portable is again one of those vague
> | term.  We do not use it. It's a valid C program (for this gcc an my
> | machine).
>
> What makes you believe that is a valid C program?

I did not claim "The code conforms to Standard xxx". I claimed it is a  
valid C program for my gcc on my machine.

> It invokes
> undefined behaviour.  From there you can prove everything you want.

No the behaviour is not undefined for this very gcc. It most likely is  
undefined according to most C standards, but for this very gcc I use, the  
behaviour is defined. I *know* where the variables are stored in memory  
and how they are connected. It's repeatable and always the same. It is  
defined for my gcc.

I did not claim it's portable. I do not like such code myself. But it's  
valid code for my gcc on my machine. It runs and works. Not be adhering to  
any C standard, but by design.

In the same spirit, string$String from the aldor libarry is valid -- for  
old enough gccs.

> | Maybe this example showed you, that the issue is also related to what
> | you  choose as reference. I chose "C as accepted by my gcc on my
> | machine".  Aldor did not choose the current C specification, but maybe
> | the "C as  accepted by (the then current) gcc".
>
> But even with K&R, you have rubbish.

I never said to do K&R.

> | > That is a fine distinction.  However, it does not work in practice: I
> | > can't test any useful program coming with the AUG without having
> | > libaldor.   AUG says, page 12:
> | >
> | >    #include "aldor" is the general include statement that will allow
> | >    the types and functions from libaldor to be visible. It is
> | >    necessary to use it (or an equivalent library) in order to write
> | >    programs.
> |
> | There are equivalent libraries.
>
> I have no doubt that you can find *different implementations* of the
> Aldor libary.  However, they will be _equivalent_.  That equivalence
> classes (i.e. semamtics) is part of the compiler.

They are not equivalent. They'll most probably share some things, but they  
are not equivalent.

They'll probably all define Type, Category and these things. But the rest  
is not needed.

> | I wrote one myself when experimenting
> | with  the semantics of Aldor's categories. In my base library, the
> | domain  Category had a completely different signature. I did not have
> | a domain  String at all.
> |
> | Compare it to C++ and the STL. You can code C++ without using the STL.
>
> That sounds like "you can code in C++ without while".  That is
> true, but that hardly implies that "while" is not part of the C++
> language.

I am sorry, but I just have to accept we a quite different view of what  
constitues the Aldor language. I do not know what other arguments I should  
give.

> However, you have many implementations of the C++ standard library.
> That does not mean the standard library is not part of the language.
>
> [...]
>
> | The aldor library is not part of the Run-time System. Aldor's runtime
> | system has types like HInt and SInt and expects Category and Type to
> | be  some domain valued constants (to give an example of the connection
> | between  the front-end and the run-time system).
> | But the Aldor library is not in the scope of this. The Aldor libarry
> | is  separated from the run-time system.
>
> OK.

This "OK" puzzles me.
Do you mean "Let's accept we have different points of view" or "I feel  
convinced"?

--
Kind regards,
Christian



From tmgisi at gmx.at  Mon Aug 14 07:22:58 2006
From: tmgisi at gmx.at (Christian Aistleitner)
Date: Mon, 14 Aug 2006 13:22:58 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <m3fyg04t0n.fsf@zeus.integrable-solutions.net>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<op.td7rzcytu6j4vy@spencer.aistleitner.info>
	<m3fyg04t0n.fsf@zeus.integrable-solutions.net>
Message-ID: <op.td9twklou6j4vy@spencer.aistleitner.info>

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



From daly at axiom-developer.org  Mon Aug 14 01:25:34 2006
From: daly at axiom-developer.org (root)
Date: Mon, 14 Aug 2006 01:25:34 -0400
Subject: [Aldor-l] Compiling setup
In-Reply-To: <op.td7vonx2u6j4vy@spencer.aistleitner.info> (tmgisi@gmx.at)
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<20060812141942.GA30663@ptibonum.scl.csd.uwo.ca>
	<20060812224638.GA5946@aquarium.aldor.org>
	<20060812225529.GC11239@ptibonum.scl.csd.uwo.ca>
	<op.td7vonx2u6j4vy@spencer.aistleitner.info>
Message-ID: <200608140525.k7E5PYG11880@localhost.localdomain>

> However, according to the AUG, a Literal is a constant. According to the  
> discussion, we all agree constants are correctly modelled by
>    char * str = "my_fancy_literal".
> To my understanding, this is basically, what Aldor does at the moment.  
> This is a sound behaviour -- No one wants to change the representation of  
> string literals.

Really? Aldor is based on the ideas in the spad language.
String literals are easily mutable in spad.
It is incorrect to reflect a C restriction upward.

t


From tmgisi at gmx.at  Mon Aug 14 07:50:19 2006
From: tmgisi at gmx.at (Christian Aistleitner)
Date: Mon, 14 Aug 2006 13:50:19 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <200608140525.k7E5PYG11880@localhost.localdomain>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<20060812141942.GA30663@ptibonum.scl.csd.uwo.ca>
	<20060812224638.GA5946@aquarium.aldor.org>
	<20060812225529.GC11239@ptibonum.scl.csd.uwo.ca>
	<op.td7vonx2u6j4vy@spencer.aistleitner.info>
	<200608140525.k7E5PYG11880@localhost.localdomain>
Message-ID: <op.td9u55gju6j4vy@spencer.aistleitner.info>

Hello,

first off, sorry for not answering to the post of aldor-l but to the one  
sent to me directly. I cannot find the post to the mailing list.

On Mon, 14 Aug 2006 07:25:34 +0200, Tim Daly <daly at axiom-developer.org>  
wrote:

>> However, according to the AUG, a Literal is a constant. According to the
>> discussion, we all agree constants are correctly modelled by
>>    char * str = "my_fancy_literal".
>> To my understanding, this is basically, what Aldor does at the moment.
>> This is a sound behaviour -- No one wants to change the representation  
>> of string literals.
>
> Really? Aldor is based on the ideas in the spad language.
> String literals are easily mutable in spad.
> It is incorrect to reflect a C restriction upward.

The "no one" refers to the people discussing the issue ("According to the  
discussion"). You just joined in, so the "no one" apparently does not  
include you.

String literals are constants in Aldor (as written in ?5.2 of the AUG).
I guess main purpose of the _Aldor_ compiler should be to compile _Aldor_  
code and assist _Aldor_ developers.
I consider read-only constants an extremely helpful and a good design  
decision.

If the Aldor compiler can compile spad files for you, it's nice. However,  
I would strongly vote against legacy support, if it forbids a good  
experience for the main audience.

Ad main audience:
I know that there are more Axiom developers than Aldor developers around  
here, so I hope the main audience still are Aldor developers, even though  
there are hardly any ...


--
Kind regards,
Christian


From d.i.preininger at tele2.at  Thu Aug 17 02:35:05 2006
From: d.i.preininger at tele2.at (Preininger)
Date: Thu, 17 Aug 2006 08:35:05 +0200
Subject: [Aldor-l] write!
Message-ID: <auto-000087127305@mailfe10.swip.net>

Hello,

I try the AUG example 21.14 Text input,

with aldor -ginterp textinput.as
the command - open("file",fileWrite) works
the command - write!(c,tw) fails with an error in: putc in sal_file.as

any solution?




From ralf at hemmecke.de  Thu Aug 17 09:45:35 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Thu, 17 Aug 2006 15:45:35 +0200
Subject: [Aldor-l] write!
In-Reply-To: <auto-000087127305@mailfe10.swip.net>
References: <auto-000087127305@mailfe10.swip.net>
Message-ID: <44E472FF.6030007@hemmecke.de>

Hello,

On 08/17/2006 08:35 AM, Preininger wrote:
> Hello,
> 
> I try the AUG example 21.14 Text input,
> 
> with aldor -ginterp textinput.as
> the command - open("file",fileWrite) works
> the command - write!(c,tw) fails with an error in: putc in sal_file.as
> 
> any solution?

That file is supposed to be run as an executable. So try

aldor -laldor -fx textinput.as
textinput

or

aldor -laldor -grun textinput.as

The reason why it fails is, that (my very guess) the switch "-ginterp" 
instructs the compiler to compile to foam and execute that FOAM code. 
However, with FOAM you have NO access to routines directly implemented in C.

Ralf



From martin.rubey at univie.ac.at  Tue Aug 15 15:43:24 2006
From: martin.rubey at univie.ac.at (Martin Rubey)
Date: 15 Aug 2006 21:43:24 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <op.td9u55gju6j4vy@spencer.aistleitner.info>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<20060812141942.GA30663@ptibonum.scl.csd.uwo.ca>
	<20060812224638.GA5946@aquarium.aldor.org>
	<20060812225529.GC11239@ptibonum.scl.csd.uwo.ca>
	<op.td7vonx2u6j4vy@spencer.aistleitner.info>
	<200608140525.k7E5PYG11880@localhost.localdomain>
	<op.td9u55gju6j4vy@spencer.aistleitner.info>
Message-ID: <9qsljx3hur.fsf@aquin.mat.univie.ac.at>

"Christian Aistleitner" <tmgisi at gmx.at> writes:

> I know that there are more Axiom developers than Aldor developers around  
> here, [...]

I first read "more SPAD programmers than Aldor programmers", and wanted to
respond:

  In fact, I doubt that. At least, I consider rather like an Aldor programmer
  condemned to restrict himself to SPAD code...
  
  I don't think that there are many SPAD programmers left. Antoine codes in
  Aldor, so does Ralf, I nearly do. Who else has written something recently?
  
  If I had (at least) a _promise_ that Aldor will become free software (at
  least in some sense) then I'd switch immediately myself, and work hard to
  make Axiom go Aldor altogether.

Martin



From bill.page1 at synthesis.anikast.ca  Fri Aug 18 14:25:51 2006
From: bill.page1 at synthesis.anikast.ca (Bill Page)
Date: Fri, 18 Aug 2006 14:25:51 -0400
Subject: [Aldor-l] Using Aldor or SPAD
In-Reply-To: <9q3bbuue86.fsf_-_@login.mat.univie.ac.at>
Message-ID: <024001c6c2f3$c1397ed0$6900a8c0@asus>

On August 18, 2006 1:49 PM Martin Rubey wrote:
> 
> Gabriel Dos Reis writes:
> 
> > I've been writing more and more SPAD, less and less Aldor. 
> > And I suspect very soon my students will more SPAD than 
> > Aldor, however imperfect SPAD...
> 
> why is that? I really can't understand, there are so many 
> things missing in spad!
> 

Ya, like error message a human can understand, for one! :)
I think SPAD is nearly impossible to learn because the results
of compiling incorrect programs are so difficult to interpret.
I usually write something in Aldor first to get the syntax and
types correct and then (if necessary) back port it to SPAD.

On the other hand (with a few notable exceptions like fully
implemented dependent types), the SPAD *language* is not
fundamentally very different than Aldor. SPAD is a productive
language - after all 1,300 packages domains and categories
are currently implemented in this language.

Then, of course there is the long unresolved issue of the lack
of a clear open source license for Aldor. I fear that if this
not resolved in the next few **weeks**, then the consequences
for both Aldor and Axiom could be very negative. All the rhetoric
of having to get people who already agree to agree aside, I just
do not understand why aldor.org would have neglected this for
so long. :(

Regards,
Bill Page.




From ralf at hemmecke.de  Fri Aug 18 15:37:47 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Fri, 18 Aug 2006 21:37:47 +0200
Subject: [Aldor-l] Using Aldor or SPAD
In-Reply-To: <024001c6c2f3$c1397ed0$6900a8c0@asus>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>
Message-ID: <44E6170B.1020108@hemmecke.de>

On 08/18/2006 08:25 PM, Bill Page wrote:
> On August 18, 2006 1:49 PM Martin Rubey wrote:
>> Gabriel Dos Reis writes:
>>
>>> I've been writing more and more SPAD, less and less Aldor. 
>>> And I suspect very soon my students will more SPAD than 
>>> Aldor, however imperfect SPAD...
>> why is that? I really can't understand, there are so many 
>> things missing in spad!

On which list did that appear. I don't remember that I have seen these 
mails... :-(

> Ya, like error message a human can understand, for one! :)
> I think SPAD is nearly impossible to learn because the results
> of compiling incorrect programs are so difficult to interpret.
> I usually write something in Aldor first to get the syntax and
> types correct and then (if necessary) back port it to SPAD.

That sounds reasonable and it probably results in better readable SPAD 
code. But anyway, SPAD should die out, either by using an sufficiently 
open source Aldor compiler or by modifying the current SPAD compiler to 
accept the Aldor language (and giving proper error messages).

> On the other hand (with a few notable exceptions like fully
> implemented dependent types), the SPAD *language* is not
> fundamentally very different than Aldor. SPAD is a productive
> language - after all 1,300 packages domains and categories
> are currently implemented in this language.

If you really look at the code then you see that most of it must be 
considered as black boxes. Even if you can read the spad sources (since 
they are open), it remains our task to make pamphlets out of them. And I 
would rather like to do this by replacing a non-strictly defined 
language like SPAD by a more strictly defined language Aldor.

> Then, of course there is the long unresolved issue of the lack
> of a clear open source license for Aldor. I fear that if this
> not resolved in the next few **weeks**, then the consequences
> for both Aldor and Axiom could be very negative.

What can you do? The only option we have if the Aldor compiler is not 
going to open soon, is to write another compiler. But I guess that is 
going to take quite a while. First we have to find people who are 
willing an able to start such a project.

Gaby, have you any idea how long it could take to produce another 
reasonably efficient Aldor compiler?

Ralf


From gdr at integrable-solutions.net  Fri Aug 18 16:02:53 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 18 Aug 2006 22:02:53 +0200
Subject: [Aldor-l] Using Aldor or SPAD
In-Reply-To: <44E6170B.1020108@hemmecke.de>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>
	<44E6170B.1020108@hemmecke.de>
Message-ID: <m3y7tlak2a.fsf@zeus.integrable-solutions.net>

Ralf Hemmecke <ralf at hemmecke.de> writes:

[...]

| That sounds reasonable and it probably results in better readable SPAD 
| code. But anyway, SPAD should die out, either by using an sufficiently 
| open source Aldor compiler or by modifying the current SPAD compiler to 
| accept the Aldor language (and giving proper error messages).

I can't promote the disappearance of SPAD if I don't havw a working
replacement. 

[...]

|                                                   But I guess that is 
| going to take quite a while. First we have to find people who are 
| willing an able to start such a project.

It may take a while but it would be an interesting project, beneficial
to the Aldor language and community.  Most of the non-proprietary
languages I know have greatly benefited from the availability of
several implementations.

| Gaby, have you any idea how long it could take to produce another 
| reasonably efficient Aldor compiler?

It all depends on what you want to have in the "reasonably efficient"
compiler. It should be a mater of days or weeks to have a good
front-end. It would take momths to have decent optimizations in.
but, that is definitely in our reach.

-- Gaby


From ralf at hemmecke.de  Fri Aug 18 18:13:07 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Sat, 19 Aug 2006 00:13:07 +0200
Subject: [Aldor-l] Using Aldor or SPAD
In-Reply-To: <m3y7tlak2a.fsf@zeus.integrable-solutions.net>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>	<44E6170B.1020108@hemmecke.de>
	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>
Message-ID: <44E63B73.1050403@hemmecke.de>

> | Gaby, have you any idea how long it could take to produce another 
> | reasonably efficient Aldor compiler?

> It all depends on what you want to have in the "reasonably efficient"
> compiler.

Yes, that is clear.

> It should be a mater of days or weeks to have a good front-end.

Oh, really? Why then wait any longer? Maybe, because there is no 100% 
clear definition of the language Aldor?

> It would take momths to have decent optimizations in.
> but, that is definitely in our reach.

Does somebody volunteer to start such a project, preferably under GPL?
I don't want the Aldor **language** to split, because of different 
compiler implementation, but staying in an uncertain future is just bad 
for the Aldor language to reach the masses.

Ralf


From gdr at integrable-solutions.net  Fri Aug 18 18:23:08 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 19 Aug 2006 00:23:08 +0200
Subject: [Aldor-l] Using Aldor or SPAD
In-Reply-To: <44E63B73.1050403@hemmecke.de>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>
	<44E6170B.1020108@hemmecke.de>
	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>
	<44E63B73.1050403@hemmecke.de>
Message-ID: <m3ac617kfn.fsf@zeus.integrable-solutions.net>

Ralf Hemmecke <ralf at hemmecke.de> writes:

[...]

| > It should be a mater of days or weeks to have a good front-end.
| 
| Oh, really? 

when you get a handful of motivated people, yes.

| Why then wait any longer? Maybe, because there is no 100%
| clear definition of the language Aldor?

That is an important factor I guess. I.e. what do we want?  What kind
of problems do we want to see solved by the language?

| > It would take momths to have decent optimizations in.
| > but, that is definitely in our reach.
| 
| Does somebody volunteer to start such a project, preferably under GPL?

well, I'm already burried with Axiom and other projects; but I do
definitely have an interest here.

| I don't want the Aldor **language** to split, because of different
| compiler implementation, but staying in an uncertain future is just
| bad for the Aldor language to reach the masses.

it would not be good for anybody to have the community split; however,
more than one implementations are beneficial for both the language and
the community.

-- Gaby


From ralf at hemmecke.de  Fri Aug 18 19:11:09 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Sat, 19 Aug 2006 01:11:09 +0200
Subject: [Aldor-l] Using Aldor or SPAD
In-Reply-To: <m3ac617kfn.fsf@zeus.integrable-solutions.net>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>	<44E6170B.1020108@hemmecke.de>	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>	<44E63B73.1050403@hemmecke.de>
	<m3ac617kfn.fsf@zeus.integrable-solutions.net>
Message-ID: <44E6490D.60207@hemmecke.de>

On 08/19/2006 12:23 AM, Gabriel Dos Reis wrote:
> Ralf Hemmecke <ralf at hemmecke.de> writes:
> 
> [...]
> 
> | > It should be a mater of days or weeks to have a good front-end.
> | 
> | Oh, really? 
> 
> when you get a handful of motivated people, yes.

Maybe we should open up a Wiki and call for people on the FrontPage 
similar to the FreeAldor link.

> | Why then wait any longer? Maybe, because there is no 100%
> | clear definition of the language Aldor?
> 
> That is an important factor I guess. I.e. what do we want?  What kind
> of problems do we want to see solved by the language?

I believe that some research is involved here. I would definitely like 
to see better support in the language to state the input-output 
conditions in formal terms that could be used by a theorem prover.
If that just appears in the comments it is lost for checking program 
correctness.

> | > It would take momths to have decent optimizations in.
> | > but, that is definitely in our reach.
> | 
> | Does somebody volunteer to start such a project, preferably under GPL?
> 
> well, I'm already burried with Axiom and other projects; but I do
> definitely have an interest here.

Axiom is really big, may I ask on which part of Axiom do you want to 
concentrate?

In my eyes Aldor is/should become one of the most important pieces in 
Axiom. The mathematical knowledge that is hidden in all the SPAD 
domains, must be rewritten in Aldor and in a pamphlet style.

> | I don't want the Aldor **language** to split, because of different
> | compiler implementation, but staying in an uncertain future is just
> | bad for the Aldor language to reach the masses.

> it would not be good for anybody to have the community split; however,
> more than one implementations are beneficial for both the language and
> the community.

The availability of manpower is a big question mark for a second 
implementation of Aldor.

Ralf


From daly at axiom-developer.org  Fri Aug 18 19:10:21 2006
From: daly at axiom-developer.org (root)
Date: Fri, 18 Aug 2006 19:10:21 -0400
Subject: [Aldor-l] [Axiom-developer] Re:  Using Aldor or SPAD
In-Reply-To: <44E6490D.60207@hemmecke.de> (message from Ralf Hemmecke on Sat, 
	19 Aug 2006 01:11:09 +0200)
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>	<44E6170B.1020108@hemmecke.de>	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>	<44E63B73.1050403@hemmecke.de>
	<m3ac617kfn.fsf@zeus.integrable-solutions.net>
	<44E6490D.60207@hemmecke.de>
Message-ID: <200608182310.k7INALa15933@localhost.localdomain>

>From historical experience a new Aldor compiler would be a
3 year, 5 person project.

t


From gdr at integrable-solutions.net  Fri Aug 18 19:28:42 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 19 Aug 2006 01:28:42 +0200
Subject: [Aldor-l] [Axiom-developer] Re:  Using Aldor or SPAD
In-Reply-To: <200608182310.k7INALa15933@localhost.localdomain>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>
	<44E6170B.1020108@hemmecke.de>
	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>
	<44E63B73.1050403@hemmecke.de>
	<m3ac617kfn.fsf@zeus.integrable-solutions.net>
	<44E6490D.60207@hemmecke.de>
	<200608182310.k7INALa15933@localhost.localdomain>
Message-ID: <m3y7tl4o9h.fsf@zeus.integrable-solutions.net>

root <daly at axiom-developer.org> writes:

| >From historical experience a new Aldor compiler would be a
| 3 year, 5 person project.

but, such a new compiler would have to reinvent everything from
scratch.  A lot have been done in recent years in terms for dependent
types (Nurpl, epigram, etc.), functional languages implementations
techniques and optimizations (OCaml, Haskell, etc.).  Furthermore
it may attract more students.  

Of course, that is not said to underestimate the task; just to remind
that not everything has to be reinvented.

-- Gaby


From gdr at integrable-solutions.net  Fri Aug 18 19:35:11 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 19 Aug 2006 01:35:11 +0200
Subject: [Aldor-l] [Axiom-developer] Re:  Using Aldor or SPAD
In-Reply-To: <m3y7tl4o9h.fsf@zeus.integrable-solutions.net>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>
	<44E6170B.1020108@hemmecke.de>
	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>
	<44E63B73.1050403@hemmecke.de>
	<m3ac617kfn.fsf@zeus.integrable-solutions.net>
	<44E6490D.60207@hemmecke.de>
	<200608182310.k7INALa15933@localhost.localdomain>
	<m3y7tl4o9h.fsf@zeus.integrable-solutions.net>
Message-ID: <m34pw9k47k.fsf@zeus.integrable-solutions.net>

Gabriel Dos Reis <gdr at integrable-solutions.net> writes:

| root <daly at axiom-developer.org> writes:
| 
| | >From historical experience a new Aldor compiler would be a
| | 3 year, 5 person project.
| 
| but, such a new compiler would have to reinvent everything from
                                ^

ouch, there is a missing "NOT" here. Sorry for that.

-- Gaby


From ralf at hemmecke.de  Fri Aug 18 20:22:29 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Sat, 19 Aug 2006 02:22:29 +0200
Subject: [Aldor-l] Const Bug?
Message-ID: <44E659C5.20000@hemmecke.de>

Who can tell me whether the compiler behaves correctly when it rejects 
that program below...

Removing the definitions of fooConst and barConst, compiles without a 
problem.

Ralf

 >aldor -laldor aaaConst.as
"aaaConst.as", line 16:                 nth(): Integer == 0;
                         ................^
[L16 C17] #2 (Note 1)  (cf. L21 C17)

"aaaConst.as", line 21:                 nth(): Integer == 1;
                         ................^
[L21 C17] #1 (Error) Constant `nth' cannot be redefined.
(see Note 1)



---BEGIN aaaConst.as
#include "aldor"
#include "aldorio"

AAA: with == add {
	foo(): Integer == {
		nth(): Integer == 0;
		stdout << "something" << newline;
		nth();
	}
	bar(): Integer == {
		nth(): Integer == 1;
		stdout << "else" << newline;
		nth();
	}
	fooConst: Integer == {
		nth(): Integer == 0;
		stdout << "something" << newline;
		nth();
	}
	barConst: Integer == {
		nth(): Integer == 1;
		stdout << "else" << newline;
		nth();
	}
}
---END aaaConst.as



From daly at axiom-developer.org  Sat Aug 19 00:29:35 2006
From: daly at axiom-developer.org (root)
Date: Sat, 19 Aug 2006 00:29:35 -0400
Subject: [Aldor-l] [Axiom-developer] Re:  Using Aldor or SPAD
In-Reply-To: <m34pw9k47k.fsf@zeus.integrable-solutions.net> (message from
	Gabriel Dos Reis on 19 Aug 2006 01:35:11 +0200)
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>
	<44E6170B.1020108@hemmecke.de>
	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>
	<44E63B73.1050403@hemmecke.de>
	<m3ac617kfn.fsf@zeus.integrable-solutions.net>
	<44E6490D.60207@hemmecke.de>
	<200608182310.k7INALa15933@localhost.localdomain>
	<m3y7tl4o9h.fsf@zeus.integrable-solutions.net>
	<m34pw9k47k.fsf@zeus.integrable-solutions.net>
Message-ID: <200608190429.k7J4TZQ16041@localhost.localdomain>

| root <daly at axiom-developer.org> writes:
| 
| | >From historical experience a new Aldor compiler would be a
| | 3 year, 5 person project.
| 
| but, such a new compiler would NOT have to reinvent everything from

of course, if it were written in lisp and assumed the axiom system
underneath it then it is a much less complex problem.

t



From tmgisi at gmx.at  Sat Aug 19 02:02:59 2006
From: tmgisi at gmx.at (Christian Aistleitner)
Date: Sat, 19 Aug 2006 08:02:59 +0200
Subject: [Aldor-l] No Const Bug (was: Re:  Const Bug?)
In-Reply-To: <44E659C5.20000@hemmecke.de>
References: <44E659C5.20000@hemmecke.de>
Message-ID: <op.teioe9a0u6j4vy@spencer.aistleitner.info>

Hello,

On Sat, 19 Aug 2006 02:22:29 +0200, Ralf Hemmecke <ralf at hemmecke.de> wrote:

> Who can tell me whether the compiler behaves correctly when it rejects
> that program below...

I guess, this is actually correct behaviour ;)
Bear in mind, that { } does not necessarily create a new scope.
It does create new scopes for foo and bar, but not for fooConst and  
barConst.
That is correct according to ?8.1 AUG.
Hence the nth of fooConst is not local to fooConst, but local to the add  
expression. Same holds for the nth in barConst.
So both constants nth are in the same scope. The nth of barConst is trying  
to redefine the nth definide in fooConst.

> ---BEGIN aaaConst.as
> #include "aldor"
> #include "aldorio"
>
> AAA: with == add {
> 	foo(): Integer == {
> 		nth(): Integer == 0;
> 		stdout << "something" << newline;
> 		nth();
> 	}
> 	bar(): Integer == {
> 		nth(): Integer == 1;
> 		stdout << "else" << newline;
> 		nth();
> 	}
> 	fooConst: Integer == {
> 		nth(): Integer == 0;
> 		stdout << "something" << newline;
> 		nth();
> 	}
> 	barConst: Integer == {
> 		nth(): Integer == 1;
> 		stdout << "else" << newline;
> 		nth();
> 	}
> }
> ---END aaaConst.as

--
Kind regards,
Christian


From tmgisi at gmx.at  Sat Aug 19 02:58:06 2006
From: tmgisi at gmx.at (Christian Aistleitner)
Date: Sat, 19 Aug 2006 08:58:06 +0200
Subject: [Aldor-l] Using Aldor or SPAD
In-Reply-To: <44E6490D.60207@hemmecke.de>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>
	<44E6170B.1020108@hemmecke.de>
	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>
	<44E63B73.1050403@hemmecke.de>
	<m3ac617kfn.fsf@zeus.integrable-solutions.net>
	<44E6490D.60207@hemmecke.de>
Message-ID: <op.teiqy4szu6j4vy@spencer.aistleitner.info>

Hello,

On Sat, 19 Aug 2006 01:11:09 +0200, Ralf Hemmecke <ralf at hemmecke.de> wrote:

> On 08/19/2006 12:23 AM, Gabriel Dos Reis wrote:
>> Ralf Hemmecke <ralf at hemmecke.de> writes:
>>
>> [...]
>>
>> | > It should be a mater of days or weeks to have a good front-end.
>> |
>> | Oh, really?
>>
>> when you get a handful of motivated people, yes.
>
> Maybe we should open up a Wiki and call for people on the FrontPage
> similar to the FreeAldor link.

Bear in mind, that you are trying to rewrite an existing product.
IANAL and I do not know French/British/Canadian law.
But I have been reading several traits of US law (which I have been told  
to be not too different from Canadian law).
According to my understanding of US law, someone who has seen Aldor source  
code cannot work on rewriting Aldor (without explicit permission by those  
who hold the rights of the Aldor source code).
I am not sure, to what extend the US law situation is reflected by  
Canadian, French or British law.
However, as (I guess) most of the ppl interested in Aldor, have seen the  
compiler's source code, they (probably) should not work on the  
reimplementation of it.

This is not some funny side remark of myself, but a real issue. Just think  
about the pain ReactOS is going through.

--
Kind regards,
Christian


From martin.rubey at univie.ac.at  Sat Aug 19 06:32:07 2006
From: martin.rubey at univie.ac.at (Martin Rubey)
Date: 19 Aug 2006 12:32:07 +0200
Subject: [Aldor-l] Using Aldor or SPAD
In-Reply-To: <m3y7tlak2a.fsf@zeus.integrable-solutions.net>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>
	<44E6170B.1020108@hemmecke.de>
	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>
Message-ID: <9qoduh10ew.fsf@aquin.mat.univie.ac.at>

Dear Gabriel, Ralf, Christian, Bill, ...

Gabriel Dos Reis <gdr at integrable-solutions.net> writes:

> | Gaby, have you any idea how long it could take to produce another
> | reasonably efficient Aldor compiler?
> 
> It all depends on what you want to have in the "reasonably efficient"
> compiler. It should be a mater of days or weeks to have a good front-end. It
> would take momths to have decent optimizations in.  but, that is definitely
> in our reach.

What implementation language would you propose? Is the legal situation affected
by the choice of the implementation language? Gaby, did your students see the
source code of the aldor compiler?

I think we should not wait any longer. I'm currently interested in two
projects:

* species, together with Ralf and Nicolas

* symmetric functions

Both of these projects depend *heavily* on types being first class objects, and
on allowing dependent types. Both of these features are missing in SPAD.

In fact, there are two things missing in Axiom:

1) a replacement for SPAD that allows one to use the Aldor language

2) a replacement for the interpreter, that allows one to use the Aldor language

I wouldn't be surprised if 2) would be easier to achieve, but I don't
know. Gaby, how much money do you need for 1), for 2) and for both?

Martin



From gdr at integrable-solutions.net  Sat Aug 19 09:43:32 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 19 Aug 2006 15:43:32 +0200
Subject: [Aldor-l] Using Aldor or SPAD
In-Reply-To: <9qoduh10ew.fsf@aquin.mat.univie.ac.at>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>
	<44E6170B.1020108@hemmecke.de>
	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>
	<9qoduh10ew.fsf@aquin.mat.univie.ac.at>
Message-ID: <m3hd08et8b.fsf@zeus.integrable-solutions.net>

Martin Rubey <martin.rubey at univie.ac.at> writes:

| Dear Gabriel, Ralf, Christian, Bill, ...
| 
| Gabriel Dos Reis <gdr at integrable-solutions.net> writes:
| 
| > | Gaby, have you any idea how long it could take to produce another
| > | reasonably efficient Aldor compiler?
| > 
| > It all depends on what you want to have in the "reasonably efficient"
| > compiler. It should be a mater of days or weeks to have a good front-end. It
| > would take momths to have decent optimizations in.  but, that is definitely
| > in our reach.
| 
| What implementation language would you propose? Is the legal

this usually turns to be a language war so I would like first to have
us agree on what we want to have, then seek the means.

| situation affected by the choice of the implementation language?
| Gaby, did your students see the source code of the aldor compiler?

No, and I never saw it.  The only thing I know of the Aldor compiler
is that long time ago my "intern-mate" Yannis was working on it at
Sophia Antipolis...

| I think we should not wait any longer. I'm currently interested in two
| projects:
| 
| * species, together with Ralf and Nicolas
| 
| * symmetric functions
| 
| Both of these projects depend *heavily* on types being first class
| objects, and on allowing dependent types. Both of these features are
| missing in SPAD. 

Indeed.  You have mentioned dependent types many times.  I would like
to know more about what you mean.  For example, if we go full
dependent types, I suspect it would be very difficult to evaluate
all categories at compile-time.  So, I'm interested in the kind of
dependency you want.
[ For example, C++ has dependent types at its "template systems" but
  values are limited to integers and addresses of toplevel entities ]

| In fact, there are two things missing in Axiom:
| 
| 1) a replacement for SPAD that allows one to use the Aldor language

Can anyone familiar with integrating SPAD with foreign languages
educate me about the thorny issues?

| 2) a replacement for the interpreter, that allows one to use the Aldor language
| 
| I wouldn't be surprised if 2) would be easier to achieve, but I don't
| know. Gaby, how much money do you need for 1), for 2) and for both?

At the moment, I would have assess students' needs before.  Let's talk about
this aspect latter.

Thanks for your support!

-- Gaby


From gdr at integrable-solutions.net  Sat Aug 19 09:46:34 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 19 Aug 2006 15:46:34 +0200
Subject: [Aldor-l] No Const Bug (was: Re:  Const Bug?)
In-Reply-To: <op.teioe9a0u6j4vy@spencer.aistleitner.info>
References: <44E659C5.20000@hemmecke.de>
	<op.teioe9a0u6j4vy@spencer.aistleitner.info>
Message-ID: <m3bqqget39.fsf@zeus.integrable-solutions.net>

"Christian Aistleitner" <tmgisi at gmx.at> writes:

| Hello,
| 
| On Sat, 19 Aug 2006 02:22:29 +0200, Ralf Hemmecke <ralf at hemmecke.de> wrote:
| 
| > Who can tell me whether the compiler behaves correctly when it rejects
| > that program below...
| 
| I guess, this is actually correct behaviour ;)
| Bear in mind, that { } does not necessarily create a new scope.
| It does create new scopes for foo and bar, but not for fooConst and  
| barConst.

What is the rationale for that design point?

-- Gaby


From gdr at integrable-solutions.net  Sat Aug 19 09:54:06 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 19 Aug 2006 15:54:06 +0200
Subject: [Aldor-l] [Axiom-developer] Re:  Using Aldor or SPAD
In-Reply-To: <200608190429.k7J4TZQ16041@localhost.localdomain>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>
	<44E6170B.1020108@hemmecke.de>
	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>
	<44E63B73.1050403@hemmecke.de>
	<m3ac617kfn.fsf@zeus.integrable-solutions.net>
	<44E6490D.60207@hemmecke.de>
	<200608182310.k7INALa15933@localhost.localdomain>
	<m3y7tl4o9h.fsf@zeus.integrable-solutions.net>
	<m34pw9k47k.fsf@zeus.integrable-solutions.net>
	<200608190429.k7J4TZQ16041@localhost.localdomain>
Message-ID: <m3psewde69.fsf@zeus.integrable-solutions.net>

root <daly at axiom-developer.org> writes:

| | root <daly at axiom-developer.org> writes:
| | 
| | | >From historical experience a new Aldor compiler would be a
| | | 3 year, 5 person project.
| | 
| | but, such a new compiler would NOT have to reinvent everything from
| 
| of course, if it were written in lisp and assumed the axiom system
| underneath it then it is a much less complex problem.

It would be difficult for me to find good and motivated students
sufficiently fluent in Lisp :-)  But, I get your point.  If, we have a
new compiler, it would be engineered so that it solves problems
encountered by Axiom uses and improve the way people think of or write
Axiom libraries.

-- Gaby


From gdr at integrable-solutions.net  Sat Aug 19 09:58:13 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 19 Aug 2006 15:58:13 +0200
Subject: [Aldor-l] Using Aldor or SPAD
In-Reply-To: <op.teiqy4szu6j4vy@spencer.aistleitner.info>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>
	<44E6170B.1020108@hemmecke.de>
	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>
	<44E63B73.1050403@hemmecke.de>
	<m3ac617kfn.fsf@zeus.integrable-solutions.net>
	<44E6490D.60207@hemmecke.de>
	<op.teiqy4szu6j4vy@spencer.aistleitner.info>
Message-ID: <m3k654ddze.fsf@zeus.integrable-solutions.net>

"Christian Aistleitner" <tmgisi at gmx.at> writes:

| Hello,
| 
| On Sat, 19 Aug 2006 01:11:09 +0200, Ralf Hemmecke <ralf at hemmecke.de> wrote:
| 
| > On 08/19/2006 12:23 AM, Gabriel Dos Reis wrote:
| >> Ralf Hemmecke <ralf at hemmecke.de> writes:
| >>
| >> [...]
| >>
| >> | > It should be a mater of days or weeks to have a good front-end.
| >> |
| >> | Oh, really?
| >>
| >> when you get a handful of motivated people, yes.
| >
| > Maybe we should open up a Wiki and call for people on the FrontPage
| > similar to the FreeAldor link.
| 
| Bear in mind, that you are trying to rewrite an existing product.
| IANAL and I do not know French/British/Canadian law.
| But I have been reading several traits of US law (which I have been
| told  to be not too different from Canadian law).
| According to my understanding of US law, someone who has seen Aldor
| source  code cannot work on rewriting Aldor (without explicit
| permission by those  who hold the rights of the Aldor source code).

I never touched/saw Aldor compiler source code.  

I'm not trying to rewrite the existing compiler.  I'm only interested
in a new compiler for the *Aldor language*.  If the *Aldor language*
is defined to be the behaviour of its *current compiler*, then we are
all in trouble. 

| I am not sure, to what extend the US law situation is reflected by
| Canadian, French or British law.
| However, as (I guess) most of the ppl interested in Aldor, have seen
| the  compiler's source code, they (probably) should not work on the
| reimplementation of it.

That is a very good point.  Does that also imply that you cannot
answer any technical question about the *Aldor language*?

| This is not some funny side remark of myself, but a real issue. Just
| think  about the pain ReactOS is going through.

:-)

-- Gaby


From ralf at hemmecke.de  Sat Aug 19 10:41:03 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Sat, 19 Aug 2006 16:41:03 +0200
Subject: [Aldor-l] No Const Bug
In-Reply-To: <m3bqqget39.fsf@zeus.integrable-solutions.net>
References: <44E659C5.20000@hemmecke.de>	<op.teioe9a0u6j4vy@spencer.aistleitner.info>
	<m3bqqget39.fsf@zeus.integrable-solutions.net>
Message-ID: <44E722FF.5000902@hemmecke.de>

On 08/19/2006 03:46 PM, Gabriel Dos Reis wrote:
> "Christian Aistleitner" <tmgisi at gmx.at> writes:
> 
> | Hello,
> | 
> | On Sat, 19 Aug 2006 02:22:29 +0200, Ralf Hemmecke <ralf at hemmecke.de> wrote:
> | 
> | > Who can tell me whether the compiler behaves correctly when it rejects
> | > that program below...
> | 
> | I guess, this is actually correct behaviour ;)
> | Bear in mind, that { } does not necessarily create a new scope.
> | It does create new scopes for foo and bar, but not for fooConst and  
> | barConst.
> 
> What is the rationale for that design point?

I am looking forward to an answer to this question.

> -- Gaby


From ralf at hemmecke.de  Sat Aug 19 13:04:06 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Sat, 19 Aug 2006 19:04:06 +0200
Subject: [Aldor-l] Using Aldor or SPAD
In-Reply-To: <m3hd08et8b.fsf@zeus.integrable-solutions.net>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>	<44E6170B.1020108@hemmecke.de>	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>	<9qoduh10ew.fsf@aquin.mat.univie.ac.at>
	<m3hd08et8b.fsf@zeus.integrable-solutions.net>
Message-ID: <44E74486.1090706@hemmecke.de>

> The only thing I know of the Aldor compiler
> is that long time ago my "intern-mate" Yannis was working on it at
> Sophia Antipolis...

Ah, Yannis Chicha worked with you... This world is so small...

> | I think we should not wait any longer. I'm currently interested in two
> | projects:
> | 
> | * species, together with Ralf and Nicolas
> | 
> | * symmetric functions
> | 
> | Both of these projects depend *heavily* on types being first class
> | objects, and on allowing dependent types. Both of these features are
> | missing in SPAD. 
> 
> Indeed.  You have mentioned dependent types many times.  I would like
> to know more about what you mean.  For example, if we go full
> dependent types, I suspect it would be very difficult to evaluate
> all categories at compile-time.  So, I'm interested in the kind of
> dependency you want.

Currently, in aldor-combinat I am going to define something like...

define CombinatorialSpecies(L: LabelType): Category == with {
         <<exports: CombinatorialSpecies>>
}
CharacteristicSpecies(n:Integer)(L:LabelType): CombinatorialSpecies L == 
add {
         Rep == Set L;
         import from Rep;
         <<implementation: CharacteristicSpecies>>
}
EmptySetSpecies(L: LabelType): CombinatorialSpecies L == {
         CharacteristicSpecies(0$Integer)(L) add;
}

As you see, EmptySetSpecies is a function and its result type depends on 
its input type L.

But I think what you mention about categories is not really connected to 
dependent or not dependent types. I actually don't know how one can 
construct a category at runtime and later use it.

For example,

define Cat: Category == if odd? random() then {with {foo: () -> ()}}
                                          else {with {bar: () -> ()}}

I could define a domain

Dom: Cat == add {
    foo(): () == {}
    bar(): () == {}
}

But how would I use it? At compile time the compiler cannot decide whether

foo()$Dom;

is actually available.

> [ For example, C++ has dependent types at its "template systems" but
>   values are limited to integers and addresses of toplevel entities ]

Could you provide some example code? A link?

> | In fact, there are two things missing in Axiom:
> | 
> | 1) a replacement for SPAD that allows one to use the Aldor language

> Can anyone familiar with integrating SPAD with foreign languages
> educate me about the thorny issues?

What exactly do you mean here?

Ralf


From gdr at integrable-solutions.net  Sat Aug 19 14:08:17 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 19 Aug 2006 20:08:17 +0200
Subject: [Aldor-l] Using Aldor or SPAD
In-Reply-To: <44E74486.1090706@hemmecke.de>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>
	<44E6170B.1020108@hemmecke.de>
	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>
	<9qoduh10ew.fsf@aquin.mat.univie.ac.at>
	<m3hd08et8b.fsf@zeus.integrable-solutions.net>
	<44E74486.1090706@hemmecke.de>
Message-ID: <m3lkpklhta.fsf@zeus.integrable-solutions.net>

Ralf Hemmecke <ralf at hemmecke.de> writes:

| > The only thing I know of the Aldor compiler
| > is that long time ago my "intern-mate" Yannis was working on it at
| > Sophia Antipolis...
| 
| Ah, Yannis Chicha worked with you... This world is so small...

Yup; Yannis hosted me for weeks before I got a place; it must have been
sometime in 1996. Stephen was the project leader at the time.

[...]

| Currently, in aldor-combinat I am going to define something like...
| 
| define CombinatorialSpecies(L: LabelType): Category == with {
|          <<exports: CombinatorialSpecies>>
| }
| CharacteristicSpecies(n:Integer)(L:LabelType): CombinatorialSpecies L == 
| add {
|          Rep == Set L;
|          import from Rep;
|          <<implementation: CharacteristicSpecies>>
| }
| EmptySetSpecies(L: LabelType): CombinatorialSpecies L == {
|          CharacteristicSpecies(0$Integer)(L) add;
| }
| 
| As you see, EmptySetSpecies is a function and its result type depends on 
| its input type L.


Yes. My question is whether "L" can be any value computed at runtime,
or only values known at compile-time.  E.g., do you want to say

   * read in a Label l
   * call CharacteristicSpecies with l

?

If yes, evaluation at compile-time will be very limited.

Or, would you be happy with Label values that are "known" to the
compiler, from "simple" program text analysis?

| But I think what you mention about categories is not really connected to 
| dependent or not dependent types. I actually don't know how one can 
| construct a category at runtime and later use it.
| 
| For example,
| 
| define Cat: Category == if odd? random() then {with {foo: () -> ()}}
|                                           else {with {bar: () -> ()}}
| 
| I could define a domain
| 
| Dom: Cat == add {
|     foo(): () == {}
|     bar(): () == {}
| }
| 
| But how would I use it? At compile time the compiler cannot decide whether
| 
| foo()$Dom;
| 
| is actually available.

Yes, that pushes checking to runtime and inhibit some static
optimizations.  So, I guess, we sort of agree on where to draw the
boundary. 

| > [ For example, C++ has dependent types at its "template systems" but
| >   values are limited to integers and addresses of toplevel entities ]
| 
| Could you provide some example code? A link?

A simple example involving non-type parameter is the classical

   template<tyename T, int N>
     struct buffer {
       T data[N];
     };

here the template buffer is parameterized by a type name and an
integer.  Internally it holds an array of N Ts.  It can be used as

     buffer<int, 512> cache;

or

     buffer<char, 4 * 512> buf;

Notice that the integer argument is anything that can be evaluated at
compile-time such as 512 or 4 * 512.  

| > | In fact, there are two things missing in Axiom:
| > | 
| > | 1) a replacement for SPAD that allows one to use the Aldor language
| 
| > Can anyone familiar with integrating SPAD with foreign languages
| > educate me about the thorny issues?
| 
| What exactly do you mean here?

Well, suppose I'm going to provide a language (that can be an existing
language such as C or Lisp or Aldor) that people use to write
libraries intended to be used with or from Axiom; are are the whoops I
or people would have to jump through?

-- Gaby


From tmgisi at gmx.at  Sun Aug 20 03:23:48 2006
From: tmgisi at gmx.at (Christian Aistleitner)
Date: Sun, 20 Aug 2006 09:23:48 +0200
Subject: [Aldor-l] Using Aldor or SPAD
In-Reply-To: <m3k654ddze.fsf@zeus.integrable-solutions.net>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>
	<44E6170B.1020108@hemmecke.de>
	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>
	<44E63B73.1050403@hemmecke.de>
	<m3ac617kfn.fsf@zeus.integrable-solutions.net>
	<44E6490D.60207@hemmecke.de>
	<op.teiqy4szu6j4vy@spencer.aistleitner.info>
	<m3k654ddze.fsf@zeus.integrable-solutions.net>
Message-ID: <op.tekmty1cu6j4vy@spencer.aistleitner.info>

Hello,

> | I am not sure, to what extend the US law situation is reflected by
> | Canadian, French or British law.
> | However, as (I guess) most of the ppl interested in Aldor, have seen
> | the  compiler's source code, they (probably) should not work on the
> | reimplementation of it.
>
> That is a very good point.  Does that also imply that you cannot
> answer any technical question about the *Aldor language*?

I assume the "you" does not refer to me, but someone having seen the  
compiler sources.
The term "technical question" is rather vague to me in this context.
Up to my knowledge, people having seen the compiler sources may do only  
one thing (in the US): Write specifications.

--
Kind regards,
Christian


From ralf at hemmecke.de  Sun Aug 20 04:01:49 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Sun, 20 Aug 2006 10:01:49 +0200
Subject: [Aldor-l] Using Aldor or SPAD
In-Reply-To: <m3lkpklhta.fsf@zeus.integrable-solutions.net>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>	<44E6170B.1020108@hemmecke.de>	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>	<9qoduh10ew.fsf@aquin.mat.univie.ac.at>	<m3hd08et8b.fsf@zeus.integrable-solutions.net>	<44E74486.1090706@hemmecke.de>
	<m3lkpklhta.fsf@zeus.integrable-solutions.net>
Message-ID: <44E816ED.4040204@hemmecke.de>

> | Currently, in aldor-combinat I am going to define something like...
> | 
> | define CombinatorialSpecies(L: LabelType): Category == with {
> |          <<exports: CombinatorialSpecies>>
> | }
> | CharacteristicSpecies(n:Integer)(L:LabelType): CombinatorialSpecies L == 
> | add {
> |          Rep == Set L;
> |          import from Rep;
> |          <<implementation: CharacteristicSpecies>>
> | }
> | EmptySetSpecies(L: LabelType): CombinatorialSpecies L == {
> |          CharacteristicSpecies(0$Integer)(L) add;
> | }
> | 
> | As you see, EmptySetSpecies is a function and its result type depends on 
> | its input type L.

> Yes. My question is whether "L" can be any value computed at runtime,
> or only values known at compile-time.  E.g., do you want to say
> 
>    * read in a Label l
>    * call CharacteristicSpecies with l
> 
> ?

Species can be substituted. I have not yet put this into the code, but 
in <<exports: CombinatorialSpecies>> you will find LabelType.

So I should be able to read m, n from the command line and say

extend String: LabelType == add;

(currently LabelType == PrimitiveType)

MySpec(L: LabelType): CombinatorialSpecies L == {
     CharacteristicSpecies(n)(CharacteristicSpecies m)(L) add;
}

In the middle of that you have the category

CombinatorialSpecies(CharacteristicSpecies m)

Is that enough to make things complicated?
BTW, I would not want to miss that power of Aldor.
MySpec is just a special case of a "Compose" constructor of species.

> If yes, evaluation at compile-time will be very limited.

Yes, I assume that is a big research topic to make such code efficient. 
I leave that to the compiler people. ;-)

> Or, would you be happy with Label values that are "known" to the
> compiler, from "simple" program text analysis?

The final goal for species is to work with them interactively. So I 
don't care if the interpreter in the middle of the session starts the 
compiler to produce some efficient code for me, but it should be 
possible to produce a "sufficiently efficient" standalone program.

And, in particular for species there seems to be need to call the compiler.

This here is another code piece.

BinaryTree(L: LabelType): CombinatorialSpecies L == {
         macro {
                 + == Plus;
                 * == Times;
                 1 == EmptySetSpecies;
                 X == SingletonSpecies;
                 B == BinaryTree;
         }
         (1 + X * B * B)(L) add;
}

For the full current status of that project see
svn://svn.risc.uni-linz.ac.at/hemmecke/combinat/trunk
and listen at aldor-combinat-devel at lists.sourceforge.net .

In general one would have a set of such recursive "equations". Writing 
my own interpreter for that must invoke the compiler. So I would like 
some language feature to start compilation, otherwise I take the input 
string write it out to a file, invoke the external compiler and then 
link the resulting library (I have no idea how the last thing is done).
But going the external way, my standalone program must know where the 
aldor compiler is on that system. :-(

> | > [ For example, C++ has dependent types at its "template systems" but
> | >   values are limited to integers and addresses of toplevel entities ]
> | 
> | Could you provide some example code? A link?
> 
> A simple example involving non-type parameter is the classical
> 
>    template<tyename T, int N>
>      struct buffer {
>        T data[N];
>      };
> 
> here the template buffer is parameterized by a type name and an
> integer.  Internally it holds an array of N Ts.  It can be used as
> 
>      buffer<int, 512> cache;
> 
> or
> 
>      buffer<char, 4 * 512> buf;
> 
> Notice that the integer argument is anything that can be evaluated at
> compile-time such as 512 or 4 * 512.  

I suspect that it is already hard to simplify 0+0 in Aldor. Suppose you 
write

Dom(X: with {0:%, +: (%, %)->%}): with {...} == add {
     Rep == X;
     local doubleZero: % == per(0 + 0);
     ...
}

The only thing a compiler can do is to produce a generic domain.
No lets suppose I give you the .ao library, but not the .as file.
Then you write a program that somewhere in the middle uses Dom(Integer) 
(where hopefully nobody had redefined 0 or + from Integer). Then I would 
like the executable having the equivalent of

    local doubleZero: Integer == 0;

as binary code. That is though, I guess. But as far as I know the 
current Aldor compiler is already doing such things.

Ralf


From martin.rubey at univie.ac.at  Sun Aug 20 05:14:06 2006
From: martin.rubey at univie.ac.at (Martin Rubey)
Date: 20 Aug 2006 11:14:06 +0200
Subject: [Aldor-l] Using Aldor or SPAD
In-Reply-To: <44E74486.1090706@hemmecke.de>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>
	<44E6170B.1020108@hemmecke.de>
	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>
	<9qoduh10ew.fsf@aquin.mat.univie.ac.at>
	<m3hd08et8b.fsf@zeus.integrable-solutions.net>
	<44E74486.1090706@hemmecke.de>
Message-ID: <9qr6zbzs4h.fsf@login.mat.univie.ac.at>

Ralf Hemmecke <ralf at hemmecke.de> writes:

> For example,
> 
> define Cat: Category == if odd? random() then {with {foo: () -> ()}}
>                                           else {with {bar: () -> ()}}
> 
> I could define a domain
> 
> Dom: Cat == add {
>     foo(): () == {}
>     bar(): () == {}
> }
> 
> But how would I use it? At compile time the compiler cannot decide whether
> 
> foo()$Dom;
> 
> is actually available.

Well, isn't it (currently) possible to ask:

  if Dom has foo then ...

> The final goal for species is to work with them interactively. So I don't
> care if the interpreter in the middle of the session starts the compiler to
> produce some efficient code for me, but it should be possible to produce a
> "sufficiently efficient" standalone program.

Please note that I did write an Aldor program that takes a list of strings (the
specification of a grammar) and that produces the corresponding domain. Thus, I
think that

> And, in particular for species there seems to be need to call the compiler.

is incorrect. To look at it, get 

svn://svn.risc.uni-linz.ac.at/hemmecke/combinat/branches/experiments/rubey

Again:

> In general one would have a set of such recursive "equations". Writing my own
> interpreter for that must invoke the compiler. 

I think that this is not correct. The code is in uc.as.nw

Martin



From ralf at hemmecke.de  Sun Aug 20 07:13:31 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Sun, 20 Aug 2006 13:13:31 +0200
Subject: [Aldor-l] Using Aldor or SPAD
In-Reply-To: <9qr6zbzs4h.fsf@login.mat.univie.ac.at>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>	<44E6170B.1020108@hemmecke.de>	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>	<9qoduh10ew.fsf@aquin.mat.univie.ac.at>	<m3hd08et8b.fsf@zeus.integrable-solutions.net>	<44E74486.1090706@hemmecke.de>
	<9qr6zbzs4h.fsf@login.mat.univie.ac.at>
Message-ID: <44E843DB.8010100@hemmecke.de>

On 08/20/2006 11:14 AM, Martin Rubey wrote:
> Ralf Hemmecke <ralf at hemmecke.de> writes:
> 
>> For example,
>>
>> define Cat: Category == if odd? random() then {with {foo: () -> ()}}
>>                                           else {with {bar: () -> ()}}
>>
>> I could define a domain
>>
>> Dom: Cat == add {
>>     foo(): () == {}
>>     bar(): () == {}
>> }
>>
>> But how would I use it? At compile time the compiler cannot decide whether
>>
>> foo()$Dom;
>>
>> is actually available.
> 
> Well, isn't it (currently) possible to ask:
> 
>   if Dom has foo then ...

Good point. But you perhaps agree that things become cumbersome.

Should the compiler accept the lines

DomFoo: Cat == add {
     foo(): () == {}
}

? Certainly not. I suspect that even with the additional bar function 
the current compiler rejects that.

I haven't yet seen a use case for generation and use of categories at 
runtime. Any theoretical suggestions?

>> The final goal for species is to work with them interactively. So I don't
>> care if the interpreter in the middle of the session starts the compiler to
>> produce some efficient code for me, but it should be possible to produce a
>> "sufficiently efficient" standalone program.
> 
> Please note that I did write an Aldor program that takes a list of strings (the
> specification of a grammar) and that produces the corresponding domain. Thus, I
> think that
> 
>> And, in particular for species there seems to be need to call the compiler.

> is incorrect. To look at it, get 
> 
> svn://svn.risc.uni-linz.ac.at/hemmecke/combinat/branches/experiments/rubey

Martin, your approach seems to work, but I am still not sure whether it 
just works because of the current compiler. I would be happier if I had 
a sound explanation in terms of the *Aldor language* not in terms of the 
*compiler*.

Best regards
Ralf


From martin.rubey at univie.ac.at  Sun Aug 20 08:43:49 2006
From: martin.rubey at univie.ac.at (Martin Rubey)
Date: 20 Aug 2006 14:43:49 +0200
Subject: [Aldor-l] implementing aldor / new species approach
In-Reply-To: <44E843DB.8010100@hemmecke.de>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>
	<44E6170B.1020108@hemmecke.de>
	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>
	<9qoduh10ew.fsf@aquin.mat.univie.ac.at>
	<m3hd08et8b.fsf@zeus.integrable-solutions.net>
	<44E74486.1090706@hemmecke.de> <9qr6zbzs4h.fsf@login.mat.univie.ac.at>
	<44E843DB.8010100@hemmecke.de>
Message-ID: <9qbqqfmvay.fsf_-_@login.mat.univie.ac.at>

Dear all,

Ralf Hemmecke <ralf at hemmecke.de> writes:


> I haven't yet seen a use case for generation and use of categories at
> runtime. Any theoretical suggestions?

Yes. Imposing restrictions is a bad thing. Note that our use of types being
first class objects, in particular my parser, is probably not easy to
foresee. However, it turned out to be very useful. Maybe defining categories on
the fly turns out to be very hip some time.

It would be OK for me though to implement only a part of the Aldor language. In
fact, SPAD implements a subset of the Aldor language, at least roughly. It has
proven to be quite useful, you can even implement a computer algebra system
with it. Only, meanwhile we hit the restrictions on dependent types and types
being first class objects (I.e., List Ring is not allowed), so it is time to
extend it. I wouldn't though it away, unless it turns out that this is
easier. I'd be very happy with the old SPAD compiler, if it would understand
dependent types, at least in the most common cases. And I want to be able to
say l: List Ring := [Integer, Polynomial Integer, PF 5].

Furthermore, I'd like to be able to define domains on the command lines. (It is
not necessary to have Categories on the command line, though. In fact, it seems
that this is too much to ask for, looking at aldor -gloop segfaulting very
often.)

> I wrote:
> > Thus, I think that

> >> And, in particular for species there seems to be need to call the compiler.
> 
> > is incorrect. To look at it, get
> > svn://svn.risc.uni-linz.ac.at/hemmecke/combinat/branches/experiments/rubey
 
> Martin, your approach seems to work, but I am still not sure whether it just
> works because of the current compiler. I would be happier if I had a sound
> explanation in terms of the *Aldor language* not in terms of the *compiler*.

I agree. However, if somebody is going to implement Aldor a second time, I'd
argue that this code working is so useful, that it should be abstracted and
included in the specification.

In fact, I have the feeling that it is not a coincidence that it works. After
all, it works with all compiler settings. Don't worry, I'm not saying that it
should work given the specification of the AUG. I'm only saying that it *might*
be that way. I really hope that we can explain the behaviour. Christian
Aistleitner, did you try?


Ralf: I quite like your new species file. There is so little code in it that
is's got to be the right approach :-) Unfortunately I forgot how to see the
results of the test cases, and my Aldor compiler is on the other end of the
modem only... Did you try to leave away the label parameter? (although that's
one thing I really like! By the way, I guess one can make this parameter
optional, don't you think?)


Martin



From gdr at integrable-solutions.net  Sun Aug 20 09:00:06 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 20 Aug 2006 15:00:06 +0200
Subject: [Aldor-l] Using Aldor or SPAD
In-Reply-To: <op.tekmty1cu6j4vy@spencer.aistleitner.info>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>
	<44E6170B.1020108@hemmecke.de>
	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>
	<44E63B73.1050403@hemmecke.de>
	<m3ac617kfn.fsf@zeus.integrable-solutions.net>
	<44E6490D.60207@hemmecke.de>
	<op.teiqy4szu6j4vy@spencer.aistleitner.info>
	<m3k654ddze.fsf@zeus.integrable-solutions.net>
	<op.tekmty1cu6j4vy@spencer.aistleitner.info>
Message-ID: <m3psev1s15.fsf@zeus.integrable-solutions.net>

"Christian Aistleitner" <tmgisi at gmx.at> writes:

| Hello,
| 
| > | I am not sure, to what extend the US law situation is reflected by
| > | Canadian, French or British law.
| > | However, as (I guess) most of the ppl interested in Aldor, have seen
| > | the  compiler's source code, they (probably) should not work on the
| > | reimplementation of it.
| >
| > That is a very good point.  Does that also imply that you cannot
| > answer any technical question about the *Aldor language*?
| 
| I assume the "you" does not refer to me, but someone having seen the
| compiler sources.

well, I meant you (Christian).

| The term "technical question" is rather vague to me in this context.
| Up to my knowledge, people having seen the compiler sources may do
| only  one thing (in the US): Write specifications.

:-)
-- Gaby


From ralf at hemmecke.de  Sun Aug 20 10:41:36 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Sun, 20 Aug 2006 16:41:36 +0200
Subject: [Aldor-l] implementing aldor / new species approach
In-Reply-To: <9qbqqfmvay.fsf_-_@login.mat.univie.ac.at>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>	<44E6170B.1020108@hemmecke.de>	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>	<9qoduh10ew.fsf@aquin.mat.univie.ac.at>	<m3hd08et8b.fsf@zeus.integrable-solutions.net>	<44E74486.1090706@hemmecke.de>
	<9qr6zbzs4h.fsf@login.mat.univie.ac.at>	<44E843DB.8010100@hemmecke.de>
	<9qbqqfmvay.fsf_-_@login.mat.univie.ac.at>
Message-ID: <44E874A0.3040407@hemmecke.de>

>> Martin, your approach seems to work, but I am still not sure whether it just
>> works because of the current compiler. I would be happier if I had a sound
>> explanation in terms of the *Aldor language* not in terms of the *compiler*.
> 
> I agree. However, if somebody is going to implement Aldor a second time, I'd
> argue that this code working is so useful, that it should be abstracted and
> included in the specification.

Maybe it is already in the specification, but I would like to see 
somebody from aldor.org confirming that it should work.

The code we are speaking about is basically this.

grammar(p: List String): List CombinatorialClass == {
         macro CC == CombinatorialClass;
         import from MachineInteger, List CC;
         A: CC == Atom;
         res: List CC := [A for x in p];
         E(i: MachineInteger): CC == evaluate(parse(p.i), res) add {
#if WantSegfault
#else
                 valuation(): Integer == 1
#endif
         }
         for i in 1..#p repeat res.i := E(i);
         res;
}

p contains a list of strings describing the right hand sides of a set of 
equations. Inside these strings "Self_i" corresponds to the left hand 
side. The left hand sides are assumed to be Self_1,...Self_n.
As you see, first the result list res is initialised by Atom (which is 
just a dummy value). In the for loop at the end the list is 
destructively modified in order to produce the recusively define domains.

Let's abbreviate Self_1 by X and Self_2 by Y. grammar should return a 
list of domains. So what happens if I have the equations

X = Atom * Y
Y = Atom * X

The for loop bothers me. In the first iteration we basically call

evaluate(parse("Atom * Y"), [Atom, Atom])

in the second round we would have

evaluate(parse("Atom * X"), [X,    Atom])

So no matter what evaluate and parse actually do, I simply fear that in 
the end res.1 is not the same domain as res.2 although the above 
equations very much suggest equality.

> Ralf: I quite like your new species file. There is so little code in it that
> is's got to be the right approach :-)

Thanks. It took me long enough to follow the Aldor approach, ie, remove 
restrictions instead of adding functionality. ;-)

> Unfortunately I forgot how to see the
> results of the test cases, and my Aldor compiler is on the other end of the
> modem only... 


 >TestSuited
Looking in BinaryTree(String) for generatingSeries with code 164979209
+--- beginning of test case : TestCombinatorialSpecies
|
|  +--- beginning of test : testBinaryTree
|  | calling setUp function
|  | setUp function finished
|  | ----------------------
|  | calling test function
|  |
|  | failing, because an exception occurred in the test function !
|  | Type:
|  | RuntimeError()
|  | Presentation:
|  | Export not found
|  |
|  | ----------------------
|  | calling tearDown function
|  | tearDown function finished
|  +--- end of test : testBinaryTree( test failed )
|
+--- end of test case       : TestCombinatorialSpecies ( 2 total / 1 
correct / 1 failed tests )


summary of the test suite:
============================

test cases      : 4
tests           : 13
tests succeeded : 12
tests failed    : 1

I don't see how I can go around that "missing function". It should be 
there that is for sure. But maybe blaming the compiler is a bit too early.

> Did you try to leave away the label parameter?

No, I didn't.

 > (although that's one thing I really like! By the way, I guess one can
 > make this parameter optional, don't you think?)

No. By design, you cannot make this optional. Oh, well, perhaps it could 
work, but then you'd have to say EmptySetSpecies() (with parens) since
EmptySetSpecies (without parens is of another type. I am not yet sure 
whether this works, but what do you want it to mean anyway??? What would 
be the default?

Ralf


From daly at axiom-developer.org  Sun Aug 20 11:35:08 2006
From: daly at axiom-developer.org (root)
Date: Sun, 20 Aug 2006 11:35:08 -0400
Subject: [Aldor-l] implementing aldor / new species approach
In-Reply-To: <9qbqqfmvay.fsf_-_@login.mat.univie.ac.at> (message from Martin
	Rubey on 20 Aug 2006 14:43:49 +0200)
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>
	<44E6170B.1020108@hemmecke.de>
	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>
	<9qoduh10ew.fsf@aquin.mat.univie.ac.at>
	<m3hd08et8b.fsf@zeus.integrable-solutions.net>
	<44E74486.1090706@hemmecke.de> <9qr6zbzs4h.fsf@login.mat.univie.ac.at>
	<44E843DB.8010100@hemmecke.de>
	<9qbqqfmvay.fsf_-_@login.mat.univie.ac.at>
Message-ID: <200608201535.k7KFZ8924649@localhost.localdomain>

> It would be OK for me though to implement only a part of the Aldor
> language. In fact, SPAD implements a subset of the Aldor language,
> at least roughly. It has proven to be quite useful, you can even
> implement a computer algebra system with it. Only, meanwhile we hit
> the restrictions on dependent types and types being first class
> objects (I.e., List Ring is not allowed), so it is time to extend
> it. I wouldn't though it away, unless it turns out that this is
> easier. I'd be very happy with the old SPAD compiler, if it would
> understand dependent types, at least in the most common cases. And I
> want to be able to say l: List Ring := [Integer, Polynomial Integer,
> PF 5].

Ring is implemented as a lisp object. You can put these into a list.

There is no inherent restriction on creating lists of domains
except for the spad compiler, which can be changed.

t


From gdr at integrable-solutions.net  Sun Aug 20 14:26:10 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 20 Aug 2006 20:26:10 +0200
Subject: [Aldor-l] Using Aldor or SPAD
In-Reply-To: <023f01c6c2f2$c93b51e0$6900a8c0@asus>
References: <023f01c6c2f2$c93b51e0$6900a8c0@asus>
Message-ID: <m3oduf462l.fsf@zeus.integrable-solutions.net>

"Bill Page" <bill.page1 at synthesis.anikast.ca> writes:

| On August 18, 2006 1:49 PM Martin Rubey wrote:
| > 
| > Gabriel Dos Reis writes:
| > 
| > > I've been writing more and more SPAD, less and less Aldor. 
| > > And I suspect very soon my students will more SPAD than 
| > > Aldor, however imperfect SPAD...
| > 
| > why is that? I really can't understand, there are so many 
| > things missing in spad!
| > 
| 
| Ya, like error message a human can understand, for one! :)

Yup :-(

[ error message from C++ compilers with respect to templates look quite
  highly intelligible when compared to what the SPAD compiler spits
  out :-(]

-- Gaby


From martin.rubey at univie.ac.at  Sun Aug 20 15:54:32 2006
From: martin.rubey at univie.ac.at (Martin Rubey)
Date: 20 Aug 2006 21:54:32 +0200
Subject: [Aldor-l] implementing aldor / new species approach
In-Reply-To: <200608201535.k7KFZ8924649@localhost.localdomain>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>
	<44E6170B.1020108@hemmecke.de>
	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>
	<9qoduh10ew.fsf@aquin.mat.univie.ac.at>
	<m3hd08et8b.fsf@zeus.integrable-solutions.net>
	<44E74486.1090706@hemmecke.de> <9qr6zbzs4h.fsf@login.mat.univie.ac.at>
	<44E843DB.8010100@hemmecke.de>
	<9qbqqfmvay.fsf_-_@login.mat.univie.ac.at>
	<200608201535.k7KFZ8924649@localhost.localdomain>
Message-ID: <9qhd0718uf.fsf@login.mat.univie.ac.at>

root <daly at axiom-developer.org> writes:

> Ring is implemented as a lisp object. You can put these into a list.

(2) -> l : List Ring := [Integer]
 
   Cannot convert an element of the construct to type Any .
(2) -> l : Ring := Integer
 
   Ring is a category, not a domain, and declarations require domains.

Martin

PS: PLEASE (!!!!) copy to aldor-combinat only stuff specific to the combinat project!



From tmgisi at gmx.at  Wed Aug 23 09:45:25 2006
From: tmgisi at gmx.at (Christian Aistleitner)
Date: Wed, 23 Aug 2006 15:45:25 +0200
Subject: [Aldor-l] Using Aldor or SPAD
In-Reply-To: <m3psev1s15.fsf@zeus.integrable-solutions.net>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>
	<44E6170B.1020108@hemmecke.de>
	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>
	<44E63B73.1050403@hemmecke.de>
	<m3ac617kfn.fsf@zeus.integrable-solutions.net>
	<44E6490D.60207@hemmecke.de>
	<op.teiqy4szu6j4vy@spencer.aistleitner.info>
	<m3k654ddze.fsf@zeus.integrable-solutions.net>
	<op.tekmty1cu6j4vy@spencer.aistleitner.info>
	<m3psev1s15.fsf@zeus.integrable-solutions.net>
Message-ID: <op.teqohzvhu6j4vy@spencer.aistleitner.info>

Hello,

> | > | I am not sure, to what extend the US law situation is reflected by
> | > | Canadian, French or British law.
> | > | However, as (I guess) most of the ppl interested in Aldor, have  
> seen
> | > | the  compiler's source code, they (probably) should not work on the
> | > | reimplementation of it.
> | >
> | > That is a very good point.  Does that also imply that you cannot
> | > answer any technical question about the *Aldor language*?
> |
> | I assume the "you" does not refer to me, but someone having seen the
> | compiler sources.
>
> well, I meant you (Christian).

ok. If its about me, I'll shift to a private discussion.

--
Kind regards,
Christian


From tmgisi at gmx.at  Wed Aug 23 10:48:04 2006
From: tmgisi at gmx.at (Christian Aistleitner)
Date: Wed, 23 Aug 2006 16:48:04 +0200
Subject: [Aldor-l] implementing aldor / new species approach
In-Reply-To: <9qbqqfmvay.fsf_-_@login.mat.univie.ac.at>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>
	<44E6170B.1020108@hemmecke.de>
	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>
	<9qoduh10ew.fsf@aquin.mat.univie.ac.at>
	<m3hd08et8b.fsf@zeus.integrable-solutions.net>
	<44E74486.1090706@hemmecke.de>
	<9qr6zbzs4h.fsf@login.mat.univie.ac.at>
	<44E843DB.8010100@hemmecke.de>
	<9qbqqfmvay.fsf_-_@login.mat.univie.ac.at>
Message-ID: <op.teqreec6u6j4vy@spencer.aistleitner.info>

Hello,

>> Martin, your approach seems to work, but I am still not sure whether it  
>> just
>> works because of the current compiler. I would be happier if I had a  
>> sound
>> explanation in terms of the *Aldor language* not in terms of the  
>> *compiler*.
>
> I agree. However, if somebody is going to implement Aldor a second time,  
> I'd
> argue that this code working is so useful, that it should be abstracted  
> and
> included in the specification.

No. I would not add it to the specification. I always argued that such  
code is a potential problem. What it all comes down to is building a  
domain and _afterwards_ exchanging its parameters with different values.
Its plainly a trick thats working -- currently.
The reason why it is working, we can only guess.

> In fact, I have the feeling that it is not a coincidence that it works.  
> After
> all, it works with all compiler settings. Don't worry, I'm not saying  
> that it
> should work given the specification of the AUG. I'm only saying that it  
> *might*
> be that way. I really hope that we can explain the behaviour. Christian
> Aistleitner, did you try?

I tried. Several times. Maybe lazy instantiation (as hinted in the AUG).  
Maybe something completely different. Maybe even a compiler bug.

But please replace my name by "Stephen Watt", "Laurentiu Dragan", or any  
the name of any other Aldor people.

--
Kind regards,
Christian


From gdr at integrable-solutions.net  Fri Aug 18 12:57:32 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 18 Aug 2006 18:57:32 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <9qsljx3hur.fsf@aquin.mat.univie.ac.at>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<20060812141942.GA30663@ptibonum.scl.csd.uwo.ca>
	<20060812224638.GA5946@aquarium.aldor.org>
	<20060812225529.GC11239@ptibonum.scl.csd.uwo.ca>
	<op.td7vonx2u6j4vy@spencer.aistleitner.info>
	<200608140525.k7E5PYG11880@localhost.localdomain>
	<op.td9u55gju6j4vy@spencer.aistleitner.info>
	<9qsljx3hur.fsf@aquin.mat.univie.ac.at>
Message-ID: <m3d5ay6kxv.fsf@zeus.integrable-solutions.net>

Martin Rubey <martin.rubey at univie.ac.at> writes:


[...]

|   I don't think that there are many SPAD programmers left. Antoine codes in
|   Aldor, so does Ralf, I nearly do. Who else has written something recently?

I've been writing more and more SPAD, less and less Aldor. 
And I suspect very soon my students will more SPAD than Aldor, however
imperfect SPAD...

-- Gaby


From martin.rubey at univie.ac.at  Fri Aug 18 13:48:41 2006
From: martin.rubey at univie.ac.at (Martin Rubey)
Date: 18 Aug 2006 19:48:41 +0200
Subject: [Aldor-l] Using Aldor or SPAD
In-Reply-To: <m3d5ay6kxv.fsf@zeus.integrable-solutions.net>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<20060812141942.GA30663@ptibonum.scl.csd.uwo.ca>
	<20060812224638.GA5946@aquarium.aldor.org>
	<20060812225529.GC11239@ptibonum.scl.csd.uwo.ca>
	<op.td7vonx2u6j4vy@spencer.aistleitner.info>
	<200608140525.k7E5PYG11880@localhost.localdomain>
	<op.td9u55gju6j4vy@spencer.aistleitner.info>
	<9qsljx3hur.fsf@aquin.mat.univie.ac.at>
	<m3d5ay6kxv.fsf@zeus.integrable-solutions.net>
Message-ID: <9q3bbuue86.fsf_-_@login.mat.univie.ac.at>

Gabriel Dos Reis <gdr at integrable-solutions.net> writes:

> I've been writing more and more SPAD, less and less Aldor. 
> And I suspect very soon my students will more SPAD than Aldor, however
> imperfect SPAD...

why is that? I really can't understand, there are so many things missing in
spad!

Martin



From gdr at integrable-solutions.net  Fri Aug 18 15:57:09 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 18 Aug 2006 21:57:09 +0200
Subject: [Aldor-l] Using Aldor or SPAD
In-Reply-To: <9q3bbuue86.fsf_-_@login.mat.univie.ac.at>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<20060812141942.GA30663@ptibonum.scl.csd.uwo.ca>
	<20060812224638.GA5946@aquarium.aldor.org>
	<20060812225529.GC11239@ptibonum.scl.csd.uwo.ca>
	<op.td7vonx2u6j4vy@spencer.aistleitner.info>
	<200608140525.k7E5PYG11880@localhost.localdomain>
	<op.td9u55gju6j4vy@spencer.aistleitner.info>
	<9qsljx3hur.fsf@aquin.mat.univie.ac.at>
	<m3d5ay6kxv.fsf@zeus.integrable-solutions.net>
	<9q3bbuue86.fsf_-_@login.mat.univie.ac.at>
Message-ID: <m34pw9bywa.fsf@zeus.integrable-solutions.net>

Martin Rubey <martin.rubey at univie.ac.at> writes:

| Gabriel Dos Reis <gdr at integrable-solutions.net> writes:
| 
| > I've been writing more and more SPAD, less and less Aldor. 
| > And I suspect very soon my students will more SPAD than Aldor, however
| > imperfect SPAD...
| 
| why is that?

Lack of a working compiler that runs on my systems and students'.

I've read suggestions that people should downgrade to older GCC.
This is something I will NOT recommend.
If recent version of GCC cannot work with Aldor, why should I expect
my systems to work properly with older versions of GCC when they
are packaged with recent version of GCC?

| I really can't understand, there are so many things missing in
| spad!

No doubt many things are missing.  But, at least I can build a working
compiler and work with it on my current systems.  I can even show
students how it is programed to work -- however disguisting the
innards may be. 

-- Gaby



From martin.rubey at univie.ac.at  Thu Aug 24 07:16:56 2006
From: martin.rubey at univie.ac.at (Martin Rubey)
Date: 24 Aug 2006 13:16:56 +0200
Subject: [Aldor-l] [Axiom-developer] spad: language and compiler
In-Reply-To: <m3u042a0jv.fsf@zeus.integrable-solutions.net>
References: <20060823223817.54667.qmail@web56710.mail.re3.yahoo.com>
	<m3u042a0jv.fsf@zeus.integrable-solutions.net>
Message-ID: <9qk64ycriv.fsf@login.mat.univie.ac.at>

Gabriel Dos Reis <gdr at integrable-solutions.net> writes:

> I know Martin has examples for dependent types.  Are those the only things we
> are missing?

Yes:

* types being first class objects, i.e., being able to have a list of Rings.

Examples:

f(m: INT, n: INT): PF n == m::PF(n)

[f(100, n) for n in primes(1,100)]

L := [PF(n) for n in primes(1,100)]

[a::P for P in L]

> My take is that the improvement to the SPAD compiler, first, needs to be
> driven by needs we have for writing Axiom libraries.

If we had dependent types, we could get rid of "Any" in the series
operations. If we have both of the above, Combinat will work in Axiom.

By the way, I think it is more important to make the interpreter understand
these things. Since:

* it would maybe be easier, I guess 

* we have to do it anyway: having the compiler understand won't help since we
                           couldn't use it in the interpreter

                           the aldor interpreter doesn't work too well

* we could use aldor meanwhile

* it will help us understand the issues involved, I guess


> We need a clearer type system and semantics description -- this independently
> of whether we convert to Aldor or not.

As far as I know, the SPAD implementation does not "conflict" with the Aldor
language. I.e., those concepts that are present work just as specified in the
Aldor User Guide.

So, this amounts to clarifying the Aldor User guide. Quite a bit of work has
been done on this side. Consult the archives or ask specific questions on
aldor-devel.

> Jaakko and I are interested in the dependent type system aspect, 

great!

> If people can look at the existing Axiom libraries (of planned libraries)
> souces and say what they would like to express _directly_ -- assuming they
> had the linguistic constructs -- that would help us shape directions for the
> SPAD language and compiler.

I think, that the series stuff in the algebra(SPAD) library and our species
stuff serve as very good examples for the things I personally would like to
have. I would really like you to start on that one :-)

BTW, I think that there is no SPAD language, only a SPAD implementation. There
is however an Aldor language (more or less) and an Aldor
implementation. Fortunately, the SPAD implementation implements a subset (in
some sense) of the Aldor language.

> It is important we aim at "ideal expression", not just limited to what the
> current SPAD or Aldor languages accept (hi Martin, Ralf).

I think that we first need to explore the possibilities of the Aldor language
before we embark to modify it. When we do, I think the thesis of Nic Doye is a
good starting point, as well as FOCAL by Renaud Rioboo and THEOREMA by
Buchberger et al.,

> Of course, we have gotten the lisp problem.  I don't volunteer to
> attack that one yet.  :-/  

for the interpreter I guess that this is nearly a must (or was it BOOT?).Unless
you rewrite it from scratch. In this case, Aldor would be a natural choice, I
guess. Christian has a parser written in Aldor, but you know that.

> However, I have the desire to target not just Lisp, but C, C++ and probably
> Java or C#.  There are interesting problems lurking there, but not none that
> is urgent.

So, that's a point for FOAM :-)

Martin



From ralf at hemmecke.de  Thu Aug 24 07:50:09 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Thu, 24 Aug 2006 13:50:09 +0200
Subject: [Aldor-l] [Axiom-developer] spad: language and compiler
In-Reply-To: <9qk64ycriv.fsf@login.mat.univie.ac.at>
References: <20060823223817.54667.qmail@web56710.mail.re3.yahoo.com>	<m3u042a0jv.fsf@zeus.integrable-solutions.net>
	<9qk64ycriv.fsf@login.mat.univie.ac.at>
Message-ID: <44ED9271.4090106@hemmecke.de>

> f(m: INT, n: INT): PF n == m::PF(n)
> 
> [f(100, n) for n in primes(1,100)]

Ask yourself, what type that list will have and you realise that Aldor 
will reject that its compilation.

> L := [PF(n) for n in primes(1,100)]

That is fine, though.

> [a::P for P in L]

That is as problematic as the first list.

> So, this amounts to clarifying the Aldor User guide. Quite a bit of work has
> been done on this side. Consult the archives or ask specific questions on
> aldor-devel.

aldor-l at aldor.org to be precise.

> BTW, I think that there is no SPAD language, only a SPAD implementation.

That's a good one. There is an implementation of a non-language. How 
could someone have implemented that?

>> It is important we aim at "ideal expression", not just limited to what the
>> current SPAD or Aldor languages accept (hi Martin, Ralf).

I am all with you, Gaby, As you know, I would like to see support for 
formal specification inside the language. An Aldor program should allow 
to be fed to a proof checker, so I would like to be able to express 
invariants and all that stuff formally and not just in the documentation.

>> However, I have the desire to target not just Lisp, but C, C++ and probably
>> Java or C#.  There are interesting problems lurking there, but not none that
>> is urgent.
> 
> So, that's a point for FOAM :-)

I also think so. You can completely forget about Aldor if you just want 
to generate different target languages. That is as I understand the foam 
business.

Ralf


From martin.rubey at univie.ac.at  Thu Aug 24 08:38:19 2006
From: martin.rubey at univie.ac.at (Martin Rubey)
Date: 24 Aug 2006 14:38:19 +0200
Subject: [Aldor-l] [Axiom-developer] spad: language and compiler
In-Reply-To: <44ED9271.4090106@hemmecke.de>
References: <20060823223817.54667.qmail@web56710.mail.re3.yahoo.com>
	<m3u042a0jv.fsf@zeus.integrable-solutions.net>
	<9qk64ycriv.fsf@login.mat.univie.ac.at> <44ED9271.4090106@hemmecke.de>
Message-ID: <9qhd02mhqc.fsf@login.mat.univie.ac.at>

Ralf Hemmecke <ralf at hemmecke.de> writes:

> > f(m: INT, n: INT): PF n == m::PF(n)
that's OK.


> > [f(100, n) for n in primes(1,100)]
that's stupid.

> Ask yourself, what type that list will have and you realise that Aldor will
> reject that its compilation.
Excuse me, Gaby. Sorry about being so stupid.


> > [a::P for P in L]
> That is as problematic as the first list.
"problematic" is an understatement. Sorry.

> > BTW, I think that there is no SPAD language, only a SPAD implementation.
> 
> That's a good one. There is an implementation of a non-language. How could
> someone have implemented that?

Quite unbelievable, isn't it? (Maybe I'm being too critical though. I wouldn't
call Basic a "language" in the sense I'm trying to establish here. I probably
should have said: specification)


Martin



From ralf at hemmecke.de  Thu Aug 24 12:18:55 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Thu, 24 Aug 2006 18:18:55 +0200
Subject: [Aldor-l] Surprising compiler...
Message-ID: <44EDD16F.3050700@hemmecke.de>

It seems that the compiler people are kind of funny...

"csseries.as", line 164:
local (x: %) * (y: %): Generator Integer == generate {
.....................................................^
[L164 C54] #4 (Fatal Error) Compiler bug: no exit list for 
terrorSequence (ooops).

Anyway, that doesn't help me too much. :-(

Ralf


From martin.rubey at univie.ac.at  Thu Aug 24 13:31:26 2006
From: martin.rubey at univie.ac.at (Martin Rubey)
Date: 24 Aug 2006 19:31:26 +0200
Subject: [Aldor-l] question about set! in streams
In-Reply-To: <44EDAB23.7040705@hemmecke.de>
References: <44E81C24.1060400@hemmecke.de>
	<op.ter3smwlu6j4vy@spencer.aistleitner.info>
	<44ED6849.8070007@hemmecke.de> <9qmz9u7btp.fsf@login.mat.univie.ac.at>
	<44ED7045.7070105@risc.uni-linz.ac.at>
	<9qu0424bu8.fsf@login.mat.univie.ac.at> <44ED9336.8030107@hemmecke.de>
	<9qsljm4767.fsf@login.mat.univie.ac.at> <44EDAB23.7040705@hemmecke.de>
Message-ID: <9q8xle6nwx.fsf_-_@login.mat.univie.ac.at>

Dear all,

I'm just attempting to solve the initial values problem. However I stepped on
an Aldor problem.

Can somebody explain the output of the attached program to me?

WARNING: it enters an infinite loop.

The output begins with
-------------------------------------------------------------------------------
set!01
set!end
Hi
set!01
coeff0
coeff0
coeff0
coeff0
coeff0
-------------------------------------------------------------------------------

and goes on with coeff0 forever...

Short explanation: The following program works as expected. Its output is
simply

-------------------------------------------------------------------------------
set!01
-------------------------------------------------------------------------------

i.e., coefficient is never called.

#include "aldor"
#include "aldorio"


define GeneratingSeriesCategory: Category == with {
        0: %;
        coefficient: (%, Integer) -> Integer;
        set!: (%, Integer, Integer) -> Integer;
}
GeneratingSeries: GeneratingSeriesCategory == add {
        Rep == Stream Integer;
        import from Integer, Rep, MachineInteger;
        0: % == per stream(0);
        coefficient(x: %, n: Integer): Integer == {
                stdout << "coeff" << n << newline;      
                (rep x).(machine n);
        }
        set!(x: %, n: Integer, v: Integer): Integer == {
                stdout << "set!" << n << v << newline;  
                set!(rep x, machine n, v);
        }
}
test(): () == {
        import from Integer;
        g: GeneratingSeries;
        set!(g, 0, 1);
}
test();

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------

The story is different for the following program, where some recursion is
taking place. Note that generatingSeries$MyList is defined in terms of
itself. Still, I don't understand why coefficient is called. Is there a way to
modify generatingSeries$MyList without having coefficient called?

!!!PLEASE HELP!!!

Martin

-------------------------------------------------------------------------------
#include "aldor"
#include "aldorio"

define GeneratingSeriesCategory: Category == with {
        0: %;
        coerce: Stream Integer -> %;
        coefficient: (%, Integer) -> Integer;
        set!: (%, Integer, Integer) -> Integer;
        +: (%, %) -> %;
        *: (%, %) -> %; 
}
GeneratingSeries: GeneratingSeriesCategory == add {
        Rep == Stream Integer;
        import from Integer, Rep, MachineInteger;
        0: % == per stream(0);
        coerce(s: Stream Integer): % == per s;
        coefficient(x: %, n: Integer): Integer == {
                stdout << "coeff" << n << newline;      
                (rep x).(machine n);
        }
        set!(x: %, n: Integer, v: Integer): Integer == {
                stdout << "set!" << n << v << newline;  
                z := set!(rep x, machine n, v);
                stdout << "set!end" << newline; 
                z;
        }
        
        (x: %) + (y: %): % == per stream(0$I, (n:MachineInteger):Integer 
                                              +-> (rep x).n + (rep y).n);

        (x: %) * (y: %): % == {
                local coeffTimes(nMI: MachineInteger): Integer == {
                        local n       : Integer := nMI::Integer;
                        local startIdx: Integer := 0;
                        local endIdx  : Integer := n;       
  
--                      if zero? ( coefficient( x, 0 ) ) then
--                      {
--                              startIdx := 1;
--                      }

                        z: Integer := 0;
                        for k in startIdx .. endIdx repeat {
                                z := z + coefficient( x, k ) 
                                       * coefficient( y, (n-k) );
                        }
                        z;
                }               
                per stream(0$MachineInteger, coeffTimes);
        }
}

define CombinatorialSpecies(L: PrimitiveType): Category == with {
        generatingSeries: GeneratingSeries;
}

CharacteristicSpecies(n:Integer)(L:PrimitiveType): CombinatorialSpecies L == 
    add {
        Rep == Set L;
        nn: MachineInteger == machine n;
        nth(k: MachineInteger): Integer == if k = nn then return 1 else 0;
        import from Rep;
        generatingSeries: GeneratingSeries == {
                import from Stream Integer;
                stream(0, nth, next nn, 0) :: GeneratingSeries;
        }
}


1(L: PrimitiveType): CombinatorialSpecies L == 
        CharacteristicSpecies(0$Integer)(L);

X(L: PrimitiveType): CombinatorialSpecies L == 
        CharacteristicSpecies(1$Integer)(L);

(+)(
    F: (T: PrimitiveType) -> CombinatorialSpecies(T),
    G: (T: PrimitiveType) -> CombinatorialSpecies(T)
): (L: PrimitiveType) -> CombinatorialSpecies(L) == (L: PrimitiveType):
    CombinatorialSpecies(L) +-> add {
        generatingSeries: GeneratingSeries == generatingSeries$F(L) +
    generatingSeries$G(L);
}

(*)(
    F: (T: PrimitiveType) -> CombinatorialSpecies(T),
    G: (T: PrimitiveType) -> CombinatorialSpecies(T)
): (L: PrimitiveType) -> CombinatorialSpecies(L) == (L: PrimitiveType):
    CombinatorialSpecies(L) +-> add {
        generatingSeries: GeneratingSeries == {
                import from Stream Integer;
                coerce stream( 0$MachineInteger, 
                    (n:MachineInteger):Integer +-> 
                              coefficient(generatingSeries$F(L) *
                                          generatingSeries$G(L), n::Integer) );
        }
}

MyList(L: PrimitiveType): CombinatorialSpecies L == ( 1 + X*MyList*MyList)(L);

testMyList(): () == {
        import from Integer, String, MyList String;
        h: GeneratingSeries := 0;
        set!(h, 0, 1);
        g: GeneratingSeries := generatingSeries;
        stdout << "Hi" << newline; -- until here everything works just fine     
        set!(g, 0, 1);
}
testMyList();

-------------------------------------------------------------------------------



From martin.rubey at univie.ac.at  Thu Aug 24 14:18:57 2006
From: martin.rubey at univie.ac.at (Martin Rubey)
Date: 24 Aug 2006 20:18:57 +0200
Subject: [Aldor-l] question about set! in streams / shorter example
In-Reply-To: <9q8xle6nwx.fsf_-_@login.mat.univie.ac.at>
References: <44E81C24.1060400@hemmecke.de>
	<op.ter3smwlu6j4vy@spencer.aistleitner.info>
	<44ED6849.8070007@hemmecke.de> <9qmz9u7btp.fsf@login.mat.univie.ac.at>
	<44ED7045.7070105@risc.uni-linz.ac.at>
	<9qu0424bu8.fsf@login.mat.univie.ac.at> <44ED9336.8030107@hemmecke.de>
	<9qsljm4767.fsf@login.mat.univie.ac.at> <44EDAB23.7040705@hemmecke.de>
	<9q8xle6nwx.fsf_-_@login.mat.univie.ac.at>
Message-ID: <9qirkiro8e.fsf_-_@login.mat.univie.ac.at>

I have a much shorter example for my question now:
-------------------------------------------------------------------------------
#include "aldor"
#include "aldorio"


define GeneratingSeriesCategory: Category == with {
        coerce: Stream Integer -> %;    
        set!: (%, Integer, Integer) -> Integer;
}
GeneratingSeries: GeneratingSeriesCategory == add {
        Rep == Stream Integer;
        import from Integer, Rep, MachineInteger;
        coerce(s: Stream Integer): % == per s;

        set!(x: %, n: Integer, v: Integer): Integer == {
                stdout << "set! " << n << " " << v << newline;  
                set!(rep x, machine n, v);
        }
}
test(): () == {
        import from Integer, Stream Integer;
        g: GeneratingSeries := coerce stream(0$MachineInteger, 
                                             (n:MachineInteger):Integer +-> {
                                                     stdout << "gen " << n
                                                            << newline;  
                                                     n::Integer} );
        stdout << "Start" << newline;                                                    
        set!(g, 0, 1);
        stdout << "Middle" << newline;          
        set!(g, 0, 2);  
        stdout << "End" << newline;     
}
test();
-------------------------------------------------------------------------------

the output is:

Start
set! 0 1
gen 0
Middle
set! 0 2
End

and the question is:

WHY IS gen 0 APPEARING?

Please help!

Martin



From martin.rubey at univie.ac.at  Thu Aug 24 14:56:25 2006
From: martin.rubey at univie.ac.at (Martin Rubey)
Date: 24 Aug 2006 20:56:25 +0200
Subject: [Aldor-l] question about set! in streams / even shorter
In-Reply-To: <9qirkiro8e.fsf_-_@login.mat.univie.ac.at>
References: <44E81C24.1060400@hemmecke.de>
	<op.ter3smwlu6j4vy@spencer.aistleitner.info>
	<44ED6849.8070007@hemmecke.de> <9qmz9u7btp.fsf@login.mat.univie.ac.at>
	<44ED7045.7070105@risc.uni-linz.ac.at>
	<9qu0424bu8.fsf@login.mat.univie.ac.at> <44ED9336.8030107@hemmecke.de>
	<9qsljm4767.fsf@login.mat.univie.ac.at> <44EDAB23.7040705@hemmecke.de>
	<9q8xle6nwx.fsf_-_@login.mat.univie.ac.at>
	<9qirkiro8e.fsf_-_@login.mat.univie.ac.at>
Message-ID: <9qy7teync6.fsf_-_@login.mat.univie.ac.at>

Finally, I think I have the ultimate way to formulate my question:

For a Stream, why does set! compute the element I want to modify destructively?

Suppose I have a stream of the form s := stream(0, f) and I say

set!(s, 0, 1783);

why on earth is f(0) computed? Is there a way around that? Unfortunately, the
stream is already given. It is not an option to define it differently in the
first place.

Martin



From ralf at hemmecke.de  Thu Aug 24 15:19:30 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Thu, 24 Aug 2006 21:19:30 +0200
Subject: [Aldor-l] question about set! in streams / even shorter
In-Reply-To: <9qy7teync6.fsf_-_@login.mat.univie.ac.at>
References: <44E81C24.1060400@hemmecke.de>	<op.ter3smwlu6j4vy@spencer.aistleitner.info>	<44ED6849.8070007@hemmecke.de>
	<9qmz9u7btp.fsf@login.mat.univie.ac.at>	<44ED7045.7070105@risc.uni-linz.ac.at>	<9qu0424bu8.fsf@login.mat.univie.ac.at>
	<44ED9336.8030107@hemmecke.de>	<9qsljm4767.fsf@login.mat.univie.ac.at>
	<44EDAB23.7040705@hemmecke.de>	<9q8xle6nwx.fsf_-_@login.mat.univie.ac.at>	<9qirkiro8e.fsf_-_@login.mat.univie.ac.at>
	<9qy7teync6.fsf_-_@login.mat.univie.ac.at>
Message-ID: <44EDFBC2.7020607@hemmecke.de>

On 08/24/2006 08:56 PM, Martin Rubey wrote:
> Finally, I think I have the ultimate way to formulate my question:
> 
> For a Stream, why does set! compute the element I want to modify destructively?
> 
> Suppose I have a stream of the form s := stream(0, f) and I say
> 
> set!(s, 0, 1783);
> 
> why on earth is f(0) computed?

That is simple. Internally a stream is an Array(T) + a function
next: () -> T that computes the next element. If set! would not compute 
f(0) (which means: call next() and store the value into the zeroth 
position of the array), then the "next" function would be wrong since it 
then is called for the first time to compute f(1), but remember, it is 
called for the first time and so would assign to the array in position 1 
what was actually meant for position 0.

> Is there a way around that? Unfortunately, the
> stream is already given. It is not an option to define it differently in the
> first place.

But you can define your own Stream. I more or less have already done so.
But I restrict to the stuff we need in aldor-combinat.

Ralf


From martin.rubey at univie.ac.at  Thu Aug 24 16:04:14 2006
From: martin.rubey at univie.ac.at (Martin Rubey)
Date: 24 Aug 2006 22:04:14 +0200
Subject: [Aldor-l] question about set! in streams / even shorter
In-Reply-To: <44EDFBC2.7020607@hemmecke.de>
References: <44E81C24.1060400@hemmecke.de>
	<op.ter3smwlu6j4vy@spencer.aistleitner.info>
	<44ED6849.8070007@hemmecke.de> <9qmz9u7btp.fsf@login.mat.univie.ac.at>
	<44ED7045.7070105@risc.uni-linz.ac.at>
	<9qu0424bu8.fsf@login.mat.univie.ac.at> <44ED9336.8030107@hemmecke.de>
	<9qsljm4767.fsf@login.mat.univie.ac.at> <44EDAB23.7040705@hemmecke.de>
	<9q8xle6nwx.fsf_-_@login.mat.univie.ac.at>
	<9qirkiro8e.fsf_-_@login.mat.univie.ac.at>
	<9qy7teync6.fsf_-_@login.mat.univie.ac.at>
	<44EDFBC2.7020607@hemmecke.de>
Message-ID: <9qodu9gatd.fsf@login.mat.univie.ac.at>

Ralf Hemmecke <ralf at hemmecke.de> writes:

> On 08/24/2006 08:56 PM, Martin Rubey wrote:
> > Finally, I think I have the ultimate way to formulate my question:
> > For a Stream, why does set! compute the element I want to modify
> > destructively?
> > Suppose I have a stream of the form s := stream(0, f) and I say
> > set!(s, 0, 1783);
> > why on earth is f(0) computed?
> 
> That is simple. Internally a stream is an Array(T) + a function next: () -> T
> that computes the next element. If set! would not compute f(0) (which means:
> call next() and store the value into the zeroth position of the array), then
> the "next" function would be wrong since it then is called for the first time
> to compute f(1), but remember, it is called for the first time and so would
> assign to the array in position 1 what was actually meant for position 0.

Ah, that makes sense. That is, stream doesn't use n +-> f(n) but rather a
function derived from that one.

Is there a way to delete an element from a stream? Eg., in Axiom one can say

delete(s, 2) 

(s being a Stream) and gets the Stream s.1, s.3, s.4,...

Martin



From ralf at hemmecke.de  Thu Aug 24 16:18:09 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Thu, 24 Aug 2006 22:18:09 +0200
Subject: [Aldor-l] question about set! in streams / even shorter
In-Reply-To: <9qodu9gatd.fsf@login.mat.univie.ac.at>
References: <44E81C24.1060400@hemmecke.de>	<op.ter3smwlu6j4vy@spencer.aistleitner.info>	<44ED6849.8070007@hemmecke.de>
	<9qmz9u7btp.fsf@login.mat.univie.ac.at>	<44ED7045.7070105@risc.uni-linz.ac.at>	<9qu0424bu8.fsf@login.mat.univie.ac.at>
	<44ED9336.8030107@hemmecke.de>	<9qsljm4767.fsf@login.mat.univie.ac.at>
	<44EDAB23.7040705@hemmecke.de>	<9q8xle6nwx.fsf_-_@login.mat.univie.ac.at>	<9qirkiro8e.fsf_-_@login.mat.univie.ac.at>	<9qy7teync6.fsf_-_@login.mat.univie.ac.at>	<44EDFBC2.7020607@hemmecke.de>
	<9qodu9gatd.fsf@login.mat.univie.ac.at>
Message-ID: <44EE0981.3000909@hemmecke.de>

> Is there a way to delete an element from a stream? Eg., in Axiom one can say

> delete(s, 2) 

> (s being a Stream) and gets the Stream s.1, s.3, s.4,...

The API of LibAldor doesn't show such a delete. But of course it would 
be easy to greate such a stream.

delete(s: Stream T, n: MachineInteger): Stream T == {
     g: Generator T == generate {
         for i in 0 .. for t in s repeat if i ~= n then yield t;
     }
     stream g;
}

Ralf


From ralf at hemmecke.de  Fri Aug 25 16:01:19 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Fri, 25 Aug 2006 22:01:19 +0200
Subject: [Aldor-l] How to emulate new infix and postfix operators in Aldor
Message-ID: <44EF570F.2020809@hemmecke.de>

Hello,

I think some of you might find this interesting ...

*Question:* Aldor has a number of infix operators (AUG Sect 4.4). Can 
one define other infix operators?

*Answer:* No.

*Question:* Aldor has a number of postfix operators (notably ".."). Can 
one define other postfix operators?

*Answer:* No.

*Question:* Can one experiment with syntactic sugar in Aldor?

*Anser:* *YES!!!*

---BEGIN aaaInfixPostfix.as
#include "aldor"
#include "aldorio"

macro Z == Integer;

extend Z: with {
	apply: (Z, Z -> Z) -> Z;
} == add {
	apply(z: Z, f: Z -> Z): Z == f z;
}
main(): () == {
	_42 := "I am forty-two."; -- _42 is an identifier.
	stdout << _42 << newline;
	
	_!(z: Z): Z == {zero? z => 1; z * (z-1)_!;}
	z: Z := 4 _!;
	stdout << z << newline;

	x(a: Z)(b: Z): Z == a*b;
	z := 4 x 5 x 2;
	stdout << z << newline;
}
main();
---END aaapostfix.as

 >aldor -grun -laldor aaaInfixPostfix.as
--rhx: ignore the compiler warnings...
I am forty-two.
24
40

Hope, you like that...

Ralf


From ralf at hemmecke.de  Tue Aug 29 06:42:04 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Tue, 29 Aug 2006 12:42:04 +0200
Subject: [Aldor-l] Type: Type
In-Reply-To: <87odu3eu5u.fsf@soliton.cs.tamu.edu>
References: <20060829025344.90960.qmail@web56714.mail.re3.yahoo.com>	<44F40C6B.70501@hemmecke.de>
	<87odu3eu5u.fsf@soliton.cs.tamu.edu>
Message-ID: <44F419FC.7010302@hemmecke.de>

> At the logical level, as I have observed some time ago, there is an
> inconsistency problem with Type:Type.  I'm wondering how Aldor gets
> away with that.  Many languages (mostly functional) use stratified
> types.

That question should be asked at aldor-l.

Can you construct a paradox that demonstrates the problem in terms of 
Aldor code? To me it looks like the class (not set) of all classes. 
Would there be a problem in class theory?

Ralf


From watt at scl.csd.uwo.ca  Tue Aug 29 08:51:47 2006
From: watt at scl.csd.uwo.ca (Stephen Watt)
Date: Tue, 29 Aug 2006 08:51:47 -0400
Subject: [Aldor-l] Type: Type
In-Reply-To: <44F419FC.7010302@hemmecke.de>
References: <20060829025344.90960.qmail@web56714.mail.re3.yahoo.com>
	<44F40C6B.70501@hemmecke.de> <87odu3eu5u.fsf@soliton.cs.tamu.edu>
	<44F419FC.7010302@hemmecke.de>
Message-ID: <20060829125147.GA11369@ptibonum.scl.csd.uwo.ca>

You are correct that there is a potential inconsistency.

We avoid Russel's paradox by limiting the operations for
constructing and testing membership in type categories.

Note that many programming languages have the problem of
allowing types with no elements, which can lead to the type
theory equivalent of a division by zero error.

Aldor is no exception in this regard:  It is possible to construct
a domain with no effective way to make elements.  

These kinds of errors have to be seen as  bugs in programs, just as 
division by zero is a programming error and not an invalidation of
integer arithmetic.

-- Stephen
    

On Tue, Aug 29, 2006 at 12:42:04PM +0200, Ralf Hemmecke wrote:
> > At the logical level, as I have observed some time ago, there is an
> > inconsistency problem with Type:Type.  I'm wondering how Aldor gets
> > away with that.  Many languages (mostly functional) use stratified
> > types.
> 
> That question should be asked at aldor-l.
> 
> Can you construct a paradox that demonstrates the problem in terms of 
> Aldor code? To me it looks like the class (not set) of all classes. 
> Would there be a problem in class theory?
> 
> Ralf
> _______________________________________________
> Aldor-l mailing list
> Aldor-l at aldor.org
> http://www.aldor.org/mailman/listinfo/aldor-l


From Bill.Page at drdc-rddc.gc.ca  Tue Aug 29 19:25:33 2006
From: Bill.Page at drdc-rddc.gc.ca (Page, Bill)
Date: Tue, 29 Aug 2006 19:25:33 -0400
Subject: [Aldor-l] How to emulate new infix and postfix operators in
	Aldor
In-Reply-To: <44EF570F.2020809@hemmecke.de>
Message-ID: <CAE9B164E720CE4D8727792DF8F28AE37D3524@corporateex02.Corporate.drdc-rddc.gc.ca>

Ralf, 

On Friday, August 25, 2006 4:01 PM you wrote:
> 
> I think some of you might find this interesting ...
> 
> *Question:* Aldor has a number of infix operators (AUG Sect 4.4).
> Can one define other infix operators?
> 
> *Answer:* No.
> 
> *Question:* Aldor has a number of postfix operators (notably 
> ".."). Can one define other postfix operators?
> 
> *Answer:* No.
>

In a general purpose compiler these limitations seem very
desirable to me. But of course in Axiom or other computer
algebra system one might wish for more flexibility in order
to better model common mathematical usage.
 
> *Question:* Can one experiment with syntactic sugar in
> Aldor?
> 
> *Answer:* *YES!!!*
> 
> ---BEGIN aaaInfixPostfix.as
> #include "aldor"
> #include "aldorio"
> 
> macro Z == Integer;
> 
> extend Z: with {
> 	apply: (Z, Z -> Z) -> Z;
> } == add {
> 	apply(z: Z, f: Z -> Z): Z == f z;
> }
> main(): () == {
> 	_42 := "I am forty-two."; -- _42 is an identifier.
> 	stdout << _42 << newline;
> 	
> 	_!(z: Z): Z == {zero? z => 1; z * (z-1)_!;}
> 	z: Z := 4 _!;
> 	stdout << z << newline;
> 
> 	x(a: Z)(b: Z): Z == a*b;
> 	z := 4 x 5 x 2;
> 	stdout << z << newline;
> }
> main();
> ---END aaapostfix.as
> 
>  >aldor -grun -laldor aaaInfixPostfix.as
> --rhx: ignore the compiler warnings...
> I am forty-two.
> 24
> 40
> 
> Hope, you like that...
> 

Nice.

But I don't see much "syntactic sugar" here. Using _42 as an
identifier just seems weird. Can you think of a reason to do
that?

The other two examples are not a matter of syntax but rather of
semantics. Defining the application of an integer to a function
as evaluation of the function on that integer is clever. Because
application is denoted by simple juxtaposition, this only looks
like "syntax" but really it just makes all unary functions commute
with their arguments. E.g.

  import from Integer;

  z abs = abs z

We can even extend this to binary functions:

  extend Z: with {
    apply: (Z, Z -> Z) -> Z;
    apply: (Z, Z) -> Cross(Z,Z);
    apply: (Z, (Z,Z) -> Z) -> (Z->Z);
  } == add {
    apply(z: Z, f: Z -> Z): Z == f z;
    apply(z: Z, w: Z): Cross(Z,Z) == (z,w);
    apply(z: Z, f: (Z,Z) -> Z): (Z->Z) == ((x:Z):Z +-> f(z,x));
  }

Then we have

  sum(z:Z,w:Z):Z == z+w;

  1 2 sum = sum 1 2

Unfortunately although we can now write

  + 1 2

the over jealous compiler rejects

  1 2 +

as a syntax error (although it would seem ok to me).

Regards,
Bill Page.



From ralf at hemmecke.de  Tue Aug 29 19:54:28 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Wed, 30 Aug 2006 01:54:28 +0200
Subject: [Aldor-l] How to emulate new infix and postfix operators in
	Aldor
In-Reply-To: <CAE9B164E720CE4D8727792DF8F28AE37D3524@corporateex02.Corporate.drdc-rddc.gc.ca>
References: <CAE9B164E720CE4D8727792DF8F28AE37D3524@corporateex02.Corporate.drdc-rddc.gc.ca>
Message-ID: <44F4D3B4.605@hemmecke.de>

> But I don't see much "syntactic sugar" here.

The syntactic sugar is that you don't *see* the "apply" function.
The compiler add "apply" for you without changing the semantics of the 
program.

 > Using _42 as an identifier just seems weird. Can you think of a 
reason to do
> that?

No. But, when I was looking for turning ! into an identifier, I found 
_33 in the AUG and so I just copied it here for demonstration. I don't 
think that I would use it unless someone tells me a nice application.

> Then we have
> 
>   sum(z:Z,w:Z):Z == z+w;
> 
>   1 2 sum = sum 1 2
> 
> Unfortunately although we can now write
> 
>   + 1 2
> 
> the over jealous compiler rejects
> 
>   1 2 +
> 
> as a syntax error (although it would seem ok to me).

Well, + is a special thing as would be all the other operators that are 
treated as "infix" operators by the language. You can explicitly turn 
them into prefix operators by putting parentheses around them.

Try

1 2 (+)

That works.

Ralf


From Bill.Page at drdc-rddc.gc.ca  Tue Aug 29 20:09:17 2006
From: Bill.Page at drdc-rddc.gc.ca (Page, Bill)
Date: Tue, 29 Aug 2006 20:09:17 -0400
Subject: [Aldor-l] How to emulate new infix and postfix operators in
	Aldor
In-Reply-To: <44F4D3B4.605@hemmecke.de>
Message-ID: <CAE9B164E720CE4D8727792DF8F28AE37D3525@corporateex02.Corporate.drdc-rddc.gc.ca>

Ralf,

On Tuesday, August 29, 2006 7:54 PM you wrote:
> Bill Page wrote: 
> > But I don't see much "syntactic sugar" here.
> 
> The syntactic sugar is that you don't *see* the "apply" function.
> The compiler add "apply" for you without changing the semantics
> of the program.

I would put this differently. 'apply' is a just another generic tie-in
(see http://www.aldor.org/docs/HTML/chap11.html) like 'bracket'. And
juxaposition always denotes application (that's semantics!). See
http://www.aldor.org/docs/HTML/chap4.html#6 No syntax involved here at
all. But I guess it doesn't really matter what you call it unless you
are the compiler writer. :)

> ... 
> Try
> 
> 1 2 (+)
> 
> That works.
> 

Neat. Thanks.

Regards,
Bill Page.



From Bill.Page at drdc-rddc.gc.ca  Wed Aug 30 05:30:26 2006
From: Bill.Page at drdc-rddc.gc.ca (Page, Bill)
Date: Wed, 30 Aug 2006 05:30:26 -0400
Subject: [Aldor-l] Type: Type
In-Reply-To: <20060829125147.GA11369@ptibonum.scl.csd.uwo.ca>
Message-ID: <CAE9B164E720CE4D8727792DF8F28AE37D352E@corporateex02.Corporate.drdc-rddc.gc.ca>

On Tuesday, August 29, 2006 6:03 AM Gabriel Dos Reis wrote:
>>> At the logical level, as I have observed some time ago, there
>>> is an inconsistency problem with Type:Type.  I'm wondering how
>>> Aldor gets away with that.  Many languages (mostly functional)
>>> use stratified types.

On Tue, Aug 29, 2006 at 12:42:04PM +0200, Ralf Hemmecke wrote:
>> Can you construct a paradox that demonstrates the problem in
>> terms of Aldor code? To me it looks like the class (not set)
>> of all classes. Would there be a problem in class theory?

On Tuesday, August 29, 2006 8:52 AM Stephen Watt wrote:
> 
> You are correct that there is a potential inconsistency.
> 
> We avoid Russel's paradox by limiting the operations for
> constructing and testing membership in type categories.
> ...

I think the fact that Aldor defines the type of Type as Type
is very interesting from a theoretical point of view and that
it is not correct to suggest that it implies any inconsistency
or even necessarily any fundamental limitation.

In mathematics it is often necessary to deal formally with
"very large" objects, for example, to be able to reason and
compute with things like streams and formal series or for that
matter even objects such as exact real numbers. These things
do not have simple finite representations inside the computer
yet we do have means to manipulate such objects in the Aldor
and Axiom libaries. Even larger objects such as categories and
the category of all categories can be effectively represented.

Non-well-founded set theory deals specifically with this kind
of situation. (Note: The term "non-well-founded" should not be
interpreted pejoratively, in the same way "imaginary" does not
imply any algebraic defect in reference to a number.)

http://en.wikipedia.org/wiki/Non-well-founded_set_theory

I am particularly fond of the book by Barwise and Moss:
Vicious Circles: on the mathematics of circular phenomena,
CSLI Lecture Notes, 1996.

An earlier but very important reference is the book by
Peter Aczel, Non-Well-Founded Sets. Center for the Study of
Language and Information, CSLI Lecture Notes no. 14, 1988.

http://standish.stanford.edu/pdf/00000056.pdf

One of the ways of axiomatizing non-well-founded sets is via
"accessible pointed graphs". It seems to me that these graphs
also provide an excellent model for Types in Aldor and Axiom.

This is particularly evident in the Axiom library where there
are many inherent circular dependencies. Given the presence of
circulary dependencies and the potential for mutual recursion,
fixed point methods seem especially appropropriate for compiling
the Axiom library. It seems that the SPAD language leaves no
alternative to this process, but Aldor is able to compile some
mutually recursive definitions when they occur in the same source
file. And post-facto extension makes many (most?) cases of mutual
recursion over larger groups of library modules unnecessary. It
remains to be determined whether this is sufficient to implement
Axiom's library without any essential compromises.

http://wiki.axiom-developer.org/MutualRecursion

Further, it seems to me that in principle the concept of
bi-simulation introduced in the theory of non-well-founded sets
might provide an effective definition of equivalence for Aldor's
types.

Regards,
Bill Page.



From ralf at hemmecke.de  Wed Aug 30 07:35:55 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Wed, 30 Aug 2006 13:35:55 +0200
Subject: [Aldor-l] [Axiom-developer] spad: language and compiler
In-Reply-To: <web-8253734@cgate.sci.ccny.cuny.edu>
References: <web-8253734@cgate.sci.ccny.cuny.edu>
Message-ID: <44F5781B.4000103@hemmecke.de>

>>> > f(m: INT, n: INT): PF n == m::PF(n)
>> that's OK.
>>
>>
>>> > [f(100, n) for n in primes(1,100)]
>> that's stupid.

> Why? I would think it is an element (not a list) in a cartesian product 
> of #primes(1,100) prime fields.

OK, if you like. But then I would like to see the definition of the 
bracket function. Can you give that?

I strongly believe you can't, because that would require Aldor to 
compute "primes(1,100)" at compile time. Which is currently not possible 
and if the compiler is allowed to evaluate it then it might run into an 
infinite loop (at compile time) since the "primes" function does not 
terminate as you would expect. Compile time evaluation in full 
generality introduces a way make it really hard to find bugs.

But anyway, maybe Aldor should allow compile time evaluation.

>>> Ask yourself, what type that list will have and you realise that 
>>> Aldor will
>>> reject that its compilation.
>> Excuse me, Gaby. Sorry about being so stupid.
> 
> It's a perfectly good mathematical object in a cartesian product.

William is right, but I cannot believe that a construction like

[f(100, n) for n in [2,3,5]$List(Integer)]

would work.

[f(100, n), f(100, n), f(100, n)]

should be easily definable and give an element in the cartesian product 
of   PF(2), PF(3), and PF(5). But that is a finite construct and not 
done via Generator as above.

>>> > [a::P for P in L]
>>> That is as problematic as the first list.
>> "problematic" is an understatement. Sorry.
> 
> Ditto. The only problem I see that can't be handled is if you make it 
> into a function of k:

> [f(100, n) for n in primes(1,k)]

Initially, I believe, Martin wanted lists. What you are calling for is a 
cartesian product constructor of the form.

PFCartesian(k: Integer): with {
     coerce: ((n: Integer) -> PF(n)) -> %;
     ...
} == add {
     ...
}

Then instead of [f(100, n) for n in primes(1,k)] it would be more 
appropriate to define

k: Integer == << stdin; -- read from standard input and make it constant
foo(m: Integer)(n: Integer): PF(n) == m :: PF(n);
import from PFCartesian(k);
z := foo(42) :: PFCartesian(k);

Such a construction would work, but it does not involve a Generator or 
something that you must compute at compile time.

Ralf


From carette at mcmaster.ca  Wed Aug 30 08:14:35 2006
From: carette at mcmaster.ca (Jacques Carette)
Date: Wed, 30 Aug 2006 08:14:35 -0400
Subject: [Aldor-l] [Axiom-developer] spad: language and compiler
In-Reply-To: <44F5781B.4000103@hemmecke.de>
References: <web-8253734@cgate.sci.ccny.cuny.edu>
	<44F5781B.4000103@hemmecke.de>
Message-ID: <44F5812B.1040205@mcmaster.ca>

Ralf Hemmecke wrote:
> Compile time evaluation in full 
> generality introduces a way make it really hard to find bugs.
>
> But anyway, maybe Aldor should allow compile time evaluation.
>   
Quick remark --  it has been shown that:
1) C++'s template language is a Turing Complete PL
2) Haskell's class types (with common extensions) is also a Turing 
Complete PL
3) All meta-programming systems allow arbitrary compile time evaluation

Yes, it does make debugging harder.  But the advantages seem to _far_ 
outweigh the problems.  One just develops new debugging (and coding) 
techniques to deal with the added power/complexity.

I could re-use Stephen's brilliant closing line from yesterday's email:
    "These kinds of errors have to be seen as bugs in programs, just as 
division by zero is a programming error and not an invalidation of 
integer arithmetic." -- S.M. Watt
[where 'These kinds of errors' is now /Programs with infinite loops in 
types/]

Jacques


From carette at mcmaster.ca  Wed Aug 30 13:17:37 2006
From: carette at mcmaster.ca (Jacques Carette)
Date: Wed, 30 Aug 2006 13:17:37 -0400
Subject: [Aldor-l] [Axiom-developer] spad: language and compiler
In-Reply-To: <87ac5m4bn1.fsf@soliton.cs.tamu.edu>
References: <web-8253734@cgate.sci.ccny.cuny.edu>	<44F5781B.4000103@hemmecke.de>
	<44F5812B.1040205@mcmaster.ca> <87ac5m4bn1.fsf@soliton.cs.tamu.edu>
Message-ID: <44F5C831.3070106@mcmaster.ca>

Gabriel Dos Reis wrote:
> I agree with most of what you said.  However, the slogan "well-typed
> programs don't go wrong" does some value that I would heisate to
> compromise...
>   
But well-typed programs can still diverge!  So "go wrong" just means 
that _when_ they return a value, it is guaranteed to be of the right type.

You can do the same thing for types - this is usually called a 'kinding' 
system.  In fact some languages (like Tim Sheard's Omega -- 
http://web.cecs.pdx.edu/~sheard/Omega/index.html) push that further by 
having a complete hierarchy (the names often used for the lower levels 
are term - type - kind - sort).

A "well-kinded" type doesn't "go wrong" either [assuming termination].

Jacques


From carette at mcmaster.ca  Wed Aug 30 13:28:53 2006
From: carette at mcmaster.ca (Jacques Carette)
Date: Wed, 30 Aug 2006 13:28:53 -0400
Subject: [Aldor-l] [Axiom-developer] spad: language and compiler
In-Reply-To: <Pine.GSO.4.58.0608301223280.4041@sun>
References: <web-8253734@cgate.sci.ccny.cuny.edu>
	<44F5781B.4000103@hemmecke.de> <44F5812B.1040205@mcmaster.ca>
	<87ac5m4bn1.fsf@soliton.cs.tamu.edu> <44F5C831.3070106@mcmaster.ca>
	<Pine.GSO.4.58.0608301223280.4041@sun>
Message-ID: <44F5CAD5.9000603@mcmaster.ca>

Gabriel Dos Reis wrote:
> With Type:Type, it is not clear to me that when a well-typed
> expression does not diverge, its value is not "wrong".
>   
Every 6 months or so, I tell Stephen he should write up a formalization 
of Aldor's type system, and prove the usual Progress and Preservation 
theorems for it. 

Jacques


From Bill.Page at drdc-rddc.gc.ca  Wed Aug 30 14:43:18 2006
From: Bill.Page at drdc-rddc.gc.ca (Page, Bill)
Date: Wed, 30 Aug 2006 14:43:18 -0400
Subject: [Aldor-l] [Axiom-developer] spad: language and compiler
In-Reply-To: <44F5CAD5.9000603@mcmaster.ca>
Message-ID: <CAE9B164E720CE4D8727792DF8F28AE37D3642@corporateex02.Corporate.drdc-rddc.gc.ca>

On Wednesday, August 30, 2006 1:29 PM Jacques Carette wrote:
> 
> Gabriel Dos Reis wrote:
> > With Type:Type, it is not clear to me that when a well-typed
> > expression does not diverge, its value is not "wrong".
> >   
> Every 6 months or so, I tell Stephen he should write up a 
> formalization of Aldor's type system, and prove the usual
> Progress and Preservation theorems for it. 
> 

When it comes to the application of Aldor as the Axiom library
compiler, I am afraid that demanding that Aldor satisfy these
usual requirements might amount to "throwing the baby out with
the bath water".

The concept of "Progress" is very similar to well-foundedness.
By direct analogy with the theory of non-well-founded sets we
can have non-well-founded types which violate Progress but still
satisfy Preservation.

There is a growing literature on this subject.

http://portal.acm.org/ft_gateway.cfm?id=351261&type=pdf

Recursive Subtyping Revealed
Functional Pearl
Vladimir Gapeyev, Michael Y. Levin, Benjamin C. Pierce

http://www.dcs.ed.ac.uk/home/mf/TYPES/coinduction.ps

A Coinduction Principle for Recursive Data Types
Based on Bisimulation, by Marcelo Fiore

etc.

But I supposed Gaby would claim that these are still more
"vague allusions to co-inductive formalism" ;) Oh well...

Regards,
Bill Page.



From carette at mcmaster.ca  Wed Aug 30 15:09:45 2006
From: carette at mcmaster.ca (Jacques Carette)
Date: Wed, 30 Aug 2006 15:09:45 -0400
Subject: [Aldor-l] [Axiom-developer] spad: language and compiler
In-Reply-To: <CAE9B164E720CE4D8727792DF8F28AE37D3642@corporateex02.Corporate.drdc-rddc.gc.ca>
References: <CAE9B164E720CE4D8727792DF8F28AE37D3642@corporateex02.Corporate.drdc-rddc.gc.ca>
Message-ID: <44F5E279.9060709@mcmaster.ca>

Page, Bill wrote:
>> Every 6 months or so, I tell Stephen he should write up a 
>> formalization of Aldor's type system, and prove the usual
>> Progress and Preservation theorems for it. 
>>     
>
> When it comes to the application of Aldor as the Axiom library
> compiler, I am afraid that demanding that Aldor satisfy these
> usual requirements might amount to "throwing the baby out with
> the bath water".
>
> The concept of "Progress" is very similar to well-foundedness.
> By direct analogy with the theory of non-well-founded sets we
> can have non-well-founded types which violate Progress but still
> satisfy Preservation.
>   
Aldor 'works'.  So if it were necessary to introduce new notions (or 
leverage recent work) to formally prove this, that would be icing on the 
cake!

As far as co-induction goes, I'm a fan too! ;-) 
[http://lists.seas.upenn.edu/pipermail/types-list/2004/000177.html]

Jacques


From ralf at hemmecke.de  Wed Aug 30 19:05:18 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Thu, 31 Aug 2006 01:05:18 +0200
Subject: [Aldor-l] [Axiom-developer] spad: language and compiler
In-Reply-To: <web-8259658@cgate.sci.ccny.cuny.edu>
References: <web-8259658@cgate.sci.ccny.cuny.edu>
Message-ID: <44F619AE.5020702@hemmecke.de>

Dear William,

> Getting back to your question, it is up to the programmer to define
> the bracket function for the domain where Martin's expression lives.
> Even though it may not be possible in Axiom to directly program
> tuples of heterogeneous domains, such tuples are present in most
> function signatures like foo:(INT, Boolean)->INT. I would expect
> Aldor therefore to be able to directly program tuples of
> heterogeneous domains.

As you know Record and Cross are two ways in Aldor to construct
heterogeneous tuples. The problem is that both must have a certain fixed
length when you write them into your program.

> Thus Martin's expression, perhaps using round parentheses instead of 
> brackets, should work in Aldor.

Martin's line contained a "for n in primes(1,100)" iterator, so the type
would only be know if the compiler were able to evaluate "primes(1,100)"
at compile time.

> I don't know how "primes" is implemented but it is probably a
> built-in using both a table for lower range and some sophisticated
> algorithms for higher ones.

Whatever "built-in" means for you. It is certainly not built into the 
Aldor language, it is part of a library and as such it could mean 
anything I like.

 > I am not suggesting compile time
> evaluation be extended to all static computations, but my guess is
> "primes" is special. A bit of compiler optimization would probably
> evaluate expressions like 2+3, so why not primes(1,100)?

To what should 2+3 evaluate? To the Integer 5? To the MachineInteger 5? 
To a sparse univariate polynomial 5? To 0 mod 5? It is awfully ambiguous 
and would in general involve more than just a call to the addition of 
machine size integers. I could have even overloaded + for 
MachineInteger. I guess, optimizing 2+3 to 5 is not even correct in some 
circumstances.

>> William is right, but I cannot believe that a construction like
>> 
>> [f(100, n) for n in [2,3,5]$List(Integer)]
>> 
>> would work.
> 
> The main reason why it is not working presently is because we have
> not constructed cartesian product over an arbitrary set of domains.
> But nothing in the language (even Spad) seems to prevent one from
> doing this.

Of course not, but note that you have a generator in the above 
construction and thus the compiler does not know the length of the tuple 
until it is *computed*. To make myself clear: I believe that one can 
write a constuctor for arbitrary tuples of variable length, but Martin's 
syntax to construct an element of such a type would not work. (Please 
convince me otherwise by providing running code.)

>> [f(100, n), f(100, n), f(100, n)]
> 
> You meant: [f(100,2), f(100,3), f(100,5)], I assume.

Of course.

>> should be easily definable and give an element in the cartesian 
>> product of   PF(2), PF(3), and PF(5). But that is a finite
>> construct and not done via Generator as above.
> 
> As discussed above, what is missing is cartesian product over an 
> arbitrary set of domains. If domains are first class objects, we
> should be able to construct sets of them, even via Generator, and
> hence also cartesian product.

Oh, yes, of course it is possible (even now) to construct a 
heterogeneous tuple type via Generator. But Martin's construction would 
mean to construct the type AND the element at the same time. And that (I 
believe) is impossible.

> At the very least, one should be able
> to form a set or list of domains of the same category (which IS
> homogeneous).

No problem in Aldor.

#include "aldor"
U: List PrimitiveType := [Integer, String, Character];

That is a completely valid Aldor program.

>> PFCartesian(k: Integer): with {
 >>     coerce: ((n: Integer) -> PF(n)) -> %;
 >>     ...
 >> }== add { ... }

> I am not following. Is PFCartesian(k) a cartesian product of the
> first k prime fields, like PFCartesian(3) is PF(2) x PF(3) x PF(5)?
> Then given a function (n:Integer)->PF(n) (basically, an sequence of
> elements, one from each PF(n), and n better be a prime! but let's
> pretend we interpret PF(n) as Integer mod n), the coerce function
> maps the anonymous function to PFCartesian(k) by using the first k
> elements in the sequence?

I was not thinking too much about it. I wanted that PFCartesian(7) 
stands for PF(2) x PF(3) x PF(5) x PF(7) and PF for PrimeField. And the 
coerce function basically turns the projection functions into an element 
of PFCartesian.

As representation I could choose

Rep == (n: Integer) -> PF(n);

But I still cannot make

[f(100, n) for n in [2,3,5]$List(Integer)]

into valid Aldor code if f is the function given by Martin.

Can you?

Ralf


From Bill.Page at drdc-rddc.gc.ca  Wed Aug 30 23:20:54 2006
From: Bill.Page at drdc-rddc.gc.ca (Page, Bill)
Date: Wed, 30 Aug 2006 23:20:54 -0400
Subject: [Aldor-l] [Axiom-developer] spad: language and compiler
In-Reply-To: <44F619AE.5020702@hemmecke.de>
Message-ID: <CAE9B164E720CE4D8727792DF8F28AE37D3682@corporateex02.Corporate.drdc-rddc.gc.ca>

On Wednesday, August 30, 2006 7:05 PM Ralf Hemmecke wrote:
> ... 
> As you know Record and Cross are two ways in Aldor to construct
> heterogeneous tuples. The problem is that both must have a 
> certain fixed length when you write them into your program.
> ...

What does "fixed" mean in this context?

> Martin's line contained a "for n in primes(1,100)" iterator, 
> so the type would only be known if the compiler were able to
> evaluate "primes(1,100)" at compile time.

>From our earlier discusion of 'random()' in the context of
Aldor types that are determined at compile-time, it seems
clear that it should be no problem to define a constant such
as

  P:List Integer == primes(1,100);

In fact, 'primes(1,100)' is a constant expression. As we
discovered, although P is a constant it's actual *value* is
only determined during run-time initialization, and then it
is fixed for the duration of the program execution. I recall
that you demonstrated in several programs that types in Aldor
(which must be constant) are also evaluated in exactly this
way.

At first I found this very surprising but now I am pretty
happy about it. :) That this is the case should not really
be so surprising considering that one of the target runtime
environments for Aldor is lisp!

Anyway I see no reason in principle for Aldor to reject
something like:

  [f(100,n) for n in P]::Cross(PF(n) for n in P)

where the bracket function is define by the Cross domain
constructor.

This is not the only type which satisfies Martin's original
example. Another possibility is:

  [f(100,n) for n in P]::List Union(n:PF(n) for n in P)

i.e. a List over a type union. This would be a more general
type than the cross product, but equally valid from a
conceptual point of view.

> ... 
> >> I cannot believe that a construction like
> >> 
> >> [f(100, n) for n in [2,3,5]$List(Integer)]
> >> 
> >> would work.
> > 
> > The main reason why it is not working presently is because
> > we have not constructed cartesian product over an arbitrary
> > set of domains. But nothing in the language (even Spad)
> > seems to prevent one from doing this.

I am afraid that there may indeed be such a restriction --
at least in SPAD. The problem is how and when the arity of
functions is decided. The arity is actually encoded into
the names given to the functions and as far as I know these
names *must* be decided strictly at compile-time.

The situation in Aldor might be different but I do not
understand in sufficient detail the actual FOAM that Aldor
generates.

> 
> Of course not, but note that you have a generator in the
> above construction and thus the compiler does not know the
> length of the tuple until it is *computed*.

Although the length is not known at compile-time, nontheless
it is fixed at run-time initialization. That is not an
unusual sitation in Aldor.

> 
> Oh, yes, of course it is possible (even now) to construct a 
> heterogeneous tuple type via Generator.

Really?

> But Martin's construction would mean to construct the type
> AND the element at the same time. And that (I believe) is
> impossible.
> ... 
> But I still cannot make
> 
> [f(100, n) for n in [2,3,5]$List(Integer)]
> 
> into valid Aldor code if f is the function given by Martin.
>

Probably what we need is some kind of recursive type constructor.
See for example:

http://www.cs.kent.ac.uk/people/staff/sjt/Atypical/AldorExs/vector.as

Something like ... ?

PFCartesian(k: Integer): Type 
    == if k<=1 then PF(1) else Record(fst:PF(k),rst:PFCartesian(k-1));

See also section 23.8 "Recursive Strurctures" page 324 of the
Axiom Library Compiler Users Guide, 1994:

www.ph.ed.ac.uk/~bj/paraldor/WWW/docs/documentation/axlugII.pdf

I hope to have more time some to work with these examples.

Regards,
Bill Page.



From ralf at hemmecke.de  Thu Aug 31 04:41:41 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Thu, 31 Aug 2006 10:41:41 +0200
Subject: [Aldor-l] [Axiom-developer] spad: language and compiler
In-Reply-To: <CAE9B164E720CE4D8727792DF8F28AE37D3682@corporateex02.Corporate.drdc-rddc.gc.ca>
References: <CAE9B164E720CE4D8727792DF8F28AE37D3682@corporateex02.Corporate.drdc-rddc.gc.ca>
Message-ID: <44F6A0C5.6010407@hemmecke.de>

On 08/31/2006 05:20 AM, Page, Bill wrote:
> On Wednesday, August 30, 2006 7:05 PM Ralf Hemmecke wrote:
>> ... 
>> As you know Record and Cross are two ways in Aldor to construct
>> heterogeneous tuples. The problem is that both must have a 
>> certain fixed length when you write them into your program.
>> ...
> 
> What does "fixed" mean in this context?

If you write Cross(A1, A2, ..., Ak) in your program with k types 
A1,...,Ak then the the k must be a natural number. Of course you can write

Cross(A1);
Cross(A1, A2);
Cross(A1, A2, A3);

but you cannot write

Cross [x for x in g]

for some Generator G and an appropriate definition of bracket.

Oh... maybe one can... but I am too lazy to check that you can write a 
bracket: Generator Type -> Tuple Type
and hand the result to Cross.

Anyway it doesn't solve the problem of having to generate the value and 
the type at the same time.


>> Martin's line contained a "for n in primes(1,100)" iterator, 
>> so the type would only be known if the compiler were able to
>> evaluate "primes(1,100)" at compile time.
> 
>>From our earlier discusion of 'random()' in the context of
> Aldor types that are determined at compile-time, it seems
> clear that it should be no problem to define a constant such
> as
> 
>   P:List Integer == primes(1,100);
> 
> In fact, 'primes(1,100)' is a constant expression. As we
> discovered, although P is a constant it's actual *value* is
> only determined during run-time initialization, and then it
> is fixed for the duration of the program execution. I recall
> that you demonstrated in several programs that types in Aldor
> (which must be constant) are also evaluated in exactly this
> way.

Oh, yes. Good remark.

> At first I found this very surprising but now I am pretty
> happy about it. :) That this is the case should not really
> be so surprising considering that one of the target runtime
> environments for Aldor is lisp!
> 
> Anyway I see no reason in principle for Aldor to reject
> something like:
> 
>   [f(100,n) for n in P]::Cross(PF(n) for n in P)
> 
> where the bracket function is define by the Cross domain
> constructor.

Interesting. That looks good, but is terribly wrong. Why? Because
    for n in P
accesses P destructively. Depending on what is evaluated first, either 
the Cross is essentially Cross() or the bracket is []. What language 
specification tells you the compiler should produce? (And both would be 
wrong anyway.)

>>>> I cannot believe that a construction like
>>>>
>>>> [f(100, n) for n in [2,3,5]$List(Integer)]
>>>>
>>>> would work.
>>> The main reason why it is not working presently is because
>>> we have not constructed cartesian product over an arbitrary
>>> set of domains. But nothing in the language (even Spad)
>>> seems to prevent one from doing this.
> 
> I am afraid that there may indeed be such a restriction --
> at least in SPAD. The problem is how and when the arity of
> functions is decided. The arity is actually encoded into
> the names given to the functions and as far as I know these
> names *must* be decided strictly at compile-time.

This is exactly what I meant by "fixed length" above.

>> Oh, yes, of course it is possible (even now) to construct a 
>> heterogeneous tuple type via Generator.
> 
> Really?

You want me to produce code, right? ;-)

>> But Martin's construction would mean to construct the type
>> AND the element at the same time. And that (I believe) is
>> impossible.
>> ... 
>> But I still cannot make
>>
>> [f(100, n) for n in [2,3,5]$List(Integer)]
>>
>> into valid Aldor code if f is the function given by Martin.

> Probably what we need is some kind of recursive type constructor.
> See for example:
> 
> http://www.cs.kent.ac.uk/people/staff/sjt/Atypical/AldorExs/vector.as
> 
> Something like ... ?
> 
> PFCartesian(k: Integer): Type 
>     == if k<=1 then PF(1) else Record(fst:PF(k),rst:PFCartesian(k-1));

Oh! Although it is done a bit different, you should take a look at the 
definition of RecursiveMultivariatePolynomial0. Do you have the sources 
of Aldor's LibAlgebra?

> See also section 23.8 "Recursive Strurctures" page 324 of the
> Axiom Library Compiler Users Guide, 1994:

> www.ph.ed.ac.uk/~bj/paraldor/WWW/docs/documentation/axlugII.pdf

> I hope to have more time some to work with these examples.

Oh, a definition of Tree... Not very exciting. We now have a way to 
construct a binary tree as a combinatorial species in aldor-combinat

svn co svn://svn.risc.uni-linz.ac.at/hemmecke/combinat/trunk

Look at the end of the file src/species.as.nw and you'll find the 
following definition for a tree...

BinaryTree(L: LabelType): CombinatorialSpecies L == {
         macro {
                 + == Plus;
                 * == Times;
                 1 == EmptySetSpecies;
                 X == SingletonSpecies;
                 B == BinaryTree;
         }
         (1 + X * B * B)(L) add;
}

But I have the suspicion that it is not the right code to construct 
heterogeneous products. Anyway, the interesting part in the BinaryTree 
definition is that at the same time of constructing the tree you get a 
function that generates all (labelled) trees of a given size and a 
function that counts trees of a given size (the generating function).

Ralf


From ralf at hemmecke.de  Thu Aug 31 06:16:54 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Thu, 31 Aug 2006 12:16:54 +0200
Subject: [Aldor-l] [Axiom-developer] spad: language and compiler
In-Reply-To: <CAE9B164E720CE4D8727792DF8F28AE37D3682@corporateex02.Corporate.drdc-rddc.gc.ca>
References: <CAE9B164E720CE4D8727792DF8F28AE37D3682@corporateex02.Corporate.drdc-rddc.gc.ca>
Message-ID: <44F6B716.4050506@hemmecke.de>

> Probably what we need is some kind of recursive type constructor.
> See for example:
> 
> http://www.cs.kent.ac.uk/people/staff/sjt/Atypical/AldorExs/vector.as

If you look closer to that, then you see that vector.as is implementing 
"List" in a terribly complicated way.

Look at

-- Add up the entries of a Vector(n).
addVec(n:Integer,v:Vector(n)):Integer
     == {
     import from Record(fst:Integer,rst:Vector(n-1));
     if n<=1
           then 0
	  else vec.fst + addVec(n-1,vec.rst);
	  where { vec == (v pretend				-- A
	  		 Record(fst:Integer,rst:Vector(n-1))); }};

in particular look at the argument. If it were a list you could forget 
about the n, but here you have to give it. I am sure, nobody would ever 
use such code.

If you must have a union over Vectors of arbitrary lenght then a cleaner 
design would be to define vectors of lenght n and in a second step 
define operations on vectors of different length.

In aldor-combinat you would define that thing like in the BinaryTree 
example I gave before but just use the equation V = 1 + X * V.
And, by the way, I did not use "pretend" in my code.

Ralf


From wyscc at sci.ccny.cuny.edu  Wed Aug 30 06:15:54 2006
From: wyscc at sci.ccny.cuny.edu (William Sit)
Date: Wed, 30 Aug 2006 06:15:54 -0400
Subject: [Aldor-l] [Axiom-developer] spad: language and compiler
In-Reply-To: <9qhd02mhqc.fsf@login.mat.univie.ac.at>
Message-ID: <web-8253734@cgate.sci.ccny.cuny.edu>

On 24 Aug 2006 14:38:19 +0200
  Martin Rubey <martin.rubey at univie.ac.at> wrote:
>Ralf Hemmecke <ralf at hemmecke.de> writes:
>
>> > f(m: INT, n: INT): PF n == m::PF(n)
>that's OK.
>
>
>> > [f(100, n) for n in primes(1,100)]
>that's stupid.

Why? I would think it is an element (not a list) in a 
cartesian product of #primes(1,100) prime fields.

>> Ask yourself, what type that list will have and you 
>>realise that Aldor will
>> reject that its compilation.
>Excuse me, Gaby. Sorry about being so stupid.

It's a perfectly good mathematical object in a cartesian 
product.

>
>> > [a::P for P in L]
>> That is as problematic as the first list.
>"problematic" is an understatement. Sorry.

Ditto. The only problem I see that can't be handled is if 
you make it into a function of k:

[f(100, n) for n in primes(1,k)]

To have true dependent types means the compiler should be 
able to handle

[f(100, n) for n in primes(1,100)]

because the list primes(1,100) is computable at compile 
time and hence the prime fields can be constructed and 
their cartesian product too. prime(1,k) is a totally 
different ball game, but even that should be doable with 
generated code to instantiate the prime fields when k is 
given a value at run time.

William


From gdr at cs.tamu.edu  Wed Aug 30 06:15:57 2006
From: gdr at cs.tamu.edu (Gabriel Dos Reis)
Date: 30 Aug 2006 05:15:57 -0500
Subject: [Aldor-l] [Axiom-developer] RE:  Type: Type
In-Reply-To: <CAE9B164E720CE4D8727792DF8F28AE37D352E@corporateex02.Corporate.drdc-rddc.gc.ca>
References: <CAE9B164E720CE4D8727792DF8F28AE37D352E@corporateex02.Corporate.drdc-rddc.gc.ca>
Message-ID: <87lkp64jhe.fsf@soliton.cs.tamu.edu>

"Page, Bill" <Bill.Page at drdc-rddc.gc.ca> writes:

| On Tuesday, August 29, 2006 6:03 AM Gabriel Dos Reis wrote:
| >>> At the logical level, as I have observed some time ago, there
| >>> is an inconsistency problem with Type:Type.  I'm wondering how
| >>> Aldor gets away with that.  Many languages (mostly functional)
| >>> use stratified types.
| 
| On Tue, Aug 29, 2006 at 12:42:04PM +0200, Ralf Hemmecke wrote:
| >> Can you construct a paradox that demonstrates the problem in
| >> terms of Aldor code? To me it looks like the class (not set)
| >> of all classes. Would there be a problem in class theory?
| 
| On Tuesday, August 29, 2006 8:52 AM Stephen Watt wrote:
| > 
| > You are correct that there is a potential inconsistency.
| > 
| > We avoid Russel's paradox by limiting the operations for
| > constructing and testing membership in type categories.
| > ...
| 
| I think the fact that Aldor defines the type of Type as Type
| is very interesting from a theoretical point of view and that
| it is not correct to suggest that it implies any inconsistency
| or even necessarily any fundamental limitation.

I believe I need more explanations than the vague allusion to
co-inductive formalism.  Epigram, for example, faces the same issue, and
I don't think it is just mirage:

   http://www.mail-archive.com/epigram at durham.ac.uk/msg00038.html

-- Gaby


From gdr at cs.tamu.edu  Wed Aug 30 09:05:22 2006
From: gdr at cs.tamu.edu (Gabriel Dos Reis)
Date: 30 Aug 2006 08:05:22 -0500
Subject: [Aldor-l] [Axiom-developer] spad: language and compiler
In-Reply-To: <44F5812B.1040205@mcmaster.ca>
References: <web-8253734@cgate.sci.ccny.cuny.edu>
	<44F5781B.4000103@hemmecke.de> <44F5812B.1040205@mcmaster.ca>
Message-ID: <87ac5m4bn1.fsf@soliton.cs.tamu.edu>

Jacques Carette <carette at mcmaster.ca> writes:

| Ralf Hemmecke wrote:
| > Compile time evaluation in full 
| > generality introduces a way make it really hard to find bugs.
| >
| > But anyway, maybe Aldor should allow compile time evaluation.
| >   
| Quick remark --  it has been shown that:
| 1) C++'s template language is a Turing Complete PL
| 2) Haskell's class types (with common extensions) is also a Turing 
| Complete PL
| 3) All meta-programming systems allow arbitrary compile time evaluation
| 
| Yes, it does make debugging harder.  But the advantages seem to _far_ 
| outweigh the problems.  One just develops new debugging (and coding) 
| techniques to deal with the added power/complexity.
| 
| I could re-use Stephen's brilliant closing line from yesterday's email:
|     "These kinds of errors have to be seen as bugs in programs, just as 
| division by zero is a programming error and not an invalidation of 
| integer arithmetic." -- S.M. Watt
| [where 'These kinds of errors' is now /Programs with infinite loops in 
| types/]

I agree with most of what you said.  However, the slogan "well-typed
programs don't go wrong" does some value that I would heisate to
compromise...

-- Gaby


From gdr at cs.tamu.edu  Wed Aug 30 13:25:25 2006
From: gdr at cs.tamu.edu (Gabriel Dos Reis)
Date: Wed, 30 Aug 2006 12:25:25 -0500 (CDT)
Subject: [Aldor-l] [Axiom-developer] spad: language and compiler
In-Reply-To: <44F5C831.3070106@mcmaster.ca>
References: <web-8253734@cgate.sci.ccny.cuny.edu>
	<44F5781B.4000103@hemmecke.de>
	<44F5812B.1040205@mcmaster.ca> <87ac5m4bn1.fsf@soliton.cs.tamu.edu>
	<44F5C831.3070106@mcmaster.ca>
Message-ID: <Pine.GSO.4.58.0608301223280.4041@sun>

On Wed, 30 Aug 2006, Jacques Carette wrote:

| Gabriel Dos Reis wrote:
| > I agree with most of what you said.  However, the slogan "well-typed
| > programs don't go wrong" does some value that I would heisate to
| > compromise...
| >
| But well-typed programs can still diverge!  So "go wrong" just means
| that _when_ they return a value, it is guaranteed to be of the right type.

No dispute there.

With Type:Type, it is not clear to me that when a well-typed
expression does not diverge, its value is not "wrong".

-- Gaby


From gdr at cs.tamu.edu  Wed Aug 30 15:04:11 2006
From: gdr at cs.tamu.edu (Gabriel Dos Reis)
Date: Wed, 30 Aug 2006 14:04:11 -0500 (CDT)
Subject: [Aldor-l] [Axiom-developer] spad: language and compiler
In-Reply-To: <CAE9B164E720CE4D8727792DF8F28AE37D3642@corporateex02.Corporate.drdc-rddc.gc.ca>
References: <CAE9B164E720CE4D8727792DF8F28AE37D3642@corporateex02.Corporate.drdc-rddc.gc.ca>
Message-ID: <Pine.GSO.4.58.0608301403190.4041@sun>

On Wed, 30 Aug 2006, Page, Bill wrote:

| But I supposed Gaby would claim that these are still more
| "vague allusions to co-inductive formalism" ;) Oh well...

I hope we would make progress with scientific skepticism :-)

-- Gaby


From wyscc at sci.ccny.cuny.edu  Wed Aug 30 17:51:42 2006
From: wyscc at sci.ccny.cuny.edu (William Sit)
Date: Wed, 30 Aug 2006 17:51:42 -0400
Subject: [Aldor-l] [Axiom-developer] spad: language and compiler
In-Reply-To: <44F5781B.4000103@hemmecke.de>
Message-ID: <web-8259658@cgate.sci.ccny.cuny.edu>

On Wed, 30 Aug 2006 13:35:55 +0200
  Ralf Hemmecke <ralf at hemmecke.de> wrote:
>>>>> f(m: INT, n: INT): PF n == m::PF(n)
Martin's expression:
>>>>> [f(100, n) for n in primes(1,100)]
>>I would think it is an element (not a list) in a 
>>cartesian product of #primes(1,100) prime fields.
>
>OK, if you like. But then I would like to see the 
>definition of the bracket function. Can you give that?

One main difference between list of mathematical objects 
and say C++ objects is that the former is often 
homogeneous (elements of the list are of the same type) 
but the latter is often heterogeneous (elements need not 
be of the same type). In Axiom, all lists are homogeneous 
(even List Any) by definition of the domain List (or the 
domain Tuple). A variant that allows hetergeneous objects 
in a "list" is the domain Record. The bracket constructor 
is by default the list constructor but can be used to 
construct elements of Record. But since Record must have 
pre-defined named fields, Martin's line could not have 
meant a Record element. It certainly is not a list in the 
Axiom sense. So the remaining possibility is an element of 
a cartesian product. Axiom currently has a constructor for 
cartesian product of two sets: Product, where elements are 
constructed using the function makeprod. But here, we are 
not discussing existing domains, but rather whether 
Martin's expression is mathematically meaningful and 
whether the language allows its construction in Aldor. 

Getting back to your question, it is up to the programmer 
to define the bracket function for the domain where 
Martin's expression lives. Even though it may not be 
possible in Axiom to directly program tuples of 
heterogeneous domains, such tuples are present in most 
function signatures like foo:(INT, Boolean)->INT. I would 
expect Aldor therefore to be able to directly program 
tuples of heterogeneous domains. Thus Martin's expression, 
perhaps using round parentheses instead of brackets, 
should work in Aldor.

>I strongly believe you can't, because that would require 
>Aldor to compute "primes(1,100)" at compile time. Which 
>is currently not possible and if the compiler is allowed 
>to evaluate it then it might run into an infinite loop 
>(at compile time) since the "primes" function does not 
>terminate as you would expect. Compile time evaluation in 
>full generality introduces a way make it really hard to 
>find bugs.

I don't know how "primes" is implemented but it is 
probably a built-in using both a table for lower range and 
some sophisticated algorithms for higher ones. I am not 
suggesting compile time evaluation be extended to all 
static computations, but my guess is "primes" is special. 
A bit of compiler optimization would probably evaluate 
expressions like 2+3, so why not primes(1,100)? Obviously, 
compile time evaluation should be severely restricted 
(otherwise many programs may compile to just the output if 
no input is required).

>But anyway, maybe Aldor should allow compile time 
>evaluation.
>
>>>>Ask yourself, what type that list will have and you 
>>>>realise that 
>>>>Aldor will
>>>>reject that its compilation.
>>>Excuse me, Gaby. Sorry about being so stupid.
>>
>>It's a perfectly good mathematical object in a cartesian 
>>product.
>
>William is right, but I cannot believe that a 
>construction like
>
>[f(100, n) for n in [2,3,5]$List(Integer)]
>
>would work.

The main reason why it is not working presently is because 
we have not constructed cartesian product over an 
arbitrary set of domains. But nothing in the language 
(even Spad) seems to prevent one from doing this.

>[f(100, n), f(100, n), f(100, n)]

You meant: [f(100,2), f(100,3), f(100,5)], I assume.

>should be easily definable and give an element in the 
>cartesian product of   PF(2), PF(3), and PF(5). But that 
>is a finite construct and not done via Generator as 
>above.

As discussed above, what is missing is cartesian product 
over an arbitrary set of domains. If domains are first 
class objects, we should be able to construct sets of 
them, even via Generator, and hence also cartesian 
product. At the very least, one should be able to form a 
set or list of domains of the same category (which IS 
homogeneous). Something like:

Product(A: List PrimeField, B: List) 

where B is the index "set." Or, as you did below, using an 
anonymous function as the argument.

>>>>> [a::P for P in L]
>>>>That is as problematic as the first list.
>>>"problematic" is an understatement. Sorry.
>>
>>Ditto. The only problem I see that can't be handled is if 
>>you make it into a function of k:
>
>>[f(100, n) for n in primes(1,k)]
>
>Initially, I believe, Martin wanted lists. What you are 
>calling for is a cartesian product constructor of the 
>form.
>
>PFCartesian(k: Integer): with {
>     coerce: ((n: Integer) -> PF(n)) -> %;
>     ...
>}== add {
>     ...
>}

I am not following. Is PFCartesian(k) a cartesian product 
of the first k prime fields, like PFCartesian(3) is PF(2) 
x PF(3) x PF(5)? Then given a function (n:Integer)->PF(n) 
(basically, an sequence of elements, one from each PF(n), 
and n better be a prime! but let's pretend we interpret 
PF(n) as Integer mod n), the coerce function maps the 
anonymous function to PFCartesian(k) by using the first k 
elements in the sequence?

>Then instead of [f(100, n) for n in primes(1,k)] it would 
>be more appropriate to define
>
>k: Integer == << stdin; -- read from standard input and 
>make it constant
>foo(m: Integer)(n: Integer): PF(n) == m :: PF(n);
>import from PFCartesian(k);
>z := foo(42) :: PFCartesian(k);
>
>Such a construction would work, but it does not involve a 
>Generator or something that you must compute at compile 
>time.

The construction of the domain PFcartesian(k) might, even 
when k is given at instantiation time, depending on the 
meaning of that domain.

William


From tmgisi at gmx.at  Tue Aug  1 03:00:21 2006
From: tmgisi at gmx.at (Christian Aistleitner)
Date: Tue, 01 Aug 2006 09:00:21 +0200
Subject: [Aldor-l] Current version of Aldor
Message-ID: <op.tdle2vu0u6j4vy@spencer.aistleitner.info>

Hello,

in a private Email I have been asked, about the current version of Aldor.  
As it probably apllies to other people as well, I decided to answer to the  
list.

As of today (2006-08-01), I guesss the current version is 1.0.3 (quietly  
released some manths ago), although the homepage claims the current  
version is 1.0.2.

You can download 1.0.3 via the aldor homepage -- Just try to download  
Aldor and you'll get a file carrying 1.0.3 in the filename.
Quick Link:
http://www.aldor.org/downl.html

--
Kind regards,
Christian


From tmgisi at gmx.at  Tue Aug  1 03:52:17 2006
From: tmgisi at gmx.at (Christian Aistleitner)
Date: Tue, 01 Aug 2006 09:52:17 +0200
Subject: [Aldor-l] Reading from stdin
Message-ID: <op.tdlhhfkyu6j4vy@spencer.aistleitner.info>

Hello,

in a private Email I have been asked, about reading from stdin. As it  
probably applies to other people as well, I decided to answer to the list.

The naive approach via

#include "aldor"

import from TextReader;
import from TextWriter;
import from String;
import from Character;

local str: String := << stdin;

stdout << "Received: " << str << newline;

Gives problems, as it does not necessarily give the whole line:

____________________________________________
tmgisi at spencer
cwd: ~
$ LC_ALL=C /opt/aldor/bin/aldor -M no-abbrev -C args=-Wopts=-m32 -Ffm \
-Fx -lalgebra -laldor test2.as && ( echo 3/4 | ./test2 )
cc1: note: -fwritable-strings is deprecated; see documentation for details
cc1: note: -fwritable-strings is deprecated; see documentation for details
Received: 3


You'll have to use quotes to achive this:

____________________________________________
tmgisi at spencer
cwd: ~
$ LC_ALL=C /opt/aldor/bin/aldor -M no-abbrev -C args=-Wopts=-m32 -Ffm \
-Fx -lalgebra -laldor test2.as && ( echo \"3/4\" | ./test2 )
cc1: note: -fwritable-strings is deprecated; see documentation for details
cc1: note: -fwritable-strings is deprecated; see documentation for details
Received: 3/4

Forcing users to quote things is nasty. For the CharSet library I used the  
following function:

readString():String == {
	import from Character;
	import from MachineInteger;

	local ret : String := empty;
	local ch : Character;
	
	ch := <<$Character stdin;
	while ch ~= newline repeat
	{
		ret := ret + ch::String;
		ch := <<$Character stdin;
	}
	ret;
}

It reads _every_ character until a newline occurs. The returned string  
does not contain a trailing newline:

____________________________________________
tmgisi at spencer
cwd: ~
$ LC_ALL=C /opt/aldor/bin/aldor -M no-abbrev -C args=-Wopts=-m32 -Ffm -Fx  
-lalgebra -laldor test3.as && ( echo 3/4 | ./test3 )
cc1: note: -fwritable-strings is deprecated; see documentation for details
cc1: note: -fwritable-strings is deprecated; see documentation for details
Received: 3/4

On systems with suitable readline support (Every 32-bit GNU/Linux system  
should do), you can use something like:

#include "aldor"

import from TextReader;
import from TextWriter;
import from String;
import from Character;

Readline: with {
     (<<): ( prompt: String == "" ) -> String;
} == add {

     import {
	readline: String -> String;
     } from Foreign C;

     (<<)( prompt ): String == {
	readline( prompt );
     }
}

import from Readline;

local str: String := <<();

stdout << "Received: " << str << newline;


to take advantage readline. I could not test the readline snippet, as I do  
not have 32-bit version of readline -- still waiting for 64-bit Aldor.

--
Kind regards,
Christian



From ldragan at uwo.ca  Thu Aug  3 15:41:45 2006
From: ldragan at uwo.ca (Laurentiu Dragan)
Date: Thu, 03 Aug 2006 15:41:45 -0400
Subject: [Aldor-l] Announcement: www.aldor.org updates
Message-ID: <44D25179.9030106@uwo.ca>

Hi,

I have made two additions to www.aldor.org:

1. the FOAM reference manual in the documentation page

2. a compiler for the older Linux distributions (glibc 2.2).

--
Laurentiu


From antoine.hersen at gmail.com  Fri Aug  4 08:48:02 2006
From: antoine.hersen at gmail.com (Antoine Hersen)
Date: Fri, 4 Aug 2006 14:48:02 +0200
Subject: [Aldor-l] Mac version
Message-ID: <c281860e0608040548i2d1c11ct72dad312db4767b7@mail.gmail.com>

Hello,

I will like to know if it will be possible to have a Mac OSX/PPC version of
the Aldor compiler ?

XCode ship with gcc4.0 and 3.3.

I will be happy to help if needed.


Regards,
Antoine Hersen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.aldor.org/pipermail/aldor-l_aldor.org/attachments/20060804/4b83a783/attachment-0001.html>

From bill.page1 at synthesis.anikast.ca  Mon Aug  7 11:52:58 2006
From: bill.page1 at synthesis.anikast.ca (Bill Page)
Date: Mon, 7 Aug 2006 11:52:58 -0400
Subject: [Aldor-l] Mac version
In-Reply-To: <c281860e0608040548i2d1c11ct72dad312db4767b7@mail.gmail.com>
Message-ID: <00d101c6ba39$94661ca0$6900a8c0@asus>

Antoine,

On August 4, 2006 8:48 AM you wrote to Laurentiu Dragan
aldor-l at aldor.org

> I will like to know if it will be possible to have a Mac OSX/PPC
> version of the Aldor compiler ?
>
> XCode ship with gcc4.0 and 3.3.
>
> I will be happy to help if needed.

My experience is that aldor.org does not really have sufficient
resources to support multiple versions of Aldor on different
platforms. For example, there is no current Windows version of
Aldor either.

Of course all of this would change immediately if/when Aldor
is licensed as open source. But while we continue to wait for
that much anticipated event, you might want to proceed anyway by
working with the currently closed sources. As explained at
http://aldor.org this source code is available on request.
I compiled an x64 version of Aldor from these sources. See

http://wiki.axiom-developer.org/Aldor

Regards,
Bill Page.




From pcr at pcrt.com  Thu Aug 10 18:39:21 2006
From: pcr at pcrt.com (PCR)
Date: Thu, 10 Aug 2006 16:39:21 -0600
Subject: [Aldor-l] Compiling setup
Message-ID: <44DBB599.2020100@pcrt.com>

I was trying a first problem in Aldor, and got this result.  Mayhap I 
set things up wrong?  Thanks for any help.

pcr1 at Delta:~/aldor$ aldor -fx -laldor sieve.as
cc1: error: unrecognized command line option "-fwritable-strings"
#1 (Fatal Error) C compile failed.  Command was: unicl 
-I/usr/local/aldor/linux/1.0.3/include -c sieve.c
#1 (Warning) Removing file `sieve.c'






From Bill.Page at drdc-rddc.gc.ca  Thu Aug 10 20:16:45 2006
From: Bill.Page at drdc-rddc.gc.ca (Page, Bill)
Date: Thu, 10 Aug 2006 20:16:45 -0400
Subject: [Aldor-l] Compiling setup
In-Reply-To: <44DBB599.2020100@pcrt.com>
Message-ID: <CAE9B164E720CE4D8727792DF8F28AE376742F@corporateex02.Corporate.drdc-rddc.gc.ca>

On Thursday, August 10, 2006 6:39 PM PCR wrote:
> 
> I was trying a first problem in Aldor, and got this result.
> Mayhap I set things up wrong?  Thanks for any help.
> 
> pcr1 at Delta:~/aldor$ aldor -fx -laldor sieve.as
> cc1: error: unrecognized command line option "-fwritable-strings"
> #1 (Fatal Error) C compile failed.  Command was: unicl 
> -I/usr/local/aldor/linux/1.0.3/include -c sieve.c
> #1 (Warning) Removing file `sieve.c'
> 

You don't say what computer and version of operating
system you are using (you should in any error report or
request for help), but the problem seems to be that you
are using a version of the gcc C compiler that is "too new".

The -fx option tells Aldor to compile a native C runtime
program but the curent version of the Aldor compiler
generated intermediate C code that will only work with
a C compiler that supports "writable strings". Newer
versions of C (since gcc 4.0) do not support modification
of string constants.

You can revert to an earlier version of C.

It is also possible to get around this limitation by
compiling to intermediate lisp and then using a lisp
compiler such as GCL that works with the newer C compilers.

Regards,
Bill Page.



From gdr at integrable-solutions.net  Thu Aug 10 20:56:00 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 11 Aug 2006 02:56:00 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <44DBB599.2020100@pcrt.com>
References: <44DBB599.2020100@pcrt.com>
Message-ID: <m38xlwoztr.fsf@zeus.integrable-solutions.net>

PCR <pcr at pcrt.com> writes:

| I was trying a first problem in Aldor, and got this result.  Mayhap I 
| set things up wrong?  Thanks for any help.
| 
| pcr1 at Delta:~/aldor$ aldor -fx -laldor sieve.as
| cc1: error: unrecognized command line option "-fwritable-strings"

I suspect you must be using a recent version of GCC -- the Aldor
configuration file that ships with the RPM is for a very old GCC.  
What you have to do is that you need to modify the variable gcc-hacks
from section [gcc] of /usr/local/aldor/linux/1.0.3/aldor.conf
not to include -fwritable-strings.  There is an obscure comment about
why that flags is needed.  

Mine now reads:

  # On some platforms string literals are stored in read-only segments.
  # This causes problems when users write Aldor programs in which a
  # string literal is used as a buffer. The result is a segfault that
  # is extremely hard to track down, even for experienced Aldor coders.
  # GDR: Well, either that is a bug in Aldor, or a bug in those experienced
  # GDR: aldor coders' programs.  At any rate, that option is no
  # longer supported.
  #  gcc-hacks = -fwritable-strings
     gcc-hacks = 

-- Gaby


From gdr at integrable-solutions.net  Thu Aug 10 20:57:21 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 11 Aug 2006 02:57:21 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <CAE9B164E720CE4D8727792DF8F28AE376742F@corporateex02.Corporate.drdc-rddc.gc.ca>
References: <CAE9B164E720CE4D8727792DF8F28AE376742F@corporateex02.Corporate.drdc-rddc.gc.ca>
Message-ID: <m33bc4ozri.fsf@zeus.integrable-solutions.net>

"Page, Bill" <Bill.Page at drdc-rddc.gc.ca> writes:

[...]

| You can revert to an earlier version of C.

For many people, that is not an option.

-- Gaby


From Bill.Page at drdc-rddc.gc.ca  Thu Aug 10 21:13:38 2006
From: Bill.Page at drdc-rddc.gc.ca (Page, Bill)
Date: Thu, 10 Aug 2006 21:13:38 -0400
Subject: [Aldor-l] Compiling setup
In-Reply-To: <m38xlwoztr.fsf@zeus.integrable-solutions.net>
Message-ID: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>

On Thursday, August 10, 2006 8:56 PM Gabriel Dos Reis wrote:

> ...
> What you have to do is that you need to modify the variable
> gcc-hacks from section [gcc] of /usr/local/aldor/linux/
> 1.0.3/aldor.conf not to include -fwritable-strings.  There
> is an obscure comment about why that flags is needed.  
> 
> Mine now reads:
> 
>   # On some platforms string literals are stored in read-only 
>     segments.
>   # This causes problems when users write Aldor programs in
>     which a
>   # string literal is used as a buffer. The result is a
>     segfault that
>   # is extremely hard to track down, even for experienced 
>     Aldor coders.
>   # GDR: Well, either that is a bug in Aldor, or a bug in 
>     those experienced
>   # GDR: aldor coders' programs.  At any rate, that option
>     is no
>   # longer supported.
>   #  gcc-hacks = -fwritable-strings
>      gcc-hacks = 
> 

Rather than "bug" I think it would be more fair to call
this a "design flaw"... :)

Does your change to aldor.conf actually work?? If so great!
But this does contradict a statement made recently by one
of (the only?) Aldor compiler developer here on this list.
How much testing have you done?

I presumed that the gcc developers removed rewritable-strings
because this "feature" of the C language is no longer
supported -- not just because they are "purists", right? ;)
So if Aldor can generate C code that violates this restriction,
it is probably not such a good idea to remove this "gcc-hack"
until the Aldor developers say it is no longer required. No?

Regards,
Bill Page.



From gdr at integrable-solutions.net  Thu Aug 10 21:46:47 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 11 Aug 2006 03:46:47 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
Message-ID: <m3ejvo2ge0.fsf@zeus.integrable-solutions.net>

"Page, Bill" <Bill.Page at drdc-rddc.gc.ca> writes:

| On Thursday, August 10, 2006 8:56 PM Gabriel Dos Reis wrote:
| 
| > ...
| > What you have to do is that you need to modify the variable
| > gcc-hacks from section [gcc] of /usr/local/aldor/linux/
| > 1.0.3/aldor.conf not to include -fwritable-strings.  There
| > is an obscure comment about why that flags is needed.  
| > 
| > Mine now reads:
| > 
| >   # On some platforms string literals are stored in read-only 
| >     segments.
| >   # This causes problems when users write Aldor programs in
| >     which a
| >   # string literal is used as a buffer. The result is a
| >     segfault that
| >   # is extremely hard to track down, even for experienced 
| >     Aldor coders.
| >   # GDR: Well, either that is a bug in Aldor, or a bug in 
| >     those experienced
| >   # GDR: aldor coders' programs.  At any rate, that option
| >     is no
| >   # longer supported.
| >   #  gcc-hacks = -fwritable-strings
| >      gcc-hacks = 
| > 
| 
| Rather than "bug" I think it would be more fair to call
| this a "design flaw"... :)

Sorry, I can't call it a "design flaw" :-)

| Does your change to aldor.conf actually work?? If so great!

For the little programs I've tried, yes it *seems* to work.
It is either that, or no Aldor program at all. 

| But this does contradict a statement made recently by one
| of (the only?) Aldor compiler developer here on this list.
| How much testing have you done?

| I presumed that the gcc developers removed rewritable-strings
| because this "feature" of the C language is no longer
| supported -- not just because they are "purists", right? ;)

it never was a "feature" of the C language.  

The C language explicitly says that it is undefined behaviour to modify
string literals.  For many reasons, including security, it is
better for the compiler to honor the spirit and the letter of the C
definition: literal strings cannot be modified.

| So if Aldor can generate C code that violates this restriction,
| it is probably not such a good idea to remove this "gcc-hack"
| until the Aldor developers say it is no longer required. No?

I don't quite understand why this really is a problem.  Surely, one
can have string buffers in C programs.  So, why is it that Aldor needs
the buffer to be *string literal*?  That sounds to me like an internal
logical inconsistency.  The generated program cannot be correct.


>From the C standard, section "6.4.5  String literals"
      
       [...]

       [#6] It is unspecified whether  these  arrays  are  distinct
       provided their elements have the appropriate values.  If the
       program attempts to modify such an array,  the  behavior  is
       undefined.


-- Gaby


From ralf at hemmecke.de  Fri Aug 11 03:46:14 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Fri, 11 Aug 2006 09:46:14 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <CAE9B164E720CE4D8727792DF8F28AE376742F@corporateex02.Corporate.drdc-rddc.gc.ca>
References: <CAE9B164E720CE4D8727792DF8F28AE376742F@corporateex02.Corporate.drdc-rddc.gc.ca>
Message-ID: <44DC35C6.1010003@hemmecke.de>

See

http://article.gmane.org/gmane.comp.lang.aldor/10/match=fwritable+strings
Date: 2005-02-08 19:48:53 GMT (1 year, 26 weeks, 1 day, 5 hours and 51 
minutes ago)

In a recent mail from one of the Aldor maintainers (which unfortunately 
wasn't copied to aldor-l) I can read

   All I said is that aldor cannot use the new version of the GNU C
   compiler because FSF decided to create the string literals as
   read-only.  Because of this, aldor no longer works with gcc 4 and
   above.  I tried again to compile aldor with gcc 4 and after some
   "standard compliance" changes I managed to compile the compiler, but
   it failed to compile the aldor runtime.  If it would have been a
   simple change to replace the writable literals (like the suggested
   char a[] ="a"), it would have been done by now.  If you look at the
   comments related to gcc-hacks in aldor.conf, you will see that it was
   used to avoid a bug.

There is still some bug in the Aldor compiler sources, and unfortunately 
we must wait until the sources are open to fix that.

Ralf


From ralf at hemmecke.de  Fri Aug 11 04:05:34 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Fri, 11 Aug 2006 10:05:34 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <CAE9B164E720CE4D8727792DF8F28AE376742F@corporateex02.Corporate.drdc-rddc.gc.ca>
References: <CAE9B164E720CE4D8727792DF8F28AE376742F@corporateex02.Corporate.drdc-rddc.gc.ca>
Message-ID: <44DC3A4E.9090601@hemmecke.de>

See http://www.aldor.org/faqs.html
When I compile an Aldor source file, it doesn't find gcc32?

It says:
Answer:Aldor compiler is not compatible with latest version of gcc 
(version 4). New linux distributions use version 4 of gcc as the default 
C compiler. If that is the case in your distribution, using gcc will not 
work. That is the reason we replaced gcc with gcc32 in aldor.conf. If 
you use an older Linux distribution you should comment those two lines 
from aldor.conf that contain gcc32. The current setting should work for 
Fedora Core 4 and 5, for other linux distributions find the name of the 
older C compiler and use that instead of gcc32.

Ralf


From ralf at hemmecke.de  Fri Aug 11 04:25:07 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Fri, 11 Aug 2006 10:25:07 +0200
Subject: [Aldor-l] automatic dependency generation was: Re:
	[Axiom-developer] lattice
In-Reply-To: <m3lkpw2h83.fsf@zeus.integrable-solutions.net>
References: <200608101947.k7AJlx4K011635@axiom-developer.org>
	<m3lkpw2h83.fsf@zeus.integrable-solutions.net>
Message-ID: <44DC3EE3.8060802@hemmecke.de>

> A project might be to have the compiler output spad dependencies --
> just like GCC is able to output dependencies, which greatly
> facilitates the tedious part of writing Makefiles and keeping them in
> sync; Automake uses it.

That would be a nice feature, but even if it probably will not happen 
that often, Aldor's "extend" might complicate that process (I don't say 
it makes it impossible).

Look at the files given below.
My intention is to compile them via

--aldor         aaaf1.as;  ar rv libmyprj.al aaaf1.ao;  rm aaaf1.ao
--aldor -lmyprj aaaf2.as;  ar rv libmyprj.al aaaf2.ao;  rm aaaf2.ao
--aldor -lmyprj aaaf3.as;  ar rv libmyprj.al aaaf3.ao;  rm aaaf3.ao

Assume the compiler first gets aaaf3.as. It sees either #library or 
"extend" and gives up, since no library is existing.
So it takes aaaf2.as and delays it for the same reason.
It can, however, compile aaaf1.as. Fine. But it really has to produce 
the .ao file and the library in order to be able to go on. So it is not 
just a lightweight compilation without producing code.
Then it starts again by looking at aaaf3.as. No compilation possible, 
since the function "bar" cannot be found. Now, is this just because 
there is a spelling mistake in "bar" or because the compiler has not yet 
seen aaaf2.as? OK, the compiler delays aaaf3.as and compiles aaaf2.as 
(with which options?). That works. Again the compiler must produce code 
so that aaaf3.as can compile.

One can easily setup several more extensions and finding the 
dependencies just explodes combinatorially.

A simple workaround would be to introduce a CONVENTION. One library may 
only extend a domain once. If there is need to extend another time, then 
that should happen in another library. In this way one gets a (more or 
less) natural layered structure and the library structure becomes easier 
to understand for a human.

There already happen several "extend"s in libalgebra (distributed with 
Aldor) and it is quite hard to find your way through the sources. One 
constantly has to check what the Makefile says.

Ralf

---BEGIN aaaf1.as
#include "aldor"
define CatA: Category == with {foo: () -> ()}
Dom: with {foo: () -> ()} == add {foo(): () == {}}
---END aaaf1.as

---BEGIN aaaf2.as
#include "aldor"
#library MyPrj "myprj"
import from MyPrj
extend Dom with {bar: () -> ()} == add {bar(): () == foo()}
---END aaaf2.as

---BEGIN aaaf3.as
#include "aldor"
#library MyPrj "myprj"
import from MyPrj
extend Dom with {ans: () -> ()} == add {ans(): () == bar()}
---END aaaf3.as


From tmgisi at gmx.at  Fri Aug 11 05:59:26 2006
From: tmgisi at gmx.at (Christian Aistleitner)
Date: Fri, 11 Aug 2006 11:59:26 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
Message-ID: <op.td351cpau6j4vy@spencer.aistleitner.info>

Hello,

On Fri, 11 Aug 2006 03:46:47 +0200, Gabriel Dos Reis  
<gdr at integrable-solutions.net> wrote:

> "Page, Bill" <Bill.Page at drdc-rddc.gc.ca> writes:
>
> | On Thursday, August 10, 2006 8:56 PM Gabriel Dos Reis wrote:
> |
> | > ...
> | > What you have to do is that you need to modify the variable
> | > gcc-hacks from section [gcc] of /usr/local/aldor/linux/
> | > 1.0.3/aldor.conf not to include -fwritable-strings.  There
> | > is an obscure comment about why that flags is needed.
> | >
> | > Mine now reads:
> | >
> | >   # On some platforms string literals are stored in read-only
> | >     segments.
> | >   # This causes problems when users write Aldor programs in
> | >     which a
> | >   # string literal is used as a buffer. The result is a
> | >     segfault that
> | >   # is extremely hard to track down, even for experienced
> | >     Aldor coders.
> | >   # GDR: Well, either that is a bug in Aldor, or a bug in
> | >     those experienced
> | >   # GDR: aldor coders' programs.  At any rate, that option
> | >     is no
> | >   # longer supported.
> | >   #  gcc-hacks = -fwritable-strings
> | >      gcc-hacks =
> | >
> |
[...]
>
> | Does your change to aldor.conf actually work?? If so great!
>
> For the little programs I've tried, yes it *seems* to work.
> It is either that, or no Aldor program at all.

Just consider the attached test.as. It does just the dangerous thing (as  
described in the aldor.conf) -- modifying an Aldor String constant.  
Consider the following output with writable strings:

____________________________________________
tmgisi at spencer
cwd: ~/aldor
$ grep gcc-hacks.*= /opt/aldor/include/aldor.conf ; LC_ALL=C  
/opt/aldor/bin/aldor \
-M no-abbrev -C args=-Wopts=-m32 -Fx -laldor test.as && ./test
   gcc-hacks = -fwritable-strings
cc1: note: -fwritable-strings is deprecated; see documentation for details
cc1: note: -fwritable-strings is deprecated; see documentation for details
abcdefghij
abcXefghij

And now without writable strings

____________________________________________
tmgisi at spencer
cwd: ~/aldor
$ grep gcc-hacks.*= /opt/aldor/include/aldor.conf ; LC_ALL=C  
/opt/aldor/bin/aldor \
-M no-abbrev -C args=-Wopts=-m32 -Fx -laldor test.as && ./test
   gcc-hacks =
abcdefghij
Speicherzugriffsfehler


So at least for this simple file, it does not work. Of course you can  
rewrite the Aldor code to make it work. The provided test.as shows  
"-fwritable-strings" is not just a relict in the aldor.conf file, but it  
is actually needed.

*Please* do *not* omit "-fwritable-strings", for your own sake.
Instead:
1. get an old enough compiler (wherever this is possible), so you can  
compile the programs and
2. keep mocking about the issue.

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.

On another layer the test.as's "abcdefghij" is a constant. However,  
implicitly, the constant is fed to the
   string: Literal -> String
function from the String domain. Actually (ignoring the implementation of  
the string function), the constant "abcdefghij" is not used directly, but  
only the result of passing the constant to a function is used and modified  
via "a.3". (Of course, due to the implementation of string$String,  
"abcdefghij" and the variable a are the same thing, but that's a different  
issue) So shouldn't string$String declare it generates memory aliases?

The question is about "What is considered bad style?".
aldor.conf explicitly deals with the issue of whether string literals are  
read-only or not, so I doubt that Aldor compiler developers consider it  
bad style.


--
Kind regards,
Christian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.as
Type: application/octet-stream
Size: 182 bytes
Desc: not available
URL: <http://mail.aldor.org/pipermail/aldor-l_aldor.org/attachments/20060811/cb4d178f/attachment-0001.obj>

From gdr at integrable-solutions.net  Fri Aug 11 06:52:33 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 11 Aug 2006 12:52:33 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <op.td351cpau6j4vy@spencer.aistleitner.info>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
Message-ID: <m3u04j8rym.fsf@zeus.integrable-solutions.net>

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


You are however correct that, given that the erroneous translation
(from the only compiler available) is known  and documented, it is not
just bad style but actually a programming error.


"a" above is not a constant -- or else the language could have
forbidden its modification.  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. 

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

If you initialize an integer variable with the integer literal 1, and
you subsequently modify that variable to hold 2, do you expect the aldor
compiler to pretend that the *integer literal 1* is actually 2?

[...]

| The question is about "What is considered bad style?".
| aldor.conf explicitly deals with the issue of whether string literals
| are  read-only or not, so I doubt that Aldor compiler developers
| consider it  bad style.

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

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

-- Gaby


From pcr at pcrt.com  Fri Aug 11 15:25:34 2006
From: pcr at pcrt.com (PCR)
Date: Fri, 11 Aug 2006 13:25:34 -0600
Subject: [Aldor-l] Compiling setup
In-Reply-To: <CAE9B164E720CE4D8727792DF8F28AE376742F@corporateex02.Corporate.drdc-rddc.gc.ca>
References: <CAE9B164E720CE4D8727792DF8F28AE376742F@corporateex02.Corporate.drdc-rddc.gc.ca>
Message-ID: <44DCD9AE.5040507@pcrt.com>

Page, Bill wrote:
> On Thursday, August 10, 2006 6:39 PM PCR wrote:
>   
>> I was trying a first problem in Aldor, and got this result.
>> Mayhap I set things up wrong?  Thanks for any help.
>>
>> pcr1 at Delta:~/aldor$ aldor -fx -laldor sieve.as
>> cc1: error: unrecognized command line option "-fwritable-strings"
>> #1 (Fatal Error) C compile failed.  Command was: unicl 
>> -I/usr/local/aldor/linux/1.0.3/include -c sieve.c
>> #1 (Warning) Removing file `sieve.c'
>>
>>     
>
> You don't say what computer and version of operating
> system you are using (you should in any error report or
> request for help), but the problem seems to be that you
> are using a version of the gcc C compiler that is "too new".
>
> The -fx option tells Aldor to compile a native C runtime
> program but the curent version of the Aldor compiler
> generated intermediate C code that will only work with
> a C compiler that supports "writable strings". Newer
> versions of C (since gcc 4.0) do not support modification
> of string constants.
>
> You can revert to an earlier version of C.
>
> It is also possible to get around this limitation by
> compiling to intermediate lisp and then using a lisp
> compiler such as GCL that works with the newer C compilers.
>
> Regards,
> Bill Page.
>
>
>   
I am trying the detour. aldor -flsp -laldor sieve.as gave me a file 
sieve.lsp. Running gcl and typing (load "sieve.lsp") at the promt gave me:

 >(load "sieve.lsp")

Loading sieve.lsp

Error: "FOAM" is not of type (OR SYMBOL STRING ...).
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by IN-PACKAGE.
Broken at IN-PACKAGE. Type :H for Help.
 >>

This has to be my mistake somehow!



From bill.page1 at synthesis.anikast.ca  Sat Aug 12 01:47:15 2006
From: bill.page1 at synthesis.anikast.ca (Bill Page)
Date: Sat, 12 Aug 2006 01:47:15 -0400
Subject: [Aldor-l] Compiling setup
In-Reply-To: <44DCD9AE.5040507@pcrt.com>
Message-ID: <021801c6bdd2$d7833580$6900a8c0@asus>

On August 11, 2006 3:26 PM PCR wrote:
> 
> Bill Page wrote:
> > ...
> > It is also possible to get around this limitation by
> > compiling to intermediate lisp and then using a lisp
> > compiler such as GCL that works with the newer C compilers.
> >

> I am trying the detour. aldor -flsp -laldor sieve.as gave me a
> file sieve.lsp. Running gcl and typing (load "sieve.lsp") at the 
> promt gave me:
> 
>  >(load "sieve.lsp")
> 
> Loading sieve.lsp
> 
> Error: "FOAM" is not of type (OR SYMBOL STRING ...).
> Fast links are on: do (si::use-fast-links nil) for debugging
> Error signalled by IN-PACKAGE.
> Broken at IN-PACKAGE. Type :H for Help.
>  >>
> 
> This has to be my mistake somehow!
> 

I am sorry that I mislead you about how easy this was to do.
It turns out that although Aldor can compile to lisp, apparently
there is currently no stand alone runtime environment for lisp
like the C runtime library for Aldor. :( I was sure I actually
had an example of Aldor used with GCL this way at one time, but
I can't seem to find it now. )

There is however a lisp runtime for running Aldor inside Axiom.

See the example here:

http://wiki.axiom-developer.org/SandBoxAldorSieve

Note that the example has to be changed a little to be compatible
with the Axiom library.

It is also possible to use Aldor outside of Axiom as described
here:

http://www.aldor.org/docs/HTML/chap18.html#12

to compile Aldor to lisp code. Then you just need Axiom to compile
and run the lisp code:

  $ AXIOMsys
  (1) -> )compile sieve.lsp
  (1) -> sieve 2000

But in the current binary distribution of Axiom+Aldor to get
stand alone Aldor to compile for Axiom, you most copy the file
libaxiom.al from Axiom .../mnt/linux/algebra/libaxiom.al to
...aldor/linux/1.0.3/lib

And all of this will work on a linux system with an up to date
gcc compiler.

I hope this helps.

Regards,
Bill Page.




From tmgisi at gmx.at  Sat Aug 12 06:20:57 2006
From: tmgisi at gmx.at (Christian Aistleitner)
Date: Sat, 12 Aug 2006 12:20:57 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <m3u04j8rym.fsf@zeus.integrable-solutions.net>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
Message-ID: <op.td51o72eu6j4vy@spencer.aistleitner.info>

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


From gdr at integrable-solutions.net  Sat Aug 12 09:24:08 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 12 Aug 2006 15:24:08 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <op.td51o72eu6j4vy@spencer.aistleitner.info>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
Message-ID: <m3slk22ikn.fsf@zeus.integrable-solutions.net>

"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



From watt at scl.csd.uwo.ca  Sat Aug 12 10:19:42 2006
From: watt at scl.csd.uwo.ca (Stephen Watt)
Date: Sat, 12 Aug 2006 10:19:42 -0400
Subject: [Aldor-l] Compiling setup
In-Reply-To: <m3slk22ikn.fsf@zeus.integrable-solutions.net>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
Message-ID: <20060812141942.GA30663@ptibonum.scl.csd.uwo.ca>

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


From gdr at integrable-solutions.net  Sat Aug 12 10:39:47 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 12 Aug 2006 16:39:47 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <20060812141942.GA30663@ptibonum.scl.csd.uwo.ca>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<20060812141942.GA30663@ptibonum.scl.csd.uwo.ca>
Message-ID: <m37j1enhl8.fsf@zeus.integrable-solutions.net>

Stephen Watt <watt at scl.csd.uwo.ca> writes:

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

Many thanks!

I hope there will be a version for GNU/Linux systems working with the
most current glibc (e.g. glibc-2.4 and higher).

-- Gaby


From ralf at hemmecke.de  Sat Aug 12 12:32:49 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Sat, 12 Aug 2006 18:32:49 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <op.td51o72eu6j4vy@spencer.aistleitner.info>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>	<op.td351cpau6j4vy@spencer.aistleitner.info>	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
Message-ID: <44DE02B1.4030704@hemmecke.de>

Christian's mail was quite hard to read due to strange line breaks, but 
I think he made an important point. If the compiler sees something like

   "blah"

in general it is even impossible to guess the type of that thing.

See my posts to axiom-developer from
14-Feb-2005 (Subject: "The symbol 4 (was Re: Aldor and Axiom)") and
22-Feb-2006 (Subject: "1: %").

Or simply let me repeat the program...

---file crazy.as--
#include "aldor"
CrazyInteger: IntegerType with {string: Literal -> %} == Integer add {
     Rep == Integer;
     import from Rep;
     integer(l: Literal): % == per(integer(l)$Integer + 1);
     string(l: Literal): % == per 42;
}

main(): () == {
     import from TextWriter, Character;
     import from CrazyInteger;
     stdout << "This is crazy :" << space << 1 << newline;
     stdout << "This is crazy :" << space << 2 << newline;
     stdout << "Fourtytwo" + 4 << newline;
}

main();
---end crazy.as

For me it says.
 >aldor -grun -laldor crazy.as
42 1
42 3
47

I cannot believe that Christian meant:
 >   local litA: Literal := "abcdefghij";    -- (*)
should be translated to
 >   char * litA = "abcdefghij";

First of all, the line (*) does not compile at all with libaldor. And I 
even don't know of a way to create a thing of type Literal.
And also the C code is probably not right.

As I see it, the things of type Literal are the true constants, since 
they cannot change as they are character strings that appear in the .as 
file. The type String, however, is a library thing (as Christian pointed 
out). Now, how a literal constant appears as a string is completely up 
to the library. So I guess, we are actually talking about whether or not
things of type Literal should be put into a non-writable data section by 
the compiler.

You should not be misled by the fact that a library (like libaldor) 
provides a type String. And the Aldor library, makes it implicitly clear 
that strings are writeable, by providing a function

   set!: (String, MachineInteger, Character) -> String

So if the (future) compiler puts literals into read-only memory, then 
the library definition

   string(l:Literal):% == string(l pretend Pointer);

is the bug and must be changed.

Ralf


From ralf at hemmecke.de  Sat Aug 12 12:57:31 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Sat, 12 Aug 2006 18:57:31 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <m3slk22ikn.fsf@zeus.integrable-solutions.net>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>	<op.td351cpau6j4vy@spencer.aistleitner.info>	<m3u04j8rym.fsf@zeus.integrable-solutions.net>	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
Message-ID: <44DE087B.6040904@hemmecke.de>

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

I consider it bad style! But probably for another reason. It contains a 
syntax error. Christian should have written

local a:String := "abc";

or

local a:String == "abc";

In the first case, modification should be allowed. In the second it 
would be quite questionable. But then

a.3 := char "X";

is the same as

set!(a, 3, char "X);

It's a BANG function and by convention destructive so one might expect 
strange behaviour even if a is a constant.

It becomes interesting to ask what the semantics of the following 
program should be.

---BEGIN aaavarconst.as
#include "aldor"
a: String := "a";   c: String == "c";
b: String := "a";   d: String == "c"
a.1 := char "X";    c.1 := char "Y";
---END aaavarconst.as

Clearly one expects b = "a". But would be d="Y" also be OK?

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

Hmm, until someone proves me wrong, I would claim that String is not 
part of the Aldor language. And it is also not a part of the runtime. It 
is defined in the Aldor library "libaldor". And I don't count libaldor 
as part of the compiler stuff.

Ralf


From gdr at integrable-solutions.net  Sat Aug 12 13:08:43 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 12 Aug 2006 19:08:43 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <44DE02B1.4030704@hemmecke.de>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<44DE02B1.4030704@hemmecke.de>
Message-ID: <m3d5b5hof8.fsf@zeus.integrable-solutions.net>

Ralf Hemmecke <ralf at hemmecke.de> writes:

| Christian's mail was quite hard to read due to strange line breaks, but 
| I think he made an important point. If the compiler sees something like
| 
|    "blah"
| 
| in general it is even impossible to guess the type of that thing.

To my eyes, that is a literal string.

[...]

| I cannot believe that Christian meant:
|  >   local litA: Literal := "abcdefghij";    -- (*)
| should be translated to
|  >   char * litA = "abcdefghij";
| 
| First of all, the line (*) does not compile at all with libaldor. And I 
| even don't know of a way to create a thing of type Literal.
| And also the C code is probably not right.

Why would  the C code not right?

[...]

| You should not be misled by the fact that a library (like libaldor) 
| provides a type String. And the Aldor library, makes it implicitly clear 
| that strings are writeable, by providing a function
| 
|    set!: (String, MachineInteger, Character) -> String
| 
| So if the (future) compiler puts literals into read-only memory, then 
| the library definition
| 
|    string(l:Literal):% == string(l pretend Pointer);
| 
| is the bug and must be changed.

That is essentially the difference betweenn

   char *litA = "abcdefghij";

and

   char strA[] = "abcdefghij";

litA points to a storage where resides string literal.  strA is an
array whose elementss  can be freely modified.

The first morally corresponds to Literal, and the second to String.

All major programming languages I know of that provide a modifiable
string type behave correctly when a string is initialized with a literal.

-- Gaby


From gdr at integrable-solutions.net  Sat Aug 12 13:45:43 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 12 Aug 2006 19:45:43 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <44DE087B.6040904@hemmecke.de>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<44DE087B.6040904@hemmecke.de>
Message-ID: <m3veoxg854.fsf@zeus.integrable-solutions.net>

Ralf Hemmecke <ralf at hemmecke.de> 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*.
| 
| I consider it bad style! But probably for another reason. It contains
| a syntax error.

:-)

| Christian should have written
| 
| local a:String := "abc";
| 
| or
| 
| local a:String == "abc";
| 
| In the first case, modification should be allowed.

OK.

| In the second it would be quite questionable.

You can't define a programming language semantics in terms of
"questionable".  You have to say whether it is well-formed with
well-defined behaviour, or it has no defined behaviour.  If the latter,
we just declare the program is ill-formed.  In a strongly typed
language, it is an error that should be either caught at compile time 
or at runtime.

| But then
| 
| a.3 := char "X";
| 
| is the same as
| 
| set!(a, 3, char "X);
| 
| It's a BANG function and by convention destructive so one might expect
| strange behaviour even if a is a constant.

So back to my question: Is is a well-formed program with well-defined
behavior?  That is all that counts.  I can't compute the behavior of
a program with consideration like "bad style" -- the computer does not
know that.

[...]

| > 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.
| 
| Hmm, until someone proves me wrong, I would claim that String is not
| part of the Aldor language. And it is also not a part of the
| runtime. It is defined in the Aldor library "libaldor". And I don't
| count libaldor as part of the compiler stuff.

That is a fine distinction.  However, it does not work in practice: I
can't test any useful program coming with the AUG without having
libaldor.   AUG says, page 12:

   #include "aldor" is the general include statement that will allow
   the types and functions from libaldor to be visible. It is
   necessary to use it (or an equivalent library) in order to write
   programs. 



For all practical purposes, libaldor is part of the compiler.  You can
distinguish the front-end from the supporting runtime system, but you
cannot usefully, meaningfully, and practically dissociate it from the
compiler. 

Among other languages that have tried similar distinctions, you will
find the C programming language.  The C programming language defines
two families of C implementations:

   * freestanding implementations, and
   * hosted implementations.

A freestanding implementation is one where you don't necessarily have
_all_ of the C library (you may view GCC/gcc as a freestanding
implementation, but the actual issue is more complicated than that).
In a freestanding implementation, the function "main()" is not
required for starting up the program (it is up to the implementation).

A hosted implementation is one which is required to provide all of the
C library and the function "main()" is required as entry point.  You
may view GCC/gcc as not being a hosted implementation.  However, the
actual issue is more complicated than that.  For example, GCC/gcc in a
non-freestanding-mode assumes that any symbol with external linkage
that is also defined by the C standard library actually has the
semantics of the C library.  It thus proceed to apply many
transformations and optimizations based on the standard semantics.
As you see, GCC/gcc does not provide you with a C library but it does
assume all standard semantics and acts as if the runtime library is
part of it.  That, in effect, mirrors the spirit of the standard.

>From my other experience contributing to implement the C++ standard
library, we (the libstdc++ team) have come to appreciate that there is
no absolute meaningful way to separate the compiler from the runtime
support systems.  Here, I won't spend time on the pains my
co-maintainers and I went through.

Granted, all of the above examples come from personal experience so
may constitute biased examples, but you can see that they started out
as distinguishing between the "pure" compiler and the supporting
runtime system.  It is a theory that does not work well in practice.
The runtime system has to make assumptions about the front-end, andthe
front-end has to make assumptions about the library.  Of course, we
all want those set of assumptions to be as minimal as possible.

I was quite happy to see that the Aldor distribution did not get into
that trap.

Even if you succeeded in providing an alternate, independent,
implementation of libaldor, it will still remain as an essential part
needed to have any useful Aldor program running.  It is

-- Gaby


From ralf at hemmecke.de  Sat Aug 12 16:26:55 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Sat, 12 Aug 2006 22:26:55 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <m3d5b5hof8.fsf@zeus.integrable-solutions.net>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>	<op.td351cpau6j4vy@spencer.aistleitner.info>	<m3u04j8rym.fsf@zeus.integrable-solutions.net>	<op.td51o72eu6j4vy@spencer.aistleitner.info>	<44DE02B1.4030704@hemmecke.de>
	<m3d5b5hof8.fsf@zeus.integrable-solutions.net>
Message-ID: <44DE398F.1070005@hemmecke.de>

> | If the compiler sees something like
> | 
> |    "blah"
> | 
> | in general it is even impossible to guess the type of that thing.

> To my eyes, that is a literal string.

That seems to be true, but what does "literal string" actually mean?

It is definitely not something of the libaldor type String (my base 
library might be something else where String does not even exist). And 
as you saw from the program I gave, it could mean the Integer 4.

I guess the Aldor type Literal is probably the closest we can get.

> |  >   char * litA = "abcdefghij";

> Why would  the C code not right?

>    char *litA = "abcdefghij";
>    char strA[] = "abcdefghij";

> litA points to a storage where resides string literal.  strA is an
> array whose elementss  can be freely modified.

Sorry, my knowledge of C is mainly non-existing.

> All major programming languages I know of that provide a modifiable
> string type behave correctly when a string is initialized with a literal.

I think the libaldor type String ought to do that. But as I said, I 
actually don't consider String as part of the Aldor language.

Ralf


From ralf at hemmecke.de  Sat Aug 12 17:25:36 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Sat, 12 Aug 2006 23:25:36 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <m3veoxg854.fsf@zeus.integrable-solutions.net>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>	<op.td351cpau6j4vy@spencer.aistleitner.info>	<m3u04j8rym.fsf@zeus.integrable-solutions.net>	<op.td51o72eu6j4vy@spencer.aistleitner.info>	<m3slk22ikn.fsf@zeus.integrable-solutions.net>	<44DE087B.6040904@hemmecke.de>
	<m3veoxg854.fsf@zeus.integrable-solutions.net>
Message-ID: <44DE4750.9070704@hemmecke.de>

> | local a:String == "abc";
> | In the second it would be quite questionable.
... what the value of a is after assignment
    a.3 := char "X";

> You can't define a programming language semantics in terms of
> "questionable".

I did not define the language. In fact, what I wanted to say is, that I 
know how the current compiler behaves in that case, but not how the 
Aldor language defines it.

 > You have to say whether it is well-formed with
> well-defined behaviour, or it has no defined behaviour.  If the latter,
> we just declare the program is ill-formed.  In a strongly typed
> language, it is an error that should be either caught at compile time 
> or at runtime.

> | But then
> | 
> | a.3 := char "X";
> | 
> | is the same as
> | 
> | set!(a, 3, char "X);
> | 
> | It's a BANG function and by convention destructive so one might expect
> | strange behaviour even if a is a constant.

For the compiler the above assignment is syntactic sugar for the 
function call to set!. That destructive functions should have a name 
that ends in ! is a convention that is not known to the compiler. So I 
guess a compiler would have hard times to figure out that

set!(a, 3, char "X)

actually modifies the constant a. Am I wrong? I guess, that is the 
reason why the Aldor compiler doesn't try. I think the program is 
well-formed (sorry I am not really familiar with this concept), but its 
behaviour is probably undefined. set! is a side effecting function that 
modifies something in memory that is related to its first argument.

I cannot say that I like it very much if I cannot rely on the fact that 
a constant is constant. But on the other hand, using a BANG function 
warns me that I cannot rely on what strange side effect I get.

Just being curious... is there a legal C program that defines a constant 
array, and a pointer (or whatever) to on element of that array and then 
modifies that entry in-place? If that is possible then there would be 
non-constant constants in C.

> | > 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.
> | 
> | Hmm, until someone proves me wrong, I would claim that String is not
> | part of the Aldor language. And it is also not a part of the
> | runtime. It is defined in the Aldor library "libaldor". And I don't
> | count libaldor as part of the compiler stuff.
> 
> That is a fine distinction.  However, it does not work in practice: I
> can't test any useful program coming with the AUG without having
> libaldor.

Yes, you can. Take axllib. That also ships with the Aldor compiler and 
also has a type which is called String. You probably guess rightly that
String$LibAldor is not the same as String$AxlLib. Of course they are 
quite similar. As a library writer you would not want to confuse people 
too much.

Or, if you like, take libaxiom... yet another String type.

If you look at the sources you find that the representation of String is

PackedPrimitiveArray Character

in libaldor and BArr in axllib. One can certainly track down what
PackedPrimitiveArray or BArr is in terms of more primitive types of 
FOAM, but you see, String is a library thing.

In fact, I quite like that Aldor has a quite limited set of things that 
are built into the language.

> For all practical purposes, libaldor is part of the compiler.  You can
> distinguish the front-end from the supporting runtime system, but you
> cannot usefully, meaningfully, and practically dissociate it from the
> compiler. 

Hmm, when I came in contact with Aldor, I compiled against libaxiom. 
Since I realised that the compilation took too long and there was a 
light-weight library that was sufficient for me, I compiled against 
axllib. Then Bronstein wrote salli (standard aldor library) which is 
different from and incompatible with axllib. Salli basically became 
libaldor (after a few modifications). That is the history of the basic 
libraries of Aldor. I really cannot say that I believe that the compiler 
and this library are too attached. And if the libaldor and libalgebra 
don't become free enough, I'll think about writing my own GPL'ed one.

> Among other languages that have tried similar distinctions, you will
> find the C programming language.

[...]

>>From my other experience contributing to implement the C++ standard
> library, we (the libstdc++ team) have come to appreciate that there is
> no absolute meaningful way to separate the compiler from the runtime
> support systems.  Here, I won't spend time on the pains my
> co-maintainers and I went through.

Oh, please... I am all for standards. And I would even like to have a 
standard aldor library that is open source, well tested and a literate 
program, but still, I would call it a library. It is not part of the 
actual (aldor) language.

If you call libaldor "runtime system", OK, but currently it is not.
libaldor is shipped with the compiler, but for example in order to 
extend Axiom, you can happily do it without libaldor. (You even must do 
it without libaldor.) So if we end up with a standard aldor library and 
remove all the mess of the currently existing base libraries, I am all 
for it. If that even results in better optimization, the better.

> I was quite happy to see that the Aldor distribution did not get into
> that trap.

Hmm, really? Do you take libaldor.al or libaxllib.al? They are both 
provided with the compiler. ;-)

Ralf


From ldragan at aldor.org  Sat Aug 12 18:46:38 2006
From: ldragan at aldor.org (ldragan at aldor.org)
Date: Sat, 12 Aug 2006 18:46:38 -0400
Subject: [Aldor-l] Compiling setup
In-Reply-To: <20060812141942.GA30663@ptibonum.scl.csd.uwo.ca>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<20060812141942.GA30663@ptibonum.scl.csd.uwo.ca>
Message-ID: <20060812224638.GA5946@aquarium.aldor.org>

On Sat, Aug 12, 2006 at 10:19:42AM -0400, Stephen Watt wrote:
> The Aldor compiler does indeed need to be fixed to not rely on
> implementation dependencies of the C compiler in this respect.

I think this issue should be fixed in the library.  The Aldor compiler
only deals with literals, which are constant like in C.  The library
implementing String should know that string literals are constant
and either make them constant or copy them when a new String is
initialized.

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

The solution proposed by Christian is very reasonable and
should work with the current compiler.

--
Laurentiu



From watt at scl.csd.uwo.ca  Sat Aug 12 18:55:29 2006
From: watt at scl.csd.uwo.ca (Stephen Watt)
Date: Sat, 12 Aug 2006 18:55:29 -0400
Subject: [Aldor-l] Compiling setup
In-Reply-To: <20060812224638.GA5946@aquarium.aldor.org>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<20060812141942.GA30663@ptibonum.scl.csd.uwo.ca>
	<20060812224638.GA5946@aquarium.aldor.org>
Message-ID: <20060812225529.GC11239@ptibonum.scl.csd.uwo.ca>

Laurentiu, I think there is more to this than meets the eye.

The Aldor system developers are not the only ones to write libraries -- 
the compiler should have correct behaviour for any legitimate Aldor code
and not break depending on the underlying C compiler.

-- Stephen


On Sat, Aug 12, 2006 at 06:46:38PM -0400, ldragan at aldor.org wrote:
> On Sat, Aug 12, 2006 at 10:19:42AM -0400, Stephen Watt wrote:
> > The Aldor compiler does indeed need to be fixed to not rely on
> > implementation dependencies of the C compiler in this respect.
> 
> I think this issue should be fixed in the library.  The Aldor compiler
> only deals with literals, which are constant like in C.  The library
> implementing String should know that string literals are constant
> and either make them constant or copy them when a new String is
> initialized.
> 
> > 
> > We will look into this without waiting until the open source release.
> 
> The solution proposed by Christian is very reasonable and
> should work with the current compiler.
> 
> --
> Laurentiu


From gdr at integrable-solutions.net  Sat Aug 12 20:02:25 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 13 Aug 2006 02:02:25 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <44DE4750.9070704@hemmecke.de>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<44DE087B.6040904@hemmecke.de>
	<m3veoxg854.fsf@zeus.integrable-solutions.net>
	<44DE4750.9070704@hemmecke.de>
Message-ID: <m37j1da4fi.fsf@zeus.integrable-solutions.net>

Ralf Hemmecke <ralf at hemmecke.de> writes:

| > | local a:String == "abc";
| > | In the second it would be quite questionable.
| ... what the value of a is after assignment
|     a.3 := char "X";

Stephen gave me an explanation and if I did understand correctly, that
assignment is also OK.

[...]

| Just being curious... is there a legal C program that defines a
| constant array, and a pointer (or whatever) to on element of that
| array and then modifies that entry in-place?

If I understand the question correctly, the answer is "no".

[...]

| > I was quite happy to see that the Aldor distribution did not get into
| > that trap.
| 
| Hmm, really? 

Yes, for all practical pruposes, I find the distinction artificial.

-- Gaby


From gdr at integrable-solutions.net  Sat Aug 12 20:15:52 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 13 Aug 2006 02:15:52 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <44DE398F.1070005@hemmecke.de>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<44DE02B1.4030704@hemmecke.de>
	<m3d5b5hof8.fsf@zeus.integrable-solutions.net>
	<44DE398F.1070005@hemmecke.de>
Message-ID: <m31wrla3t3.fsf@zeus.integrable-solutions.net>

Ralf Hemmecke <ralf at hemmecke.de> writes:

| > | If the compiler sees something like
| > | |    "blah"
| > | | in general it is even impossible to guess the type of that thing.
| 
| > To my eyes, that is a literal string.
| 
| That seems to be true, but what does "literal string" actually mean?

s/literal string/string literal/

The meaning is whatever the Aldor definition says it is.  See section
5.2, page 38.

| It is definitely not something of the libaldor type String (my base
| library might be something else where String does not even exist). And
| as you saw from the program I gave, it could mean the Integer 4.

I appreciate all that.  The issue under discussion, is what should be
the proper translation of 

    a : String == "vlndoffmnelcfeeqmeejfoie";

into C.

| I guess the Aldor type Literal is probably the closest we can get.

The way literals are treated in Aldor is not very different from what
Haskell does for integer literals for example.  If you're not happy
with the appearant type "string literal", you can view it as having
type (borrowing notation from Haskell):

    "blah" : forall a. () -> a

-- Gaby


From tmgisi at gmx.at  Sun Aug 13 03:01:53 2006
From: tmgisi at gmx.at (Christian Aistleitner)
Date: Sun, 13 Aug 2006 09:01:53 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <m37j1enhl8.fsf@zeus.integrable-solutions.net>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<20060812141942.GA30663@ptibonum.scl.csd.uwo.ca>
	<m37j1enhl8.fsf@zeus.integrable-solutions.net>
Message-ID: <op.td7m5fu7u6j4vy@spencer.aistleitner.info>

Hello,

On Sat, 12 Aug 2006 16:39:47 +0200, Gabriel Dos Reis  
<gdr at integrable-solutions.net> wrote:

> I hope there will be a version for GNU/Linux systems working with the
> most current glibc (e.g. glibc-2.4 and higher).

I am puzzled ... is there already some glibc-2.5 or glibc-3.0? According to
http://www.gnu.org/software/libc/
glibc-2.4 is the current version of glibc.

I have glibc-2.4 installed on my gentoo box (and no glibc-2.3 or other  
version of glibc) and it just works very well with aldor.
I know that on the webpage, you can only download the aldor compiler for  
glibc-2.3 (and glibc-2.2) for GNU/Linux OSes.
Is it a coincidence that everything works with glibc-2.4, or is it  
supposed to work (and the webpage provides wrong information once again)?

Did anyone experience difficulties using glibc-2.4 with Aldor?

____________________________________________
tmgisi at spencer
cwd: ~/aldor
$ ldd `which aldor`
         linux-gate.so.1 =>  (0xffffe000)
         libm.so.6 => /lib32/libm.so.6 (0xf7f42000)
         libc.so.6 => /lib32/libc.so.6 (0xf7e25000)
         /lib/ld-linux.so.2 (0xf7f89000)

____________________________________________
tmgisi at spencer
cwd: ~/aldor
$ ls -l /lib32/libc.so.6
lrwxrwxrwx 1 root root 11  1. Aug 13:02 /lib32/libc.so.6 -> libc-2.4.so*

--
Kind regards,
Christian



From tmgisi at gmx.at  Sun Aug 13 03:28:20 2006
From: tmgisi at gmx.at (Christian Aistleitner)
Date: Sun, 13 Aug 2006 09:28:20 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <44DE02B1.4030704@hemmecke.de>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<44DE02B1.4030704@hemmecke.de>
Message-ID: <op.td7odiypu6j4vy@spencer.aistleitner.info>

Hello,

> ---file crazy.as--
> #include "aldor"
> CrazyInteger: IntegerType with {string: Literal -> %} == Integer add {
>      Rep == Integer;
>      import from Rep;
>      integer(l: Literal): % == per(integer(l)$Integer + 1);
>      string(l: Literal): % == per 42;
> }
>
> main(): () == {
>      import from TextWriter, Character;
>      import from CrazyInteger;
>      stdout << "This is crazy :" << space << 1 << newline;
>      stdout << "This is crazy :" << space << 2 << newline;
>      stdout << "Fourtytwo" + 4 << newline;
> }
>
> main();
> ---end crazy.as
>
> For me it says.
>  >aldor -grun -laldor crazy.as
> 42 1
> 42 3
> 47

Just what I'd expect... Nothing fancy or crazy from my point of view.

> I cannot believe that Christian meant:
>  >   local litA: Literal := "abcdefghij";    -- (*)
> should be translated to
>  >   char * litA = "abcdefghij";
>
> First of all, the line (*) does not compile at all with libaldor. And I
> even don't know of a way to create a thing of type Literal.
> And also the C code is probably not right.

However, it really *is* what I meant. The line (*) compiles very well.  
However, the compiler does not allow to use Literal directly. Every  
Literal has to be converted using a string, integer, ... function. I  
omittet it for brevity, but consider
   #include "aldor"
   string( l: Literal ): Literal == l;
   local litA: Literal := "abcdefghij";
. It compiles and runs without any problems...
I cannot see any problems in the Aldor code I gave (of course I did not  
specify the string function, but the mail was about conversion of a  
Literal to C code. Therefore, I considered the trivial string function not  
necessary to jot down.).
Just as Gaby, I cannot see any problems with the C code.

Are there any open issues with the code I gave?

> So if the (future) compiler puts literals into read-only memory, then
> the library definition
>
>    string(l:Literal):% == string(l pretend Pointer);
>
> is the bug and must be changed.

Ja. Just as I said before.

--
Kind regards,
Christian



From tmgisi at gmx.at  Sun Aug 13 04:46:14 2006
From: tmgisi at gmx.at (Christian Aistleitner)
Date: Sun, 13 Aug 2006 10:46:14 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <m3slk22ikn.fsf@zeus.integrable-solutions.net>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
Message-ID: <op.td7rzcytu6j4vy@spencer.aistleitner.info>

Hello,

On Sat, 12 Aug 2006 15:24:08 +0200, Gabriel Dos Reis  
<gdr at integrable-solutions.net> wrote:

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

Yes. And indeed I like the way gcc handles the issue. No doubt about that.  
Nevertheless:

True is: gcc changed its behaviour in this part.

> | Faulty user source code:
[...]
> | 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".
We do not have a grammar of the Aldor language used by the current Aldor  
compiler. So it's hard to discuss validity ...
To me it is valid, as the compiler swallows it and produces working code  
with old enough gccs.


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

Never heard a preacher talking about bad style ;)

> Either a construct is well-defined and have a meaning, or it does not.

I assume it is well-defined from the compiler point of view.
a of type String is assigned the value of applying string$String to the  
literal "abc".
No syntax problems.
No *compiler* semantics problem.
It also has a well defined meaning for the compiler.

> 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.
When working with bleeding edge software, you are often in the situation  
that some of your libraries are too new to work with other tools.
However, typically things get sorted out over time as new versions go  
mainstream.
For Aldor the problem is known for *some* time and it is still not solved.
However, if Aldor tells you "your compiler is too new" it is you not  
meeting their requirements.

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

I am not comparing apples and oranges.
The C program defines this behaviour to be undefined.
The string$String functions behaviour is not defined.
This gives an undefined behaviour in both cases.

However, the semantics of the Aldor program is well defined from the  
compiler point of view, as described above. From the library point of view  
it is not.
So it might be, it is not a compiler problem, but a library problem.

And I do not consider it to be wrong to use functions that work but are  
not documented well enough. However, I might consider it bad style to use  
them.

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

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

Good thing.

> The failure is translated String
> properly is the cause of the error.

And the agreement ends here :(
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.
Did you actually ever try to read the C code generated from Aldor?
Aldor does not care about what domain is represented in C code. (Mostly)  
everything is represented by FiWord -- which is unsigned long int. These  
FiWords are used as pointers to the data structures of interest.
(You might mock about lacking type information and improper use of  
"unsigned long int", but that's not important right now -- Besides I would  
join you if you camplain about it.)
Strings are represented by FiWord as well. So defining a variable to be of  
type String, gives you a FiWord -- So no specification of whether char *  
or char ..[] is meant. The Literal "abcdefghij" is passed as (FiWord)  
"abcdefghij" to the string$String function. So the string$String function  
cannot control whether or not the Literal is in read-only memory or not.
However, it is supposed to return a character sequence in read-write  
memory. (Note the "supposed", as the semantics of the stirng$String  
function, mapping a Literal to a String, is not defined). Hence it must  
_not_ simply return the (FiWord) "abcdefghij" but has to assure, it uses  
read-write memory.

>  Not that -fwritable-strings has
> disappears.

Still "removing the -fwritable-strings" triggered the problem.
Nevertheless I strongly agree, that Aldor should never have relied on  
gcc's behaviour, as it is undefined. I defended this position against  
Aldor compiler people some time ago. So we are both on the same side.

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

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

IIRC I read some complaints, back when it has been decided, that  
writable-strings is not the way to go. These things mostly occur in legacy  
code...
But the problem should have been dealt with years ago. No doubt.
But whining about these issues helps no one. The Aldor people agree that  
there is a problem with current gccs. And they are working on making  
things work for current gcc for some months now (at least some months ago,  
a compiler developer told me, he's working on it).

We should help them to track the problem down and fix it.

--
Kind regards,
Christian


From tmgisi at gmx.at  Sun Aug 13 04:47:20 2006
From: tmgisi at gmx.at (Christian Aistleitner)
Date: Sun, 13 Aug 2006 10:47:20 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <44DE087B.6040904@hemmecke.de>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<44DE087B.6040904@hemmecke.de>
Message-ID: <op.td7r06aeu6j4vy@spencer.aistleitner.info>

Hello,

>> | 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*.
>
> I consider it bad style! But probably for another reason. It contains a
> syntax error. Christian should have written
>
> local a:String := "abc";
>
> or
>
> local a:String == "abc";

Sorry for that. Of course I meant it in the spirit of my previous mails,  
so my intention has been:
  local a:String := "abc";
.

--
Kind regards,
Christian



From tmgisi at gmx.at  Sun Aug 13 05:38:11 2006
From: tmgisi at gmx.at (Christian Aistleitner)
Date: Sun, 13 Aug 2006 11:38:11 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <m3veoxg854.fsf@zeus.integrable-solutions.net>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<44DE087B.6040904@hemmecke.de>
	<m3veoxg854.fsf@zeus.integrable-solutions.net>
Message-ID: <op.td7udxt0u6j4vy@spencer.aistleitner.info>

Hello,

> | In the second it would be quite questionable.
>
> You can't define a programming language semantics in terms of
> "questionable".  You have to say whether it is well-formed with
> well-defined behaviour, or it has no defined behaviour.  If the latter,
> we just declare the program is ill-formed.  In a strongly typed
> language, it is an error that should be either caught at compile time
> or at runtime.


Ok, omit terms like "bad style" and "questionable". The following code is  
a nice and cosy C program (for my compiler on my machine ... see below):

#include <stdio.h>
int main( int argc, char * argv[] )
{
   char str0[]="QRST";
   char str1[]="ABCDEFGHIJKLMNO";
   str1[strlen(str1)]='P';
   printf( "%s\n", str1 );
   return 0;
}

. Its not very portable -- but portable is again one of those vague term.  
We do not use it. It's a valid C program (for this gcc an my machine).  
Seeing my intention, I am sure you guessed the output

____________________________________________
tmgisi at spencer
cwd: ~/aldor
$ nano test.c && gcc -o test test.c && ./test
ABCDEFGHIJKLMNOPQRST

on my machine
____________________________________________
tmgisi at spencer
cwd: ~/aldor
$ gcc --version
x86_64-pc-linux-gnu-gcc (GCC) 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0,  
pie-8.7.9)
Copyright (C) 2006 Free Software Foundation, Inc.
Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es
gibt KEINE Garantie; auch nicht f?r VERKAUFBARKEIT oder F?R SPEZIELLE  
ZWECKE.

____________________________________________
tmgisi at spencer
cwd: ~/aldor
$ uname -a
Linux spencer 2.6.16-gentoo-r8 #1 Sun Jul 23 06:47:56 CEST 2006 x86_64 AMD  
Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux

I relied on several specifics of the compiled code, which you can  
(probably) not find in the C specification or is defined to give undefined  
behaviour. Yet it works. So it's more than valid to use on *this* gcc on  
*my* machine. It's not portable. It's not robust. I would not want to use  
such code and consider it "bad style" although it's valid code for *this*  
gcc on *my* machine.
I would not want to use such code, but you do not want to reason in those  
vague terms -- You should be more than happy to use that code with *this*  
gcc on *my* machine.

Maybe this example showed you, that the issue is also related to what you  
choose as reference. I chose "C as accepted by my gcc on my machine".  
Aldor did not choose the current C specification, but maybe the "C as  
accepted by (the then current) gcc".

> | > 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.
> |
> | Hmm, until someone proves me wrong, I would claim that String is not
> | part of the Aldor language. And it is also not a part of the
> | runtime. It is defined in the Aldor library "libaldor". And I don't
> | count libaldor as part of the compiler stuff.
>
> That is a fine distinction.  However, it does not work in practice: I
> can't test any useful program coming with the AUG without having
> libaldor.   AUG says, page 12:
>
>    #include "aldor" is the general include statement that will allow
>    the types and functions from libaldor to be visible. It is
>    necessary to use it (or an equivalent library) in order to write
>    programs.

There are equivalent libraries. I wrote one myself when experimenting with  
the semantics of Aldor's categories. In my base library, the domain  
Category had a completely different signature. I did not have a domain  
String at all.

Compare it to C++ and the STL. You can code C++ without using the STL.  
Admittedly, you'd have a rough start without using STL.
You can compile Java sources with either Sun's library or the GNU  
Classpath.

It is a crucial point to separate the language from the base library. I  
really love the Aldor language, but I do not like the aldor library at all.

> For all practical purposes, libaldor is part of the compiler.

No. What about the Axiom people using the Aldor compiler? What about  
BasicMath?
(I have not worked yot with Axiom using the Aldor compiler. Someone who  
has may please correct me if I am wrong)

> You can
> distinguish the front-end from the supporting runtime system, but you
> cannot usefully, meaningfully, and practically dissociate it from the
> compiler.

I fully agree that the runtime system is closely coupled with the  
compiler. But the Aldor library is _not_ part of the runtime system.

The aldor library is not part of the Run-time System. Aldor's runtime  
system has types like HInt and SInt and expects Category and Type to be  
some domain valued constants (to give an example of the connection between  
the front-end and the run-time system).
But the Aldor library is not in the scope of this. The Aldor libarry is  
separated from the run-time system.

--
Kind regards,
Christian


From tmgisi at gmx.at  Sun Aug 13 05:52:01 2006
From: tmgisi at gmx.at (Christian Aistleitner)
Date: Sun, 13 Aug 2006 11:52:01 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <m37j1da4fi.fsf@zeus.integrable-solutions.net>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<44DE087B.6040904@hemmecke.de>
	<m3veoxg854.fsf@zeus.integrable-solutions.net>
	<44DE4750.9070704@hemmecke.de>
	<m37j1da4fi.fsf@zeus.integrable-solutions.net>
Message-ID: <op.td7u0zpuu6j4vy@spencer.aistleitner.info>

Hello,

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

> Ralf Hemmecke <ralf at hemmecke.de> writes:
>
> | > | local a:String == "abc";
> | > | In the second it would be quite questionable.
> | ... what the value of a is after assignment
> |     a.3 := char "X";
>
> Stephen gave me an explanation and if I did understand correctly, that
> assignment is also OK.

sadly enough, this seems to have been a private discussion and has not  
been posted to aldor-l -- Or did I miss it?

> [...]
>
> | Just being curious... is there a legal C program that defines a
> | constant array, and a pointer (or whatever) to on element of that
> | array and then modifies that entry in-place?
>
> If I understand the question correctly, the answer is "no".

For those being not familiar with C or C++:
These languages also provide a modifier const (just doing what its name  
suggests), which Aldor (currently) lacks.

--
Kind regards,
Christian



From tmgisi at gmx.at  Sun Aug 13 06:06:13 2006
From: tmgisi at gmx.at (Christian Aistleitner)
Date: Sun, 13 Aug 2006 12:06:13 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <20060812225529.GC11239@ptibonum.scl.csd.uwo.ca>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<20060812141942.GA30663@ptibonum.scl.csd.uwo.ca>
	<20060812224638.GA5946@aquarium.aldor.org>
	<20060812225529.GC11239@ptibonum.scl.csd.uwo.ca>
Message-ID: <op.td7vonx2u6j4vy@spencer.aistleitner.info>

Hello Stephen,

On Sun, 13 Aug 2006 00:55:29 +0200, Stephen Watt <watt at scl.csd.uwo.ca>  
wrote:

> Laurentiu, I think there is more to this than meets the eye.

you are probably right. We cannot judge, as we do not have access to the  
sources.
However, according to the AUG, a Literal is a constant. According to the  
discussion, we all agree constants are correctly modelled by
   char * str = "my_fancy_literal".
To my understanding, this is basically, what Aldor does at the moment.  
This is a sound behaviour -- No one wants to change the representation of  
string literals.

The aldor library currently assumes that the literal is in a read-write  
memory location and can be modified in-place. Assuming that a constant  
(i.e.: the literal) is in read-write memory is a bad choice. Assuming to  
modify a constant in-place is even further off.
However, the aldor library should/has to assure that the returned value is  
in read-write memory.
Its no big deal to implement this behaviour in the string$String function  
by adding a "copy" (as I showed).

> The Aldor system developers are not the only ones to write libraries --
> the compiler should have correct behaviour for any legitimate Aldor code
> and not break depending on the underlying C compiler.

If other libraries make the same assumption, it should be the problem of  
these libraries, and not of the Aldor compiler.

The current compiler has correct behaviour for legitimate Aldor code.  
However, the aldor library makes assumptions that do not hold for current  
gccs.

However, we cannot inspect the run-time system. Maybe there the assumption  
can be found as well...

--
Kind regards,
Christian



From ralf at hemmecke.de  Sun Aug 13 07:32:56 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Sun, 13 Aug 2006 13:32:56 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <op.td7u0zpuu6j4vy@spencer.aistleitner.info>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<44DE087B.6040904@hemmecke.de>
	<m3veoxg854.fsf@zeus.integrable-solutions.net>
	<44DE4750.9070704@hemmecke.de>
	<m37j1da4fi.fsf@zeus.integrable-solutions.net>
	<op.td7u0zpuu6j4vy@spencer.aistleitner.info>
Message-ID: <44DF0DE8.80609@hemmecke.de>

>> | Just being curious... is there a legal C program that defines a
>> | constant array, and a pointer (or whatever) to on element of that
>> | array and then modifies that entry in-place?
>>
>> If I understand the question correctly, the answer is "no".
> 
> For those being not familiar with C or C++:
> These languages also provide a modifier const (just doing what its name 
> suggests), which Aldor (currently) lacks.

Ooops. What is then

str: String == anotherString;

supposed to mean?

Ralf


From ralf at hemmecke.de  Sun Aug 13 07:40:03 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Sun, 13 Aug 2006 13:40:03 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <m31wrla3t3.fsf@zeus.integrable-solutions.net>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>	<op.td351cpau6j4vy@spencer.aistleitner.info>	<m3u04j8rym.fsf@zeus.integrable-solutions.net>	<op.td51o72eu6j4vy@spencer.aistleitner.info>	<44DE02B1.4030704@hemmecke.de>	<m3d5b5hof8.fsf@zeus.integrable-solutions.net>	<44DE398F.1070005@hemmecke.de>
	<m31wrla3t3.fsf@zeus.integrable-solutions.net>
Message-ID: <44DF0F93.6050700@hemmecke.de>

> I appreciate all that.  The issue under discussion, is what should be
> the proper translation of 
> 
>     a : String == "vlndoffmnelcfeeqmeejfoie";
> 
> into C.

That completely depends on how you define the type String (in a library) 
and how the function

string: Literal -> String

is implemented in that library. Without a library the compiler has to 
reject that line, since it is not Aldor code (String is not known).

Ralf


From gdr at integrable-solutions.net  Sun Aug 13 09:30:27 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 13 Aug 2006 15:30:27 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <op.td7m5fu7u6j4vy@spencer.aistleitner.info>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<20060812141942.GA30663@ptibonum.scl.csd.uwo.ca>
	<m37j1enhl8.fsf@zeus.integrable-solutions.net>
	<op.td7m5fu7u6j4vy@spencer.aistleitner.info>
Message-ID: <m3wt9c4vbg.fsf@zeus.integrable-solutions.net>

"Christian Aistleitner" <tmgisi at gmx.at> writes:

| Hello,
| 
| On Sat, 12 Aug 2006 16:39:47 +0200, Gabriel Dos Reis
| <gdr at integrable-solutions.net> wrote:
| 
| > I hope there will be a version for GNU/Linux systems working with the
| > most current glibc (e.g. glibc-2.4 and higher).
| 
| I am puzzled ... is there already some glibc-2.5 or glibc-3.0? According to
| http://www.gnu.org/software/libc/
| glibc-2.4 is the current version of glibc.

Yes, glibc-2.4 is the currently released version.  However, I don't
know how long it will take to produce a new Aldor compiler.  My hope
is that when it is released it will work with the most recently
released glibc (maybe 2.4, if it is soon, or higher it takes at least
six months).

| I have glibc-2.4 installed on my gentoo box (and no glibc-2.3 or other
| version of glibc) and it just works very well with aldor.
| I know that on the webpage, you can only download the aldor compiler
| for  glibc-2.3 (and glibc-2.2) for GNU/Linux OSes.
| Is it a coincidence that everything works with glibc-2.4, or is it
| supposed to work (and the webpage provides wrong information once
| again)?

Is there any reason to believe that there need to be two different
versions: one for glibc-2.2, and another for glibc-2.3, but everything
should be OK with higher versions of glibc?

-- Gaby


From gdr at integrable-solutions.net  Sun Aug 13 09:44:22 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 13 Aug 2006 15:44:22 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <op.td7u0zpuu6j4vy@spencer.aistleitner.info>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<44DE087B.6040904@hemmecke.de>
	<m3veoxg854.fsf@zeus.integrable-solutions.net>
	<44DE4750.9070704@hemmecke.de>
	<m37j1da4fi.fsf@zeus.integrable-solutions.net>
	<op.td7u0zpuu6j4vy@spencer.aistleitner.info>
Message-ID: <m3r6zk4uo9.fsf@zeus.integrable-solutions.net>

"Christian Aistleitner" <tmgisi at gmx.at> writes:

| Hello,
| 
| On Sun, 13 Aug 2006 02:02:25 +0200, Gabriel Dos Reis
| <gdr at integrable-solutions.net> wrote:
| 
| > Ralf Hemmecke <ralf at hemmecke.de> writes:
| >
| > | > | local a:String == "abc";
| > | > | In the second it would be quite questionable.
| > | ... what the value of a is after assignment
| > |     a.3 := char "X";
| >
| > Stephen gave me an explanation and if I did understand correctly, that
| > assignment is also OK.
| 
| sadly enough, this seems to have been a private discussion and has not
| been posted to aldor-l -- Or did I miss it?

You're correct that it was a private message.  He just reminded me
that since a is defined as

    a : String == "abc";

therefore with type String, and a String is modifiable, the
modification 

  a.3 := char "X" 

is OK.

| > [...]
| >
| > | Just being curious... is there a legal C program that defines a
| > | constant array, and a pointer (or whatever) to on element of that
| > | array and then modifies that entry in-place?
| >
| > If I understand the question correctly, the answer is "no".
| 
| For those being not familiar with C or C++:
| These languages also provide a modifier const (just doing what its
| name  suggests), which Aldor (currently) lacks.

OK, let me expand a little bit on this.

First of all, K&R lacks "const" -- it was an invention for "C with
Classes" (the precursor of C++) that the ANSI C committee adopted
later, sadly with a slightly different semantics.  However, given

     char *a = "hqdfnoioffe";

you can't modify what a points to -- though you're free to modify the
pointer a.  Notice that no const is involved there.

The reason is that in C, therefore in C++, modifiability really is a 
*property of the object*, not just that of the expression used to
access the object.  However, you are right that C++ does enforce those
properties more often than C by lifting most of them directly into the
static semantics.  For example the string literal

   "hqdfnoioffe"

has type

   const char[12]

in C++. The proper way to write the above declaration in C++ is

     const char *a = "hqdfnoioffe";

However, the declaration

     char *a = "hqdfnoioffe";

is also accepted for C-compatibility reasons, but deprecated.  The
semantics however remains that you can't modify what a points to.

-- Gaby


From gdr at integrable-solutions.net.integrable-solutions.net  Sun Aug 13 10:00:04 2006
From: gdr at integrable-solutions.net.integrable-solutions.net (Gabriel Dos Reis)
Date: 13 Aug 2006 16:00:04 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <op.td7udxt0u6j4vy@spencer.aistleitner.info>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<44DE087B.6040904@hemmecke.de>
	<m3veoxg854.fsf@zeus.integrable-solutions.net>
	<op.td7udxt0u6j4vy@spencer.aistleitner.info>
Message-ID: <m3lkps4ty3.fsf@zeus.integrable-solutions.net>

"Christian Aistleitner" <tmgisi at gmx.at> writes:

[...]

| #include <stdio.h>
| int main( int argc, char * argv[] )
| {
|    char str0[]="QRST";
|    char str1[]="ABCDEFGHIJKLMNO";
|    str1[strlen(str1)]='P';
|    printf( "%s\n", str1 );
|    return 0;
| }
| 
| . Its not very portable -- but portable is again one of those vague
| term.  We do not use it. It's a valid C program (for this gcc an my
| machine).

What makes you believe that is a valid C program?  It invokes
undefined behaviour.  From there you can prove everything you want.

[...]

| Maybe this example showed you, that the issue is also related to what
| you  choose as reference. I chose "C as accepted by my gcc on my
| machine".  Aldor did not choose the current C specification, but maybe
| the "C as  accepted by (the then current) gcc".

But even with K&R, you have rubbish.


| 
| > | > 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.
| > |
| > | Hmm, until someone proves me wrong, I would claim that String is not
| > | part of the Aldor language. And it is also not a part of the
| > | runtime. It is defined in the Aldor library "libaldor". And I don't
| > | count libaldor as part of the compiler stuff.
| >
| > That is a fine distinction.  However, it does not work in practice: I
| > can't test any useful program coming with the AUG without having
| > libaldor.   AUG says, page 12:
| >
| >    #include "aldor" is the general include statement that will allow
| >    the types and functions from libaldor to be visible. It is
| >    necessary to use it (or an equivalent library) in order to write
| >    programs.
| 
| There are equivalent libraries.

I have no doubt that you can find *different implementations* of the
Aldor libary.  However, they will be _equivalent_.  That equivalence
classes (i.e. semamtics) is part of the compiler.

| I wrote one myself when experimenting
| with  the semantics of Aldor's categories. In my base library, the
| domain  Category had a completely different signature. I did not have
| a domain  String at all.
| 
| Compare it to C++ and the STL. You can code C++ without using the STL.

That sounds like "you can code in C++ without while".  That is
true, but that hardly implies that "while" is not part of the C++
language. 

STL is part of the *hosted implementation* specification of ISO C++ --
though a freestanding implementation can offer too, but is not
required too.  Most certainly the "STL" -- what most people call STL today
is not the real STL -- is part of the ISO C++ specification.  It is
part of the language. There is no real distinction, and certainly the
ISO C++ definition does not make any formal distintion.

However, you have many implementations of the C++ standard library.
That does not mean the standard library is not part of the language.

[...]

| The aldor library is not part of the Run-time System. Aldor's runtime
| system has types like HInt and SInt and expects Category and Type to
| be  some domain valued constants (to give an example of the connection
| between  the front-end and the run-time system).
| But the Aldor library is not in the scope of this. The Aldor libarry
| is  separated from the run-time system.

OK.

-- Gaby


From gdr at integrable-solutions.net  Sun Aug 13 10:20:08 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 13 Aug 2006 16:20:08 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <op.td7rzcytu6j4vy@spencer.aistleitner.info>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<op.td7rzcytu6j4vy@spencer.aistleitner.info>
Message-ID: <m3fyg04t0n.fsf@zeus.integrable-solutions.net>

"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



From ralf at hemmecke.de  Sun Aug 13 13:34:06 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Sun, 13 Aug 2006 19:34:06 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <m3lkps4ty3.fsf@zeus.integrable-solutions.net>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>	<op.td351cpau6j4vy@spencer.aistleitner.info>	<m3u04j8rym.fsf@zeus.integrable-solutions.net>	<op.td51o72eu6j4vy@spencer.aistleitner.info>	<m3slk22ikn.fsf@zeus.integrable-solutions.net>	<44DE087B.6040904@hemmecke.de>	<m3veoxg854.fsf@zeus.integrable-solutions.net>	<op.td7udxt0u6j4vy@spencer.aistleitner.info>
	<m3lkps4ty3.fsf@zeus.integrable-solutions.net>
Message-ID: <44DF628E.2060803@hemmecke.de>

> I have no doubt that you can find *different implementations* of the 
> Aldor libary.  However, they will be _equivalent_.  That equivalence 
> classes (i.e. semamtics) is part of the compiler.

Gaby, can you show me a definition of THE Aldor library?

All I can find is an API description of what happens to be an
implementation that leads to libaldor.al + libaldor.a and is distributed
with the compiler.

And if you actually mean that implementation should be called THE Aldor
library, then there is currently no equivalent one existing.

In fact, I believe that the current libaldor should be improved or 
rewritten to become a standard.

Ralf


From tmgisi at gmx.at  Mon Aug 14 02:21:02 2006
From: tmgisi at gmx.at (Christian Aistleitner)
Date: Mon, 14 Aug 2006 08:21:02 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <44DF0DE8.80609@hemmecke.de>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<44DE087B.6040904@hemmecke.de>
	<m3veoxg854.fsf@zeus.integrable-solutions.net>
	<44DE4750.9070704@hemmecke.de>
	<m37j1da4fi.fsf@zeus.integrable-solutions.net>
	<op.td7u0zpuu6j4vy@spencer.aistleitner.info>
	<44DF0DE8.80609@hemmecke.de>
Message-ID: <op.td9fxcmnu6j4vy@spencer.aistleitner.info>

Hello,

On Sun, 13 Aug 2006 13:32:56 +0200, Ralf Hemmecke <ralf at hemmecke.de> wrote:

>>> | Just being curious... is there a legal C program that defines a
>>> | constant array, and a pointer (or whatever) to on element of that
>>> | array and then modifies that entry in-place?
>>>
>>> If I understand the question correctly, the answer is "no".
>>
>> For those being not familiar with C or C++:
>> These languages also provide a modifier const (just doing what its name
>> suggests), which Aldor (currently) lacks.
>
> Ooops. What is then
>
> str: String == anotherString;
>
> supposed to mean?

Sorry, I did not make myself clear enough.

Gaby already elaborated on the "const" modifier. However, I meant it more  
in the direction of passing parameters. For example type "man strcat" at  
your command line and you'll probably get a description of the C function  
strcat. Already from its signature
   char *strcat(char *dest, const char *src);
you can read off, that src is not meant to be changed, while dest probably  
will be modified (indeed the string it points to is modified). That's the  
concept Aldor lacks. We just have the "!"-convention. But that's not a  
hard requirement but simply a convention. The compiler cannot use it to  
perform checks. Furthermore, the "!" does not specify, which parameters  
act constant and which may be modified.

--
Kind regards,
Christian



From tmgisi at gmx.at  Mon Aug 14 02:41:22 2006
From: tmgisi at gmx.at (Christian Aistleitner)
Date: Mon, 14 Aug 2006 08:41:22 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <m3lkps4ty3.fsf@zeus.integrable-solutions.net>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<44DE087B.6040904@hemmecke.de>
	<m3veoxg854.fsf@zeus.integrable-solutions.net>
	<op.td7udxt0u6j4vy@spencer.aistleitner.info>
	<m3lkps4ty3.fsf@zeus.integrable-solutions.net>
Message-ID: <op.td9gu8j0u6j4vy@spencer.aistleitner.info>

Hello,

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

> "Christian Aistleitner" <tmgisi at gmx.at> writes:
>
> [...]
>
> | #include <stdio.h>
> | int main( int argc, char * argv[] )
> | {
> |    char str0[]="QRST";
> |    char str1[]="ABCDEFGHIJKLMNO";
> |    str1[strlen(str1)]='P';
> |    printf( "%s\n", str1 );
> |    return 0;
> | }
> |
> | . Its not very portable -- but portable is again one of those vague
> | term.  We do not use it. It's a valid C program (for this gcc an my
> | machine).
>
> What makes you believe that is a valid C program?

I did not claim "The code conforms to Standard xxx". I claimed it is a  
valid C program for my gcc on my machine.

> It invokes
> undefined behaviour.  From there you can prove everything you want.

No the behaviour is not undefined for this very gcc. It most likely is  
undefined according to most C standards, but for this very gcc I use, the  
behaviour is defined. I *know* where the variables are stored in memory  
and how they are connected. It's repeatable and always the same. It is  
defined for my gcc.

I did not claim it's portable. I do not like such code myself. But it's  
valid code for my gcc on my machine. It runs and works. Not be adhering to  
any C standard, but by design.

In the same spirit, string$String from the aldor libarry is valid -- for  
old enough gccs.

> | Maybe this example showed you, that the issue is also related to what
> | you  choose as reference. I chose "C as accepted by my gcc on my
> | machine".  Aldor did not choose the current C specification, but maybe
> | the "C as  accepted by (the then current) gcc".
>
> But even with K&R, you have rubbish.

I never said to do K&R.

> | > That is a fine distinction.  However, it does not work in practice: I
> | > can't test any useful program coming with the AUG without having
> | > libaldor.   AUG says, page 12:
> | >
> | >    #include "aldor" is the general include statement that will allow
> | >    the types and functions from libaldor to be visible. It is
> | >    necessary to use it (or an equivalent library) in order to write
> | >    programs.
> |
> | There are equivalent libraries.
>
> I have no doubt that you can find *different implementations* of the
> Aldor libary.  However, they will be _equivalent_.  That equivalence
> classes (i.e. semamtics) is part of the compiler.

They are not equivalent. They'll most probably share some things, but they  
are not equivalent.

They'll probably all define Type, Category and these things. But the rest  
is not needed.

> | I wrote one myself when experimenting
> | with  the semantics of Aldor's categories. In my base library, the
> | domain  Category had a completely different signature. I did not have
> | a domain  String at all.
> |
> | Compare it to C++ and the STL. You can code C++ without using the STL.
>
> That sounds like "you can code in C++ without while".  That is
> true, but that hardly implies that "while" is not part of the C++
> language.

I am sorry, but I just have to accept we a quite different view of what  
constitues the Aldor language. I do not know what other arguments I should  
give.

> However, you have many implementations of the C++ standard library.
> That does not mean the standard library is not part of the language.
>
> [...]
>
> | The aldor library is not part of the Run-time System. Aldor's runtime
> | system has types like HInt and SInt and expects Category and Type to
> | be  some domain valued constants (to give an example of the connection
> | between  the front-end and the run-time system).
> | But the Aldor library is not in the scope of this. The Aldor libarry
> | is  separated from the run-time system.
>
> OK.

This "OK" puzzles me.
Do you mean "Let's accept we have different points of view" or "I feel  
convinced"?

--
Kind regards,
Christian



From tmgisi at gmx.at  Mon Aug 14 07:22:58 2006
From: tmgisi at gmx.at (Christian Aistleitner)
Date: Mon, 14 Aug 2006 13:22:58 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <m3fyg04t0n.fsf@zeus.integrable-solutions.net>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<op.td7rzcytu6j4vy@spencer.aistleitner.info>
	<m3fyg04t0n.fsf@zeus.integrable-solutions.net>
Message-ID: <op.td9twklou6j4vy@spencer.aistleitner.info>

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



From daly at axiom-developer.org  Mon Aug 14 01:25:34 2006
From: daly at axiom-developer.org (root)
Date: Mon, 14 Aug 2006 01:25:34 -0400
Subject: [Aldor-l] Compiling setup
In-Reply-To: <op.td7vonx2u6j4vy@spencer.aistleitner.info> (tmgisi@gmx.at)
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<20060812141942.GA30663@ptibonum.scl.csd.uwo.ca>
	<20060812224638.GA5946@aquarium.aldor.org>
	<20060812225529.GC11239@ptibonum.scl.csd.uwo.ca>
	<op.td7vonx2u6j4vy@spencer.aistleitner.info>
Message-ID: <200608140525.k7E5PYG11880@localhost.localdomain>

> However, according to the AUG, a Literal is a constant. According to the  
> discussion, we all agree constants are correctly modelled by
>    char * str = "my_fancy_literal".
> To my understanding, this is basically, what Aldor does at the moment.  
> This is a sound behaviour -- No one wants to change the representation of  
> string literals.

Really? Aldor is based on the ideas in the spad language.
String literals are easily mutable in spad.
It is incorrect to reflect a C restriction upward.

t


From tmgisi at gmx.at  Mon Aug 14 07:50:19 2006
From: tmgisi at gmx.at (Christian Aistleitner)
Date: Mon, 14 Aug 2006 13:50:19 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <200608140525.k7E5PYG11880@localhost.localdomain>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<20060812141942.GA30663@ptibonum.scl.csd.uwo.ca>
	<20060812224638.GA5946@aquarium.aldor.org>
	<20060812225529.GC11239@ptibonum.scl.csd.uwo.ca>
	<op.td7vonx2u6j4vy@spencer.aistleitner.info>
	<200608140525.k7E5PYG11880@localhost.localdomain>
Message-ID: <op.td9u55gju6j4vy@spencer.aistleitner.info>

Hello,

first off, sorry for not answering to the post of aldor-l but to the one  
sent to me directly. I cannot find the post to the mailing list.

On Mon, 14 Aug 2006 07:25:34 +0200, Tim Daly <daly at axiom-developer.org>  
wrote:

>> However, according to the AUG, a Literal is a constant. According to the
>> discussion, we all agree constants are correctly modelled by
>>    char * str = "my_fancy_literal".
>> To my understanding, this is basically, what Aldor does at the moment.
>> This is a sound behaviour -- No one wants to change the representation  
>> of string literals.
>
> Really? Aldor is based on the ideas in the spad language.
> String literals are easily mutable in spad.
> It is incorrect to reflect a C restriction upward.

The "no one" refers to the people discussing the issue ("According to the  
discussion"). You just joined in, so the "no one" apparently does not  
include you.

String literals are constants in Aldor (as written in ?5.2 of the AUG).
I guess main purpose of the _Aldor_ compiler should be to compile _Aldor_  
code and assist _Aldor_ developers.
I consider read-only constants an extremely helpful and a good design  
decision.

If the Aldor compiler can compile spad files for you, it's nice. However,  
I would strongly vote against legacy support, if it forbids a good  
experience for the main audience.

Ad main audience:
I know that there are more Axiom developers than Aldor developers around  
here, so I hope the main audience still are Aldor developers, even though  
there are hardly any ...


--
Kind regards,
Christian


From d.i.preininger at tele2.at  Thu Aug 17 02:35:05 2006
From: d.i.preininger at tele2.at (Preininger)
Date: Thu, 17 Aug 2006 08:35:05 +0200
Subject: [Aldor-l] write!
Message-ID: <auto-000087127305@mailfe10.swip.net>

Hello,

I try the AUG example 21.14 Text input,

with aldor -ginterp textinput.as
the command - open("file",fileWrite) works
the command - write!(c,tw) fails with an error in: putc in sal_file.as

any solution?




From ralf at hemmecke.de  Thu Aug 17 09:45:35 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Thu, 17 Aug 2006 15:45:35 +0200
Subject: [Aldor-l] write!
In-Reply-To: <auto-000087127305@mailfe10.swip.net>
References: <auto-000087127305@mailfe10.swip.net>
Message-ID: <44E472FF.6030007@hemmecke.de>

Hello,

On 08/17/2006 08:35 AM, Preininger wrote:
> Hello,
> 
> I try the AUG example 21.14 Text input,
> 
> with aldor -ginterp textinput.as
> the command - open("file",fileWrite) works
> the command - write!(c,tw) fails with an error in: putc in sal_file.as
> 
> any solution?

That file is supposed to be run as an executable. So try

aldor -laldor -fx textinput.as
textinput

or

aldor -laldor -grun textinput.as

The reason why it fails is, that (my very guess) the switch "-ginterp" 
instructs the compiler to compile to foam and execute that FOAM code. 
However, with FOAM you have NO access to routines directly implemented in C.

Ralf



From martin.rubey at univie.ac.at  Tue Aug 15 15:43:24 2006
From: martin.rubey at univie.ac.at (Martin Rubey)
Date: 15 Aug 2006 21:43:24 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <op.td9u55gju6j4vy@spencer.aistleitner.info>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<20060812141942.GA30663@ptibonum.scl.csd.uwo.ca>
	<20060812224638.GA5946@aquarium.aldor.org>
	<20060812225529.GC11239@ptibonum.scl.csd.uwo.ca>
	<op.td7vonx2u6j4vy@spencer.aistleitner.info>
	<200608140525.k7E5PYG11880@localhost.localdomain>
	<op.td9u55gju6j4vy@spencer.aistleitner.info>
Message-ID: <9qsljx3hur.fsf@aquin.mat.univie.ac.at>

"Christian Aistleitner" <tmgisi at gmx.at> writes:

> I know that there are more Axiom developers than Aldor developers around  
> here, [...]

I first read "more SPAD programmers than Aldor programmers", and wanted to
respond:

  In fact, I doubt that. At least, I consider rather like an Aldor programmer
  condemned to restrict himself to SPAD code...
  
  I don't think that there are many SPAD programmers left. Antoine codes in
  Aldor, so does Ralf, I nearly do. Who else has written something recently?
  
  If I had (at least) a _promise_ that Aldor will become free software (at
  least in some sense) then I'd switch immediately myself, and work hard to
  make Axiom go Aldor altogether.

Martin



From bill.page1 at synthesis.anikast.ca  Fri Aug 18 14:25:51 2006
From: bill.page1 at synthesis.anikast.ca (Bill Page)
Date: Fri, 18 Aug 2006 14:25:51 -0400
Subject: [Aldor-l] Using Aldor or SPAD
In-Reply-To: <9q3bbuue86.fsf_-_@login.mat.univie.ac.at>
Message-ID: <024001c6c2f3$c1397ed0$6900a8c0@asus>

On August 18, 2006 1:49 PM Martin Rubey wrote:
> 
> Gabriel Dos Reis writes:
> 
> > I've been writing more and more SPAD, less and less Aldor. 
> > And I suspect very soon my students will more SPAD than 
> > Aldor, however imperfect SPAD...
> 
> why is that? I really can't understand, there are so many 
> things missing in spad!
> 

Ya, like error message a human can understand, for one! :)
I think SPAD is nearly impossible to learn because the results
of compiling incorrect programs are so difficult to interpret.
I usually write something in Aldor first to get the syntax and
types correct and then (if necessary) back port it to SPAD.

On the other hand (with a few notable exceptions like fully
implemented dependent types), the SPAD *language* is not
fundamentally very different than Aldor. SPAD is a productive
language - after all 1,300 packages domains and categories
are currently implemented in this language.

Then, of course there is the long unresolved issue of the lack
of a clear open source license for Aldor. I fear that if this
not resolved in the next few **weeks**, then the consequences
for both Aldor and Axiom could be very negative. All the rhetoric
of having to get people who already agree to agree aside, I just
do not understand why aldor.org would have neglected this for
so long. :(

Regards,
Bill Page.




From ralf at hemmecke.de  Fri Aug 18 15:37:47 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Fri, 18 Aug 2006 21:37:47 +0200
Subject: [Aldor-l] Using Aldor or SPAD
In-Reply-To: <024001c6c2f3$c1397ed0$6900a8c0@asus>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>
Message-ID: <44E6170B.1020108@hemmecke.de>

On 08/18/2006 08:25 PM, Bill Page wrote:
> On August 18, 2006 1:49 PM Martin Rubey wrote:
>> Gabriel Dos Reis writes:
>>
>>> I've been writing more and more SPAD, less and less Aldor. 
>>> And I suspect very soon my students will more SPAD than 
>>> Aldor, however imperfect SPAD...
>> why is that? I really can't understand, there are so many 
>> things missing in spad!

On which list did that appear. I don't remember that I have seen these 
mails... :-(

> Ya, like error message a human can understand, for one! :)
> I think SPAD is nearly impossible to learn because the results
> of compiling incorrect programs are so difficult to interpret.
> I usually write something in Aldor first to get the syntax and
> types correct and then (if necessary) back port it to SPAD.

That sounds reasonable and it probably results in better readable SPAD 
code. But anyway, SPAD should die out, either by using an sufficiently 
open source Aldor compiler or by modifying the current SPAD compiler to 
accept the Aldor language (and giving proper error messages).

> On the other hand (with a few notable exceptions like fully
> implemented dependent types), the SPAD *language* is not
> fundamentally very different than Aldor. SPAD is a productive
> language - after all 1,300 packages domains and categories
> are currently implemented in this language.

If you really look at the code then you see that most of it must be 
considered as black boxes. Even if you can read the spad sources (since 
they are open), it remains our task to make pamphlets out of them. And I 
would rather like to do this by replacing a non-strictly defined 
language like SPAD by a more strictly defined language Aldor.

> Then, of course there is the long unresolved issue of the lack
> of a clear open source license for Aldor. I fear that if this
> not resolved in the next few **weeks**, then the consequences
> for both Aldor and Axiom could be very negative.

What can you do? The only option we have if the Aldor compiler is not 
going to open soon, is to write another compiler. But I guess that is 
going to take quite a while. First we have to find people who are 
willing an able to start such a project.

Gaby, have you any idea how long it could take to produce another 
reasonably efficient Aldor compiler?

Ralf


From gdr at integrable-solutions.net  Fri Aug 18 16:02:53 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 18 Aug 2006 22:02:53 +0200
Subject: [Aldor-l] Using Aldor or SPAD
In-Reply-To: <44E6170B.1020108@hemmecke.de>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>
	<44E6170B.1020108@hemmecke.de>
Message-ID: <m3y7tlak2a.fsf@zeus.integrable-solutions.net>

Ralf Hemmecke <ralf at hemmecke.de> writes:

[...]

| That sounds reasonable and it probably results in better readable SPAD 
| code. But anyway, SPAD should die out, either by using an sufficiently 
| open source Aldor compiler or by modifying the current SPAD compiler to 
| accept the Aldor language (and giving proper error messages).

I can't promote the disappearance of SPAD if I don't havw a working
replacement. 

[...]

|                                                   But I guess that is 
| going to take quite a while. First we have to find people who are 
| willing an able to start such a project.

It may take a while but it would be an interesting project, beneficial
to the Aldor language and community.  Most of the non-proprietary
languages I know have greatly benefited from the availability of
several implementations.

| Gaby, have you any idea how long it could take to produce another 
| reasonably efficient Aldor compiler?

It all depends on what you want to have in the "reasonably efficient"
compiler. It should be a mater of days or weeks to have a good
front-end. It would take momths to have decent optimizations in.
but, that is definitely in our reach.

-- Gaby


From ralf at hemmecke.de  Fri Aug 18 18:13:07 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Sat, 19 Aug 2006 00:13:07 +0200
Subject: [Aldor-l] Using Aldor or SPAD
In-Reply-To: <m3y7tlak2a.fsf@zeus.integrable-solutions.net>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>	<44E6170B.1020108@hemmecke.de>
	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>
Message-ID: <44E63B73.1050403@hemmecke.de>

> | Gaby, have you any idea how long it could take to produce another 
> | reasonably efficient Aldor compiler?

> It all depends on what you want to have in the "reasonably efficient"
> compiler.

Yes, that is clear.

> It should be a mater of days or weeks to have a good front-end.

Oh, really? Why then wait any longer? Maybe, because there is no 100% 
clear definition of the language Aldor?

> It would take momths to have decent optimizations in.
> but, that is definitely in our reach.

Does somebody volunteer to start such a project, preferably under GPL?
I don't want the Aldor **language** to split, because of different 
compiler implementation, but staying in an uncertain future is just bad 
for the Aldor language to reach the masses.

Ralf


From gdr at integrable-solutions.net  Fri Aug 18 18:23:08 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 19 Aug 2006 00:23:08 +0200
Subject: [Aldor-l] Using Aldor or SPAD
In-Reply-To: <44E63B73.1050403@hemmecke.de>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>
	<44E6170B.1020108@hemmecke.de>
	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>
	<44E63B73.1050403@hemmecke.de>
Message-ID: <m3ac617kfn.fsf@zeus.integrable-solutions.net>

Ralf Hemmecke <ralf at hemmecke.de> writes:

[...]

| > It should be a mater of days or weeks to have a good front-end.
| 
| Oh, really? 

when you get a handful of motivated people, yes.

| Why then wait any longer? Maybe, because there is no 100%
| clear definition of the language Aldor?

That is an important factor I guess. I.e. what do we want?  What kind
of problems do we want to see solved by the language?

| > It would take momths to have decent optimizations in.
| > but, that is definitely in our reach.
| 
| Does somebody volunteer to start such a project, preferably under GPL?

well, I'm already burried with Axiom and other projects; but I do
definitely have an interest here.

| I don't want the Aldor **language** to split, because of different
| compiler implementation, but staying in an uncertain future is just
| bad for the Aldor language to reach the masses.

it would not be good for anybody to have the community split; however,
more than one implementations are beneficial for both the language and
the community.

-- Gaby


From ralf at hemmecke.de  Fri Aug 18 19:11:09 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Sat, 19 Aug 2006 01:11:09 +0200
Subject: [Aldor-l] Using Aldor or SPAD
In-Reply-To: <m3ac617kfn.fsf@zeus.integrable-solutions.net>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>	<44E6170B.1020108@hemmecke.de>	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>	<44E63B73.1050403@hemmecke.de>
	<m3ac617kfn.fsf@zeus.integrable-solutions.net>
Message-ID: <44E6490D.60207@hemmecke.de>

On 08/19/2006 12:23 AM, Gabriel Dos Reis wrote:
> Ralf Hemmecke <ralf at hemmecke.de> writes:
> 
> [...]
> 
> | > It should be a mater of days or weeks to have a good front-end.
> | 
> | Oh, really? 
> 
> when you get a handful of motivated people, yes.

Maybe we should open up a Wiki and call for people on the FrontPage 
similar to the FreeAldor link.

> | Why then wait any longer? Maybe, because there is no 100%
> | clear definition of the language Aldor?
> 
> That is an important factor I guess. I.e. what do we want?  What kind
> of problems do we want to see solved by the language?

I believe that some research is involved here. I would definitely like 
to see better support in the language to state the input-output 
conditions in formal terms that could be used by a theorem prover.
If that just appears in the comments it is lost for checking program 
correctness.

> | > It would take momths to have decent optimizations in.
> | > but, that is definitely in our reach.
> | 
> | Does somebody volunteer to start such a project, preferably under GPL?
> 
> well, I'm already burried with Axiom and other projects; but I do
> definitely have an interest here.

Axiom is really big, may I ask on which part of Axiom do you want to 
concentrate?

In my eyes Aldor is/should become one of the most important pieces in 
Axiom. The mathematical knowledge that is hidden in all the SPAD 
domains, must be rewritten in Aldor and in a pamphlet style.

> | I don't want the Aldor **language** to split, because of different
> | compiler implementation, but staying in an uncertain future is just
> | bad for the Aldor language to reach the masses.

> it would not be good for anybody to have the community split; however,
> more than one implementations are beneficial for both the language and
> the community.

The availability of manpower is a big question mark for a second 
implementation of Aldor.

Ralf


From daly at axiom-developer.org  Fri Aug 18 19:10:21 2006
From: daly at axiom-developer.org (root)
Date: Fri, 18 Aug 2006 19:10:21 -0400
Subject: [Aldor-l] [Axiom-developer] Re:  Using Aldor or SPAD
In-Reply-To: <44E6490D.60207@hemmecke.de> (message from Ralf Hemmecke on Sat, 
	19 Aug 2006 01:11:09 +0200)
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>	<44E6170B.1020108@hemmecke.de>	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>	<44E63B73.1050403@hemmecke.de>
	<m3ac617kfn.fsf@zeus.integrable-solutions.net>
	<44E6490D.60207@hemmecke.de>
Message-ID: <200608182310.k7INALa15933@localhost.localdomain>

>From historical experience a new Aldor compiler would be a
3 year, 5 person project.

t


From gdr at integrable-solutions.net  Fri Aug 18 19:28:42 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 19 Aug 2006 01:28:42 +0200
Subject: [Aldor-l] [Axiom-developer] Re:  Using Aldor or SPAD
In-Reply-To: <200608182310.k7INALa15933@localhost.localdomain>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>
	<44E6170B.1020108@hemmecke.de>
	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>
	<44E63B73.1050403@hemmecke.de>
	<m3ac617kfn.fsf@zeus.integrable-solutions.net>
	<44E6490D.60207@hemmecke.de>
	<200608182310.k7INALa15933@localhost.localdomain>
Message-ID: <m3y7tl4o9h.fsf@zeus.integrable-solutions.net>

root <daly at axiom-developer.org> writes:

| >From historical experience a new Aldor compiler would be a
| 3 year, 5 person project.

but, such a new compiler would have to reinvent everything from
scratch.  A lot have been done in recent years in terms for dependent
types (Nurpl, epigram, etc.), functional languages implementations
techniques and optimizations (OCaml, Haskell, etc.).  Furthermore
it may attract more students.  

Of course, that is not said to underestimate the task; just to remind
that not everything has to be reinvented.

-- Gaby


From gdr at integrable-solutions.net  Fri Aug 18 19:35:11 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 19 Aug 2006 01:35:11 +0200
Subject: [Aldor-l] [Axiom-developer] Re:  Using Aldor or SPAD
In-Reply-To: <m3y7tl4o9h.fsf@zeus.integrable-solutions.net>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>
	<44E6170B.1020108@hemmecke.de>
	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>
	<44E63B73.1050403@hemmecke.de>
	<m3ac617kfn.fsf@zeus.integrable-solutions.net>
	<44E6490D.60207@hemmecke.de>
	<200608182310.k7INALa15933@localhost.localdomain>
	<m3y7tl4o9h.fsf@zeus.integrable-solutions.net>
Message-ID: <m34pw9k47k.fsf@zeus.integrable-solutions.net>

Gabriel Dos Reis <gdr at integrable-solutions.net> writes:

| root <daly at axiom-developer.org> writes:
| 
| | >From historical experience a new Aldor compiler would be a
| | 3 year, 5 person project.
| 
| but, such a new compiler would have to reinvent everything from
                                ^

ouch, there is a missing "NOT" here. Sorry for that.

-- Gaby


From ralf at hemmecke.de  Fri Aug 18 20:22:29 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Sat, 19 Aug 2006 02:22:29 +0200
Subject: [Aldor-l] Const Bug?
Message-ID: <44E659C5.20000@hemmecke.de>

Who can tell me whether the compiler behaves correctly when it rejects 
that program below...

Removing the definitions of fooConst and barConst, compiles without a 
problem.

Ralf

 >aldor -laldor aaaConst.as
"aaaConst.as", line 16:                 nth(): Integer == 0;
                         ................^
[L16 C17] #2 (Note 1)  (cf. L21 C17)

"aaaConst.as", line 21:                 nth(): Integer == 1;
                         ................^
[L21 C17] #1 (Error) Constant `nth' cannot be redefined.
(see Note 1)



---BEGIN aaaConst.as
#include "aldor"
#include "aldorio"

AAA: with == add {
	foo(): Integer == {
		nth(): Integer == 0;
		stdout << "something" << newline;
		nth();
	}
	bar(): Integer == {
		nth(): Integer == 1;
		stdout << "else" << newline;
		nth();
	}
	fooConst: Integer == {
		nth(): Integer == 0;
		stdout << "something" << newline;
		nth();
	}
	barConst: Integer == {
		nth(): Integer == 1;
		stdout << "else" << newline;
		nth();
	}
}
---END aaaConst.as



From daly at axiom-developer.org  Sat Aug 19 00:29:35 2006
From: daly at axiom-developer.org (root)
Date: Sat, 19 Aug 2006 00:29:35 -0400
Subject: [Aldor-l] [Axiom-developer] Re:  Using Aldor or SPAD
In-Reply-To: <m34pw9k47k.fsf@zeus.integrable-solutions.net> (message from
	Gabriel Dos Reis on 19 Aug 2006 01:35:11 +0200)
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>
	<44E6170B.1020108@hemmecke.de>
	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>
	<44E63B73.1050403@hemmecke.de>
	<m3ac617kfn.fsf@zeus.integrable-solutions.net>
	<44E6490D.60207@hemmecke.de>
	<200608182310.k7INALa15933@localhost.localdomain>
	<m3y7tl4o9h.fsf@zeus.integrable-solutions.net>
	<m34pw9k47k.fsf@zeus.integrable-solutions.net>
Message-ID: <200608190429.k7J4TZQ16041@localhost.localdomain>

| root <daly at axiom-developer.org> writes:
| 
| | >From historical experience a new Aldor compiler would be a
| | 3 year, 5 person project.
| 
| but, such a new compiler would NOT have to reinvent everything from

of course, if it were written in lisp and assumed the axiom system
underneath it then it is a much less complex problem.

t



From tmgisi at gmx.at  Sat Aug 19 02:02:59 2006
From: tmgisi at gmx.at (Christian Aistleitner)
Date: Sat, 19 Aug 2006 08:02:59 +0200
Subject: [Aldor-l] No Const Bug (was: Re:  Const Bug?)
In-Reply-To: <44E659C5.20000@hemmecke.de>
References: <44E659C5.20000@hemmecke.de>
Message-ID: <op.teioe9a0u6j4vy@spencer.aistleitner.info>

Hello,

On Sat, 19 Aug 2006 02:22:29 +0200, Ralf Hemmecke <ralf at hemmecke.de> wrote:

> Who can tell me whether the compiler behaves correctly when it rejects
> that program below...

I guess, this is actually correct behaviour ;)
Bear in mind, that { } does not necessarily create a new scope.
It does create new scopes for foo and bar, but not for fooConst and  
barConst.
That is correct according to ?8.1 AUG.
Hence the nth of fooConst is not local to fooConst, but local to the add  
expression. Same holds for the nth in barConst.
So both constants nth are in the same scope. The nth of barConst is trying  
to redefine the nth definide in fooConst.

> ---BEGIN aaaConst.as
> #include "aldor"
> #include "aldorio"
>
> AAA: with == add {
> 	foo(): Integer == {
> 		nth(): Integer == 0;
> 		stdout << "something" << newline;
> 		nth();
> 	}
> 	bar(): Integer == {
> 		nth(): Integer == 1;
> 		stdout << "else" << newline;
> 		nth();
> 	}
> 	fooConst: Integer == {
> 		nth(): Integer == 0;
> 		stdout << "something" << newline;
> 		nth();
> 	}
> 	barConst: Integer == {
> 		nth(): Integer == 1;
> 		stdout << "else" << newline;
> 		nth();
> 	}
> }
> ---END aaaConst.as

--
Kind regards,
Christian


From tmgisi at gmx.at  Sat Aug 19 02:58:06 2006
From: tmgisi at gmx.at (Christian Aistleitner)
Date: Sat, 19 Aug 2006 08:58:06 +0200
Subject: [Aldor-l] Using Aldor or SPAD
In-Reply-To: <44E6490D.60207@hemmecke.de>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>
	<44E6170B.1020108@hemmecke.de>
	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>
	<44E63B73.1050403@hemmecke.de>
	<m3ac617kfn.fsf@zeus.integrable-solutions.net>
	<44E6490D.60207@hemmecke.de>
Message-ID: <op.teiqy4szu6j4vy@spencer.aistleitner.info>

Hello,

On Sat, 19 Aug 2006 01:11:09 +0200, Ralf Hemmecke <ralf at hemmecke.de> wrote:

> On 08/19/2006 12:23 AM, Gabriel Dos Reis wrote:
>> Ralf Hemmecke <ralf at hemmecke.de> writes:
>>
>> [...]
>>
>> | > It should be a mater of days or weeks to have a good front-end.
>> |
>> | Oh, really?
>>
>> when you get a handful of motivated people, yes.
>
> Maybe we should open up a Wiki and call for people on the FrontPage
> similar to the FreeAldor link.

Bear in mind, that you are trying to rewrite an existing product.
IANAL and I do not know French/British/Canadian law.
But I have been reading several traits of US law (which I have been told  
to be not too different from Canadian law).
According to my understanding of US law, someone who has seen Aldor source  
code cannot work on rewriting Aldor (without explicit permission by those  
who hold the rights of the Aldor source code).
I am not sure, to what extend the US law situation is reflected by  
Canadian, French or British law.
However, as (I guess) most of the ppl interested in Aldor, have seen the  
compiler's source code, they (probably) should not work on the  
reimplementation of it.

This is not some funny side remark of myself, but a real issue. Just think  
about the pain ReactOS is going through.

--
Kind regards,
Christian


From martin.rubey at univie.ac.at  Sat Aug 19 06:32:07 2006
From: martin.rubey at univie.ac.at (Martin Rubey)
Date: 19 Aug 2006 12:32:07 +0200
Subject: [Aldor-l] Using Aldor or SPAD
In-Reply-To: <m3y7tlak2a.fsf@zeus.integrable-solutions.net>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>
	<44E6170B.1020108@hemmecke.de>
	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>
Message-ID: <9qoduh10ew.fsf@aquin.mat.univie.ac.at>

Dear Gabriel, Ralf, Christian, Bill, ...

Gabriel Dos Reis <gdr at integrable-solutions.net> writes:

> | Gaby, have you any idea how long it could take to produce another
> | reasonably efficient Aldor compiler?
> 
> It all depends on what you want to have in the "reasonably efficient"
> compiler. It should be a mater of days or weeks to have a good front-end. It
> would take momths to have decent optimizations in.  but, that is definitely
> in our reach.

What implementation language would you propose? Is the legal situation affected
by the choice of the implementation language? Gaby, did your students see the
source code of the aldor compiler?

I think we should not wait any longer. I'm currently interested in two
projects:

* species, together with Ralf and Nicolas

* symmetric functions

Both of these projects depend *heavily* on types being first class objects, and
on allowing dependent types. Both of these features are missing in SPAD.

In fact, there are two things missing in Axiom:

1) a replacement for SPAD that allows one to use the Aldor language

2) a replacement for the interpreter, that allows one to use the Aldor language

I wouldn't be surprised if 2) would be easier to achieve, but I don't
know. Gaby, how much money do you need for 1), for 2) and for both?

Martin



From gdr at integrable-solutions.net  Sat Aug 19 09:43:32 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 19 Aug 2006 15:43:32 +0200
Subject: [Aldor-l] Using Aldor or SPAD
In-Reply-To: <9qoduh10ew.fsf@aquin.mat.univie.ac.at>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>
	<44E6170B.1020108@hemmecke.de>
	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>
	<9qoduh10ew.fsf@aquin.mat.univie.ac.at>
Message-ID: <m3hd08et8b.fsf@zeus.integrable-solutions.net>

Martin Rubey <martin.rubey at univie.ac.at> writes:

| Dear Gabriel, Ralf, Christian, Bill, ...
| 
| Gabriel Dos Reis <gdr at integrable-solutions.net> writes:
| 
| > | Gaby, have you any idea how long it could take to produce another
| > | reasonably efficient Aldor compiler?
| > 
| > It all depends on what you want to have in the "reasonably efficient"
| > compiler. It should be a mater of days or weeks to have a good front-end. It
| > would take momths to have decent optimizations in.  but, that is definitely
| > in our reach.
| 
| What implementation language would you propose? Is the legal

this usually turns to be a language war so I would like first to have
us agree on what we want to have, then seek the means.

| situation affected by the choice of the implementation language?
| Gaby, did your students see the source code of the aldor compiler?

No, and I never saw it.  The only thing I know of the Aldor compiler
is that long time ago my "intern-mate" Yannis was working on it at
Sophia Antipolis...

| I think we should not wait any longer. I'm currently interested in two
| projects:
| 
| * species, together with Ralf and Nicolas
| 
| * symmetric functions
| 
| Both of these projects depend *heavily* on types being first class
| objects, and on allowing dependent types. Both of these features are
| missing in SPAD. 

Indeed.  You have mentioned dependent types many times.  I would like
to know more about what you mean.  For example, if we go full
dependent types, I suspect it would be very difficult to evaluate
all categories at compile-time.  So, I'm interested in the kind of
dependency you want.
[ For example, C++ has dependent types at its "template systems" but
  values are limited to integers and addresses of toplevel entities ]

| In fact, there are two things missing in Axiom:
| 
| 1) a replacement for SPAD that allows one to use the Aldor language

Can anyone familiar with integrating SPAD with foreign languages
educate me about the thorny issues?

| 2) a replacement for the interpreter, that allows one to use the Aldor language
| 
| I wouldn't be surprised if 2) would be easier to achieve, but I don't
| know. Gaby, how much money do you need for 1), for 2) and for both?

At the moment, I would have assess students' needs before.  Let's talk about
this aspect latter.

Thanks for your support!

-- Gaby


From gdr at integrable-solutions.net  Sat Aug 19 09:46:34 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 19 Aug 2006 15:46:34 +0200
Subject: [Aldor-l] No Const Bug (was: Re:  Const Bug?)
In-Reply-To: <op.teioe9a0u6j4vy@spencer.aistleitner.info>
References: <44E659C5.20000@hemmecke.de>
	<op.teioe9a0u6j4vy@spencer.aistleitner.info>
Message-ID: <m3bqqget39.fsf@zeus.integrable-solutions.net>

"Christian Aistleitner" <tmgisi at gmx.at> writes:

| Hello,
| 
| On Sat, 19 Aug 2006 02:22:29 +0200, Ralf Hemmecke <ralf at hemmecke.de> wrote:
| 
| > Who can tell me whether the compiler behaves correctly when it rejects
| > that program below...
| 
| I guess, this is actually correct behaviour ;)
| Bear in mind, that { } does not necessarily create a new scope.
| It does create new scopes for foo and bar, but not for fooConst and  
| barConst.

What is the rationale for that design point?

-- Gaby


From gdr at integrable-solutions.net  Sat Aug 19 09:54:06 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 19 Aug 2006 15:54:06 +0200
Subject: [Aldor-l] [Axiom-developer] Re:  Using Aldor or SPAD
In-Reply-To: <200608190429.k7J4TZQ16041@localhost.localdomain>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>
	<44E6170B.1020108@hemmecke.de>
	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>
	<44E63B73.1050403@hemmecke.de>
	<m3ac617kfn.fsf@zeus.integrable-solutions.net>
	<44E6490D.60207@hemmecke.de>
	<200608182310.k7INALa15933@localhost.localdomain>
	<m3y7tl4o9h.fsf@zeus.integrable-solutions.net>
	<m34pw9k47k.fsf@zeus.integrable-solutions.net>
	<200608190429.k7J4TZQ16041@localhost.localdomain>
Message-ID: <m3psewde69.fsf@zeus.integrable-solutions.net>

root <daly at axiom-developer.org> writes:

| | root <daly at axiom-developer.org> writes:
| | 
| | | >From historical experience a new Aldor compiler would be a
| | | 3 year, 5 person project.
| | 
| | but, such a new compiler would NOT have to reinvent everything from
| 
| of course, if it were written in lisp and assumed the axiom system
| underneath it then it is a much less complex problem.

It would be difficult for me to find good and motivated students
sufficiently fluent in Lisp :-)  But, I get your point.  If, we have a
new compiler, it would be engineered so that it solves problems
encountered by Axiom uses and improve the way people think of or write
Axiom libraries.

-- Gaby


From gdr at integrable-solutions.net  Sat Aug 19 09:58:13 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 19 Aug 2006 15:58:13 +0200
Subject: [Aldor-l] Using Aldor or SPAD
In-Reply-To: <op.teiqy4szu6j4vy@spencer.aistleitner.info>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>
	<44E6170B.1020108@hemmecke.de>
	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>
	<44E63B73.1050403@hemmecke.de>
	<m3ac617kfn.fsf@zeus.integrable-solutions.net>
	<44E6490D.60207@hemmecke.de>
	<op.teiqy4szu6j4vy@spencer.aistleitner.info>
Message-ID: <m3k654ddze.fsf@zeus.integrable-solutions.net>

"Christian Aistleitner" <tmgisi at gmx.at> writes:

| Hello,
| 
| On Sat, 19 Aug 2006 01:11:09 +0200, Ralf Hemmecke <ralf at hemmecke.de> wrote:
| 
| > On 08/19/2006 12:23 AM, Gabriel Dos Reis wrote:
| >> Ralf Hemmecke <ralf at hemmecke.de> writes:
| >>
| >> [...]
| >>
| >> | > It should be a mater of days or weeks to have a good front-end.
| >> |
| >> | Oh, really?
| >>
| >> when you get a handful of motivated people, yes.
| >
| > Maybe we should open up a Wiki and call for people on the FrontPage
| > similar to the FreeAldor link.
| 
| Bear in mind, that you are trying to rewrite an existing product.
| IANAL and I do not know French/British/Canadian law.
| But I have been reading several traits of US law (which I have been
| told  to be not too different from Canadian law).
| According to my understanding of US law, someone who has seen Aldor
| source  code cannot work on rewriting Aldor (without explicit
| permission by those  who hold the rights of the Aldor source code).

I never touched/saw Aldor compiler source code.  

I'm not trying to rewrite the existing compiler.  I'm only interested
in a new compiler for the *Aldor language*.  If the *Aldor language*
is defined to be the behaviour of its *current compiler*, then we are
all in trouble. 

| I am not sure, to what extend the US law situation is reflected by
| Canadian, French or British law.
| However, as (I guess) most of the ppl interested in Aldor, have seen
| the  compiler's source code, they (probably) should not work on the
| reimplementation of it.

That is a very good point.  Does that also imply that you cannot
answer any technical question about the *Aldor language*?

| This is not some funny side remark of myself, but a real issue. Just
| think  about the pain ReactOS is going through.

:-)

-- Gaby


From ralf at hemmecke.de  Sat Aug 19 10:41:03 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Sat, 19 Aug 2006 16:41:03 +0200
Subject: [Aldor-l] No Const Bug
In-Reply-To: <m3bqqget39.fsf@zeus.integrable-solutions.net>
References: <44E659C5.20000@hemmecke.de>	<op.teioe9a0u6j4vy@spencer.aistleitner.info>
	<m3bqqget39.fsf@zeus.integrable-solutions.net>
Message-ID: <44E722FF.5000902@hemmecke.de>

On 08/19/2006 03:46 PM, Gabriel Dos Reis wrote:
> "Christian Aistleitner" <tmgisi at gmx.at> writes:
> 
> | Hello,
> | 
> | On Sat, 19 Aug 2006 02:22:29 +0200, Ralf Hemmecke <ralf at hemmecke.de> wrote:
> | 
> | > Who can tell me whether the compiler behaves correctly when it rejects
> | > that program below...
> | 
> | I guess, this is actually correct behaviour ;)
> | Bear in mind, that { } does not necessarily create a new scope.
> | It does create new scopes for foo and bar, but not for fooConst and  
> | barConst.
> 
> What is the rationale for that design point?

I am looking forward to an answer to this question.

> -- Gaby


From ralf at hemmecke.de  Sat Aug 19 13:04:06 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Sat, 19 Aug 2006 19:04:06 +0200
Subject: [Aldor-l] Using Aldor or SPAD
In-Reply-To: <m3hd08et8b.fsf@zeus.integrable-solutions.net>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>	<44E6170B.1020108@hemmecke.de>	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>	<9qoduh10ew.fsf@aquin.mat.univie.ac.at>
	<m3hd08et8b.fsf@zeus.integrable-solutions.net>
Message-ID: <44E74486.1090706@hemmecke.de>

> The only thing I know of the Aldor compiler
> is that long time ago my "intern-mate" Yannis was working on it at
> Sophia Antipolis...

Ah, Yannis Chicha worked with you... This world is so small...

> | I think we should not wait any longer. I'm currently interested in two
> | projects:
> | 
> | * species, together with Ralf and Nicolas
> | 
> | * symmetric functions
> | 
> | Both of these projects depend *heavily* on types being first class
> | objects, and on allowing dependent types. Both of these features are
> | missing in SPAD. 
> 
> Indeed.  You have mentioned dependent types many times.  I would like
> to know more about what you mean.  For example, if we go full
> dependent types, I suspect it would be very difficult to evaluate
> all categories at compile-time.  So, I'm interested in the kind of
> dependency you want.

Currently, in aldor-combinat I am going to define something like...

define CombinatorialSpecies(L: LabelType): Category == with {
         <<exports: CombinatorialSpecies>>
}
CharacteristicSpecies(n:Integer)(L:LabelType): CombinatorialSpecies L == 
add {
         Rep == Set L;
         import from Rep;
         <<implementation: CharacteristicSpecies>>
}
EmptySetSpecies(L: LabelType): CombinatorialSpecies L == {
         CharacteristicSpecies(0$Integer)(L) add;
}

As you see, EmptySetSpecies is a function and its result type depends on 
its input type L.

But I think what you mention about categories is not really connected to 
dependent or not dependent types. I actually don't know how one can 
construct a category at runtime and later use it.

For example,

define Cat: Category == if odd? random() then {with {foo: () -> ()}}
                                          else {with {bar: () -> ()}}

I could define a domain

Dom: Cat == add {
    foo(): () == {}
    bar(): () == {}
}

But how would I use it? At compile time the compiler cannot decide whether

foo()$Dom;

is actually available.

> [ For example, C++ has dependent types at its "template systems" but
>   values are limited to integers and addresses of toplevel entities ]

Could you provide some example code? A link?

> | In fact, there are two things missing in Axiom:
> | 
> | 1) a replacement for SPAD that allows one to use the Aldor language

> Can anyone familiar with integrating SPAD with foreign languages
> educate me about the thorny issues?

What exactly do you mean here?

Ralf


From gdr at integrable-solutions.net  Sat Aug 19 14:08:17 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 19 Aug 2006 20:08:17 +0200
Subject: [Aldor-l] Using Aldor or SPAD
In-Reply-To: <44E74486.1090706@hemmecke.de>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>
	<44E6170B.1020108@hemmecke.de>
	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>
	<9qoduh10ew.fsf@aquin.mat.univie.ac.at>
	<m3hd08et8b.fsf@zeus.integrable-solutions.net>
	<44E74486.1090706@hemmecke.de>
Message-ID: <m3lkpklhta.fsf@zeus.integrable-solutions.net>

Ralf Hemmecke <ralf at hemmecke.de> writes:

| > The only thing I know of the Aldor compiler
| > is that long time ago my "intern-mate" Yannis was working on it at
| > Sophia Antipolis...
| 
| Ah, Yannis Chicha worked with you... This world is so small...

Yup; Yannis hosted me for weeks before I got a place; it must have been
sometime in 1996. Stephen was the project leader at the time.

[...]

| Currently, in aldor-combinat I am going to define something like...
| 
| define CombinatorialSpecies(L: LabelType): Category == with {
|          <<exports: CombinatorialSpecies>>
| }
| CharacteristicSpecies(n:Integer)(L:LabelType): CombinatorialSpecies L == 
| add {
|          Rep == Set L;
|          import from Rep;
|          <<implementation: CharacteristicSpecies>>
| }
| EmptySetSpecies(L: LabelType): CombinatorialSpecies L == {
|          CharacteristicSpecies(0$Integer)(L) add;
| }
| 
| As you see, EmptySetSpecies is a function and its result type depends on 
| its input type L.


Yes. My question is whether "L" can be any value computed at runtime,
or only values known at compile-time.  E.g., do you want to say

   * read in a Label l
   * call CharacteristicSpecies with l

?

If yes, evaluation at compile-time will be very limited.

Or, would you be happy with Label values that are "known" to the
compiler, from "simple" program text analysis?

| But I think what you mention about categories is not really connected to 
| dependent or not dependent types. I actually don't know how one can 
| construct a category at runtime and later use it.
| 
| For example,
| 
| define Cat: Category == if odd? random() then {with {foo: () -> ()}}
|                                           else {with {bar: () -> ()}}
| 
| I could define a domain
| 
| Dom: Cat == add {
|     foo(): () == {}
|     bar(): () == {}
| }
| 
| But how would I use it? At compile time the compiler cannot decide whether
| 
| foo()$Dom;
| 
| is actually available.

Yes, that pushes checking to runtime and inhibit some static
optimizations.  So, I guess, we sort of agree on where to draw the
boundary. 

| > [ For example, C++ has dependent types at its "template systems" but
| >   values are limited to integers and addresses of toplevel entities ]
| 
| Could you provide some example code? A link?

A simple example involving non-type parameter is the classical

   template<tyename T, int N>
     struct buffer {
       T data[N];
     };

here the template buffer is parameterized by a type name and an
integer.  Internally it holds an array of N Ts.  It can be used as

     buffer<int, 512> cache;

or

     buffer<char, 4 * 512> buf;

Notice that the integer argument is anything that can be evaluated at
compile-time such as 512 or 4 * 512.  

| > | In fact, there are two things missing in Axiom:
| > | 
| > | 1) a replacement for SPAD that allows one to use the Aldor language
| 
| > Can anyone familiar with integrating SPAD with foreign languages
| > educate me about the thorny issues?
| 
| What exactly do you mean here?

Well, suppose I'm going to provide a language (that can be an existing
language such as C or Lisp or Aldor) that people use to write
libraries intended to be used with or from Axiom; are are the whoops I
or people would have to jump through?

-- Gaby


From tmgisi at gmx.at  Sun Aug 20 03:23:48 2006
From: tmgisi at gmx.at (Christian Aistleitner)
Date: Sun, 20 Aug 2006 09:23:48 +0200
Subject: [Aldor-l] Using Aldor or SPAD
In-Reply-To: <m3k654ddze.fsf@zeus.integrable-solutions.net>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>
	<44E6170B.1020108@hemmecke.de>
	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>
	<44E63B73.1050403@hemmecke.de>
	<m3ac617kfn.fsf@zeus.integrable-solutions.net>
	<44E6490D.60207@hemmecke.de>
	<op.teiqy4szu6j4vy@spencer.aistleitner.info>
	<m3k654ddze.fsf@zeus.integrable-solutions.net>
Message-ID: <op.tekmty1cu6j4vy@spencer.aistleitner.info>

Hello,

> | I am not sure, to what extend the US law situation is reflected by
> | Canadian, French or British law.
> | However, as (I guess) most of the ppl interested in Aldor, have seen
> | the  compiler's source code, they (probably) should not work on the
> | reimplementation of it.
>
> That is a very good point.  Does that also imply that you cannot
> answer any technical question about the *Aldor language*?

I assume the "you" does not refer to me, but someone having seen the  
compiler sources.
The term "technical question" is rather vague to me in this context.
Up to my knowledge, people having seen the compiler sources may do only  
one thing (in the US): Write specifications.

--
Kind regards,
Christian


From ralf at hemmecke.de  Sun Aug 20 04:01:49 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Sun, 20 Aug 2006 10:01:49 +0200
Subject: [Aldor-l] Using Aldor or SPAD
In-Reply-To: <m3lkpklhta.fsf@zeus.integrable-solutions.net>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>	<44E6170B.1020108@hemmecke.de>	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>	<9qoduh10ew.fsf@aquin.mat.univie.ac.at>	<m3hd08et8b.fsf@zeus.integrable-solutions.net>	<44E74486.1090706@hemmecke.de>
	<m3lkpklhta.fsf@zeus.integrable-solutions.net>
Message-ID: <44E816ED.4040204@hemmecke.de>

> | Currently, in aldor-combinat I am going to define something like...
> | 
> | define CombinatorialSpecies(L: LabelType): Category == with {
> |          <<exports: CombinatorialSpecies>>
> | }
> | CharacteristicSpecies(n:Integer)(L:LabelType): CombinatorialSpecies L == 
> | add {
> |          Rep == Set L;
> |          import from Rep;
> |          <<implementation: CharacteristicSpecies>>
> | }
> | EmptySetSpecies(L: LabelType): CombinatorialSpecies L == {
> |          CharacteristicSpecies(0$Integer)(L) add;
> | }
> | 
> | As you see, EmptySetSpecies is a function and its result type depends on 
> | its input type L.

> Yes. My question is whether "L" can be any value computed at runtime,
> or only values known at compile-time.  E.g., do you want to say
> 
>    * read in a Label l
>    * call CharacteristicSpecies with l
> 
> ?

Species can be substituted. I have not yet put this into the code, but 
in <<exports: CombinatorialSpecies>> you will find LabelType.

So I should be able to read m, n from the command line and say

extend String: LabelType == add;

(currently LabelType == PrimitiveType)

MySpec(L: LabelType): CombinatorialSpecies L == {
     CharacteristicSpecies(n)(CharacteristicSpecies m)(L) add;
}

In the middle of that you have the category

CombinatorialSpecies(CharacteristicSpecies m)

Is that enough to make things complicated?
BTW, I would not want to miss that power of Aldor.
MySpec is just a special case of a "Compose" constructor of species.

> If yes, evaluation at compile-time will be very limited.

Yes, I assume that is a big research topic to make such code efficient. 
I leave that to the compiler people. ;-)

> Or, would you be happy with Label values that are "known" to the
> compiler, from "simple" program text analysis?

The final goal for species is to work with them interactively. So I 
don't care if the interpreter in the middle of the session starts the 
compiler to produce some efficient code for me, but it should be 
possible to produce a "sufficiently efficient" standalone program.

And, in particular for species there seems to be need to call the compiler.

This here is another code piece.

BinaryTree(L: LabelType): CombinatorialSpecies L == {
         macro {
                 + == Plus;
                 * == Times;
                 1 == EmptySetSpecies;
                 X == SingletonSpecies;
                 B == BinaryTree;
         }
         (1 + X * B * B)(L) add;
}

For the full current status of that project see
svn://svn.risc.uni-linz.ac.at/hemmecke/combinat/trunk
and listen at aldor-combinat-devel at lists.sourceforge.net .

In general one would have a set of such recursive "equations". Writing 
my own interpreter for that must invoke the compiler. So I would like 
some language feature to start compilation, otherwise I take the input 
string write it out to a file, invoke the external compiler and then 
link the resulting library (I have no idea how the last thing is done).
But going the external way, my standalone program must know where the 
aldor compiler is on that system. :-(

> | > [ For example, C++ has dependent types at its "template systems" but
> | >   values are limited to integers and addresses of toplevel entities ]
> | 
> | Could you provide some example code? A link?
> 
> A simple example involving non-type parameter is the classical
> 
>    template<tyename T, int N>
>      struct buffer {
>        T data[N];
>      };
> 
> here the template buffer is parameterized by a type name and an
> integer.  Internally it holds an array of N Ts.  It can be used as
> 
>      buffer<int, 512> cache;
> 
> or
> 
>      buffer<char, 4 * 512> buf;
> 
> Notice that the integer argument is anything that can be evaluated at
> compile-time such as 512 or 4 * 512.  

I suspect that it is already hard to simplify 0+0 in Aldor. Suppose you 
write

Dom(X: with {0:%, +: (%, %)->%}): with {...} == add {
     Rep == X;
     local doubleZero: % == per(0 + 0);
     ...
}

The only thing a compiler can do is to produce a generic domain.
No lets suppose I give you the .ao library, but not the .as file.
Then you write a program that somewhere in the middle uses Dom(Integer) 
(where hopefully nobody had redefined 0 or + from Integer). Then I would 
like the executable having the equivalent of

    local doubleZero: Integer == 0;

as binary code. That is though, I guess. But as far as I know the 
current Aldor compiler is already doing such things.

Ralf


From martin.rubey at univie.ac.at  Sun Aug 20 05:14:06 2006
From: martin.rubey at univie.ac.at (Martin Rubey)
Date: 20 Aug 2006 11:14:06 +0200
Subject: [Aldor-l] Using Aldor or SPAD
In-Reply-To: <44E74486.1090706@hemmecke.de>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>
	<44E6170B.1020108@hemmecke.de>
	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>
	<9qoduh10ew.fsf@aquin.mat.univie.ac.at>
	<m3hd08et8b.fsf@zeus.integrable-solutions.net>
	<44E74486.1090706@hemmecke.de>
Message-ID: <9qr6zbzs4h.fsf@login.mat.univie.ac.at>

Ralf Hemmecke <ralf at hemmecke.de> writes:

> For example,
> 
> define Cat: Category == if odd? random() then {with {foo: () -> ()}}
>                                           else {with {bar: () -> ()}}
> 
> I could define a domain
> 
> Dom: Cat == add {
>     foo(): () == {}
>     bar(): () == {}
> }
> 
> But how would I use it? At compile time the compiler cannot decide whether
> 
> foo()$Dom;
> 
> is actually available.

Well, isn't it (currently) possible to ask:

  if Dom has foo then ...

> The final goal for species is to work with them interactively. So I don't
> care if the interpreter in the middle of the session starts the compiler to
> produce some efficient code for me, but it should be possible to produce a
> "sufficiently efficient" standalone program.

Please note that I did write an Aldor program that takes a list of strings (the
specification of a grammar) and that produces the corresponding domain. Thus, I
think that

> And, in particular for species there seems to be need to call the compiler.

is incorrect. To look at it, get 

svn://svn.risc.uni-linz.ac.at/hemmecke/combinat/branches/experiments/rubey

Again:

> In general one would have a set of such recursive "equations". Writing my own
> interpreter for that must invoke the compiler. 

I think that this is not correct. The code is in uc.as.nw

Martin



From ralf at hemmecke.de  Sun Aug 20 07:13:31 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Sun, 20 Aug 2006 13:13:31 +0200
Subject: [Aldor-l] Using Aldor or SPAD
In-Reply-To: <9qr6zbzs4h.fsf@login.mat.univie.ac.at>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>	<44E6170B.1020108@hemmecke.de>	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>	<9qoduh10ew.fsf@aquin.mat.univie.ac.at>	<m3hd08et8b.fsf@zeus.integrable-solutions.net>	<44E74486.1090706@hemmecke.de>
	<9qr6zbzs4h.fsf@login.mat.univie.ac.at>
Message-ID: <44E843DB.8010100@hemmecke.de>

On 08/20/2006 11:14 AM, Martin Rubey wrote:
> Ralf Hemmecke <ralf at hemmecke.de> writes:
> 
>> For example,
>>
>> define Cat: Category == if odd? random() then {with {foo: () -> ()}}
>>                                           else {with {bar: () -> ()}}
>>
>> I could define a domain
>>
>> Dom: Cat == add {
>>     foo(): () == {}
>>     bar(): () == {}
>> }
>>
>> But how would I use it? At compile time the compiler cannot decide whether
>>
>> foo()$Dom;
>>
>> is actually available.
> 
> Well, isn't it (currently) possible to ask:
> 
>   if Dom has foo then ...

Good point. But you perhaps agree that things become cumbersome.

Should the compiler accept the lines

DomFoo: Cat == add {
     foo(): () == {}
}

? Certainly not. I suspect that even with the additional bar function 
the current compiler rejects that.

I haven't yet seen a use case for generation and use of categories at 
runtime. Any theoretical suggestions?

>> The final goal for species is to work with them interactively. So I don't
>> care if the interpreter in the middle of the session starts the compiler to
>> produce some efficient code for me, but it should be possible to produce a
>> "sufficiently efficient" standalone program.
> 
> Please note that I did write an Aldor program that takes a list of strings (the
> specification of a grammar) and that produces the corresponding domain. Thus, I
> think that
> 
>> And, in particular for species there seems to be need to call the compiler.

> is incorrect. To look at it, get 
> 
> svn://svn.risc.uni-linz.ac.at/hemmecke/combinat/branches/experiments/rubey

Martin, your approach seems to work, but I am still not sure whether it 
just works because of the current compiler. I would be happier if I had 
a sound explanation in terms of the *Aldor language* not in terms of the 
*compiler*.

Best regards
Ralf


From martin.rubey at univie.ac.at  Sun Aug 20 08:43:49 2006
From: martin.rubey at univie.ac.at (Martin Rubey)
Date: 20 Aug 2006 14:43:49 +0200
Subject: [Aldor-l] implementing aldor / new species approach
In-Reply-To: <44E843DB.8010100@hemmecke.de>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>
	<44E6170B.1020108@hemmecke.de>
	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>
	<9qoduh10ew.fsf@aquin.mat.univie.ac.at>
	<m3hd08et8b.fsf@zeus.integrable-solutions.net>
	<44E74486.1090706@hemmecke.de> <9qr6zbzs4h.fsf@login.mat.univie.ac.at>
	<44E843DB.8010100@hemmecke.de>
Message-ID: <9qbqqfmvay.fsf_-_@login.mat.univie.ac.at>

Dear all,

Ralf Hemmecke <ralf at hemmecke.de> writes:


> I haven't yet seen a use case for generation and use of categories at
> runtime. Any theoretical suggestions?

Yes. Imposing restrictions is a bad thing. Note that our use of types being
first class objects, in particular my parser, is probably not easy to
foresee. However, it turned out to be very useful. Maybe defining categories on
the fly turns out to be very hip some time.

It would be OK for me though to implement only a part of the Aldor language. In
fact, SPAD implements a subset of the Aldor language, at least roughly. It has
proven to be quite useful, you can even implement a computer algebra system
with it. Only, meanwhile we hit the restrictions on dependent types and types
being first class objects (I.e., List Ring is not allowed), so it is time to
extend it. I wouldn't though it away, unless it turns out that this is
easier. I'd be very happy with the old SPAD compiler, if it would understand
dependent types, at least in the most common cases. And I want to be able to
say l: List Ring := [Integer, Polynomial Integer, PF 5].

Furthermore, I'd like to be able to define domains on the command lines. (It is
not necessary to have Categories on the command line, though. In fact, it seems
that this is too much to ask for, looking at aldor -gloop segfaulting very
often.)

> I wrote:
> > Thus, I think that

> >> And, in particular for species there seems to be need to call the compiler.
> 
> > is incorrect. To look at it, get
> > svn://svn.risc.uni-linz.ac.at/hemmecke/combinat/branches/experiments/rubey
 
> Martin, your approach seems to work, but I am still not sure whether it just
> works because of the current compiler. I would be happier if I had a sound
> explanation in terms of the *Aldor language* not in terms of the *compiler*.

I agree. However, if somebody is going to implement Aldor a second time, I'd
argue that this code working is so useful, that it should be abstracted and
included in the specification.

In fact, I have the feeling that it is not a coincidence that it works. After
all, it works with all compiler settings. Don't worry, I'm not saying that it
should work given the specification of the AUG. I'm only saying that it *might*
be that way. I really hope that we can explain the behaviour. Christian
Aistleitner, did you try?


Ralf: I quite like your new species file. There is so little code in it that
is's got to be the right approach :-) Unfortunately I forgot how to see the
results of the test cases, and my Aldor compiler is on the other end of the
modem only... Did you try to leave away the label parameter? (although that's
one thing I really like! By the way, I guess one can make this parameter
optional, don't you think?)


Martin



From gdr at integrable-solutions.net  Sun Aug 20 09:00:06 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 20 Aug 2006 15:00:06 +0200
Subject: [Aldor-l] Using Aldor or SPAD
In-Reply-To: <op.tekmty1cu6j4vy@spencer.aistleitner.info>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>
	<44E6170B.1020108@hemmecke.de>
	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>
	<44E63B73.1050403@hemmecke.de>
	<m3ac617kfn.fsf@zeus.integrable-solutions.net>
	<44E6490D.60207@hemmecke.de>
	<op.teiqy4szu6j4vy@spencer.aistleitner.info>
	<m3k654ddze.fsf@zeus.integrable-solutions.net>
	<op.tekmty1cu6j4vy@spencer.aistleitner.info>
Message-ID: <m3psev1s15.fsf@zeus.integrable-solutions.net>

"Christian Aistleitner" <tmgisi at gmx.at> writes:

| Hello,
| 
| > | I am not sure, to what extend the US law situation is reflected by
| > | Canadian, French or British law.
| > | However, as (I guess) most of the ppl interested in Aldor, have seen
| > | the  compiler's source code, they (probably) should not work on the
| > | reimplementation of it.
| >
| > That is a very good point.  Does that also imply that you cannot
| > answer any technical question about the *Aldor language*?
| 
| I assume the "you" does not refer to me, but someone having seen the
| compiler sources.

well, I meant you (Christian).

| The term "technical question" is rather vague to me in this context.
| Up to my knowledge, people having seen the compiler sources may do
| only  one thing (in the US): Write specifications.

:-)
-- Gaby


From ralf at hemmecke.de  Sun Aug 20 10:41:36 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Sun, 20 Aug 2006 16:41:36 +0200
Subject: [Aldor-l] implementing aldor / new species approach
In-Reply-To: <9qbqqfmvay.fsf_-_@login.mat.univie.ac.at>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>	<44E6170B.1020108@hemmecke.de>	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>	<9qoduh10ew.fsf@aquin.mat.univie.ac.at>	<m3hd08et8b.fsf@zeus.integrable-solutions.net>	<44E74486.1090706@hemmecke.de>
	<9qr6zbzs4h.fsf@login.mat.univie.ac.at>	<44E843DB.8010100@hemmecke.de>
	<9qbqqfmvay.fsf_-_@login.mat.univie.ac.at>
Message-ID: <44E874A0.3040407@hemmecke.de>

>> Martin, your approach seems to work, but I am still not sure whether it just
>> works because of the current compiler. I would be happier if I had a sound
>> explanation in terms of the *Aldor language* not in terms of the *compiler*.
> 
> I agree. However, if somebody is going to implement Aldor a second time, I'd
> argue that this code working is so useful, that it should be abstracted and
> included in the specification.

Maybe it is already in the specification, but I would like to see 
somebody from aldor.org confirming that it should work.

The code we are speaking about is basically this.

grammar(p: List String): List CombinatorialClass == {
         macro CC == CombinatorialClass;
         import from MachineInteger, List CC;
         A: CC == Atom;
         res: List CC := [A for x in p];
         E(i: MachineInteger): CC == evaluate(parse(p.i), res) add {
#if WantSegfault
#else
                 valuation(): Integer == 1
#endif
         }
         for i in 1..#p repeat res.i := E(i);
         res;
}

p contains a list of strings describing the right hand sides of a set of 
equations. Inside these strings "Self_i" corresponds to the left hand 
side. The left hand sides are assumed to be Self_1,...Self_n.
As you see, first the result list res is initialised by Atom (which is 
just a dummy value). In the for loop at the end the list is 
destructively modified in order to produce the recusively define domains.

Let's abbreviate Self_1 by X and Self_2 by Y. grammar should return a 
list of domains. So what happens if I have the equations

X = Atom * Y
Y = Atom * X

The for loop bothers me. In the first iteration we basically call

evaluate(parse("Atom * Y"), [Atom, Atom])

in the second round we would have

evaluate(parse("Atom * X"), [X,    Atom])

So no matter what evaluate and parse actually do, I simply fear that in 
the end res.1 is not the same domain as res.2 although the above 
equations very much suggest equality.

> Ralf: I quite like your new species file. There is so little code in it that
> is's got to be the right approach :-)

Thanks. It took me long enough to follow the Aldor approach, ie, remove 
restrictions instead of adding functionality. ;-)

> Unfortunately I forgot how to see the
> results of the test cases, and my Aldor compiler is on the other end of the
> modem only... 


 >TestSuited
Looking in BinaryTree(String) for generatingSeries with code 164979209
+--- beginning of test case : TestCombinatorialSpecies
|
|  +--- beginning of test : testBinaryTree
|  | calling setUp function
|  | setUp function finished
|  | ----------------------
|  | calling test function
|  |
|  | failing, because an exception occurred in the test function !
|  | Type:
|  | RuntimeError()
|  | Presentation:
|  | Export not found
|  |
|  | ----------------------
|  | calling tearDown function
|  | tearDown function finished
|  +--- end of test : testBinaryTree( test failed )
|
+--- end of test case       : TestCombinatorialSpecies ( 2 total / 1 
correct / 1 failed tests )


summary of the test suite:
============================

test cases      : 4
tests           : 13
tests succeeded : 12
tests failed    : 1

I don't see how I can go around that "missing function". It should be 
there that is for sure. But maybe blaming the compiler is a bit too early.

> Did you try to leave away the label parameter?

No, I didn't.

 > (although that's one thing I really like! By the way, I guess one can
 > make this parameter optional, don't you think?)

No. By design, you cannot make this optional. Oh, well, perhaps it could 
work, but then you'd have to say EmptySetSpecies() (with parens) since
EmptySetSpecies (without parens is of another type. I am not yet sure 
whether this works, but what do you want it to mean anyway??? What would 
be the default?

Ralf


From daly at axiom-developer.org  Sun Aug 20 11:35:08 2006
From: daly at axiom-developer.org (root)
Date: Sun, 20 Aug 2006 11:35:08 -0400
Subject: [Aldor-l] implementing aldor / new species approach
In-Reply-To: <9qbqqfmvay.fsf_-_@login.mat.univie.ac.at> (message from Martin
	Rubey on 20 Aug 2006 14:43:49 +0200)
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>
	<44E6170B.1020108@hemmecke.de>
	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>
	<9qoduh10ew.fsf@aquin.mat.univie.ac.at>
	<m3hd08et8b.fsf@zeus.integrable-solutions.net>
	<44E74486.1090706@hemmecke.de> <9qr6zbzs4h.fsf@login.mat.univie.ac.at>
	<44E843DB.8010100@hemmecke.de>
	<9qbqqfmvay.fsf_-_@login.mat.univie.ac.at>
Message-ID: <200608201535.k7KFZ8924649@localhost.localdomain>

> It would be OK for me though to implement only a part of the Aldor
> language. In fact, SPAD implements a subset of the Aldor language,
> at least roughly. It has proven to be quite useful, you can even
> implement a computer algebra system with it. Only, meanwhile we hit
> the restrictions on dependent types and types being first class
> objects (I.e., List Ring is not allowed), so it is time to extend
> it. I wouldn't though it away, unless it turns out that this is
> easier. I'd be very happy with the old SPAD compiler, if it would
> understand dependent types, at least in the most common cases. And I
> want to be able to say l: List Ring := [Integer, Polynomial Integer,
> PF 5].

Ring is implemented as a lisp object. You can put these into a list.

There is no inherent restriction on creating lists of domains
except for the spad compiler, which can be changed.

t


From gdr at integrable-solutions.net  Sun Aug 20 14:26:10 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 20 Aug 2006 20:26:10 +0200
Subject: [Aldor-l] Using Aldor or SPAD
In-Reply-To: <023f01c6c2f2$c93b51e0$6900a8c0@asus>
References: <023f01c6c2f2$c93b51e0$6900a8c0@asus>
Message-ID: <m3oduf462l.fsf@zeus.integrable-solutions.net>

"Bill Page" <bill.page1 at synthesis.anikast.ca> writes:

| On August 18, 2006 1:49 PM Martin Rubey wrote:
| > 
| > Gabriel Dos Reis writes:
| > 
| > > I've been writing more and more SPAD, less and less Aldor. 
| > > And I suspect very soon my students will more SPAD than 
| > > Aldor, however imperfect SPAD...
| > 
| > why is that? I really can't understand, there are so many 
| > things missing in spad!
| > 
| 
| Ya, like error message a human can understand, for one! :)

Yup :-(

[ error message from C++ compilers with respect to templates look quite
  highly intelligible when compared to what the SPAD compiler spits
  out :-(]

-- Gaby


From martin.rubey at univie.ac.at  Sun Aug 20 15:54:32 2006
From: martin.rubey at univie.ac.at (Martin Rubey)
Date: 20 Aug 2006 21:54:32 +0200
Subject: [Aldor-l] implementing aldor / new species approach
In-Reply-To: <200608201535.k7KFZ8924649@localhost.localdomain>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>
	<44E6170B.1020108@hemmecke.de>
	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>
	<9qoduh10ew.fsf@aquin.mat.univie.ac.at>
	<m3hd08et8b.fsf@zeus.integrable-solutions.net>
	<44E74486.1090706@hemmecke.de> <9qr6zbzs4h.fsf@login.mat.univie.ac.at>
	<44E843DB.8010100@hemmecke.de>
	<9qbqqfmvay.fsf_-_@login.mat.univie.ac.at>
	<200608201535.k7KFZ8924649@localhost.localdomain>
Message-ID: <9qhd0718uf.fsf@login.mat.univie.ac.at>

root <daly at axiom-developer.org> writes:

> Ring is implemented as a lisp object. You can put these into a list.

(2) -> l : List Ring := [Integer]
 
   Cannot convert an element of the construct to type Any .
(2) -> l : Ring := Integer
 
   Ring is a category, not a domain, and declarations require domains.

Martin

PS: PLEASE (!!!!) copy to aldor-combinat only stuff specific to the combinat project!



From tmgisi at gmx.at  Wed Aug 23 09:45:25 2006
From: tmgisi at gmx.at (Christian Aistleitner)
Date: Wed, 23 Aug 2006 15:45:25 +0200
Subject: [Aldor-l] Using Aldor or SPAD
In-Reply-To: <m3psev1s15.fsf@zeus.integrable-solutions.net>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>
	<44E6170B.1020108@hemmecke.de>
	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>
	<44E63B73.1050403@hemmecke.de>
	<m3ac617kfn.fsf@zeus.integrable-solutions.net>
	<44E6490D.60207@hemmecke.de>
	<op.teiqy4szu6j4vy@spencer.aistleitner.info>
	<m3k654ddze.fsf@zeus.integrable-solutions.net>
	<op.tekmty1cu6j4vy@spencer.aistleitner.info>
	<m3psev1s15.fsf@zeus.integrable-solutions.net>
Message-ID: <op.teqohzvhu6j4vy@spencer.aistleitner.info>

Hello,

> | > | I am not sure, to what extend the US law situation is reflected by
> | > | Canadian, French or British law.
> | > | However, as (I guess) most of the ppl interested in Aldor, have  
> seen
> | > | the  compiler's source code, they (probably) should not work on the
> | > | reimplementation of it.
> | >
> | > That is a very good point.  Does that also imply that you cannot
> | > answer any technical question about the *Aldor language*?
> |
> | I assume the "you" does not refer to me, but someone having seen the
> | compiler sources.
>
> well, I meant you (Christian).

ok. If its about me, I'll shift to a private discussion.

--
Kind regards,
Christian


From tmgisi at gmx.at  Wed Aug 23 10:48:04 2006
From: tmgisi at gmx.at (Christian Aistleitner)
Date: Wed, 23 Aug 2006 16:48:04 +0200
Subject: [Aldor-l] implementing aldor / new species approach
In-Reply-To: <9qbqqfmvay.fsf_-_@login.mat.univie.ac.at>
References: <024001c6c2f3$c1397ed0$6900a8c0@asus>
	<44E6170B.1020108@hemmecke.de>
	<m3y7tlak2a.fsf@zeus.integrable-solutions.net>
	<9qoduh10ew.fsf@aquin.mat.univie.ac.at>
	<m3hd08et8b.fsf@zeus.integrable-solutions.net>
	<44E74486.1090706@hemmecke.de>
	<9qr6zbzs4h.fsf@login.mat.univie.ac.at>
	<44E843DB.8010100@hemmecke.de>
	<9qbqqfmvay.fsf_-_@login.mat.univie.ac.at>
Message-ID: <op.teqreec6u6j4vy@spencer.aistleitner.info>

Hello,

>> Martin, your approach seems to work, but I am still not sure whether it  
>> just
>> works because of the current compiler. I would be happier if I had a  
>> sound
>> explanation in terms of the *Aldor language* not in terms of the  
>> *compiler*.
>
> I agree. However, if somebody is going to implement Aldor a second time,  
> I'd
> argue that this code working is so useful, that it should be abstracted  
> and
> included in the specification.

No. I would not add it to the specification. I always argued that such  
code is a potential problem. What it all comes down to is building a  
domain and _afterwards_ exchanging its parameters with different values.
Its plainly a trick thats working -- currently.
The reason why it is working, we can only guess.

> In fact, I have the feeling that it is not a coincidence that it works.  
> After
> all, it works with all compiler settings. Don't worry, I'm not saying  
> that it
> should work given the specification of the AUG. I'm only saying that it  
> *might*
> be that way. I really hope that we can explain the behaviour. Christian
> Aistleitner, did you try?

I tried. Several times. Maybe lazy instantiation (as hinted in the AUG).  
Maybe something completely different. Maybe even a compiler bug.

But please replace my name by "Stephen Watt", "Laurentiu Dragan", or any  
the name of any other Aldor people.

--
Kind regards,
Christian


From gdr at integrable-solutions.net  Fri Aug 18 12:57:32 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 18 Aug 2006 18:57:32 +0200
Subject: [Aldor-l] Compiling setup
In-Reply-To: <9qsljx3hur.fsf@aquin.mat.univie.ac.at>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<20060812141942.GA30663@ptibonum.scl.csd.uwo.ca>
	<20060812224638.GA5946@aquarium.aldor.org>
	<20060812225529.GC11239@ptibonum.scl.csd.uwo.ca>
	<op.td7vonx2u6j4vy@spencer.aistleitner.info>
	<200608140525.k7E5PYG11880@localhost.localdomain>
	<op.td9u55gju6j4vy@spencer.aistleitner.info>
	<9qsljx3hur.fsf@aquin.mat.univie.ac.at>
Message-ID: <m3d5ay6kxv.fsf@zeus.integrable-solutions.net>

Martin Rubey <martin.rubey at univie.ac.at> writes:


[...]

|   I don't think that there are many SPAD programmers left. Antoine codes in
|   Aldor, so does Ralf, I nearly do. Who else has written something recently?

I've been writing more and more SPAD, less and less Aldor. 
And I suspect very soon my students will more SPAD than Aldor, however
imperfect SPAD...

-- Gaby


From martin.rubey at univie.ac.at  Fri Aug 18 13:48:41 2006
From: martin.rubey at univie.ac.at (Martin Rubey)
Date: 18 Aug 2006 19:48:41 +0200
Subject: [Aldor-l] Using Aldor or SPAD
In-Reply-To: <m3d5ay6kxv.fsf@zeus.integrable-solutions.net>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<20060812141942.GA30663@ptibonum.scl.csd.uwo.ca>
	<20060812224638.GA5946@aquarium.aldor.org>
	<20060812225529.GC11239@ptibonum.scl.csd.uwo.ca>
	<op.td7vonx2u6j4vy@spencer.aistleitner.info>
	<200608140525.k7E5PYG11880@localhost.localdomain>
	<op.td9u55gju6j4vy@spencer.aistleitner.info>
	<9qsljx3hur.fsf@aquin.mat.univie.ac.at>
	<m3d5ay6kxv.fsf@zeus.integrable-solutions.net>
Message-ID: <9q3bbuue86.fsf_-_@login.mat.univie.ac.at>

Gabriel Dos Reis <gdr at integrable-solutions.net> writes:

> I've been writing more and more SPAD, less and less Aldor. 
> And I suspect very soon my students will more SPAD than Aldor, however
> imperfect SPAD...

why is that? I really can't understand, there are so many things missing in
spad!

Martin



From gdr at integrable-solutions.net  Fri Aug 18 15:57:09 2006
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 18 Aug 2006 21:57:09 +0200
Subject: [Aldor-l] Using Aldor or SPAD
In-Reply-To: <9q3bbuue86.fsf_-_@login.mat.univie.ac.at>
References: <CAE9B164E720CE4D8727792DF8F28AE3767431@corporateex02.Corporate.drdc-rddc.gc.ca>
	<m3ejvo2ge0.fsf@zeus.integrable-solutions.net>
	<op.td351cpau6j4vy@spencer.aistleitner.info>
	<m3u04j8rym.fsf@zeus.integrable-solutions.net>
	<op.td51o72eu6j4vy@spencer.aistleitner.info>
	<m3slk22ikn.fsf@zeus.integrable-solutions.net>
	<20060812141942.GA30663@ptibonum.scl.csd.uwo.ca>
	<20060812224638.GA5946@aquarium.aldor.org>
	<20060812225529.GC11239@ptibonum.scl.csd.uwo.ca>
	<op.td7vonx2u6j4vy@spencer.aistleitner.info>
	<200608140525.k7E5PYG11880@localhost.localdomain>
	<op.td9u55gju6j4vy@spencer.aistleitner.info>
	<9qsljx3hur.fsf@aquin.mat.univie.ac.at>
	<m3d5ay6kxv.fsf@zeus.integrable-solutions.net>
	<9q3bbuue86.fsf_-_@login.mat.univie.ac.at>
Message-ID: <m34pw9bywa.fsf@zeus.integrable-solutions.net>

Martin Rubey <martin.rubey at univie.ac.at> writes:

| Gabriel Dos Reis <gdr at integrable-solutions.net> writes:
| 
| > I've been writing more and more SPAD, less and less Aldor. 
| > And I suspect very soon my students will more SPAD than Aldor, however
| > imperfect SPAD...
| 
| why is that?

Lack of a working compiler that runs on my systems and students'.

I've read suggestions that people should downgrade to older GCC.
This is something I will NOT recommend.
If recent version of GCC cannot work with Aldor, why should I expect
my systems to work properly with older versions of GCC when they
are packaged with recent version of GCC?

| I really can't understand, there are so many things missing in
| spad!

No doubt many things are missing.  But, at least I can build a working
compiler and work with it on my current systems.  I can even show
students how it is programed to work -- however disguisting the
innards may be. 

-- Gaby



From martin.rubey at univie.ac.at  Thu Aug 24 07:16:56 2006
From: martin.rubey at univie.ac.at (Martin Rubey)
Date: 24 Aug 2006 13:16:56 +0200
Subject: [Aldor-l] [Axiom-developer] spad: language and compiler
In-Reply-To: <m3u042a0jv.fsf@zeus.integrable-solutions.net>
References: <20060823223817.54667.qmail@web56710.mail.re3.yahoo.com>
	<m3u042a0jv.fsf@zeus.integrable-solutions.net>
Message-ID: <9qk64ycriv.fsf@login.mat.univie.ac.at>

Gabriel Dos Reis <gdr at integrable-solutions.net> writes:

> I know Martin has examples for dependent types.  Are those the only things we
> are missing?

Yes:

* types being first class objects, i.e., being able to have a list of Rings.

Examples:

f(m: INT, n: INT): PF n == m::PF(n)

[f(100, n) for n in primes(1,100)]

L := [PF(n) for n in primes(1,100)]

[a::P for P in L]

> My take is that the improvement to the SPAD compiler, first, needs to be
> driven by needs we have for writing Axiom libraries.

If we had dependent types, we could get rid of "Any" in the series
operations. If we have both of the above, Combinat will work in Axiom.

By the way, I think it is more important to make the interpreter understand
these things. Since:

* it would maybe be easier, I guess 

* we have to do it anyway: having the compiler understand won't help since we
                           couldn't use it in the interpreter

                           the aldor interpreter doesn't work too well

* we could use aldor meanwhile

* it will help us understand the issues involved, I guess


> We need a clearer type system and semantics description -- this independently
> of whether we convert to Aldor or not.

As far as I know, the SPAD implementation does not "conflict" with the Aldor
language. I.e., those concepts that are present work just as specified in the
Aldor User Guide.

So, this amounts to clarifying the Aldor User guide. Quite a bit of work has
been done on this side. Consult the archives or ask specific questions on
aldor-devel.

> Jaakko and I are interested in the dependent type system aspect, 

great!

> If people can look at the existing Axiom libraries (of planned libraries)
> souces and say what they would like to express _directly_ -- assuming they
> had the linguistic constructs -- that would help us shape directions for the
> SPAD language and compiler.

I think, that the series stuff in the algebra(SPAD) library and our species
stuff serve as very good examples for the things I personally would like to
have. I would really like you to start on that one :-)

BTW, I think that there is no SPAD language, only a SPAD implementation. There
is however an Aldor language (more or less) and an Aldor
implementation. Fortunately, the SPAD implementation implements a subset (in
some sense) of the Aldor language.

> It is important we aim at "ideal expression", not just limited to what the
> current SPAD or Aldor languages accept (hi Martin, Ralf).

I think that we first need to explore the possibilities of the Aldor language
before we embark to modify it. When we do, I think the thesis of Nic Doye is a
good starting point, as well as FOCAL by Renaud Rioboo and THEOREMA by
Buchberger et al.,

> Of course, we have gotten the lisp problem.  I don't volunteer to
> attack that one yet.  :-/  

for the interpreter I guess that this is nearly a must (or was it BOOT?).Unless
you rewrite it from scratch. In this case, Aldor would be a natural choice, I
guess. Christian has a parser written in Aldor, but you know that.

> However, I have the desire to target not just Lisp, but C, C++ and probably
> Java or C#.  There are interesting problems lurking there, but not none that
> is urgent.

So, that's a point for FOAM :-)

Martin



From ralf at hemmecke.de  Thu Aug 24 07:50:09 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Thu, 24 Aug 2006 13:50:09 +0200
Subject: [Aldor-l] [Axiom-developer] spad: language and compiler
In-Reply-To: <9qk64ycriv.fsf@login.mat.univie.ac.at>
References: <20060823223817.54667.qmail@web56710.mail.re3.yahoo.com>	<m3u042a0jv.fsf@zeus.integrable-solutions.net>
	<9qk64ycriv.fsf@login.mat.univie.ac.at>
Message-ID: <44ED9271.4090106@hemmecke.de>

> f(m: INT, n: INT): PF n == m::PF(n)
> 
> [f(100, n) for n in primes(1,100)]

Ask yourself, what type that list will have and you realise that Aldor 
will reject that its compilation.

> L := [PF(n) for n in primes(1,100)]

That is fine, though.

> [a::P for P in L]

That is as problematic as the first list.

> So, this amounts to clarifying the Aldor User guide. Quite a bit of work has
> been done on this side. Consult the archives or ask specific questions on
> aldor-devel.

aldor-l at aldor.org to be precise.

> BTW, I think that there is no SPAD language, only a SPAD implementation.

That's a good one. There is an implementation of a non-language. How 
could someone have implemented that?

>> It is important we aim at "ideal expression", not just limited to what the
>> current SPAD or Aldor languages accept (hi Martin, Ralf).

I am all with you, Gaby, As you know, I would like to see support for 
formal specification inside the language. An Aldor program should allow 
to be fed to a proof checker, so I would like to be able to express 
invariants and all that stuff formally and not just in the documentation.

>> However, I have the desire to target not just Lisp, but C, C++ and probably
>> Java or C#.  There are interesting problems lurking there, but not none that
>> is urgent.
> 
> So, that's a point for FOAM :-)

I also think so. You can completely forget about Aldor if you just want 
to generate different target languages. That is as I understand the foam 
business.

Ralf


From martin.rubey at univie.ac.at  Thu Aug 24 08:38:19 2006
From: martin.rubey at univie.ac.at (Martin Rubey)
Date: 24 Aug 2006 14:38:19 +0200
Subject: [Aldor-l] [Axiom-developer] spad: language and compiler
In-Reply-To: <44ED9271.4090106@hemmecke.de>
References: <20060823223817.54667.qmail@web56710.mail.re3.yahoo.com>
	<m3u042a0jv.fsf@zeus.integrable-solutions.net>
	<9qk64ycriv.fsf@login.mat.univie.ac.at> <44ED9271.4090106@hemmecke.de>
Message-ID: <9qhd02mhqc.fsf@login.mat.univie.ac.at>

Ralf Hemmecke <ralf at hemmecke.de> writes:

> > f(m: INT, n: INT): PF n == m::PF(n)
that's OK.


> > [f(100, n) for n in primes(1,100)]
that's stupid.

> Ask yourself, what type that list will have and you realise that Aldor will
> reject that its compilation.
Excuse me, Gaby. Sorry about being so stupid.


> > [a::P for P in L]
> That is as problematic as the first list.
"problematic" is an understatement. Sorry.

> > BTW, I think that there is no SPAD language, only a SPAD implementation.
> 
> That's a good one. There is an implementation of a non-language. How could
> someone have implemented that?

Quite unbelievable, isn't it? (Maybe I'm being too critical though. I wouldn't
call Basic a "language" in the sense I'm trying to establish here. I probably
should have said: specification)


Martin



From ralf at hemmecke.de  Thu Aug 24 12:18:55 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Thu, 24 Aug 2006 18:18:55 +0200
Subject: [Aldor-l] Surprising compiler...
Message-ID: <44EDD16F.3050700@hemmecke.de>

It seems that the compiler people are kind of funny...

"csseries.as", line 164:
local (x: %) * (y: %): Generator Integer == generate {
.....................................................^
[L164 C54] #4 (Fatal Error) Compiler bug: no exit list for 
terrorSequence (ooops).

Anyway, that doesn't help me too much. :-(

Ralf


From martin.rubey at univie.ac.at  Thu Aug 24 13:31:26 2006
From: martin.rubey at univie.ac.at (Martin Rubey)
Date: 24 Aug 2006 19:31:26 +0200
Subject: [Aldor-l] question about set! in streams
In-Reply-To: <44EDAB23.7040705@hemmecke.de>
References: <44E81C24.1060400@hemmecke.de>
	<op.ter3smwlu6j4vy@spencer.aistleitner.info>
	<44ED6849.8070007@hemmecke.de> <9qmz9u7btp.fsf@login.mat.univie.ac.at>
	<44ED7045.7070105@risc.uni-linz.ac.at>
	<9qu0424bu8.fsf@login.mat.univie.ac.at> <44ED9336.8030107@hemmecke.de>
	<9qsljm4767.fsf@login.mat.univie.ac.at> <44EDAB23.7040705@hemmecke.de>
Message-ID: <9q8xle6nwx.fsf_-_@login.mat.univie.ac.at>

Dear all,

I'm just attempting to solve the initial values problem. However I stepped on
an Aldor problem.

Can somebody explain the output of the attached program to me?

WARNING: it enters an infinite loop.

The output begins with
-------------------------------------------------------------------------------
set!01
set!end
Hi
set!01
coeff0
coeff0
coeff0
coeff0
coeff0
-------------------------------------------------------------------------------

and goes on with coeff0 forever...

Short explanation: The following program works as expected. Its output is
simply

-------------------------------------------------------------------------------
set!01
-------------------------------------------------------------------------------

i.e., coefficient is never called.

#include "aldor"
#include "aldorio"


define GeneratingSeriesCategory: Category == with {
        0: %;
        coefficient: (%, Integer) -> Integer;
        set!: (%, Integer, Integer) -> Integer;
}
GeneratingSeries: GeneratingSeriesCategory == add {
        Rep == Stream Integer;
        import from Integer, Rep, MachineInteger;
        0: % == per stream(0);
        coefficient(x: %, n: Integer): Integer == {
                stdout << "coeff" << n << newline;      
                (rep x).(machine n);
        }
        set!(x: %, n: Integer, v: Integer): Integer == {
                stdout << "set!" << n << v << newline;  
                set!(rep x, machine n, v);
        }
}
test(): () == {
        import from Integer;
        g: GeneratingSeries;
        set!(g, 0, 1);
}
test();

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------

The story is different for the following program, where some recursion is
taking place. Note that generatingSeries$MyList is defined in terms of
itself. Still, I don't understand why coefficient is called. Is there a way to
modify generatingSeries$MyList without having coefficient called?

!!!PLEASE HELP!!!

Martin

-------------------------------------------------------------------------------
#include "aldor"
#include "aldorio"

define GeneratingSeriesCategory: Category == with {
        0: %;
        coerce: Stream Integer -> %;
        coefficient: (%, Integer) -> Integer;
        set!: (%, Integer, Integer) -> Integer;
        +: (%, %) -> %;
        *: (%, %) -> %; 
}
GeneratingSeries: GeneratingSeriesCategory == add {
        Rep == Stream Integer;
        import from Integer, Rep, MachineInteger;
        0: % == per stream(0);
        coerce(s: Stream Integer): % == per s;
        coefficient(x: %, n: Integer): Integer == {
                stdout << "coeff" << n << newline;      
                (rep x).(machine n);
        }
        set!(x: %, n: Integer, v: Integer): Integer == {
                stdout << "set!" << n << v << newline;  
                z := set!(rep x, machine n, v);
                stdout << "set!end" << newline; 
                z;
        }
        
        (x: %) + (y: %): % == per stream(0$I, (n:MachineInteger):Integer 
                                              +-> (rep x).n + (rep y).n);

        (x: %) * (y: %): % == {
                local coeffTimes(nMI: MachineInteger): Integer == {
                        local n       : Integer := nMI::Integer;
                        local startIdx: Integer := 0;
                        local endIdx  : Integer := n;       
  
--                      if zero? ( coefficient( x, 0 ) ) then
--                      {
--                              startIdx := 1;
--                      }

                        z: Integer := 0;
                        for k in startIdx .. endIdx repeat {
                                z := z + coefficient( x, k ) 
                                       * coefficient( y, (n-k) );
                        }
                        z;
                }               
                per stream(0$MachineInteger, coeffTimes);
        }
}

define CombinatorialSpecies(L: PrimitiveType): Category == with {
        generatingSeries: GeneratingSeries;
}

CharacteristicSpecies(n:Integer)(L:PrimitiveType): CombinatorialSpecies L == 
    add {
        Rep == Set L;
        nn: MachineInteger == machine n;
        nth(k: MachineInteger): Integer == if k = nn then return 1 else 0;
        import from Rep;
        generatingSeries: GeneratingSeries == {
                import from Stream Integer;
                stream(0, nth, next nn, 0) :: GeneratingSeries;
        }
}


1(L: PrimitiveType): CombinatorialSpecies L == 
        CharacteristicSpecies(0$Integer)(L);

X(L: PrimitiveType): CombinatorialSpecies L == 
        CharacteristicSpecies(1$Integer)(L);

(+)(
    F: (T: PrimitiveType) -> CombinatorialSpecies(T),
    G: (T: PrimitiveType) -> CombinatorialSpecies(T)
): (L: PrimitiveType) -> CombinatorialSpecies(L) == (L: PrimitiveType):
    CombinatorialSpecies(L) +-> add {
        generatingSeries: GeneratingSeries == generatingSeries$F(L) +
    generatingSeries$G(L);
}

(*)(
    F: (T: PrimitiveType) -> CombinatorialSpecies(T),
    G: (T: PrimitiveType) -> CombinatorialSpecies(T)
): (L: PrimitiveType) -> CombinatorialSpecies(L) == (L: PrimitiveType):
    CombinatorialSpecies(L) +-> add {
        generatingSeries: GeneratingSeries == {
                import from Stream Integer;
                coerce stream( 0$MachineInteger, 
                    (n:MachineInteger):Integer +-> 
                              coefficient(generatingSeries$F(L) *
                                          generatingSeries$G(L), n::Integer) );
        }
}

MyList(L: PrimitiveType): CombinatorialSpecies L == ( 1 + X*MyList*MyList)(L);

testMyList(): () == {
        import from Integer, String, MyList String;
        h: GeneratingSeries := 0;
        set!(h, 0, 1);
        g: GeneratingSeries := generatingSeries;
        stdout << "Hi" << newline; -- until here everything works just fine     
        set!(g, 0, 1);
}
testMyList();

-------------------------------------------------------------------------------



From martin.rubey at univie.ac.at  Thu Aug 24 14:18:57 2006
From: martin.rubey at univie.ac.at (Martin Rubey)
Date: 24 Aug 2006 20:18:57 +0200
Subject: [Aldor-l] question about set! in streams / shorter example
In-Reply-To: <9q8xle6nwx.fsf_-_@login.mat.univie.ac.at>
References: <44E81C24.1060400@hemmecke.de>
	<op.ter3smwlu6j4vy@spencer.aistleitner.info>
	<44ED6849.8070007@hemmecke.de> <9qmz9u7btp.fsf@login.mat.univie.ac.at>
	<44ED7045.7070105@risc.uni-linz.ac.at>
	<9qu0424bu8.fsf@login.mat.univie.ac.at> <44ED9336.8030107@hemmecke.de>
	<9qsljm4767.fsf@login.mat.univie.ac.at> <44EDAB23.7040705@hemmecke.de>
	<9q8xle6nwx.fsf_-_@login.mat.univie.ac.at>
Message-ID: <9qirkiro8e.fsf_-_@login.mat.univie.ac.at>

I have a much shorter example for my question now:
-------------------------------------------------------------------------------
#include "aldor"
#include "aldorio"


define GeneratingSeriesCategory: Category == with {
        coerce: Stream Integer -> %;    
        set!: (%, Integer, Integer) -> Integer;
}
GeneratingSeries: GeneratingSeriesCategory == add {
        Rep == Stream Integer;
        import from Integer, Rep, MachineInteger;
        coerce(s: Stream Integer): % == per s;

        set!(x: %, n: Integer, v: Integer): Integer == {
                stdout << "set! " << n << " " << v << newline;  
                set!(rep x, machine n, v);
        }
}
test(): () == {
        import from Integer, Stream Integer;
        g: GeneratingSeries := coerce stream(0$MachineInteger, 
                                             (n:MachineInteger):Integer +-> {
                                                     stdout << "gen " << n
                                                            << newline;  
                                                     n::Integer} );
        stdout << "Start" << newline;                                                    
        set!(g, 0, 1);
        stdout << "Middle" << newline;          
        set!(g, 0, 2);  
        stdout << "End" << newline;     
}
test();
-------------------------------------------------------------------------------

the output is:

Start
set! 0 1
gen 0
Middle
set! 0 2
End

and the question is:

WHY IS gen 0 APPEARING?

Please help!

Martin



From martin.rubey at univie.ac.at  Thu Aug 24 14:56:25 2006
From: martin.rubey at univie.ac.at (Martin Rubey)
Date: 24 Aug 2006 20:56:25 +0200
Subject: [Aldor-l] question about set! in streams / even shorter
In-Reply-To: <9qirkiro8e.fsf_-_@login.mat.univie.ac.at>
References: <44E81C24.1060400@hemmecke.de>
	<op.ter3smwlu6j4vy@spencer.aistleitner.info>
	<44ED6849.8070007@hemmecke.de> <9qmz9u7btp.fsf@login.mat.univie.ac.at>
	<44ED7045.7070105@risc.uni-linz.ac.at>
	<9qu0424bu8.fsf@login.mat.univie.ac.at> <44ED9336.8030107@hemmecke.de>
	<9qsljm4767.fsf@login.mat.univie.ac.at> <44EDAB23.7040705@hemmecke.de>
	<9q8xle6nwx.fsf_-_@login.mat.univie.ac.at>
	<9qirkiro8e.fsf_-_@login.mat.univie.ac.at>
Message-ID: <9qy7teync6.fsf_-_@login.mat.univie.ac.at>

Finally, I think I have the ultimate way to formulate my question:

For a Stream, why does set! compute the element I want to modify destructively?

Suppose I have a stream of the form s := stream(0, f) and I say

set!(s, 0, 1783);

why on earth is f(0) computed? Is there a way around that? Unfortunately, the
stream is already given. It is not an option to define it differently in the
first place.

Martin



From ralf at hemmecke.de  Thu Aug 24 15:19:30 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Thu, 24 Aug 2006 21:19:30 +0200
Subject: [Aldor-l] question about set! in streams / even shorter
In-Reply-To: <9qy7teync6.fsf_-_@login.mat.univie.ac.at>
References: <44E81C24.1060400@hemmecke.de>	<op.ter3smwlu6j4vy@spencer.aistleitner.info>	<44ED6849.8070007@hemmecke.de>
	<9qmz9u7btp.fsf@login.mat.univie.ac.at>	<44ED7045.7070105@risc.uni-linz.ac.at>	<9qu0424bu8.fsf@login.mat.univie.ac.at>
	<44ED9336.8030107@hemmecke.de>	<9qsljm4767.fsf@login.mat.univie.ac.at>
	<44EDAB23.7040705@hemmecke.de>	<9q8xle6nwx.fsf_-_@login.mat.univie.ac.at>	<9qirkiro8e.fsf_-_@login.mat.univie.ac.at>
	<9qy7teync6.fsf_-_@login.mat.univie.ac.at>
Message-ID: <44EDFBC2.7020607@hemmecke.de>

On 08/24/2006 08:56 PM, Martin Rubey wrote:
> Finally, I think I have the ultimate way to formulate my question:
> 
> For a Stream, why does set! compute the element I want to modify destructively?
> 
> Suppose I have a stream of the form s := stream(0, f) and I say
> 
> set!(s, 0, 1783);
> 
> why on earth is f(0) computed?

That is simple. Internally a stream is an Array(T) + a function
next: () -> T that computes the next element. If set! would not compute 
f(0) (which means: call next() and store the value into the zeroth 
position of the array), then the "next" function would be wrong since it 
then is called for the first time to compute f(1), but remember, it is 
called for the first time and so would assign to the array in position 1 
what was actually meant for position 0.

> Is there a way around that? Unfortunately, the
> stream is already given. It is not an option to define it differently in the
> first place.

But you can define your own Stream. I more or less have already done so.
But I restrict to the stuff we need in aldor-combinat.

Ralf


From martin.rubey at univie.ac.at  Thu Aug 24 16:04:14 2006
From: martin.rubey at univie.ac.at (Martin Rubey)
Date: 24 Aug 2006 22:04:14 +0200
Subject: [Aldor-l] question about set! in streams / even shorter
In-Reply-To: <44EDFBC2.7020607@hemmecke.de>
References: <44E81C24.1060400@hemmecke.de>
	<op.ter3smwlu6j4vy@spencer.aistleitner.info>
	<44ED6849.8070007@hemmecke.de> <9qmz9u7btp.fsf@login.mat.univie.ac.at>
	<44ED7045.7070105@risc.uni-linz.ac.at>
	<9qu0424bu8.fsf@login.mat.univie.ac.at> <44ED9336.8030107@hemmecke.de>
	<9qsljm4767.fsf@login.mat.univie.ac.at> <44EDAB23.7040705@hemmecke.de>
	<9q8xle6nwx.fsf_-_@login.mat.univie.ac.at>
	<9qirkiro8e.fsf_-_@login.mat.univie.ac.at>
	<9qy7teync6.fsf_-_@login.mat.univie.ac.at>
	<44EDFBC2.7020607@hemmecke.de>
Message-ID: <9qodu9gatd.fsf@login.mat.univie.ac.at>

Ralf Hemmecke <ralf at hemmecke.de> writes:

> On 08/24/2006 08:56 PM, Martin Rubey wrote:
> > Finally, I think I have the ultimate way to formulate my question:
> > For a Stream, why does set! compute the element I want to modify
> > destructively?
> > Suppose I have a stream of the form s := stream(0, f) and I say
> > set!(s, 0, 1783);
> > why on earth is f(0) computed?
> 
> That is simple. Internally a stream is an Array(T) + a function next: () -> T
> that computes the next element. If set! would not compute f(0) (which means:
> call next() and store the value into the zeroth position of the array), then
> the "next" function would be wrong since it then is called for the first time
> to compute f(1), but remember, it is called for the first time and so would
> assign to the array in position 1 what was actually meant for position 0.

Ah, that makes sense. That is, stream doesn't use n +-> f(n) but rather a
function derived from that one.

Is there a way to delete an element from a stream? Eg., in Axiom one can say

delete(s, 2) 

(s being a Stream) and gets the Stream s.1, s.3, s.4,...

Martin



From ralf at hemmecke.de  Thu Aug 24 16:18:09 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Thu, 24 Aug 2006 22:18:09 +0200
Subject: [Aldor-l] question about set! in streams / even shorter
In-Reply-To: <9qodu9gatd.fsf@login.mat.univie.ac.at>
References: <44E81C24.1060400@hemmecke.de>	<op.ter3smwlu6j4vy@spencer.aistleitner.info>	<44ED6849.8070007@hemmecke.de>
	<9qmz9u7btp.fsf@login.mat.univie.ac.at>	<44ED7045.7070105@risc.uni-linz.ac.at>	<9qu0424bu8.fsf@login.mat.univie.ac.at>
	<44ED9336.8030107@hemmecke.de>	<9qsljm4767.fsf@login.mat.univie.ac.at>
	<44EDAB23.7040705@hemmecke.de>	<9q8xle6nwx.fsf_-_@login.mat.univie.ac.at>	<9qirkiro8e.fsf_-_@login.mat.univie.ac.at>	<9qy7teync6.fsf_-_@login.mat.univie.ac.at>	<44EDFBC2.7020607@hemmecke.de>
	<9qodu9gatd.fsf@login.mat.univie.ac.at>
Message-ID: <44EE0981.3000909@hemmecke.de>

> Is there a way to delete an element from a stream? Eg., in Axiom one can say

> delete(s, 2) 

> (s being a Stream) and gets the Stream s.1, s.3, s.4,...

The API of LibAldor doesn't show such a delete. But of course it would 
be easy to greate such a stream.

delete(s: Stream T, n: MachineInteger): Stream T == {
     g: Generator T == generate {
         for i in 0 .. for t in s repeat if i ~= n then yield t;
     }
     stream g;
}

Ralf


From ralf at hemmecke.de  Fri Aug 25 16:01:19 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Fri, 25 Aug 2006 22:01:19 +0200
Subject: [Aldor-l] How to emulate new infix and postfix operators in Aldor
Message-ID: <44EF570F.2020809@hemmecke.de>

Hello,

I think some of you might find this interesting ...

*Question:* Aldor has a number of infix operators (AUG Sect 4.4). Can 
one define other infix operators?

*Answer:* No.

*Question:* Aldor has a number of postfix operators (notably ".."). Can 
one define other postfix operators?

*Answer:* No.

*Question:* Can one experiment with syntactic sugar in Aldor?

*Anser:* *YES!!!*

---BEGIN aaaInfixPostfix.as
#include "aldor"
#include "aldorio"

macro Z == Integer;

extend Z: with {
	apply: (Z, Z -> Z) -> Z;
} == add {
	apply(z: Z, f: Z -> Z): Z == f z;
}
main(): () == {
	_42 := "I am forty-two."; -- _42 is an identifier.
	stdout << _42 << newline;
	
	_!(z: Z): Z == {zero? z => 1; z * (z-1)_!;}
	z: Z := 4 _!;
	stdout << z << newline;

	x(a: Z)(b: Z): Z == a*b;
	z := 4 x 5 x 2;
	stdout << z << newline;
}
main();
---END aaapostfix.as

 >aldor -grun -laldor aaaInfixPostfix.as
--rhx: ignore the compiler warnings...
I am forty-two.
24
40

Hope, you like that...

Ralf


From ralf at hemmecke.de  Tue Aug 29 06:42:04 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Tue, 29 Aug 2006 12:42:04 +0200
Subject: [Aldor-l] Type: Type
In-Reply-To: <87odu3eu5u.fsf@soliton.cs.tamu.edu>
References: <20060829025344.90960.qmail@web56714.mail.re3.yahoo.com>	<44F40C6B.70501@hemmecke.de>
	<87odu3eu5u.fsf@soliton.cs.tamu.edu>
Message-ID: <44F419FC.7010302@hemmecke.de>

> At the logical level, as I have observed some time ago, there is an
> inconsistency problem with Type:Type.  I'm wondering how Aldor gets
> away with that.  Many languages (mostly functional) use stratified
> types.

That question should be asked at aldor-l.

Can you construct a paradox that demonstrates the problem in terms of 
Aldor code? To me it looks like the class (not set) of all classes. 
Would there be a problem in class theory?

Ralf


From watt at scl.csd.uwo.ca  Tue Aug 29 08:51:47 2006
From: watt at scl.csd.uwo.ca (Stephen Watt)
Date: Tue, 29 Aug 2006 08:51:47 -0400
Subject: [Aldor-l] Type: Type
In-Reply-To: <44F419FC.7010302@hemmecke.de>
References: <20060829025344.90960.qmail@web56714.mail.re3.yahoo.com>
	<44F40C6B.70501@hemmecke.de> <87odu3eu5u.fsf@soliton.cs.tamu.edu>
	<44F419FC.7010302@hemmecke.de>
Message-ID: <20060829125147.GA11369@ptibonum.scl.csd.uwo.ca>

You are correct that there is a potential inconsistency.

We avoid Russel's paradox by limiting the operations for
constructing and testing membership in type categories.

Note that many programming languages have the problem of
allowing types with no elements, which can lead to the type
theory equivalent of a division by zero error.

Aldor is no exception in this regard:  It is possible to construct
a domain with no effective way to make elements.  

These kinds of errors have to be seen as  bugs in programs, just as 
division by zero is a programming error and not an invalidation of
integer arithmetic.

-- Stephen
    

On Tue, Aug 29, 2006 at 12:42:04PM +0200, Ralf Hemmecke wrote:
> > At the logical level, as I have observed some time ago, there is an
> > inconsistency problem with Type:Type.  I'm wondering how Aldor gets
> > away with that.  Many languages (mostly functional) use stratified
> > types.
> 
> That question should be asked at aldor-l.
> 
> Can you construct a paradox that demonstrates the problem in terms of 
> Aldor code? To me it looks like the class (not set) of all classes. 
> Would there be a problem in class theory?
> 
> Ralf
> _______________________________________________
> Aldor-l mailing list
> Aldor-l at aldor.org
> http://www.aldor.org/mailman/listinfo/aldor-l


From Bill.Page at drdc-rddc.gc.ca  Tue Aug 29 19:25:33 2006
From: Bill.Page at drdc-rddc.gc.ca (Page, Bill)
Date: Tue, 29 Aug 2006 19:25:33 -0400
Subject: [Aldor-l] How to emulate new infix and postfix operators in
	Aldor
In-Reply-To: <44EF570F.2020809@hemmecke.de>
Message-ID: <CAE9B164E720CE4D8727792DF8F28AE37D3524@corporateex02.Corporate.drdc-rddc.gc.ca>

Ralf, 

On Friday, August 25, 2006 4:01 PM you wrote:
> 
> I think some of you might find this interesting ...
> 
> *Question:* Aldor has a number of infix operators (AUG Sect 4.4).
> Can one define other infix operators?
> 
> *Answer:* No.
> 
> *Question:* Aldor has a number of postfix operators (notably 
> ".."). Can one define other postfix operators?
> 
> *Answer:* No.
>

In a general purpose compiler these limitations seem very
desirable to me. But of course in Axiom or other computer
algebra system one might wish for more flexibility in order
to better model common mathematical usage.
 
> *Question:* Can one experiment with syntactic sugar in
> Aldor?
> 
> *Answer:* *YES!!!*
> 
> ---BEGIN aaaInfixPostfix.as
> #include "aldor"
> #include "aldorio"
> 
> macro Z == Integer;
> 
> extend Z: with {
> 	apply: (Z, Z -> Z) -> Z;
> } == add {
> 	apply(z: Z, f: Z -> Z): Z == f z;
> }
> main(): () == {
> 	_42 := "I am forty-two."; -- _42 is an identifier.
> 	stdout << _42 << newline;
> 	
> 	_!(z: Z): Z == {zero? z => 1; z * (z-1)_!;}
> 	z: Z := 4 _!;
> 	stdout << z << newline;
> 
> 	x(a: Z)(b: Z): Z == a*b;
> 	z := 4 x 5 x 2;
> 	stdout << z << newline;
> }
> main();
> ---END aaapostfix.as
> 
>  >aldor -grun -laldor aaaInfixPostfix.as
> --rhx: ignore the compiler warnings...
> I am forty-two.
> 24
> 40
> 
> Hope, you like that...
> 

Nice.

But I don't see much "syntactic sugar" here. Using _42 as an
identifier just seems weird. Can you think of a reason to do
that?

The other two examples are not a matter of syntax but rather of
semantics. Defining the application of an integer to a function
as evaluation of the function on that integer is clever. Because
application is denoted by simple juxtaposition, this only looks
like "syntax" but really it just makes all unary functions commute
with their arguments. E.g.

  import from Integer;

  z abs = abs z

We can even extend this to binary functions:

  extend Z: with {
    apply: (Z, Z -> Z) -> Z;
    apply: (Z, Z) -> Cross(Z,Z);
    apply: (Z, (Z,Z) -> Z) -> (Z->Z);
  } == add {
    apply(z: Z, f: Z -> Z): Z == f z;
    apply(z: Z, w: Z): Cross(Z,Z) == (z,w);
    apply(z: Z, f: (Z,Z) -> Z): (Z->Z) == ((x:Z):Z +-> f(z,x));
  }

Then we have

  sum(z:Z,w:Z):Z == z+w;

  1 2 sum = sum 1 2

Unfortunately although we can now write

  + 1 2

the over jealous compiler rejects

  1 2 +

as a syntax error (although it would seem ok to me).

Regards,
Bill Page.



From ralf at hemmecke.de  Tue Aug 29 19:54:28 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Wed, 30 Aug 2006 01:54:28 +0200
Subject: [Aldor-l] How to emulate new infix and postfix operators in
	Aldor
In-Reply-To: <CAE9B164E720CE4D8727792DF8F28AE37D3524@corporateex02.Corporate.drdc-rddc.gc.ca>
References: <CAE9B164E720CE4D8727792DF8F28AE37D3524@corporateex02.Corporate.drdc-rddc.gc.ca>
Message-ID: <44F4D3B4.605@hemmecke.de>

> But I don't see much "syntactic sugar" here.

The syntactic sugar is that you don't *see* the "apply" function.
The compiler add "apply" for you without changing the semantics of the 
program.

 > Using _42 as an identifier just seems weird. Can you think of a 
reason to do
> that?

No. But, when I was looking for turning ! into an identifier, I found 
_33 in the AUG and so I just copied it here for demonstration. I don't 
think that I would use it unless someone tells me a nice application.

> Then we have
> 
>   sum(z:Z,w:Z):Z == z+w;
> 
>   1 2 sum = sum 1 2
> 
> Unfortunately although we can now write
> 
>   + 1 2
> 
> the over jealous compiler rejects
> 
>   1 2 +
> 
> as a syntax error (although it would seem ok to me).

Well, + is a special thing as would be all the other operators that are 
treated as "infix" operators by the language. You can explicitly turn 
them into prefix operators by putting parentheses around them.

Try

1 2 (+)

That works.

Ralf


From Bill.Page at drdc-rddc.gc.ca  Tue Aug 29 20:09:17 2006
From: Bill.Page at drdc-rddc.gc.ca (Page, Bill)
Date: Tue, 29 Aug 2006 20:09:17 -0400
Subject: [Aldor-l] How to emulate new infix and postfix operators in
	Aldor
In-Reply-To: <44F4D3B4.605@hemmecke.de>
Message-ID: <CAE9B164E720CE4D8727792DF8F28AE37D3525@corporateex02.Corporate.drdc-rddc.gc.ca>

Ralf,

On Tuesday, August 29, 2006 7:54 PM you wrote:
> Bill Page wrote: 
> > But I don't see much "syntactic sugar" here.
> 
> The syntactic sugar is that you don't *see* the "apply" function.
> The compiler add "apply" for you without changing the semantics
> of the program.

I would put this differently. 'apply' is a just another generic tie-in
(see http://www.aldor.org/docs/HTML/chap11.html) like 'bracket'. And
juxaposition always denotes application (that's semantics!). See
http://www.aldor.org/docs/HTML/chap4.html#6 No syntax involved here at
all. But I guess it doesn't really matter what you call it unless you
are the compiler writer. :)

> ... 
> Try
> 
> 1 2 (+)
> 
> That works.
> 

Neat. Thanks.

Regards,
Bill Page.



From Bill.Page at drdc-rddc.gc.ca  Wed Aug 30 05:30:26 2006
From: Bill.Page at drdc-rddc.gc.ca (Page, Bill)
Date: Wed, 30 Aug 2006 05:30:26 -0400
Subject: [Aldor-l] Type: Type
In-Reply-To: <20060829125147.GA11369@ptibonum.scl.csd.uwo.ca>
Message-ID: <CAE9B164E720CE4D8727792DF8F28AE37D352E@corporateex02.Corporate.drdc-rddc.gc.ca>

On Tuesday, August 29, 2006 6:03 AM Gabriel Dos Reis wrote:
>>> At the logical level, as I have observed some time ago, there
>>> is an inconsistency problem with Type:Type.  I'm wondering how
>>> Aldor gets away with that.  Many languages (mostly functional)
>>> use stratified types.

On Tue, Aug 29, 2006 at 12:42:04PM +0200, Ralf Hemmecke wrote:
>> Can you construct a paradox that demonstrates the problem in
>> terms of Aldor code? To me it looks like the class (not set)
>> of all classes. Would there be a problem in class theory?

On Tuesday, August 29, 2006 8:52 AM Stephen Watt wrote:
> 
> You are correct that there is a potential inconsistency.
> 
> We avoid Russel's paradox by limiting the operations for
> constructing and testing membership in type categories.
> ...

I think the fact that Aldor defines the type of Type as Type
is very interesting from a theoretical point of view and that
it is not correct to suggest that it implies any inconsistency
or even necessarily any fundamental limitation.

In mathematics it is often necessary to deal formally with
"very large" objects, for example, to be able to reason and
compute with things like streams and formal series or for that
matter even objects such as exact real numbers. These things
do not have simple finite representations inside the computer
yet we do have means to manipulate such objects in the Aldor
and Axiom libaries. Even larger objects such as categories and
the category of all categories can be effectively represented.

Non-well-founded set theory deals specifically with this kind
of situation. (Note: The term "non-well-founded" should not be
interpreted pejoratively, in the same way "imaginary" does not
imply any algebraic defect in reference to a number.)

http://en.wikipedia.org/wiki/Non-well-founded_set_theory

I am particularly fond of the book by Barwise and Moss:
Vicious Circles: on the mathematics of circular phenomena,
CSLI Lecture Notes, 1996.

An earlier but very important reference is the book by
Peter Aczel, Non-Well-Founded Sets. Center for the Study of
Language and Information, CSLI Lecture Notes no. 14, 1988.

http://standish.stanford.edu/pdf/00000056.pdf

One of the ways of axiomatizing non-well-founded sets is via
"accessible pointed graphs". It seems to me that these graphs
also provide an excellent model for Types in Aldor and Axiom.

This is particularly evident in the Axiom library where there
are many inherent circular dependencies. Given the presence of
circulary dependencies and the potential for mutual recursion,
fixed point methods seem especially appropropriate for compiling
the Axiom library. It seems that the SPAD language leaves no
alternative to this process, but Aldor is able to compile some
mutually recursive definitions when they occur in the same source
file. And post-facto extension makes many (most?) cases of mutual
recursion over larger groups of library modules unnecessary. It
remains to be determined whether this is sufficient to implement
Axiom's library without any essential compromises.

http://wiki.axiom-developer.org/MutualRecursion

Further, it seems to me that in principle the concept of
bi-simulation introduced in the theory of non-well-founded sets
might provide an effective definition of equivalence for Aldor's
types.

Regards,
Bill Page.



From ralf at hemmecke.de  Wed Aug 30 07:35:55 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Wed, 30 Aug 2006 13:35:55 +0200
Subject: [Aldor-l] [Axiom-developer] spad: language and compiler
In-Reply-To: <web-8253734@cgate.sci.ccny.cuny.edu>
References: <web-8253734@cgate.sci.ccny.cuny.edu>
Message-ID: <44F5781B.4000103@hemmecke.de>

>>> > f(m: INT, n: INT): PF n == m::PF(n)
>> that's OK.
>>
>>
>>> > [f(100, n) for n in primes(1,100)]
>> that's stupid.

> Why? I would think it is an element (not a list) in a cartesian product 
> of #primes(1,100) prime fields.

OK, if you like. But then I would like to see the definition of the 
bracket function. Can you give that?

I strongly believe you can't, because that would require Aldor to 
compute "primes(1,100)" at compile time. Which is currently not possible 
and if the compiler is allowed to evaluate it then it might run into an 
infinite loop (at compile time) since the "primes" function does not 
terminate as you would expect. Compile time evaluation in full 
generality introduces a way make it really hard to find bugs.

But anyway, maybe Aldor should allow compile time evaluation.

>>> Ask yourself, what type that list will have and you realise that 
>>> Aldor will
>>> reject that its compilation.
>> Excuse me, Gaby. Sorry about being so stupid.
> 
> It's a perfectly good mathematical object in a cartesian product.

William is right, but I cannot believe that a construction like

[f(100, n) for n in [2,3,5]$List(Integer)]

would work.

[f(100, n), f(100, n), f(100, n)]

should be easily definable and give an element in the cartesian product 
of   PF(2), PF(3), and PF(5). But that is a finite construct and not 
done via Generator as above.

>>> > [a::P for P in L]
>>> That is as problematic as the first list.
>> "problematic" is an understatement. Sorry.
> 
> Ditto. The only problem I see that can't be handled is if you make it 
> into a function of k:

> [f(100, n) for n in primes(1,k)]

Initially, I believe, Martin wanted lists. What you are calling for is a 
cartesian product constructor of the form.

PFCartesian(k: Integer): with {
     coerce: ((n: Integer) -> PF(n)) -> %;
     ...
} == add {
     ...
}

Then instead of [f(100, n) for n in primes(1,k)] it would be more 
appropriate to define

k: Integer == << stdin; -- read from standard input and make it constant
foo(m: Integer)(n: Integer): PF(n) == m :: PF(n);
import from PFCartesian(k);
z := foo(42) :: PFCartesian(k);

Such a construction would work, but it does not involve a Generator or 
something that you must compute at compile time.

Ralf


From carette at mcmaster.ca  Wed Aug 30 08:14:35 2006
From: carette at mcmaster.ca (Jacques Carette)
Date: Wed, 30 Aug 2006 08:14:35 -0400
Subject: [Aldor-l] [Axiom-developer] spad: language and compiler
In-Reply-To: <44F5781B.4000103@hemmecke.de>
References: <web-8253734@cgate.sci.ccny.cuny.edu>
	<44F5781B.4000103@hemmecke.de>
Message-ID: <44F5812B.1040205@mcmaster.ca>

Ralf Hemmecke wrote:
> Compile time evaluation in full 
> generality introduces a way make it really hard to find bugs.
>
> But anyway, maybe Aldor should allow compile time evaluation.
>   
Quick remark --  it has been shown that:
1) C++'s template language is a Turing Complete PL
2) Haskell's class types (with common extensions) is also a Turing 
Complete PL
3) All meta-programming systems allow arbitrary compile time evaluation

Yes, it does make debugging harder.  But the advantages seem to _far_ 
outweigh the problems.  One just develops new debugging (and coding) 
techniques to deal with the added power/complexity.

I could re-use Stephen's brilliant closing line from yesterday's email:
    "These kinds of errors have to be seen as bugs in programs, just as 
division by zero is a programming error and not an invalidation of 
integer arithmetic." -- S.M. Watt
[where 'These kinds of errors' is now /Programs with infinite loops in 
types/]

Jacques


From carette at mcmaster.ca  Wed Aug 30 13:17:37 2006
From: carette at mcmaster.ca (Jacques Carette)
Date: Wed, 30 Aug 2006 13:17:37 -0400
Subject: [Aldor-l] [Axiom-developer] spad: language and compiler
In-Reply-To: <87ac5m4bn1.fsf@soliton.cs.tamu.edu>
References: <web-8253734@cgate.sci.ccny.cuny.edu>	<44F5781B.4000103@hemmecke.de>
	<44F5812B.1040205@mcmaster.ca> <87ac5m4bn1.fsf@soliton.cs.tamu.edu>
Message-ID: <44F5C831.3070106@mcmaster.ca>

Gabriel Dos Reis wrote:
> I agree with most of what you said.  However, the slogan "well-typed
> programs don't go wrong" does some value that I would heisate to
> compromise...
>   
But well-typed programs can still diverge!  So "go wrong" just means 
that _when_ they return a value, it is guaranteed to be of the right type.

You can do the same thing for types - this is usually called a 'kinding' 
system.  In fact some languages (like Tim Sheard's Omega -- 
http://web.cecs.pdx.edu/~sheard/Omega/index.html) push that further by 
having a complete hierarchy (the names often used for the lower levels 
are term - type - kind - sort).

A "well-kinded" type doesn't "go wrong" either [assuming termination].

Jacques


From carette at mcmaster.ca  Wed Aug 30 13:28:53 2006
From: carette at mcmaster.ca (Jacques Carette)
Date: Wed, 30 Aug 2006 13:28:53 -0400
Subject: [Aldor-l] [Axiom-developer] spad: language and compiler
In-Reply-To: <Pine.GSO.4.58.0608301223280.4041@sun>
References: <web-8253734@cgate.sci.ccny.cuny.edu>
	<44F5781B.4000103@hemmecke.de> <44F5812B.1040205@mcmaster.ca>
	<87ac5m4bn1.fsf@soliton.cs.tamu.edu> <44F5C831.3070106@mcmaster.ca>
	<Pine.GSO.4.58.0608301223280.4041@sun>
Message-ID: <44F5CAD5.9000603@mcmaster.ca>

Gabriel Dos Reis wrote:
> With Type:Type, it is not clear to me that when a well-typed
> expression does not diverge, its value is not "wrong".
>   
Every 6 months or so, I tell Stephen he should write up a formalization 
of Aldor's type system, and prove the usual Progress and Preservation 
theorems for it. 

Jacques


From Bill.Page at drdc-rddc.gc.ca  Wed Aug 30 14:43:18 2006
From: Bill.Page at drdc-rddc.gc.ca (Page, Bill)
Date: Wed, 30 Aug 2006 14:43:18 -0400
Subject: [Aldor-l] [Axiom-developer] spad: language and compiler
In-Reply-To: <44F5CAD5.9000603@mcmaster.ca>
Message-ID: <CAE9B164E720CE4D8727792DF8F28AE37D3642@corporateex02.Corporate.drdc-rddc.gc.ca>

On Wednesday, August 30, 2006 1:29 PM Jacques Carette wrote:
> 
> Gabriel Dos Reis wrote:
> > With Type:Type, it is not clear to me that when a well-typed
> > expression does not diverge, its value is not "wrong".
> >   
> Every 6 months or so, I tell Stephen he should write up a 
> formalization of Aldor's type system, and prove the usual
> Progress and Preservation theorems for it. 
> 

When it comes to the application of Aldor as the Axiom library
compiler, I am afraid that demanding that Aldor satisfy these
usual requirements might amount to "throwing the baby out with
the bath water".

The concept of "Progress" is very similar to well-foundedness.
By direct analogy with the theory of non-well-founded sets we
can have non-well-founded types which violate Progress but still
satisfy Preservation.

There is a growing literature on this subject.

http://portal.acm.org/ft_gateway.cfm?id=351261&type=pdf

Recursive Subtyping Revealed
Functional Pearl
Vladimir Gapeyev, Michael Y. Levin, Benjamin C. Pierce

http://www.dcs.ed.ac.uk/home/mf/TYPES/coinduction.ps

A Coinduction Principle for Recursive Data Types
Based on Bisimulation, by Marcelo Fiore

etc.

But I supposed Gaby would claim that these are still more
"vague allusions to co-inductive formalism" ;) Oh well...

Regards,
Bill Page.



From carette at mcmaster.ca  Wed Aug 30 15:09:45 2006
From: carette at mcmaster.ca (Jacques Carette)
Date: Wed, 30 Aug 2006 15:09:45 -0400
Subject: [Aldor-l] [Axiom-developer] spad: language and compiler
In-Reply-To: <CAE9B164E720CE4D8727792DF8F28AE37D3642@corporateex02.Corporate.drdc-rddc.gc.ca>
References: <CAE9B164E720CE4D8727792DF8F28AE37D3642@corporateex02.Corporate.drdc-rddc.gc.ca>
Message-ID: <44F5E279.9060709@mcmaster.ca>

Page, Bill wrote:
>> Every 6 months or so, I tell Stephen he should write up a 
>> formalization of Aldor's type system, and prove the usual
>> Progress and Preservation theorems for it. 
>>     
>
> When it comes to the application of Aldor as the Axiom library
> compiler, I am afraid that demanding that Aldor satisfy these
> usual requirements might amount to "throwing the baby out with
> the bath water".
>
> The concept of "Progress" is very similar to well-foundedness.
> By direct analogy with the theory of non-well-founded sets we
> can have non-well-founded types which violate Progress but still
> satisfy Preservation.
>   
Aldor 'works'.  So if it were necessary to introduce new notions (or 
leverage recent work) to formally prove this, that would be icing on the 
cake!

As far as co-induction goes, I'm a fan too! ;-) 
[http://lists.seas.upenn.edu/pipermail/types-list/2004/000177.html]

Jacques


From ralf at hemmecke.de  Wed Aug 30 19:05:18 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Thu, 31 Aug 2006 01:05:18 +0200
Subject: [Aldor-l] [Axiom-developer] spad: language and compiler
In-Reply-To: <web-8259658@cgate.sci.ccny.cuny.edu>
References: <web-8259658@cgate.sci.ccny.cuny.edu>
Message-ID: <44F619AE.5020702@hemmecke.de>

Dear William,

> Getting back to your question, it is up to the programmer to define
> the bracket function for the domain where Martin's expression lives.
> Even though it may not be possible in Axiom to directly program
> tuples of heterogeneous domains, such tuples are present in most
> function signatures like foo:(INT, Boolean)->INT. I would expect
> Aldor therefore to be able to directly program tuples of
> heterogeneous domains.

As you know Record and Cross are two ways in Aldor to construct
heterogeneous tuples. The problem is that both must have a certain fixed
length when you write them into your program.

> Thus Martin's expression, perhaps using round parentheses instead of 
> brackets, should work in Aldor.

Martin's line contained a "for n in primes(1,100)" iterator, so the type
would only be know if the compiler were able to evaluate "primes(1,100)"
at compile time.

> I don't know how "primes" is implemented but it is probably a
> built-in using both a table for lower range and some sophisticated
> algorithms for higher ones.

Whatever "built-in" means for you. It is certainly not built into the 
Aldor language, it is part of a library and as such it could mean 
anything I like.

 > I am not suggesting compile time
> evaluation be extended to all static computations, but my guess is
> "primes" is special. A bit of compiler optimization would probably
> evaluate expressions like 2+3, so why not primes(1,100)?

To what should 2+3 evaluate? To the Integer 5? To the MachineInteger 5? 
To a sparse univariate polynomial 5? To 0 mod 5? It is awfully ambiguous 
and would in general involve more than just a call to the addition of 
machine size integers. I could have even overloaded + for 
MachineInteger. I guess, optimizing 2+3 to 5 is not even correct in some 
circumstances.

>> William is right, but I cannot believe that a construction like
>> 
>> [f(100, n) for n in [2,3,5]$List(Integer)]
>> 
>> would work.
> 
> The main reason why it is not working presently is because we have
> not constructed cartesian product over an arbitrary set of domains.
> But nothing in the language (even Spad) seems to prevent one from
> doing this.

Of course not, but note that you have a generator in the above 
construction and thus the compiler does not know the length of the tuple 
until it is *computed*. To make myself clear: I believe that one can 
write a constuctor for arbitrary tuples of variable length, but Martin's 
syntax to construct an element of such a type would not work. (Please 
convince me otherwise by providing running code.)

>> [f(100, n), f(100, n), f(100, n)]
> 
> You meant: [f(100,2), f(100,3), f(100,5)], I assume.

Of course.

>> should be easily definable and give an element in the cartesian 
>> product of   PF(2), PF(3), and PF(5). But that is a finite
>> construct and not done via Generator as above.
> 
> As discussed above, what is missing is cartesian product over an 
> arbitrary set of domains. If domains are first class objects, we
> should be able to construct sets of them, even via Generator, and
> hence also cartesian product.

Oh, yes, of course it is possible (even now) to construct a 
heterogeneous tuple type via Generator. But Martin's construction would 
mean to construct the type AND the element at the same time. And that (I 
believe) is impossible.

> At the very least, one should be able
> to form a set or list of domains of the same category (which IS
> homogeneous).

No problem in Aldor.

#include "aldor"
U: List PrimitiveType := [Integer, String, Character];

That is a completely valid Aldor program.

>> PFCartesian(k: Integer): with {
 >>     coerce: ((n: Integer) -> PF(n)) -> %;
 >>     ...
 >> }== add { ... }

> I am not following. Is PFCartesian(k) a cartesian product of the
> first k prime fields, like PFCartesian(3) is PF(2) x PF(3) x PF(5)?
> Then given a function (n:Integer)->PF(n) (basically, an sequence of
> elements, one from each PF(n), and n better be a prime! but let's
> pretend we interpret PF(n) as Integer mod n), the coerce function
> maps the anonymous function to PFCartesian(k) by using the first k
> elements in the sequence?

I was not thinking too much about it. I wanted that PFCartesian(7) 
stands for PF(2) x PF(3) x PF(5) x PF(7) and PF for PrimeField. And the 
coerce function basically turns the projection functions into an element 
of PFCartesian.

As representation I could choose

Rep == (n: Integer) -> PF(n);

But I still cannot make

[f(100, n) for n in [2,3,5]$List(Integer)]

into valid Aldor code if f is the function given by Martin.

Can you?

Ralf


From Bill.Page at drdc-rddc.gc.ca  Wed Aug 30 23:20:54 2006
From: Bill.Page at drdc-rddc.gc.ca (Page, Bill)
Date: Wed, 30 Aug 2006 23:20:54 -0400
Subject: [Aldor-l] [Axiom-developer] spad: language and compiler
In-Reply-To: <44F619AE.5020702@hemmecke.de>
Message-ID: <CAE9B164E720CE4D8727792DF8F28AE37D3682@corporateex02.Corporate.drdc-rddc.gc.ca>

On Wednesday, August 30, 2006 7:05 PM Ralf Hemmecke wrote:
> ... 
> As you know Record and Cross are two ways in Aldor to construct
> heterogeneous tuples. The problem is that both must have a 
> certain fixed length when you write them into your program.
> ...

What does "fixed" mean in this context?

> Martin's line contained a "for n in primes(1,100)" iterator, 
> so the type would only be known if the compiler were able to
> evaluate "primes(1,100)" at compile time.

>From our earlier discusion of 'random()' in the context of
Aldor types that are determined at compile-time, it seems
clear that it should be no problem to define a constant such
as

  P:List Integer == primes(1,100);

In fact, 'primes(1,100)' is a constant expression. As we
discovered, although P is a constant it's actual *value* is
only determined during run-time initialization, and then it
is fixed for the duration of the program execution. I recall
that you demonstrated in several programs that types in Aldor
(which must be constant) are also evaluated in exactly this
way.

At first I found this very surprising but now I am pretty
happy about it. :) That this is the case should not really
be so surprising considering that one of the target runtime
environments for Aldor is lisp!

Anyway I see no reason in principle for Aldor to reject
something like:

  [f(100,n) for n in P]::Cross(PF(n) for n in P)

where the bracket function is define by the Cross domain
constructor.

This is not the only type which satisfies Martin's original
example. Another possibility is:

  [f(100,n) for n in P]::List Union(n:PF(n) for n in P)

i.e. a List over a type union. This would be a more general
type than the cross product, but equally valid from a
conceptual point of view.

> ... 
> >> I cannot believe that a construction like
> >> 
> >> [f(100, n) for n in [2,3,5]$List(Integer)]
> >> 
> >> would work.
> > 
> > The main reason why it is not working presently is because
> > we have not constructed cartesian product over an arbitrary
> > set of domains. But nothing in the language (even Spad)
> > seems to prevent one from doing this.

I am afraid that there may indeed be such a restriction --
at least in SPAD. The problem is how and when the arity of
functions is decided. The arity is actually encoded into
the names given to the functions and as far as I know these
names *must* be decided strictly at compile-time.

The situation in Aldor might be different but I do not
understand in sufficient detail the actual FOAM that Aldor
generates.

> 
> Of course not, but note that you have a generator in the
> above construction and thus the compiler does not know the
> length of the tuple until it is *computed*.

Although the length is not known at compile-time, nontheless
it is fixed at run-time initialization. That is not an
unusual sitation in Aldor.

> 
> Oh, yes, of course it is possible (even now) to construct a 
> heterogeneous tuple type via Generator.

Really?

> But Martin's construction would mean to construct the type
> AND the element at the same time. And that (I believe) is
> impossible.
> ... 
> But I still cannot make
> 
> [f(100, n) for n in [2,3,5]$List(Integer)]
> 
> into valid Aldor code if f is the function given by Martin.
>

Probably what we need is some kind of recursive type constructor.
See for example:

http://www.cs.kent.ac.uk/people/staff/sjt/Atypical/AldorExs/vector.as

Something like ... ?

PFCartesian(k: Integer): Type 
    == if k<=1 then PF(1) else Record(fst:PF(k),rst:PFCartesian(k-1));

See also section 23.8 "Recursive Strurctures" page 324 of the
Axiom Library Compiler Users Guide, 1994:

www.ph.ed.ac.uk/~bj/paraldor/WWW/docs/documentation/axlugII.pdf

I hope to have more time some to work with these examples.

Regards,
Bill Page.



From ralf at hemmecke.de  Thu Aug 31 04:41:41 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Thu, 31 Aug 2006 10:41:41 +0200
Subject: [Aldor-l] [Axiom-developer] spad: language and compiler
In-Reply-To: <CAE9B164E720CE4D8727792DF8F28AE37D3682@corporateex02.Corporate.drdc-rddc.gc.ca>
References: <CAE9B164E720CE4D8727792DF8F28AE37D3682@corporateex02.Corporate.drdc-rddc.gc.ca>
Message-ID: <44F6A0C5.6010407@hemmecke.de>

On 08/31/2006 05:20 AM, Page, Bill wrote:
> On Wednesday, August 30, 2006 7:05 PM Ralf Hemmecke wrote:
>> ... 
>> As you know Record and Cross are two ways in Aldor to construct
>> heterogeneous tuples. The problem is that both must have a 
>> certain fixed length when you write them into your program.
>> ...
> 
> What does "fixed" mean in this context?

If you write Cross(A1, A2, ..., Ak) in your program with k types 
A1,...,Ak then the the k must be a natural number. Of course you can write

Cross(A1);
Cross(A1, A2);
Cross(A1, A2, A3);

but you cannot write

Cross [x for x in g]

for some Generator G and an appropriate definition of bracket.

Oh... maybe one can... but I am too lazy to check that you can write a 
bracket: Generator Type -> Tuple Type
and hand the result to Cross.

Anyway it doesn't solve the problem of having to generate the value and 
the type at the same time.


>> Martin's line contained a "for n in primes(1,100)" iterator, 
>> so the type would only be known if the compiler were able to
>> evaluate "primes(1,100)" at compile time.
> 
>>From our earlier discusion of 'random()' in the context of
> Aldor types that are determined at compile-time, it seems
> clear that it should be no problem to define a constant such
> as
> 
>   P:List Integer == primes(1,100);
> 
> In fact, 'primes(1,100)' is a constant expression. As we
> discovered, although P is a constant it's actual *value* is
> only determined during run-time initialization, and then it
> is fixed for the duration of the program execution. I recall
> that you demonstrated in several programs that types in Aldor
> (which must be constant) are also evaluated in exactly this
> way.

Oh, yes. Good remark.

> At first I found this very surprising but now I am pretty
> happy about it. :) That this is the case should not really
> be so surprising considering that one of the target runtime
> environments for Aldor is lisp!
> 
> Anyway I see no reason in principle for Aldor to reject
> something like:
> 
>   [f(100,n) for n in P]::Cross(PF(n) for n in P)
> 
> where the bracket function is define by the Cross domain
> constructor.

Interesting. That looks good, but is terribly wrong. Why? Because
    for n in P
accesses P destructively. Depending on what is evaluated first, either 
the Cross is essentially Cross() or the bracket is []. What language 
specification tells you the compiler should produce? (And both would be 
wrong anyway.)

>>>> I cannot believe that a construction like
>>>>
>>>> [f(100, n) for n in [2,3,5]$List(Integer)]
>>>>
>>>> would work.
>>> The main reason why it is not working presently is because
>>> we have not constructed cartesian product over an arbitrary
>>> set of domains. But nothing in the language (even Spad)
>>> seems to prevent one from doing this.
> 
> I am afraid that there may indeed be such a restriction --
> at least in SPAD. The problem is how and when the arity of
> functions is decided. The arity is actually encoded into
> the names given to the functions and as far as I know these
> names *must* be decided strictly at compile-time.

This is exactly what I meant by "fixed length" above.

>> Oh, yes, of course it is possible (even now) to construct a 
>> heterogeneous tuple type via Generator.
> 
> Really?

You want me to produce code, right? ;-)

>> But Martin's construction would mean to construct the type
>> AND the element at the same time. And that (I believe) is
>> impossible.
>> ... 
>> But I still cannot make
>>
>> [f(100, n) for n in [2,3,5]$List(Integer)]
>>
>> into valid Aldor code if f is the function given by Martin.

> Probably what we need is some kind of recursive type constructor.
> See for example:
> 
> http://www.cs.kent.ac.uk/people/staff/sjt/Atypical/AldorExs/vector.as
> 
> Something like ... ?
> 
> PFCartesian(k: Integer): Type 
>     == if k<=1 then PF(1) else Record(fst:PF(k),rst:PFCartesian(k-1));

Oh! Although it is done a bit different, you should take a look at the 
definition of RecursiveMultivariatePolynomial0. Do you have the sources 
of Aldor's LibAlgebra?

> See also section 23.8 "Recursive Strurctures" page 324 of the
> Axiom Library Compiler Users Guide, 1994:

> www.ph.ed.ac.uk/~bj/paraldor/WWW/docs/documentation/axlugII.pdf

> I hope to have more time some to work with these examples.

Oh, a definition of Tree... Not very exciting. We now have a way to 
construct a binary tree as a combinatorial species in aldor-combinat

svn co svn://svn.risc.uni-linz.ac.at/hemmecke/combinat/trunk

Look at the end of the file src/species.as.nw and you'll find the 
following definition for a tree...

BinaryTree(L: LabelType): CombinatorialSpecies L == {
         macro {
                 + == Plus;
                 * == Times;
                 1 == EmptySetSpecies;
                 X == SingletonSpecies;
                 B == BinaryTree;
         }
         (1 + X * B * B)(L) add;
}

But I have the suspicion that it is not the right code to construct 
heterogeneous products. Anyway, the interesting part in the BinaryTree 
definition is that at the same time of constructing the tree you get a 
function that generates all (labelled) trees of a given size and a 
function that counts trees of a given size (the generating function).

Ralf


From ralf at hemmecke.de  Thu Aug 31 06:16:54 2006
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Thu, 31 Aug 2006 12:16:54 +0200
Subject: [Aldor-l] [Axiom-developer] spad: language and compiler
In-Reply-To: <CAE9B164E720CE4D8727792DF8F28AE37D3682@corporateex02.Corporate.drdc-rddc.gc.ca>
References: <CAE9B164E720CE4D8727792DF8F28AE37D3682@corporateex02.Corporate.drdc-rddc.gc.ca>
Message-ID: <44F6B716.4050506@hemmecke.de>

> Probably what we need is some kind of recursive type constructor.
> See for example:
> 
> http://www.cs.kent.ac.uk/people/staff/sjt/Atypical/AldorExs/vector.as

If you look closer to that, then you see that vector.as is implementing 
"List" in a terribly complicated way.

Look at

-- Add up the entries of a Vector(n).
addVec(n:Integer,v:Vector(n)):Integer
     == {
     import from Record(fst:Integer,rst:Vector(n-1));
     if n<=1
           then 0
	  else vec.fst + addVec(n-1,vec.rst);
	  where { vec == (v pretend				-- A
	  		 Record(fst:Integer,rst:Vector(n-1))); }};

in particular look at the argument. If it were a list you could forget 
about the n, but here you have to give it. I am sure, nobody would ever 
use such code.

If you must have a union over Vectors of arbitrary lenght then a cleaner 
design would be to define vectors of lenght n and in a second step 
define operations on vectors of different length.

In aldor-combinat you would define that thing like in the BinaryTree 
example I gave before but just use the equation V = 1 + X * V.
And, by the way, I did not use "pretend" in my code.

Ralf


From wyscc at sci.ccny.cuny.edu  Wed Aug 30 06:15:54 2006
From: wyscc at sci.ccny.cuny.edu (William Sit)
Date: Wed, 30 Aug 2006 06:15:54 -0400
Subject: [Aldor-l] [Axiom-developer] spad: language and compiler
In-Reply-To: <9qhd02mhqc.fsf@login.mat.univie.ac.at>
Message-ID: <web-8253734@cgate.sci.ccny.cuny.edu>

On 24 Aug 2006 14:38:19 +0200
  Martin Rubey <martin.rubey at univie.ac.at> wrote:
>Ralf Hemmecke <ralf at hemmecke.de> writes:
>
>> > f(m: INT, n: INT): PF n == m::PF(n)
>that's OK.
>
>
>> > [f(100, n) for n in primes(1,100)]
>that's stupid.

Why? I would think it is an element (not a list) in a 
cartesian product of #primes(1,100) prime fields.

>> Ask yourself, what type that list will have and you 
>>realise that Aldor will
>> reject that its compilation.
>Excuse me, Gaby. Sorry about being so stupid.

It's a perfectly good mathematical object in a cartesian 
product.

>
>> > [a::P for P in L]
>> That is as problematic as the first list.
>"problematic" is an understatement. Sorry.

Ditto. The only problem I see that can't be handled is if 
you make it into a function of k:

[f(100, n) for n in primes(1,k)]

To have true dependent types means the compiler should be 
able to handle

[f(100, n) for n in primes(1,100)]

because the list primes(1,100) is computable at compile 
time and hence the prime fields can be constructed and 
their cartesian product too. prime(1,k) is a totally 
different ball game, but even that should be doable with 
generated code to instantiate the prime fields when k is 
given a value at run time.

William


From gdr at cs.tamu.edu  Wed Aug 30 06:15:57 2006
From: gdr at cs.tamu.edu (Gabriel Dos Reis)
Date: 30 Aug 2006 05:15:57 -0500
Subject: [Aldor-l] [Axiom-developer] RE:  Type: Type
In-Reply-To: <CAE9B164E720CE4D8727792DF8F28AE37D352E@corporateex02.Corporate.drdc-rddc.gc.ca>
References: <CAE9B164E720CE4D8727792DF8F28AE37D352E@corporateex02.Corporate.drdc-rddc.gc.ca>
Message-ID: <87lkp64jhe.fsf@soliton.cs.tamu.edu>

"Page, Bill" <Bill.Page at drdc-rddc.gc.ca> writes:

| On Tuesday, August 29, 2006 6:03 AM Gabriel Dos Reis wrote:
| >>> At the logical level, as I have observed some time ago, there
| >>> is an inconsistency problem with Type:Type.  I'm wondering how
| >>> Aldor gets away with that.  Many languages (mostly functional)
| >>> use stratified types.
| 
| On Tue, Aug 29, 2006 at 12:42:04PM +0200, Ralf Hemmecke wrote:
| >> Can you construct a paradox that demonstrates the problem in
| >> terms of Aldor code? To me it looks like the class (not set)
| >> of all classes. Would there be a problem in class theory?
| 
| On Tuesday, August 29, 2006 8:52 AM Stephen Watt wrote:
| > 
| > You are correct that there is a potential inconsistency.
| > 
| > We avoid Russel's paradox by limiting the operations for
| > constructing and testing membership in type categories.
| > ...
| 
| I think the fact that Aldor defines the type of Type as Type
| is very interesting from a theoretical point of view and that
| it is not correct to suggest that it implies any inconsistency
| or even necessarily any fundamental limitation.

I believe I need more explanations than the vague allusion to
co-inductive formalism.  Epigram, for example, faces the same issue, and
I don't think it is just mirage:

   http://www.mail-archive.com/epigram at durham.ac.uk/msg00038.html

-- Gaby


From gdr at cs.tamu.edu  Wed Aug 30 09:05:22 2006
From: gdr at cs.tamu.edu (Gabriel Dos Reis)
Date: 30 Aug 2006 08:05:22 -0500
Subject: [Aldor-l] [Axiom-developer] spad: language and compiler
In-Reply-To: <44F5812B.1040205@mcmaster.ca>
References: <web-8253734@cgate.sci.ccny.cuny.edu>
	<44F5781B.4000103@hemmecke.de> <44F5812B.1040205@mcmaster.ca>
Message-ID: <87ac5m4bn1.fsf@soliton.cs.tamu.edu>

Jacques Carette <carette at mcmaster.ca> writes:

| Ralf Hemmecke wrote:
| > Compile time evaluation in full 
| > generality introduces a way make it really hard to find bugs.
| >
| > But anyway, maybe Aldor should allow compile time evaluation.
| >   
| Quick remark --  it has been shown that:
| 1) C++'s template language is a Turing Complete PL
| 2) Haskell's class types (with common extensions) is also a Turing 
| Complete PL
| 3) All meta-programming systems allow arbitrary compile time evaluation
| 
| Yes, it does make debugging harder.  But the advantages seem to _far_ 
| outweigh the problems.  One just develops new debugging (and coding) 
| techniques to deal with the added power/complexity.
| 
| I could re-use Stephen's brilliant closing line from yesterday's email:
|     "These kinds of errors have to be seen as bugs in programs, just as 
| division by zero is a programming error and not an invalidation of 
| integer arithmetic." -- S.M. Watt
| [where 'These kinds of errors' is now /Programs with infinite loops in 
| types/]

I agree with most of what you said.  However, the slogan "well-typed
programs don't go wrong" does some value that I would heisate to
compromise...

-- Gaby


From gdr at cs.tamu.edu  Wed Aug 30 13:25:25 2006
From: gdr at cs.tamu.edu (Gabriel Dos Reis)
Date: Wed, 30 Aug 2006 12:25:25 -0500 (CDT)
Subject: [Aldor-l] [Axiom-developer] spad: language and compiler
In-Reply-To: <44F5C831.3070106@mcmaster.ca>
References: <web-8253734@cgate.sci.ccny.cuny.edu>
	<44F5781B.4000103@hemmecke.de>
	<44F5812B.1040205@mcmaster.ca> <87ac5m4bn1.fsf@soliton.cs.tamu.edu>
	<44F5C831.3070106@mcmaster.ca>
Message-ID: <Pine.GSO.4.58.0608301223280.4041@sun>

On Wed, 30 Aug 2006, Jacques Carette wrote:

| Gabriel Dos Reis wrote:
| > I agree with most of what you said.  However, the slogan "well-typed
| > programs don't go wrong" does some value that I would heisate to
| > compromise...
| >
| But well-typed programs can still diverge!  So "go wrong" just means
| that _when_ they return a value, it is guaranteed to be of the right type.

No dispute there.

With Type:Type, it is not clear to me that when a well-typed
expression does not diverge, its value is not "wrong".

-- Gaby


From gdr at cs.tamu.edu  Wed Aug 30 15:04:11 2006
From: gdr at cs.tamu.edu (Gabriel Dos Reis)
Date: Wed, 30 Aug 2006 14:04:11 -0500 (CDT)
Subject: [Aldor-l] [Axiom-developer] spad: language and compiler
In-Reply-To: <CAE9B164E720CE4D8727792DF8F28AE37D3642@corporateex02.Corporate.drdc-rddc.gc.ca>
References: <CAE9B164E720CE4D8727792DF8F28AE37D3642@corporateex02.Corporate.drdc-rddc.gc.ca>
Message-ID: <Pine.GSO.4.58.0608301403190.4041@sun>

On Wed, 30 Aug 2006, Page, Bill wrote:

| But I supposed Gaby would claim that these are still more
| "vague allusions to co-inductive formalism" ;) Oh well...

I hope we would make progress with scientific skepticism :-)

-- Gaby


From wyscc at sci.ccny.cuny.edu  Wed Aug 30 17:51:42 2006
From: wyscc at sci.ccny.cuny.edu (William Sit)
Date: Wed, 30 Aug 2006 17:51:42 -0400
Subject: [Aldor-l] [Axiom-developer] spad: language and compiler
In-Reply-To: <44F5781B.4000103@hemmecke.de>
Message-ID: <web-8259658@cgate.sci.ccny.cuny.edu>

On Wed, 30 Aug 2006 13:35:55 +0200
  Ralf Hemmecke <ralf at hemmecke.de> wrote:
>>>>> f(m: INT, n: INT): PF n == m::PF(n)
Martin's expression:
>>>>> [f(100, n) for n in primes(1,100)]
>>I would think it is an element (not a list) in a 
>>cartesian product of #primes(1,100) prime fields.
>
>OK, if you like. But then I would like to see the 
>definition of the bracket function. Can you give that?

One main difference between list of mathematical objects 
and say C++ objects is that the former is often 
homogeneous (elements of the list are of the same type) 
but the latter is often heterogeneous (elements need not 
be of the same type). In Axiom, all lists are homogeneous 
(even List Any) by definition of the domain List (or the 
domain Tuple). A variant that allows hetergeneous objects 
in a "list" is the domain Record. The bracket constructor 
is by default the list constructor but can be used to 
construct elements of Record. But since Record must have 
pre-defined named fields, Martin's line could not have 
meant a Record element. It certainly is not a list in the 
Axiom sense. So the remaining possibility is an element of 
a cartesian product. Axiom currently has a constructor for 
cartesian product of two sets: Product, where elements are 
constructed using the function makeprod. But here, we are 
not discussing existing domains, but rather whether 
Martin's expression is mathematically meaningful and 
whether the language allows its construction in Aldor. 

Getting back to your question, it is up to the programmer 
to define the bracket function for the domain where 
Martin's expression lives. Even though it may not be 
possible in Axiom to directly program tuples of 
heterogeneous domains, such tuples are present in most 
function signatures like foo:(INT, Boolean)->INT. I would 
expect Aldor therefore to be able to directly program 
tuples of heterogeneous domains. Thus Martin's expression, 
perhaps using round parentheses instead of brackets, 
should work in Aldor.

>I strongly believe you can't, because that would require 
>Aldor to compute "primes(1,100)" at compile time. Which 
>is currently not possible and if the compiler is allowed 
>to evaluate it then it might run into an infinite loop 
>(at compile time) since the "primes" function does not 
>terminate as you would expect. Compile time evaluation in 
>full generality introduces a way make it really hard to 
>find bugs.

I don't know how "primes" is implemented but it is 
probably a built-in using both a table for lower range and 
some sophisticated algorithms for higher ones. I am not 
suggesting compile time evaluation be extended to all 
static computations, but my guess is "primes" is special. 
A bit of compiler optimization would probably evaluate 
expressions like 2+3, so why not primes(1,100)? Obviously, 
compile time evaluation should be severely restricted 
(otherwise many programs may compile to just the output if 
no input is required).

>But anyway, maybe Aldor should allow compile time 
>evaluation.
>
>>>>Ask yourself, what type that list will have and you 
>>>>realise that 
>>>>Aldor will
>>>>reject that its compilation.
>>>Excuse me, Gaby. Sorry about being so stupid.
>>
>>It's a perfectly good mathematical object in a cartesian 
>>product.
>
>William is right, but I cannot believe that a 
>construction like
>
>[f(100, n) for n in [2,3,5]$List(Integer)]
>
>would work.

The main reason why it is not working presently is because 
we have not constructed cartesian product over an 
arbitrary set of domains. But nothing in the language 
(even Spad) seems to prevent one from doing this.

>[f(100, n), f(100, n), f(100, n)]

You meant: [f(100,2), f(100,3), f(100,5)], I assume.

>should be easily definable and give an element in the 
>cartesian product of   PF(2), PF(3), and PF(5). But that 
>is a finite construct and not done via Generator as 
>above.

As discussed above, what is missing is cartesian product 
over an arbitrary set of domains. If domains are first 
class objects, we should be able to construct sets of 
them, even via Generator, and hence also cartesian 
product. At the very least, one should be able to form a 
set or list of domains of the same category (which IS 
homogeneous). Something like:

Product(A: List PrimeField, B: List) 

where B is the index "set." Or, as you did below, using an 
anonymous function as the argument.

>>>>> [a::P for P in L]
>>>>That is as problematic as the first list.
>>>"problematic" is an understatement. Sorry.
>>
>>Ditto. The only problem I see that can't be handled is if 
>>you make it into a function of k:
>
>>[f(100, n) for n in primes(1,k)]
>
>Initially, I believe, Martin wanted lists. What you are 
>calling for is a cartesian product constructor of the 
>form.
>
>PFCartesian(k: Integer): with {
>     coerce: ((n: Integer) -> PF(n)) -> %;
>     ...
>}== add {
>     ...
>}

I am not following. Is PFCartesian(k) a cartesian product 
of the first k prime fields, like PFCartesian(3) is PF(2) 
x PF(3) x PF(5)? Then given a function (n:Integer)->PF(n) 
(basically, an sequence of elements, one from each PF(n), 
and n better be a prime! but let's pretend we interpret 
PF(n) as Integer mod n), the coerce function maps the 
anonymous function to PFCartesian(k) by using the first k 
elements in the sequence?

>Then instead of [f(100, n) for n in primes(1,k)] it would 
>be more appropriate to define
>
>k: Integer == << stdin; -- read from standard input and 
>make it constant
>foo(m: Integer)(n: Integer): PF(n) == m :: PF(n);
>import from PFCartesian(k);
>z := foo(42) :: PFCartesian(k);
>
>Such a construction would work, but it does not involve a 
>Generator or something that you must compute at compile 
>time.

The construction of the domain PFcartesian(k) might, even 
when k is given at instantiation time, depending on the 
meaning of that domain.

William


