[clean-list] Queries for introduction to Clean's language and environment

[John van Groningen]

Dear Mikael,

On 6-6-2011 13:37, You wrote:
>..
>> *Live coding, debugging*
>>  * Is there anything like a REPL / live code environment? I understood
>> Hilde should do this, where do I find its executable? Does it have any
>> particular limitations?
>
>     Clean has no live interpreter. Hilde is an interactive shell that
>     let's you define and evaluate clean expressions. So it is very close
>     to an interactive code environment. I don't know the details exactly.
>     You can find Hilde in the Libraries folder of the Clean 2.2
>     distribution. (It was removed in the 2.3 distribution because it is
>     no longer maintained)
>
>
> Did it need any maintenance to be kept up to date?

It can only be used on 32 bit Windows, because it uses the dynamic
linker (which is only available on that platform).

> To have an interactive shell with the environment sounds like a very
> useful feature to me, why take it away?
>
> In all cases, how did it work - do you have any console interaction log
> anywhere that shows a session of its use?
>
> How did it work under the hood, for instance did it re-process all the
> involved ABC code for each command it was fed with? What was/is its
> primary limitations?

See:

Rinus Plasmeijer, Arjen van Weelden. A Functional Shell that Operates on 
Typed and Compiled Applications. In Vene, V., Uustalu, T. Eds. 5th 
International School on Advanced Functional Programming, AFP2004, Tartu, 
Estonia, August 14-21, 2004, Revised Lectures. Springer, LNCS 3622, 
pp.245-272.

http://www.st.cs.ru.nl/papers/2004/plar2004-Esther_AFP.pdf.

and:

Arjen van Weelden, Rinus Plasmeijer. A Functional Shell that Dynamically 
Combines Compiled Code. In Michaelson, G., Trinder, Ph. Eds. Proceedings 
15th International Workshop on the Implementation of Functional 
Languages, IFL 2003, Selected Papers, Edinburgh, Scotland, September 
8-10, 2003, Springer, LNCS 3145, pp.36-52.

http://www.st.cs.ru.nl/papers/2004/vWeA2004-Esther.pdf

>> *License*
>..
>
>>         * Is there any intent to release Clean's environment as BSD or
>>     MIT i.e. a completely open-sourced license?
>     I would be in favor. I am not sure what the plans are.

We will use a FreeBSD style license for the libraries and runtime system
for the next release (instead of LGPL).

>>     *Portability
>>     * * Is Clean completely locked to Windows and Linux, or can all
>>     non-GUI-parts be fully utilized on all other supporting systems
>>     such as Mac OS X, BSD and IPhones?
>     It is not locked to Windows and Linux per se. Platform availability
>     is mostly a matter of manpower. There is an alpha version of a Mac
>     OS X compiler being tested currently. BSD would not be problem.
>     Iphones are a bit more difficult because they would require a code
>     generator for t
>
> Aha, so the code generation flow is Clean -> ABC bytecode -> x86
> executable binary code image .. or is it Clean -> ABC bytecode -> C code
> with some assembly inlining?

It is Clean -> ABC code -> machine code (object files) -> executable file

We have our own code generator and do do not use a C compiler to 
generate code.

> *Compiler backend language support*
> Is the compiler constructed in such a way that it would be feasible to
> make a backend to another language, such as Javascript, so that Clean
> code would be compiled to it instead of ABC code?

Why compile to an interpreted language like Javascript ? If the
performance of an interpreter is acceptable, it would probably
be easier to write an ABC interpreter or use a byte code interpreter 
written in a compiled language like C or Java.

Such an approach is used by SAPL:

Jan Martin Jansen, Pieter Koopman, Rinus Plasmeijer. From Interpretation 
to Compilation. In Horváth, Plasmeijer, Soós, Zsók, Eds. 2nd Central 
European Functional Programming School, CEFP 2007, June 23-30 2007, 
Cluj-Napoca, Romania. Springer LNCS 5161, pp. 286-301, 2008

http://www.st.cs.ru.nl/papers/2008/janj08-CEFP07-InterpretationToCompilation.pdf

> If so, where in the compiler's code are the hooks and other places where
> such an alternative backend could be implemented?

There are several options, use the .abc file, replace the backend.dll
or add some code to the compiler to get the syntax tree.

