Name: Anonymous 2007-08-01 20:42 ID:dHzFpar2
I think that fexprs have been unfairly denounced by the mainstream Lisp community. Furthermore, I believe that macros, especially "hygienic" ones, are kludged up constructs that take away from the "purity" of Lisp. Hence, I present here a general idea for a language that should satisfy the little minimalists-with-OCD in all of us.
... primitives:
def, st!, bd!, clone, pair?, null?, flam, and eval.
def, st! and bd! are shortenings of define, set! and bind! The difference is that they evaluate BOTH their arguments. Why have both a set! and a bind!? Well, sometimes we want to only modify a binding, and at other times we're trying to alter a value itself. Suffice it to say that bd! does the former and st! does the latter. def has no side effects, and you can probably guess what cloning does.
The most important primitive here, however, is flam. flam works kinda like the flambdas of old with the argument specification syntax of Scheme. When a flam object is called, the raw expressions are bound to the given arguments.
"Whoah there," you must be thinking, "how would we get the value of an argument, then? Is he seriously suggesting... *gasp* DYNAMIC SCOPE!?"
No sir, I am not. This language is thankfully wholly statically scoped. And here, I shall introduce two (semi-)new constructs: current-continuation and caller-environment. The former is a symbol dynamically bound to where each flam is supposed to return. Without invoking this, the flam won't return anything. The latter is also a dynamic symbol, bound to (you guessed it) the environment of the procedure that called this flam. Yes, that means we have both first class continuations and first-class environments, compilability be damned.
Thus, lambda can be implemented in terms of flam, with each passed raw expression being (eval <expression> caller-environment)'d on the fly, and the last expression returned through (current-continuation <expression>).
Speaking of eval, you might have noticed that it is also a primitive. This is regrettable, since having a metacircular evluator has always been one of the defining features of scheme. Alas, we have no other ways of accessing environments without having to introduce more primitives, or making environments associative lists. No, eval is necessary here. Feel free to prove me wrong.
"But wait," you ask, "where's car, cdr, and quote?" Good man, I assure you: these can be easily constructed with flams.
Of course, there's other little details, like how () means false and everything else is true, and how everything besides symbols and lists eval to themselves, etc. The gist of it is that this language removed the necessity of macros, reduced the number of primitives, and added even more power by a revision of the way Lisp tends to do things.
... primitives:
def, st!, bd!, clone, pair?, null?, flam, and eval.
def, st! and bd! are shortenings of define, set! and bind! The difference is that they evaluate BOTH their arguments. Why have both a set! and a bind!? Well, sometimes we want to only modify a binding, and at other times we're trying to alter a value itself. Suffice it to say that bd! does the former and st! does the latter. def has no side effects, and you can probably guess what cloning does.
The most important primitive here, however, is flam. flam works kinda like the flambdas of old with the argument specification syntax of Scheme. When a flam object is called, the raw expressions are bound to the given arguments.
"Whoah there," you must be thinking, "how would we get the value of an argument, then? Is he seriously suggesting... *gasp* DYNAMIC SCOPE!?"
No sir, I am not. This language is thankfully wholly statically scoped. And here, I shall introduce two (semi-)new constructs: current-continuation and caller-environment. The former is a symbol dynamically bound to where each flam is supposed to return. Without invoking this, the flam won't return anything. The latter is also a dynamic symbol, bound to (you guessed it) the environment of the procedure that called this flam. Yes, that means we have both first class continuations and first-class environments, compilability be damned.
Thus, lambda can be implemented in terms of flam, with each passed raw expression being (eval <expression> caller-environment)'d on the fly, and the last expression returned through (current-continuation <expression>).
Speaking of eval, you might have noticed that it is also a primitive. This is regrettable, since having a metacircular evluator has always been one of the defining features of scheme. Alas, we have no other ways of accessing environments without having to introduce more primitives, or making environments associative lists. No, eval is necessary here. Feel free to prove me wrong.
"But wait," you ask, "where's car, cdr, and quote?" Good man, I assure you: these can be easily constructed with flams.
Of course, there's other little details, like how () means false and everything else is true, and how everything besides symbols and lists eval to themselves, etc. The gist of it is that this language removed the necessity of macros, reduced the number of primitives, and added even more power by a revision of the way Lisp tends to do things.