[Top][All Lists]

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

Re: Imports / inclusion of s.el into Emacs

From: 조성빈
Subject: Re: Imports / inclusion of s.el into Emacs
Date: Mon, 4 May 2020 03:12:09 +0900

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

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

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.


reply via email to

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