[Re: Open Clean Source]

[Ana Maria Abrao]

This email is by Alex and Eduardo, since Ana is not here to
give her own comments.

OLIVIER LEFEVRE wrote:
>

> Excuse me but this strikes me as pure paranoia. There are a dozen of
> Scheme implementations, 4 or 5 or Haskell and ML and one has yet to
> hear any of the implementors complain that implementation xyz (you
> know, the one from these _other_ people) is giving them and the
> whole field a bad reputation.

It is interesting to note that the implementations that you cite do
give a bad reputation to Scheme, Haskell and ML. More than that!
They give a bad reputation to the whole field of functional
programming and symbolic manipulation. Every body says that
functional languages (symbolic languages) are slow and inefficient.
The reason: Bad experience with LISP, Scheme and ML compilers.
It is interesting to observe that most people don't believe 
that Clean is fast, because of previous experience with slow
Scheme,  and SML compilers.

We think that Scheme is not that hard to implement. 
At least, Scheme is easier to implement than Clean. 
Of course we may be wrong, because we are
not experts in compiler construction. It is possible that Scheme
is much harder to implement than Clean. We got almost every Scheme
compiler we could find for free or for a price: 
Rabit, Orbit, Chez Scheme, T, MIT Scheme, Gambit, Kawa, etc.  
All compilers generate slow code
(at least four times slower than the slowest C compiler; ten times
is the rule), consumes a lot of memory, and generate huge executables. 

Let's consider ML. We will not speak about OCAML, because we don't
know the compiler (we never could make it work). Let's talk about
SML/NJ and Harlequin. They do have a deserved reputation for
being slow. These two compilers generate code which is about
four times slower than the code generated by gcc.

Haskell is another story. There is a joke going around that
you need an installed Haskell compiler to compile part of the
libraries, and you need the libraries to install Haskell. The
happy few who succeeded in installing the compiler say that
it is fast, even faster than Clean. However, for most people,
a Haskell compiler is like the nun's ear in that famous
joke: Everybody knows that it is there, but nobody has seen it.
As for the Haskell's code... well Champolion has spent 12 years 
to decifer the hieroglyphic script. 
We think that the published source of Haskell is almost
as difficult to decifer as that. Since we don't have
12 years, we are not interested.

>> As you fear, if you open the sources, Clean team may be forced 
>> to give long explanations about the workings of the compiler,

> Please explain how anyone could _force_ them to??? 

Well, the Clean team has commited itself to give us support.
Then, they are forced by their own commitment. I suppose that
people who ask for the source want somebody to provide support.
Clean team is having a hard time in providing support for
their libraries and language. It is a long time since they
added the last entry in that book on Functional Programming 
in Clean. They never finished the chapters on 
Relational Databases, Editor writing and     Compression.
We would rather have them improving their support to
the language and libraries than increasing the number
of users, who need support.

Our suggestion is that they choose a small number of
partners, and perform a transference of technology to them.
These partners could help in developing the language,
could help in the documentation, and could answer questions
from users. Besides this, if the members of the Clean
team decide to give up the compiler construction business and
open an academy of martial arts (like Ana), the users
will have back up centers of support. The language will not die,
like Trilogy.

> The primary purpose of programming language research is to add to the
> body of knowledge about such languages, not to serve the particular 
> needs of any user group, much less to apease unfounded fears.

If the Clean team thinks like you (that language research is to add
to the body of knowledge about such languages), then you are
right: They should open the sources. The open sources could help
in the development of Haskell, for instance. It could even unify
the two languages. I think that if the Haskell team could lay
hold of things like the ABC machine, they could produce a faster
(compile time) and smaller compiler. Besides this, Haskell would
benefit from unique types, faster matrix manipulation, and a
unifying GUI. We would appreciate a small and fast Haskell
compiler. However, I am not sure whether Clean team wants
only to add to the body of knowledge about functional languages.


> PS: Lest some readers should feel I am taking too much space on this 
>list :-), I want to point out that this will be my last posting on 
> the topic.

I think that everybody liked your postings, since a lot of people
posted replies to them. Then, please, don't stop from bringing
interesting issues to our discussions. Postings like this brings
life to the list.



Alex
Eduardo Costa