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: [email protected] > To: [email protected] > CC: [email protected] > 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 <[email protected]> http://www.ccil.org/~cowan > Fundamental thinking is ha-ard. Let's go ideology-shopping. > --Philosopher Barbie
_______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
