🦋 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.
00:17 sena_kun left 00:58 notna joined
MasterDuke huh. just reverting the src/Raku/ast/name.rakumod part of 196fbee doesn't unbreak the jvm build. didn't expect that 01:13
01:13 notna left 01:14 notna joined 01:16 notna left 01:26 notna joined 02:04 notna left
Geth rakudo: MasterDuke17++ created pull request #5544:
Unbreak the JVM build		 02:45
ab5tract borretti.me/article/type-inference...-a-mistake 09:29
(from: lobste.rs/s/pkgjno/type_inference_was_mistake) 09:30
Is type inference being used synonymously with gradual typing here? 09:31
nine Not really, though they do share some problems. 10:04
One of the things Python got right is the mantra that explicit is better than implicit. Of course they then screwed it up by ignoring their own mantra basically everywhere. But at least they had the right idea. 10:06
FWIW I have come to a similar conclusion as that author. 10:11
OTOH I kinda like that I can just write: val response = basicRequest.post(url).body(write(...Response])
and not have to type this monster: val response: sttp.client3.RequestT[Identity, Either[ ResponseException[String, Exception], SingularResponse[CreateAsyncReportResponseValue]], Any] = basicRequest.post(url).body(write(...Response]) 10:12
ab5tract indeed :)
nine On the other hand type aliases make that problem go away almost as well: val repsonse: APIResponse = basicRequest...
And I actually needed that type alias anyway as I wanted to pass that response around. 10:13
And I guess if type inference weren't as common in Scala, library authors would take more care in making such type aliases available or easier to create. 10:14
ab5tract I'm writing Java at $work and I've gotten more used to it but... damn is it verbose ... and processing JSON? .. not fun
nine On that tangent, it does look awful at first glance and boy do I wish there was better documentation with more examples for sttp but once you're past that it's damn, the compiler is happy, so you basically know that the code is, too. And this includes handling the different formats you may get for error responses. 10:16
The place where I really like type inference though is for the real functional workhorses like map: Array[Int].new(1, 2, 3).map(_ + 1) // gives (2, 3, 4) 10:23
ab5tract so how does all of this intersect with the way we do things in Raku land? 10:27
(in terms of your happiness / unhappiness with type inferences) 10:29
nine I don't think it does. Raku doesn't do type inference at all as it's not a statically typed language. It still has the same problems though as from my $a = foo; alone you simply cannot know what type $a has. 10:31
ab5tract Well that was what I was trying to get at. If those problems have pushed you to dislike type inference, then I would (perhaps wrongly) presume that those same problems would push you to dislike gradual typing 10:36
If so, what can we do about it? And if not, how can we advertise those successes in contrast to type inference? 10:38
If it's just the question of (Java) `var x = someFunction();` and (Raku) `my $x = some-function;` then it seems to be a a pretty limited issue 10:41
in the Java case, the IDE will usually force the type description into the space where you would have typed it out anyway, so I usually just go the long route 10:42
nine Well, yes, I do have indeed found a new appreciation for statically typed languages in the past 2 years. Enough that I would if in doubt pick one over any dynamically or gradually typed language. 10:45
The code examples above are Scala btw. which ticks a lot of boxes for me. Doesn't mean it's perfect as I e.g. miss having real type objects or typed undefined values. But I can recommend anyone curious to have a look at it. 10:46
ab5tract are you on Scala 3? 10:48
I ask because I started to poke at Scala a while back and the 2/3 divide still seemed pretty severe 10:49
10:51 sena_kun joined
nine Nah, Scala 2 due to Spark. But I have looked at a Scala 3 upgrade and it would actually be possible. The Scala compiler understands both language versions, so you can mix. There are also automated tools to upgrade your code and again, since it's statically typed, those can actually do a thorough job. 10:52
ab5tract that definitely makes it sound like one would need to know both 2 and 3 (or just 2) in order to be fluent 10:54
nine Yes. But then it's not like they are really different languages. Things like parenthesis in if statements becoming optional won't trip you up :) 11:00
To not make this too one sided, there are a lot of other features that Raku has had way before Scala 3 picked them up :) Like first class coercion types or fully integrated delegation 11:03
ab5tract I choose to read the above statement as "Raku wins!" :) 11:36
nine Does anyone know why parameterization of constants, i.e. my Int constant @a = Array[Int].new; is forbidden? 11:55
lizmat no, but why would you? the Array[Int].new would be enough 12:01
but more generally: I just think the grammar doesn't allow it 12:02
m: my Int constant @a = Array[Int].new
camelia ===SORRY!=== Error while compiling <tmp>
Parameterization of constants is forbidden
at <tmp>:1
------> my Int constant @a = Array[Int].new⏏<EOL>
lizmat could probably be fixed in the Raku grammar, with a compile-time typecheck 12:03
similar to:
m: my Int $a is default("foo")
camelia ===SORRY!=== Error while compiling <tmp>
Default value 'foo' will never bind to a variable of type Int
at <tmp>:1
------> my Int $a is default("foo")⏏<EOL>
expecting any of:
constraint
Geth rakudo/main: e6a28e1cb2 | (Elizabeth Mattijsen)++ | src/core.c/allomorphs.rakumod
Add Allomorph.narrow

