Lambda the Ultimate

As a LtU junkie, I've learnt a lot from the discussions that LtU editors bring up and I've been hacking away trying to implement some "fairly modern" concepts in a scheme-based open-source scripting language muSE. The latest hacks are in the processes branch and include the following -

• Erlang-style message passing processes
• Concurrency management using (atomic ...) blocks
• Resumable exception mechanism
• Exception handler choice using argument pattern matching
• Support for guards in patterns

Some basic description of this stuff is available from the muSE blog page. This is public code that's there for anyone interested in exploring lisp-based expressions of such functionality. Comments, suggestions, questions, brick bats, rotten eggs, all are welcome.

Notes: You'll need MS VC++ Express edition in order to build a muSE interpreter. "Solution" files are available from the above mentioned branch. Currently only MS Windows+Intel combination is supported [.. ducking to avoid laser beams! ..]

I'm trying to learn lisp. I've been reading some of Paul Graham's stuff and he has convinced me of its coolness :) So anyway, I'm totally lost. I'm using gcl (Gnu Common Lisp) under Gentoo. I tried to get sbcl and cmucl but they didn't compile. My basic issue is simple - how do I make a binary executable with gcl? My test program is just this.

(format t "hello lisp")

This file is called 'hw.lisp', I've managed to create an object file but do not know how to link it to make a binary. I'm just doing this in the interactive gcl session

(COMPILE-FILE "hw.lisp")

Now that gives me the 'hw.o' file but how to link it? Or is there a way to just go straight to the executable? I've looked online but the gcl docs are rather sparse.

Attempto Controlled English (ACE)

Though formal methods promise improved quality of software and partial automation of the software development process they are not readily accepted by domain specialists. This applies particularly to formal specifications that are at the very basis of any formal software development. The reasons are twofold -- formal specifications are hard to understand and difficult to relate to the concepts of the application domain. ...

In brief, an ACE specification is formal and at the same time "explains what the specification means in real-world terms and why the specification says what it does".