Email list hosting service & mailing list manager

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