Re: Imports / inclusion of s.el into Emacs

[João Távora]

On Sun, May 3, 2020 at 7:12 PM 조성빈 <address@hidden> wrote:

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

As far as I know, Scheme is minimalist, and has modules.  Common
Lisp and Elisp are not minimalist.  And Elisp doesn't have modules,
possibly because no-one ever thought it would be one of the most
popular Lisps. And Clojure as far as I understand, doesn't have
to deal with a class of problems such as mutable version of each
function, and crucially, has namespaces. So you have multiple
reverse's apparently.  One in clojure.string, another in clojure.core.
You _don't_ have string-reverse and seq-reverse (again, I may
be wrong).

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

Perl has lots of flaws, but its terse names are not it, IMO.

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

But the one you're proposing is too ambitious and flawed.

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

Yes, I've used that convention in the past. C.f sort and sorted.
But it doesn't always work, because English is irregular.

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

It already does to a point.  But we tend to leave old stuff alone.

> (FYI, I don’t think that polymorphic functions like concat should be renamed
>   now.)

I would think the value of s.el comes from the consistency between
its members.  I would really just like for Elispers to be able to use it
without encroaching on the legacy namespace.

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

[To _not_ want to be better, you mean. ]

Yes, than I will turn that argument around.  We're not that
far away from perfection that it warrants new names.

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

Once you start thinking of by operations rather than
by types, many functions become generic.

A big flaw in CL is not having gone far enough with generic
functions. i.e. most people agree that generic arithmetic
+, -, would be a tremendous gain.  I guess the money ran out :-),
so now +, - etc only work with numbers.  Should we rename them
number-+ and number-- in Elisp, for predictability? :-)

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

In specialized domains, but not in the base general purpose
library.

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

How can it become close to 0? What about old programs?

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

Couldn't disagree more.  Old programs are useful.  I want them and their
dependencies to load cleanly, so I can study them. The real-world
equivalent to your idea is just throwing away old books.

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

Doing it in the scale that you originally proposed would be. And
string-trim etc, already exist in Elisp.  In the "foreign" purgatory
of subr-x.el.  Curiously, there is this comment there:

;; Less commonly used functions that complement basic APIs, often implemented in
;; C code (like hash-tables and strings), and are not eligible for inclusion
;; in subr.el.
;; Do not document these functions in the lispref.
;; https://lists.gnu.org/r/emacs-devel/2014-01/msg01006.html

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

It's the weight of history.  But in CL there are multiple attempts (curiously
not particularly successful) to write a modernized library. You can use
one of those, and they fit snugly in a package. You can make that
package your default package, if you wish and enjoy its benefits.

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

Oh, so you did find it. That is one of those attempts. But there have
been more, I think.

But I disagree with Fukamachi, or at least I think it is very naive. CL21 is an
interesting project, but CL is time-consuming because it is big, not because
of function names or signatures., but the many programming paradigms in
one language: functional, imperative, OO, meta, exceptions, systems
programming...  It's enormous. It's not CL21 that's going to "fix" that.
Really, the "learning names" problem is vastly overstated.  It's only for people
who use the language once in a while.  But that also happens for other
languages. I just quickly skim a manual before I get back to them. Of course
CL21's authors are trying to appeal to that new impatient blood that's flocking
to Clojure.  But they're flocking to Clojure mainly for the libraries, Java
interop, concurrency features, and the real-life jobs, not really the names.

By comparison, the only language as ambitious as CL that I know is C++.
Same hunger for general-purpose, multi-paradigm, meta-functional-system,
imperative-type-hungry language . All backward-compatible. A work of art.
 _That's_ a time-consuming programming language. And they're adding
and adding to it, to make it sexy for the cool kids.  Are they succeeding?
Open question.

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

Oh but I wouldn't think it that to be a bad thing, on the contrary.  I was
asking honestly: is the best thing in Clojure the names of the functions?
I find that hard to believe.

João