Dear Wren, Am Mittwoch, den 21.12.2011, 13:04 -0500 schrieb wren ng thornton:
On 12/21/11 4:31 AM, Joachim Breitner wrote:
This would be particularly handy when with, for example snd tuple `evaluateUntilItDoesNotNeed` tuple where the tuple is unevaluated in the right component (and where we don’t want to force this just now), but retains something large in the left component (that we want to become GCable).
Can't you already do that with:
let (_,x) = tuple in ...x...
or
case tuple of (_,x) -> ...x...
?
The tuple will be evaluated far enough that we can access its second component, and then we're free to discard the tuple itself provided it's not referenced elsewhere. The above would only be strict in x if the use sites are strict.
Or do you mean that you want something with the semantics of the above, but with a syntactic form that enables us to abstract out the ellipses?
Your first example would not work, because the tuple is only evaluated when x is evaluated, which might be later than the point where I want the left component of the tuple to be GCed: Prelude Debug.Trace> let (_,x) = trace "some tuple" (error "a", error "b") in const () x () The second case works in this particular instance: Prelude Debug.Trace> case trace "some tuple" (error "a", error "b") of (_,x) -> const () x some tuple () But assume the function is not snd but rather a library provided function that you have no control over and that you know returns one component of the tuple, but you don’t know which (depending on other parameters, perhaps). The advantage of a `evaluateUntilItDoesNotNeed` would be that it can be combined with code that was written without having such considerations in mind. Greetings, Joachim -- Joachim "nomeata" Breitner mail@joachim-breitner.de | nomeata@debian.org | GPG: 0x4743206C xmpp: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/