Email list hosting service & mailing list manager

Editorial nits; define-record-type John Cowan (02 Sep 2015 20:27 UTC)
Re: Editorial nits; define-record-type taylanbayirli@xxxxxx (03 Sep 2015 12:05 UTC)
Re: Editorial nits; define-record-type John Cowan (03 Sep 2015 13:33 UTC)
Re: Editorial nits; define-record-type taylanbayirli@xxxxxx (03 Sep 2015 15:01 UTC)
Re: Editorial nits; define-record-type taylanbayirli@xxxxxx (03 Sep 2015 15:31 UTC)

Re: Editorial nits; define-record-type taylanbayirli@xxxxxx 03 Sep 2015 15:31 UTC

xxxxxx@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes:

> And if not that, then adopt R6RS hashtables as-is into R7RS please!
> After all, there is already (r6rs hashtables) which makes that API
> available on all R7RS systems.  This means "SRFI-69 is more widely
> supported" is not an excuse.

Correction: it would be kind of an excuse if there were more SRFI-69
using Scheme code out there and if the new proposed API were a backwards
compatible extension of SRFI-69, but it seems that code changes will be
necessary anyhow.  And as mentioned, R6RS improves on SRFI-69, doesn't
merely change names.

I would be fine with it if the newly proposed API built on SRFI-69 but
extended it in such a way that its limitations are removed, so it's at
least on the same level as R6RS in terms of features.  If that's
impossible, then the most minimal amount of backwards-incompatible
changes necessary to remove said limitations might also yield an
acceptable new API (e.g. if a big majority of SRFI-69 using code keeps
working without changes, despite the small changes in the API).

Still, the much simpler route is to just take R6RS hashtables and go
with that one.  Code using SRFI-69 can keep doing so until the author
feels like switching to R6RS hashtables.

Taylan