News for hackers. Stuff that matters.

A comment on Cyclone Scheme.

Re:Cyclone Scheme by hajile on Tuesday October 06, 2020 @10:54AM (#24698274)
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

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%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/

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#...

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.

[ Parent | on HN ]
Re:Cyclone Scheme by ar-nelson on Tuesday October 06, 2020 @11:05AM (#24698400)
In theory, R7RS Large will fix the discoverability problem by picking a single blessed SRFI implementation of each kind of library, and giving each one a name like (scheme hash-table), etc. Whenever it's done. And who knows when that will be.

In the meantime, I'm in the process of building my own "alternate prelude" for several R7RS Schemes that chooses the latest SRFI for most of the common features you'd want (strings, hash tables, console text formatting, etc.) and polyfills them for Schemes that don't have them: https://github.com/ar-nelson/schemepunk

Also, the compatibility story in R7RS is better than you'd think. The biggest problem is that a lot of R7RS implementations are incomplete and don't conform to the standard. For the ones that do, it feels similar to JavaScript in the early 2000s: lots of little inconsistencies, but they can be polyfilled over with enough work. Someone just needs to give it the Crockford treatment and isolate the "good parts" that can be shared between implementations.

[ Parent | on HN ]
Re:Cyclone Scheme by thibran on Tuesday October 06, 2020 @01:17PM (#24700155)
> In the meantime, I'm in the process of building my own "alternate prelude"

I'm thinking more and more about doing the same. But – there is always a but – I also dislike some other things:

Fix procedure signatures → Why is there 'remove' and 'delete'? Scheme is not statically typed, but strangely enough, this fact in not exploited often. There should be only one word with the meaning "delete" in the programming language.

Fix argument positioning → The order should always be: proc-name, main-object, arguments... Ideally one should be able to guess the name and arguments of a procedure.

Fix procedure names → Some procedure names are too long or have strange names. List procedures should have a list- prefix, only Transducers or generic procedures should have no prefix.

Also maybe stop supporting a :key argument and design everything to use lenses to target sub-structures.

Some handy general purpose procedures are missing here and there, so an improved prelude should come with them, too. I don't want to import multiple string/list/whatever-libraries to handle a task. The nice thing about Scheme is, all of this is doable.

[ Parent | on HN ]
Re:Cyclone Scheme by anentropic on Tuesday October 06, 2020 @12:43PM (#24699756)
I also feel like it would be useful for Schemes to have a common FFI interface.

Currently AFAICT (I don't know much, so might be wrong...) each Scheme implementation has its own FFI. So even though pure-Scheme R6RS or R7RS libraries are portable across multiple Schemes I don't think any Scheme libs which are wrappers for C libs are (?)

But these C libs are often vital to many projects.

I found this attempt at such a thing: https://github.com/ktakashi/r6rs-pffi ("R6RS Portable Foreign Function Interface")

But I didn't find many libs which were written on that PFFI. What I mostly see are libs specific to a single Scheme implementation.

Would love to know if my impression here is correct or if things are actually better than that?

[ Parent | on HN ]
Re:Cyclone Scheme by slaymaker1907 on Tuesday October 06, 2020 @04:17PM (#24701875)
Just look at Python to see how difficult this is. It's hard to specify a FFI which doesn't assume a bunch of things about the implementation of the language. Racket is also having some pain points with this in the move over to the Chez Scheme backend.
[ Parent | on HN ]
Re:Cyclone Scheme by anentropic on Wednesday October 07, 2020 @05:33AM (#24706575)
Python is different since most people use the same implementation (I realise the whole FFI situation there is currently undergoing an overhaul to better support PyPy)

And https://github.com/ktakashi/r6rs-pffi seems to show that such a thing is possible for Scheme as it supports half a dozen different R6RS Schemes, but (I believe?) it needs library authors to target the PFFI interface rather than the implementation-specific FFI interface of a particular Scheme as most do currently.

So it seems like that shows that a compatibility layer is possible, at least for many of the major Schemes, and it "just" needs standardisation and adoption.

[ Parent | on HN ]
Re:Cyclone Scheme by hajile on Tuesday October 06, 2020 @11:12AM (#24698497)
They've been working on r7rs-large for at least 7 years and last I looked had less than 20 SRFI approved. I know they do it on their free time, so no gripes about them. The point is that at the current rate, I'll be retiring before they finish.

r7rs-large also doesn't fix issues where some SRFI must be in the r7rs-small spec to ensure cross-implementation compatibility. They need a r7rs-standard which adds these features over the minimalist r7rs-small while retaining r7rs-large as additional libraries.

[ Parent | on HN ]
Re:Cyclone Scheme by slaymaker1907 on Tuesday October 06, 2020 @04:14PM (#24701856)
I think in general R7RS-large is supposed to be what mainline implementations implement with R7RS-small mainly being for implementations used for embedding scheme as part of a larger application (and even then you might still use large) as well as for experimental/hobbyist implementations.

Particularly if you are just using scheme as a scripting language which mostly calls out to C, it doesn't necessarily make a bunch of sense to include complex features like reflection or weak boxes. Such an implementation might not even have a GC in the first place and just rely on the scheme process ending to release memory back to the OS.

[ Parent | on HN ]
Re:Cyclone Scheme by hajile on Tuesday October 06, 2020 @11:01AM (#24698365)
To the Cyclone devs, If you want real-world users make sure you address the glaring documentation issues.

I'd recommend moving the SRFI list to a footnote. Have your own API documentation with examples. Instead of SRFI-69, have an entry for hash tables. Mention at the bottom that you comply with SRFI-69 with a link to the spec, but have your own docs that show how to use those APIs instead. Also make sure you document all the r7rs-small functions and data types too.

[ Parent | on HN ]
Re:Cyclone Scheme by justinethier on Tuesday October 06, 2020 @11:15AM (#24698536)
We have our own pages such as:

http://justinethier.github.io/cyclone/docs/api/srfi/69

Admittedly this does not include examples.

Perhaps it needs to be more clear that the API documentation contains links both to our internal docs as well as the official SRFI pages:

http://justinethier.github.io/cyclone/docs/API#srfi-librarie...

[ Parent | on HN ]