nrinaudo/kantan.regex

Regular expression library for Scala

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 :)

rubenpieters

@rubenpieters

Well currently the workaround is that I split the string and parse those elements separately in the case classes I want. I'm not sure the .decoder would work since in total there are more than 22 fields

Nicolas Rinaudo

@nrinaudo

ah, I see

Nicolas Rinaudo

@nrinaudo

Alright, so kantan.codecs now has support for java 8 times. I need to tidy it up somewhat, but it should now be trivial to bring it to kantan.regex

rubenpieters

@rubenpieters

Ok cool thanks

Where communities thrive

People

Repo info

Activity