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 | ==================================================