5 ms·

And as political background, this is basically the "we'll offer both options" resolution to the R6RS acrimony. R6RS tried to take the language in a more "batter

And as political background, this is basically the "we'll offer both options" resolution to the R6RS acrimony. R6RS tried to take the language in a more "batteries included" direction, which led to a lot of resistance from some quarters, and was part of why Racket ended up disclaiming itself as being a Scheme and going in its own direction (the Racket team was quite involved in R6RS, and I believe stung by the way it was essentially rejected by a big part of the Scheme community). R7RS-small is sort of a spiritual successor to R5RS, and R7RS-large is trying to carry on what R6RS attempted, but in a way that can be factored out of R7RS-small and used to complement it. The problem people have been trying to work through is that many people like a small, clean, minimalist core Scheme, but many other people (well, some are the same people, myself included) don't think the current standard is enough to produce useful interoperability. Especially implementors like being able to write small self-hosted experimental or embedded Schemes without a large standard. But many people writing Scheme code are not all that happy about the poor interoperability story that ends up resulting, because there is not quite enough standardized to write libraries that will work on all the major schemes, which is why there's no Scheme equivalent of CL's Quicklisp repository of cross-implementation libraries (the SFRI system is the only real attempt to make this sort-of happen, and is not really good enough).

dleslie 10y ago
Well said. And yet, R7RS-large _still_ will not have a standardized FFI.
- qwertyuiop924 10y ago
  You actually CAN'T have a standard FFI, without having a blessed implementation, as so much of FFI is implementation specific. Besides, it would force FFIs in scheme to do The Right Thing to handle continuations (many don't). And call/cc is expensive enough as it is.
  - dleslie 10y ago
    There are many languages without blessed implementations that define ways to interoperate with other languages. For instance: C++[0], Haskell[1], Java[2], Common Lisp[3], and others[4]. The FFI needn't describe how Scheme structures should behave, it need only describe how to send and receive data that a foreign library can interpret; IE, C data structures. 0: http://en.cppreference.com/w/cpp/language/language_linkage http://en.cppreference.com/w/cpp/language/language_linkage 1: https://www.haskell.org/onlinereport/haskell2010/haskellch8.html https://www.haskell.org/onlinereport/haskell2010/haskellch8.... 2: https://docs.oracle.com/javase/8/docs/technotes/guides/jni/ https://docs.oracle.com/javase/8/docs/technotes/guides/jni/ 3: https://common-lisp.net/project/cffi/ https://common-lisp.net/project/cffi/ 4: https://en.wikipedia.org/wiki/Foreign_function_interface#Examples https://en.wikipedia.org/wiki/Foreign_function_interface#Exa...
    - qwertyuiop924 10y ago
      Alright. I didn't know. But I will say that Scheme is a particularly hard language to build an FFI for. In order to do The Right Thing, and have continuations work across language boundries, you have to integrate continuations into a system that is gleefully unaware of their existance. Depending on the design decisions made, making the FFI do The Right Thing is either impossible, or painfully expensive. So many implementations don't. The only thing RnRS could do is define as implementation inspecific an API as possible, and define any use with continuations undefined behaviour. And that would only be moderately better than not having them at all.
      - dleslie 10y ago
        Why should continuations need to safely work across language boundaries? Plenty of Schemes support FFIs with the enormous warning that call/cc exists and you should be aware of that. This solution is hugely superior to having none at all; as it means that bindings to foreign libraries may trivially be ported across many Schemes. Choosing the right Scheme will be less about what libraries are available, and more about which provides the best execution environment for your needs. In this case, doing the right thing happens to be doing nothing more than warning the user, as is often the case. Attempting to design a system that safely captures foreign state with continuations is almost certainly an over-engineered solution.
spraak 10y ago
Thanks so much for your very detailed explanation! With interop, do you mean FFI? For R7RS-large, are there plans for a module standard?
- _delirium 10y ago
  Maybe interop isn't quite the right term. I meant being able to write portable Scheme code, something that can run on, say, both Guile and Bigloo. The current standard leaves so much undefined that most practical Scheme code is nonportable.

dleslie 10y ago

Well said. And yet, R7RS-large _still_ will not have a standardized FFI.

qwertyuiop924 10y ago
You actually CAN'T have a standard FFI, without having a blessed implementation, as so much of FFI is implementation specific. Besides, it would force FFIs in scheme to do The Right Thing to handle continuations (many don't). And call/cc is expensive enough as it is.
- dleslie 10y ago
  There are many languages without blessed implementations that define ways to interoperate with other languages. For instance: C++[0], Haskell[1], Java[2], Common Lisp[3], and others[4]. The FFI needn't describe how Scheme structures should behave, it need only describe how to send and receive data that a foreign library can interpret; IE, C data structures. 0: http://en.cppreference.com/w/cpp/language/language_linkage http://en.cppreference.com/w/cpp/language/language_linkage 1: https://www.haskell.org/onlinereport/haskell2010/haskellch8.html https://www.haskell.org/onlinereport/haskell2010/haskellch8.... 2: https://docs.oracle.com/javase/8/docs/technotes/guides/jni/ https://docs.oracle.com/javase/8/docs/technotes/guides/jni/ 3: https://common-lisp.net/project/cffi/ https://common-lisp.net/project/cffi/ 4: https://en.wikipedia.org/wiki/Foreign_function_interface#Examples https://en.wikipedia.org/wiki/Foreign_function_interface#Exa...
  - qwertyuiop924 10y ago
    Alright. I didn't know. But I will say that Scheme is a particularly hard language to build an FFI for. In order to do The Right Thing, and have continuations work across language boundries, you have to integrate continuations into a system that is gleefully unaware of their existance. Depending on the design decisions made, making the FFI do The Right Thing is either impossible, or painfully expensive. So many implementations don't. The only thing RnRS could do is define as implementation inspecific an API as possible, and define any use with continuations undefined behaviour. And that would only be moderately better than not having them at all.
    - dleslie 10y ago
      Why should continuations need to safely work across language boundaries? Plenty of Schemes support FFIs with the enormous warning that call/cc exists and you should be aware of that. This solution is hugely superior to having none at all; as it means that bindings to foreign libraries may trivially be ported across many Schemes. Choosing the right Scheme will be less about what libraries are available, and more about which provides the best execution environment for your needs. In this case, doing the right thing happens to be doing nothing more than warning the user, as is often the case. Attempting to design a system that safely captures foreign state with continuations is almost certainly an over-engineered solution.

spraak 10y ago

Thanks so much for your very detailed explanation! With interop, do you mean FFI? For R7RS-large, are there plans for a module standard?

_delirium 10y ago
Maybe interop isn't quite the right term. I meant being able to write portable Scheme code, something that can run on, say, both Guile and Bigloo. The current standard leaves so much undefined that most practical Scheme code is nonportable.