bug#72160: 29.3; package buglet

[Philip Kaludercic <philipk@posteo.net>]

Devon Sean McCullough <Emacs-hacker2023@jovi.net> writes:

> On 2024-07-21 05:59, Philip Kaludercic wrote:
>> Devon Sean McCullough <Emacs-hacker2023@jovi.net> writes:
>>> Strings and symbols should be equally acceptable package designators.
>> We can improve on that error message, but is there any use-case for
>> denoting a package by a string?
>
> Consistency -- load-library takes strings.
> Features, libraries & packages all fill the same needs
> so require should take strings too.

Load-library takes a string, and signals an error if you pass it a
symbol.  My take: This makes sense, since the string is denoting a file
in `load-path'.  Symbols on the other hand are a kind of "protocol"
between (provide ...) and (require ...) expressions, and abstract over
loading of files, e.g. by not loading a feature that has already been
required before.  Packages on the other hand are another level on top of
features, that also happens to use symbols, but with a different intent.

So to me, consistency means keeping these levels of abstraction
distinct, and not coercing inputs to match more than we do already
(e.g. with the assumption that packages always provide a feature of the
same name).

Again, what I wanted to know of there was a practical use-case for
packages to accept string; there is probably little point in discussing
matters of taste here.

> 		Peace
> 			--Devon
>
> P.S.  Symbol/string dichotomy exposes implementation
> details not germane to the user's task.
>

-- 
	Philip Kaludercic on peregrine