On Thu, May 22, 2008 at 10:37 AM, Gabriel Dos Reis wrote: > Bill Page 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? > | ... > | 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'. >
Yes, I see the problem. 't(3,2)' is ambiguous. It satisfies the signature of more than one function in this context. There are a few other situations where this can occur. I think that in this case the compiler (and the interpreter) could simply return an error message. For example, in this case Aldor returns the message: "There are 2 meanings for the operator `foo'" See http://axiom-wiki.newsynthesis.org/[EMAIL PROTECTED] But I am not convinced that locally overloaded functions is a good idea. I would prefer that the interpreter be extended to easily define new packages (and domains) in the interpreter, then such situations can be disambiguated as package calls. > ... > | By "type name for 'x: T' " do you mean that 'x:T' would have a > | different type from 'T'? > > Yes. As far 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. Ok. In fact I would like these names to be exported by the type. So the type of 'x:T' would be just 'Record(x:T)' which would export x: % -> T But notice that 'Union(x:T)' exports x: T -> % > > | I am not convinced that type is the right abstraction for the > difference between these expressions. > > Could you elaborate? > After thinking about it, I guess I have convinced myself that you are right. I was thinking about the way this is described in the Aldor documentation and I did not like that at all. But if 'x:T' is just 'Record(x:T)', then it seems ok to me. For example, if I define: f(x:String,n:Integer):String == concat([x for i in 1..n]) I would like that 'x' and 'n' are functions (projection operators) x: Record(x:String,n:Integer) -> String n: Record(x:String,n:Integer) -> Integer and so this definition is just a short form of: f(arg:Record(x:String,n:Integer)):String == concat([arg.x for i in 1..arg.n]) > ... > | 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 unnamed fields, > > versus > > Union(f: Integer, g: String) -- union with named fields. > > They generate different operations and use different codes internally > in the compiler. > It seems to me that these can and should be implemented by essentially the same code. 'Union(Integer,String)' is currently broken since it exports coerce: Integer -> % coerce: String -> % which doesn't make sense if the component types are the same. Similarly the construction x case Integer could be ambiguous. There is a need for some syntax to designate otherwise unnamed tags. Suppose we use '%1', '%2', ... for such names. Then 'Union(Integer,String)' could export: %1: Integer -> % %2: String -> % and we would write x case %1 => ... If desirable and unambiguous in a given context then 'x case Integer' could be translated as 'x case %1'. In the case of the named unions, e.g. Union(f:Integer,g:String) these same exports are simply named: f:Integer -> % g:String -> % The same approach applies to records with unnamed fiels, so that 'Record(Integer,Float)' would export: %1: % -> Integer %2: % -> Float > | > 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. > Ok, yes. 'Mapping' as a built-in type constructor is currently displayed as: Mapping(T:Type, S:Type, R:Type, ...): (S, R, ... ) -> T but of we cannot actually write and compile definitions like this. I guess you are suggesting that we think of this as: Mapping(T:Type, S:Tuple Type): S -> T Of course we might also would like to be able to write: Mapping(T:Tuple Type, S:Tuple Type) i.e. for the type of functions that return a tuple of values: f: (S,R,...) -> (T,U, ...) There is no need for Mapping to be defined with more than two arguments. Regards, Bill Page. ------------------------------------------------------------------------- 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 open-axiom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open-axiom-devel
