Ralf Hemmecke wrote:
>
> >> Concerning reflection: reflection complicates semantics and
> >> it is easier to implement language without reflection. But
> >> reflection has some good uses and I would like to support
> >> them (as long as there is no conflict with compilation).
>
> > Ok. This is a "permissive" approach to language design. From the point
> > of view of a general purpose language maybe it is ok to let the
> > programmer use certain constructs if it is more convenient even if it
> > does fit some preconceived model of how one's program "ought" to look.
> > But Spad was originally designed for a very specific purpose - as a
> > language in which to express mathematical algorithms for the Axiom
> > library. I think the restrictions that sometimes makes Spad a somewhat
> > difficult language to use also often contribute to the goal of making
> > it more precise and expressive when it comes to the mathematics.
>
> Bill,
>
> do you actually see a need for reflection? The only things that come to
> my mind are a debugger written in SPAD and perhaps some more convenience
> for unit testing (But for the latter I find reflection not terribly
> necessary.) I debugger is a rather low-level thing, so a special
> (not-exported) language feature to implement it is certainly helpful.
> Any other things that you have in mind when it comes to the
> implementation of a Mathematics library?
>
> Note... I don't speak about the interpreter. Runtime reflection in the
> interpreter may be wanted for several reasons. If I sit in front of my
> CAS, I'd like to be able to ask what functions a certain domain exports.
> A user cannot be expected to have the source code lying somewhere on
> his/her hard drive.
>
> 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
2) interpreter uses library, sometimes library uses intepreter. The
easiest way to implement reflection in interpreter is to have it
at library level
Concerning to use cases:
1) external interfaces: we need info about types to construct something
which is in 1-1 correspondence with internal date
2) IIRC Gaby wants to do program transformations and his idea is
to base this on reflection
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.
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.
Also, note that I am pragmatic rather than permissive: I do not
want to (now) to spent time implementing elaborate reflection
facility, rather I allow useful features if they do not conflist
with static checking.
--
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
-~----------~----~----~----~------~----~------~--~---
