01:09 skids joined, AlexDaniel joined 01:35 AlexDani` joined 01:47 ilbot3 joined 03:54 geekosaur joined 05:29 geekosaur joined 05:31 geekosaur joined
masak yep -- shortest day of the year! 08:54
masak .oO( leap hour )
09:11 RabidGravy joined 09:33 dalek joined
[Tux] test 22.338 10:19
test-t 12.827
csv-parser 26.899
10:59 FROGGS joined 12:25 vendethiel joined 12:56 RabidGravy joined
lizmat m: say "foo99".succ # sort of unexpected, but logical 13:44
camelia rakudo-moar 47d21b: OUTPUT«fop00␤»
lizmat m: say "foo.99".succ # sort of expected to see "foo.100"
camelia rakudo-moar 47d21b: OUTPUT«fop.99␤»
lizmat ^^ feels like a bug to me, opinions ?? I mean, it should probably be "fop.00" if we're just ignoring non-magical chars 13:45
masak m: say "foo-99".succ # hyphen behaves differently from dot -- why? 13:50
camelia rakudo-moar 47d21b: OUTPUT«foo-100␤»
masak currently I see no arguments either for changing or keeping the current behavior. 13:51
though I confess to being wary of this type of magic
lizmat masak: there's an explicit check for "." somewhere in there
masak I would probably not rely on it in production -- I'd write something slightly longer but clearer :)
lizmat: could be that "." figures in numbers, perhaps? I dunno. 13:52
vendethiel no, it's here explicitly for this, AFAIK: 13:55
m: say "file99.ext".succ;
camelia rakudo-moar 47d21b: OUTPUT«filf00.ext␤»
lizmat the check for "." was part of pmichaud's original implementation in ffb46dcfc0057475ed5
vendethiel m: say "file99-ext".succ;
camelia rakudo-moar 47d21b: OUTPUT«file99-exu␤»
vendethiel ^ masak
lizmat this feels more like an implementation of IO::Path.succ 13:56
masak I can see that argument, yes 13:57
that's kind of why we have types ;)
13:58 Ven joined
masak m: say "file-99.ext".succ # saner example 13:58
camelia rakudo-moar 47d21b: OUTPUT«file-100.ext␤»
Ven I'd argue it's **very** surprising how the "add-another-char" behavior is :o
lizmat m: say "9".succ # really surprising ?? 14:01
camelia rakudo-moar 47d21b: OUTPUT«10␤»
Ven m: say "file99.ext".succ; 14:02
camelia rakudo-moar 47d21b: OUTPUT«filf00.ext␤»
Ven instead of prepending a "1", it changed "e" (from file) to "f"
lizmat: ^ that I consider surprising.. 14:03
masak that's a p5 thing, though
m: say "f9".succ
camelia rakudo-moar 47d21b: OUTPUT«g0␤»
lizmat ah, yes, that, well, it's logical in a way, since the "e" is a magical char as far as .succ is concerned
masak easier to see when the letter is not a word...
lizmat m: say "z".succ 14:04
camelia rakudo-moar 47d21b: OUTPUT«aa␤»
lizmat m: say "aa".pred
camelia rakudo-moar 47d21b: OUTPUT«Decrement out of range␤ in block <unit> at /tmp/8PoC91TM1y line 1␤␤Actually thrown at:␤ in block <unit> at /tmp/8PoC91TM1y line 1␤␤»
masak $ perl -E 'my $s = "f9"; $s++; say $s'
g0
lizmat huh?
masak lizmat: ¿huh
lizmat "aa" doesn't have a pred ?
masak I remember us adding that error
Ven m: say "99".succ 14:05
camelia rakudo-moar 47d21b: OUTPUT«100␤»
Ven heh.
masak m: say "100".pred
camelia rakudo-moar 47d21b: OUTPUT«099␤»
lizmat $ perl -E 'my $a = "aa"; say $a--; say $a'
aa
-1
weird
masak hm, actually, I'm wrong 14:06
it wasn't added
it's from the *original* 2011 implementation by pmichaud++
lizmat yeah..
masak a comment says
# cannot carry beyond first rangechar position
which I think is fair
lizmat but if "z".succ is "aa", shouldn't "aa".pred be "z" ? 14:07
masak my brain insists (vaguely) that there was some very good reason not to do that
but I don't have a reference, sorry
maybe it was some discussion on IRC or p6l
lizmat well, it definitely simplifies matters :-) 14:08
masak it's easy to rationalize why it shouldn't work
namely, strings aren't numbers, and you can't increment them
we try to pretend that they are and that you can
to a point, after which it turns untenable. then we throw an exception
also, due to the way ranges work, I'd think that .succ is way more common than .pred 14:09
lizmat true
masak so maybe it could be argued that "aa".pred is much more indicative of mistake/confusion than "z".succ
language design is tricky :)
masak .oO( let's go shopping ) 14:10
lizmat it feels that I'm getting close to 6.c.1 or 6.d territory 14:25
dalek kudo/nom: d0c675c | lizmat++ | tools/build/makeMAGIC_INC_DEC.pl6:
Some more WIP on succ/pred data structure generating
 14:26
TimToady wonders why this sudden urge to redesign all the things... 15:00
jnthn .succ/.pred are methods, so can't really be handled by language versioning 15:01
TimToady the '.' exception was quite intentional from the start
jnthn I'm pretty sure I have code that relies on the . special case even :)
So yeah, we won't change that.
I'd be surprised if it's not test-covered 15:02
TimToady I'd be surprised if it's not explicitly specced
jnthn That too ;)
jnthn isn't sure whether the backlog was actually proposing changes or just exploring what exactly is going on... :) 15:04
lizmat I was looking at fixing the "z" .. "ab" issue 15:10
dinner&
jnthn m: say "z" .. "ab" 15:11
camelia rakudo-moar d0c675: OUTPUT«"z".."ab"␤»
jnthn m: say list "z" .. "ab"
camelia rakudo-moar d0c675: OUTPUT«()␤»
16:36 vendethiel joined
masak I hope I will never need the correct behavior of "z" .. "ab" in any of my future code :P 16:58
17:10 skids joined 17:29 vendethiel joined
lizmat the more I dig into this, the more I think Str ranges should only allow single char strings 18:33
lizmat is going to check out what Batman has against Superman 18:34
so afk for a few hours&
well, that was a lot of WAT! 22:23
good night, #p6dev! 22:24
jnthn
.oO( Don't worry, the sequel will DWIM to make up for it... )
RabidGravy Ooh didn't do my weekly "test all the things" run 22:42
tomorrow
23:20 vendethiel joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!