| It already has a bug entry: #7828. What would help is to know the
| kind of use you have in mind, to see whether it fits with the proposed
| solution.
Indeed. Moreover #7828 is stalled; it needs some arrow-savvy person to focus
cycles on it. If rebindable syntax for arrows is considered
The GHC manual already for quite a number of version states:
• Arrow notation (see Section 7.17, “Arrow notation ”) uses whatever
arr, (), first, app, (|||) and loop functions are in scope.
But unlike the other constructs, the types of these functions must
match the Prelude
On Tue, Oct 14, 2014 at 10:26:46PM +0200, S. Doaitse Swierstra wrote:
The GHC manual already for quite a number of version states:
• Arrow notation (see Section 7.17, “Arrow notation ”) uses whatever
arr, (), first, app, (|||) and loop functions are in scope.
But unlike the
Dear all,
I introduce a very simple extension to the Lens datatype from Control.Lens
that allows it to work with Arrows:
https://gist.github.com/tomjaguarpaw/6865080
I would particularly like to discuss this with authors of Control.Lens to
see if such an idea is suitable for inclusion
On Mon, 7 Oct 2013 10:40:13 +0100, Tom Ellis
tom-lists-haskell-cafe-2...@jaguarpaw.co.uk wrote:
Dear all,
I introduce a very simple extension to the Lens datatype from Control.Lens
that allows it to work with Arrows:
https://gist.github.com/tomjaguarpaw/6865080
I would particularly
On Mon, Oct 07, 2013 at 07:14:44PM +0200, Niklas Haas wrote:
On Mon, 7 Oct 2013 10:40:13 +0100, Tom Ellis
tom-lists-haskell-cafe-2...@jaguarpaw.co.uk wrote:
I introduce a very simple extension to the Lens datatype from Control.Lens
that allows it to work with Arrows:
https
Control.Lens
that allows it to work with Arrows:
https://gist.github.com/tomjaguarpaw/6865080
The reason we don't tend to have combinators like ‘view’ or ‘over’
generalized in their return profunctor like that is because you very
quickly run into type ambiguity issues.
Perhaps I
Tom Ellis tom-lists-haskell-cafe-2...@jaguarpaw.co.uk wrote:
Unfortunately my type doesn't have a Monad instance.
If you could reveal the type, we could give more precise suggestions.
In most cases when you expose an `Arrow` interface you can also
expose a `Category`+`Applicative`
I feel I may be doing a lot of programming with Arrows in the near future.
Currently I'm delighted that Arrow notation[1] exists. It makes using
Arrows much less painful.
Are there any best-practices I should be aware of with Arrows? Or is it
just a case of getting on with it?
Tom
1. http
Tom Ellis tom-lists-haskell-cafe-2...@jaguarpaw.co.uk wrote:
Are there any best-practices I should be aware of with Arrows? Or is
it just a case of getting on with it?
The best practice is probably to avoid them. If your type is a monad,
there is little reason to use the awkward arrow
of with Arrows? Or is
it just a case of getting on with it?
The best practice is probably to avoid them. If your type is a monad,
there is little reason to use the awkward arrow interface.
Unfortunately my type doesn't have a Monad instance.
In most cases when you expose an `Arrow` interface you
and the `(| banana bracket notation |)`. This is very
valuable information.
Interesting. I hadn't noticed the `(| banana bracket notation |)` on the
GHC Arrows page[1] before, but just saw it when I went back to check.
The banana brackets can be handy when you have operations on your arrow
type beyond
* Stephen Tetley stephen.tet...@gmail.com [2013-04-16 19:48:47+0100]
On 16 April 2013 16:12, Alejandro Serrano Mena trup...@gmail.com wrote:
Hi,
First of all, let me say that this work on matchers is really useful :)
Following Roman advice, I'm trying to find a more principled approach
You are right Alejandro, arrows are a perfect fit here. (Most of it
is possible with monads as well, but arrows are useful to maintain
static names of the properties.)
Here's what I've come up with: https://gist.github.com/feuerbach/5409326
Now everyItem and hasJust have types
everyItem
it as a - Either
String a, because in this latter case we have a in covariant and
contravariant positions and it's difficult to get anything.
On the other hand, it seems very easy, from a Matcher a and a Matcher
b, to get a Matcher (a,b). This reminds me a bit about arrows, but
without output
me a bit about arrows, but
without output parameters. Does it make sense? I've always been
reluctant to arrows because I don't fully understand them, but maybe
this is a good moment to learn.
Do any of this make sense? I would really like to contribute to this
great library! :)
2013/4/16
On 16 April 2013 16:12, Alejandro Serrano Mena trup...@gmail.com wrote:
Hi,
First of all, let me say that this work on matchers is really useful :)
Following Roman advice, I'm trying to find a more principled approach
that could be useful for this library. It seems that Match could
easily be
case we have a in covariant and
contravariant positions and it's difficult to get anything.
On the other hand, it seems very easy, from a Matcher a and a Matcher
b, to get a Matcher (a,b). This reminds me a bit about arrows, but
without output parameters. Does it make sense? I've always been
#7071: Refactoring arrows
---+
Reporter: simonpj | Owner:
Type: bug | Status: closed
Priority: normal| Milestone
#7071: Refactoring arrows
---+
Reporter: simonpj | Owner:
Type: bug | Status: closed
Priority: normal| Milestone
#7071: Refactoring arrows
---+
Reporter: simonpj | Owner:
Type: bug | Status: closed
Priority: normal| Milestone
#7071: Refactoring arrows
---+
Reporter: simonpj | Owner:
Type: bug | Status: closed
Priority: normal| Milestone
Dear all,
I am trying to find a way to translate normal recursive notation such
as the |fib| function below to an arrow, retaining as much of the
structure of the recursive notation as possible. In addition I would
like to inspect the arrow. For this I created a datatype containing a
constructor
#7071: Refactoring arrows
-+--
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: normal| Milestone
#7071: Refactoring arrows
-+--
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: normal| Milestone
#7071: Refactoring arrows
-+--
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: normal| Milestone
#7071: Refactoring arrows
-+--
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: normal| Milestone
#7071: Refactoring arrows
-+--
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: normal| Milestone
#5605: T5267 (uses Arrows) core lint failure
---+
Reporter: igloo | Owner: ross
Type: bug | Status: closed
Priority: high
#5605: T5267 (uses Arrows) core lint failure
-+--
Reporter: igloo | Owner: ross
Type: bug | Status: new
Priority: high
#5605: T5267 (uses Arrows) core lint failure
-+--
Reporter: igloo |Owner: ross
Type: bug | Status: new
Priority: high |Milestone
#5605: T5267 (uses Arrows) core lint failure
-+--
Reporter: igloo |Owner:
Type: bug | Status: new
Priority: high |Milestone
#5605: T5267 (uses Arrows) core lint failure
-+--
Reporter: igloo |Owner: ross
Type: bug | Status: new
Priority: high |Milestone
On Mon, Oct 31, 2011 at 3:19 PM, John Lask jvl...@hotmail.com wrote:
On 1/11/2011 1:35 AM, Captain Freako wrote:
you need to study ArrowLoop and understand that.
Thanks, John.
I'm working my way through Hughes' suggested exercise in `Programming
with Arrows', to wit:
The reader who finds
Hi John,
I'm trying to use the GHCI debugger on this code:
20 instance ArrowLoop SF where
21 loop (SF f) = SF $ \as -
22 let (bs, cs) = unzip (f (zip as (stream cs))) in bs
23 where stream ~(x:xs) = x : stream xs
24
25 swap :: (a,b) - (b,a)
26 swap (x,y) = (y,x)
in
Try
swap p = (snd p, fst p)
or, equivalently
swap ~(x,y) = (y,x)
-- ryan
On Tue, Nov 1, 2011 at 1:30 PM, Captain Freako capn.fre...@gmail.comwrote:
Hi John,
I'm trying to use the GHCI debugger on this code:
20 instance ArrowLoop SF where
21 loop (SF f) = SF $ \as -
22
Never mind, I misread the code, 'zip' and the lazy definition of stream
should add the necessary laziness.
-- ryan
On Tue, Nov 1, 2011 at 3:36 PM, Ryan Ingram ryani.s...@gmail.com wrote:
Try
swap p = (snd p, fst p)
or, equivalently
swap ~(x,y) = (y,x)
-- ryan
On Tue, Nov 1, 2011
I can't comment on using ghci debugger to observe evaluation. I have in
the past used hood (http://hackage.haskell.org/package/hood) and found
it both convenient and useful when trying to observe evaluation order.
On 2/11/2011 7:00 AM, Captain Freako wrote:
Hi John,
I'm trying to use the
First, let's lay out our definitions:
unzip [] = ([], [])
unzip ((x,y):xys) = (x:xs, y:ys) where (xs,ys) = unzip xys
zip [] _ = []
zip _ [] = []
zip (x:xs) (y:ys) = (x,y) : zip xs ys
map _ [] = []
map f (x:xs) = f x : map f xs
stream ~(a:as) = a : stream as
-- equivalently
stream xs = head xs
Hi John,
Thanks for all your help.
I've been studying your suggested code:
type FilterAu b c = Automaton (-) b c
liftAu :: ((x,FilterState s)-(y,FilterState s)) - FilterState s -
FilterAu x y
liftAu f s0 = proc x - do
rec (y,s') - arr f - (x,s)
s - delay s0 - s'
returnA
Does anyone have figures 6 and 7, as well as the intervening
unnumbered figure, from `Programming with Arrows'?
Thanks,
-db
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
On 1/11/2011 1:35 AM, Captain Freako wrote:
you need to study ArrowLoop and understand that. In the code
rec (y,s')- arr f - (x,s)
s- delay s0 - s'
the state is 'captured' in the recursive binding. i.e. just like in real
circuits the output state s is threaded back as an input.
The
#5380: Too general type with Arrows extension
---+
Reporter: sebf|Owner: ross
Type: bug | Status: new
Priority: highest
#5380: arrows if command given too general a type
--+-
Reporter: sebf | Owner: ross
Type: bug | Status: closed
Priority
` is a function - a parameter of liftAu'. While all functions
are arrows (Arrow is defined on (-)), the value `arr f` is an arrow of the
automaton model. The `=` symbol is used to define the liftAu function. What
are you imagining?
___
Haskell-Cafe mailing
On Thu, Oct 20, 2011 at 5:19 AM, Captain Freako capn.fre...@gmail.comwrote:
Hi David,
I was referring to the `f' in the `runAuto' function, not the `liftAu'
function.
-db
Ah, I see. You quoted one thing and spoke of another, and I got all
confused. Keep in mind that functions are arrows
20, 2011 at 5:19 AM, Captain Freakocapn.fre...@gmail.comwrote:
Hi David,
I was referring to the `f' in the `runAuto' function, not the `liftAu'
function.
-db
Ah, I see. You quoted one thing and spoke of another, and I got all
confused. Keep in mind that functions are arrows (instance Arrow
John Lask wrote:
This is literate code. It expounds on your initial question and provides
two solutions based either on the StateArrow or Automaton
(Remainder omitted.)
John,
Thanks so much for your help!
I'm going to study your example code and try to understand how the
Automaton implicit
into the arrows is not buying you much.
John Lask wrote:
This is literate code. It expounds on your initial question and provides
two solutions based either on the StateArrow or Automaton
(Remainder omitted.)
John,
Thanks so much for your help!
I'm going to study your example code and try
not doing any composition as
such then lifting your functions into the arrows is not buying you much.
John Lask wrote:
This is literate code. It expounds on your initial question and provides
two solutions based either on the StateArrow or Automaton
(Remainder omitted.)
John,
Thanks so
)
this explicitly returns the state with evry value. However, you then need to
manually thread the state through.
note: the arrow plumbing is only used when you start composing filters,
with arrow combinators. If your not doing any composition as
such then lifting your functions into the arrows
,
-db
liftAu' f s0 = proc x - do
rec (y,s') - arr f - (x,s)
s - delay s0 - s'
returnA - (y,s)
The value `f` is a function - a parameter of liftAu'. While all functions
are arrows (Arrow is defined on (-)), the value `arr f` is an arrow of the
automaton model. The `=` symbol is used
Hi John,
Thanks for this reply:
Date: Tue, 18 Oct 2011 14:05:22 +1030
From: John Lask jvl...@hotmail.com
Subject: Re: [Haskell-cafe] How to implement a digital filter, using
Arrows?
To: haskell-cafe@haskell.org
Message-ID: BLU0-
smtp384394452fd2750fbe3bcfcc6...@phx.gbl
Content-Type
filter, using
Arrows?
To: haskell-cafe@haskell.org
Message-ID: BLU0-
smtp384394452fd2750fbe3bcfcc6...@phx.gbl
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
your function corresponds with Control.Arrow.Transformer.Automaton. If
you frame your function is such most of your
{-# LANGUAGE Arrows #-}
This is literate code. It expounds on your initial question and provides
two solutions based either on the StateArrow or Automaton
module Test where
import Data.List ( mapAccumL )
import Control.Arrow
import Control.Arrow.Operations
import
Hi all,
If I have a pure function, which maps `(input, initialState)' to `(output,
nextState)', what's the most succinct way of constructing a digital filter
from this function, using Arrows?
Thanks,
-db
___
Haskell-Cafe mailing list
Haskell-Cafe
your function corresponds with Control.Arrow.Transformer.Automaton. If
you frame your function is such most of your plumbing is taken care of.
http://hackage.haskell.org/packages/archive/arrows/0.4.1.2/doc/html/Control-Arrow-Transformer-Automaton.html
On 18/10/2011 1:46 PM, Captain Freako
#5380: Too general type with Arrows extension
---+
Reporter: sebf|Owner: ross
Type: bug | Status: new
Priority: highest
2011/9/30 John Lask jvl...@hotmail.com:
On 30/09/2011 7:15 AM, Sergey Mironov wrote:
Hello. I am reading Programming with Arrows by John Hughes (very
helpful and interesting!), the book has an exercises requiring a
module called Circuits for checking the answer. There should be things
like
Hello. I am reading Programming with Arrows by John Hughes (very
helpful and interesting!), the book has an exercises requiring a
module called Circuits for checking the answer. There should be things
like class ArrowCircuit and various functions related to digital logic
circuits simulation. Does
#5380: Too general type with Arrows extension
---+
Reporter: sebf|Owner:
Type: bug | Status: new
Priority: highest
#5380: Too general type with Arrows extension
---+
Reporter: sebf|Owner:
Type: bug | Status: new
Priority: normal
#5380: Too general type with Arrows extension
---+
Reporter: sebf|Owner:
Type: bug | Status: new
Priority: highest
#5380: Too general type with Arrows extension
---+
Reporter: sebf|Owner:
Type: bug | Status: new
Priority: highest
#5380: Too general type with Arrows extension
---+
Reporter: sebf| Owner:
Type: bug | Status: new
Priority: normal
#5045: panic! (the 'impossible' happened) compiling code using arrows and
elimReader (test case included)
-+--
Reporter: josh| Owner: simonpj
Type: bug
#5081: Unexpected passes arrows and ghci, typecheck and ghci
---+
Reporter: daniel.is.fischer | Owner:
Type: bug| Status: closed
Priority: normal
David Barbour dmbarb...@gmail.com writes:
you likened asynchronous/distributed products used in 'synch' to
'additive conjunction' in the earlier message (help for asynchronous
arrows) and the same concept to multiplicative disjunction here.
I apologize; I transposed additive
are your thoughts regarding this issue?
Yes, they certainly do clutter things up... but really, the whole
representation business is in there mostly to show that the functor is
identity-on-objects requirement of Freyd categories need not apply to
generalized arrows.
If you want to reduce the clutter
to some confusion that you likened asynchronous/distributed
products used in 'synch' to 'additive conjunction' in the earlier message
(help for asynchronous arrows) and the same concept to multiplicative
disjunction here.
Elements in such a product may exist at different times (i.e. production
I wonder if I need something like your use of 'representation' types, i.e.
to restrict what sort of elements can be stored in a collection.
I've just recently hit on the idea of using a barrier type 'V' to wrap a
synchronous value. A 'synchronous value' is one that can be observed at a
single
writes:
Peter Gammie suggested use of Adam Megacz's Generalized Arrows, which
would avoid this problem by use of an opaque product type that can
only be converted to a pair by an explicit operation (i.e. 'synch :: a
(b**c) (b,c)' for opaque product type (**)). I'm still debating
whether to take
David Barbour dmbarb...@gmail.com writes:
I've a preliminary model, using Adam Megacz's Generalized Arrows, of
the form:
Hey, neat. Actually, this sounds more like the generalized arrow
version of arrowized FRP's switch and par (Section 2.6 of [1]). I'd
been meaning to figure out the GArrow
Has anyone developed a typeclass model for (Control.Monad.mapM) and related
functions for arrows?
I've a preliminary model, using Adam Megacz's Generalized Arrows, of the
form:
class (GArrowDrop a (**) u) = GArrowMap_ a (**) u c where
mapA_ :: a d u - a (c d) u
class (GArrow a (**) u c
#5045: panic! (the 'impossible' happened) compiling code using arrows and
elimReader (test case included)
-+--
Reporter: josh| Owner: simonpj
Type: bug
#5045: panic! (the 'impossible' happened) compiling code using arrows and
elimReader (test case included)
---+
Reporter: josh|Owner: simonpj
Type: bug | Status: new
#5045: panic! (the 'impossible' happened) compiling code using arrows and
elimReader (test case included)
---+
Reporter: josh|Owner:
Type: bug | Status: new
#5081: Unexpected passes arrows and ghci, typecheck and ghci
--+-
Reporter: daniel.is.fischer | Owner:
Type: bug| Status: new
Priority: normal
)
first a3 will produce different result than (a1 a3) *** a2.
This is in direct conflict to arrow laws.
Arrows by themselves do not impose physical synchronization. They are
very often used to model computations about synchronous data streams,
but that is a very different concept.
In the actual
.
Arrows by themselves do not impose physical synchronization. They are
very often used to model computations about synchronous data streams,
but that is a very different concept.
In the actual implementation of such lifting (perhaps over multiple
type classes), the calculation of the time
#5045: panic! (the 'impossible' happened) compiling code using arrows and
elimReader (test case included)
---+
Reporter: josh|Owner:
Type: bug | Status: new
to a3, without
touching a2. However, arrows also allow:
(a1 *** a2) arr f
And, in this case, the current state of a1 and a2 must be combined
into a stream of pairs so that f may be mapped over the stream.
Obtaining both streams at a single place (a single vat) and time is a
synchronizing
I now understand where you are coming from, but I don't quite get your
motivation to develop new classes for arrows. Tupling is Haskell is of
course very lazy, it does not evaluate any of its element. As for the
spatial and logical concepts, don't you think they are over-specifying
what is really
Thanks for the elaboration. I now have a much better understanding.
FIrst of all, I agree that the system model as you laid out do not fit
into the arrows abstraction with respect to the set of arrow laws.
Then the choice is whether to shape the arrows to fit your model, or
shape your model
On 2011-03-21 01:18, David Barbour wrote:
I was giving Control.Arrow a try for a reactive programming system.
The arrows are agents that communicate by sending and returning
time-varying state. Different agents may live in different 'vats'
(event-driven threads) to roughly model distributed
#5045: panic! (the 'impossible' happened) compiling code using arrows and
elimReader (test case included)
---+
Reporter: josh| Owner:
Type: bug | Status: new
#5045: panic! (the 'impossible' happened) compiling code using arrows and
elimReader (test case included)
---+
Reporter: josh| Owner:
Type: bug | Status: new
David,
On 21/03/2011, at 4:18 PM, David Barbour wrote:
I was giving Control.Arrow a try for a reactive programming system.
The arrows are agents that communicate by sending and returning
time-varying state. Different agents may live in different 'vats'
(event-driven threads) to roughly model
I was giving Control.Arrow a try for a reactive programming system.
The arrows are agents that communicate by sending and returning
time-varying state. Different agents may live in different 'vats'
(event-driven threads) to roughly model distributed computing. For the
most part, the state varies
On Nov 7, 2010, at 1:40 AM, Sebastian Fischer wrote:
On Nov 6, 2010, at 10:00 PM, Sebastiaan Visser wrote:
List arrows are a powerful tool when processing XML, building query
languages and lots of other domains that build on functions that might
return more than one value as their output
I'm planning to write up a blog post about using list arrows for XML
processing.
Ok, I'll say tuned! Maybe a smaller example for the Haddock docs needs
less time.
Maybe this sounds weird on the Haskell mailing list, but at Silk[1]
we have a full implementation of (functional reactive
the above, we need a bunch of auxiliary arrows.
First, list con- and destructors:
cons :: Arrow (~) = (a,[a]) ~ [a]
cons = arr (uncurry (:))
uncons :: ArrowList (~) = [a] ~ (a,[a])
uncons = isA (not . null) arr (\ (x:xs) - (x,xs))
Second (and more annoyingly), reordering arrows
Hi all,
Live from the Hackaton in Ghent, Belgium, I present the first release of the
arrow-list[1,2] package. List arrows are a powerful tool when processing XML,
building query languages and lots of other domains that build on functions that
might return more than one value as their output
On Nov 6, 2010, at 10:00 PM, Sebastiaan Visser wrote:
List arrows are a powerful tool when processing XML, building query
languages and lots of other domains that build on functions that
might return more than one value as their output.
Interesting. Do you plan to write some examples
C. McCann wrote:
Heinrich Apfelmus wrote:
Combined with = / you have multiple reading direction in the same
expression, as in
expression ( c . b . a ) `liftM` a1 = a2 = a3
reading order 6 5 41 2 3
That's why I'm usually using = instead of = .
Does it
specialized subset of the
general arrow combinators. I think that dropping the arrows and
rebranding your nice set of combinators as filter combinators would
greatly improve the library.
But then, HXT's filter combinators would return to being rather like
HaXml's filter combinators, where the concept
Uwe Schmidt wrote:
In HXT, the concept of a filter is the most important one. This
concept is a natural generalisation of a function (and that's what
arrows are). A user has to grasp this idea of a filter. And he/she
can do this even without knowing anything about arrows or monads.
People
specialized subset of the
general arrow combinators. I think that dropping the arrows and
rebranding your nice set of combinators as filter combinators would
greatly improve the library.
But then, HXT's filter combinators would return to being rather like
HaXml's filter combinators, where the concept
,
guards ), it's just that they are a very specialized subset of the
general arrow combinators. I think that dropping the arrows and
rebranding your nice set of combinators as filter combinators would
greatly improve the library.
But then, HXT's filter combinators would return to being rather like
2010/10/13 Henning Thielemann schlepp...@henning-thielemann.de:
David Virebayre schrieb:
2010/10/12 Gregory Crosswhite gcr...@phys.washington.edu:
Also, I don't see why one would prefer over the standard function
composition operator, ..
With . you have to read right-to-left to follow
1 - 100 of 320 matches
Mail list logo
