[cltl3-devel] RFC: CLtL3 Charter

[Gustavo]

2009/9/6 Robert Uhl <eadmund42 at gmail.com>

> Gustavo <gugamilare at gmail.com> writes:
> >
> > It will not change function or macro names nor create new names or
> > aliases for them in some other package, even if the new names are more
> > descriptive or acceptable.
>
> That seems unnecessarily restrictive.  What's wrong with a COMMON-LISP-3
> package which has more orthogonal names?  Heck, it could even take
> advantage of some theoretical versioned-package functionality.
>

I based this sentence on what Drew Crampsie said:

"We will also _not_ be deprecating things from CL because they are
bizarrely name or parameterized."

Just renaming functions or creating a new package with more "orthogonal
names" (whatever that means) does not include any new feature nor
functionality in the language and it is something you can do yourself. It
falls into what was already said: that it is not one of Cltl3's goal to make
CL more readable or easier for newbies or whatever. It also depends too much
on personal taste. Having one function with different names makes more
confusion than clarification.

Such a thing pollutes the packages with names you are not going to use. For
instance, I might not like some naming conventions in COMMON-LISP-3 or I
might have some code that already uses CL's standard names, so I decide to
import from both packages COMMON-LISP-3 and COMMON-LISP. Then I will have to
manually shadow all symbols that I don't want to use, or I will be obligated
not to use those names in my package.

Not to mention that doing this will make it look like that we are trying to
force people to program in a different language, learn new names or new
parameter orders. This is very different from including extensions - you may
safely and easily just ignore such extensions. Maybe in the course of
discussion we end up creating functions that are generalizations of other
functions already in ANSI CL, then it will be ok to deprecate those
functions, but this is very different from just creating aliases.

And, as a mater of fact, I can't imagine how to implement versioned packages
in a way that its cost is below its benefits. I can only imaging that
something in this direction will need big changes in implementations for
only providing a small benefit, or to occupy more space (many versions of
the same functions). I will be glad if someone proves me wrong. Conduit
packages look much more useful than versioned packages.


> --
> Robert A. Uhl
> I take great delight at jeering at overly healthy types and telling
> them that they're going to feel really stupid one day, lying in a
> bed dying of nothing.                                        --GB
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cltl3-devel/attachments/20090906/980e64a5/attachment.html>