--- Richard Fateman wrote:
> C Y wrote:
>
> >
> > P.S. Is the implimentation of ordergreat and orderless really as
> > dumb as I think it is, or are there reasons it's done that way?
>
> Could you be more explicit? Does it matter? The programs that
> matter are "great" and its subroutines, which should be as efficient
> as possible.
Ordergreat will not accept commands of the form ordergreat([s,m,kg])
Nor will it allow something like:
ordergreat(s)
[s]
ordergreat(m)
[s,m]
This makes it hard to prepare a list in a loop, and then feed it to
ordergreat, for example. Is there a reason upgrading the definition to
support input of the form ordergreat([s,m,kg]) is a bad idea?
Here are the definitions, as it stands now:
(defmspec $ordergreat (l)
(if greatorder (merror "Reordering is not allowed."))
(makorder (setq greatorder (reverse (cdr l))) '_))
(defmspec $orderless (l)
(if lessorder (merror "Reordering is not allowed."))
(makorder (setq lessorder (cdr l)) '|#|))
Unless I'm reading this wrong, once ANYTHING is assigned to
greatorder/lessorder no further assignments can be made. Eeek.
Is it that I'm using the wrong function? Maybe ordergreat is the wrong
command to be working with?
CY
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com