[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 09:50:55 -0400
On Thu, Sep 23, 2010 at 10:43 PM, David Manura <dm.lua@math2.org> wrote:
> I don't entirely like the idea of strings being interpreted as string
> patterns rather than strings; string patterns could be encoded
> specially in similar manner to how variables are with V. Strings
> passed into structural patterns as variables rather than as literals
> might be misinterpreted as string patterns, leading to subtle bugs.
> Lua's string library does the same thing though, apart from the
> `plain` parameter on string.find, and concerns have been raised on
> that [1-2].
I'm not set on testing strings with :match rather than just ==,
either. Perhaps it could be activated by an optional optional
match=true flag on the pattern row, like { "foo %d+", handle_num,
match=true } ? For now, it checks strings for magic characters and
only uses :match on string patterns when they are present (which makes
a big difference timewise). (Steve Donovan and I debated the pros and
cons of this, too.)
> First, tamale does exact matches but seems limited in handling
> unanchored matches and partial matches, such as to test whether an
> object is a table containing a field 'tag' equal to 'String', not
> caring whether the table contains any other fields (i.e. type(o) ==
> 'table' and o.tag == 'String').
Would it suffice to add a row flag, "partial=true", to allow the
table value being matched to have more elements than the pattern? It
actually happened by default, but I added a check because I thought it
would be surprising if done unintentionally. It seems like your case
would be handled by matching { tag="String", other="contents",
x="foo", y="bar" } with { {tag="String"}, partial=true, handler },
correct? I think that's a good idea, and shouldn't be difficult to
add.
> tamale does support variable captures, but I don't think it supports the concept of an "unknown number of fields".
I'm planning on adding a special case for a variable V"...", which
captures the remaining of the array-portion values: with { V"a", V"b",
V"..." }, {1, 2, 3, 4, 5} would match to {a=1, b=2, ["..."]={3, 4,
5}}.
> Alternation also comes up, e.g. pattern {tag =
> Or{'foo', 'bar'}}, although tamale does in a limited way support that
> by passing multiple patterns to tamale.matcher.
Using multiple patterns (a row each for foo and bar) is more
idiomatic, but checking via a when=has_foo_or_bar would also work.
Tamale is designed to efficiently handle matcher functions with dozens
of patterns (for FSMs, switching on bytecode, etc.). I guess some kind
of syntactic sugar could be added for Or that expands in place
multiple rows at build-time, though.
Thanks for your feedback!
Scott