Lisp with maps instead of lists

I've been working on something similar for the last few years. It's a neat idea that has some interesting properties: a code block is a triple: code, value and map (and quite possibly a closure so that it can be repeatedly re-evaluated). You can easily build complex iterative lazy structures as well as all the ordinary things like for-loops, function calls etc using the same basic structures.<p>It's a similar idea, in many ways, to the way Javascript does objects: run some code get a map back. Where it gets interesting is that you can choose to use the evaluated value and the scope that was generated in evaluating it. Objects, maps, code, scope, closures and lazy evaluation become the same thing: you declare a block of code, you evaluate it into a closure (with scope and a stack) you query it for results, rinse-repeat.<p>A for-loop becomes a function that takes two blocks: one that lazily generates values in and one that lazily consumes them. It is the two closures that remember their state - not the for-loop function. The 'for-function' just passes the current value to the second block to use it.<p>Javascript, REBOL and Lua do have these capabilities but none have the elegance (nor simplicity) of Lisp. I'd love to see a language that does.

It may be a toy language, but it's a serious idea, one I've often wondered about. I work a lot with both Common Lisp and Javascript and the one killer JS feature that I miss in CL is its maps, or rather its use of the map as its organizing principle. This particularly shines for exploratory programming, since it frees you from having to work very hard when adding, removing, or reordering information in your program: it's trivial to stuff a property into a JS map and trivial to get it back. Since nearly everything is a map, nearly everything has this flexibility. CL's plists seem like they ought to serve this purpose, but they don't (compared to JS) because plists are conses and their identity changes when you prepend new properties to them; also, all null plists are the same, which turns out to be surprisingly restrictive (again compared to JS).<p>On my project we ended up adding a JS-style property operator to CL and using JS-style maps wherever we wanted this flexibility, which was nearly everywhere. It just compiles to CL hashtables under the hood. This is so valuable, it's natural to wonder what a Lisp with the map as its organizing principle would look like.

It's difficult to gauge how serious this proposal slash thought experiment is. The nice thing about a pair is the way it naturally lends itself to iterative processing: There's the CAR and the CDR, the first and the rest. (Are the keys in these maps ordered?)<p>Not all data is complex enough to merit a map: modeling e.g. a list using lists is perverse in that you're using degenerate single-item maps to model what is a simpler data structure.<p>And what does a lisp based on maps look like, if this language preserves the homoiconic nature of lisp?<p>The argument by analogy that a lisp "should" have a "better" data structure than a cons cell because lisp lambdas support multiple arguments, unlike pure lambda calculus, doesn't hold water. Lisps--and even Scheme, which is often incorrectly taken to have as a design goal to be minimalistic to the point of consisting of axiomatic primitives--do not deal in pedantic adherence to theory. Limiting lambdas to a single argument is pointless whereas a cell happens to be minimal yet extremely useful in practice.<p>Other have written lisps atop vectors as the primitive data type. That's an idea that makes more sense: it's a generalization of the pair to arbitrary length.

This is interesting. Maps are themselves functions, taking the key as a parameter and returning its associated value. So when your basic data type is a map, the language is arguably more "functional" than the usual functions + lists combination.

I've also built something similar that is based on .NET: <a href="http://code.google.com/p/metalang/" rel="nofollow">http://code.google.com/p/metalang/</a><p>Maybe we should all team up or something...

This looks like REBOL. :)

We discussed this same article extensively yesterday at <a href="http://news.ycombinator.com/item?id=2552180" rel="nofollow">http://news.ycombinator.com/item?id=2552180</a> .