Ralf Hemmecke <[EMAIL PROTECTED]> writes:
[...]
| >>>> In Implicit System F, or in a forall-quantified style I would write
| >>>>
| >>>> forall(T: Type) .
| >>>> Associative(Modemap(T,T,T): op): Category == with nil
| >>>>
| >>>> so that when I say Associative(_+$Integer), T gets deduced to
| >>>> Integer.
|
| Also here we can end up with an ambiguous situation.
|
| MyInt: with {
| +: (%, %) -> %;
| +: (String, String) -> String;
| } == add {
| -- implement something here
| }
|
| Now if you say
|
| Associative(+$MyInt)
|
| then that should be rejected by a compiler, since it is ambiguous.
|
| Well, of course, that is a constructed case, but why shouldn't I be
| allowed to write MyInt and state associativity of the first + and
| maybe some other property for the second? Unfortunately, I am unable
| to specify the input for Associative with the current choices
| (i.e. using $ and/or @).
In OpenAxiom, one can use @ to restrict the set of mappings, e.g.
[EMAIL PROTECTED](INT,NNI,INT)
selects the * as default-supplied by ABELGRP.
In fact, I don't see what would be wrong with
[EMAIL PROTECTED](INT,INT,INT)
or
[EMAIL PROTECTED](String,String,String)
-- Gaby
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
open-axiom-devel mailing list
open-axiom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open-axiom-devel
