Re: Imports / inclusion of s.el into Emacs

[조성빈]

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:
> >
> > > Aliases:
> > >
> > > 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/
>
> João