To narrow the value of any allomorph to its numeric part.
Spotted by habere-et-disper++		 12:12
nine lizmat: the actions explicitly prohibit it. It'd be easy to support. In fact I had support in RakuAST ready before I realized that it's prohibited. It even has its own exception type, so that was quite deliberate. I just don't know why. 12:17
lizmat possibly an issue with Parrot ?
then, I mean 12:18
how old is the exception class?
nine 2018, introduced by zoffix 12:19
ab5tract I can't find any relevant issues in closed or open 12:36
lizmat: it looks like blin presupposes a commit to the main branch as it relies on whateverable's builds 12:37
searching through issues I found this: R#4534.. more parameter pain :( 12:40
linkable6 R#4534 [open]: github.com/rakudo/rakudo/issues/4534 Capture coercers wrongfully treat all pairs as named arguments
ab5tract this one is also kind of interesting... R#1587 12:55
linkable6 R#1587 [open]: github.com/rakudo/rakudo/issues/1587 `my Int constant .= new: 42` doesn't crash
ab5tract that one I can at least put a `Fixed in RakuAST` badge on :) 12:56
lizmat :-)
ab5tract nine: I think this might be the associated issue zoffix was working on: R#1503 13:01
linkable6 R#1503 [closed]: github.com/rakudo/rakudo/issues/1503 Type constraints on constants not implemented
ab5tract based on this comment (github.com/rakudo/rakudo/issues/15...401116405) which links to this commit (github.com/rakudo/rakudo/commit/a1...768027535) 13:02
something about a CaR grant, but zoffix helpfully removed all CaR grant labels from tickets he had associated with the car grant 13:04
lizmat: do you have any objections to me merging R#5543? since as I mentioned above, there's not direct way to blin a branch anyway 13:19
linkable6 R#5543 [open]: github.com/rakudo/rakudo/pull/5543 Add multi disambiguation for positional scalars 13:20
Geth rakudo/main: d1fbc0d707 | (Elizabeth Mattijsen)++ | src/Perl6/Metamodel/ClassHOW.nqp
Streamline Metamodel::ClassHOW (Part 1/N)

  - remove is_pun attribute for nqp::isnull check		 13:22
lizmat ab5tract: go for it! 13:23
Geth rakudo/main: ff08bcde7e | ab5tract++ | src/vm/moar/dispatchers.nqp
Add multi disambiguation for positional scalars

Until now there has been no way to capture the use of $[]
  (as opposed to []) by the caller of a multi routine.
For example:
   multi sub($a where *.elems > 0) {...}
