Duncan Steele scripsit:
>
> I think it would be great for there to be a way to give an (optional)
> hint to the interpreter/compiler to evaluate (delay ) ed expressions
> in a background thread.  I assume that the lion's share of threading
> support will be in R7RS-large, but with the trend of rapidly increasing
> core counts I think that parallelism in some form must be tackled by
> any serious language at the language level, and not delegated to its
> standard library.

It seems clear that having `delay` spawn a background thread is consistent
with the R5RS/R7RS definition of `delay`, so I have added the following
editorial remark:

# This behavior may be implemented in a variety of ways,
# including the return of a thunk which `force` will evaluate
# to the creation of a background thread to do the computation.

> I don't think record types belong in the core of scheme.  As I
> understand it the record definitions offer little more than what is
> traditionally achieved by using a vector as a record, then defining
> constructors and accessors to operate on that vector.

Little more indeed, but that little is essential to R7RS-large, namely the
ability to create novel types disjoint from the standard Scheme types.
A variety of ways and means were considered by the WG; SRFI 9 prevailed
on the grounds of simplicity and the fact that many implementations
provide it.  There will be a WG2 package consistent with WG1 to provide
run-time record support as well.

> Finally, given that the focus of R7RS seems to be adapting Scheme for
> production code, and that R7RS-small seems to be the minimal set of
> additions to R5RS necessary to achieve this, I think the C Foreign
> Function Interface should standardised in R7RS-small.  It would be
> a shame if efforts on implementing R7RS-large were divided due to a
> variety of incompatible FFIs.

Both WG1 and WG2 have passed on the provision of FFIs, pending the
Steering Committee decision to charter a separate WG on the subject.
See http://trac.sacrideo.us/wg/wiki/ReassignedDocket for the other
packages in this position.  In addition, for implementations hosted on
the JVM or the CLR, the appropriate FFI would be different.

> In general I am excited by R7RS scheme; Scheme is the cleanest lisp,
> and the most pleasurable to code in, so it is frustrating that it has
> not been usable for real projects.  R7RS-large seems set to be solve
> this and fill the hole left by the increasingly long in the tooth
> Common Lisp.

IMO, Scheme applications are and probably will continue to be best
implemented on top of a specific Scheme implementation, since almost all
implementations are themselves portable to the heavily-used operating
environments (Windows, Linux, BSD, Mac OS X, Solaris, Cygwin) of today.
The portability need addressed by R7RS is primarily that of library
programmers, who want their libraries to be usable in more than one
Scheme implementation.

--
John Cowan <cowan@ccil.org>             http://www.ccil.org/~cowan
Fundamental thinking is ha-ard.  Let's go ideology-shopping.
                        --Philosopher Barbie

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports