[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: [ANN] tamale-1.2 - Erlang-style pattern matching library
- From: Scott Vokes <vokes.s@...>
- Date: Fri, 24 Sep 2010 10:39:35 -0400
On Fri, Sep 24, 2010 at 10:14 AM, Javier Guerra Giraldez
<javier@guerrag.com> wrote:
> my 2 cents (with 30% discount for not having read the source!): don't
> scan the string either, use closures:
>
> instead of: "xxx" is a constant, and "xx%d" is a match pattern, do:
> "xxx" is a constant and tamale.M("xx%d") is a match predicate (a
> closure that takes the target element and returns true or false).
That could work, though the behavior for string.match also includes
captures, and multiple match predicates would need to be factored in
any indexing. Indexing is responsible for most of tamale's complexity,
but it also gives a pretty substantial performance improvement.
In my mental model of how tamale works:
matching "xx3" against { "xx%d", handler} -> fails
matching "xx3" against { "xx%d", handler, match=true } -> succeed (and
pass { 3 } to the handler). match=true being a flag that compares
string values by string.match, rather than ==.
matching "xx3" against { M"xx%d", handler } could do same (where M
returns your string.match fun, closed over "xx%d") - the rule could be
that if the pattern is a function, it takes a value and returns either
false/nil (for no match), true (match), or a table (match, with
captures). This would be more general than just using string:match,
but couldn't be indexed. (Variables and string patterns aren't indexed
either, though.)
How does that sound?
Thanks,
Scott