Email list hosting service & mailing list manager

library names Alex Shinn (19 Aug 2020 04:18 UTC)
Re: library names Marc Nieper-Wißkirchen (19 Aug 2020 05:24 UTC)
Re: library names Alex Shinn (19 Aug 2020 05:42 UTC)
Re: library names Marc Nieper-Wißkirchen (19 Aug 2020 06:06 UTC)
Ideas for library names; please contribute Marc Nieper-Wißkirchen (21 Sep 2020 06:49 UTC)
Re: Ideas for library names; please contribute John Cowan (21 Sep 2020 12:34 UTC)
Re: Ideas for library names; please contribute Marc Nieper-Wißkirchen (21 Sep 2020 12:42 UTC)
Re: Ideas for library names; please contribute John Cowan (21 Sep 2020 13:50 UTC)
Re: Ideas for library names; please contribute Marc Nieper-Wißkirchen (21 Sep 2020 14:13 UTC)

Re: Ideas for library names; please contribute Marc Nieper-Wißkirchen 21 Sep 2020 14:12 UTC

Am Mo., 21. Sept. 2020 um 15:49 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

>> I didn't know that `$' has problems on some file systems.
>
>
> It doesn't.  But e.g. "chibi-scheme -msrfi.206.$all" (which is an error, of course) will confuse the shell.

That points to possible inconveniences. Possibly best to drop the "$" choice.

>> Whether something is created on the fly or not, depends on the
>> implementation. From a user's perspective, there is actually the
>> illusion that countably many identifiers pre-exist.
>
>
> In one sense, yes: a user of bignums can assume that countably many bignums exist even though there is no room for them anywhere.  (In addition, there is always an implementation restriction on the size of bignums, which may or may not exceed memory.  But this case I would mentally model it as "give me a bound identifier, creating it if necessary" rather than "this is an infinite pool of already bound identifiers".  YMMV.

I think the model with the bignums fits quite well. Consider two
libraries lib1 and lib2 which both use the magic "*" library and
import auxiliary syntax named "foo". A top-level program may use both
lib1 and lib2 and it is important that "foo" coming through lib1 is
compatible with "foo" coming through lib2.

Now it may happen that both lib1 and lib2 were compiled separately
from the top-level program and separately from each other. Thus the
view of "creating the auxiliary syntax if necessary" can only make
sense if we have the illusion that the created syntax will be stored
forever after for the benefit of later invocations of the compiler.
The "bignum model" is mentally much simpler IMHO when adding in the
possibility of AOT compilation. I would say, symbols are viewed
similarly. That they are interned is an implementation detail. From
the point of the user, one can assume that a symbol has always been
there.