On Mon, Jan 26, 2015 at 4:41 PM, Simon Peyton Jones <[email protected]> wrote:
> 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? > I don't have too many opinions about implicit parameters, but they don't really see a lot of use, which makes me somewhat leery of copying the pattern. ;) 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 problem is that if you make #bar an instance of Category so that it can use (.) then it will fail to allow type changing re-assignment. > 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. > Admittedly @bar . @baz has the benefit that it introduces no namespacing conflicts at all. If we really had to go with some kind of sigil based solution, I _could_ rally behind that one, but I do like it a lot less than the import trick, if only because the import trick gets rid of that last '@' and space we have on every accessor and you have to admit that the existing foo^.bar.baz.quux idiom reads a lot more cleanly than foo ^. @bar . @baz . @quux ever can. (I used @foo above because it avoids any potential conflict with existing user code as @ isn't a legal operator) 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? > I was mostly referring to the use of the (a -> f b) -> s -> f t form. > 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? > I was writing that paragraph in response to your query if it'd make sense to have the @foo return some data type: It comes at a rather high cost. Lens gets away with using (.) to compose because its really using functions, with a funny mapM-like shape (a -> f b) -> (s -> f t) is still a function on the outside, it just happens to have a (co)domain that also looks like a function (a -> f b). If we make the outside type constructor a data type with its own Category instance, and just go `Accessor s a` then it either loses its ability to change out types in s -- e.g. change out the type of the second member in a pair, or it loses its ability to compose. We gave up the latter to make Gundry's proposal work as we were forced into that shape by trying to return a combinators that could be overloaded to act as an existing accessor function. To keep categorical composition for the accessor, you might at first think we can use a product kind or something to get Accessor '(s,t) '(a,b) with both indices but that gets stuck when you go to define `id`, so necessarily such a version of things winds up needing its own set of combinators. -Edward
_______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
