5 ms·

Cyclone Scheme

89 points by andrenth 6y ago

wrycoder 6y ago
This is a traditional ("small") Scheme implementation. From the R7RS report: Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary. Scheme demonstrates that a very small number of rules for forming expressions, with no restrictions on how they are composed, suffice to form a practical and efficient programming language that is flexible enough to support most of the major programming paradigms in use today. [The] Scheme Steering Committee decided in August 2009 to divide the standard into two separate but compatible languages — a “small” language, suitable for educators, researchers, and users of embedded languages, focused on R5RS compatibility, and a “large” language focused on the practical needs of mainstream software development, intended to become a replacement for R6RS. The present report describes the “small” language of that effort: therefore it cannot be considered in isolation as the successor to R6 RS.
- oddthink 6y ago
  Was R7RS-large ever ratified? It doesn't look so to me, but it's been so long that I'm not sure I'm looking in the right places.
  - wrycoder 6y ago
    Yes, it was ratified: https://en.wikipedia.org/wiki/Scheme_(programming_language)#R7RS https://en.wikipedia.org/wiki/Scheme_(programming_language)#...
    - fanf2 6y ago
      That page says R7RS-small was ratified but not R7RS-large, and http://www.scheme-reports.org/ http://www.scheme-reports.org/ says the same
  - johncowan 6y ago
    R7RS-large is a work in progress, and will not have a single "ratification" event. The work has been divided into editions named after colors, which are cumulative. So far the contents of the Red Edition and the Tangerine Edition have been voted on (anyone interested can vote) and are established; the Orange Edition is currently in preparation. We use the SRFI process to develop specific components of an edition, which means that all components already have implementations before they are voted on, usually portable ones. See r7rs.org for details.
    - dleslie 6y ago
      Hey John! I'm curious; is there any possibility that Scheme will eventually abandon call/cc in favour of delimited continuations?
  - p4bl0 6y ago
    R7RS-large is Racket ;). (This is a joke, do not take this seriously.)
- fn1 6y ago
  > Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary. "A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away." - Antoine de Saint-Exupery
  - Wezl 6y ago
    I've been writing a picolisp-like lisp interpreter[1] and I have really noticed this too. I added a length built-in just because recursion wasn't working properly, but if I had continued without the important functionality for too long, I would have needed to implement many more functions (and the lisp still would be missing important things). [1]: https://github.com/ErmineII/mapL https://github.com/ErmineII/mapL
7thaccount 6y ago
I'm getting a 404 error on the example code links from the home page. Also, how does Windows installation work? I figure most people would prefer a single executable that drops into the REPL and can compile programs rather than an install wizard if at all possible, but I have no idea if that is possible at any point.
- wrycoder 6y ago
  Try https://github.com/justinethier/cyclone/tree/master/examples https://github.com/justinethier/cyclone/tree/master/examples
  - 7thaccount 6y ago
    That worked, thanks!
- justinethier 6y ago
  Here are instructions for the Windows installation. Unfortunately additional libraries are required, there is not a single drop-in executable: https://github.com/justinethier/cyclone-bootstrap/blob/master/README.Windows.md https://github.com/justinethier/cyclone-bootstrap/blob/maste...
  - 7thaccount 6y ago
    Understood and thanks!
