An Acceptable Lisp

On 2008-08-27, Pascal Costanza <pc@p-cos.net> wrote:
> Jon Harrop wrote:
>> Matthew D Swank wrote:
>>> He also said:
>>> "There should be a simple, easily implementable kernel to the Lisp. That
>>> kernel should be both more than Scheme -- modules and macros -- and less
>>> than Scheme -- continuations remain an ugly stain on the otherwise clean
>>> manuscript of Scheme.
>>
>> What's wrong with continuations?
>
> They interact badly with side effects.

That's not an argument for leaving them out of a language.

Side effects interact badly with other side effects, yet decent programming
languages support side effects.

But there is still a salient point here. Continuations are not some quick fix
path to speculative, nondeterministing programming. A continuation allows the
program to jump back to some saved point in its execution. However, this saved
point doesn't save the entire machine state. It could be argued that the
continuation saves only some relatively uninteresting pieces of the machine
state: namely some entities like lexical variables which are defined in the
programming language. In real software, you have external state: open files,
external databases, hardware, connections to other processes, et cetera. In
recognition of this, Scheme gives you dynamic-wind. With this, you are supposed
to take on the responsibility of saving and restoring any aspect of the world
that should work together with the continuation. Good luck!

For instance, if, deeply in some code, it is assumed that a database
transaction is in progress, then whenever you temporarily escape out of that
code via a continuation, you have to roll back that transaction. You may never
go back to that point again, so the database has to be in a state as if that
code never executed. But if you resume the code via a continuation, you have
to restore the transaction to exactly what it was at that point prior to the
escape, so that this partially completed transaction can continue. This is not
a matter of just adding a liberal sprinking of dynamic-wind and crossing your
fingers.

The nice thing about ordinary dynamic control transfers (the kind which escape
from a dynamic scope and can never return, triggering once-only unwind-protect
cleanup), is that they can settle everything. If code bails in the middle of
an incomplete transaction, the unwind-protect rolls it back, and that is final.
There are no questions about what if that code is resurrected and wants to
finish the transaction, and where do you stick the information needed to be able to do that, and how do you represent it, etc.

On Wed, 27 Aug 2008 17:36:09 +0000, Kaz Kylheku wrote:

> On 2008-08-26, Matthew D Swank <akopa.gmane.poster@gmail.com> wrote:
>> On Tue, 26 Aug 2008 12:06:48 -0700, Vsevolod wrote:
>>
>>>> What they are missing is that CL is a great language because it is
>>>> extremely well-engineered, and the existing features fit together
>>>> very nicely.
>>> I completely agree with you.
>>>
>>> Dick Gabriel said: "I think there will be a next Lisp". (http://
>>> www.dreamsongs.com/WIB.html. 3.6 The Next Lisp) And actually I'm
>>> willing to put effort in the direction of "the Ultimate Lisp" and plan
>>> to do that, when I'm ready. But, surely, my efforts won't be enough,
>>> and, moreover, as I've mentioned above, one- man efforts can't lead to
>>> something as finely thought-out and engineered, as well as acceptable,
>>> as, for example, Common Lisp
>>>
>>> Vsevolod
>>
>> He also said:
>> "There should be a simple, easily implementable kernel to the Lisp.
>> That kernel should be both more than Scheme -- modules and macros --
>> and less than Scheme -- continuations remain an ugly stain on the
>> otherwise clean manuscript of Scheme.
>>
>> The kernel should emphasize implementational simplicity, but not at the
>> expense of interface simplicity.
>
> Simplicity is for amateurs. Or maybe for seasoned hackers who are
> breaking new ground.
>
> Production quality, N-th generation systems should emphasize reliability
> and performance.
>
> If you keep simplicity out of a kernel, it doesn't disappear. It simply
> moves somewhere else, and possibly multiplies, because certain things
> can't be done in a straightforward way outside of the kernel.

Well the desire for a kernel/library separation is mostly a pragmatic one
in my case. With a correct reference implementation of most of common
lisp as portable library, the leaning curve and time investment to
implement the kernel and bootstrap a proper lisp would not be so steep.

For example, despite the hand-wringing over R6RS, having the libraries
and macro-system basically available off-the shelf in psyntax makes it
easy to adopt.

Also the explicit kernel/library separation would hopefully encourage
more language experimentation, with the kernel basically providing a
common runtime in which these lisps can coexist.

Matt

Matthew D Swank <akopa.gmane.poster@gmail.com> writes:
> Well the desire for a kernel/library separation is mostly a pragmatic one
> in my case. With a correct reference implementation of most of common
> lisp as portable library, the leaning curve and time investment to
> implement the kernel and bootstrap a proper lisp would not be so steep.

Why "would"? "Is"!


> Also the explicit kernel/library separation would hopefully encourage
> more language experimentation, with the kernel basically providing a
> common runtime in which these lisps can coexist.

The Common Lisp kernel is specified in CLHS. Mind all the operators
marked "Special Operators". All the rest is library macros or functions.


--
__Pascal Bourguignon__ http://www.informatimago.com/

READ THIS BEFORE OPENING PACKAGE: According to certain suggested
versions of the Grand Unified Theory, the primary particles
constituting this product may decay to nothingness within the next
four hundred million years.

On Aug 28, 2:17*am, p...@informatimago.com (Pascal J. Bourguignon)
wrote:

