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)
|
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.