Re: [Scheme-reports] Some comments after reading the r7rs public draft

Thank you for responding, and for including the delay suggestion. I didn't consider the unreasonable complexity of standardising the FFI across JVM or CLR implementations, in which case you are right that it is best left out of R7RS-small, however I don't agree with your last point that "Scheme applications are and probably will continue to be best implemented on top of a specific Scheme implementation...".

With the rise of cloud computing it is now more common to pick a language and an ecosystem than it is to choose an interpreter/compiler and work with only that. Cloud hosted web applications are precisely the confluence of buzzwords that many people use Scheme to avoid, but R7RS-large will be a great alternative to a language like Ruby for this task. Ruby for example has at least 2 native code implementations and 1 implementation each for the JVM and CLR, and if these weren't compatible, then migration of code from development servers to any one of a number of commercial hosting companies would be complex, and it is hard to see how Ruby would be as good a choice as it is for a web application without that compatibility.

Cloud considerations are perhaps not the most pressing reasons to avoid dialects in Scheme, but if the intention with R7RS-large is to build an "engineering" Scheme (I'm not certain what the exact R7RS brief is, but I certainly hope to use Scheme in future work), then I think it needs to attain the consistency that python, ruby, php get from having a reference implementation.

-- Duncan Steele

> Date: Wed, 6 Jun 2012 15:52:42 -0400
> From: cowan@x
> To: steeleduncan@x
> CC: scheme-reports@x
> Subject: Re: [Scheme-reports] Some comments after reading the r7rs public draft
>
> 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@x> http://www.ccil.org/~cowan
> Fundamental thinking is ha-ard. Let's go ideology-shopping.
> --Philosopher Barbie