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

definitions; APPEND!; etc

Since the report won't appear in SIGPLAN Notices until after the Lisp
conference, I too favor waiting another month.

----------------------------------------------------------------
At Brandeis we agreed that (BEGIN (DEFINE ...) (DEFINE ...)) would be
flattened when it appeared at the beginning of a lambda body, but I
forgot to mention that in the RRRS.  It seems simplest to extend that
flattening to apply to the top level as well by changing the formal
syntax of <definition>  to be

    <definition>  -->  (define <variable> <expression>)
                    |  (define (<pattern> <formalz>) <body>)
                    |  (begin <definition>+)

This still rules out things like

    (begin (define up)
           (define down)
           (let ((n 0))
             (set! up (lambda () (set! n (1+ n)) n))
	     (set! down (lambda () (set! n (-1+ n)) n))))

After writing the new syntax for <program> that would be needed
to allow this, I decided it isn't worth it.

----------------------------------------------------------------
I prefer dropping both NAMED-LAMBDA and REC to leaving them both
in.

----------------------------------------------------------------
I have a few remarks to add to some of David Bartley's comments.

>Add "in the same order" at the end of "Two procedures are
>operationally equivalent iff ... they return the same value and
>perform the same side-effects."  (Or is that implied by `having the
>same side-effects'?)

There is still considerable research directed toward formulating
a satisfactory notion of operational equivalence for procedures
with side effects in the presence of concurrency, or even in the
presence of asynchronous interrupts.  To see that the definition
on page 14 is inadequate, consider that

    (lambda (x) (set! x (1+ (1+ x))) x)
and
    (lambda (x) (set! x (1+ x)) (set! x (1+ x)) x)

are operationally equivalent but

    (lambda (y) (set! x (1+ (1+ y))) x)
and
    (lambda (y) (set! x (1+ y)) (set! x (1+ x)) x)

are not.


>APPEND! always side-effects all but its last argument.

No, APPEND! should not be required to perform side effects.  This is not
as silly as it may sound.  In an implementation using the Hewitt-Lieberman
gc algorithm, for example, side effects to sufficiently old structures are
likely to be more expensive than consing.  APPEND! should be free to decide
for itself which technique is fastest.

I would feel differently if APPEND! returned an unspecified value, as
does VECTOR-SET!.


>Rephrase "to make all user populations happy".  >I'm< not happy with
>having both forms (e.g., both = and =?) and I'd settle for EITHER ONE!

I have been one of the main holdouts here, but I too am now willing to
settle for either one.


>If we only have SUBSTRING-MOVE-RIGHT! to support text editors, let's
>flush it!  This is only the tip of the iceberg when it comes to handy
>little utility functions for building editors.

I agree.  I think we should write other documents, however, to describe
the portable Scheme libraries that people have written, and we should
work on improving portability and availability.

peace, Will