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
_______________________________________________
clean-list mailing list
[email protected]
http://mailman.science.ru.nl/mailman/listinfo/clean-list
