Dear Bas,<br><br>Thank you a lot for your long reply. It clarified a lot of things.<br><br>Below please find response to the previous email, and three new questions.<br><br><div class="gmail_quote">2011/4/4 Bas Lijnse <span dir="ltr"><<a href="mailto:b.lijnse@cs.ru.nl">b.lijnse@cs.ru.nl</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div bgcolor="#ffffff" text="#000000">
Hi Mikael,<br></div></blockquote><div class="im"><br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">
I have done my best to answer my questions, so I think it is only
fair to ask one in return ;)<br>
Where did you look for this information before turning to the
mailinglist?</blockquote><div><br>I googled all I could.<br>
<br>While the information available out there is sparse, one of the more clear reviews I found was this one:
<a href="http://fpmatters.blogspot.com/2009/04/clean-programming-language-insanely.html">http://fpmatters.blogspot.com/2009/04/clean-programming-language-insanely.html</a><br>
<br>
Unfortunately, it states there's no FFI and no stack traces, which is not correct, so I believe it should be corrected.<br>
</div><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">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.<br></blockquote><div><br>Yes please do this, it's of highest value for Clean.<br></div>
<br> <br>
<blockquote type="cite">
<b>Live coding, debugging</b><br>
* 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?<br>
</blockquote></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div bgcolor="#ffffff" text="#000000">
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.<br>
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)</div></blockquote><div class="im"><br>Did it need any maintenance to be kept up to date?<br><br>To have an interactive shell with the environment sounds like a very useful feature to me, why take it away?<br>
<br>In all cases, how did it work - do you have any console interaction log anywhere that shows a session of its use?<br><br>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?<br>
<br>
<blockquote type="cite">
<b>License</b><br>
* Is the licensing LGPL or commercial also today? Furthermore:<br>
</blockquote></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div bgcolor="#ffffff" text="#000000">
I think the license is still the same.</div></blockquote><div><br>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.<br>
<br>I believe this is really a key issue for Clean, that the license needs to be open for any use.<br><br>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.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div bgcolor="#ffffff" text="#000000"><div class="im">
</div><div class="im"><blockquote type="cite">
* Is there any intent to release Clean's environment as BSD or
MIT i.e. a completely open-sourced license?<br>
</blockquote></div>
I would be in favor. I am not sure what the plans are.</div></blockquote><div><br>Who is planning this?<br> <br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
<div class="im"><blockquote type="cite">
<b>Portability<br>
</b> * 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?<br>
</blockquote></div>
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</div></blockquote><div><br>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?<br>
</div><div><br><br><br><br><b>Compiler backend language support</b><br>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?<br>
<br>If so, where in the compiler's code are the hooks and other places where such an alternative backend could be implemented?<br></div></div><br><br><b>General architecture as regards environment requirements (processor, OS, C compiler)</b><br>
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:<br><br>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.<br>
<br>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.<br>
<br>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.<br><br>So something like,<br><br> * 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 -<br>
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.<br>
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.<br><br> * 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.<br>
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.<br>
It becomes a language only for a very limited scope of use.<br><br> * 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.<br>
<br> * 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.<br> 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.<br>
<br><br>What do you view as your current and future status about this, do you view this kind of portability as a goal?<br><br><br><b>Number types</b><br>If I got the language spec right, the number types there are are Int and Float and that's it.<br>
<br>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)?<br><br>Having Int and Float separate and Bignum as a separate language can make the code for basic calculations quite messy.<br>
<br><br><br><br>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.<br><br>Thanks,<br>Mikael<br><br>