emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Better way to require with shorthands/renamed symbols


From: João Távora
Subject: Re: Better way to require with shorthands/renamed symbols
Date: Mon, 27 Sep 2021 13:24:41 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Stefan Kangas <stefankangas@gmail.com> writes:

> joaotavora@gmail.com (João Távora) writes:
>
>> +(defun t-reverse-lines (s) (string-join (reverse (sns-lines s)) "\n")
>> +
>> +;; Local Variables:
>> +;; elisp-shorthands: (("t-" . "my-tricks-")
>> +;;                    ("sns-" . "some-nice-string-utils-"))
>> +;; End:
>
> This is really nice and straight-forward, thanks!
>
> I see one problem here.  It basically splits the require up in two:
> I need to look both at the start and at the end of the file to
> understand what is going on.
>
> In the previous discussion, Adam Porter suggested this:[1]
>
>     (shorthand-require 'magnar-string :with "^s-" :as "magnar-string-")
>
> I like that proposal a lot, but it's a bit too verbose for my taste.
> It also seems to flip the :as and :with from what I would expect (in
> Python, "import x as y" means that x is available "as" y in this file).
>
> In my ideal world, we should be able to just say simply:
>
>     (require 'magnar-string :as "s-")
>

I wrote before that something like is reasonable and sounds useful.  But
I was rash in that assessment.  Or rather, it must be very clearly
thought out.

One should understand (or perhaps, as a programmer, one _must_
understand) that the Shorthands feature works at the Lisp reader level.

It's tricky to think about the execution of that manifestation of the
'require' special and what it does at the Shorthands level.  You're
probably thinking of putting it on the top of your file, which is the
most common case, but far from the only use.  What if it happens at
non-top level, in an IF form?  What if it happen sat top level but in
the middle of the file?  It would amount to setting variables that
influence the reader during the read process.

Of course, that is exactly what Common Lisp's IN-PACKAGE does.  But that
comes with other challenges, prominent among which teaching tools like
xref, ElDoc, describe-function and completions what the "current"
shorthands are.  You see, those tools are always finding symbols in the
current buffer and they also need to know the value of
'elisp-shorthands' (soon to be renamed 'read-shorthands', hopefully).

We'd need to update 'elisp-shorthands' whenever point moves perhaps? Or
just-in-time before an 'intern-soft' is called.  That is how SLY and
SLIME do it.  Maybe.  At any rate, this is more work.  Perhaps, when we
arrive at that that point, we decide to put the effort and implement
IN-PACKAGE, since it's so well understood (...but is it? Not by some, I
fear, maybe that'll change).

For now, I'd just like people to experiment with Shorthands.

As Stefan Monnier once wrote (here?), implementing namespace systems
isn't hard in itself (it wasn't here).  It's making the tooling around
it consistent.  The latter was only possible with the Shorthands feature
because of the relative dumbness of its approach.

João





reply via email to

[Prev in Thread] Current Thread [Next in Thread]