Ralf Hemmecke wrote:
>
> 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, this checking is tricky (= udecidable) in general, but
clearly compiler could at least try to determine which conditions
are possible.
However, currently compiler is doing only little inference and
one reason is that after recompiling other domains such inferences
may became invalid. Currently if you recompile a domain or
a category other domains will notice change in exported
functionality. Of course, this is dangerous in sense that
one may get into strange states which would not appear if
things are compiled in order. However, with more inferences
the problem would be much more serious. So there is conflict
between static checking and dynamic developement style.
--
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.
