I was thinking of something that looked like let. Since you wouldn't be able to do it for all types, it seems like it would be better to make the programmer see the vars he was going to close over. Otherwise you'd run into the kinds of problems Lisp hackers ran into in the days of dynamic scope, where your code works (till it doesn't) by accident.
Well, currently a few people in the Arc community are building implementations of Arc.
It may actually be possible to include as an axiom a few functions that allow a closured function to be destructured.
For example, it may be possible to define a set of functions which can be applied on a function to determine if it encloses any variables or not, what number of enclosed variables, and the variable values (if not the names).
It would also be possible to add as an axiom a function to extract the "code part" of a closure, at least as an opaque (but uniquely-comparable) object. Speaking as an implementeer hacking on the low-level side, generally the implementation of a closured function is simply two pointers: a pointer to the enclosed environment, and a pointer to the code (of course, in arc2c it's just an array where the first entry is a reference to the code and the succeeding array entries are the enclosed variables).
Only the pointer to the enclosed environment needs to actually be considered: the code is constant (except for code updates, but one would expect updates to be rarer than actual invocations of the code).
If we can extract the data of each closured variable, we can determine if it's trivially serializable (e.g. strings, numbers, proper lists of strings and numbers), and if so, it is potentially possible to encrypt the values into the URL.
We can then also add some functions to reconstruct a closure, given only an opaque code reference and a bunch of data.
Since my Arc implementation, SNAP, will require the ability to serialize and deserialize closured functions (including code and data) anyway, I'll have to extend Arc that way.
The advantage of this is that you don't need to explicitly state what you want to close over: you just close over variables, and the base system will destructure your closure, and just encode the trivially serializable variables into the generated URL link.
Note that although serializing simple values (like numbers and symbols) to urls works, serializing big data doesn't work because urls have a length limit.
What I was trying to explain is a system that stores the data on the server and passes pointers to this data to the client. Web applications that use databases already work this way. The id/primary key column of a database table is the pointer.
To serialize a closure you generate ids for the values of the free variables. Then you save the values in a hash table and send the ids to the client (instead of the actual values). To deserialize a closure you fetch the free variables from the hash table.
This system doesn't work yet because this hash table keeps growing. Every time you serialize a closure you put the free variables in the hash table. This is wasteful because some of the values might already be in the hash table. This is simple to fix; just look if the value is in the hash table, and if it is you return the existing id (this can be done efficiently by having two hash tables: ids->values and values->ids).
> What I was trying to explain is a system that stores the data on the server and passes pointers to this data to the client.
What I was trying to explain was to make this seamless to the programmer, i.e. the programmer doesn't have to use a let-like form listing the variables he or she wants to use, he or she just uses them. Basically the base system scans through the enclosed variables, checks if they're trivial, and encodes them directly if so; if not, it puts the data for retrieval somewhere.
Mostly I'm concentrating on keeping Arc succint, and modifying the base system without, if possible, modifying higher-level code.
In any case your suggested implementation does look good.
> if it is you return the existing id (this can be done efficiently by having two hash tables: ids->values and values->ids).
