4 ms·

This is tangentially related but it seems like you might know - I heard something about a big vs small release of R7RS? Do you know anything about that?

by spraak 10y ago

jdmichal 10y ago
Scheme has traditionally had a minimalist philosophy about the language itself. Basically, the language defines only very low-level syntax and operations -- think arithmetic, variable and function definition, basic control flow, etc. It was then up to libraries to add additional functionality. R7RS small maintains this same mentality. R7RS big is basically R7RS small with a large standard library.
- sitkack 10y ago
  R7RS would have to been an extraction, because big came first. That is probably the way to do things 1. kitchen sink 2. extract core 3. redefine kitchen sink as `small` + extras
  - jdmichal 10y ago
    R7RS-small was ratified back in July 2013, while R7RS-big still isn't ratified.
    - sitkack 10y ago
      That is great news. I remember when they got announced, -big was first with -small to follow.
- _delirium 10y ago
  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.

This is tangentially related but it seems like you might know - I heard something about a big vs small release of R7RS? Do you know anything about that?

by spraak 10y ago

This is tangentially related but it seems like you might know - I heard something about a big vs small release of R7RS? Do you know anything about that?

jdmichal 10y ago

Scheme has traditionally had a minimalist philosophy about the language itself. Basically, the language defines only very low-level syntax and operations -- think arithmetic, variable and function definition, basic control flow, etc. It was then up to libraries to add additional functionality. R7RS small maintains this same mentality. R7RS big is basically R7RS small with a large standard library.

sitkack 10y ago
R7RS would have to been an extraction, because big came first. That is probably the way to do things 1. kitchen sink 2. extract core 3. redefine kitchen sink as `small` + extras
- jdmichal 10y ago
  R7RS-small was ratified back in July 2013, while R7RS-big still isn't ratified.
  - sitkack 10y ago
    That is great news. I remember when they got announced, -big was first with -small to follow.
_delirium 10y ago
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.