Labelled field restrictions
Iavor S. Diatchki
diatchki@cse.ogi.edu
Fri, 13 Sep 2002 09:52:51 -0700
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 |
==================================================