TIP: Implementation of pattern matching

[ljmf00]

Idea

There will be two matchers. One for type matching and the other for value-based matching:

Generic matchers will be implemented on taurus.match.

Type matching

On this type of matchers you need to specify the matched type on a list of lambda functions.

Using class typeid:

class A {}
class C {}

Object a = new C;
string ret = atum.match!(
	(C c) => c.toString(),
    (A a) => a.toString(),
	() => ""
);

Could be also implemented with other type matchers that use typeid for type discovery.

Using Optional types:

auto s = some(7);

int ret = s.match!(
	(Some!int s) => s.get(),
    (None) => 0,
);

You can even omit None, or Some, if that happens you need to strictly define a default, otherwise, you need to use finalMatch!() template. This behavior mimics the D switch and final switch respectively.

Value-based matching

You will have two generic value-based matchers:

bool atum;

/// associative array
int ret1 = atum.match!([
    true: (bool x) => x,
    false: (bool x) => x
]);

/// quasiquotes syntax based on associative array body initializer
int ret2 = atum.match!(q{
    true: x => x,
    false: x => x
});

---

This description may change on new proposals

[ljmf00]

@iK4tsu what do you think would be a good naming for the generic module for pattern matching?

• taurus.match
• taurus.matching
• taurus.pattern

Any other idea?

[iK4tsu]

taurus.match is the better fit.

[iK4tsu]

I'm afraid this isn't possible in the present. D doesn't not let you pass an AA in compile time with lambdas.

template match(alias AA)
{
	auto match(T)(T _){}
}

bool atum;

// perfectly valid
int ret1 = atum.match!([
    true: 3,
    false: 4
]);

// expression __lambda1 is not a valid template value argument
// expression __lambda2 is not a valid template value argument
int ret1 = atum.match!([
    true: (bool x) => x,
    false: (bool x) => x
]);

The only way to do it is to use Alias. But unfortunately this cannot be used in templates.

// valid
alias AA = Alias!([
    true: (bool x) => x,
    false: (bool x) => x
]);

Probably D tries to evaluate __lambdas to soon and because of that they're considered invalid. An alternative to this is to use CTFE.

auto match(T,AA)(T _t, AA _a) {}

bool atum;

// now it works
int ret1 = atum.match([
    true: (bool x) => x,
    false: (bool x) => x
]);

[iK4tsu]

Perhaps when static initialization is implemented this will be possible, but right now it is not.

[ljmf00]

I guess its possible to implement this with the current approach. I can do some PoC code.

Perhaps when static initialization is implemented this will be possible, but right now it is not.

Weird, because this is. At least, it compiles and run as expected. You can also do it at compile-time, using enum.

enum long[string] aa = [
      "foo": 5,
      "bar": 10,
      "baz": 2000
    ];

immutable long[string] bb = [
      "foo": 5,
      "bar": 10,
      "baz": 2000
    ];

Both works.

[iK4tsu]

I guess its possible to implement this with the current approach. I can do some PoC code.

It's not.

Weird, because this is. At least, it compiles and run as expected. You can also do it at compile-time, using enum.

I gave that example above, including using Alias. It does not work with lambda when passing it to a template. You can instantiate them with enum or Alias because it's evaluated in CTFE but you cannot pass them to a template which is evaluated in compile time. I linked to that because what is currently implemented and working might not be what they intend to be working, meaning, it might not be the static initialization they want or define. If it is implemented and they forgot to update the spec, either it doesn't work with lambda or it's a bug. I say this because it's possible to pass an AA to a template with those examples above, as I exemplified as well, and we can also pass a lambda to a template (e.g alias fun), but you can't pass an AA with lambda.

import std;

template aa(alias pred) { void aa() {} }

void main()
{
	// ok
    aa!([
  		"foo": 5,
      	"bar": 10,
      	"baz": 2000
	]);

	// ok
	aa!(() => 5);
    
	// oh hell nah
	aa!([
  		"foo": () => 5,
      	"bar": () => 10,
      	"baz": () => 2000
	]);
}

[ljmf00]

It's not.

It is.

Currently, it only works with function literals. With some help from Adam D. and other people on D discord, we figured out the problem.

template match(alias pred)
{
        auto helper() {
                return pred["foo"]();
        }
        enum match = helper();
}

void main()
{
    auto a = match!([
        "foo": () => 5,
    ]);
}

This proves that it's possible to work around this problem using CTFE. The thing we need to avoid in templates is introducing pointers. This problem is all about pointers, not about type inference.

A reduced version of the problematic code:

void match(alias pred)()
{}

int fun() { return 5; }

void main()
{
    match!(&fun);
}

Currently, in D, every expression that has lambdas inside converts it to a pointer, if you try the first example with normal arrays, it won't work too. CTFE is perfectly working with lambdas + associative arrays and the proof of it is this:

int match(alias pred)()
{
        return pred["foo"]();
}

void main()
{
    pragma(msg, match!([
        "foo": () => 5,
    ]));
}

Output:

5
app.d(9): Error: expression __lambda1 is not a valid template value argument

That's why we can do matching with function literals. Although, if we want this type of matching to be dynamic, we need to do a PR to the compiler.