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

[Mikael]

Dear Bas,

Thank you a lot for your long reply. It clarified a lot of things.

Below please find response to the previous email, and three new questions.

2011/4/4 Bas Lijnse <b.lijnse at cs.ru.nl>

>  Hi Mikael,
>

I have done my best to answer my questions, so I think it is only fair to
> ask one in return ;)
> Where did you look for this information before turning to the mailinglist?


I googled all I could.

While the information available out there is sparse, one of the more clear
reviews I found was this one:
http://fpmatters.blogspot.com/2009/04/clean-programming-language-insanely.html

Unfortunately, it states there's no FFI and no stack traces, which is not
correct, so I believe it should be corrected.


> Maybe I can put more of this info on the wiki and add links in the right
> places, so you could have found it online.
>

Yes please do this, it's of highest value for Clean.



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

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?

 *License*
 * Is the licensing LGPL or commercial also today? Furthermore:

I think the license is still the same.
>

Please consider switching the license to a free one (i.e. MIT or BSD), and
you'll open the gates for an exponentially much larger community to join in.
If you are interested in profits, then make a business model around
commercial support, and soon you'll have more income than you'd have gotten
from commercial licenses in the first place anyhow.

I believe this is really a key issue for Clean, that the license needs to be
open for any use.

Your documentation states the fee for a commercial license is 75€. This
would soon be paid back by a startup fee on the commercial support, or by
voluntary donations, or by another business model.

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

Who is planning this?


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




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

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


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

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.

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

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

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


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

Do you plan to maintain it like this, 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)?

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




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.

Thanks,
Mikael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/clean-list/attachments/20110606/27000b5a/attachment.html>