Lambda the Ultimate

The implementation department is for language implementation issues, like garbage collection, compilers etc.

I am interested in the bit on the end about "simulating subroutine behavior", though.

It wasn't quite clear to me what was going on... is there session state being stored on the server, or does the code that generates the URL add state to it?

A sample screenshot of the theoretical "Edit Person" form would be usefull too.

So, for example, you could generate code that would make a "checkout page" that took an item that had been bought as a parameter. This code is stored on the server under a hash value. The client is sent a page of products; selecting a product posts a request to teh server with the hash + the selected product code. The server then digs out the code, passes the product code, and generates the appropriate checkout page

See the link I posted yesterday for continuation passing - it's the same idea.

Excellent link, thanks!

The bit about using keyword functions is a key thing. When doing layout code is is VERY VERY USEFUL to be able to change the parameters without breaking the existing displays. You don't want to be changing function signatures and having to comb through every use you in your display code, since nothing is actually being calculated.

As I said earlier I'd asked on the Haskell group for comments and the general feeling was that higher order functions can do much of what macros do (at a similar cost).

Certainly, the first reason for Lisp in the article - the vague comments about recursion - apply equally well to functions.

However, the RTML hack (in the positive sense of that word) is very much a Lisp solution. The Lisp reader (parser) and syntax together provide a very neat way of instantly implementing "embedded languages". To do this in any other FPL would require writing a parser of some kind (not such a big deal compared to imperative languages - see almost any introductory FPL book - but not completely trivial).

This, more than macros, seems to be the big plus of Lisp - the close integration of data and code (which, of course, is closely connected with macros, but would exist even without them).

OTOH, RTML turned out to not be as useful. The structure editor could equally well have manipulated some kind of functional composition, I suspect.

Hmmm. Interesting. Personally, while I like Lisp, I much prefer the straight-jacket of static typing (it fits my "rely on the compiler" programming style!). I was hoping that I could persuade myself that statically typed FPLs were equally powerful, but I'm not at all sure that's the case. Maybe I need to return to CMUCL and use explicit type declarations.

Macros are essential in writing custom control structures in eager languages, e.g., assertions, three-way conditionals, guarded execution (similar to evaluation of a clause in Prolog or a list comprehension expression in Haskell).

Macros can be used as a poor-man configuration language: conditional compilation in C/C++, configuration language in Lisp and Scheme. In a more refined form, macros can implement a limited module system.

Finally macros can introduce notations. A well-chosen notation organizes the mind and makes important ideas easier to see and communicate. "Tutorial on Good Lisp Programming Style"
http://www.norvig.com/luv-slides.ps
devotes a special chapter on this topic.

Syntactic abstractions are possible even in C. For example, message map macros make defining COM interfaces easier. Better examples are DECLARE_MODULE, VFS_SET and other similar "micro-languages" extensively used in programming of device drivers and other kernel components.

The most elevated form is macros generating macros. For example, in Gambit-C Scheme system,

	(define-structure xml-token kind head)

	(CGI:define station-id #f)
	(CGI:define st-name #f)

	(if (cgi#station-id)
		; if it is specified
	   (if (not (string->number (cgi#station-id)))
	      (handle-error)))

In Scheme, macros can effect profound (global) transformations of the code: inlining of functions, lazy semantics, type inference, partial evaluation.