On Wednesday, March 20, 2019 at 4:37:49 AM UTC-7, Emmanuel Charpentier wrote: > > But I wont, because I tend to think that, as long as we are insisting on > explicit creation of symbolic variables, >
An argument that has been used in that context is that in "f(x)=sin(x)" the `x` does occur on the LHS of the assignment, so it is part of what is "assigned to". Just as in "R.<x>=QQ[]", the assignment does mention `x` explicitly on the LHS, so it is an explicit assignment. > > > 1. raise an error if the arguments of a symbolic function are not yet > existing in the name space, or > > I expect that would break too much. If you're worried to losing information, we could inject something in the code produced by the preparser that issues an error or a warning if the assigned-to variable names already have a binding that doesn't agree with what they are being bound to. > > 1. > 2. automatically create undeclared variables as symbolic variables (as > in Maxima, Mathematica und so weiter...). > > I don't think that follows as a corollary from being "explicit" because the variables are mentioned explicitly on the LHS in our current syntax. However, if you'd run a full fragment through the python parser, you should be able to get a tree back from which you can read off what symbols need to take their binding from outside. That's how python decides which variables are local, global, or part of a closure. So we'd need a "postparser" for that. I would not support that. I would say the ship has sailed on this one: this is how the preparser was designed to define symbolic functions with a concise short-hand syntax that would otherwise be a syntax error in python. Breaking that now will affect too much code that's already out there; in particular little examples people have prepared to use in teaching, where breakage is likely not detected (checking pre-prepared materials that worked before is just a chore) and is embarrassing in front of a large audience, doing great damage to the perception of sage being useful as a classroom tool. It's convenient for beginner use of sage, where the objective is to quickly do something calculus-like without having to dwell on the peculiarities of mathematics software: the WolframAlpha scenario. If you don't like the implications of the syntax, don't use it, but call something like f = (sin(x)).function(x) instead. That's straight-up valid python syntax with no hidden preparser complications. The preparser is not tuned towards serious programming. -- You received this message because you are subscribed to the Google Groups "sage-support" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at https://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
