>> However, I consider interpreter and library design as two different >> things. So what use cases in library design do you see?
> I do not think you should separate interpreter and library: > > 1) I would like interpreter and compiler language to be as similar > as possible Me too. > 2) interpreter uses library, sometimes library uses intepreter. The > easiest way to implement reflection in interpreter is to have it > at library level Ufff. I don't agree with 'sometimes library uses intepreter'. As I mentioned informally at the Aldor&Axiom Workshop I would rather like to have several stages. a) low level things that implement the language (compiler) b) very close low level things (debugger, interpreter) c) library level d) user level a) basically makes everything ready that one can use a language SPAD-1 b) debugger and interpreter can be implemented in the languge SPAD-1. Here I would allow reflection and whatever to make those low-level things easily possible in SPAD-1. Also some very basic library things could be implemented in SPAD-1. c) is for writing algorithms, domains, categories connected to mathematics. That works with SPAD-2, a language without reflection and low-level stuff. d) The user interaction language must be a bit different from SPAD-2, since here reflection might be a good thing. Guessing of types is done by the interpreter (mentioned above) on the basis of a given library. The interpreter should not have any mathematical knowledge. I am not sure, whether one can allow here the power of SPAD-1. > Concerning to use cases: > 1) external interfaces: we need info about types to construct something > which is in 1-1 correspondence with internal date OK, but that would live at level b) and has an interface to d) and if you like also to c). As a mathematician, I don't need to know how an Integer is represented. If I want to interface with an external program, I simply call a function foo that passes that Integer to the external program. foo should be implemented at level b), but don't give the user all the right. What I call b) is somehow a "developer's level". > 2) IIRC Gaby wants to do program transformations and his idea is > to base this on reflection Sounds like what Maple offers. I'm not so sure that I am interested in that currently. > 3) Think about re-writing i-coerce or i-coerfn as Spad code -- we > could do it as list/tree manipulations (basically mimicking what > Boot code is doing). But it would be nice to make the code somewhat > typed and to re-use type machinery from compiler -- it is > likely that reflection may help. Yep. That is level b). > Let me also note that "good reflection" basically means that > at user level we need some information which is already known > to the compiler. If we ask compiler to provide this information > we simpilify user code _and_ make static checking easier: compiler > can assume that information it provided satisfy certain invariants, > while if we force users to recompute the information than compiler > will have hard time trying to prove that what user computes is the > same as the internal information. I only roughly understood what you meant here. No need to elaborate on this at the moment. Ralf --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
