Re: [Haskell-cafe] functional references and HList?
Edward Kmett wrote: Functional references let you both read and write 'attributes' in a structure. These can be chained to access members of members. You can also use them to build bidirectional views on fields (and compose those again as well). Martijn. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] functional references and HList?
Hi, from all this I'm not so sure that these two techniques do not overlap. I mean HList tries to provide a technique for extensible Records, or composable data structures. So far it is possible in Haskell to extend / compose Data Structures but not at run-time and also rather clumsily. One could of course use tuples or rather nested pairs to compose data structures too, which would work at run-time. But that would be very hard to maintain. HList implements this composability by elaborate type-level programming. In my opinion functional references allows for this too but not through type-level programming. Am I wrong? Günther Am 04.02.10 13:18, schrieb Martijn van Steenbergen: Edward Kmett wrote: Functional references let you both read and write 'attributes' in a structure. These can be chained to access members of members. You can also use them to build bidirectional views on fields (and compose those again as well). Martijn. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] functional references and HList?
I see them as addressing separate issues. They overlap in that they both address the notion of how to access attributes in some sense, but really they are complementary techniques. HList as used by OOHaskell provides you with a mechanism by which you can define extensible records and structural subtyping. Functional references let you both read and write 'attributes' in a structure. These can be chained to access members of members. These techniques can be used together to get extensible records that have settable fields in the form of functional references, where these references can be chained together. HList/OOHaskell doesn't concern itself with the 'deep reference' problem, and functional references do not concern themselves directly with extensible records. -Edward Kmett 2010/2/2 Günther Schmidt gue.schm...@web.de Hi all, I wonder if there is some a field of use overlap between HList and functional references aka accessors. Do both tackle the same problem? Günther ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] functional references and HList?
Hi all, I wonder if there is some a field of use overlap between HList and functional references aka accessors. Do both tackle the same problem? Günther ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Functional references
I've discussed the license of data-accessor with it's authors (Luke Palmer Henning Thieleman). They are ok with changing it to BSD3. So I don't think the license will be a reason not to use it. Tim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ganesh Sittampalam Sent: Saturday, 6 September 2008 4:52 AM To: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Functional references On Fri, 5 Sep 2008, Jules Bean wrote: I think it would be worth spending some time (on this mailing list, perhaps, or in another forum) trying to hash out a decent API which meets most people's requirements, rather than ending up with 4 or 5 slightly different ones. This sounds like a good plan, but please make sure the result is as free as GHC, rather than GPL like data-accessor is. It's so simple that it being GPL just drives people for whom licencing is an issue to write an alternative rather than consider complying. Ganesh ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Functional references
You should package this up and put it on hackage. It is nice, but there is already another FRef package on hackage (Data.Accessor) and I have a home-grown one of my own, which uses different notation / combinators to either the hackage one or Tim's. There are also fragments of FRef-like things in some of the big libraries like OpenGL and GTK. I think it would be worth spending some time (on this mailing list, perhaps, or in another forum) trying to hash out a decent API which meets most people's requirements, rather than ending up with 4 or 5 slightly different ones. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Functional references
On Fri, 5 Sep 2008, Jules Bean wrote: I think it would be worth spending some time (on this mailing list, perhaps, or in another forum) trying to hash out a decent API which meets most people's requirements, rather than ending up with 4 or 5 slightly different ones. This sounds like a good plan, but please make sure the result is as free as GHC, rather than GPL like data-accessor is. It's so simple that it being GPL just drives people for whom licencing is an issue to write an alternative rather than consider complying. Ganesh ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Functional references
On Thu, 4 Sep 2008, Ryan Ingram wrote: Nice. I've written similar stuff a couple of times before, but the formulation using Maybe and modify definitely solves some problems I started to notice as I used it on bigger structures. However, it might be better to separate a class of never failing references, where the reader is guaranteed to succeed, from potentially failing references which give a Maybe value. I'd also not use the names get and modify because they are already used by MonadState.I always used frGet, frSet, and frModify, and then tended to not use them directly as I was generally working in a state monad. Haskell already supports qualification, why manual prefixing? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Functional references
On Fri, Sep 5, 2008 at 1:39 PM, Henning Thielemann [EMAIL PROTECTED] wrote: Haskell already supports qualification, why manual prefixing? This is just a stylistic opinion, but I absolutely hate required qualifications; it is a waste of typing and, in my opinion, it makes the resulting code look more cluttered and harder to read. It's especially bad when modules are extremely likely to be used together, like Control.Monad.State FRef, or Data.Map the Prelude. You end up being required to import one or the other qualified. I direct you to my proposal for ad-hoc overloading, recently discussed on this list, as a way to solve this problem. In my experience, the code is almost always unambiguous without the qualification because using the wrong operator would fail to typecheck. In this case, I agree that manual prefixing isn't really better, but using ugly names encourages people to find better ones. I couldn't think of any off the top of my head, but I wasn't trying very hard. -- ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Functional references
It's especially bad when modules are extremely likely to be used together, like Control.Monad.State FRef, or Data.Map the Prelude. You end up being required to import one or the other qualified. I think in the case of State vs. FRef a simple solution is to make two modules: FRef, which uses get and set and modify naturally, and FRef.State which defines State equivalents without polluting the namespace. Then if you're working with pure functions you can import FRef and use the natural names, and when you're using the State monad you can import FRef.State and get the State definitions that dont interfere with the standard get and modify names. In the rare case (I think, am I wrong?) where you use both State and FRef modify and get definitions in the same file, you can import the one you use less off qualified... -- ryan Tim Newsham http://www.thenewsh.com/~newsham/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Functional references
I'm playing with functional references and looking for some feedback on a small FRec library I put together: http://www.thenewsh.com/~newsham/FRef.hs Novel (I think) is that the library is applied to some data accesses that are not normally covered by functional references -- ie. extracting words or replacing words in a string or values in an association list. I'm hoping it will provides a useful framework for editing complex values such as data embedded in Base64 cookies in an HTTP header. Tim Newsham http://www.thenewsh.com/~newsham/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Functional references
Nice. I've written similar stuff a couple of times before, but the formulation using Maybe and modify definitely solves some problems I started to notice as I used it on bigger structures. However, it might be better to separate a class of never failing references, where the reader is guaranteed to succeed, from potentially failing references which give a Maybe value. I'd also not use the names get and modify because they are already used by MonadState.I always used frGet, frSet, and frModify, and then tended to not use them directly as I was generally working in a state monad. Here's a few more primitives that I found quite useful: fetch :: MonadState s m = FRef s a - m (Maybe a) fetch ref = liftM (frGet ref) get (=:) :: MonadState s m = FRef s a - a - m () r =: v = modify (frSet r v) ($=) :: MonadState s m = FRef s a - (a - a) - m () r $= f = modify (frModify r f) You should package this up and put it on hackage. -- ryan On Thu, Sep 4, 2008 at 4:51 PM, Tim Newsham [EMAIL PROTECTED] wrote: I'm playing with functional references and looking for some feedback on a small FRec library I put together: http://www.thenewsh.com/~newsham/FRef.hs Novel (I think) is that the library is applied to some data accesses that are not normally covered by functional references -- ie. extracting words or replacing words in a string or values in an association list. I'm hoping it will provides a useful framework for editing complex values such as data embedded in Base64 cookies in an HTTP header. Tim Newsham http://www.thenewsh.com/~newsham/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
