Non-escaping lets, join-points and binding updatability

Jan Stolarek jan.stolarek at p.lodz.pl
Thu Oct 17 09:55:01 UTC 2013


Thank you both.

> Does that resolve the question?
Yes.

I'll update the comments so it is more obvious what is going on.

Janek

Dnia czwartek, 17 października 2013, Simon Peyton-Jones napisał:
> Yes, a join point should always have at least one argument, although it can
> be a zero-width argument that takes no registers to pass.  (That's the
> State# RealWorld thing Simon mentions.)
>
> See Note [Join point abstraction] in Simplify.lhs.
>
> At one point the demand analyser was noticing that the argument was unused,
> and removing it, but I believe I fixed that.
>
> Does that resolve the question? Are any comments in the code inconsistent?
>
> Please clarify with Note [blah], and/or cross-reference to other Notes.
>
> Simon
>
> | -----Original Message-----
> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Simon
> | Marlow
> | Sent: 17 October 2013 09:44
> | To: Jan Stolarek; ghc-devs at haskell.org
> | Subject: Re: Non-escaping lets, join-points and binding updatability
> |
> | On 16/10/2013 18:27, Jan Stolarek wrote:
> | > Hi all,
> | >
> | > I'm trying to understand this:
> | >
> | > 1. Note [What is a non-escaping let] says that one of conditions of
> |
> | binding being a non-escaping
> |
> | > let is non-updatability.
> | > 2. My understanding is that a if a binding has at least one parameter
> |
> | it is non-updatable, though
> |
> | > I suspect that converse does not have to be true (lambdas)
> | > 3. Join-points are implemented using LNE bindings and I can imagine a
> |
> | join-points not having any
> |
> | > parameters (and not being a lambda).
> |
> | A join-point always has at least one argument.  If there are no
> | arguments, then a dummy one of type State# RealWorld is added, to avoid
> | creating a thunk.
> |
> | Cheers,
> | Simon
> | _______________________________________________
> | ghc-devs mailing list
> | ghc-devs at haskell.org
> | http://www.haskell.org/mailman/listinfo/ghc-devs




More information about the ghc-devs mailing list