[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Fixing Lisp?

>>: Sundar Narasimhan wrote:
>> So what are the hacks that constrain you in Common Lisp -- that you
>> couldn't fix within the language? 

>: Daniel Weinreb wrote:
> Having separate "value cells" and "function cells"
I think there are many upsides to having a Lisp2
- as demonstrated by my pattern-matcher, for instance.
If I were to make a new, improved lisp,
I'd try rather try to mesh things with syntax like
  (let (((function foo) (lambda (x) (bar x y)))
        (foo (baz)))
   (foo foo))
than build a pseudo equivalence between head and tail positions in a SEXP,
that are usefully distinguished by the semantics.
I also think that Python- (Dylan- ?) like blocks
are much nicer than explicitly nested binding forms.
the multi-level positional syntax of (let ...)
strikes me as particularly low-level.

For a discussion about "Lisp, the next generation", you may participate
in the CLiki discussion, or leave pointers there:

Important topics include
* concurrency and distribution,
* static vs dynamic specification (see sealing in Dylan),
* self-virtualization, and a MOP in general
* open compiler technology (standard code-walking?)

> I think it would have come out looking more like Scheme in general.
Scheme is the Lisp that dreams of being ML.
Though a new Lisp could learn from ML,
I think that Scheme has a deep meta-level schiwophrenia
in not choosing (and not allowing to specify in any standard way)
between static programming and dynamic programming,
ending up with the worst of both world, typing-wise.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[  TUNES project for a Free Reflective Computing System  | http://tunes.org  ]
To those who ask "why would anyone want to write free software for free?",
I answer: "why would anyone want to write a PhD thesis?" -- Faré