GNU bug report logs - #72160
29.3; package buglet

Previous Next

Package: emacs;

Reported by: Devon Sean McCullough <Emacs-hacker2023 <at> jovi.net>

Date: Wed, 17 Jul 2024 16:18:02 UTC

Severity: normal

Found in version 29.3

Fixed in version 31.1

Done: Stefan Kangas <stefankangas <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Philip Kaludercic <philipk <at> posteo.net>
To: Devon Sean McCullough <Emacs-hacker2023 <at> jovi.net>
Cc: 72160 <at> debbugs.gnu.org
Subject: bug#72160: 29.3; package buglet
Date: Sun, 21 Jul 2024 16:17:12 +0000
Devon Sean McCullough <Emacs-hacker2023 <at> jovi.net> writes:

> On 2024-07-21 05:59, Philip Kaludercic wrote:
>> Devon Sean McCullough <Emacs-hacker2023 <at> 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




This bug report was last modified 130 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.