[GiNaC-devel] Parser breakage changes

[Jens Vollinga]

Hi Alexei,

Alexei Sheplyakov schrieb:
> And it does not understand pow, sqrt, power, and user defined classes
> any more :(

fixed now.

> This breaks existing code (both GiNaC and `user code') and is not welcome.

It is _very_ welcome by some people that had their existing code broken 
by your new parser. I got quite some nasty complains about it.

Now, I see the problem that it breaks _your_ existing code, but when 
thinking about whether I should hurt the other people's code or 
introduce a different parser behavior I opted for the first option, 
because the parser as it was violated the basic assumption (not only 
that of the people that complained but also mine!) that the parser, 
without any tweaking, should just read any expression containing any 
functions and classes defined at that moment.

> It's impossible (or at least difficult) to extend the parser now (i.e. to
> read `user defined' classes). Please revert.

I extended it accordingly. Now it should work. Feel free to test it, I 
might have overlooked some issues again. The hack is dirty but only 
intended for 1.5.x. For future branches we have to do something better. 
This still needs to be done sooner or later.

> Also I dislike the idea. Being able to define function in such a way that
> parser knows nothing about it is a good thing. It is useful to make sure
> that input does NOT contain certain (auxiliary) functions. Previously this

Useful for what?

Your preferences here are very particular, probably because you are not 
a regular GiNaC user but also a developer. A user shouldn't be forced to 
define his own reader just to get a simple expression read in (just look 
at that stupid boilerplate code 
http://www.ginac.de/pipermail/ginac-list/2009-June/001540.html
)

> was very easy: don't tell the parser about those functions, and that's it.
> Now parser understands every auxiliary function (which is not supposed to
> appear in input or output expressions) so extra checks are necessary.

You are still free to define your own reader for that special purpose.

> Although it's possible to make a custom parser table (start from the default
> one and erase unwanted functions from it) this requires more (boilerplate)
> code.

Yeah, more boilerplate code, right, but now only people with special 
needs have to go through this hassle and not the average user anymore.

Regards,
Jens