>> Based on this I believe it describes the specification.

> 

>That's correct. It's been slightly modified in places where it said

>things like "left to the implementation" and I was able to verify what

>the current implementation in Guix does.

 

I assume Guix->Guile.

 

This modification of “left to the implementation” -> “what Guile does” is problematic, since it misleads readers into thinking this is the standard behaviour (it is after all named SRFI 64, not GRFI 64).

 

“What Guile does” is also important information to have.

 

To avoid this problem, when it documents a choice made by Guile, it should indicate in some way that this is Guile behaviour.

(E.g.: “It is left to the implementation what happens when A. Guile chooses to B.”, or “It is left to the implementation what happens when A. Guile currently chooses to B, but may choose differently in future versions.”)

 

To be fair to Guile, this is a problem caused by the reference implementation coming directly from SRFI 64. It doesn't properly follow its own specification.

I believe most Scheme implementations that support SRFI-64 just use the reference implementation, just like Guile does, so one could even say: There's the "on paper" standard of SRFI 64 (the spec), and then there's the de facto standard of SRFI 64 that basically all implementations use (the reference implementation provided by the SRFI 64 author), and Guile uses the latter like every other Scheme implementation.

I think the spec as written is more useful though, so I've made my implementation actually conform to it. Mainly, there's one significant difference: The test runner returned by `test-runner-simple` shouldn't use its `aux` field (and the spec explicitly claims that it doesn't), so users can use the simple test runner as a basis to extend upon, using the `aux` field to store any state that their custom extension to the runner may need to store. The `test-runner-simple` returned by the reference implementation actually *does* use the `aux` field for something internal already (name of a log file), in direct contradiction to what the spec states.

>> I think either of those is fine (albeit describing the Guile's flavor

>> would be preferred), but is should be stated (that the behavior

>There's not really a Guile flavor; it's more like the reference

implementation flavor ;-).  The one in Guile is pretty stock.

 

Then Guile flavour is stock flavour, and stock flavour isn’t specification vanilla. From what I’ve heard, it’s not just sprinkles added to vanilla, it also has bugs (not the crunchy food kind).

One or two bugs in the upstream reference implementation were actually fixed after I had pointed them out. From a quick glance, it doesn't seem Guile ever bothered to update, though, so I guess Guile still has them.

Further, on July 30, Tomas Volf sent a large number of SRFI-64 bug reports to the bug-guile mailing list. I didn't have time then, but will be responding to them now... I can see at least one clear bug he seems to have found, which my implementation doesn't seem to suffer from (simply thanks to clean coding practices). Maybe I'll find a couple more to fix, because my implementation was originally derived from the reference implementation so may still be sharing bugs with it. Some of them seem like issues with the spec instead... Anyway, I'll respond to them one by one.

Thanks for raising these issues,

Taylan

P.S.: I've been sending HTML email using Thunderbird lately. If it messes up the formatting too much, please do complain. Some of my contacts use HTML, and I haven't yet found a way to switch back and forth quickly in Thunderbird.