guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Stupid module and pregexp questions


From: Rob Browning
Subject: Re: Stupid module and pregexp questions
Date: Mon, 05 May 2003 02:47:20 -0500
User-agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3 (gnu/linux)

Tom Lord <address@hidden> writes:

> (Ahem!) The distinction between PCRE and other matchers (posix
> matchers in genral, Rx specifically - is not _syntactic_.  It's
> semantic and has deep implications for implementation techniques and
> performance, in both short and long time frames.  So, choices you make
> today, assuming that guile persists and spreads, have _long_ term
> consequences.

Sure, but a counter argument would be that just guaranteeing that we
have elisp, or perl, or "well defined POSIX" (perhaps Rx[1]) regular
expressions available (for example) doesn't say anything positive or
negative about what *else* we might have available, and it does mean
that anyone that is familiar and comfortable with whichever one we
might pick can reach for guile more easily whenever they want to get
something done (something they already know how to do).  They can
always learn the better thing later, once we have it.

Note that it's possible I'm trying to fix something that isn't broken
here.  If all (or nearly all) of the libs that guile might choose to
link against for (ice-9 regex) on various platforms are consistent
with each other, then I should perhaps withdraw my suggestions.  I was
just under the impression that they vary substantially, and wanted to
have at least one familiar regex subsystem in the core that eliminated
the variance.

Also, if one of the main things you're arguing is that perl and
emacs-style regexes have extensions that we need to do without if we
want good performance, then I'm not trying to argue against that
assertion.  I'm really just ruminating on the advisability of a
well-defined, invariant, and reasonably familiar regex syntax for
guile's core.  I'd probably be perfectly happy with a good POSIX
implementation in the core, perhaps even with a subset of POSIX if
dropping certain bits were somehow important...

Thanks again

[1] Of course, I completely understand if you don't feel you're in a
    position to make that available for inclusion ATM.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4




reply via email to

[Prev in Thread] Current Thread [Next in Thread]