--- Robert Dodier wrote:
>
> I have mixed feelings about this. On the one hand,
> so far as I can tell there aren't any harmful side effects.
> On the other hand, I don't think we want package maintainers
> to make modifications to the core code solely for the benefit
> of the add-on package.
I agree. That's why Barton and I tried to make this as generally useful
as possible - the new functionality can be used by ANY pacakge, not
just my units code, should it be needed. I was hoping to make this
change in order to minimize the temptation of redefining it yet again
later. There are a few extra features and safeguards that would be
nice to add, but once a mature preread - preeval - posteval set of
hooks is achieved I don't see the need to mess with this particular
problem again. Anyway, regardless, the point is I'm not proposing this
just because of the unit code, but because I think it is a good idea
generally to have this functionality. I'm also in favor of
establishing some kind of hook functionality (like Wolfgang's original
suggestion for toplevel-macsyma-eval) in things like kill1, so coders
can add special kill functionality without redefining kill1. But
that's for another discussion.
> In particular, I really don't see the
> need for a units package to replace core functions.
It has to if, say, the : operator is going to check for dimensional
consistency for (say) a case like x[time] : 3*sec (valid) and x[time]
: 2*m (error). That is, of course, unless these core functions provide
the ability to extend themselves. (Via hooks, for example.) There are
other cases where core code will need updating, plot2d and plot3d being
definite canditates.
Cheers,
CY
__________________________________
Discover Yahoo!
Stay in touch with email, IM, photo sharing and more. Check it out!
http://discover.yahoo.com/stayintouch.html