Re: Ann: regex pack

Michael, a loosely coupled note about your valuable contribution.

I'm working on reusing syntax highlighting in Qt, and noted the absence of
number class in library(prolog_colour).
Given the richness of numeric types, and the recent introduction of digit
group separators in output/input, I was planning to patch the library, but
I quickly realized I don't know how to rightly tackle the problem.

Now there is some bug around: for instance

?- [library(dcg/basics)].
?- phrase(number(X), "12 000").
false.

and maybe some naive parsing will fail. dcg/basics is rightly based on
code_type, but

?- member(X," _"), setof(T,code_type(X,T),L).
X = 32,
L = [ascii, space, white, to_lower(32), to_upper(32)] ;
X = 95,
L = [ascii, csym, csymf, graph, prolog_atom_start,
prolog_identifier_continue, prolog_var_start, punct, to_lower(...)|...].

I wonder if adding the group digit separators to code_type (or char_type)
could break something around, and if the locale setting should play any
role in this topic...

2013/9/13 Michael Hendricks <[email protected]>

> I love DCGs as much as the next Prolog fan, but sometimes a tiny regular
> expression will do the job.  Or perhaps regular expressions are part of
> your app's UI.  Anyway, this
> pack<http://www.swi-prolog.org/pack/list?p=regex>supports many
> features of Perl compatible regex (see link for full support).
>
> As the semantic version number indicates, the API is very early and will
> probably change. It currently uses =~ (as do Haskell and Perl), but that
> gives no access to captured values.  A YAP-compatible API would support
> captures so I might do that.  I'd also love to use
> prolog_load_context(variable_names, _) with regex named captures to
> automatically bind clause variables by name.
>
> I considered supporting quasiquotation (so one doesn't have to escape all
> the slashes), but decided for now that a regex that complex should probably
> be rewritten as a DCG anyway.
>
> The regular expression engine is currently a naive interpreter.  I partly
> did that so that I have an interpreter to play with as I experiment with
> some partial evaluation ideas.  It would be cool to partially evaluate the
> regex interpreter against a regex to generate fast, concise Prolog code.
>
>
This sounds great. I think there is available code from Kuniaki
Mukai<https://lists.iai.uni-bonn.de/pipermail/swi-prolog/2012/008108.html>,
worth to study and eventually reuse.
His PAC should also be made available way in packs, as well as his REX :)

Last thought: I tried to design the library to support pluggable regex
> engines.  The idea is that one just adds a single line:
>
>     :- use_module(library(regex/engine/re2)).
>
> and your regular expressions are now handled by the re2
> engine<https://code.google.com/p/re2/> (or
> PCRE or POSIX or ...).  Any interest in such things?  I've used similar
> tools to good effect in both Haskell and Perl.
>
> --
> Michael
> -------------- next part --------------
> HTML attachment scrubbed and removed
> _______________________________________________
> SWI-Prolog mailing list
> [email protected]
> https://lists.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog
>
-------------- next part --------------
HTML attachment scrubbed and removed