On Tue, Jun 17, 2014 at 03:10:14PM -0400, Carter Schonwald wrote:
> to clarify: having bind would be equivalent to having arr for the
> purposes of my question (assuming its the standard monadic bind).
>
> having arr :: (b -> c) -> a b c
>
> is tantamount to assuming that any haskell function can
yes, that what I meant, though the standard >>= does need to be used
carefully on a restricted universe of types to ensure you can get a deep
embedding
On Tue, Jun 17, 2014 at 5:33 PM, John Lato wrote:
> Did you mean pure/return as the monadic equivalent? I've frequently
> encountered embedd
Did you mean pure/return as the monadic equivalent? I've frequently
encountered embeddings where it's possible to have a valid <*> and >>= but
not pure (or fmap).
On Jun 17, 2014 1:46 PM, "Carter Schonwald"
wrote:
>
> ok, so one example of this design, albeit implemented in a funky way
(compiler
ok, so one example of this design, albeit implemented in a funky way
(compiler passes written in coq), was
Adam Megacz's Garrows project http://www.megacz.com/berkeley/garrows/
a more concrete example of a haskell lib that enjoys a deep embedding and
doesn't let you inject arbitrary (f:: a-> b )
w
Conal (cc'd) also has an ongoing blog series about this
http://conal.net/blog/
On Tue, Jun 17, 2014 at 4:45 PM, Carter Schonwald <
carter.schonw...@gmail.com> wrote:
> ok, so one example of this design, albeit implemented in a funky way
> (compiler passes written in coq), was
> Adam Megacz's Gar
> assuming that any haskell function can be embedded in an
> arrow instance (...) prevents a lot of interesting deep embedding uses of the
> Arrow
> abstraction
Could you point me to some specific examples? I'm new to arrows and definitely
far from groking
all the arcana of their usage.
Janek
_
> You can use it, and a few of us have already been doing so. There isn't
> any Trac integration yet, but it works nicely for patch review.
Right. I was wondering about the inclusion of phabricator utilities in the GHC
tree - I believe
this was mentioned in the discussion.
> There's a short int
I would require a lot of convincing that we wanted Uniques for RdrNames. I
seriously doubt that, once the dust has settled, you'll need a finite map
indexed by RdrNames. But even if you do, you could use a TrieMap-like
structure.
Simon
| -Original Message-
| From: ghc-devs [mailto:gh
to clarify: having bind would be equivalent to having arr for the purposes
of my question (assuming its the standard monadic bind).
having arr :: (b -> c) -> a b c
is tantamount to assuming that any haskell function can be embedded in an
arrow instance
which prevents a lot of interesting deep emb
We just haven't needed one so far.
Can a RdrName and a Name have the same Unique? Well, of course that just
depends on what you are using the RdrName Uniques for. It's not a question
that has a yes or no answer.
Does it matter if (Orig m x) and (Orig n x) have the same Unique? Same answer,
e
So, without really trying to understand the code, what you are saying is this:
you want a finite map from RdrNames. That seems sensible enough, if the domain
elements all appear in the same scope in the Haskell source. I don't have
enough perspective to say whether a Uniquable instance is the wa
On 13/06/14 10:47, Jan Stolarek wrote:
It seems that most people are in favour of using Phabricator for code review.
So what are the next
steps? Can we just start using the existing phabricator instance? I'm working
on some code right
now that definitely needs reviewing.
You can use it, and a
> FYI it's #7828, not #7282.
Of course, yes.
> would making arrow remindable involve dropping the arr == haksell functions
> assumption or doing
> something that would allow generalized arrows?
Not sure if I fully understand what you mean. There's an idea to give up on
current desugaring
that
13 matches
Mail list logo
