The wrong time to ask, or just the wrong time?

[jjtolton]

jay@Ultimus-MkIII ~/programs/scryer-prolog $ scryer-prolog -v
v0.9.4-179-g3fa6b69a
jay@Ultimus-MkIII ~/programs/scryer-prolog $ git rev-parse --abbrev-ref HEAD
heads/upstream/master
jay@Ultimus-MkIII ~/programs/scryer-prolog $ git rev-parse HEAD
3fa6b69a79eeba6d1b6eb0628d90de9d55231a97

While working through some problems, I encountered some strangeness.

I would think that using charsio:char_type/2 would be the best way to describe a relationship between a character and a set of characters, but when I was working on this problem, using char_type(D, decimal_digit) was unforgivably slow when it came to parsing numbers. Take a look and please replicate for yourself:

Considering the amount of Scryer code I've seen that uses char_type/2 for parsing, this seems a little problematic. I'm wondering if I'm missing something, like a flag I'm supposed to set?

:- use_module(library(time)).
:- use_module(library(charsio)).
:- use_module(library(lists)).
?- time(findall(D, char_type(D, decimal_digit), Ds)).
%@    % CPU time: 0.598s, 7_784_568 inferences
%@    Ds = "0123456789".

?- time(findall(D, member(D, "0123456789"), Ds)).
%@    % CPU time: 0.000s, 35 inferences
%@    Ds = "0123456789".


?- time(char_type('X', decimal_digit)).
%@    % CPU time: 0.000s, 27 inferences
%@    false.

?- time(member('X', "0123456789")).
%@    % CPU time: 0.000s, 19 inferences
%@    false.

Edit: Updated to most recent master commit 3fa6b69

[triska]

Currently, the implementation enumerates all Unicode code points, please have a look at the source code:

scryer-prolog/src/lib/charsio.pl

Line 155 in 3fa6b69

ccode(Code) :- between(0, 0xD7FF, Code).

I think it is well worth thinking about partially evaluating this predicate at compilation or code generation time, especially for those classes of characters where this would significantly reduce the runtime and not significantly increase the compilation time!

[jjtolton]

Great observation. Specifically here explains why parsing is faster than generating. Still, I agree, this is something that should be optimized at compile time or run time, considering there are a finite number of cases. I think this is worth filing an issue for and to get some comments on improvement.

Is there any Chesteron reason why this should not be optimized?

[librarianmage]

Yep, filed a similar issue here: #2329

[hurufu]

I think that it is possible to formulate char_type/2 relation as a CLP(ℤ) problem: #Type #= 1 #/\ #Code in 48 .. 57 #\/ ... and even generate all constraints directly from unicode database. Probably performance would suffer, but I envision some cool uses.

[hurufu]

Also as a bonus info, human languages are very complex (and messy): for example in an answer for the following query:

?- char_type(i, upper(U))

U should depend on user locale, because for Turkish language it must be İ.

[UWN]

Not sure it makes sense to make this so much dependent on the language environment. Maybe a local_upper/1 might take that burden.

[hurufu]

Or even local_upper/2 if user wants to use another locale:

?- char_type(i, local_upper("tr_TR", U)).
   U = İ.