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:04 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:01 UTC
John Cowan <xxxxxx@mercury.ccil.org> writes: > Taylan Ulrich Bayırlı/Kammer scripsit: > >> >From what I can tell, SRFI-69 is obsoleted by the R6RS hashtable API. > > I think that's an exaggeration. As far as I know, Chibi, Chicken, and > Husk support SRFI 69 but not R6RS hashtables, and Gauche's native hash > tables are close to SRFI 69. Among R5RS implementations, SISC, STklos, > and even SigScheme support SRFI 69. That's a fairly substantial presence. An implementation that supports SRFI-69 and R7RS also supports R6RS hashtables thanks to the (r6rs hashtables) library. An implementation that supports neither R6RS hashtables directly nor the R7RS feature-set is in dire need of modernization. > In addition, I intend to propose a new hash table SRFI, available in > pre-SRFI form as <http://trac.sacrideo.us/wg/wiki/HashTablesCowan>, > which is much closer to SRFI 69 than to R6RS. (Note that the > Implementation section is obsolete now that Will Clinger has written > a full implementation of it, which uses R6RS if available and SRFI 69 if not.) I think we discussed that one before, but I have serious problems with that one: - It extends neither SRFI-69 nor R6RS hashtables; it's something new entirely. What the heck? - It regresses from R6RS hashtables in that keys aren't allowed to be mutated, even if it's a eq?/eqv? table. A totally needless limitation that prevents a whole class of use-cases of hashtables which is to create *arbitrary* object associations. - It standardizes a *ton* of utility functions, and the bimap type, yet no weak tables support is standardized. Pretty please, take the R6RS API, add rudimentary weakness support (just a couple new constructors and predicates?) and be done with it. I would have thought that's the most obvious next step from R6RS hashtables. 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. All those utility functions can be made into a library outside the standardization process, which would become a de-facto standard if people like it. Same with bimaps (unless they cannot be implemented purely as a library). The whole effort to standardize these as a part of Scheme is huge amounts of wasted effort and contains dangers of standardization accidents that will diminish the credibility of the RnRS *even* further. I love some of your contributions, but that page makes me panic. Sorry for going off-topic, and perhaps being very opinionated on this one. Taylan