Syntax/semantics for partial dicts

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 …

[1] SWI-Prolog -- library(assoc): Association lists

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?

2 Likes

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 :slight_smile:

2 Likes