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: recursive and non recursive functions (Kim-Ee Yeoh)
2. Evaluation order semantics.. (Mike Meyer)
3. Re: Evaluation order semantics.. (Keshav Kini)
4. Re: Evaluation order semantics.. (???)
5. How to understand the type "ShowS"? (yi lu)
----------------------------------------------------------------------
Message: 1
Date: Mon, 23 Sep 2013 21:34:58 +0700
From: Kim-Ee Yeoh <k...@atamo.com>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <beginners@haskell.org>
Subject: Re: [Haskell-beginners] recursive and non recursive functions
Message-ID:
<capy+zdq7wrzgxhxwazgkh1bljfbnqo4mjnvqoucicyryy1w...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Thu, Sep 19, 2013 at 2:31 AM, Brent Yorgey <byor...@seas.upenn.edu>wrote:
> The distinction is simply this: given a definition
>
> foo = ...
>
> does foo show up in the ..., i.e. on the right-hand-side of its own
> definition, or not? If foo shows up in its own definition, it is
> recursive. If not, it is not recursive.
>
This isn't a satisfactory answer 'simply' (there's that word again!)
because it makes a hash out of equational reasoning:
fix f = f (fix f) -- recursive
fix2 = fix -- no longer recursive!
thereby making the very concept itself ontologically suspect. Which of
course, it shouldn't be.
The stackoverflow question asks about 'representation', which, for the
purpose of discussion, posits an actual graph-reduction machine.
The current answers give GHC Core in gory detail. If that works for you,
great!
Otherwise, I recommend the self-guided tutorial on graph reduction in PJ &
Lester:
http://research.microsoft.com/en-us/um/people/simonpj/papers/pj-lester-book/
-- Kim-Ee
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20130923/93208a5a/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 23 Sep 2013 13:34:38 -0500
From: Mike Meyer <m...@fpcomplete.com>
To: beginners@haskell.org
Subject: [Haskell-beginners] Evaluation order semantics..
Message-ID:
<CAD272pBi70shR1s9xVvF2Th4g8aZhie3bpm=tjdiywdwejk...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
??? wbbtiger at gmail.com wrote:
Since no one else answered this, I'll take a crack at it.
?> ?
The Haskell language specification states that it is a non-strict
? ?
?
language,
?> ?
but nothing about the evaluation strategy (like when and how an expression
?> ?
is evaluated, and to what level). It does mention the word "evaluate"
?> ?
several times when talking about pattern matching.
?>?
?> ?
I have read a wonderful tutorial (
?> ?
http://en.wikibooks.org/wiki/Haskell/Laziness
<http://en.wikibooks.org/wiki/Haskell/Laziness>) about lazy evaluation
and
?> ?
weak head normal form, but it is just an implemenation strategy of some
?> ?
compiler, which I should not depend on when writing codes.
?>?
?> ?
I come from a strict language background and I just don't feel right if I
?> ?
don't understand how my codes are execuated. I wonder why the language
?> ?
specificition does not define the evaluation strategy.
?>?
?> ?
I hope someone can enlighten me. Thanks!
?I think you have already achieved enlightenment - you just don't feel
right about it.?
?The language specification doesn't define the evaluation strategy because
it doesn't matter. At least, it doesn't matter in pure code. You'll get the
same answer no matter what order expressions are evaluated in, so long as
they are evaluated by the time they are needed. Not specifying evaluation
order gives the compiler freedom to arrange it to get the best possible
performance.
That said, there are cases where the evaluation order matters. Come to
think of it, most of them fall into two categories: the order matters for
performance reasons (clearly outside the purview of a specification), or
you want to insure that something is evaluated before it's actually used
(like doing IO), and there are tools in the language to force evaluation in
those cases.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20130923/8e6fa2c5/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 23 Sep 2013 17:29:48 -0500
From: Keshav Kini <keshav.k...@gmail.com>
To: beginners@haskell.org
Subject: Re: [Haskell-beginners] Evaluation order semantics..
Message-ID: <87siwvtbmr....@gmail.com>
Content-Type: text/plain; charset=utf-8
Mike Meyer <m...@fpcomplete.com> writes:
> ?The language specification doesn't define the evaluation strategy
> because it doesn't matter. At least, it doesn't matter in pure code.
> You'll get the same answer no matter what order expressions are
> evaluated in, so long as they are evaluated by the time they are
> needed.
Is non-termination included in "pure code"? If so, then different
evaluation strategies can indeed affect whether or not an expression can
be evaluated "by the time it is needed", or even at all.
let foo = foo in const () foo
... is an example of an expression that terminates with a sufficiently
lazy evaluation strategy but doesn't terminate given a sufficiently
eager evaluation strategy.
Or did I misunderstand what you meant?
-Keshav
------------------------------
Message: 4
Date: Tue, 24 Sep 2013 12:01:51 +0800
From: ??? <wbbti...@gmail.com>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <beginners@haskell.org>
Subject: Re: [Haskell-beginners] Evaluation order semantics..
Message-ID:
<CAE4nzfssF-R=7u5AjDLPQ96=b47357rpzk2fuzgjlstbtbx...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
2013/9/24 Mike Meyer <m...@fpcomplete.com>
> ??? wbbtiger at gmail.com wrote:
>
> Since no one else answered this, I'll take a crack at it.
>
>
> ?> ?
> The Haskell language specification states that it is a non-strict
> ? ?
>
> ?
> language,
> ?> ?
> but nothing about the evaluation strategy (like when and how an expression
> ?> ?
> is evaluated, and to what level). It does mention the word "evaluate"
> ?> ?
> several times when talking about pattern matching.
> ?>?
> ?> ?
> I have read a wonderful tutorial (
> ?> ?
> http://en.wikibooks.org/wiki/Haskell/Laziness
> <http://en.wikibooks.org/wiki/Haskell/Laziness>) about lazy evaluation and
> ?> ?
> weak head normal form, but it is just an implemenation strategy of some
> ?> ?
> compiler, which I should not depend on when writing codes.
> ?>?
> ?> ?
> I come from a strict language background and I just don't feel right if I
> ?> ?
> don't understand how my codes are execuated. I wonder why the language
> ?> ?
> specificition does not define the evaluation strategy.
> ?>?
> ?> ?
> I hope someone can enlighten me. Thanks!
>
> ?I think you have already achieved enlightenment - you just don't feel
> right about it.?
>
> ?The language specification doesn't define the evaluation strategy because
> it doesn't matter. At least, it doesn't matter in pure code. You'll get the
> same answer no matter what order expressions are evaluated in, so long as
> they are evaluated by the time they are needed. Not specifying evaluation
> order gives the compiler freedom to arrange it to get the best possible
> performance.
>
> That said, there are cases where the evaluation order matters. Come to
> think of it, most of them fall into two categories: the order matters for
> performance reasons (clearly outside the purview of a specification), or
> you want to insure that something is evaluated before it's actually used
> (like doing IO), and there are tools in the language to force evaluation in
> those cases.
>
>
Yes, if the spec does not state the evaluation order I can't predict the
performance definitely.
--
spockwang
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20130924/ba926cd6/attachment-0001.html>
------------------------------
Message: 5
Date: Tue, 24 Sep 2013 18:15:38 +0800
From: yi lu <zhiwudazhanjiang...@gmail.com>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <Beginners@haskell.org>
Subject: [Haskell-beginners] How to understand the type "ShowS"?
Message-ID:
<CAKcmqqxGjATa258KSv-Ze2fVt_P=_Ce5=5+xb+ns7qmxvuw...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Prelude> :i ShowS
type ShowS = String -> String -- Defined in `GHC.Show'
It is a type of a function? I cannot understand this type, and don't know
how to create functions of this type.
And this function "shows"
Prelude> :i shows
shows :: Show a => a -> ShowS -- Defined in `GHC.Show'
I don't know how this function works.
Yi
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20130924/8266243a/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
Beginners mailing list
Beginners@haskell.org
http://www.haskell.org/mailman/listinfo/beginners
------------------------------
End of Beginners Digest, Vol 63, Issue 35
*****************************************
