[bitc-dev] Implications of pair

[Constantine Plotnikov]

I think that there is an option to have one element tuple and still to 
have a bit more regular processing if we would not try to save on amout 
of types involved at compile time. The approach is less effient at 
compile time as there is always terminator head field of unit type.

In haskel notation with type classes it would be:

module Test.TupleTest where
   
    class TupleHead a where
   
    data TupleEmpty = TupleEmtpy
    data TupleHead headType => TuplePair headType tailType = TuplePair  
headType tailType
   
    instance TupleHead TupleEmpty where
    instance TupleHead headType => TupleHead (TuplePair headType 
tailType) where

(tuple int string) type would expand to the following : (TuplePair 
(TuplePair TupleEmpty int) string)
(id 1 "aaa") value would expand to the following (pair (pair () 1) 
"aaa"). Approach is using type classes, but this can be avoided by using 
wraper tuple type with single field.

Constantine

Jonathan S. Shapiro wrote:

>Two motivations for PAIR replacing TUPLE are varargs compatibility for
>external function declarations and for a kind of "poor man's currying".
>
>The proposal currently reflected in the document is that all procedures
>(logically) take a single argument, and that applications are
>syntactically rewritten as follows:
>
>  (e1 e2)              => (e1 e2)   ; already canonical
>  (e1)                 => (e1 ())   ; i.e. unit instance
>  (e1 e2 e3            => (e1 (pair e2 e3))
>  (e1 e2 e3 ...)       => (e1 (pair e2 (pair e3 ...)))
>
>where the "..." is reduced in right-associative fashion until only one
>item remains, resulting in the expected right-reduced nesting of PAIR
>forms.
>
>What we lose is a certain degree of regularity in argument processing,
>because there is nothing comparable to "tuple of one element" and
>because it is no longer the case that all procedures take tuples as
>arguments. However, the "all arguments are tuples" thing was really a
>consequence of the specification of APPLY. It was never a "feature" in
>my mind.
>
>Note that the low-level code emission can exploit the type system to
>avoid passing that unit tuple in the case of no arguments.
>
>Also, I like the fact that if function calls are specified this way then
>we can explain the type of the CLOSE operation that forms closures:
>
>  close: (fn (fn (pair 'a 'b) 'c) (fn 'b 'c))
>
>this is actually quite nice, and it will help us explain objects when we
>get around to specifying DEFOBJECT.
>
>_______________________________________________
>bitc-dev mailing list
>bitc-dev at coyotos.org
>http://www.coyotos.org/mailman/listinfo/bitc-dev
>  
>