RE: Imports / inclusion of s.el into Emacs

[Drew Adams <drew.adams@oracle.com>]

>>> In Haskell, do you name every function with a
>>> prefix that advertises the type of its return
>>> value or one of its main arguments?
>>
>> [... replies pointing out that some Haskell
>> functions do prefix their names with type names...]
>>
>> I suggest those of you who think that Haskell
>> too deserves type-name prefixes for all its
>> function names start an initiative to rename
>> its `map', `add', `zip', `head', ... functions.
>
> notice how in Haskell there is a strong will to
> group things together. That's what you'd take out
> of the example.

Of course.  In Haskell and in life generally.  Things
that are alike generally belong together.

But this discussion is about _naming_ functions, vars,
etc., not just grouping them.  In Elisp, grouping them
in a library already gives them a library prefix.  And
in general that has nothing to do with the type of
objects they use or return.

I should also point out that my initial question was,
in particular, about Haskell code that you write,
(e.g. for an application), not Haskell library code.

In the wide world there are many, many more functions
that _use_ objects of various kinds (types, classes)
than just the functions that are needed to _define_
those kinds.

That's especially true of a language like Lisp.
What you call "generic functions" are not corner
cases in Lisp.

It's even true of a typed functional language like
Haskell, I think: lots of functions need not be
associated with just one data type.  (They're
type-grouped by their signatures, of course.)  But
forget Haskell as example, if you're not convinced.

It's true of Lisp, in any case (even CLOS).

But it's not true of OOP.  In most OOP languages
you pretty much _have_ to place a function in some
class, e.g. as a method (which typically privileges
one of its args as the target object (which is in
that class).  (But in most OOP, there's no need to
add the class name as part of each method name.)

It can make sense to adopt a prefix convention for
functions that define a type of thing (e.g. buffer,
window, vector, string) than it does to impose it
willy-nilly way on functions that might just return
such a thing or accept it as one of their args.

Most functions do not fit that bill of defining a
thing type.  And many (most?) do not fit the bill
of acting only/mainly on one particular type of
thing or having as their main purpose to return
such a thing.

That was really the point.  Perhaps there are some
cases in Elisp where it would make sense to prefix
more functions that involve a particular kind of
thing.  I've acknowledged that.  And others have
said the same thing, citing strings as a type that
might be looked at more in this regard.

My preference would not be to name string-related
functions as a whole with a `string-' prefix, but
instead to consider them on a case-by-case basis.

(That said, I don't disagree with what Tomás said
about having "some vision as to which direction
those renames should tend to, if one wants to have
some overall consistency."  And I agree with him
that your proposal can serve discussion, and so
is part of the process.)

The functions in a library (especially 3rd-party)
are a different story.  They should have the
library prefix, not some object-type prefix.

E.g., if s.el functions were added to Elisp, and
if the library prefix remained as `s-', then they
should get that prefix.  If the library prefix
were renamed to `str-' or `foo' then that should
be the prefix for its function names.

But on its own, that has nothing to do with the
type of objects the functions act on or return.
The fact that most functions in that package
might involve strings in some way is something
else.  Even a function, macro, etc. in it that
has nothing to do with strings (if such exists)
should get its library prefix.

> yes, some generic functions will have trouble finding
> a good home. ...those function could either be left
> untouched, or they could be moved to `seq-`,...

That's where the disagreement is, I think - wrt
the degree to which such a renaming is needed or
useful.

Your point of view is apparently that functions
should generally, i.e., by default, be prefixed
with a thing name, and you acknowledge that it
might be difficult for "some generic functions"
to find a good thing type to name them with.

My point of view is farther down the spectrum.
It's not about generic functions.  It's about many,
probably MOST, functions in Lisp.  They don't have
a "good home" in the sense you mean it (some
privileged object type), and IMO they shouldn't
have a type-name prefix.

IOW, you seem to want to repaint everything, but
you acknowledge that it might be difficult to find
the right color paint for some things.  I don't.
I think it makes more sense to paint only things
that really need a type-labeling.

I contrasted painting the bikeshed with patching
holes in its roof.  I suggested dealing with names
case by case, and I even suggested filing bugs for
that, to track, discuss, and debate case by case.

A given case/bug could involve more than one
function name.  But I'd rather we err in the
direction of too few at a time than too many.

There's no right or wrong approach here.  It's a
question of aim, and view of the problem & cure.

> But I suggest we don't talk about these corner cases

See above.  For you, the corner cases (to ignore)
are a few "generic functions" that aren't easily
assigned a thing type, and you propose to leave
them out of the painting initiative.

The corner cases for me are the relatively few
functions whose names cry out for labeling as
specific to some type, and I'd propose fixing
their names, case by case.