<br><br><div class="gmail_quote">2009/9/6 Robert Uhl <span dir="ltr"><<a href="mailto:eadmund42@gmail.com">eadmund42@gmail.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Gustavo <<a href="mailto:gugamilare@gmail.com">gugamilare@gmail.com</a>> writes:<br>
><br>
> It will not change function or macro names nor create new names or<br>
> aliases for them in some other package, even if the new names are more<br>
> descriptive or acceptable.<br>
<br>
</div>That seems unnecessarily restrictive.  What's wrong with a COMMON-LISP-3<br>
package which has more orthogonal names?  Heck, it could even take<br>
advantage of some theoretical versioned-package functionality.<br></blockquote><div><br>I based this sentence on what Drew Crampsie said:<br>
<br>
"We will also _not_ be deprecating things from CL because they are<br>

bizarrely name or parameterized."<br>
<br>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.<br><br>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.<br>
<br>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.<br>
<br>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.<br>
</div><div></div><div><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<font color="#888888"><br>
--<br>
Robert A. Uhl<br>
I take great delight at jeering at overly healthy types and telling<br>
them that they're going to feel really stupid one day, lying in a<br>
bed dying of nothing.                                        --GB<br>
</font></blockquote></div><br>