Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Nov 18 21:30
    scala-steward closed #145
  • Nov 18 21:30
    scala-steward commented #145
  • Nov 18 21:30
    scala-steward opened #146
  • Nov 08 20:03
    scala-steward closed #144
  • Nov 08 20:03
    scala-steward commented #144
  • Nov 08 20:03
    scala-steward opened #145
  • Oct 21 20:33
    scala-steward closed #142
  • Oct 21 20:33
    scala-steward commented #142
  • Oct 21 20:33
    scala-steward opened #144
  • Sep 17 20:15
    scala-steward closed #140
  • Sep 17 20:15
    scala-steward commented #140
  • Sep 17 20:15
    scala-steward opened #143
  • Jul 13 23:59
    scala-steward closed #141
  • Jul 13 23:59
    scala-steward commented #141
  • Jul 13 23:59
    scala-steward opened #142
  • Jul 11 23:30
    scala-steward opened #141
  • Jul 11 23:30
    scala-steward opened #140
  • Mar 20 19:10
    scala-steward closed #131
  • Mar 20 19:10
    scala-steward commented #131
  • Mar 20 19:10
    scala-steward opened #139
Nicolas Rinaudo
@nrinaudo
but thanks, it makes it pretty clear that something's wrong with generic type class instance derivation
rubenpieters
@rubenpieters
I think in your genericinstances.scala you need to treat the GroupDecoder the same way as you did the MatchDecoder to handle arbitrary hlists, but in your comment you specifically mention hlists of size 1 so I'm not sure if it was a deliberate choice at some point
and thanks for the tips, I'll see if I can get a good example of my second point I mentioned
Nicolas Rinaudo
@nrinaudo
yeah, if you have a GroupDecoder[A] and a case class CC1 that only contains one field, and that field is of type A, then your GroupDecoder[A], is essentially a MatchDecoder[CC1]
but you're right, there might be something dodgy there. It's all tested, of course, but probably not quite as well as I thought
Nicolas Rinaudo
@nrinaudo
mmm... hang on, you're right, your use case cannot work with the current implementation
this looks like a design decision of my past self. I need to give this some thought :)
rubenpieters
@rubenpieters
Actually the other thing wasn't related to your library, it seems to be a general thing that implicits give a nullpointer if you use them before you initialize them
Nicolas Rinaudo
@nrinaudo
that's really weird
I wouldn't mind an example anyway, even if just here, I've never seen that behaviour
rubenpieters
@rubenpieters
object KantanRegexMatchNullPointer {
  val regex = rx"([0-9|-]+)".asUnsafeRegex[CCDT]

  implicit val timeDecoder: GroupDecoder[LocalDate] = {
    GroupDecoder[String].mapResult(s =>
      DecodeResult(LocalDate.parse(s, DateTimeFormatter.ofPattern("yyyy-MM-dd")))
    )
  }

  def main(args: Array[String]): Unit = {
    "2016-07-08".evalRegex(regex)
  }
}

case class CCDT(dt: LocalDate)
Nicolas Rinaudo
@nrinaudo
this throws a NullPointerException??
rubenpieters
@rubenpieters
yep
Nicolas Rinaudo
@nrinaudo
wtf.
you're right, probably not kantan.regex related, but still.
right, so, about your first issue. It's actually twofold
implicitly[GroupDecoder[CC4]] was never going to work. You can have a MatchDecoder[CC4], but not a GroupDecoder. Do you need me to explain why?
rubenpieters
@rubenpieters
uh yea
Nicolas Rinaudo
@nrinaudo
ok, so, a GroupDecoder decodes a group in a match - a string
a MatchDecoder decodes a match - potentially many strings
([a-z]+) ([0-9|-]+) has two groups: the first one, at least one letter, and the second one, at least one digit
you could represent matches of this regex as, for example, (String, Int)
I'm not sure if I'm being clear - I'm actually really tired and might not be making much sense
the point is that a group is a single string and a match is a collection of strings, so a GroupDecoder[A] is essentially a String => A where a MatchDecoder[A] is a Seq[String] => A
rubenpieters
@rubenpieters
yes I sort of get what you're saying, I'm just confused about something
I'll try it just gimme a sec
Nicolas Rinaudo
@nrinaudo
sure, no worries. I might actually fall asleep on my laptop soon though - if I don't answer straight away, don't worry, I'll just answer after a good night's sleep
rubenpieters
@rubenpieters
sure theres no hurry for me
ill play around a bit and try to understand it better
Nicolas Rinaudo
@nrinaudo
(I'm in Europe, so we might not be in the same time zones)
rubenpieters
@rubenpieters
im in europe too :)
Nicolas Rinaudo
@nrinaudo
I tried to explain everything in the documentation
if it's not clear enough, that's good feedback
by documentation, I mean the site, not the scaladoc, which is dodgy at best
right, and the second aspect of your issue: you currently need a GroupDecoder for both A and B in order to derive a MatchDecoder[(A, B)]. Since CC4 cannot have a GroupDecoder, you cannot get a MatchDecoder[(CC4, B)] for any B
I can't decide whether this makes sense or is a limitation. I'll need to think about it with a fresh brain.
rubenpieters
@rubenpieters

yep that part I get

but conceptually speaking there is not much difference in my eyes between something like ((A, B), (C, D)) and (A, B, C, D).

so that's why I would think that .evalRegex[((A, B), (C, D)) could work just as .evalRegex[(A, B, C, D)] works

but you don't have to answer this immediately

for now I can work around this and I really appreciate your library :+1:
Nicolas Rinaudo
@nrinaudo
you're absolutely right, but I don't think that's what your example shows
oh, hang on
you're absolutely right, this is what your example shows :)
rubenpieters
@rubenpieters
haha I'm glad it was clear
Nicolas Rinaudo
@nrinaudo
so yeah, I see your point. Not quite sure how to address it, but in an ideal world, what you want to do should work
well. I'm going to crash now, I'm useless in that state. Thanks for the positive feedback and interesting issues! :)
rubenpieters
@rubenpieters
no problem, thanks for the awesome and fast responses :)
Nicolas Rinaudo
@nrinaudo
I'm just excited to meet someone that actually uses my work :)
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