"Bill Page" <[EMAIL PROTECTED]> writes:
| On Thu, May 22, 2008 at 9:39 AM, Gabriel Dos Reis wrote:
| > Bill Page writes:
| > ...
| > |
| > | 3) Can I use Tuple in a similar manner when calling a function?
| > | E.g.
| > |
| > | t(x:Tuple PI):INT == length(x)
| > |
| > | t(1,2,3)
| > |
| > | instead of?
| > |
| > | t([1,2,3])
| >
| > The patch is orthogonal to this case -- the patch deals specifically
| > with instantiating Tuple-like constructors, not call to general functions.
| >
|
| Please consider this a feature request. :-)
We need a thorough analysis, otherwise we don't have a guarantee that
we have something sensible.
Currently we don't have overloaded functions in the interpreter, but
that is a deficiency. Now, assume we are in a world where functions
can be overloaded in sciprs, and consider
t: Tuple INT -> INT -- #1
t: (INT, INT) -> INT -- #2
and the calls
t (3) -- calls?
t (3,2) -- calls?
t (3,2,1) -- calls?
I want a mechanism that yields a reliable call resolution, in the
`improved world'.
|
| > | Comments:
| > |
| > | 1) Besides 'Tuple', would it also be possible to treat 'Record' and
| > | 'Union' this way? E.g.
| > |
| > | RecDom(arg:Record(sym: Symbol, str:String, int: Integer)): Public
| > | == Private where
| > |
| > | if arg.sym=x and arg.str="x" or arg.int=0 then ...
| > |
| > | MyDom := RecDom(x,"x",1)
| >
| > In principle, treating Record this way should be possible when we
| > have a type name for 'x: T'. Also, to make it fully work, one needs
| > to modify the compiler too -- my patch modifies only the interpreter.
| >
|
| Yes, I think it is desirable that this also work in the compiler.
|
| By "type name for 'x: T' " do you mean that 'x:T' would have a
| different type from 'T'?
Yes. As fas as I can tell, Record(gcd: Integer, lcm: Integer) is
very different from Record(foo: Integer, bar: Integer) -- think use of
those types in function types. The names of the fields are part of
the type.
| I am not convinced that type is the right
| abstraction for the difference between these expressions.
Could you elaborate?
|
| > | ----------
| > |
| > | UnionDom(arg:Union(sym: Symbol, str:String, int: Integer)):
| > | Public == Private where
| > |
| > | if arg case sym then ...
| > |
| > | MyDom := UnionDom("x")
| >
| > The case of Union is harder. The reason is that constructors cannot
| > not be overloaded. Union is overloaded.
| >
|
| I don't understand. As far as I can see in the definition
|
| UnionDom(arg:Union(sym: Symbol, str:String, int: Integer)) ...
|
| arg has a specific type, thus 'UnionDom' is not overloaded in the same
| sense that the
|
| UnionDom(arg:Symbol) ...
| UnionDom(arg:String) ...
| UnionDom(arg:Integer) ...
|
| is an overloaded definition for 'UnionDom'.
The overloading is between
Union(Integer,String) -- union with named fields,
versus
Union(f: Integer, g: String) -- union with unnamed fields.
They generate different operations and use different codes internally in
the compiler.
| > You did not ask for Mapping, but one should be able to have it
| > for Mapping -- in fact, it was working on something related to
| > Mapping (modemaps) that prompted me to add the capability.
| >
|
| Could you give an example of how this might be applied to Mapping?
Well, conceptually Mapping has type Tuple Type -> Type, and follows
exactly the calling convention implemented by the patch.
-- Gaby
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
open-axiom-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/open-axiom-devel
