Personally, I don't like the sigil mangled version at all. You don’t comment on the relationship with implicit parameters. Are they ok with sigils? If it is then further encumbered by a combinator it is now several symbols longer at every single use site than other alternatives put forth in this thread. =( No, as Nikita says, under the “Redesign” proposal it would be #bar . #baz The import Field trick is magic, yes, but it has the benefit of being the first approach I've seen where the resulting syntax can be as light as what the user can generate by hand today. That’s why I added it to the “Redesign” page. It seems viable to me; a clever idea, thank you. Still, personally I prefer #x because of the link with implicit parameters. It would be interesting to know what others think. I'm confess, I, like many in this thread, am less than comfortable with the notion of bringing chunks of lens into base. Frankly, I'd casually dismissed such concerns as a job for Haskell 2025. ;) However, I've been trying to consider it with an open mind here, because the alternatives proposed thus far lock in uglier code than the status quo with more limitations while simultaneously being harder to explain. I don’t think anyone is suggesting adding any of lens are they? Which bits did you think were being suggested for addition? Note: once you start using a data-type then (.) necessarily fails to allow you to ever do type changing assignment, due to the shape of Category, or you have to use yet another operator, so that snippet cannot work without giving up something we can do today. OTOH: Using the lens-style story, no types are needed here that isn't already available in base and, done right, no existing operators need be stolen from the user, and type changing assignment is trivial. I’m afraid I couldn’t understand this paragraph at all. Perhaps some examples would help, to illustrate what you mean? Simon
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
