On Tue, Aug 12, 2008 at 4:57 PM, Ralf Hemmecke wrote: > Bill Page wrote: >> Yes I am aware of how Aldor implements tags in Record and Union >> as Enumerations. This is not the case in Axiom/SPAD even though >> there is some preliminary support for Enumerations there. In any >> case, I think this is a mistake in the design of the Aldor language. >> Projections (from Record) and Injections (into Union) are functions, >> not tags. > > http://www.aldor.org/docs/HTML/chap13.html#6 > > Do you mean that for > > Record(a: Integer, b: String) > > you would rather like to see the exports > > a: % -> Integer > b: % -> String > > instead of > > apply: (%, 'a') -> Integer > apply: (%, 'b') -> String > > ?
Yes! > > I think the difference is only cosmetic. Don't you think? No. I think it has to do with defining proper semantics for Record (and Union). The current solution in Aldor is strange. 'a' is of type Enumeration containing only the element a. Enumeration(a: Type) Therefore one sees strange things in Aldor code like: import from 'a'; just in order to be able to write r.a This is mixing concepts unnecessarily. > Perhaps it has to do with implementation details. > Maybe the 'apply' version requires only one slot in the domain > vector. I don't know. Yes, I think so. I think these details should be transparent to the program since Aldor is supposed to be a high-level language. > > but writing > > a r > > as a projection with your proposal or > > r a (same as r.a) > > as we do now, is just thinking of 'a' as a postfix function. ;-) > Allowing the '.' notation to mean postfix function application so that for any function 'a': r.a = a(r) is fine with me. That is the kind of syntactic sugar that I find easy to accept. > I guess, adding your wish to the compiler could be made with simply > adding syntactic sugar. Or do you really want to use 'a' as a function > of type % -> Integer (for passing it to another function). Yes I really want this. I also want the higher-order function product: (A:Type, A->X,A->Y, ... ) -> (A->%) exported from Record(x:X, y:Y, ... ) and uniquely defined by product(A,f,g).x = f, product(A,f,g).y = g, etc. for any functions f:A->X, g:A->Y, etc. Hiding A (universally quantifying A, in Gaby's terms) and writing 'product' as 'bracket' [f,g] also looks like good syntactic sugar to me. Then for example where now we write: [1,1.1,"123"]$Record(x:Integer,y:Float,z:String) we can say this is really a call to product((),1,1.2,"123")$Record(x:Integer,y:Float,z:String) returning the value ()->Record(x:Integer,y:Float,z:String), where 1:()->Integer, 1.1:()->Float and "123":()->String constants. And of course '()->' is normally also suppressed in the types of such constants. So syntactically all this looks the same as what we already write in Spad and Aldor. But using this product in more general contexts also makes sense and could be useful - especially in functional-style coding. All this means is that Record is semantically just a categorical product (limit). > Well, in fact, I am not really against having projections exported as > proper functions in this way. > Great! Then we agree. :-) Would you mind if I copied this email to "open-axiom-devel" or some other list? Regards, Bill Page. ------------------------------------------------------------------------- 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
