nrinaudo/kantan.regex

Regular expression library for Scala

rubenpieters

@rubenpieters

I played around with this a bit and here is one idea that works quite cleanly in the current model:
https://gist.github.com/rubenpieters/05cbc4d3884bcdf3aaf9ad8bd9920483

(I also had another idea where matchdecoders could be represented as a list of groupdecoders but that would require a lot of breaking stuff in the current implementation)

but for the progressed match gist: if there is a way to know how much of the matches a decoder will take from the matcher then the implicit could be generalized to more arbitrary shapes.

Nicolas Rinaudo

@nrinaudo

Yeah, that's pretty much the same direction I was going. It'll still need to break a lot things, so I honestly doubt I'll start before the next release.

Which should hopefully be soon, the only large outstanding issue is adding support for java 8 time.

Nicolas Rinaudo

@nrinaudo

by the way, may I ask how you stumbled on kantan.regex? I've not exaclty gone out of my way to advertise it

rubenpieters

@rubenpieters

I was googling something with scala and regex, i dont remember what exactly

it was not simply scala regex, but something more specific

Nicolas Rinaudo

@nrinaudo

"amazing scala regex library"

probably.

rubenpieters

@rubenpieters

haha

Nicolas Rinaudo

@nrinaudo

right, so, about your suggested improvement. Having some sort of state aware match implementation sounds like a good way to do it

rubenpieters

@rubenpieters

ah it was "github scala regex gr library" I was actually looking for a gist or a repo I remember seeing somewhere but then one of the top matches is your repo if you google that

Nicolas Rinaudo

@nrinaudo

what bothers me about it a bit is that it'd strictly be for the shapeless module, and is actually less powerful than what exists now

what's gr stand for?

rubenpieters

@rubenpieters

i dont know I just thought that in the title of the thing I was looking for that was used, I think its simply an abbreviation for groups or something

Nicolas Rinaudo

@nrinaudo

when I say less powerful, I mean that if you write your own MatchDecoder, you can grab groups for anywhere in the match to build your values. With a state aware match, you must work with the assumption that they're ordered

rubenpieters

@rubenpieters

hmm yes good point

Nicolas Rinaudo

@nrinaudo

which can be problematic with recursive types - how would you deal with a Tree[A], where a node might contain a node that might contain a node?

I don't think that's reason enough to drop the idea - at worst, it's a good default behaviour

but I want to give it more thoughts, because the modifications would spill into the rest of the library and make it backward-incompatible

rubenpieters

@rubenpieters

I'm not sure if shapeless sort of has an ordering for its nested hlists representation for case classes, I think it might

Nicolas Rinaudo

@nrinaudo

I really don't know. At least it'd need to decide whether it wants to do a depth- or breadth- first traversal

rubenpieters

@rubenpieters

breadth first seems kinda counterintuitive to me, but maybe thats just me

Nicolas Rinaudo

@nrinaudo

that's the entire point: I don't know, it probably depends on the user, and whatever choice we make will be wrong sometimes :)

so my point is: your idea is sound but will require me to give it more thoughts. Do you want me to show you how to deal with your specific (CC1, CC4) issue if that's a blocker?

rubenpieters

@rubenpieters

no the current workaround I have is fine for me

Nicolas Rinaudo

@nrinaudo

because your issue is not that you can't write a MatchDecoder[(CC1, CC4)] instance, but that you can't derive one automatically

which is absolutely true

rubenpieters

@rubenpieters

yep I know

Nicolas Rinaudo

@nrinaudo

ok, cool

automatic derivation is always going to be limited anyway - what happens if your case class fields are not declared in exactly the same order as your regex groups?

it makes a lot of assumptions about types and results, and those are clearly not always the correct ones

that's why kantan.regex also provides non-generic helpers for case class decoder creation - I don't know if you've seen those?

rubenpieters

@rubenpieters

hmm I don't think so

I'm not sure what you're referring to exactly

Nicolas Rinaudo

@nrinaudo

MatchDecoder.decoder and MatchDecoder.ordered

MatchDecoder.decoder(1, 3, 5) { (i: Int, d: Date, l: Long) => new MyType(i, d, l) }

rubenpieters

@rubenpieters

ah ok cool, is that one on the website somewhere? I saw the ordered, but I didn't see that one

Nicolas Rinaudo

@nrinaudo

it's more hinted at than properly explained, I probably need to address that

ah hang on, no, it is

https://nrinaudo.github.io/kantan.regex/tut/arbitrary_types.html

(and so we're clear: all the documentation's code is actually compiled and executed, so if it's in the doc, you know it's correct. I'm really proud of that)

ok, so I just re-read that example, and it was a mistake on my part to use ordered in the documentation. I should have used decoder. I'll create an issue

rubenpieters

@rubenpieters

thats pretty cool

Nicolas Rinaudo

@nrinaudo

is it clear what MatchDecoder.decoder does, and that it supports any arity from 1 to 22, or do you need some help?

rubenpieters

@rubenpieters

yes that is clear, but since it takes implicit groupdecoders it wont work when I will put multiple case class in it, is that right?

Nicolas Rinaudo

@nrinaudo

(just got pulled in on a meeting)

rubenpieters

@rubenpieters

ok nevermind the previous comment, I understand a bit better what it does now, the .decoder thing is a nice solution for the user to specify the order of things he wants to do

Nicolas Rinaudo

@nrinaudo

or build nested case class structures

rubenpieters

@rubenpieters

yep

Nicolas Rinaudo

@nrinaudo

I assumed that was your workaround :)

Where communities thrive

People

Repo info

Activity