Bulat Ziganshin wrote:
Hello wren,
Thursday, November 6, 2008, 12:00:22 PM, you wrote:
the trie automaton I mentioned in my previous post: just add a (?{
$value = ... }) action to the end of each component regex and read out
the value of $value after you match.
$value? in haskell? :)
Shh,
Hello wren,
Thursday, November 6, 2008, 12:00:22 PM, you wrote:
> the trie automaton I mentioned in my previous post: just add a (?{
> $value = ... }) action to the end of each component regex and read out
> the value of $value after you match.
$value? in haskell? :)
--
Best regards,
Bulat
ChrisK wrote:
If you need to be left-biased then you need a perl-style engine, and you
can use the regex-pcre or pcre-light haskell package and the PCRE
library. These are obtainable from Hackage. I doubt PCRE uses a simple
DFA...
I don't know if regex-pcre or pcre-light supports the (?{...
On 6 Nov 2008, at 1:25 am, Johannes Waldmann wrote:
using strings (inside a program) to represent structured data
is wrong (*).
+1
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
"roger peppe" <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 5, 2008 at 1:56 PM, Martijn van Steenbergen
> <[EMAIL PROTECTED]> wrote:
> > I think I'll try roger's (private)
>
> eek, bitten by "reply to sender only" again!
>
> i had intended to send to the list too.
>
I recommend using a newsreader and
Johannes Waldmann schrieb:
> using strings (inside a program) to represent structured data
> is wrong (*).
>
> of course you need strings for interfacing the "outside" world,
> but the microsecond they get on the inside,
> they should be tokenized and parsed away
> into something useful (= an ab
using strings (inside a program) to represent structured data
is wrong (*).
of course you need strings for interfacing the "outside" world,
but the microsecond they get on the inside,
they should be tokenized and parsed away
into something useful (= an abstract syntax tree).
(*) corollary:
u
Excerpts from ajb's message of Wed Nov 05 03:59:03 +0100 2008:
> G'day all.
Hi,
>
> Quoting Achim Schneider <[EMAIL PROTECTED]>:
>
> > Considering that he's talking about a mud, I figure the grammar is a
> > quite straightforward
> >
> > command = l[eft] | r[ight] | ... | t[ake] | c[ast]
> >
G'day all.
Quoting Achim Schneider <[EMAIL PROTECTED]>:
Considering that he's talking about a mud, I figure the grammar is a
quite straightforward
command = l[eft] | r[ight] | ... | t[ake] | c[ast]
That is, I'd be very surprised if you even need more than two or three
characters lookahead,
G'day all.
Quoting Achim Schneider <[EMAIL PROTECTED]>:
Considering that he's talking about a mud, I figure the grammar is a
quite straightforward
command = l[eft] | r[ight] | ... | t[ake] | c[ast]
That is, I'd be very surprised if you even need more than two or three
characters lookahead,
On Tue, 2008-11-04 at 10:02 -0800, Dan Piponi wrote:
> On Tue, Nov 4, 2008 at 9:26 AM, Achim Schneider <[EMAIL PROTECTED]> wrote:
> > Martijn van Steenbergen <[EMAIL PROTECTED]> wrote:
> > For anything remotely connected to parsing, always use parsec.
> >
> > I'd not be surprised if the beast is to
On Tue, Nov 04, 2008 at 08:34:37PM +0100, Achim Schneider wrote:
>
> Parsec is a thousand times more efficient for such things than regular
> expressions, and you can just lazily parse all the input into a list
> of data constructors and happily fold it into your state...
I would recommend you to
The regex-tdfa package (and regex-posix) implement subexpressions capture.
So if you want to match alpha beta and gamma in parallel you could write
"(alpha)|(beta)|(gamma)" and check which subexpression has the non-empty match.
This becomes slightly complicated if there are parenthesis and capt
"Dan Piponi" <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 4, 2008 at 9:26 AM, Achim Schneider <[EMAIL PROTECTED]>
> wrote:
> > Martijn van Steenbergen <[EMAIL PROTECTED]> wrote:
> > For anything remotely connected to parsing, always use parsec.
> >
> > I'd not be surprised if the beast is touring comp
On Tue, Nov 4, 2008 at 9:26 AM, Achim Schneider <[EMAIL PROTECTED]> wrote:
> Martijn van Steenbergen <[EMAIL PROTECTED]> wrote:
> For anything remotely connected to parsing, always use parsec.
>
> I'd not be surprised if the beast is touring complete in itself...
Actually, this can count against y
On Tue, 2008-11-04 at 18:26 +0100, Achim Schneider wrote:
> Martijn van Steenbergen <[EMAIL PROTECTED]> wrote:
>
> > Does anyone have any experience with this? What's the best way to
> > achieve this?
> >
> For anything remotely connected to parsing, always use parsec.
>
> I'd not be surprised
Martijn van Steenbergen <[EMAIL PROTECTED]> wrote:
> Does anyone have any experience with this? What's the best way to
> achieve this?
>
For anything remotely connected to parsing, always use parsec.
I'd not be surprised if the beast is touring complete in itself... or
can parse something that
17 matches
Mail list logo
