On Sat, 2007-02-24 at 10:50 -0500, Brian Hurt wrote:
> 
> On Sat, 24 Feb 2007, Lukasz Stafiniak wrote:
> 
> > I have this idea... We could have row polymorphism in tuples, without
> > any impact on performance! Instead of insisting that ('a * 'b) means
> > exactly two elements, we could have (> 'a * 'b) at least two elements.
> > Any projections or pattern matching fetches the tuple fields without
> > problems: it doesn't need to care that there are more than it needs.
> >
> > Say you realize that you need to return another value from a function
> > (which already returns a tuple): you would only modify the function
> > and not its uses.
> 
> Not being able to do this is one of the reasons I *like* Ocaml.
> 
> Consider the case where the calling location is:
>  	let a, b = foo ... in
>  	...
> 
> Now you change foo to return 3 tuples instead of just 2.  What happens?
> 
> If you say "The third element quietly gets dropped", I'll respond with "if 
> I wanted that behavior, I'd be coding in Perl."

I think you're taking his idea too literally: consider instead
an explicit syntax which allows tuples to be pattern matched
like lists. Felix can actually do this:

/////////////////////////////////////////
#import <flx.flxh>

typedef fun xcur(t:TYPE):TYPE => typematch t with
  | ?a -> ?b => a * xcur b
  | _ => t
endmatch;

var x : xcur (int->long->double) = (1,(2L,3.0));

match x with
| ?a,(?b,?c) => { 
  print a; print " "; 
  print b; print " "; 
  print c; endl;
}
endmatch;
//////////////////////////////////////////

The thing to note here is that we have a generic pattern match
which can fold along the components of a function type
using recursion. (This is an example of my version of Jay
pattern calculus).

But you cannot recurse over a tuple like this because it
isn't built up inductively from a binary operator.

We can adapt Lukasz suggestion to make it possible,
by for example the syntax:

  head, tail ...

or some such, which treats a tuple like a list. Of course
such a construction should be *explicit*.

Similarly, a version of this could work for arrays: it would
be data polymorphic but not generic (since all array elements
have the same type).


-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net