naking in srfi-167
Per Bothner
(19 Apr 2019 05:03 UTC)
|
Re: naming in srfi-167
Per Bothner
(19 Apr 2019 05:14 UTC)
|
Re: naking in srfi-167
John Cowan
(19 Apr 2019 06:00 UTC)
|
Re: naking in srfi-167
Amirouche Boubekki
(19 Apr 2019 13:38 UTC)
|
Re: naking in srfi-167 Marc Nieper-Wißkirchen (19 Apr 2019 13:42 UTC)
|
Re: naking in srfi-167
Amirouche Boubekki
(22 Apr 2019 09:57 UTC)
|
Re: naking in srfi-167
John Cowan
(22 Apr 2019 15:27 UTC)
|
Re: naking in srfi-167 Marc Nieper-WiÃkirchen 19 Apr 2019 13:42 UTC
Am Fr., 19. Apr. 2019 um 15:38 Uhr schrieb Amirouche Boubekki <xxxxxx@gmail.com>: > > > > Le ven. 19 avr. 2019 à 08:00, John Cowan <xxxxxx@ccil.org> a écrit : >> >> Agreed. Looking at SRFI 168, however, I thought they might be just local conventions for parameter names. >> >> The relation between the two SRFIs is not really made clear anywhere. > > > The relation between this SRFI 167 (okvstore) and the Generic Tuple Store Database SRFI 168 (nstore) > is made by the `engine` type. `engine` takes as first parameter an object as return by okvstore:make > and the following parameters are the other procedures defined in this SRFI 167 except `pack` and `unpack`. > > `pack` and `unpack` are supposed to be used in the implementation of SRFI 168 (nstore) but they are not > part of the parameters passed to `engine` for some reason. I just figured that. > >> >> >> On Fri, Apr 19, 2019 at 1:03 AM Per Bothner <xxxxxx@bothner.com> wrote: >>> >>> Without getting into the meat of this srfi, the names seem awkward. >>> Most obviously, there is a set! operator, which conflicts with r7rs. >>> The 'make' procedure conflicts with (at least) Kawa and Guile. >>> The 'range' name might be better saved for a procedure that returns >>> a "range" (sequence of integers) value. >>> >>> Obviously all of these can renamed on import, but it seems rather contrary >>> to Scheme naming conventions. > > > I chose the names with r7rs prefix import in mind. Indeed, if there is no way to > prefix imports or rename this won't work. There was a similar discussion about the names in SRFI 165. The discussion's upshot was that SRFIs intended to be included in R7RS-large should choose names that are unique without prefixing or renaming. -- Marc > >>> -- >>> --Per Bothner >>> xxxxxx@bothner.com http://per.bothner.com/ > > To unsubscribe from this list please go to http://www.simplelists.com/confirm.php?u=Iv39SLL8JKn16Xoj08EgsTTVKIlgFzfk