caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: skaller <skaller@users.sourceforge.net>
To: Jason Smith <jns28@student.canterbury.ac.nz>
Cc: caml-list <caml-list@pauillac.inria.fr>
Subject: RE: [Caml-list] laziness
Date: 05 Sep 2004 15:46:58 +1000	[thread overview]
Message-ID: <1094363217.3352.501.camel@pelican.wigram> (raw)
In-Reply-To: <413879B6@webmail>

On Sun, 2004-09-05 at 11:07, Jason Smith wrote:

> >Must they be evaluated before the function is called?
> 
> If O'Caml follows the usual eager order semantics then evaluation is AOR or 
> Applicative order redection. (Which is what I use in Mondrian).
> 
> There are several locations where we may attempt to reduce this overhead.

Let me rephrase the question then. Suppose you wanted to
reduce the overhead "almost all the time". 
You can't do this if you specify the usual eager semantics.

So the question is: what changes to the semantic specification
would allow the optimisations?

For example: for 'simple' functions, it makes no difference
if evaluation is eager or lazy, so  the optimiser can choose
to evaluate lazily if it is possible the result will not
be used, or eagerly if it is used many times.

Many functions programmers write will have this property.

In a language where functions could have side effects,
clearly you'd have to either make some statement about
when and if the side effects occur, or simply
exclude such a function from the optimisation.

OTOH in Haskell I would guess there are only two properties
which would prevent an arbitrary evaluation time: if the
function could fail, or if it could fail to terminate.
So if the function is pure, total, and terminating,
there's no reason to specify when, if, or how many
times it is executed.

So you could, for example, simply allow the programmer
to state a function is 'nice' to allow the optimiser
maximum freedom (and on the programmers head it will
be if they lied :)

I'm not recommending this -- just giving an example
of one way one might try to get around what seems
to be a vast overconstraint for many functions
in languages that mandate some rigid mix of
eager/lazy semantics (and then try to optimise
the result preserving the semantics).

What would give the optimiser more freedom,
without sacrificing the *ability* to use eager
or lazy semantics when it is actually necessary
semantically?

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
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


  reply	other threads:[~2004-09-05  5:47 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-05  1:07 Jason Smith
2004-09-05  5:46 ` skaller [this message]
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
  -- strict thread matches above, loose matches on Subject: below --
2004-09-06 12:17 Jason Smith
2004-09-06 17:00 ` skaller
2004-09-06  9:16 Jason Smith
2004-09-06  9:07 Jason Smith
2004-09-06 10:18 ` skaller
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=1094363217.3352.501.camel@pelican.wigram \
    --to=skaller@users.sourceforge.net \
    --cc=caml-list@pauillac.inria.fr \
    --cc=jns28@student.canterbury.ac.nz \
    /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;
as well as URLs for NNTP newsgroup(s).