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: explaining effects (Imants Cekusins)
2. find an element in a list (Fabien R)
3. Re: find an element in a list (Max Voit)
4. Re: find an element in a list (David McBride)
5. Re: find an element in a list (Fabien R)
6. Re: How to show a predicate (martin)
7. Re: explaining effects (Rein Henrichs)
----------------------------------------------------------------------
Message: 1
Date: Sat, 26 Dec 2015 13:09:13 +0100
From: Imants Cekusins <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] explaining effects
Message-ID:
<cap1qinahkxdn2b90pwf+s3kjwzlhckaaljqqjrt-8vu4xic...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
for some practical purposes, would it make sense to forget about
effects and purity and distinguish only between IO and non-IO? It
should be easy enough to tell IO from non-IO, no?
also, could we say that a function that returns a value of such a type
of which no part is a function (for lack of a better definition) is
definitely a pure function
?
------------------------------
Message: 2
Date: Sat, 26 Dec 2015 15:19:17 +0100
From: Fabien R <[email protected]>
To: Haskell Beginners <[email protected]>
Subject: [Haskell-beginners] find an element in a list
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
As a newbie, I'm studying the pdf 'the Haskell road to logic, math and
programming' and I'm stuck with one exercise.
I want to extract x if x is at the beginning of a list.
I thought to use something like this:
extractIfBegins x [xs] | [xs] == (x:ys) = [ys] |
otherwise = [xs]
But ghci complains that ys is not defined.
Without giving the answer, can someone give a hint about the approach to
follow ?
--
Fabien
------------------------------
Message: 3
Date: Sat, 26 Dec 2015 15:46:19 +0100
From: Max Voit <[email protected]>
To: [email protected]
Subject: Re: [Haskell-beginners] find an element in a list
Message-ID: <[email protected]>
Content-Type: text/plain; charset=US-ASCII
Hi Fabien,
On Sat, 26 Dec 2015 15:19:17 +0100
Fabien R <[email protected]> wrote:
> extractIfBegins x [xs] | [xs] == (x:ys) = [ys]
> | otherwise = [xs]
>
> But ghci complains that ys is not defined.
That is because you cannot pattern match whilst equality testing. The
statement
xs == (x:ys)
is problematic therefore. You expect the compiler to see "oh, I don't
know ys, but xs is a list, so I'm just checking x and put the rest into
ys while I'm at it".
> Without giving the answer, can someone give a hint about the approach
> to follow ?
Try pattern matching on the list xs instead. Also take care that it's
xs, not [xs] (the latter notation implies a list with one element xs).
Best,
Max
------------------------------
Message: 4
Date: Sat, 26 Dec 2015 09:59:26 -0500
From: David McBride <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] find an element in a list
Message-ID:
<CAN+Tr42A6+Jh=1oky3P6n=nkJaw-YVJhsM+O_Ebq011Mn_=o...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
It sounds like you want to include x only if it is not already at the head
of the list. Try this:
extractIfBegins x (y:ys)
| x == y = ys
| otherwise = x:ys
On Sat, Dec 26, 2015 at 9:19 AM, Fabien R <[email protected]> wrote:
> As a newbie, I'm studying the pdf 'the Haskell road to logic, math and
> programming' and I'm stuck with one exercise.
> I want to extract x if x is at the beginning of a list.
> I thought to use something like this:
> extractIfBegins x [xs] | [xs] == (x:ys) = [ys] |
> otherwise = [xs]
>
> But ghci complains that ys is not defined.
> Without giving the answer, can someone give a hint about the approach to
> follow ?
>
> --
> Fabien
> _______________________________________________
> 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/20151226/33ec6a4d/attachment-0001.html>
------------------------------
Message: 5
Date: Sat, 26 Dec 2015 16:39:25 +0100
From: Fabien R <[email protected]>
To: [email protected]
Subject: Re: [Haskell-beginners] find an element in a list
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 26/12/15 15:46, Max Voit wrote:
> That is because you cannot pattern match whilst equality testing. The
> statement
> xs == (x:ys)
> is problematic therefore. You expect the compiler to see "oh, I don't
> know ys, but xs is a list, so I'm just checking x and put the rest into
> ys while I'm at it".
Thanks Max,
It's more clear now.
--
Fabien
------------------------------
Message: 6
Date: Sat, 26 Dec 2015 18:44:40 +0100
From: martin <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] How to show a predicate
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Am 12/25/2015 um 03:11 PM schrieb Lyndon Maydwell:
> Depending on how you construct your predicates, you may be able to capture
> their composition... And then serialise that.
>
> For example:
>
> If you were doing some sort of range intersection predicate construction ~
>
> R1 n R2 n R3
>
> Could be represented as a list of those ranges [(l1,r1),(l2,r2),(l3,r3)].
> Basically, instead of constructing a predicate
> function directly, you would assemble a data-structure representing the
> essence of the predicate, then convert that to
> both a function for evaluation, as well as a string for serialisation. This
> would also allow you to perform some
> "optimisation" before serialisation which could be fun.
Thanks, I understand I need a representation and a Set would be just one of the
possiblilities.
------------------------------
Message: 7
Date: Sat, 26 Dec 2015 18:53:20 +0000
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] explaining effects
Message-ID:
<cajp6g8zb8tcy4hyexdnkvjjfssyp4j1-ydez7pi1s9j+wef...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
TL;DR: Evaluation is always pure[1]. Execution isn't, but it wasn't
supposed to be in the first place.
> would it make sense to forget about effects and purity and distinguish
only between IO and non-IO? It should be easy enough to tell IO from
non-IO, no?
There is no need to distinguish between IO and non-IO. Everything is pure,
including IO.
When people talk about effects, they tend to mean something encapsulated
and "hidden" by the implementation of bind and return for a particular
Monad instance; the meaning of "effect" is entirely dependent on this
context. For example, State encapsulates the effect of passing an
accumulating parameter to multiple functions and properly threading the
results. Reader encapsulates additional function parameters that are never
varied. Writer encapsulates writing to a "log" (any monoidal accumulator).
The list monad encapsulates the effect of non-determinism (functions that
can return more than one result), allowing you to work with placeholder
variables that represent all possible results at that stage of the
computation. ST encapsulates mutation in way that is *externally
unobservable*. And so on. None of these "effects" are impure. They are all
referentially transparent. They do not mutate any external or global state.
They can all be rewritten by inlining the relevant definitions of bind and
return in a way that will make it obvious that no "funny stuff" is
happening.
One important difference between this sort of encapsulation and the kind
that you might find in an OOP language is that this encapsulation is
*perfect*. These abstractions *do not leak*. There is no way for your
program to externally observe any mutation during evaluation of a State
action and the same holds, mutatis mutandis, for all the other monad
instances.
IO is a common source of confusion, but the important distinction here is
the one that Chris already made: *evaluation* of IO actions is pure,
referentially transparent, and causes no effects (side- or otherwise).
Execution of the `main` IO action by the runtime?and by extension the
execution of those other IO actions that may compose it?is obviously not
pure, but no one is expecting *execution* to be pure: if execution were
required to be pure then the program couldn't be run at all, because any
attempt to run it would cause some sort of externally observable effect
(even if it merely heats up the surrounding space a bit).
A commonly used metaphor that may help to understand this is to consider an
IO action to be like a recipe like one might find in a cookbook. If
`getLine` is the recipe for a particular type of cake then it will be the
same recipe every time it is invoked. The actual cake that you produce when
you execute the recipe may differ?more or less, depending on how proficient
you are at baking?but this does not mean that the recipe itself has changed
each time. And so it is with IO: The actions are pure. They are the same
every time. The results that they produce when executed may change, but
this is not at odds with our claim that the values themselves are pure.
> also, could we say that a function that returns a value of such a type of
which no part is a function (for lack of a better definition) is definitely
a pure function
Yes, and all the other functions are pure too.
[1] Modulo usages of `unsafePerformIO` and friends, but these can and
should be dealt with separately.
On Sat, Dec 26, 2015 at 4:09 AM Imants Cekusins <[email protected]> wrote:
> for some practical purposes, would it make sense to forget about
> effects and purity and distinguish only between IO and non-IO? It
> should be easy enough to tell IO from non-IO, no?
>
> also, could we say that a function that returns a value of such a type
> of which no part is a function (for lack of a better definition) is
> definitely a pure function
>
> ?
> _______________________________________________
> 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/20151226/5f188506/attachment.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 44
*****************************************
