Scheme news

http://trac.sacrideo.us/wg/wiki/WG1Ballot

Third ballot for R7RS. Do you like where it's heading?

Now that we have blobs, we have to decide what to call them. R6RS uses bytevector, SRFI-4 and SRFI-68 uses u8vector, while the original WG1 proposal used blob (which is therefore the default).

    * Options: blob, bytevector, byte-vector, u8vector, octet-vector, undecided
    * Default: blob
    * Preferences:
Blob is pig-disgusting, use bytevector

Three things:

- The WG1 should use a better record syntax, easier for WG2 to eventually extend without breaking compatibility. SRFI-9's syntax is just impossible to extend easily.
I'd probably choose either http://trac.sacrideo.us/wg/wiki/RecordsArcfide.
- Change the ``unspecified value'' to ``unspecified values''.
- Syntax-case instead of er-macros in WG2. Most of the time, you just want hygiene. Breaking hygiene is the exception, not the rule, and it should be done explicitly.

I'm ok with the rest. Modules and cond-expand (not segregated inside an SRFI) basically fixed the 90% of the problems with Scheme.

>>2
They should call them u8vector, since WG2 will have u16/u32/s16/...-vectors too. I don't like blob either.

>>3
1. https://groups.google.com/group/scheme-reports-wg2/browse_thread/thread/7ac79e8f0a1511a0
2. No, breaking perfectly fine old code for negligable benefit is retarded.
3. Yes, but keep it the fuck away from the WG1 diamond.

>>2,3
The difference between a blob and an u8vector is that a blob is just some memory, that we happen to access 8 bits at a time by default for practical reasons. You could access it 80 bits at a time and it would make sense too, but accessing an u8vector 10 items at a time makes no sense.

Chicken has blobs that can't even be accessed without using a SRFI 4 conversion, but putting SRFI 4 in WG1 would be overkill.

http://wiki.call-cc.org/man/4/Unit%20library#blobs
http://wiki.call-cc.org/man/4/Unit%20srfi-4

>>4
1. https://groups.google.com/group/scheme-reports-wg2/browse_thread/thread/7ac79e8f0a1511a0
That's not reinveinting much, it's a subset of R6RS records.
It doesn't even add functionality, it's practically just an alternate, friendlier syntax for SRFI-9 records, modulo the filtering constructor.
There are two macros in the proposal: define-record-type on top of define-disjoint-type, and define-disjoint-type in terms of define-record-type. The first will work forever if you put it in a srfi 9 module, the second will break as soon as WG2 will do any minor change to the record system.
Backwards compatibility is retained. SRFI-9 is not enough anymore, let's move on.

2. No, breaking perfectly fine old code for negligable benefit is retarded.
Yeah, but no. Implementations that return that obnoxious #<unspecified> value are still conformant. Chicken effectively returns 0 values.
If this change is not done, I'm not going to kill myself in despair, though, I'm more worried about the record system.

3. Yes, but keep it the fuck away from the WG1 diamond.
I agree. It's too much for WG1, especially because it would complicate the module system too.


I don't see the need of blobs in WG1.