Opened 8 years ago

Closed 8 years ago

Last modified 7 years ago

#1236 closed bug (invalid)

System.Mem.Weak breaks referential transparency

Reported by: drtomc@… Owned by:
Priority: normal Milestone:
Component: libraries/base Version: 6.6
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Test Case:
Blocked By: Blocking:
Related Tickets: Differential Revisions:

Description

Consider the following two functions:

foo = do

mkWeakPtr y (Just launchMissiles) return y where y = 42

bar = do

mkWeakPtr 42 (Just launchMissiles) return 42

These two functions are equivalent right? After all referential transparency means that if y = 42, then anywhere y occurrs I can write 42. The problem is that if I call foo, and hang on to the return value, then launchMissiles won't be called until some time after I stop using the return value, but if I call bar, then launchMissiles may be called any time, including before bar returns!

Looks to me like finalizers break referential transparency, so System.Mem.Weak is broken, though I'm quite willing to be proven wrong.

cheers, Tom

Change History (3)

comment:1 Changed 8 years ago by simonmar

  • Resolution set to invalid
  • Status changed from new to closed

mkWeakPtr does not break referential transparency. You cannot use it to write a function that returns a non-deterministic result.

Think of it as being similar to forkIO, in that it postpones an IO action until some time in the future. This is one of the reasons that mkWeakPtr must be in the IO monad, incedentally.

comment:2 Changed 7 years ago by simonmar

  • Architecture changed from Unknown to Unknown/Multiple

comment:3 Changed 7 years ago by simonmar

  • Operating System changed from Unknown to Unknown/Multiple
Note: See TracTickets for help on using tickets.