Re: Ann: SWI-Prolog 7.1.0

On 12/10/2013 07:43 PM, Nicos Angelopoulos wrote:
>
> Dear Jan, list,
>
> On Sat, 7 Dec 2013 15:54:05 +0100
> Jan Wielemaker <[email protected]> wrote:
>
>> On 12/07/2013 02:48 PM, Michael Hendricks wrote:
>>> Is there an efficient term_tag(+Term, -Tag:atom) predicate so we can
>>> manually perform this optimization when wanted?
>>>
>>> do(X) :-
>>>      term_tag(X, Tag),
>>>      do_(Tag, X).
>>> do_(Tag, X) :-
>>>      ...
>>
>> Funny enough, this was also proposed by Nicos under the name
>> term_type/2.  It might make sense, especially of a variable
>> would leave the type unbound as well (just like term_hash/2).
>>
>> Opinions?
>>
>> 	Cheers --- Jan
>
>
> 	My point being  that now with the addition of strings we have a richer set,
>          and that this is information that is cheap for the system to provide.
> 	It will probably be hard to find a single definition to satisfy all.
> 	I suspect that it will be of limited usefulness, the application I have
> 	for them right now is in the context of a DSL.
>          But where useful, they can be very handy. Not only you get efficiency,
>          but it also encourages more readable code.
> 	My vote would be for the tightest type and a bound variable when arg(1) is variable.
> 	Leaving Tag above unbound is counter intuitive (for my use case).

I am unsure.  I haven't seen that many cases where switching on the 
native type is crucial performance-wise and as we have seen here,
the application types are often not a one-to-one mapping from the
system types.  It is easy enough to write a term_type/2 doing the
right thing for the real library.  If it proves to be too slow, we
can always consider adding leading type checks to the clause indexing,
such that you can write your (application specific) term_type/2 more
efficiently.

	Cheers --- Jan