Send Beginners mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. Re: Monad and bind operator interpretation (Rein Henrichs)
2. Re: Extend instance for List (Gesh)
3. Re: Doubts about functional programming paradigm (emacstheviking)
----------------------------------------------------------------------
Message: 1
Date: Tue, 15 Dec 2015 13:00:42 -0800
From: Rein Henrichs <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] Monad and bind operator
interpretation
Message-ID:
<m2r3in5sw5.fsf@Reins-iMac.local.i-did-not-set--mail-host-address--so-tickle-me>
Content-Type: text/plain
Raja <[email protected]> writes:
> Now my new hypothetical interpretation becomes:
>
> (>>=) :: (a -> m b) -> m a -> m b
You have independently discovered (=<<), which is excellent news!
> If i further add parens:
>
> (>>=) (a -> m b) -> (m a -> m b)
>
> This allows me to slightly tweak my interpretation:
>
> bind takes one param f (of type a -> m b) and returns another param f (of
> type m
> a -> m b)
>
> This feels like a more intuitive way to think about Monads - am I on the right
> track?
> (not that I want to switch the params permanently - just trying to get a feel
> for monads)
Yes, you are absolutely on the right track. One way to interpret bind is
as a particular way to abstract function application. Consider these
types:
($) :: (a -> b) -> a -> b
(<$>) :: Functor f => (a -> b) -> f a -> f b
(=<<) :: Monad m => (a -> m b) -> m a -> m b
All of them take a particular type of function and "lift" it to apply to
a particular type of value. ($) performs an "identity lift", which is to
say that it does no lifting at all[1]. (<$>), aka fmap, lifts functions
to apply "in" a Functor "context". (=<<) lifts functions (of a certain
type) to apply in a Monad context. (The ability to talk about these
sorts of abstract functions is one of the motivations of Category
Theory, not that you need to know CT to do Haskell.)
Note also that these are listed in strictly increasing order of
expressiveness, which is to say that a later operator can do anything
that an earlier operator can do, but not vice versa[2]. If you explore
exactly what (=<<) can do that fmap cannot, you may learn something else
about monads!
[1]: By the way, you can also define ($) as id. id f = f is exactly the
"identity lift" that I am taliking about! Using your "add parens"
interpretation, ($) takes an (a -> b) and gives an (a -> b) (the
same one you gave it).
[2]: As long as you admit that Identity x is equivalent to x.
------------------------------
Message: 2
Date: Wed, 16 Dec 2015 09:57:21 +0200
From: Gesh <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] Extend instance for List
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
On December 15, 2015 12:36:58 PM GMT+02:00, Kim-Ee Yeoh <[email protected]> wrote:
>On Tue, Dec 15, 2015 at 12:43 AM, Graham Gill <[email protected]>
>wrote:
>
>I guessed that the correct Extend instance for List is needed for
>Comonad,
>> but didn't have any intuition about it.
>>
>
>List is not comonadic. In this case, the function copure must be of
>type
>[a] -> a, which must necessarily be partial.
>
>(Non-empty lists, on the other hand, are comonadic.)
In fact, it seems this distinction is true of any type that has an empty case,
i.e. f s.t. exists g. f a = 1 + g a.
What blinded me was the fact that for such types, usually the definition of
extend extends naturally to the empty case. So obviously the possibly-empty
types have an Extend instance inherited from their nonempty counterparts, but
it is only the latter who have Comonad instances.
>Graham's "Extend" -- I'll explain the scare quotes in a minute --
>instance
>for List obeys the associative law. So it's a valid instance but a bit
>boring. The exercise asks for an interesting instance.
Indeed, the same problem exists dually for Monad, where one can force the empty
case always and obtain a Monad isomorphic to Const ().
Thanks for the correction and illumination,
Gesh
>The way the NICTA course is structured, there's no mention of the
>> dependence between "extend" and "copure" (equivalent to extract and
>> duplicate I suppose) via the Comonad laws when considering Extend
>first by
>> itself.
>>
>
>It's a bit terse, but you can find "class Extend f => Comonad f" in
>Comonad.hs. After all, we're only looking at the exercises. The live
>lecture version probably does talk about the dependence.
>
>
>> I'm not knocking the NICTA course. I've found it useful. A quick
>paragraph
>> or two as you've written, stuck into the source files as comments,
>would
>> improve it.
>>
>
>Most folks are neutral about the course. If parts of it work for you,
>great. If not, no worries. The whole comonadic business is a bit
>obscure
>and some of the strongest haskell programmers don't bat an eyelid over
>not
>knowing it.
>
>p.s. "Extend" doesn't agree with the CT literature. See the paragraph
>that
>starts "The dual problem is the problem of lifting a morphism" here:
>
>http://ncatlab.org/nlab/show/extension
>
>But calling it a "lift" or "lifting" will only add to the confusion
>since
>monad transformers got first dibs on the terminology. Which is why you
>sometimes see "coextend" or (for the flipped version) "cobind".
>
>
>-- Kim-Ee
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Beginners mailing list
>[email protected]
>http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
------------------------------
Message: 3
Date: Wed, 16 Dec 2015 09:58:24 +0000
From: emacstheviking <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] Doubts about functional programming
paradigm
Message-ID:
<caeieuu+no5zwj7et7y2hrz8nasrosupsq-rbjav5mxjgas5...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I'm firmly with Derek.. we should teach people things like maps, folds and
generic recursion instead of subjecting them to stuff like Java or C++. I'm
not starting a war here, just stating that after 30+ years in software,
mentoring and helping people learn... that, like teaching your kid to read
or play guitar... the magic just happens. They learn and you don't know how
they learned but they take it in and build on it.
By not clouding impressionable learning minds with the gory details for for
loops and such like but instead immediately beginning their programming
lives with maps folds and recursion I think we would be raising the level
of goodness... then maybe Haskell would be taught in schools!
I taught myself prolog a year or three back...thanks to my FP skills,
concepts like recursion were a done deal and backtracking was not that hard
to take on board. Maybe we should teach Prolog as the first language people
ever learn!
Regarding language pragmas. Yes!!! A complete hitch-hikers guide with
information examples would be good. I have often tried to work with code I
find only realise that the author had used the "automatically munge strings
to be the right type" option and not mentioned it.
Whatever. Haskell started in '98, it's 2016 now... it's going to last!
:)
Sean
On 15 December 2015 at 20:13, Rein Henrichs <[email protected]> wrote:
>
> Mr. McIlroy,
>
> FWIW I would love to read more about that McCarthy talk. It
> sounds like an amazing experience.
>
> > There is no authoritative source about these pragmas. They are listed
> > and described in the GHC User Guide, but that source all too often
> > defines solely by example, not even bolstered by a formal syntax
> > specification.
>
> I think it would very helpful simply to better (and more rigorously)
> document the syntax and semantics of the available extensions. There is
> currently a call to action to update GHC's Haddock documentation in
> preparation for the 8.0 release [1]. Perhaps some effort can also be
> directed towards the documentation of the LANGUAGE pragmas.
>
> There is still a problem, though: For completeness, one must consider
> the interactions of the various subsets of these pragmas, some of which
> are already known to be unsound. What's worse, the number of extant
> pragmas already makes an enumeration of these subsets impractical, since
> there are some 10^31 of them even ignoring the "NoX" pragmas.
>
> The only long-term solution then seems to be to codify a new Haskell
> standard that incorporates some known-good subset of these pragmas that
> the community seems to agree on, which I suppose is part of the task
> that the Haskell Prime committee has before them. I do not envy them.
>
> [1]: https://mail.haskell.org/pipermail/ghc-devs/2015-December/010681.html
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.haskell.org/pipermail/beginners/attachments/20151216/a154d483/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
Beginners mailing list
[email protected]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
------------------------------
End of Beginners Digest, Vol 90, Issue 33
*****************************************
