Re: Ann: SWI-Prolog 7.1.13

Jan Wielemaker <[email protected]> Mon, 21 Apr 2014 17:34:49 +0200
Newsgroups gmane.comp.ai.prolog.swi
Message-ID <[email protected]>
On 04/19/2014 09:19 AM, rlaanemets wrote:
> Does the sematic issue come from the need to support nondet mode when the Key
> is unbound? As this has the usual (for anything that involves exceptions?)
> order-dependent semantics:
> 
> ?- D = _{ a: 1 }, X = b, get_dict_ex(X, D, 1).
> ERROR: get_dict_ex/3: key `b' does not exist in _G2711{a:1}
> 
> ?- D = _{ a: 1 }, get_dict_ex(X, D, 1), X = b.
> false

Not really, although get_dict/3 is in that sense logically correct.

> Anyway, I have never used get_dict_ex/3 with an unbound Key, never even
> thought about that :)
> 
> Now the question is: will the dot (.) operator keep throwing exception on
> the missing key or is that going to be changed? The documentation for
> http://swi-prolog.org/pldoc/doc_for?object=get_dict/3 says:
> 
> "This predicate is normally accessed using the functional notation Dict.Key"
> 
> which hints that it might not.

I think that get_dict/3 and the functional notation if the left-hand is a
dict should be considered stable.  get_dict_ex/3 was merely a somewhat
strange
predicate that helped implementing ./3.  I think I should never have
added that
to the public interface.  Dict.key raises an existence error.   I think
that fits
best with the intended usage.  Still, I experience that it is not
uncommon to
expect a key not to be there.  In that case you can use Dict.get(key) or
get_dict/3.

> By the way, the comment on top of '.'/3 still looks wrong:
> http://www.swi-prolog.org/git/pl-devel.git/blob/dec32b691ac0ca322456a4734f7c01d908ce2d32:/boot/dicts.pl
> 
> "fails if the first argument is not a dict or the second is not a valid key
> or unbound"

This is exactly what it does.  It it designed such that the `else' branch
of this gets all cases where Data is not a dict or Func is not a key or
variable.

.(Data, Func, Value) :-
	(   '$get_dict_ex'(Func, Data, V0)
	*-> Value = V0

I.e., it semantics is now weird, throwing an exception only if Data is a
dict and
Func is a key, but not a key in Dict.  This semantics however avoids
some tests
in the ./3 implementation, giving about 40% speedup on the most common case.

	Cheers --- Jan