2024-07-16 00:18 AEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000223mercuryBugpublic2011-11-03 12:08
Assigned Towangp 
Product Version 
Target VersionFixed in Version 
Summary0000223: thread.mvar.init/0 and thread.semaphore.init/1 should be marked impure
Descriptionthread.mvar.init/0 and thread.semaphore.init/1 are obviously impure but are not marked as such, leading to logical inconsistencies such as this:

main(!IO) :-
    M1 = init, M2 = init,
    put(M1, 1, !IO), take(M2, _, !IO).

not being equivalent to this:

main(!IO) :-
    M1 = init, M2 = M1,
    put(M1, 1, !IO), take(M2, _, !IO).

(The former will block but the latter will not.)

They should be marked impure or removed from the library.
TagsNo tags attached.
Attached Files




wangp (developer)

That's true. They were added so that mvar and semaphore mutables could be initialised without the I/O state arguments. Before marking them impure, I would like to see either or both:

- mutables allowed to be initialised by impure functions
- mutables initialised by a predicate call with access to the I/O state


juliensf (administrator)

(1) mutables allowed to be initialised by impure functions

This would be fine, for consistency we should allow calls to semipure functions too.
(Once this is done mvar.init etc can just be made impure.)

(2) mutables initialised by a predicate call with access to the I/O state

This is a bit more tricky. The third argument of a mutable declaration is currently a value, not
a call. In order to have a predicate call in the third argument this will need to change and probably
in a way that will break quite a bit of code that already uses mutables.


wangp (developer)

Fix committed.

-Issue History
Date Modified Username Field Change
2011-10-24 08:02 colanderman New Issue
2011-10-24 09:37 wangp Note Added: 0000368
2011-10-24 16:10 juliensf Note Added: 0000371
2011-10-24 16:10 juliensf Status new => acknowledged
2011-11-03 12:08 wangp Note Added: 0000380
2011-11-03 12:08 wangp Status acknowledged => resolved
2011-11-03 12:08 wangp Resolution open => fixed
2011-11-03 12:08 wangp Assigned To => wangp
+Issue History