gnu-arch-users
[Top][All Lists]
Advanced

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

[OT] lisp (was Re: [Gnu-arch-users] tla1.1 plans)


From: Tom Lord
Subject: [OT] lisp (was Re: [Gnu-arch-users] tla1.1 plans)
Date: Tue, 16 Sep 2003 10:42:13 -0700 (PDT)

    > From: Christian Lynbech <address@hidden>

    > Tom> It has been my observation that there are many "hackable" lisp
    > Tom> implementations, but that mistakes in the design of the core can
    > Tom> be severely limiting in horrible ways.

    > When you say "lisp", does that include Common Lisp which (even by the
    > ANSI standard) seems very hackable to me. 

Sorry for the confusion.  I specifically meant "hackable
_implementation_" not "hackable language design".

For example, many lisps make it easy to write C code which adds a new
function or data type.   However, the rules for how you write that C
code vary wildly and the interfaces for writing that C code limit
your options for data represeentation, garbage collection, interrupt
handling, tail-call optimization, etc.

So, rather than aiming for an initial release which has, say, the
ultimate super-cool garbage collector -- I'm aiming for an initial
release in which the C interface to the garbage collector provides a
nice amount of freedom for how GC can be (re)implemented.


    > Do you see it otherwise and in that case what core design issues
    > impose horrifying limitations?

There are some comparatively minor (but pervasive) things in CL that I
find (mostly aesthetically) "horrifying" and mostly, as nearly as I
can tell, these correspond closely to what are clearly historical
accidents -- the result of the process and goals that drove the
creation of the standard and its antecedent lisps.

For my immediate purposes, I want an initially much smaller language
than CL.

Given the things I like about Scheme (lisp-1ness and the tail-call
rules, mostly) I don't expect to produce a dialect that CLers will
feel immediately at home in but I'm trying not to design a language
that (like Scheme) pretty much precludes being extended into a full
CL.

-t




reply via email to

[Prev in Thread] Current Thread [Next in Thread]