Re: Imports / inclusion of s.el into Emacs

[조성빈]

João Távora <address@hidden> 작성:

> 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.

Are you calling Elisp Lisp, or are you calling the Lisp family?
I personally think that both Scheme and Clojure has a pretty consistent
std naming scheme.

> For a newcomer to Perl, there is _no way_,
> unless super lucky, to know that 'chomp' will remove the boring
> parts of a string.

… which is definitely one reason why Perl is called ‘line noise’.
(Disclaimer: I have never used Perl enough to know it’s syntax, so
 I might be wrong about it.)

> 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.

If you’re saying that new conventions should not clash with existing
conventions, that I can agree - I can’t agree that new conventions
shouldn’t clash with idiosyncrasies. That’s the point of conventions, to
remove idiosyncrasies!

> 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?

Maybe it’s not a literal question, but in my ideal world, functions that
aren’t destructive should read as nouns (e.g. trim-string or string-trim),
and ones that are destructive should read as verbs (e.g. trimmed-string or
string-trimmed).

> 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").

Well, those bike shedding can happen in this mailing list.
(FYI, I don’t think that polymorphic functions like concat should be renamed
 now.)

> 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.

Yes, it’s hard to be perfect - but that’s not a reason to be better.

> And doing it on the
> type is a bad idea, because polymorphism;

I agree that prefixing types on polymorphic functions aren’t a good idea.

> 2. make many new symbols that will confuse existing users.
> Even new users ask: why does this have two/three names?;

Which has a plausible explanation: it’s been renamed. There are a lot of
functions/variables that are already in similar state, IIRC.

> 3. encourage you to deprecate and eventually remove names,

If the old name’s use reduces and eventually becomes close to zero, yes one
might deprecate & remove names.

> which breaks programs and is a shame.

My personal view on this is that if one hates breaking things, one should
just not upgrade. However, considering that Emacs don’t really remove much,
I think just marking them obsolete will work, without breaking anything.

> > 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 saying that we should bring string-trim, string-left-trim, etc… It
was a response to this:

> Shoving this foreign
> convention down Lisp's throat is cruel. And ignorant, sorry.

It’s definitely not a foreign convention to Lisp.

> 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.

I think you don’t need to question them much is mostly because you’re
already familiar with the CL names. I actually feel this same problem when I
try to write some CL - I like the language, but the std is too inconsistent.

Cl21’s author Fukamachi explains this well on cl21.org:

> Is Common Lisp sufficiently well-designed? I don't think so. You use
> different functions to do the same thing to different data types (elt,  
> aref,
> nth). You have long names for commonly used macros (destructuring-bind,
> multiple-value-bind). There is no consistency in argument order (getf and
> gethash). To put it simply, the language is time-consuming to learn.

I think this applies similar to Elisp.

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

Nobody is trying to bring Clojure inside Elisp, nor CL. This is not something
like make Elisp look like an another language project.

> 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