hajile 6y ago
SRFI needs to die a painful death. SRFI 1 -- enough functions to make lists useable SRFI 25 -- multidimensional arrays SRFI 28 -- format strings SRFI 30 -- nested multiline comments SRFI 34 -- exception handling SRFI 41 -- streams SRFI 43 -- make vectors usable SRFI 47 -- add arrays SRFI 50 -- C FFI SRFI 57 -- records SRFI 69 -- hash tables SRFI 79 -- primitive (low-level) IO calls SRFI 89 -- optional args and named params SRFI 111 -- Boxes SRFI 121 -- Generators SRFI 169 -- underscores in numbers SRFI 180 -- JSON (not approved as final version until 2020....) The convention of using SRFI numbers is very anti-user. Those names are much easier to read and understand. It's very hard to discover stuff. Let's say I'm not new to programming, but I'm new to scheme and choose the very popular chicken and find myself wanting hash tables. Are they built-in or an egg? Well, searching around the manual gives the following: http://wiki.call-cc.org/man/5/The%20User%27s%20Manual http://wiki.call-cc.org/man/5/The%20User%27s%20Manual The manual has a clear "extensions to the standard" page, but that has a hard assumption that you know what the standard says (you probably don't). If you assume hash tables are in the r5rs spec, you are about to waste a ton of time finding out that they aren't there. http://wiki.call-cc.org/man/5/Extensions%20to%20the%20standard http://wiki.call-cc.org/man/5/Extensions%20to%20the%20standa... When you finally come back to the "Extensions to the Standard" page, you get this: compile chicken, compiling, library, eval, extras, regex, srfi-0, srfi-2, srfi-4, srfi-6, srfi-8, srfi-9, srfi-10, srfi-11, srfi-12, srfi-15, srfi-16, srfi-17, srfi-23, srfi-26, srfi-28, srfi-30, srfi-31, srfi-39, srfi-55, srfi-61, srfi-62 load chicken, extras, srfi-0, srfi-2, srfi-6, srfi-8, srfi-9, srfi-10, srfi-12, srfi-17, srfi-23, srfi-28, srfi-30, srfi-39, srfi-55, srfi-61, srfi-62. library is implicit. eval csi, chicken, extras, srfi-0, srfi-2, srfi-6, srfi-8, srfi-9, srfi-10, srfi-11, srfi-12, srfi-15, srfi-16, srfi-17, srfi-23, srfi-26, srfi-28, srfi-30, srfi-31, srfi-39, srfi-55, srfi-61, srfi-62. library is implicit. Well great. After that standard dead-end, I've probably run into SRFI somewhere down the line (if not, I'm probably about to google one of these things). Either way, I wind up on the SRFI page. https://srfi.schemers.org/ https://srfi.schemers.org/ OK, there are FOUR hash table SRFIs. I'll go with SRFI-69 Basic Hash Tables. Looking back at those lists, srfi-69 is nowhere to be seen. More searching will sooner or later take me to the official Chicken Scheme SRFI-69 egg which thankfully is documented. Quite an ordeal. Now, if I want records, I'll know to compare that list of SRFI numbers from the extension page with the SRFI list in the SRFI website. That'll show me that I want SRFI-9. One of two things is going to happen at this point. I might find out that the Chicken wiki has an entry for records. If I miss that somehow (why isn't it in the manual?), then I'll have no choice but to read the entire specification document and be either thankful that it's short, and/or upset that I'm stuck with zero examples (unless I find the wiki along the way). http://wiki.call-cc.org/man/5/Module%20%28chicken%20base%29#record-structures http://wiki.call-cc.org/man/5/Module%20%28chicken%20base%29#... https://srfi.schemers.org/srfi-9/srfi-9.html https://srfi.schemers.org/srfi-9/srfi-9.html As you can see, that's not a good dev experience. Moving away from that, what about compatibility? It's basically not possible to polyfill C FFI, underscores in numbers, primitive IO, exception handling, optional args, and similar. I don't want to play the "does X library work" game (sometimes switching implementations is unavoidable). These things either need to be required or need to be removed from the SRFI list. Along those same lines, things like records or arrays also need to be required. Sure, they can technically be polyfilled using lists, but the performance of that will make them basically useless. I understand the "teaching language" bit, but r7rs is already too complicated for an average student to implement. Likewise, "embedded must be small" doesn't hold weight either. Embedded devs expect to have features stripped out. Saying "generators aren't available on tiny platform X" is much easier than saying that "some desktop variants include generator support; good luck". This is the primary reason why Common Lisp is seen as "business ready" while Scheme is not. Feature Stability, predictability, and documentation matter.
dannyobrien 6y ago
I just wanted to say thank you for the extensive, beautiful and well-written documentation. Always good to see.
dpc_pw 6y ago
One thing I'll never understand about Scheme/Lisp is why they need so many versions (of the standard, and of different compilers).
- nerdponx 6y ago
  I don't think it's entirely a matter of "need". All these implementations are independent projects. Some of them include their own features on top of the standard. Some of them focus on specific use cases and/or optimize for specific performance characteristics. Some of them are toy projects. How many C implementations/compilers are there? Even Python (which has a massive and often ill-defined spec) has multiple implementations.
  - dpc_pw 6y ago
    > How many C implementations/compilers are there? I can compile same source code with pretty much any C compiler. I might be wrong, but the lisp compilers are all "slightly different". I guess scheme ones can be the same? But are they really?
    - nerdponx 6y ago
      That's fair, until you get into GCC extensions. I guess the difference is that the Scheme "core" is typically smaller and the amount of extensions is typically larger. See also: Common Lisp, which has a similar problem.

