Ian Lynagh <igloo <at> earth.li> writes: > > On Thu, Mar 01, 2012 at 08:52:29PM +0000, AntC wrote: > > > > And you get "In my opinion, this is ugly, ... > > That comment was from strake888, not SPJ? >
Thanks Ian, you're right. Specifically, it's 'igloo's tweak to the proposal and 'strake888's comment. (I had erroneously thought the whole of that page was SPJ's, and I hadn't much re-read it since SPJ posted it.) > Personally, in the context of Haskell (where the case of the first > character often determines the behaviour, e.g. a pattern of Foo vs foo), > I don't think it's too bad. > Hmm. Upper case in an expression always means data constructor (or qualified name). (You've possibly not been watching the outrage at changing the meaning of `.` ;-) Also this would be ambiguous: object.SubObject.Field.subField -- are the `SubObject` and `Field` (private) field selectors, -- or a qualified name for subField? -- or perhaps SubObject.Field is a qualified private field selector? Putting parentheses would cut out some of those interpretations, but not all of them?? In terms of scope control, I think (I'm guessing rather) you do get similar behaviour to DORF, with the added inconvenience of: * an extra arg to Has (how does the constraint sugar cope?) r{ field :: Int } => ... r{ Field :: Int } => ... -- ? does that look odd -- suppose I have two private namespaces r{ Field :: Int ::: Field1 } => ... -- ?? r{ (Field ::: Field2) :: Int } => ... -- ??? * something(?) extra in record decls: data PublicRecord = Pub { field :: Int } data PrivateRecord = Priv { Field :: Int } -- ? data PrivateRecord = Priv { Field :: Int ::: Field2 } -- ?? * a need for equality constraints between Kind and Type (that's the ft ~ FieldT bit) The class decl and instances are 'punning' on tyvar `ft` being both a type and a Kind. Is that even contemplated with Kinds? * a need for something(?) different on record update syntax: pubRec{ field = 27 } privRec{ Field = 92 } -- does upper case there look odd to you? privRec{ Field = 87 ::: Field2 } ("ugly" is a mild reaction, the more I think about it.) > > But I think you are agreeing that (leaving aside the issue of whether > the design is reasonable) the above variant would indeed allow the user > to choose the behaviour of either SORF or DORF. > No, not the "user to choose", but the implementor. We can't possibly try to support both approaches. AntC _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users