Labelled field restrictions

[Iavor S. Diatchki]

hi,

Simon Peyton-Jones wrote:
> A perfectly sensible idea. 
yes, i've tought of that too and it seem like it may be useful.

> Main difficulty I see: it’s not clear what T.x would mean if both type T 
> and module T existed, though.
there seem to be at least two choices - either the data qualifiers 
shadow the module qualifiers, or it  is just ambiguous and the compiler 
comlains.  i like the second one better, especially since with the "as" 
part of the imports it is very easy to rename the module qualifiers.

> Also if I have
> 
>  
> 
>             data T = T { x,y::Int }
> 
>             data S = S { x,y::Int }
> 
>  
> 
> I might write
> 
>            
> 
>             f :: S -> T
> 
>             f s = T { x = S.y s, y = S.x s }
> 
>  
> 
> So just because I’m inside a T construction doesn’t mean that “x” or “y” 
> are unambiguous.
i am not sure what is the problem with this example.  i can see however
how something like

s { x = ... }

may be ambiguous as "s" could be of type either S ot T.  again in such 
situations the compiler could just complain.  alternatively one could 
you use constraints as in TREX records and infer that "s is of some 
record type which has field x in it".

by the way is there any chance of GHC supporting TREX like records?

bye
iavor

-- 
==================================================
| Iavor S. Diatchki, Ph.D. student               |
| Department of Computer Science and Engineering |
| School of OGI at OHSU                          |
| http://www.cse.ogi.edu/~diatchki               |
==================================================