89 points by andrenth 6y ago

This is a traditional ("small") Scheme implementation. From the R7RS report: Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary. Scheme demonstrates that a very small number of rules for forming expressions, with no restrictions on how they are composed, suffice to form a practical and efficient programming language that is flexible enough to support most of the major programming paradigms in use today. [The] Scheme Steering Committee decided in August 2009 to divide the standard into two separate but compatible languages — a “small” language, suitable for educators, researchers, and users of embedded languages, focused on R5RS compatibility, and a “large” language focused on the practical needs of mainstream software development, intended to become a replacement for R6RS. The present report describes the “small” language of that effort: therefore it cannot be considered in isolation as the successor to R6 RS.

oddthink 6y ago
Was R7RS-large ever ratified? It doesn't look so to me, but it's been so long that I'm not sure I'm looking in the right places.
- wrycoder 6y ago
  Yes, it was ratified: https://en.wikipedia.org/wiki/Scheme_(programming_language)#R7RS https://en.wikipedia.org/wiki/Scheme_(programming_language)#...
  - fanf2 6y ago
    That page says R7RS-small was ratified but not R7RS-large, and http://www.scheme-reports.org/ http://www.scheme-reports.org/ says the same
- johncowan 6y ago
  R7RS-large is a work in progress, and will not have a single "ratification" event. The work has been divided into editions named after colors, which are cumulative. So far the contents of the Red Edition and the Tangerine Edition have been voted on (anyone interested can vote) and are established; the Orange Edition is currently in preparation. We use the SRFI process to develop specific components of an edition, which means that all components already have implementations before they are voted on, usually portable ones. See r7rs.org for details.
  - dleslie 6y ago
    Hey John! I'm curious; is there any possibility that Scheme will eventually abandon call/cc in favour of delimited continuations?
- p4bl0 6y ago
  R7RS-large is Racket ;). (This is a joke, do not take this seriously.)
fn1 6y ago
> Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary. "A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away." - Antoine de Saint-Exupery
- Wezl 6y ago
  I've been writing a picolisp-like lisp interpreter[1] and I have really noticed this too. I added a length built-in just because recursion wasn't working properly, but if I had continued without the important functionality for too long, I would have needed to implement many more functions (and the lisp still would be missing important things). [1]: https://github.com/ErmineII/mapL https://github.com/ErmineII/mapL

7thaccount 6y ago

I'm getting a 404 error on the example code links from the home page. Also, how does Windows installation work? I figure most people would prefer a single executable that drops into the REPL and can compile programs rather than an install wizard if at all possible, but I have no idea if that is possible at any point.

wrycoder 6y ago
Try https://github.com/justinethier/cyclone/tree/master/examples https://github.com/justinethier/cyclone/tree/master/examples
- 7thaccount 6y ago
  That worked, thanks!
justinethier 6y ago
Here are instructions for the Windows installation. Unfortunately additional libraries are required, there is not a single drop-in executable: https://github.com/justinethier/cyclone-bootstrap/blob/master/README.Windows.md https://github.com/justinethier/cyclone-bootstrap/blob/maste...
- 7thaccount 6y ago
  Understood and thanks!

hajile 6y ago

