R6RS Scheme Status Report

The R6RS committee has released a new status report. They've ratified a number of small additions (square brackets, multiline comments) and made progress on several fronts (Unicode support, exception handling). Unsurprisingly, the module system is still the trickiest issue.

(LtU discussion of the previous status report)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

lazy evaluation

I wonder if they'll get lazy evaluation builtin, since one of the proposals was to get rid with the "delay" and "force" procedures...

Re: lazy evaluation

If they were to do that they'd have to deal with the unpleasant ways in which lazy evaluation interacts with side effects such as mutation and I/O. I don't think Scheme has any intention of becoming Haskell. Haskell does that pretty well!

which would finally put an en

which would finally put an end to the order of evaluation flame war.

Delay and force

IIRC, "delay" and "force" were being moved out of the language proper (and into a library), as delay is trivially implemented as a lambda, and force as a function call. There isn't any proposal that I'm aware of to bolt lazy evaluation into the language.

Er...

... except for the argument that Dan Friedman has been making since at least 1984, that "cons shouldn't evaluate its arguments."

Even older

The Friedman and Wise paper "CONS should not evaluate its arguments" is from 1976, just about as old as Scheme. Maybe next year... ;)

Well, it does....

Whether cons should or shouldn't evaluate its arguments, I'll leave alone--other than to note that nearly 50 years of Lisp/Scheme code assumes that cons is eager and not lazy.

Perhaps a lazy-cons special form, in addition to (rather than instead of) the eager cons might be useful. I'm sure such a thing could be hacked together as a macro, if it hasn't been already. :)

At any rate, it doesn't apper that R6RS will be entertaining any notions of adding laziness to the language.

No need.

As for "CONS should not evaluate it's arguments," Scheme gurus already do that when it's appropriate to the problem. Lazy cons can implemented reasonably using macros and lambdas and set-bang, and implementations already exist. No need for a special form.

Another good idea is that FRONS should not evaluate it's arguments, another Friedman-Wise brainstorm.

Lazy programming in SML or Scheme isn't quite as natural as Haskell, but... this isn't entirely bad. Laziness makes space/time behaviors very difficult to reason about. (Just try ghc -fno-strictness once... Oh, the joy of ghc -O!) There is the idea that functional languages should be by default strict, and pure so that laziness can be accommodated when appropriate. (Voiced by, among others, Simon Peyton Jones and Richard Bird.)