symbolic functions can be defined with a constant argument

[pang]

The expression

h(6)=8

currently defines a symbolic function h with constant value 8. This makes no sense, but begginers make this mistake, for example if h is an array and they use () instead of []. It doesn't hurt to throw an error at all expressions

h(something) = ...

whenever something is not a symbolic variable.

Apply trac_10747-preparse_calculus.2.patch , trac_10747-preparser-docstrings-symbolic-vars.patch

[pang]

Coludn't find the ticket, but this has already been fixed.

[burcin]

Fixed in which version?

On 4.6.1, h(6)=8 still goes through without an error message and I get

sage: h

_sage_const_6> 8

IPython complains on the command line though.

[pang]

You're right. I noticed the bug on the notebook. Then some days later, I updated, and got the right error message on the console. It didn't occur to me that the behaviour could be different.

[zaf]

add doctests

[burcin]

It seems the real problem is in the preparser. Normally, when f(1)=2 is preparsed on the command line, it becomes f(Integer(1))=Integer(2). This is not valid python so we get an error anyway. In the notebook, the constants are extracted and assigned to variables named _sage_const_*. Then the preparse_calculus() function receives f(_sage_const_2)=sage_const_3 as input, which is a valid construction.

trac_10747-preparse_calculus.2.patch changes preparse_calculus() to raise an error if the argument name starts with sage.misc.preparser.numeric_literal_prefix.

trac_10747-preparser-docstrings-symbolic-vars.patch adds doctest for the errors on the command line and the notebook.

It would be better if someone more familiar with the preparser reviewed my patch.

[kcrisman]

Thanks for this - nice catch. I had to zoom through a lot of code, but this does seem to be the most efficient way to do this.

I wonder about the error message. In theory, one could mess with this by putting _sage_const_ at the beginning of some legitimate variable...

Here are other fun things that already existed.

sage:  f (x ,y,  z ,w ) = 5=3
------------------------------------------------------------
   File "<ipython console>", line 1
SyntaxError: keyword can't be an expression (<ipython console>, line 1)

sage: f(print)=5
------------------------------------------------------------
   File "<ipython console>", line 1
     __tmp__=var("print"); f = symbolic_expression(Integer(5)).function(print)
                                                                            ^
SyntaxError: invalid syntax

There are lots of ways to mess with the preparse_calculus regular expression to get things that will give fairly mystifying error messages.

Anyway, this all looks good, but I am prevented from testing it by my computer having had its OS reinstalled, and somehow now gcc is missing. I still have Xcode, but not gcc.

And great work on starting your contributions, Zaf!

[kcrisman]

A thought; it might be worth documenting (if it isn't already, I didn't check) that

sage: f(1) = x
------------------------------------------------------------
   File "<ipython console>", line 1
SyntaxError: can't assign to function call (<ipython console>, line 1)

sage: preparse("f(1)=x")
'f(Integer(1))=x'

I like the \(([^()]+)\) check for this.

[kcrisman]

Okay, this is all set - the right error messages are tested for, I just missed this. Confirmed that it works in the notebook, as it should. Attaching a test file with something nasty like this also raised correct error once I added the bad part, worked well with good part.

Relevant tests pass, and unless something weird happens (which I would report in the next hour or so) all is well. Good work.