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