7 hours ago, Marijn wrote: > > On 30-12-11 09:32, Eli Barzilay wrote: > > >> Without the capturing group the results are identical: [...] > > > > Which is expected. > > Good, just establishing a baseline here, but it is good that some > compatibility is *expected*.
I meant that getting the same results is the thing that is expected. > > There's probably uses for that -- at least for the simple version > > with a single group around the whole regexp, but that's some > > hybrid of `regexp-split' and `regexp-match*': it returns something > > that interlevase them, which can be useful, but I'd rather see it > > with a different name. > > Yes, I agree that I find it a bit weird as well. > > You don't lose anything by supporting this though, since you can > always use a non-capturing group, but I do agree that it can be > considered an inappropriate extension of the meaning of > regexp-split. I'll be sure to raise these issues on the guile list. We do have an important loss -- all current code that will break because it assumes the current behavior. This is why I suggested a different name -- the new function could be used to return the gaps (as split does), the matches (as match*), the matches including groups, or all of these. > > We've talked semi-recently about adding an option to > > `regexp-match*' so it can return the lists of matches for each > > pattern, perhaps add another option for returning the unmatched > > sequences between them, and give the whole thing a new name? > > (Something that indicates it being the multitool version of all of > > these.) > > Interesting. BTW, one thing that I think it should do is avoid the splicing of the group matches that python is doing. In any case, any suggestions for a name? -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _________________________ Racket Developers list: http://lists.racket-lang.org/dev