Ralf Hemmecke <r...@hemmecke.de> writes:
| On 01/14/2012 01:35 PM, Gabriel Dos Reis wrote:
| > Ralf Hemmecke<r...@hemmecke.de> 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.
As I said earlier, we can certainly do (and we should) a better job. It
is an annoyance to users -- OpenAxiom has an open bug report against this.
All flavours of AXIOMs already build a sort of binary decision diagram
to account for modemap predicates and set operation implementations
accordingly. This is done at domain instantiation time -- see the
second half of the runtime system function stuffDomainSlots, and the
codePart2 code generated by buildFunctor.
There are situations where one has to amend the proposal. For example,
consider the following:
)abbrev domain MYDOM MyDomain
MyDomain(T: SetCategory): Public == Private where
Public == SetCategory with
myDomain: T -> %
Private == T add
myDomain t == per t
Here, none of the operations exported by SetCategory is directly
implemented by MyDomain. Should the compiler abort compilation right away?
My answer is no. The reason is that those operations may be provided
by the actual argument T. And indeed, that is what is expected in that
definition -- operations not directly implemented in the constructor
MyDomain are to be looked up in the base domain and possible defaults.
Can the compiler find those apparently missing operations while
compiling MyDomain? No, there is no domain constructor it can look
into. It has to *assume* that the missing operations will come from T.
For constructor arguments that are not type, I believe one has to wait for
the actual value; one does not need "odd? random()" for that.
Consider the case of category ComplexCategory for example. At the moment,
all flavours of AXIOMs cheat with
if R has Field then -- this is a lie; we must know that
Field -- x**2+1 is irreducible in R
whether 'x^2 + 1' is irreducible in R is not a simple condition known to
the compiler (at least not as simple as has tests) since the exponention
and addition operations can be arbitrary user code.
For has-tests cases, the complexity can be bad in practice. There is
one constructor in the AXIOM algebra that takes a looong time, more time
to compile that others; most of the time is spent in simplifying
conditionals while building the predicate vector and generating codes to
set up the 'right' functions to call. Yet, definition of the
constructor is very simple (in apparance.)
None this is being construed as 'no, this should not be done'.
-- Gaby
------------------------------------------------------------------------------
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
_______________________________________________
open-axiom-devel mailing list
open-axiom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open-axiom-devel
