On Saturday, 12 March 2016 at 20:56:47 UTC, Jacob Carlborg wrote:
On 12/03/16 14:12, Simen Kjaeraas wrote:
As I once again bemoaned D's lack of pattern matching
yesterday, I was
inspired to create this[0] implementation, that plays to D's
strengths,
allows for user-defined matching, and has a fairly usable
syntax. The
core usage looks like this:
unittest {
auto a = tuple(1, "foo");
auto b = match(a) (
_!(int, "foo") = (int i) => 1,
_!(_, _) = () => 0
);
assert(b == 1);
}
What kind of syntax is that? Is "match" returning a struct with
opCall that is called immediately?
Indeed. The goal was to make it look similar to a switch
statement. I actually started out with an idea for expanding
switch with pattern matching using lowerings, then noticed I
could do most of the stuff I wanted without compiler changes.
With the user-defined matching implemented as follows:
struct Tuple(T...) {
// Implementation
// Magic happens here
bool opMatch(Pattern, Args...)(Pattern p, ref Args args) {
foreach (i, e; p.pattern) {
static if (isTypeTuple!e) {
enum n = countTypes!(p.pattern[0..i]);
args[n] = fields[i];
} else static if (!ignore!e) {
if (fields[i] != e) {
return false;
}
}
}
}
}
Is the tuple iterating all patterns to see if there's a match?
Shouldn't that be the job for the the match function?
The match function goes through the list of patterns and for each
one asks the tuple if opMatch returns true for that pattern. If
it does, the function assigned that pattern is called with the
values assigned to args.
opMatch here is checking for each element of the pattern if it
matches the corresponding element of the tuple. Since the pattern
is available at compile-time, opMatch can deny patterns it
doesn't like (e.g. trying to match a Tuple!(int, string) with a
string).
The match function is really only a framework for having similar
matching syntax for dissimilar types.
If the capability of matching patterns to types were in the match
function, how could a user type override it? Matching on a
Tuple!(string, string) is different from matching on an
Algebraic!(int[], Foo*) is different from matching on a
specialized user type that wants to do something real weird (I'm
not sure what that'd be, but I'm sure there are people who will
want to).
I've started implementing a pattern matching function as well.
It has a syntax that only use compile time parameters, because
both types and values can be passed. I'm not entirely sure on
the syntax yet. I'll have to see what's possible to implement.
Some suggestions:
auto a = tuple(1, "foo");
auto b = match!(a,
int, "foo", (int i) => 1,
_, _, () => 0,
);
That works. I feel the grouping is looser than in my example, and
that the pattern doesn't stand out from the rest of the
expression, but it certainly works, and there are some benefits
to that syntax.
If the pull request for inspecting templates ever will be
merged it won't be necessary to have typed lambdas:
auto b = match!(a,
int, "foo", (i) => 1,
_, _, () => 0,
);
There's a problem using that syntax? It works for me in a toy
example:
http://dpaste.dzfl.pl/7360ee90b344
Sorry about the lack of comments and stuff, but it's 3:30AM, and
I probably shouldn't be programming now.
