Serge D. Mechveliani wrote:
>
> Dear FriCAS developers,
>
> And I am going to build constructions like this:
>
> constr := UPConstr(x, FrCons("Int" :: Symbol))
>
> And to analyse it like this
>
> f(constr) ==
> constr case of Fr =>
> constr' := frConstrArg constr
> process the argument construction constr'
> constr case of UP' =>
> x := upConstrVar constr
> cConstr := upConstrCoef constr
> process x and the coefficient domain construction cConstr
>
> This approach looks rather complex, and even requires to introduce a
> category.
> I thought of SExpression. But, for example,
> convert[UP', x, coefConstr'] :: SExpressin
>
> requires of UP', x, constr' to be of the same type. Right?
> One neds to union the constructor tags, parameters (like x),
> and domain constructions into a certain type U, and to program
> processing the data in List U ...
>
> Please, what may be an adequate way?
You decided to do dispatching on types, but maybe alternative
design is better?. Namely you mix parsing expressions with
parsing types and apparantly you want to re-do parsing types
to choose correct function to apply. But you could have
mappings:
String -> Type
String -> parser function
String -> encoder function
(String, String, List(String)) -> application funnction
The fist one given a string would return FriCAS type T
(this is what you are doing in dParse). The second one
given a String would return parser, that is function from
strings (or list of lexemes) to T. The third one is
"inverse" of second one: will give you a function
which will encode values of type T into strings.
The fourth one given name of FriCAS function, encoded
return type and encoded argument types would return
apropriate function. Actually, you may also need
to know domain/package which implements given function,
that it you may need extra argument.
This may be more code that you intended to write (in
particular I do not see how to do this using a _single_
function), but may be less code compared to what you end
up writing. In particular the same parsing machinery
could be used for all four tasks. Also, such approach
should have better performance, namely in your approach
amount of dynamic dispatching is proportional to size of
data (for example you are re-doing dispatching for each
coefficient of a polynomial), while in what I propose
dispatching is proportional to size of types.
--
Waldek Hebisch
[email protected]
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en.
