🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm
Set by lizmat on 8 June 2022.
leont I spent a bunch of time on version ranges in Perl land recently, and took the liberty to port that to Raku as an alternative to #5310 00:27
nemokosch do you think it would be reasonably doable to eliminate the special behavior of "thunky" operators, going down the RakuAST route? 09:41
leont Except it turns out Version objects are already sometimes not versions but version patterns? (but they still sort to not break it completely?) I don't understand where hacks like this keep coming from; it would be like saying "Nums can now also be complex values" and expect that to be fine. 11:26
vrurg leont: I've probably missed the reset of the discussion. What worries you? 13:28
leont A version object is not necessary a version. E.g. v1.* is not a version by any reasonable definition; you can't have a package whose version is v1.* 13:32
vrurg This is clear, but it feels like there is context I don't know about. 13:33
leont It's all a violation of the Single Responsibility Principle 13:34
vrurg If there is nothing else, then at least I for myself know where ti comes from: the syntax. It would still depend on expectations of an individual, but v1.1 and v1.* producing objects of different types may break other expectations. 13:37
leont If Version does Version::Matcher, then it would all work sensibly enough 13:39
vrurg For example, to me things like ^v1.3 make little sense because I don't understand where v1.2.1 would fit into this sequence? It's like iterating over a Rat or Num. 13:40
leont Yeah, iterating over version ranges makes no sense
But comparing should be easy enough 13:41
vrurg What would Version::Matcher change from API point of view? For an end-user it would remain the same Version.
leont Invariants. The different classes can all guarantee their own invariants. 13:42
vrurg I'm afraid, this is where examples would help me more. 13:45
leont "Does this Version object have a value that I can use as a version of something" 13:46
Right now we kind of need an is-version method :-/ 13:47
vrurg Ah, you mean not `class Version does Version::Matcher` but Version::Matcher as a mixin? 13:49
If so, I barely see it ever changing because of too few gains over too many backward compatibility problems. 13:50
leont I think I meant the former, but I'm not entirely sure I understand what you meant with the latter. 13:52
Any v expression would generate a Version::Matcher, which may be a Version
vrurg Then forget the latter as irrelevant. I'm rather interested in getting your point. 13:53
From this point of view the approach would be akin to Stringy: Versionish role consumed by Version and Version::Matcher (though better name is needed then) classes. 13:55
leont Yeah something like that
vrurg I'd like it in general. But, again, it'd bee too much even for a language release bump. These kind of things are like the fundamental genes which do not change for many millions years. 13:57
leont Yeah probably 13:59
vrurg wonders if Promise lacks of methods 'andthen' and 'orelse'... 14:34
nemokosch lol 14:38
I'm more wondering if "andthen" and "orelse" should whatever-curry or not 14:39
for &&, || and ~~ it seems pretty obvious that they better should
leont What I really want is a then that automatically awaits the promise. It would save me a line on almost any then handler. That may or may not be what you mean with andthen 14:46
(my question is basically what does it do with a failed promise) 14:47
vrurg I'd rather expect a broken one to be bypassed down the stream. 14:50
I'd rather expect a broken one to be bypassed down the stream. 14:51
The point is in preserving the original cause.
leont Yeah, makes sense

Powered by Cro and the Raku® Programming Language.

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

Thank you!