On Nov 3, 2008, at 8:05 AM, Robert Dodier wrote: > William Stein wrote: > >> Incidentally, if we did allow automatic creation of symbolic >> variables, and default calling of symbolic expressions, then >> doing something like this would happen >> all the time and confuse the crap out of people: >> >> sage: function_name_with_slight_typo(10) >> 10 > > Well, that's weird, but it's not weird because of automatically > creating a variable for function_name_with_slight_typo. > Calling symbolic expressions -- that's weird.
For me the question is not so much what is "weird" but rather what behavior has the most potential for strange, subtle bugs. The nature of the "symbolic ring" to try and accept and absorb about anything makes this much worse--especially as I'd rather get an immediate error. For me Sage is much more than an environment to manipulate expressions, but a scriptable computation engine. Also, Sage being typed with many various parents and other objects makes it more natural to require the user to declare things ahead of time. >> I think it would be interesting to have at least the capability >> of a mode where variable names are made symbolic if >> not previously used, at least if the calling behavior were redefined >> as above. This would have be done by somehow parsing the >> input, finding all undefined variables, defining them, etc.... >> It's techincaly possible. Maybe Fernando Perez and I can >> try to make a demo of something like this at Sage Days 11. > > I would be inclined to plug in a custom top-level interpreter loop > which just catches NameError and instantiates suitable variables > and reevaluates the input when that happens. Is there a way to > get Python to parse the input without evaluating it? (Isn't there > an AST package or s.t.l.t. which could do that?) Then you could > (I guess) detect undefined variables without causing side-effects > from any part of the input. Just a guess -- I'm no expert on Python. There is, see http://www.python.org/doc/2.5.2/lib/module- compiler.html . Tools are even provided to "walk" the tree, so one could, for example, easily extract all (undeclared, non-declaration) NameNodes and define them to be symbolic variables before evaluating the code. Much better than introducing possible side effects with repeated re-evaluation. (Of course, I would expect this as an optional mode.) I see this thread has somewhat diverged from the original topic in the last couple of days, but I think a lot of the grief could be saved via better documentation. I created http://trac.sagemath.org/ sage_trac/ticket/4458 . Once you know what a NameError means, declaring things is an easy fix. - Robert --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
