[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: Sun, 3 May 2020 23:51:54 +0900

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

On Sun, May 3, 2020 at 11:55 AM Stefan Kangas <address@hidden> wrote:
Philippe Vaucher <address@hidden> writes:


split-string aliased as string-split

This is a better name. FWIW, I think the old one should be deprecated too.

People coming from Common Lisp and not Clojure will find 'split-string'
more appropriate.

Now really, I don't think this "prefix with the type name" makes
any sense.  When I learned Lisp coming from Java, it bothered me,
yes. But I got over it, quickly. Functions in lisp are generic, or at least
duck-typed. If in Haskell or Ruby the name of the operated-on type
always  matches the namespace qualifier, good for them I guess. I know
0 Haskell, but last I checked those Ruby functions aren't top-level
functions, they're methods on a String object. So that just reflects a
different way to look at OO.  I often use it when in those languages, but
in Lisp there's a different take to it.  So the namespace qualifier doesn't
necessarily bear any direct relation to type of the object being operated
on [1]. Sometimes it does, yes, but it's accidental. Shoving this foreign
convention down Lisp's throat is cruel. And ignorant, sorry. (ignorance
isn't a defect, it's a default).

OK, so nobody is really forcing that ’split-string’ should be aliased
as ’string-split’. What people want, is *not* a OO-based naming scheme
- it just needs to be consistent. If you think ‘traditional’ Lisps should
follow a verb-noun scheme for non-polymorphic functions and only verb for
polymorphic functions, then that’s fine. Then the user can predict that…
when one wants to split a string, one can search it with ones that start
with ’split’.

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.

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

The point of doing it, I suppose, is that it
would bring in lots of newcomers onboard. But shouldn't we rather be
welcoming them by efficiently showing them them the joys of
Javalessness instead?

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.

Do we need a manual with pretty pictures
and fancy fonts? Let's do it then.

OK, ranting over. In CL-land, there is the very good split-sequence[3],
which is a generalized split-string (and compatible with the "split the
empty string" case). I propose we get that instead.  If we're lucky, that
CL code is directly translatable to Elisp (seems to be from a cursory
inspection). Yeah call it seq-split if you really must drink the kool-aid.

[1]: The lack of a package system in Elisp (not package.el, mind you
that's a different thing) adds to the confusion, but it's really the same.
[2]: http://quickdocs.org/split-sequence/


reply via email to

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