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: Doubts about functional programming paradigm
(Dimitri DeFigueiredo)
2. Re: Doubts about functional programming paradigm (Dan Stromberg)
3. Extend instance for List (Graham Gill)
4. Re: Extend instance for List (Gesh)
----------------------------------------------------------------------
Message: 1
Date: Mon, 14 Dec 2015 00:03:43 -0200
From: Dimitri DeFigueiredo <[email protected]>
To: Henk-Jan van Tuyl <[email protected]>, 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: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Oops! Sorry, I think I wasn't clear. I know the answers to all the
questions I asked. They were rhetorical questions.
I just wanted to make a point that learning haskell is *much* harder
than learning most other programming languages and the (multitude of)
learning aids that are available are not yet cohesive enough to present
a clear path ahead for the average programmer. I also think this is the
main reason haskell will NOT be more widely used any time soon, despite
its many other advantages.
I think newcomers to the language should know this before they start to
evaluate their reasons and seek help from others (as in this list) to
guide them in the process.
Thank you very much for the pointers in any case, they look very good.
Dimitri
On 12/13/15 9:51 PM, Henk-Jan van Tuyl wrote:
> On Sat, 12 Dec 2015 01:56:48 +0100, Dimitri DeFigueiredo
> <[email protected]> wrote:
>
> :
>> Couldn't match expected type ?r? with actual type ?COParseResult?
>> ?r? is a rigid type variable bound by
>> the type signature for
>> getParseResult :: ParseResult r => String -> IO r
>> ...
>>
>> I have a PhD in computer science, but never really liked programming
>> languages back then and somehow I never learned what a "rigid type
>> variable" is.
>
> See
> [Haskell-cafe] What is a rigid type variable?
> https://mail.haskell.org/pipermail/haskell-cafe/2008-June/044622.html
>
> :
>> But would anyone care to explain to a
>> novice in a couple paragraphs why foldl (+) 0 [1..10^9] may take 10 Gigs
>> of RAM to calculate?
>
> The foldl builds up a very long expression and evaluates it after the
> last element of the list is reached (the evaluation is non-strict, or
> lazy). If you use foldl' (from Data.List) instead, the calculation is
> done per element (the evaluation is strict).
>
> For more details, see
> Foldr Foldl Foldl'
> https://wiki.haskell.org/Foldr_Foldl_Foldl'
>
> Lazy vs. non-strict
> https://wiki.haskell.org/Lazy_vs._non-strict
>
> Regards,
> Henk-Jan van Tuyl
>
>
------------------------------
Message: 2
Date: Sun, 13 Dec 2015 18:28:07 -0800
From: Dan Stromberg <[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:
<CAOvKW57O13kXiEJAkx+A+8no4GKT2=Dp45=h5b1ecw3xafo...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Sun, Dec 13, 2015 at 4:02 PM, Imants Cekusins <[email protected]> wrote:
> > The foldl builds up a very long expression and evaluates it after the
> last element of the list is reached (the evaluation is non-strict, or
> lazy). If you use foldl' (from Data.List) instead, the calculation is done
> per element (the evaluation is strict).
>
> Is it possible to write a wrapping function (if it does not already exist)
> which would analyze inputs and apply appropriate fold (foldl, foldl',
> foldr, foldr') or safeguard (return Left warning) against following the
> 10Gb ram route - if this can be avoided?
>
I know next to nothing about Haskell, but I suspect this would require
knowing whether a list is finite or infinite, which may be equivalent to
"the halting problem" - IOW, not possible in general in a finite amount of
time.
--
Dan Stromberg
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.haskell.org/pipermail/beginners/attachments/20151213/688b6519/attachment-0001.html>
------------------------------
Message: 3
Date: Sun, 13 Dec 2015 23:57:27 -0500
From: Graham Gill <[email protected]>
To: Haskell Beginners <[email protected]>
Subject: [Haskell-beginners] Extend instance for List
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
The NICTA course <https://github.com/NICTA/course> includes exercises on
the type class Extend, in Course/Extend.hs. Extend is a superclass of
Comonad. Here's the class definition:
> -- | All instances of the `Extend` type-class must satisfy one law.
> This law
> -- is not checked by the compiler. This law is given as:
> --
> -- * The law of associativity
> -- `?f g. (f <<=) . (g <<=) ? (<<=) (f . (g <<=))`
> class Functor f => Extend f where
> -- Pronounced, extend.
> (<<=) ::
> (f a -> b)
> -> f a
> -> f b
>
> infixr 1 <<=
Could someone please motivate the Extend instance for List? (Its
implementation is left as an exercise. In the course, type List a is
isomorphic to [a].) Some of the tests (<<=) is expected to pass are
shown, and make clear what ought to happen.
> -- | Implement the @Extend@ instance for @List@.
> --
> -- >>> length <<= ('a' :. 'b' :. 'c' :. Nil)
> -- [3,2,1]
> --
> -- >>> id <<= (1 :. 2 :. 3 :. 4 :. Nil)
> -- [[1,2,3,4],[2,3,4],[3,4],[4]]
> --
> -- >>> reverse <<= ((1 :. 2 :. 3 :. Nil) :. (4 :. 5 :. 6 :. Nil) :. Nil)
> -- [[[4,5,6],[1,2,3]],[[4,5,6]]]
The following (wrong, according to the tests) Extend instance for List
nevertheless obeys the types and obeys the Extend law of associativity.
> instance Extend List where
> (<<=) ::
> (List a -> b)
> -> List a
> -> List b
> (<<=) f = (:. Nil) . f
(:. Nil) is analogous to (: []), create a singleton list.
I can't find a good reference on the Extend type class to convince me
why the correct Extend instance for List in the course is the desirable
one. (I'm not saying my version is desirable, in fact it seems fairly
useless, but it works.)
Graham
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.haskell.org/pipermail/beginners/attachments/20151213/85064018/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 14 Dec 2015 12:53:24 +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 14, 2015 6:57:27 AM GMT+02:00, Graham Gill <[email protected]>
wrote:
>The NICTA course <https://github.com/NICTA/course> includes exercises
>on
>the type class Extend, in Course/Extend.hs. Extend is a superclass of
>Comonad. Here's the class definition:
>> -- | All instances of the `Extend` type-class must satisfy one law.
>> This law
>> -- is not checked by the compiler. This law is given as:
>> --
>> -- * The law of associativity
>> -- `?f g. (f <<=) . (g <<=) ? (<<=) (f . (g <<=))`
>> class Functor f => Extend f where
>> -- Pronounced, extend.
>> (<<=) ::
>> (f a -> b)
>> -> f a
>> -> f b
>>
>> infixr 1 <<=
>
>Could someone please motivate the Extend instance for List? (Its
>implementation is left as an exercise. In the course, type List a is
>isomorphic to [a].) Some of the tests (<<=) is expected to pass are
>shown, and make clear what ought to happen.
>> -- | Implement the @Extend@ instance for @List@.
>> --
>> -- >>> length <<= ('a' :. 'b' :. 'c' :. Nil)
>> -- [3,2,1]
>> --
>> -- >>> id <<= (1 :. 2 :. 3 :. 4 :. Nil)
>> -- [[1,2,3,4],[2,3,4],[3,4],[4]]
>> --
>> -- >>> reverse <<= ((1 :. 2 :. 3 :. Nil) :. (4 :. 5 :. 6 :. Nil) :.
>Nil)
>> -- [[[4,5,6],[1,2,3]],[[4,5,6]]]
>
>The following (wrong, according to the tests) Extend instance for List
>nevertheless obeys the types and obeys the Extend law of associativity.
>> instance Extend List where
>> (<<=) ::
>> (List a -> b)
>> -> List a
>> -> List b
>> (<<=) f = (:. Nil) . f
>(:. Nil) is analogous to (: []), create a singleton list.
>
>I can't find a good reference on the Extend type class to convince me
>why the correct Extend instance for List in the course is the desirable
>
>one. (I'm not saying my version is desirable, in fact it seems fairly
>useless, but it works.)
>
>Graham
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Beginners mailing list
>[email protected]
>http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
Indeed, your implementation is a valid Extend instance. However, it cannot be
extended into a valid Comonad, whereas the supplied instance can.
Can you see why?
Hint: In order to be a Comonad, an Extend instance must also supply a function
extract:: f a -> a which must be an identity for extend. Is this possible for
your instance?
The intuition behind Extend is that given a computation that takes into account
the context of the values in your container, it applies that computation
everywhere, passing it the appropriate context. Thus, elements of List may be
considered as having the remainder of the list as their context, and that is
indeed what is passed to the computation, as evidence by extend id.
Indeed, this function is so essential to the essence of a Comonad that it is
given its own name - duplicate - and forms the building block for an equivalent
set of laws for Comonad, namely:
- duplicate . duplicate = fmap duplicate . duplicate
- extract . duplicate = id = fmap extract . duplicate
(If you've heard of join in the context of Monad, this is precisely the dual
set of laws it satisfies)
Indeed, it may be easier to prove your Extend instance doesn't extend to a
Comonad instance by using this formulation of the laws.
HTH,
Gesh
------------------------------
Subject: Digest Footer
_______________________________________________
Beginners mailing list
[email protected]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
------------------------------
End of Beginners Digest, Vol 90, Issue 26
*****************************************
