I have been thinking about a modified version of LET that takes a sequence of expressions (like begin) that are either assignments or not assignments. Then it would collect all consecutive assignments together into a letrec. For example:
(let
(foo)
(= a 1)
(= b 2)
(= c 3)
(bar)
(= x 4)
(= y 5)
(baz))
I should add: This works because the host lisp is pure: there is no SET! or mutable cells.
If you have mutable cells, write out and read it back in you'd get a clone of the cell - independent of the original. This seems like the wrong behavior.
To make it work with mutable cells seems kind of impossible. I'm not sure. One system I found replaces mutable cells with distributed uniquely identified mailboxes. (termite scheme).
It's possible to record the fact that some cons cells (or other structures) are identical. The Lisp reader's #n= notation can be used for this, although usually it's only used to print circular lists. Common Lisp's print-circle can be used to demonstrate this:
Now, if you have a running process, and you want it to seralize a closure (or, generally, an object) that points to a cell that happens to be identical to something else in the process, and you want to read the closure back in and have its pointed-to cell continue to be identical to that other thing... you'll need something more sophisticated. If each object is given some unique id, that would be one approach; that sounds like the mailboxes thing. Another approach would be... say, if the other cell is the 5th element of a list identified with the global name 'blah, then conceivably that could be a good syntax. This might be useful for modules, separate compilation, and/or saving arbitrary process state.
I think you should have to quote them. Like how you have to quote lists:
'(foo bar)
is just a list, but
(foo bar)
will either call the function foo or error if it doesn't exist.
So in a similar way
{foo "bar"}
should give a syntax error, but maybe it can have some kind of semantic meaning later. I've been considering that square brackets could be used for assignment/local binding, to cut down on the need for LET (not necessarily in arc just in lisp in general).
I don't agree. quoting a list is a way to protect the expression from evaluation, in this case because round brackets normally indicate an expression that needs to be called. A table literal {...} doesn't need protection from evaluation as a callable expression as it's just data and like any other data it should evaluate to itself. And, frankly, it would really suck having to protect that data everywhere in my code because someone wants a really nuanced use case to work.
Really what should happen is that [] should be implemented such that we don't need to protect lists of data.
update: having it self evaluate (or evaluate to a hashtable with quoted keys and non-quoted values maybe) instead of a syntax error seems like a better choice