>
> > Also the explicit kernel/library separation would hopefully encourage *
> > more language experimentation, with the kernel basically providing a
> > common runtime in which these lisps can coexist. *
>
> The Common Lisp kernel is specified in CLHS. *Mind all the operators
> marked "Special Operators". *All the rest is library macros or functions.
>

A kernel ends up being both more and less than the special forms. Is
the list of special forms minimal? What about basic data types; what
about the type system itself? How much of the macro system has to be
there?

With just the special forms we can't even do any i/o. As for all the
rest, there is PCL, and Pitman's condition system implementation.
That is a lot, but there could also be most of cltl1 if we knew where
the bottom was.


Matt

akopa <akopa.gmane.poster@gmail.com> writes:

> On Aug 28, 2:17*am, p...@informatimago.com (Pascal J. Bourguignon)
> wrote:
>
>>
>> > Also the explicit kernel/library separation would hopefully encourage *
>> > more language experimentation, with the kernel basically providing a
>> > common runtime in which these lisps can coexist. *
>>
>> The Common Lisp kernel is specified in CLHS. *Mind all the operators
>> marked "Special Operators". *All the rest is library macros or functions.
>>
>
> A kernel ends up being both more and less than the special forms.

Yes, you can include a little more.

> Is the list of special forms minimal?

No. You can implement everything with LAMBDA.


> What about basic data types; what about the type system itself?

This is covered by the Special Operator THE ;-)


> How much of the macro system has to be there?

None. You can implement the macro system with only the Special
Operators. You'll prefer to use also some basic functions, themselves
implemented only with the Special Operators.


> With just the special forms we can't even do any i/o.

Indeed, but you can implement COMMON-LISP I/O function only with the
Special Operators, and possibly primitive, system specific functions
found in the SYSTEM package. The point here is that it depends on the
kind of implementation you need. If you need to interface with some
system, you'll have to implement the SYSTEM package to give access to
these "primitive" I/O routines. But you could as well implement a CL
for a closed, embedded environment where all I/O is done from memory
(for example, if the hardware ensure persistence of RAM).

(defun sys:write (object stream) (sys::enqueue object (stream-data stream)))
(defun sys:read (stream) (sys::dequeue (stream-data stream)))

But anyways, this is out of the scope of CL.


> As for all the rest, there is PCL, and Pitman's condition system
> implementation. That is a lot, but there could also be most of
> cltl1 if we knew where the bottom was.

There's no bottom, it's all turtles all the way down.

--
__Pascal Bourguignon__

Pascal J. Bourguignon wrote:

>> What about basic data types; what about the type system itself?
> This is covered by the Special Operator THE ;-)

ATOM?

Matthias Buelow <mkb@incubus.de> writes:

> Pascal J. Bourguignon wrote:
>
>>> What about basic data types; what about the type system itself?
>> This is covered by the Special Operator THE ;-)
>
> ATOM?

(THE ATOM 42)

I mean that if you want to implement THE in some way, you bring with
it the whole specification of the type system.


I also means that of course, along with these Special Operators, you
have all the implicit CL notions, those that don't have necessary a
symbol attached to them, but that are nonetheless important to
implement to realize CL semantics, like environments, or function call.

((lambda (x) (* x x)) 2)

Here, there are no special operators. But indeed it must be
evaluated. Implementing the Special Operators means implementing the
EVAL or the COMPILE function, and implementing them entirely means
implementing the evaluation (or compilation) of the above form.



Ok, but now I see that perhaps you meant that some data types can be
more primtive than others. Indeed, we don't need to implement all the
data types as primitives. For example, we can implement hash-tables
over vectors. And the choice of "primitive" datatypes is rather
orthogonal to the set of Special Operators. For lisp we would want
CONS and SYMBOL (after all, EVAL and COMPILE take s-exprs). To
implement the reader we'd like to have CHARACTER (but it could be
implemented over FIXNUM). For efficiency of the implementation it
would be nice if VECTOR was primitive. But again, it will depend on
the target, and what underlying data type are available.


--
__Pascal Bourguignon__ http://www.informatimago.com/

Pascal J. Bourguignon wrote:
>>>> What about basic data types; what about the type system itself?
>>> This is covered by the Special Operator THE ;-)
>> ATOM?
>
> (THE ATOM 42)

Ok, with handler-bind (and the corresponding evaluator-internal
primitive), it can work (you'll have to catch the error that occurs for
non-atoms and return nil in that case.)

On 25 Ago, 21:27, Vsevolod <vselo...@gmail.com> wrote:
> read all (no, thanks)

You know, we are at high-end here.
High-end discussions are by definition very personal and always
objective.

So, please don't come here (or anywhere else) expecting some major
consensus...

-PM

On Aug 30, 5:50 pm, pls.m...@gmail.com wrote:
> On 25 Ago, 21:27, Vsevolod <vselo...@gmail.com> wrote:
>
> > read all (no, thanks)
>
> You know, we are at high-end here.
> High-end discussions are by definition very personal and always
> objective.
>
> So, please don't come here (or anywhere else) expecting some major
> consensus...
>
> -PM

I don't, and after reading it for quite a while I know what this group
is like.
I was more interested in the discussion and I've got a lot of food for
thought actually.
(Hope, that in the process, nobody's feelings were hurt

Best regards,
Vsevolod