Send Beginners mailing list submissions to
beginners@haskell.org
To subscribe or unsubscribe via the World Wide Web, visit
http://www.haskell.org/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
beginners-requ...@haskell.org
You can reach the person managing the list at
beginners-ow...@haskell.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. Re: Type classes and synonyms (Isaac Dupree)
2. reverse flow . (Michael P. Mossey)
3. Re: reverse flow . (Michael Mossey)
4. Re: reverse flow . (Tony Morris)
5. Re: reverse flow . (Nicolas Pouillard)
6. combinatorial (Michael P. Mossey)
7. Re: Type classes and synonyms (Stephen Tetley)
8. Re: Type classes and synonyms (Brent Yorgey)
9. Re: Type classes and synonyms (pbrowne)
----------------------------------------------------------------------
Message: 1
Date: Sat, 21 Nov 2009 23:18:22 -0500
From: Isaac Dupree <m...@isaac.cedarswampstudios.org>
Subject: Re: [Haskell-beginners] Type classes and synonyms
Cc: beginners@haskell.org
Message-ID: <4b08bb8e.3060...@isaac.cedarswampstudios.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Sorry to take offense :-) maybe I was being too modest?
What leads me to conclude that is... Reading several papers about uses
of Arrows and Applicative and Monads for parsing and FRP, being on the
mailing-lists for a few years listening to debates and people struggling
with bits of code, getting a sense of the history of each abstraction
and of how people who use that abstraction daily relate to it. (let's
see if I can name names... Ross Paterson, Conor McBride, maybe Simon
Peyton-Jones..). Experimenting a bit with my own code. Having a vague
sense, through coding Haskell quite a bit, how much it's possible to
condense a piece of code. It is not a conclusion of compulsion, just
that I haven't seen it done better. It seems Arrows are a necessary
abstraction for a couple very particular world-views/paradigms, and
don't fit very well with a lot of other stuff.
So far, I haven't used FRP for anything major, and I've done most
parsing with Parsec (monad-based) and Happy (hmm, it's a preprocessor).
Since I don't have lots of experience with the examples, I didn't want
to claim to understand the abstraction(class) very well. :-)
-Isaac
Tony Morris wrote:
> If you don't yet understand Arrows, then what compels you to conclude
> that there are more idiomatic solutions (than what you don't yet
> understand)?
> Just sayin'
>
> Isaac Dupree wrote:
>> Philip Scott wrote:
>>> Thanks John,
>>>
>>>> Every module can have its own definition for each name, such as the
>>>> operator (+). So in your module (eg. module Main, or module
>>>> DateValueSeries), you can go ahead and define your own (+). The major
>>>> caveat is making sure you don't conflict with the default (+),
>>>> which lives
>>>> in module Prelude, which is normally automatically brought into scope.
>>> That actually quite nicely solves the problem... it feels almost a
>>> little too easy, after spending the evening getting my mind wrapped
>>> up with Arrows :)
>> why has no one mentioned: you most likely don't need to understand
>> Arrows? I'm pretty good with Haskell, and Arrows are still somewhat
>> confusing to me. Why? Most problems I've worked with in Haskell have
>> had more-idiomatic solutions than Arrows. (examples include: Monad;
>> Functor; Applicative; just plain functions; plain old lack of
>> type-class abstraction.) It's not so easy or useful to understand any
>> abstraction/class without using at least two or three useful
>> examples/instances of it first.
>>
>> -Isaac
>> _______________________________________________
>> Beginners mailing list
>> Beginners@haskell.org
>> http://www.haskell.org/mailman/listinfo/beginners
>>
>
------------------------------
Message: 2
Date: Sat, 21 Nov 2009 23:51:38 -0800
From: "Michael P. Mossey" <m...@alumni.caltech.edu>
Subject: [Haskell-beginners] reverse flow .
To: beginners@haskell.org
Message-ID: <4b08ed8a.7000...@alumni.caltech.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Can I get some recommendations on defining a function composition
operator that flows in the reverse direction?
Thanks,
Mike
------------------------------
Message: 3
Date: Sun, 22 Nov 2009 00:25:55 -0800
From: Michael Mossey <m...@alumni.caltech.edu>
Subject: Re: [Haskell-beginners] reverse flow .
To: beginners@haskell.org
Message-ID: <4b08f593.3020...@alumni.caltech.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
To clarify, I'm interested in
- what symbols you would choose
- how to set the left/right associativity and precedence
Michael P. Mossey wrote:
> Can I get some recommendations on defining a function composition
> operator that flows in the reverse direction?
>
> Thanks,
> Mike
>
> _______________________________________________
> Beginners mailing list
> Beginners@haskell.org
> http://www.haskell.org/mailman/listinfo/beginners
------------------------------
Message: 4
Date: Sun, 22 Nov 2009 18:47:34 +1000
From: Tony Morris <tonymor...@gmail.com>
Subject: Re: [Haskell-beginners] reverse flow .
To: Michael Mossey <m...@alumni.caltech.edu>
Cc: beginners@haskell.org
Message-ID: <4b08faa6.6030...@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
There is already one.
Prelude Control.Arrow> :type (>>>)
(>>>) :: (Control.Category.Category cat) => cat a b -> cat b c -> cat a c
Michael Mossey wrote:
> To clarify, I'm interested in
>
> - what symbols you would choose
> - how to set the left/right associativity and precedence
>
> Michael P. Mossey wrote:
>> Can I get some recommendations on defining a function composition
>> operator that flows in the reverse direction?
>>
>> Thanks,
>> Mike
>>
>> _______________________________________________
>> Beginners mailing list
>> Beginners@haskell.org
>> http://www.haskell.org/mailman/listinfo/beginners
> _______________________________________________
> Beginners mailing list
> Beginners@haskell.org
> http://www.haskell.org/mailman/listinfo/beginners
>
--
Tony Morris
http://tmorris.net/
------------------------------
Message: 5
Date: Sun, 22 Nov 2009 09:49:31 +0100
From: Nicolas Pouillard <nicolas.pouill...@gmail.com>
Subject: Re: [Haskell-beginners] reverse flow .
To: Michael P.Mossey <m...@alumni.caltech.edu>
Cc: beginners <beginners@haskell.org>
Message-ID: <1258879747-sup-...@peray>
Content-Type: text/plain; charset=UTF-8
Excerpts from Michael P. Mossey's message of Sun Nov 22 08:51:38 +0100 2009:
> Can I get some recommendations on defining a function composition
> operator that flows in the reverse direction?
There is (>>>) in Control.Category.
--
Nicolas Pouillard
http://nicolaspouillard.fr
------------------------------
Message: 6
Date: Sun, 22 Nov 2009 02:25:45 -0800
From: "Michael P. Mossey" <m...@alumni.caltech.edu>
Subject: [Haskell-beginners] combinatorial
To: beginners@haskell.org
Message-ID: <4b0911a9.8030...@alumni.caltech.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
I'm trying to write a combinatorial search algorithm with evaluation,
and kind of stuck. Not sure how to do this.
I'm constructing a musical phrase, which is a list of MidiPitch:
[MidiPitch]
I have an evaluation function that determines the fitness of any given
phrase:
eval :: [MidiPitch] -> Maybe Float
This returns Nothing if the phrase is completely unacceptable.
The idea is to build up a phrase one midi pitch at a time, choosing all
possible next pitches (notes) from a range:
next pitch comes from: [10..90]
Most of the pitches will result in a phrase that evaluates to Nothing,
so the combinatoral "explosion" will be limited.
I'd like to write a function that constructs a phrase of length n, and
in fact will have to return a list of all phrases that have equal scores
of the maximum.
-- <length of output phrase> -> <first pitch> -> <eval func> ->
-- <all tied phrases of best score>
coolFunc :: Int -> MidiPitch -> ([MidiPitch] -> Maybe Float) ->
[[MidiPitch]]
I am stuck on how to write this.
thanks,
Mike
------------------------------
Message: 7
Date: Sun, 22 Nov 2009 11:31:05 +0000
From: Stephen Tetley <stephen.tet...@gmail.com>
Subject: Re: [Haskell-beginners] Type classes and synonyms
To: beginners@haskell.org
Message-ID:
<5fdc56d70911220331r269340baj114bcf81af792...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
2009/11/22 Isaac Dupree <m...@isaac.cedarswampstudios.org>:
> Sorry to take offense :-) maybe I was being too modest?
>
> It seems Arrows are a necessary abstraction for a couple very particular
> world-views/paradigms, and don't fit very well with a lot of other stuff.
>
Hello All
I wouldn't go quite as far as saying Arrows are misfits, but in
Isaac's defence, if all you have are pure functions, then arrows are
just a wee bit, erm, boring.
In Philip's original message he happened to be representing his data
as a pair, so second worked fine as a projection/application function,
vis:
*Arrows> second (\x -> "fish") (10,20)
(10,"fish")
But of course it doesn't work as a projection/application function for
triples (sorry I lack a better term for projection/application):
*Arrows> second (\x -> "chips") (10,20,30)
<interactive>:1:0:
Couldn't match expected type `(t, t1, t2)'
against inferred type `(d, b)'
In the expression: second (\ x -> "chips") (10, 20, 30)
In the definition of `it':
it = second (\ x -> "chips") (10, 20, 30)
Nor would it work if Philip had defined his own data type.
Also for pure functions the derived operators (>>^) and (^>>) become
(.), and (<<^) & (^<<) are become reverse composition - which was
sometimes called (##) but now seems categorized as (<<<) .
The code below is a bit superfluous to the discussion, but it does
define the arrow operations for pure functions with the type
constructor simplified to (->), I occasionally do the Arrow
combinators longhand when I can't remember which Arrow combinator does
what.
Best wishes
Stephen
> module ArrowLonghand where
> import Control.Arrow
arr :: (b -> c) -> a b c
fun_arr :: a b c -> (b -> c) where a = (->)
> fun_arr :: (b -> c) -> (b -> c)
> fun_arr f = f
arr's definition is clearly identity, but specialized to functions
> alt_fun_arr :: (b -> c) -> (b -> c)
> alt_fun_arr = id
first :: a b c -> a (b, d) (c, d)
fun_first :: a b c -> a (b,d) (c,d) where a = (->)
> fun_first :: (b -> c) -> (b,d) -> (c,d)
> fun_first f (x,y) = (f x, y)
second :: a b c -> a (d, b) (d, c)
fun_second :: a b c -> a (d,b) (d,c) where a = (->)
> fun_second :: (b -> c) -> (d,b) -> (d,c)
> fun_second f (x,y) = (x, f y)
(***) :: a b c -> a b' c' -> a (b, b') (c, c')
fun_starstarstar :: a b c -> a b' c' -> a (b,b') (c,c') where a = (->)
> fun_starstarstar :: (b -> c) -> (b' -> c') -> (b,b') -> (c,c')
> fun_starstarstar f g (x,y) = (f x, g y)
Funnily enough, (***) is not unlike prod from Jeremy Gibbons
'Pair Calculus':
http://www.comlab.ox.ac.uk/oucl/work/jeremy.gibbons/publications/acmmpc-calcfp.pdf
> prod :: (b -> c) -> (b' -> c') -> (b,b') -> (c,c')
> prod f g = fork (f . fst, g . snd)
(&&&) :: a b c -> a b c' -> a b (c, c')
fun_ampampamp :: a b c -> a b c' -> a b (c,c') where a = (->)
> fun_ampampamp :: (b -> c) -> (b -> c') -> b -> (c,c')
> fun_ampampamp f g x = (f x, g x)
Funnily enough, (&&&) is not unlike fork from the Pair Calculus...
> fork :: (b -> c, b -> c') -> b -> (c,c')
> fork (f,g) a = (f a, g a)
> pair_first :: (b -> c) -> (b,d) -> (c,d)
> pair_first f = f `prod` id
> pair_second :: (b -> c) -> (d,b) -> (d,c)
> pair_second g = id `prod` g
--------------------------------------------------------------------------------
(^>>) :: Arrow a => (b -> c) -> a c d -> a b d
> preCompLR :: (b -> c) -> (c -> d) -> (b -> d)
> preCompLR f g = \x -> g (f x)
(>>^) :: Arrow a => a b c -> (c -> d) -> a b d
> postCompLR :: (b -> c) -> (c -> d) -> (b -> d)
> postCompLR f g = \x -> g (f x)
(^>>) and (>>^) are the same for functions.
-- reverse
(<<^) :: Arrow a => a c d -> (b -> c) -> a b d
> preCompRL :: (c -> d) -> (b -> c) -> (b -> d)
> preCompRL f g = \x -> f (g x)
(^<<) :: Arrow a => (c -> d) -> a b c -> a b d
> postCompRL :: (c -> d) -> (b -> c) -> (b -> d)
> postCompRL f g = \x -> f (g x)
------------------------------
Message: 8
Date: Sun, 22 Nov 2009 10:30:20 -0500
From: Brent Yorgey <byor...@seas.upenn.edu>
Subject: Re: [Haskell-beginners] Type classes and synonyms
To: beginners@haskell.org
Message-ID: <20091122153020.ga31...@seas.upenn.edu>
Content-Type: text/plain; charset=us-ascii
On Sat, Nov 21, 2009 at 09:07:38PM +0000, Philip Scott wrote:
> > The final piece is that (->) is an Arrow, the most basic one but still
> > an Arrow, so if you replace a by (->) in the type of second, you get :
> > second :: (->) b c -> (->) (d, b) (d, c)
> > which is just
> > second :: (b -> c) -> (d, b) -> (d, c)
>
> Ahh I see, very clever! There is method to the madness after all; I should
> never have doubted you Haskell. Thank you for taking the time to explain that
> :)
>
> Do you know of any good discussions/tutorials on Arrows? I've only managed to
> find little snippets here and there
>
> http://www.haskell.org/arrows/
The two tutorials linked from the "Bibliogrphy" section of that page
are very good:
http://www.soi.city.ac.uk/~ross/papers/fop.html
http://www.cs.chalmers.se/~rjmh/afp-arrows.pdf
You may also be interested in reading the "Category" and "Arrow"
sections of the Typeclassopedia:
http://www.haskell.org/sitewiki/images/8/85/TMR-Issue13.pdf
-Brent
------------------------------
Message: 9
Date: Sun, 22 Nov 2009 15:32:07 +0000
From: pbrowne <patrick.bro...@comp.dit.ie>
Subject: Re: [Haskell-beginners] Type classes and synonyms
To: Felipe Lessa <felipe.le...@gmail.com>
Cc: beginners@haskell.org
Message-ID: <4b095977.4080...@comp.dit.ie>
Content-Type: text/plain; charset=UTF-8
On Sat, Nov 21, 2009 at 21:08 Felipe Lessa wrote:
> Most definitions, if not all, are just the corresponding free theorems
> (meaning roughly that the definition follows from the type
> because that's the only definition that doesn't have
> undefined's).
Question: Is it correct to paraphrase Felipe's description as follows:
In Haskell the *term theorems for free* means roughly that the
definition of a class, instance or a function follows from the supplied
types because they are the only types that donât have undefined argumens
or undefined return types.
Regards,
Pat
------------------------------
_______________________________________________
Beginners mailing list
Beginners@haskell.org
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 17, Issue 23
*****************************************
