I think I would like to support Ralf's views stated below. On Sun, Oct 26, 2008 at 3:14 PM, Ralf Hemmecke wrote: > > On 10/26/2008 05:33 PM, Martin Rubey wrote: >> I'm not completely sure about the following (well, to be honest, I am, >> but I think I shouldn't be). In any case, I think we should take a decision. >> I see two possibilities: > >> A) InputForm should be precise. I.e., a given InputForm completely >> determines which functions are called, independent on what is >> exposed etc. > >> B) InputForm should be vague. I.e., calling "interpret" on a given >> InputForm mimicks behaviour at the prompt. > >> Currently, at least seriesSolve$EXPRODE depends on behaviour B: the >> InputForm corresponding to an element of EXPR INT is *not* decorated >> with package calls, and can easily be re-interpreted as function from >> UTS -> UTS. > > Looking at the documentation in mkfunc.spad > > ++ Domain of parsed forms which can be passed to the interpreter. > ++ This is also the interface between algebra code and facilities > ++ in the interpreter. > > I would clearly say, that B) applies. >
I strongly agree. It seems to me that InputForm was deliberately designed *without* package call decorations. But of course to the extent that the language treats types as first order, this does not prevent types and coercions entering InputForm values where necessary. The idead that InputForm is "the interface between algebra code and facilities in the interpreter" is also very important. In some important respects that interpreter is deliberately non-algebraic. >From my point of view InputForm is simply *the* abstract symbolic domain in Axiom. This is where Axiom expressions live without any interpretation. That fact that Axiom uses this domain for only very restricted purposes reflects that fact that Axiom is primarily an *algebraic* system. It (usually) does not emphasize manipulations that are purely symbolic. >> I think that this is not a very robust and clean solution, as demonstrated >> also by #301. I see two possibilities: > >> a) provide a function that takes an InputForm, and converts calls to EXPR >> INT to calls to UTS or whatever needed. This is the kind of symbolic processing that is possible in InputForm, but usually there are no "calls to EXPR INT" in InputForm values, as such. > >> b) take a completely different approach. > > InputForm and EXPR INT are by definition not typesafe. I do not think this is correct - at least until you give a definition of what "typesafe" might mean in this context. I can not think of any manipulation of values of EXPR INT or InputForm which do not produce good values in their respective domains. > If you really want better code, write a domain that treats the things > without InputForm or EXPR INT. I think "better" is a relative concept. What do you see as the deficiencies in the current approach? Doesn't it make sense to use the "symbolic" features of the interpreter when it is necessary to do manipulations of a symbolic nature in the algebraic code? > Although it's certainly not helpful, but any minor changes to the > current code are just hacks. There will then certainly be issues later. > I guess by that you mean that a general solution to this problem is not currently known, right? > I guess InputForm in some sense corresponds to the .ap file format > in Aldor. No, I do not think so. > Aldor (internally) also has a format which adds to any (input) > expression its corresponding type information. One might want to > define a similar type in FriCAS, but I don't think it is appropriate for > input/output to other CAS. Maybe such a InputFormWithTypeInformation > would be better suited for you, but it would probably be hard and error > prone to input by hand. > Are you aware that Gaby is working on exposing exactly such a "typed abstract syntax tree" representation in OpenAxiom which is already internally available in the Spad compiler? Regards, Bill Page. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
