This page is part of the web mail archives of SRFI 44 from before July 7th, 2015. The new archives for SRFI 44 contain all messages, not just those from before July 7th, 2015.
> From: scgmille@xxxxxxxxxxxxxxxxxx > > You have an interface spec that gives two names to one specification. > > Hello?!?! Anybody home? > You clearly didn't read *-get-left, *-get-right for the other > collection=20 types. I will ask you again to read the SRFI > carefully. We have in '*-get-{left,right}' a proposed naming convention. Both meta-names name the same thing, according to the spec. The spec does not provide any information on either: *) why an implementor should choose one name over the other *) why a system that relies on the naming convention should use one name in preference to the other So, what's the point of them? Neither users or implementors are benefited by the distinction. You're saying: well, look at how they're used for particular collection types. Swell -- summarizing how they are used is the job of the naming convention spec: a job left undone in this case. What is the value of this apparently contentless naming convention distinction? Why don't we also have (with the same spec): *-get-middle *-get-left-of-center *-get-favorite *-get-niftiest *-get-ugliest *-get-top *-get-bottom *-get-sideways *-get-easiest-to-get *-get-hardest-to-get *-get-random or, in general: *-get-<meaningless-adjective> I don't know if you've noticed but, you know, quite absent any srfi, people regularly write code that uses naming conventions that "fit" with intuitive expectations and emulate existing standard interfaces. What value is there in a srfi that says "*-get-left implies some intuitive expectations (but we won't try to say what those are). -t