Lambda the Ultimate

inactiveTopic Further information on "Beating The Averages"
started 5/3/2001; 7:01:03 PM - last post 5/4/2001; 6:35:41 PM
Brad Knotwell - Further information on "Beating The Averages"  blueArrow
5/3/2001; 7:01:03 PM (reads: 656, responses: 6)
Further information on "Beating The Averages"
Paul Graham's followup article to the recent feature on slashdot. It focuses more on the technical detail of the Viaweb store and, specifically, why Lisp was essential for development.
Posted to general by Brad Knotwell on 5/3/01; 7:02:05 PM

Ehud Lamm - Re: Further information on  blueArrow
5/3/2001; 8:15:59 PM (reads: 650, responses: 0)
Moved from implementation to general.

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

Adam Vandenberg - Re: Further information on  blueArrow
5/3/2001; 8:25:45 PM (reads: 652, responses: 1)
The thought of using recursive macro calls to generate complex HTML fills me with a vague sort of dread. For some reason. But I don't do any LISP hacking, so maybe it's "not all that bad".

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.

andrew cooke - Re: Further information on  blueArrow
5/4/2001; 12:00:25 AM (reads: 682, responses: 0)
Re "simulating subroutine behaviour": What (I think) they were doing was generating code that needed to be executed on the server when the next page was generated and accessing it via a hash (plus parameters from the page).

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!

Adam Vandenberg - Re: Further information on  blueArrow
5/4/2001; 12:08:50 AM (reads: 641, responses: 0)
Ah. Still, session state gets me nervous, but my web development experience is most with ASP and WLBS (since we don't get server affinity in our web cluster we can't use session state, you never know which server a request will go to.)

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.

andrew cooke - Re: Further information on  blueArrow
5/4/2001; 12:14:53 AM (reads: 665, responses: 0)
The most interesting parts of the article (to me) were the justifications for Lisp.

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.

Oleg - Re: Uses of macros  blueArrow
5/4/2001; 6:35:41 PM (reads: 634, responses: 0)
One use of macros is emulating higher-order polymorphic functions. In C, this is the only way to achieve parametric polymorphism. For example, see "man 3 queue" on a BSD system. In C++, templates serve the same purpose. Functional languages offer higher-order polymorphic functions natively.

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"
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)
expands into a series of macros xml-token?, xml-token-kind (getter), and xml-token-kind! (the setter), etc. Another example of micro-notation is a CGI "namespace":
For example, suppose you're to process a web form with two input fields: station-id and st-name. In your form processing code, you can declare the fields as
	(CGI:define station-id #f)
	(CGI:define st-name #f)
and then use them almost as if station-id and st-name were regular variables:
	(if (cgi#station-id)
		; if it is specified
	   (if (not (string->number (cgi#station-id)))
The notation offers coercions: (cgi#station-id) gives the first word typed in the corresponding form field, (cgi#station-id :as-list) is a list of all the words in the field, (cgi#station-id :as-full-string) gives the unparsed content of the field.

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