Re: Imports / inclusion of s.el into Emacs

[João Távora]

On Sun, May 3, 2020 at 3:52 PM 조성빈 <address@hidden> wrote:
>
> João Távora <address@hidden> 작성:
>

> The problem here is current Elisp isn’t predictable enough. Is it
> string-trim or  is it trim-string? Is it string-join or is it join-string?
> Is it string-split or is it split-string? And that’s the problem this
> proposal is trying to solve.

OK I see. And I agree to a point. It's just Lisp doesn't care so
much about it.  For a newcomer to Perl, there is _no way_,
unless super lucky, to know that 'chomp' will remove the boring
parts of a string.  Predictability from names is not useless, but
is overrated, because it will only tell you so much and it works
better in some languages versus others.

And introducing new conventions that clash with the existing
idiosyncrasy is _not_ the best way to solve it.

And people have demonstrated here over and over how it fails.
Say you don't like an hypothetical "frob" and you decide to make
a "string-frob" or "frob-string".  Now can you predict from that name
if it's destructive or not? And can you use return value? What if
you can "frob" more things than a string? Sequences, multi-dimensional
arrays, characters?  What if frob already exists and can be both
a verb or a property (like "match"). It's a losing game.  Yes, some
people have played it (and mostly lost) and these names are burned
in the namespace. Because culture.  Nothing to do about those.
If you start renaming things for predictability it'll:

1. be quite hard to get right, if at all possible.  And doing it on the
type is a bad idea, because polymorphism;
2. make many new symbols that will confuse existing users.
Even new users ask: why does this have two/three names?;
3. encourage you to deprecate and eventually remove names,
which breaks programs and is a shame.

> BTW, a quick check from sly shows me that cl:split-string doesn’t exist
> - while cl:string-trim, cl:string-left-trim, cl:string-right-trim exists.
> Which probably means that it’s not really a foreign convention in Lisp.
> (And Elisp already adopted the convention of prefixing the module name
>   in the front, which was the reason this discussion started.)

CL is foreign to Elisp, whether you like it or not (I don't, of course
but hey...). It's just not _as_ foreign. If we're going to import things
from CL I'd rather bring in specific CL features like restarts, packages,
streams, multiple values.  Definitely _not_ function names. I'm not
in love with CL's names: I just know them and don't question them
so much, like names of people. Lisp is a language of symbols and
symbols have names you learn. The function of a symbol is only
_one_ of its many facets anyway. So when bringing new symbols
into the world you shouldn't try to be too clever about the name.
Be just moderately clever.

BTW Aren't there more interesting parts of Clojure other than the
symbol names?

And "module name" is a broken convention. It's the best we have
so we might as well, but what is the module for 'car'?  Again, for
the sixteenth time, if we had packages, it would be solved: nobody
touches the :EL package but everyone can make their own fancy
"predictable" utilities package.

_THE_ way to solve is is to transform s.el into magnar-string.el
_BUT_ because of the lack of a package system, that means we
have to (magnar-string-truncate 42 s) which is a pain in the s, I'll readily
admit that. You should be able to say: "I want to use magnar-string.el
_here_ because great Clojure god".  And then type (truncate 42 s),
(left s 3), and be done with it. Or use the local "s" nickname and type
(s:truncate 42 s) and (s:left s 3). But you can't, so you want to shove
it, figuratively ;-), in the main library but that's really hard and
controversial and for every compromise you make you start
doing the original s.el library less and less justice.

> Seriously, a consistent std is *not* Java. See almost every programming
> language - consistency is something that people value. It’s not always
> the answer, but it’s something that people value & appreciate.

A std that changes according to the language-du-jour is not a std
by definition.

João