[GiNaC-devel] Parser breakage^W changes

[Alexei Sheplyakov]

Hello,

On Fri, Jul 10, 2009 at 03:06:46PM +0200, Jens Vollinga wrote:
> commit f38cbcd651246fb5c1294705d29399f3cbfddaf5
> Author: Jens Vollinga <jensv at nikhef.nl>
> Date:   Fri Jul 10 15:01:04 2009 +0200
> 
>     Changed the parser such that it understands all defined functions
>     including the user defined ones.

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

> diff --git a/ginac/parser/parse_context.h b/ginac/parser/parse_context.h
> index 15dfcd6..c7360dd 100644
> --- a/ginac/parser/parse_context.h
> +++ b/ginac/parser/parse_context.h
> @@ -72,25 +72,18 @@ typedef ex (*reader_func)(const exvector& args);
>   * foo(x+y, z^2, t)), it looks up such a table to find out which
>   * function (or class) corresponds to the given name and has the given
>   * number of the arguments.
> - *
> - * N.B.
> - *
> - * 1. The function don't have to return a (GiNaC) function or class, it
> - *    can return any expression.
> - * 2. Overloaded functions/ctors are paritally supported, i.e. there might
> - *    be several functions with the same name, but they should take different
> - *    number of arguments.
> - * 3. User can extend the parser via custom prototype tables. It's possible
> - *    to read user defined classes, create abbreviations, etc.
>   */
> -typedef std::map<prototype, reader_func> prototype_table;
> +typedef std::map<prototype, unsigned> prototype_table;

This breaks existing code (both GiNaC and `user code') and is not welcome.
It's impossible (or at least difficult) to extend the parser now (i.e. to
read `user defined' classes). Please revert.

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
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.
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.

Best regards,
	Alexei