Lambda the Ultimate

Hello,

I'm currently designing an intermediate programming language, with its virtual machine and compiler. The goal is to provide language designers a common runtime framework easy to target, well optimized, and a good set of librairies.

The language is designed to support a wide kind of semantics and type systems (static and dynamic) and offers all together imperative, OO, and functional features. It might be quite easy to generate from your favorite language to this intermediate language. This way, you can use either a safe small and embedable VM or a full speed JIT to run the code.

For reusing the libraries, you might have to write some wrappers for your language semantics but that's still less work than doing C/C++ FFI.

I'm planing to release soon the full specifications of the language with an OCaml toy interpreter, and will welcome any comments. VM and JIT will follow later.

But before that, what do you think about this project ? Will you feel like using this runtime system ? and what kind of features are you excepting to be in the specs ?

By itself, this paper is not related to PLT. However, it is interesting to observe how an idea of "types up to isomorphism" manifests itself in different communities - called data equivalence of (nested) relational schemes in this paper.

I wonder, how reformulation of the paper in CT terms would look like, and whether it will be data-equivalent to the original :-)

Restructuring Partitioned Normal Form Relations Without Information Loss

PS: I hope this is not too much off-topic.

During a discussion on the subject of passion in programming, David Bremner on #haskell pointed out Richard Hamming's 1986 talk You and Your Research. Here's a taste:

At Los Alamos I was brought in to run the computing machines which other people had got going, so those scientists and physicists could get back to business. I saw I was a stooge. I saw that although physically I was the same, they were different. And to put the thing bluntly, I was envious. I wanted to know why they were so different from me. I saw Feynman up close. I saw Fermi and Teller. I saw Oppenheimer. I saw Hans Bethe: he was my boss. I saw quite a few very capable people. I became very interested in the difference between those who do and those who might have done.

Hamming clearly describes both the difference between the two and how you can be one of those who do.

I wasn't too sure if this was the best place to come with a question like this, but I don't have many (ok any) contacts in the Lisp (CL or Scheme) world that are as well informed and opinionated as the readers of this site.

I have read many times that the programming environments of the Symbolics machines were some of the best environments to work in when programming in Lisp. To my surprise, I haven't seen any modern environments attempt (or currently attempting) to reach this level of productivity. Or if they are attempting there is a magic missing from them. But more importantly I haven't seen any commercial company attempting the development of such an editor.

Now mind you my experience with these environments is less than 'nil considering the fact that the only reference I have to go off of are the Rainer videos. I feel like a kid trying to experience the true magic of the Wild West by only watching John Wayne movies. But I can deal with the lack of experience, but a commercial project cannot not be done without the voice of experience and/or customers. This is where some help you the readers of this site can possibly help me, if willing.

I have two problems, one is the runtime. My first instinct jumps to mzscheme, because of its rather large install base across universities. I truly enjoy programming in Scheme, and see many competitors in the CL market that I am not to sure I could contend with. So my first question, with consideration from a strictly pragmatic viewpoint, is which environment is better for the user, or rather which language is better suited for what job. I know people have their preferences, but I guess I would like to know why they lean one way or the other. Or if both are used, which language is used for which types of jobs.

The second question concerns the graphical front end (more appropriately the 'product' piggy-backing on the language). I was enchanted with the graphical environment of the Symbolics machines, and just recently discovered that this set of widgets was a standard called CLIM. I also recently found out that McCLIM is a nice project that is working to create a LLGPL version of the standard.

As you can imagine finding this only put more decisions into my head. The choice was easy when I was only dealing with MrEd. I am looking for recommendations as to which road to travel, or rather to present some options I may not be seeing. On one side I feel that I could use MrEd, and strictly develop the entire environment in Scheme using its libraries. I am sure that I could use the FFI to call CL environments if the customers wished us to offer a CL version of the editor. My concern (due to lack of experience with MrEd) is that I won't be able to get the same 'Symbolics magic' from MrEd that may be possible with CLIM.
On the other hand, it is also possible to develop the editor using CLIM and CL, and use the CL's FFI implementation to call mzscheme to evaluate Scheme code. Both are viable solutions, but I see a bigger problem.

The Lisp family of languages grants much power to its user on a metalevel. This was the main reason for me wanting such an environment; no IDE developer has been able to guess every need I have (hell I don't even know until I know) so I wanted a programmable environment like those of the past (the ones everyone seems to rave about). The bigger problem I mentioned above, when using the combined language is approach, is that potential loss of programmability. If the editor is in CL and I am only offering a Scheme product, then its possible that the editor wouldn't be programmable (without a CL environment thrown in as well) which defeats the purpose of working on such an editor.

I do apologize for the length of this posting and if the content is not suited towards this site. Thank you for taking the time to read it, and I appreciate any constructive comments or advice you may have.

Best Regards,

MJ Stahl