|sequential binary parallelization at run-time email@example.com (Lauren) (2007-10-25)|
|Re: sequential binary parallelization at run-time firstname.lastname@example.org (George Neuner) (2007-10-27)|
|Unpopular parameter passing mechanisms and parallelisation (was Re: se email@example.com (Anton Lokhmotov) (2007-10-28)|
|Re: Unpopular parameter passing mechanisms and parallelisation firstname.lastname@example.org (2007-10-29)|
|Re: Unpopular parameter passing mechanisms and parallelisation email@example.com (2007-10-29)|
|Re: Unpopular parameter passing mechanisms and parallelisation firstname.lastname@example.org (Anton Lokhmotov) (2007-10-31)|
|Re: Unpopular parameter passing mechanisms and parallelisation email@example.com (Lauren) (2007-11-01)|
|Re: Unpopular parameter passing mechanisms and parallelisation firstname.lastname@example.org (George Neuner) (2007-11-01)|
|From:||email@example.com (Torben =?iso-8859-1?Q?=C6gidius?= Mogensen)|
|Date:||Mon, 29 Oct 2007 09:40:08 +0100|
|Organization:||Department of Computer Science, University of Copenhagen|
|References:||07-10-082 07-10-089 07-10-091|
|Posted-Date:||29 Oct 2007 13:15:34 EDT|
Anton Lokhmotov <firstname.lastname@example.org> writes:
> It's interesting you mention that call-by-need (CBN) parameter passing
> semantics is not particularly popular today.
It is relatively common in functional languages, such as Haskell.
> I'm not an expert in CBN but my impression that it only makes sense
> in functional languages (or languages allowing to specify that a
> function is pure, i.e. does not have side-effects),
Call-by-need can be used for non-pure languages, but in this case, you
can not optimize call-by-need to call-by-value for strict functions,
as you can in functional languages, as changing the time at which an
expression is evaluated becomes significant. But if you have non-pure
behaviour, call-by-need requires careful programming to avoid
unexpected behaviour, same as call-by-name (as was used in Algol 60).
> and we know that functional programs are well-suited for
Certainly better than OO or imperative, I agree.
> As for imperative programming, another undeservedly abandoned
> parameter passing semantics is call-by-value-result (CBVR). In CBVR,
> writes to the caller's memory by the callee do not happen until the
> callee returns but the callee keeps track of them.
I think all the advantages of CBVR are subsumed by the ability of
functions to return multiple values (in a tuple). You get the same
effect of passing values only at call and return, but you don't have
to return in the same variables as you used to pass parameters.
Return to the
Search the comp.compilers archives again.