caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: skaller <skaller@users.sourceforge.net>
To: "Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl>
Cc: caml-list <caml-list@inria.fr>
Subject: Re: [Caml-list] paralell assignment problem
Date: 09 Feb 2005 04:55:06 +1100	[thread overview]
Message-ID: <1107885305.5022.211.camel@pelican.wigram> (raw)
In-Reply-To: <87r7jrrp56.fsf@qrnik.zagroda>

On Wed, 2005-02-09 at 03:29, Marcin 'Qrczak' Kowalczyk wrote:
> skaller <skaller@users.sourceforge.net> writes:
> 
> > x1,x2,x3..xn = e1,e2,e3 .. en
> >
> > where ei might contain the variables xj. (Note = here is assignment).
> 
> If they contain calls to unknown functions, they might depend on these
> variables indirectly. 

This is true, and I need to ensure that this doesn't cause
a problem, which can be done, for example, by evaluating
the call to the unknown function first, and then using
that value. In this case, you'd be quite right that subsequent
optimisation would probably be worthless (calling a function
through a variable in Felix is quite expensive)

> So I'm not convinced that it's worth to eliminate
> temporaries in those rare cases when it's possible. After all, people
> rarely assign the value of a variable to another variable.

That may be so, however many function calls are direct,
that is, to known functions. In particular tail rec
calls typically involve passing 'old value - 1' or something
similar where no temporary is required. The actual example
which prompted this investigation is ackermann, which has two
tail-rec calls:

fun ack(x:int,y:int):int =>
  if x == 0 then y + 1
  elif y == 0 then ack(x-1, 1)
  else ack(x-1, ack(x, y-1))
  endif
;

No temporaries are needed in either tail call,
and either order of assignment will work.
But my actual code created 2 temporaries for each
tail call, unnecessarily.

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




  reply	other threads:[~2005-02-08 17:55 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-08  3:07 skaller
2005-02-08 14:34 ` Stefan Monnier
2005-02-08 16:02   ` [Caml-list] " skaller
2005-02-08 18:20     ` Stefan Monnier
2005-02-08 17:08   ` skaller
2005-02-08 18:33     ` Radu Grigore
2005-02-09  7:48       ` Radu Grigore
2005-02-09 10:11         ` skaller
2005-02-09  9:43       ` Radu Grigore
2005-02-09 11:19         ` Radu Grigore
2005-02-09 11:34         ` Pascal Zimmer
2005-02-09 13:53           ` skaller
2005-02-08 16:03 ` [Caml-list] " Florian Hars
2005-02-08 17:38   ` skaller
2005-02-08 16:29 ` Marcin 'Qrczak' Kowalczyk
2005-02-08 17:55   ` skaller [this message]
2005-02-08 18:32     ` Marcin 'Qrczak' Kowalczyk

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=1107885305.5022.211.camel@pelican.wigram \
    --to=skaller@users.sourceforge.net \
    --cc=caml-list@inria.fr \
    --cc=qrczak@knm.org.pl \
    /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).