www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Library implementation for pattern matching

reply "Idan Arye" <GenericNPC gmail.com> writes:
While getting a bit carried away with my 
`castSwitch`(https://github.com/D-Programming-Language/phobos/pull/1266#iss
ecomment-53218941), 
I realized I can do more - much more - if I can create a 
"Constraint" struct, one that can limit the values it can receive 
based on it's template parameters, and that can be queried to 
verify if a value fits in those limits without relying on 
exceptions. That kind of struct will allow me mimic the 
concrete-values-in-pattern and the case guards that you can often 
see in (statically typed) functional languages.

Even with that function, I believe there is still room for the 
old `predSwitch`, `castSwitch` and `regexSwitch`:

`predSwitch`(https://github.com/D-Programming-Language/phobos/pull/1259) 
is a syntax optimization for when you don't care about the 
matched object, only which case matched.

`regexSwitch`(https://github.com/D-Programming-Language/phobos/pull/1392) 
provides simple string-to-value conversions and in the future 
will hopefully provide range-of-matches iteration(which will make 
it a mini-lexer)(the requirements for it to provide this are what 
currently block that PR, but that's OT).

`castSwitch`(https://github.com/D-Programming-Language/phobos/pull/1266#is
uecomment-53218941) 
provides an optimization that skips many failed casts - that 
optimization takes up the majority of the code, and it will 
become so much more complex(and IMO infeasible) once we add the 
`Constraint` support, so I would rather leave it out of the 
super-powered pattern matching function and leave `castSwitch` as 
is.


So, after I finish adding multiple arguments support to 
`castSwitch` I want to start coding that full blown pattern 
matching function. Right now I consider two options:


1) First create the Constraint struct as a PR to `std.typecons` - 
that kind of struct might be useful for other things as 
well(think argument verification for reflective dispatch 
frameworks). After that gets accepted, create the monster pattern 
matching function as a PR to `std.algorithm`.

2) Create a third party library and make it available on DUB. 
Have that library closely follow the Phobos coding standards so 
someday we might add it as a new module.


The first option will allow it to get into the standard library 
faster, but the second will make it available faster and allow me 
to experiment more so I'm tending to choose it. If I follow that 
second path - do we have a convention for naming third party 
packages that aim to get into Phobos? Should I name it 
`stdx.patternmaching` or `std.experimental.patternmatching` or 
something?


Any opinions?
Aug 25 2014
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/25/14, 2:30 PM, Idan Arye wrote:

 While getting a bit carried away with my


...................................

 Any opinions?


I have too much on my plate to look at this but I recall you had some 
really promising ideas and these seem to be in the same mold, so please 
continue, something great might come out of it. Good luck! -- Andrei
Aug 25 2014
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
Don't have time to comment in details but wanted to warn about 
one thing : don't over-engineer. There is only limited value in a 
smart utility if its usage pattern can't be immediately 
recognized by a new developer.
Aug 25 2014
parent "Idan Arye" <GenericNPC gmail.com> writes:
On Monday, 25 August 2014 at 22:35:08 UTC, Dicebot wrote:

 Don't have time to comment in details but wanted to warn about 
 one thing : don't over-engineer. There is only limited value in 
 a smart utility if its usage pattern can't be immediately 
 recognized by a new developer.


Well, what I had in mind is more complex than 
`predSwitch`/`castSwitch`/`regexSwitch`, but not *that* complex. 
I want to support syntax like:

uint multiplyTuple(Tuple(int, int) operands){
     return operands.patternMatch!(
         (Constrainted!(uint, "==", 0), uint _) => 0,
         (Constrainted!(uint, "==", 1), uint b) => b,
         (a, uint b) => b + multiplyTuple(tuple(a - 1, b)),
     )();
}
Aug 26 2014
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, 25 August 2014 at 21:30:06 UTC, Idan Arye wrote:

 Any opinions?


Well, like the others, I unfortunately do not have time to look 
at this at the moment, but my first reaction is that it seems 
quite complicated, which would be a definite negative. So, I 
don't know how simple it can be to do what you're trying to do, 
but if it's complicated enough, then it probably won't get used, 
and it's more likely to be misused.

- Jonathan M Davis
Aug 25 2014