> > 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.
No, to me this discussion is about _grouping_ things, that's why we push for library prefixes.
> 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.
Just to be clear, "type-grouping" you more or less see the point but "topic-grouping" (e.g regexp, string) not so much?
> 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.
Okay, but I think we already agree on this? I propose to alias/rename functions where it's "obvious", but as we saw that what is obvious for me is not obvious for everyone, so that's complicated. I think we reached a point where everything proposed was rejected so this is a dead end.
> 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.
The ones I proposed were all rejected :-/ Do you have one in mind?