#17958: implement declare_var, deprecate (None)var
-----------------------------+------------------------
Reporter: rws | Owner:
Type: defect | Status: new
Priority: major | Milestone: sage-6.6
Component: symbolics | Resolution:
Keywords: | Merged in:
Authors: | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
Dependencies: | Stopgaps:
-----------------------------+------------------------
Comment (by nbruin):
Replying to [comment:26 tmonteil]:
> What is currently discussed is a function that injects a symbol into the
namespace, so `inject_symbol` sounds more meaningful as it just tells what
is actually done.
Except that "inject" is rather technical and not what the novice thinks
about doing. You'd probably have to explain to them: "Before using y, you
have to declare that it is a math symbol, which you do by
`declare_symbol("y")`."
I indeed agree that using "symbol" instead of "symbolic variable" would be
better to distinguish the concept from a python name. However, we've been
calling these things "var" since the start of sage, so changing that may
be painful for our current users.
> I agree that in any case, both injecting and returning is harmful
(`function` does that too).
There the terminology is even worse: python actually calls its "def" and
"lambda" objects "functions". So "declare_function" will be even more
confusing than "declare_var".
-----
A minimal plan is to either not have `var` produce side-effects, meaning
{{{
sage: var('z')
z
sage: z+1
Error
}}}
or let `var` return None, meaning
{{{
sage: z = var('z')
sage: z+1
Error
}}}
If neither one is palatable then we can stop the discussion now. We're
stuck with a bad design decision, for which the pain for repairing it is
too high.
----
An alternative is to migrate to the unspoilt
{{{
sage: z = symbol('z')
sage: declare_symbol('w')
sage: z+w+1
z+w+1
}}}
and let `var` rot and fester, trying to nudge people away from it (put a
deprecation on it after a while?). In 10 years or so we could think of
removing `var`.
----
For `function` we can perhaps do the deprecation in-place. That's mainly
going to affect people trying to solve ODEs and PDEs (outside of that,
symbolic (formal/abstract) functions don't have much use)
--
Ticket URL: <http://trac.sagemath.org/ticket/17958#comment:27>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
