----- Barton Willis wrote: -----
> Maybe something like (notice the '$done).
>
>(defmvar *finalevallist* nil)
>
>(defun $addtofinalevallist (f)
> ;; Function to add function names to *finalevallist*
> (cond
> ((mfboundp f) (push f *finalevallist*))
> (t (merror "Argument to 'addtofinalevallist' must be a function")))
> '$done)
>
>(%i1) load(functionp)$
>(%i2) addtofinalevallist('trigrat);
>(%o2) DONE
>(%i3) addtofinalevallist(f);
>Argument to 'addtofinalevallist' must be a function
> -- an error. Quitting. To debug this try DEBUGMODE(TRUE);
That looks like just the thing. Sweet! Thanks much!
I think in the testing I did that was the only remaining gotcha - the
function definiton of toplevel-macsyma-eval didn't seem to impact
anything, and all the tests I have tried thus far worked as expected.
(I still need to verify the delete command - note to self.) I'll plug
the unit package into this setup and see what happens, but if the list
approves updating macsys.lisp with this change it should then be a
simple question of filling out unit defs, adding extra user functions,
etc. (Temperature is probably the most tricky challenge left, but I
think it can be managed.) I'll try to put together a proposed diff for
macsys.lisp tomorrow evening, if I get back in in time. I'm probably
going to add some comments to continue as well, at least to identify it
as the top level control loop.
With any luck, it will be ready for 5.9.2! Yes!
----- Richard Fateman wrote: -----
> The macsyma idiom that you may want to adopt is for
> $finalevallist to be a macsyma list with a ((mlist) header,
> and to use uh, mpush? is there one? to mcons? on to
> the front of that list, and have some mmap along that
> list... (etc).
Hmm. OK. I take it there isn't a convenient list of lisp level
funcitions that have been "Maximaized"?. That should probably be its
own section in the Programming chapter.
Actually, we decided to deliberately make the finalevallist a
non-maxima list in order to provide for the possibility of preventing
the user from assigning stupid stuff to the list. (Since it is always
run at the end of every cycle, there is some significant potential for
damage.) I think the safties are probably unnecessary given the
intended use of this feature, but if they can be added without too much
effort it can't hurt to put them in.
> I'm not sure that finalevallist is quite the right name
> for all this. You might want to make it clear that this is done
> post-command execution.
Perhaps lastsimp would be better?
> In a more general setting you might want to pre and post "wrap"
> a command. kind of like tellsimp and tellsimpafter on the
> currently unnamed top-level-eval of the read-eval-print loop.
> Maybe this would be the way to implement it, in fact. have an
> "identity" function called $top_level_eval. Then allow
> tellsimpafter(top_level_eval(ANYTHING), f(ANYTHING)). Actually,
> you may need 2 functions, pre_top_level_eval and
> post_top_level_eval, and tellsimpafter on the 2nd one.
Possibly, except one of the goals of this feature is to avoid all the
quirks (or possibly features, depending on the task at hand)
tellsimpafter beings along. It seems to insist on looking at
subexpressions, which for certain unit situations doesn't work at all.
It's possible workarounds could be found, but this mechanism is a much
simpler and more straightforward way to achieve this goal. And there
is nothing to prevent it's being superceded in the future by a better
system - since it is so simple (and since it will be documented, unlike
much of the code) if there is need/interest in some other method in the
future it wouldn't pose a problem.
I think, for 5.9.2 at least, Dr. Willis has found a good way to achieve
what we are looking for. More elaborate/general mechanisms might be
possible, but should probably wait until later releases and/or the need
arises.
CY
__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/