From: Jason Smith <jns28@student.canterbury.ac.nz>
To: Jason Smith <jns28@student.canterbury.ac.nz>,
skaller@users.sourceforge.net
Cc: caml-list <caml-list@pauillac.inria.fr>,
Richard Jones <rich@annexia.org>
Subject: RE: [Caml-list] laziness
Date: Tue, 07 Sep 2004 00:17:58 +1200 [thread overview]
Message-ID: <413AB81F@webmail> (raw)
>===== Original Message From skaller@users.sourceforge.net =====
>On Mon, 2004-09-06 at 19:07, Jason Smith wrote:
>
>> The compiler should optimize it out. There shouldn't be any need for using
>> explicit print statements.
>
>Yes but the original issue is that the programmer
>is seeing an expression they expect to be evaluated
>and it isn't being evaluated -- so there is a bug
>somewhere.
I'm not sure i follow you here. How can you *not* use something? if you want
to use an expression you "use" it, I'm sorry, I'm missing something obviously.
>So your point is kind of backwards --
>the compiler may well optimise it away, but the programmer
>is actually looking for evidence that it *isn't*
>optimised away.
Um, ok so ur depositing debug statements in code to check if the expression is
still there. I still fail to see why u can't just *look* at your code and see
if ur using the value or not. Can I get an example?
>In an eager language, no conclusions can be drawn
>from a debugging output - you still don't know
>if the returned value is used or not.
True, well almost true. The compiler can determine even in a strict language
if the value is used or not, using strictness analysis. So you could put
debugging statements in an expression and expect to see them and then volla,
do not. For example,
val f x y => x + 2;
> f 2 (some computation that yields a number)
4
the long compuation was never actually used within 'f' so we don't have to
evaluate it eagerly in haskell. Unforunately as I have already pointed out in
a previous post in O'Caml it'd be harder to make this decision, but not
impossible.
>In a lazy language, debugging output indicates
>the code *is* being used and hence not dead,
Yup.
>and lack of output means it isn't, at least
>in one particular environment.
Yup.
>You might investigate further and discover the result
>is only used in an unreachable branch of a match,
>so the code really is dead: that function argument
>will never be used (so you can remove it,
>and also the unreachable branch).
Ah nope, if its 'unreachable' then the original expression will never be
evaluated, and you won't get the debug statements, and more so GHC won't
compile it to start with. As soon as you use the expression, u reduce it. The
*result* of evaluating the scrutinee expresion for a case (aka conditional
expression) must be used because it determines the branch of the conditional
to take. Weather that branch actually uses the result is irrelevant at that
point.
Cheers,
Jason.
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
next reply other threads:[~2004-09-06 12:18 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-06 12:17 Jason Smith [this message]
2004-09-06 17:00 ` skaller
-- strict thread matches above, loose matches on Subject: below --
2004-09-06 9:16 Jason Smith
2004-09-06 9:07 Jason Smith
2004-09-06 10:18 ` skaller
2004-09-05 1:07 Jason Smith
2004-09-05 5:46 ` skaller
2004-09-06 0:57 ` Richard Jones
2004-09-06 6:11 ` Nicolas Cannasse
2004-09-06 8:24 ` skaller
2004-09-06 8:44 ` Erik de Castro Lopo
2004-09-06 12:55 ` Jon Harrop
2004-09-06 16:21 ` William Lovas
2004-09-06 22:35 ` Hartmann Schaffer
2004-09-07 8:31 ` Richard Jones
2004-09-07 8:37 ` Nicolas Cannasse
2004-09-04 6:30 skaller
2004-09-04 8:40 ` Marcin 'Qrczak' Kowalczyk
2004-09-04 11:21 ` skaller
2004-09-04 11:49 ` Richard Jones
2004-09-04 20:40 ` Hartmann Schaffer
2004-09-05 10:50 ` Jon Harrop
2004-09-05 14:07 ` skaller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=413AB81F@webmail \
--to=jns28@student.canterbury.ac.nz \
--cc=caml-list@pauillac.inria.fr \
--cc=rich@annexia.org \
--cc=skaller@users.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox