Re: Luerl

[Jay Carlson <nop@...>]

On Tue, Feb 21, 2012 at 9:50 AM, Axel Kittenberger <axkibe@gmail.com> wrote:

> Also, in my opinion, the next big wave of coding languages we are
> going to see, are those that cater for "multi-computing" in varios
> ways.

This has seemed true for at least a decade of course.

[...]

> My own preference currently would lie into something that like Erlang
> or Clojure (or other functional languages) has immutable
> datastructures by default, but be just a little more imperative than
> these to hit my taste. Anyone know something like this?

Well, since I mentioned him, John Ramsdell did propose that Scheme do
this a while back. "Imitation is the most sincere form of flattery,
and I believe the Scheme community should flatter the ML community."
Scheme would lose set-car!/set-cdr!, and make variables bind to
values, not locations. To keep people from losing their minds, he
added make-cell, cell-ref, and cell-set! to explicitly mark
mutability. It might be worth thinking about how your Scheme code
would change--although stack-like variables known not to escape could
be an interesting place to hide mutability.

And of course the MOO language has immutable lists; its objects are
very heavyweight and manually managed. Frobs add a given method suite
to a list, but this doesn't affect immutability. Waifs (which are
still viewed with some suspicion) are like automatically collected
objects.

With immutable lists, there are a bunch of optimizations you can pick
up with reference counting. If you know you hold the sole reference to
a list, you can go ahead and mutate it instead of making a fresh list.
"The implementation may cheat, but it must not get caught."

Jay

[1]: Ramsdell, John. "Scheme: The Next Generation." ACM Lisp Pointers
7 (1994) http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.55.835