{"action":"created","issue":{"url":"https://api.github.com/repos/SWI-Prolog/swipl-devel/issues/163","repository_url":"https://api.github.com/repos/SWI-Prolog/swipl-devel","labels_url":"https://api.github.com/repos/SWI-Prolog/swipl-devel/issues/163/labels{/name}","comments_url":"https://api.github.com/repos/SWI-Prolog/swipl-devel/issues/163/comments","events_url":"https://api.github.com/repos/SWI-Prolog/swipl-devel/issues/163/events","html_url":"https://github.com/SWI-Prolog/swipl-devel/issues/163","id":174574707,"number":163,"title":"Rollback retract/1 change, possibly too risky.","user":{"login":"jburse","id":5411487,"avatar_url":"https://avatars.githubusercontent.com/u/5411487?v=3","gravatar_id":"","url":"https://api.github.com/users/jburse","html_url":"https://github.com/jburse","followers_url":"https://api.github.com/users/jburse/followers","following_url":"https://api.github.com/users/jburse/following{/other_user}","gists_url":"https://api.github.com/users/jburse/gists{/gist_id}","starred_url":"https://api.github.com/users/jburse/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jburse/subscriptions","organizations_url":"https://api.github.com/users/jburse/orgs","repos_url":"https://api.github.com/users/jburse/repos","events_url":"https://api.github.com/users/jburse/events{/privacy}","received_events_url":"https://api.github.com/users/jburse/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":1,"created_at":"2016-09-01T16:58:19Z","updated_at":"2016-09-02T07:01:23Z","closed_at":null,"body":"The current atomicity of erase/1 seems to be sufficient, to bootstrap\r\nalternative realization of retract/1 such as:\r\n\r\n```\r\nretract_alt(V) :- var(V),\r\n   throw(error(instantiation_error,_)).\r\nretract_alt((H :- B)) :- !,\r\n   clause(H, B, R), erase(R).\r\nretract_alt(H) :-\r\n   clause(H, true, R), erase(R).\r\n``` \r\n\r\nBut it seems a little bit to risky to override the retract/1 semantics,\r\nafter changing the erase/1 semantic. Reason: Too many Prolog systems\r\nimplement the old semantic, see below.\r\n\r\nBut the new erase/1 semantic and the old retract/1 semantic could\r\nco-exist. The old semantic retract/1 can even be bootstrapped from \r\nthe new erase/1 as follows:\r\n\r\n```\r\nretract(V) :- var(V),\r\n   throw(error(instantiation_error,_)).\r\nretract((H :- B)) :- !,\r\n   clause(H, B, R), ignore(erase(R)).\r\nretract(H) :-\r\n   clause(H, true, R), ignore(erase(R)). \r\n```\r\n\r\nBye\r\n\r\nP.S.: Here are the test results for many Prolog systems:\r\n\r\nISO core standard page 81, examples 8.9.3.4:\r\n\r\n```\r\n   :- dynamic insect/1.\r\n   insect(ant).\r\n   insect(bee). \r\n```\r\n\r\n3) GNU Prolog 1.4.4 (64 bits)\r\n   Compiled Apr 23 2013, 16:05:07 with cl\r\n\r\n```\r\n   ?- retract(insect(I)), write(I), nl,\r\n   retract(insect(bee)), fail; true.\r\n   ant\r\n   bee\r\n\r\n   yes\r\n```\r\n\r\n4) ECLiPSe Constraint Logic Programming System [kernel]\r\n   Version 6.1 #222 (x86_64_nt), Thu Jul  7 16:02 2016\r\n\r\n```\r\n   [eclipse 3]: retract(insect(I)), write(I), nl,\r\n   retract(insect(bee)), fail; true.\r\n   ant\r\n   bee\r\n\r\n   I = I\r\n   Yes (0.00s cpu)\r\n```\r\n\r\n5) Ciao 1.15-1781-g328b907: Wed Jun 19 00:06:05 PST 2013\r\n\r\n```\r\n   ?- retract(insect(I)), write(I), nl,\r\n   retract(insect(bee)), fail; true.\r\n   ant\r\n   bee\r\n\r\n   yes\r\n```\r\n\r\n6) B-Prolog Version 8.1, All rights reserved,\r\n   (C) Afany Software 1994-2014.\r\n\r\n```\r\n   ?- retract(insect(I)), write(I), nl,\r\n      retract(insect(bee)), fail; true.\r\n   ant\r\n   bee\r\n\r\n   yes\r\n```\r\n"},"comment":{"url":"https://api.github.com/repos/SWI-Prolog/swipl-devel/issues/comments/244298905","html_url":"https://github.com/SWI-Prolog/swipl-devel/issues/163#issuecomment-244298905","issue_url":"https://api.github.com/repos/SWI-Prolog/swipl-devel/issues/163","id":244298905,"user":{"login":"JanWielemaker","id":3071146,"avatar_url":"https://avatars.githubusercontent.com/u/3071146?v=3","gravatar_id":"","url":"https://api.github.com/users/JanWielemaker","html_url":"https://github.com/JanWielemaker","followers_url":"https://api.github.com/users/JanWielemaker/followers","following_url":"https://api.github.com/users/JanWielemaker/following{/other_user}","gists_url":"https://api.github.com/users/JanWielemaker/gists{/gist_id}","starred_url":"https://api.github.com/users/JanWielemaker/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/JanWielemaker/subscriptions","organizations_url":"https://api.github.com/users/JanWielemaker/orgs","repos_url":"https://api.github.com/users/JanWielemaker/repos","events_url":"https://api.github.com/users/JanWielemaker/events{/privacy}","received_events_url":"https://api.github.com/users/JanWielemaker/received_events","type":"User","site_admin":false},"created_at":"2016-09-02T07:01:23Z","updated_at":"2016-09-02T07:01:23Z","body":"I has some doubts about this.   It won't hurt many applications and I guess it is a borderline case wrt the logical update view.   Single threaded behaviour should remain compatible though.  There might be a way out for multi-threaded.\r\n\r\nIf threads do not retract using backtracking, but using once(retract(...)), we still have a race because the generation is established as the retract/1 call starts.    Possibly we can modify that such that threads competing on a retract make sure that one picks the generation when the clause still existed and the other the one after.\r\n\r\nNot sure how easy/hard that is to implement.   It would be logically sound as both threads will do classical logical update view, only one is delayed a little at the start of the retract.   If it is easy to implement it might be worthwhile.  Otherwise my conclusion is that predicates are not designed for thread communication anyway and I opt for documenting the issue."}}
{"actor":{"display_login":"JanWielemaker"}}