> *General architecture as regards environment requirements (processor,
> OS, C compiler)*
> Here is an a bit wider reflection. Possibly you already took all of this
> into consideration though just in case I wanted to address it anyhow:
>
> I get the impression from the Clean implementation that it (the compiler
> + IDE etc) was first made for Windows and then was ported from there to
> other platforms (Linux, MacOsX etc), and that in this process, certain
> aspects of the implementation's design still reflects this at a quite
> fundamental level.

No, our first main development platform was Mac OS with 680x0 
processors. The first port was a command line version for Sun OS.
The GUI library and tools were ported to OS/2 and later to Windows. Some 
other ports used Sparc or PowerPC processors.

> I.e., the target environment was Windows which always has a GUI, has
> special non-BSD non-Unix MS-specific OS API:s, and has lots of
> pecularities and constraints in the OS construction that Unix platforms
> don't have.

All OS's have peculiarities and constraints.

> If you want to make a programming environment for a more general use, it
> would appear most logical to build it on as general and well-made
> foundations as possible.
>
> So something like,
>
>   * Have the compiler as a standalone console app.

CleanCompiler.exe is a standalone console app (compiles Clean to a .abc
file), CodeGenerator.exe is a standalone console app (generates an
object file from an .abc file) and so is the linker.

> Document it well,
> with its command line arguments and all. Don't presume people will use
> Clean's IDE -

We don't, a command line tool is used on *nix to compile Clean programs: 
clm. And with --batch-build the IDE can be used to compile
from the CMD shell. We intend to make a command line tool that can do 
this on all platforms.

>       While it is a reasonable goal for you to make the world's best
> Clean compiler, I would not believe it's reasonable that you can
> maintain an IDE that would be and remain the primary choice of IDE for
> any Clean developer.

You don't have to use the CleanIDE.

>       So maintain a clear communication that the IDE is really optional
> and that the primary value the user gets from Clean is the language spec
> and the compiler.
>
>   * Have all of the compiler's and the standard library's code written
> purely in standard C, so that it compiles on any C compiler and any OS
> architecture.

That is not sufficient because you still need to port the code generator.

>       If you have automatic binary code generation, keep it as an
> optional extra feature. This is an important point as that if something
> as general as a programming language cannot be used on a certain C
> compiler or platform or combination of those (XBox, any ARM machine,
> etc.), this decreases the value of the language a lot.
>       It becomes a language only for a very limited scope of use.

Unfortunately C is not a very good target language for Clean (problems
caused by lack of tail call optimization, garbage collection, no
global register variables, inefficient calling convention (ia32)).

>   * Make the compiler and standard library max cross-portable, by only
> using OS calls that are in the POSIX spec and available on pretty much
> any platform, without any need of porting work to support it.

A port of just the compiler and runtime system is usually not that
much work. Unfortunately without any libraries and tools often not very 
useful.

>   * Have a clear separation in your communication (documentation,
> packages etc.) between general (i.e. language spec + compiler + basic
> runtime library) and more non-general stuff such as UI libraries and IDE:s.
>       While UI libraries and IDE:s come and go in such a way that it's
> not a realistic goal to make the best one on earth of it, it is a
> realistic goal to make a programming language spec that will last over
> the years, and a cross-portable compiler that will deliver on pretty
> much any current, future and past platform.

> What do you view as your current and future status about this, do you
> view this kind of portability as a goal?

We try to make Clean available on as many platforms as possible, but our 
resources are limited.

> *Number types*
> If I got the language spec right, the number types there are are Int and
> Float and that's it.

Real is a double, not a float.

> Do you plan to maintain it like this,

Yes.

> or may you be interested in
> creating some kind of universal number type (a number tower with
> integrated support for fixnums / flonums / complex numbers / bignums / etc)?

Almost all of this can be done a library. We could add some support to
the compiler for numeric literals.

> Having Int and Float separate and Bignum as a separate language can make
> the code for basic calculations quite messy.

However, accidentally using a Bignum instead of an Int can make my code 
very slow, using a floating point value as array index is usually an error.

> With all of this said, thank you for making Clean. It is made in a very
> interesting area of programming languages and programming in general.

Thank you,

John van Groningen