On 01/14/2012 01:35 PM, Gabriel Dos Reis wrote:
Ralf Hemmecke<[email protected]> writes:
|> The issue is far more involved than described in Ralf's original message
|> because of existence of default implementations and implementations that
|> are controlled by complicated conditionals the actual values of which
|> are not known until instantiations with concrete constructor arguments.
|
| Ah, OK, if conditionals are involved, then I'd understand that an
| throwing an error has to wait until it is clear what the actual values
| in the conditional expressions (proably "has"-expressions) are,
| i.e. until instantiation of the domain.
Indeed.
| But I would argue that there an important case is where function
| implementations are missing that are not controlled by any condition.
| If in such case the compiler could abort that would already be of
| great value to programmers.
A better job could be done for niladic constructors or operations with
trivial predicates. That requires duplicating the logic of defaults
search in the compiler though. Since OpenAxiom already implemented part
of this search for domain inlining, it is conceivable to extend that to
full-blown analysis. That represents some work, but doable.
After I pressed the send button, I continued thinking about your
"conditional" argument. In fact, I cannot easily find an example where
it is really a problem.
My line of thoughts is as follows. For as domain with parameters, I can
get (at compile time) an expression for all the signatures that it
exports. That involves also conditionals. In case the condition is
functional, it can be analysed at compile time. Of course, if one has
something like "if odd? random() then Field", one cannot do anything at
compile time, but such conditions are "uninteresting" anyway.
So I imagine that for each possible outcome of the conditions, one has a
(unconditioned) set of exported signatures, i.e. for n conditions 2^n
signature lists. For each of these 2^n cases one would have to check,
whether the domain in question implements all the respective signatures.
If for one case a function implementation is missing then the compiler
should abort.
That sounds bad complexity-wise, but not as an algorithm to check for
whether all functions are really implemented. Am I overlooking something?
Well, I agree, that it may be hard or perhaps even impossible in general
to figure out something like this one.
Dom(R: SetCategory): with
if R has Ring then
foo1: ()->()
foo2: ()->()
if R has Field then
foo3: ()->()
== add
if R has Ring then
foo1():()== ...
if R has Field then
foo2():()== ...
foo3():()==
I guess, that example can still be resolved, given the fact that Field
inherits from Ring, but maybe there are similar more complicated
situations that cannot be decided at compile time.
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.
