What I never understood is how this “implicit state” is any better than just an extra argument. It isn’t less typing or less reading. I guess my code is just too silly for those advanced techniques.
But it is also two mentions just not in the head. Anyway as I said obviously I just don’t get it.
I tried it and I realized it doesn’t give me anything. As I said it is two mentions of variables in square brackets in the body instead of arguments in the heads. It is just a different formalism?
I think a good example for the two states is the assoc predicate [1].
Example, the put_assoc requires a before and after state variable for the assoc:
put_assoc (+Key, +Assoc0, +Value, -Assoc)
So, if i want to fill an assoc with several initial states I will do something like this (the last one is a “nested” assoc stored at key_keyval).
get_initial_state(Assoc) :-
empty_assoc(Assoc_0),
put_assoc(key_item_count, Assoc_0, 0, Assoc_1),
put_assoc(key_visited, Assoc_1, [], Assoc_2),
put_assoc(key_search_depth, Assoc_2, 50, Assoc_3),
empty_assoc(A2),
put_assoc(key_keyval,Assoc_3, A2, Assoc).
I now wonder, how is this translated into DCG …
I guess one can wrap Assoc to make it into one …
put_assoc_update(Key, Value, Assoc0, Assoc) :-
put_assoc(Key, Assoc0, Value, Assoc).
So, here is the updated version:
@Boris , the version saves the need to pass the two last variables across each update_assoc call – which is cumbersome – in particular, when you need to add new update_assoc clauses as you go – you don’t have to re-number them.
update_assoc(Key, X, S1, S2) :-
put_assoc(Key, S1, X, S2).
get_init(Assoc) :-
empty_assoc(Assoc_0),
phrase(mon_init, Assoc_0, Assoc).
mon_init -->
update_assoc(key_item_count, 0),
update_assoc(key_visited, []),
update_assoc(key_search_depth, 0).
But, i was not able to get this to work with your updater suggestion – set_assoc(item(X,Y)) wasn’t found during the call with a variant implementation-- not sure why …
I was wondering how far this style could be taken in my system and whether its worth it … given the simplicity of the prolog syntax.
I am even shying away from the new => construct and rather use the head :- guard, ! body pattern instead.
Although, i would have liked the steadifastness guarantees coming with the use of the => operator and the single sided unification.
Edit:
Although, i am still searching for a consistent approach to error handing – and the monadic approach could provide a clearn approach – although performance wise – passing along an error during processing might not be ideal.
hey folks, getting a bit off-topic here. Can we restrict this to the partial dict rfc and move DCG discussion elsewhere, please?
I’ve been using GitHub - edechter/open_dicts: Open dicts for SWI Prolog for a while now, especially when working with deeply nested JSON (represented as dict) to extract values. A built-in syntax, especially one that could be used in clause heads would be very nice to have