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.
On
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.
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 s
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/listin
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 fo
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
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 l
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
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 p
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 th
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 guarantee
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
12 matches
Mail list logo
