#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:11 vbraun]:
> `SR.var` does exactly what the `declare_var`
No, it does not:
- `SR.var` a symbol and ''does not'' inject anything.
- `var` (toplevel) as it exists now returns a symbol ''and'' injects a
binding to it
- `declare_var` as proposed would inject a binding to a symbol and return
`None`.
The problem with the mixed actions of `var` is that people learn it, see
it returns a symbol, and then use it in circumstances where they need a
symbol returned. That works, but behind the scenes there is ''also'' a
binding injected. That then surprises them later.
If we have two routines, one that ''only'' returns a symbol and the other
that ''only'' injects a binding, this potential for surprise is
eliminated.
I think we do want the possibility of injecting something, because
`x=var('x')` or `x=SR.var('x')` is too verbose (and more importantly,
requires the `x` to by typed twice).
We need the injection capability on toplevel because this is one of the
first things that novices need to be able to do. I'm not completely sure
we need an entry to `SR.var` in the global namespace. However, the
capability has been there as part of `var` (with sometimes surprising
side-effects) so I think we pretty much have to continue it.
> `SR.symbol` and `SR.var` should probably be aliases but aren't. I wasn't
even aware of `SR.symbol`, which is why I only fixed the comma parsing in
`SR.var` in #7496.
They probably shouldn't. At least one of them should be 'make a symbol
with the given print name or raise an error'. The fact that the return
type of `var` depends on the formatting of the string (either a symbol or
a tuple of symbols) is a wart that stems from convenience for the
injection purpose.
> How about something like `R.<x> = SR()` to get symbolic generators?
Cute, but I think it misses the mark for the intended audience: complete
novices. It makes it very hard to convince people that Sage is a
reasonable choice relative to Maple and Mathematica (and Maxima), where
you can just start using a symbol.
--
Ticket URL: <http://trac.sagemath.org/ticket/17958#comment:17>
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.
