Re: Do shorthands break basic tooling (tags, grep, etc)? (was Re: Shorthands have landed on master)

["João Távora" <joaotavora@gmail.com>]

Phil Sainty <psainty@orcon.net.nz> writes:

> On 2021-09-28 20:21, João Távora wrote:
>> So it sounds like you're arguing against namespaces in general,
>
> Yes, I would vote against adding this to elisp.
>
>
>> and you're right, they have disadvantages, in any language.
>> But the advantages are immense.
>
> Are they?  I don't see how they add anything at all of genuine worth.
>
> (FWIW I'm sorry that this sounds harsh, as I'm certain that a lot of
> effort has gone into this.  I just have really strong misgivings about
> the feature.)

No problem.  We can be harsh and polite to each other.  And,
surprisingly, "not much effort" went into this :-) if you see the source
code, you'll see that is fairly terse.  Certainly much less than other
features I've added to Emacs.  A good thing.

> I agree that they make code a little nicer to write for the author
> who knows what everything is.  I think this is an *extremely* minor
> benefit which everyone can easily manage without (as they have done
> for decades); and AFAICS it is the only benefit, and so I don't see
> how it is worth all of the trouble that comes with it.
>
> I firmly disagree with the notion that it makes code easier to read
> for other people.  Other people actually now have to mentally account
> for the fact that every symbol they see might not actually exist by
> that name.

I know you don't like these analogies, but when you are with your
family, do you qualify everybody by their full names?  You don't right.
It's tedious to you, as a speaker, and I suppoe it's tedious to your
counterparts as a listener.  Humans use shorthands for lots and lots of
things.  Hence the common phrase "context is everything".

My position is that human languages are no different from artificial
ones in their interaction with humans (reading and writing).  For
interactions between programs (compilers, etc) I fully agree with Stefan
Monnier that they don't care, and neither should we.

(or should we?  Have you ever needed to debug a C++ program without a
name unmangler?)

> The manual even talked about the ability for different people to use
> different shorthands for the same library, so a symbol might actually
> have *many* names in the codebase.  This makes things harder.

Namespace systems in all languagues I know are about the ability to
refer to the same thing by different names in different contexts.  I
guess I have to refer you to some recent decade's worth of language
design.

> Allowing things to not be what they seem adds an additional cognitive
> load to *everything* you look at,

I don't deny that.  There is an additional cognitive load.  My point is
that that load is comparatively smaller, MUCH smaller, than the load
incurred by reading repetitive code.  Don't forget that typing
this-long-symbol-prefix is a way of code duplication, however primitive.
And this duplication is bad, not for storage reasons, but because it
slows down the human parser tremedously.

> It makes it harder for users to share code because, even if you know
> which libraries are used, copied and pasted code can now be completely
> broken without knowledge of the magic file-local variable.

That's true, yes.  You can't share code without context.  But listen,
that already happen in a myriad of situations.  I can't paste a snippet
that refers to a global variable or funtion and expect it to work UNLESS
I give you that context.  No really, the problem you bring about is not
new.

> From what I've seen it doesn't seem that the shorthand symbols even
> exist (they are translated at read time), so if someone reads some
> shorthand code and tries to look up the symbols they see, will they
> find them?

No.  In Lisp there is the form and there the symbol.  These are not
interchangeable.  A symbol is an object, which is much more than just
its print name.  A form is a written down version of the symbol.

Shorthands are just the forms. 

> If they C-h v and use TAB completion for the prefix they are seeing in
> the code, will they see all the completions?

No. The shorthands are local context.  So if they type C-M-i they will
see it, but with C-h v you see the full name of the symbol.  Which is
always valid, of course.

> If so, will that work in all buffers, in all locations?

No.  You may be known under different nicknames in your family, your
Yatch clubetc.  Mixing up your nicknames in those different contexts
would be disastrous.

> If they get to the help buffer and they try another look-up, will it
> then fail?

You lost m at this point.

> Or if they simply have split windows and are reading code from the
> other window?  What if different libraries specify the same shorthand
> for different dependencies?  Can people only look up certain symbols
> from certain places?

Again, it seems you are against the idea of namespaces in general in any
language.  But indirections is what hight-level programming is about.
You don't have to use all of them, and neither should you, but I firmly
believe you should have access to them.  Namespaces, generic functions,
advice, hooks, macros, functions.  All these things to "hidden" things
that you have to chase down.  If you don't want any of it, you have to
be ultra-literal.  You have to use machine code, not even assembly.

>> To organize complex problems utilizing many libraries, I cannot
>> imagine a decent language that does not have them.
>
> How do namespaces help with that?

By allowing you to compose programs from many different libraries in a
way that you don't write a mammoth prefix all the time.  You can choose
what prefix you assign to each library's symbols.  "fn" for the bunch of
"file-name" stuff you're going to do.  "s" for the bunch of
"magnars-string" stuff you're going to do. "phil" for the bunch of
"phils-incredible-library-of-utils.el" stuff you're going to do.  That
is how.

> Furthermore Emacs Lisp is not other languages, and Emacs is unusual.

Yes, Emacs is unsual.  Especially in the developers ahahah (me included,
of course).

But Emacs Lisp is not much different than other languages.  It's a
Lisp-2 with many features of Common Lisp.  Probably has more much devs
than Common Lisp, and a younger generation at that.  Probably has more
future, I'd say.  Needs a better GC.

> It combines a very large amount of global state (which most programs
> do not do)

Obviously that depends on the programs you write and how you write them.

> with dynamic binding (which most languages do not have).

And which shouldn't be abused, BTW (and here you go dynamic binding!
Another super-useful feature with lots of tricky hidden behaviour.  Oh
the cognitive load!)

> Surely "other languages have this" isn't a reason to add something to
> elisp unless there is a clear net win to doing so, and all I'm seeing
> are net losses.  What are the advantages that I'm not seeing which are
> so immense that they make all the problems worthwhile?

I've described them.  Again I refer you to all major languages that have
namespacing systems.  Or to the fair number of people that have
expressed want of a namespacing system in Emacs.

It's like you're asking me to describe to your why global variables are
useful.  Some people avoid them like the plague, they hide behaviour.
You need context.  There's cognitive load to understand a problem with
global variables.  But just like shorthands, they're opt-in.  You don't
_have_ to use them in your programs.  You can object to them in other
peoples programs, same thing.

> programming language; and I couldn't figure out what the "expressive
> power" of shorthands might be.

That is quite clear to see :-)

João