... (33 more lines)		 13:27
rakudo/main: da2d9069ee | ab5tract++ | src/Perl6/bootstrap.c/BOOTSTRAP.nqp
Add multi positional scalar disambiguation to legacy dispatch
rakudo/main: 10 commits pushed by (Stefan Seifert)++
review: github.com/rakudo/rakudo/compare/d...fe36fb404f		 13:31
nine That was one hard earned spec test file (t/spec/MISC/misc.t) 13:34
lizmat nine++ ab5tract++
ab5tract misc.t sounds painfully random 13:39
nine Surprisingly it was only 2 categories of errors. One related to ARGFILES in MAIN and then a whole lot of issues around definite type constraints like my Int:D $i .= new: 69 13:52
lizmat m: multi a(Positional $a) { dd }; multi a(@a) { dd }; a $(1,2,3); a $[1,2,3] # ab5tract shouldn't that go to the same candidate ?
camelia sub a(@a)
sub a(Positional $a)
ab5tract I didn’t include $(), no 13:55
I suppose that could lead to confusion, but I was also concerned about keeping the affected surface area small 13:56
Might have gotten the balance wrong there
lizmat well, wrt to splice, I feel this is now more confusing
sorry I missed that in the PR :-( 13:57
ab5tract Let’s see if it’s an easy fix 13:58
nine FWIW I'm pretty skeptical of the whole idea. As I understand Raku @a and Positional $a are equivalent
lizmat about the syntax, or more generally ? 14:01
ab5tract But in practice there are times when one wants to distinguish between them
Which is literally the only time one would put them both into competing multi sigs 14:02
nine I'm curious: what are those times? 14:03
lizmat github.com/rakudo/rakudo/issues/5500 14:04
nine What makes splice flatten so agressively in the first place? 14:06
ab5tract A combination of factors. One is that it supports both `**@args` and `@arg` 14:09
but the essential feature is that it inserts elements of whatever list is passed to it one by one 14:10
that is, element by element
so it will never DWIM for $[<e x>] without some means of disambiguating $[] from [] 14:11
FWIW I have encountered this situation in my own code before, though the specifics elude me at the moment 14:12
Geth nqp/main: 1ca2f18b76 | (Elizabeth Mattijsen)++ | src/how/NQPClassHOW.nqp
Add "code_of_method" and "declares_method" methods

to NQPClassHOW.
  - declares_method returns 1 if there's a method by that name in
   the method table (effectively wrapping an nqp::existskey)
  - code_of_method returns the code object of the method by the given
... (8 more lines)		 14:15
ab5tract regarding aggressiving flattening, I think it's a good question that extends to other use cases: 14:21
m: sub a(@a) { dd @a }; a([[[<q e d>]]])
camelia ["q", "e", "d"]
ab5tract I'm sure there was a strong motivation for why that happens per the single arg rule. But I certainly can't remember it now 14:22
Geth rakudo: ab5tract++ created pull request #5545:
Use positional scalar disambiguation for Array.splice dispatch		 14:46
ab5tract I hadn't actually had time to run spectests for the addtion of `$()` yet, so there may be some surprises there 14:48
afk&
15:32 coleman left
nine But splice(@a, 0, 1, @b) does not have a single arg, so that rune cannot apply. 15:32
15:33 coleman joined
ab5tract m: sub a($, @a) { dd @a }; a *, [[[<u f o>]]] 16:13
camelia ["u", "f", "o"]
ab5tract It’s a single arg as far as the parameter / in scope constructor is concerned, I guess? 16:16
(My relative lack of knowledge about how captures match to parameters and become Thingies in the routine is showing :)) 16:26
MasterDuke nine: is github.com/rakudo/rakudo/commit/19...85cf89R217 the only place that would need to explicitly call the renamed-from-new multi in Pseudostash? 16:31
ab5tract: did you see the errors in github.com/rakudo/rakudo/pull/5545? it does not like removing `$value` here github.com/rakudo/rakudo/pull/5545...e8c5eL2622 16:33
ab5tract Ah, that’s an accident for sure 16:45
nine MasterDuke: yes 17:16
m: sub a($, @a) { dd @a }; a *, [[[<u f o>,],],] 17:17
camelia [[[("u", "f", "o"),],],]
Geth rakudo/main: de40bd114b | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to get code_of_method/declares_method methods

in NQPClassHOW, so they can be used transparently in Raku's metamodel		 17:18
nine I'm getting more and more convinced that splice is just buggy. It should not flatten that array. 17:20
ab5tract if you do [[<a b>],] , it of course does not 17:21
lizmat nine: that may well be, but pretty sure we will need a language version bump to fix that 17:22
because there are a. spectests depending on it, and b: ecosystem modules most likely as well 17:23
ab5tract I've been poking at it pretty comprehensively and there's no bug, there is just single arging
*no bug that I've seens
MasterDuke nine: is there a simple way to test that my attempt at turning those PseudoStash multi news into a singular new + some other method is correct? i.e., some test or spectest or piece of code i can run with the moarvm backend 17:26
github.com/rakudo/rakudo/pull/5544 updated with a wip attempt at nine++'s suggestion 17:41
ab5tract to hopefully be more clear, when I say "just single arging" I mean behaving as any other sub which takes an @pos param behaves. 17:43
and since it has slurpy candidates, there is no difference between splice(@a, *, *, [1, 2, 3]) and splice(@a, *, *, 1, 2, 3) 17:45
the latter re-dispatches to the former 17:46
nine But those should surely be different things?
ab5tract not according to the spec and the implementation 17:47
nine They could just both be wrong. Wouldnt be the first time 17:48
ab5tract according to user expectations, I agree. which is why I've spent the time to provide a way out that keeps the existing model intact
Geth nqp/main: b644c8ed3a | (Elizabeth Mattijsen)++ | 2 files
Add "code_of_method" and "declares_method" methods

to NQPConcreteRoleHOW and NQPParametricRoleHOW as well		 17:50
MasterDuke somewhat off-tangent thought, but should we add a CI job that runs `RAKUDO_RAKUAST=1 make m-test` and `RAKUDO_RAKUAST=1 make m-spectest` and just records the results? 17:52
but for now, afk to dye eggs
ab5tract we could get away with keeping separate implementations for slurpy and non-slurpy, but if we want a single implementation then there wouldn't be a way to pass the slurpy array to the regular array candidate without it the slurpy array becoming a single element in the re-written regular array candidate 17:54
unless, of course, there were a way to pass $[] and [] to different candidates ;) 17:55
On second thought, even that distinction wouldn’t help without some contortions 18:07
Geth MoarVM-Remote/main: 81ed891d7d | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | README.md
Update README.md
 22:07
22:47 sena_kun left
MasterDuke looks like the latest commit to github.com/rakudo/rakudo/pull/5544 worked, but i'd appreciate some naming suggestions before i squash and merge 23:14
23:35 kjp left 23:38 kjp 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!