SRFI needs to die a painful death. SRFI 1 -- enough functions to make lists useable SRFI 25 -- multidimensional arrays SRFI 28 -- format strings SRFI 30 -- nested multiline comments SRFI 34 -- exception handling SRFI 41 -- streams SRFI 43 -- make vectors usable SRFI 47 -- add arrays SRFI 50 -- C FFI SRFI 57 -- records SRFI 69 -- hash tables SRFI 79 -- primitive (low-level) IO calls SRFI 89 -- optional args and named params SRFI 111 -- Boxes SRFI 121 -- Generators SRFI 169 -- underscores in numbers SRFI 180 -- JSON (not approved as final version until 2020....) The convention of using SRFI numbers is very anti-user. Those names are much easier to read and understand. It's very hard to discover stuff. Let's say I'm not new to programming, but I'm new to scheme and choose the very popular chicken and find myself wanting hash tables. Are they built-in or an egg? Well, searching around the manual gives the following: http://wiki.call-cc.org/man/5/The%20User%27s%20Manual http://wiki.call-cc.org/man/5/The%20User%27s%20Manual The manual has a clear "extensions to the standard" page, but that has a hard assumption that you know what the standard says (you probably don't). If you assume hash tables are in the r5rs spec, you are about to waste a ton of time finding out that they aren't there. http://wiki.call-cc.org/man/5/Extensions%20to%20the%20standard http://wiki.call-cc.org/man/5/Extensions%20to%20the%20standa... When you finally come back to the "Extensions to the Standard" page, you get this: compile chicken, compiling, library, eval, extras, regex, srfi-0, srfi-2, srfi-4, srfi-6, srfi-8, srfi-9, srfi-10, srfi-11, srfi-12, srfi-15, srfi-16, srfi-17, srfi-23, srfi-26, srfi-28, srfi-30, srfi-31, srfi-39, srfi-55, srfi-61, srfi-62 load chicken, extras, srfi-0, srfi-2, srfi-6, srfi-8, srfi-9, srfi-10, srfi-12, srfi-17, srfi-23, srfi-28, srfi-30, srfi-39, srfi-55, srfi-61, srfi-62. library is implicit. eval csi, chicken, extras, srfi-0, srfi-2, srfi-6, srfi-8, srfi-9, srfi-10, srfi-11, srfi-12, srfi-15, srfi-16, srfi-17, srfi-23, srfi-26, srfi-28, srfi-30, srfi-31, srfi-39, srfi-55, srfi-61, srfi-62. library is implicit. Well great. After that standard dead-end, I've probably run into SRFI somewhere down the line (if not, I'm probably about to google one of these things). Either way, I wind up on the SRFI page. https://srfi.schemers.org/ https://srfi.schemers.org/ OK, there are FOUR hash table SRFIs. I'll go with SRFI-69 Basic Hash Tables. Looking back at those lists, srfi-69 is nowhere to be seen. More searching will sooner or later take me to the official Chicken Scheme SRFI-69 egg which thankfully is documented. Quite an ordeal. Now, if I want records, I'll know to compare that list of SRFI numbers from the extension page with the SRFI list in the SRFI website. That'll show me that I want SRFI-9. One of two things is going to happen at this point. I might find out that the Chicken wiki has an entry for records. If I miss that somehow (why isn't it in the manual?), then I'll have no choice but to read the entire specification document and be either thankful that it's short, and/or upset that I'm stuck with zero examples (unless I find the wiki along the way). http://wiki.call-cc.org/man/5/Module%20%28chicken%20base%29#record-structures http://wiki.call-cc.org/man/5/Module%20%28chicken%20base%29#... https://srfi.schemers.org/srfi-9/srfi-9.html https://srfi.schemers.org/srfi-9/srfi-9.html As you can see, that's not a good dev experience. Moving away from that, what about compatibility? It's basically not possible to polyfill C FFI, underscores in numbers, primitive IO, exception handling, optional args, and similar. I don't want to play the "does X library work" game (sometimes switching implementations is unavoidable). These things either need to be required or need to be removed from the SRFI list. Along those same lines, things like records or arrays also need to be required. Sure, they can technically be polyfilled using lists, but the performance of that will make them basically useless. I understand the "teaching language" bit, but r7rs is already too complicated for an average student to implement. Likewise, "embedded must be small" doesn't hold weight either. Embedded devs expect to have features stripped out. Saying "generators aren't available on tiny platform X" is much easier than saying that "some desktop variants include generator support; good luck". This is the primary reason why Common Lisp is seen as "business ready" while Scheme is not. Feature Stability, predictability, and documentation matter.

dannyobrien 6y ago

I just wanted to say thank you for the extensive, beautiful and well-written documentation. Always good to see.

dpc_pw 6y ago

One thing I'll never understand about Scheme/Lisp is why they need so many versions (of the standard, and of different compilers).

nerdponx 6y ago
I don't think it's entirely a matter of "need". All these implementations are independent projects. Some of them include their own features on top of the standard. Some of them focus on specific use cases and/or optimize for specific performance characteristics. Some of them are toy projects. How many C implementations/compilers are there? Even Python (which has a massive and often ill-defined spec) has multiple implementations.
- dpc_pw 6y ago
  > How many C implementations/compilers are there? I can compile same source code with pretty much any C compiler. I might be wrong, but the lisp compilers are all "slightly different". I guess scheme ones can be the same? But are they really?
  - nerdponx 6y ago
    That's fair, until you get into GCC extensions. I guess the difference is that the Scheme "core" is typically smaller and the amount of extensions is typically larger. See also: Common Lisp, which has a similar problem.