Lambda the Ultimate

It certainly makes sense to make top-level define a primitive; it's the internal defines that the proposal is addressing. This is one of the little details of Scheme that has always baffled me a bit-- the meaning of a define form is different depending on whether there is an enclosing scope or not.

This is one of the little details of Scheme that has always baffled me a bit-- the meaning of a define form is different depending on whether there is an enclosing scope or not.

It's those (ex-)Lispers and their love of puns. :)

The most obvious alternative, especially w.r.t. Lisp, would have been to have "internal" defines affect the global environment, exactly the way top-level defines do. I'm sure that was considered inappropriate for a language in which lexical scope is so central.

If that possibility is ruled out, the remaining alternatives mostly don't behave exactly like top-level defines. An "extreme" solution would be to rewrite each scope into a single letrec*, so that the ability to intersperse DEFINEs and other expressions is possible within a scope, just as at top level. (You'd also need an extension to allow names to be re-DEFINEd.) But the end goal of such a change is essentially to allow the lexical structure of programs to be obscured, so again, this doesn't seem very appropriate for Scheme -- or at least certainly not for the standard, lexical-scope-oriented core.

There is definitely obvious utility to having a standardized module system. There is no particular reason why modules are implementation dependant; but having a standard module system is vital to portability as well as general sanity.

re: force and delay, (delay x) is equivalent to (lambda () x), and (force (delay x)) is just ((lambda () x))

(delay x) is equivalent to (lambda () x), and (force (delay x)) is just ((lambda () x))

(BTW, you probably want a metavariable like exp in place of x there, to be clear that it's the result of applying delay to an arbitrary expression, not a variable.)

That's an implementation that will simulate the behavior of promises, but it does not distinguish promises from thunks. For example, (procedure? (delay exp)) will evaluate to #t, and this representation doesn't provide a clear implementation of promise?.

To be able to define promises well as a derived form, you actually want not just macros but also the ability to define new, disjoint data types. For example:

(define-struct promise (contents))
(define-struct memo (value))

(define-syntax delay
  (syntax-rules ()
    [(delay exp)
     (make-promise (lambda () exp))]))

(define (force p)
  (let ([contents (promise-contents p)])
    (cond
      [(memo? contents)
       (memo-value contents)]
      [(procedure? contents)
       (set-promise-contents! p (make-memo (contents)))
       (force p)]
      [else
       (error 'force "broken promise")])))

That's not something you can do in R5RS, because there's no way to create disjoint data types.

R5RS doesn't require promise? to be implemented, and I don't think it requires a promise to be a distinct data type, but it does require semantics that aren't fulfilled by either your implementation or the one in the post you're replying to.

The simplistic implementation re-computes the calculation for every force, which is inefficient and incorrect for any useful definition of delayed evaluation.

Your version doesn't quite satisfy R5RS, either. R5RS requires that all invocations of force on the same promise evaluate to the result of the one that completes first, even if the invocations are recursive.

Your implementation could be fixed by replacing the form (set-promise-contents! ...) with:

(let ((result (contents)))
  (if (procedure? (promise-contents p))
      (set-promise-contents! p (make-memo result))))

R5RS doesn't require promise? to be implemented, and I don't think it requires a promise to be a distinct data type...

My point is simply that R5RS is unspecific enough that you can implement promises in several ways, and in fact a robust implementation requires facilities that are not part of the standard. Jeff's post describes delay and force as "equivalent" to the procedural representation; my point is that the procedural representation is only a particular implementation technique.

Your version doesn't quite satisfy R5RS, either.

Oops! Quite right. As the following example demonstrates:

(let ([g 0])
  (letrec ([a (delay (begin (set! g (+ g 1))
                            (if (>= g 10)
                                g
                                (begin (force a)
                                       42))))])
    (force a)))

The result should be 10, not 42, because the innermost application of (force a) should be the first to memoize its result and no others should clobber it. Thanks for the correction.

Being picky, but (force (delay x)) is x, not (lambda () x).

He said ((lambda() x)) not (lambda() x). Not being sufficiently scheme-literate, I think but am not sure that this evals in two stages to (x) and then to whatever x was bound to.

((lambda () x)) applies (lambda () x) to no arguments, evaluating to x.

By specifying a module system in R6RS, there will be a way of writing portable code that is structured by means of modules. This is desperately needed. SLIB provides more-or-less portable workarounds for module structure, but it's really not good enough.

Agreeing on a module system will cause a lot of pain though, since it is bound to be incompatible with a lot of code out there.