00:00 reportable6 left 00:03 reportable6 joined 00:13 jpn joined 00:18 jpn left 00:39 jrjsmrtn left 00:47 jrjsmrtn joined, rba left 00:48 rba joined 01:08 hulk joined 01:10 kylese left 01:14 jpn joined 01:19 jpn left 02:15 hulk left, jpn joined, kylese joined 02:20 jpn left 02:44 MasterDuke joined 03:16 jpn joined 03:26 jpn left 04:17 jpn joined 04:23 jpn left 04:49 squashable6 left 04:50 squashable6 joined 05:07 zara joined 05:18 jpn joined 05:23 jpn left 05:30 Sgeo left 06:00 reportable6 left 06:01 reportable6 joined 06:03 jpn joined 06:08 jpn left 06:11 zara left 06:15 MasterDuke left 06:30 jpn joined 06:37 jpn left 06:48 sena_kun joined 06:50 abraxxa joined 06:57 sena_kun left 08:15 haxxelotto joined 08:49 sena_kun joined 09:38 jpn joined
Geth docker: 4789a2e098 | (Daniel Mita)++ | 4 files
Bump to 2024.04
 09:46
docker: 486b7ff750 | Altai-man++ (committed using GitHub Web editor) | 4 files
Merge pull request #65 from m-dango/2024.04

Bump to 2024.04
09:53 basilosaurus joined 09:55 basilosaurus left 10:41 vms14_ joined 10:43 vms14__ joined, vms14 left 10:46 vms14_ left 11:23 vms14__ left 11:24 vms14 joined 11:39 jpn left 11:45 jpn joined 11:47 vms14_ joined 11:48 vms14_ left, vms14 left, vms14 joined 11:51 jpn left 11:59 jpn joined 12:00 reportable6 left 12:02 reportable6 joined 12:18 jpn left 12:19 jpn joined
librasteve I have pondered this ... and come to the view that (i) the current design is intended to delegate the typecheck computational load on the Array[Int] so that the default is for that to be done when the array is first loaded, or to be spread item by item eg in a gather take which are the "times of least surprise" and (ii) that coercion can do the job like this: 12:21
m: sub baz(ArrayInt $ints) { say 'yo' }; baz [1,2,3];
evalable6 (exit code 1) 4===SORRY!4=== Er…
Raku eval yo
evalable6 librasteve, Full output: gist.github.com/6becc8af3615f97b1f...a366af72f1
librasteve ^^ note the $ sigil 12:22
12:22 hudo joined 12:32 jmcgnh left 12:38 haxxelotto_ joined 12:39 haxxelotto left 12:50 jmcgnh joined 12:51 thaewrapt left 12:54 sftp left 13:24 thaewrapt joined 13:30 sftp joined 13:31 Altai-man joined 13:34 sena_kun left 13:43 Sgeo joined 13:47 vms14 left, vms14_ joined 14:04 vms14_ left
antononcube @lizmat Sorry to by pushy but what is the status of "Algorithm::Diff" ? Did it become a "community module"? 14:09
Agh, yes it did -- raku.land/zef:raku-community-modul...ithm::Diff 14:10
14:12 zara joined 14:15 linkable6_ left, linkable6_ joined
[Coke] is the README from that lifted directly from the perl module of the same name? 14:22
ah, looks like 14:23
[Coke] goes to submit a PR and sees lizmat already fixed a thing
antononcube I think the signatures should be changed kebab-case not snake_case. 14:31
The original module did not produce expected results a week or so ago. I will check if lizmat's version has fixed those. 14:32
[Coke] Tests pass. 14:33
antononcube Yeah, tests were passing a week or so ago, but the results did not correspond to what was exemplified in the documentation. 14:34
14:39 zara left 15:39 abraxxa left 16:02 jpn left
roguerakudev I’m generally not a fan of using the scalar sigil on things that aren’t actually scalars unless I’m wanting them to be treated like a single item 16:23
idk, all these workarounds, well, work - but they all feel a bit dirty 16:24
As far as principle of least surprise, I think most people would find it surprising to be unable to pass an array of what are clearly ints into a routine’s Int-typed @-sigiled paramagnetic 16:25
Parameter* autocomplete got me 16:26
lizmat antononcube please make an issue if you haven't already? 16:28
[Coke] roguerakudev - I believe there is already a problem solving issue for that. 16:38
[Coke] digs through github.com/Raku/problem-solving/is...en+array++ but doesn't find one. 16:39
ab5tract roguerakudev: I actually agree with you as I've bumped into this a number of times ... but If you haven't specified the type of the array, the array needs to be fully scanned to see if its contents conform to the type specified by the parameter
and it would have to happen each time the array changes (or maybe even every time perioed), because changing an array to array of int just because it happens to only contain ints at the time of one call to a routine with signature Array[Int] is *also* an easy source of confusion/consternation 16:41
even coercions are tricky, because Nums will coerce to Ints but that doesn't mean you wanted [1.2, 3.4, 5.5] to land in a routine that asked for an array of Int() 16:44
roguerakudev This quickly becomes a hard problem, huh 16:45
librasteve this 16:46
roguerakudev I wonder if it even makes sense for 5.5.Int to work the way it does rather than failing
librasteve yeah the coercion is definitely dirty 16:47
m: say [1,2].are
evalable6 (Int)
Raku eval (Int)
librasteve m: say [1,2.0].are 16:48
evalable6 (Real)
Raku eval (Real)
librasteve m: say [1,2,'a'].are
evalable6 (Cool)
Raku eval (Cool)
ab5tract I think the way coercions work is totally fine, to be honest. It's in the nature of it to be a lossy operation 16:49
[Coke] m: dd (1,2.5,3.0).map(*.narrow) 16:50
camelia (1, 2.5, 3).Seq
librasteve ^^ just chucking this thought in - there is a very nice class hierarchy - so just need somehow to call .are on the argument (behind the scenes) 16:51
[Coke] (we don't want arrays to narrow by default anywhere, but I just think it's neat </marge>)
roguerakudev I feel like there’s a missing middle ground with coercions, because sometimes what you want is “convert if it can be done without loss”
ab5tract librasteve: but that's back to the "we have to scan the whole array every time" .. unless we would keep track of that as a flag on the array.. hmmm 16:52
roguerakudev Yeah potentially you could keep a single “narrowest common type” state and update then when something new is written, but then what do you do when items are removed 16:53
librasteve coercions are fine ... by my application of them to rog's point is dirty (and has holes as you have pointed out)
16:54 hudo_ joined
/by/but/ 16:54
roguerakudev update that*
ab5tract ah ,gotcha :)
16:55 hudo_ left
roguerakudev But maybe scanning the whole array is okay, and those concerned about performance can add type constraints on the calling side if they need 16:57
16:57 hudo_ joined, hudo left
librasteve that's the raku way, for sure 16:57
roguerakudev Yeah, it would line up well with the philosophy 16:58
librasteve (well the raku way is that there is no raku way)
roguerakudev Rats aren’t as performant as floating points but we default to then anyway for less surprise/convenience 16:59
I mean that as in (less surprise)/convenience :^)
antononcube @lizmat and @Coke I submitted a PR for "Algorithm::Diff" -- the examples in PR's message should illustrate well enough why its fixes are needed. (Basically, without them "Algorithm::Diff" is useless.) 17:02
librasteve so (in a transparent way) :( Int @a ) first looks for a declared Array[Int] and then checks if .are ~~ Int which is a scan 17:03
roguerakudev I like the way of thinking about type constraints where it applies to the element(s) inside the container, whatever shape that container might have
ab5tract I think asking the writer of the signature to explicitly demonstrate that they wish to scan the whole array is a far more Raku-like solution.. all you have to do is where *.are ~~ Int
librasteve yes - could do the same for Hash values
roguerakudev And generally that conceptualization works, but it doesn’t when it comes to passing things to callables
ab5tract if you are passing a callable to a routine that wants an array of something, you probably shouldn't be surprised when it fails :) 17:04
roguerakudev Sorry, that was maybe poorly written on my part 17:05
ab5tract but flippancy aside, I'm curious to know more roguerakudev
roguerakudev I mean it works until you start thinking about signatures
for example, consider that my Int @ints = @untyped-array; works fine 17:06
and I know the underlying reason is that what happens for signatures is binding, not assignment, e.g. := vs. = 17:07
but from a naïve perspective it's surprising to see that difference in behavior
ab5tract yeah, I'm working on a bug realted to that right know R#5175 17:08
linkable6 R#5175 [open]: github.com/rakudo/rakudo/issues/5175 where-clause in subset does not work with Block/Callable
roguerakudev and I think it would be "nice" or "neat" if we could always think of constraints as applying on the elements of the container as stated above
17:09 linkable6_ left
or maybe s/always/by default/ 17:10
obviously that has to be breakable with my Type @something is Something 17:11
17:11 linkable6_ joined
when I said "passing things to callables" I just meant passing things as parameters in general, not to a Callable parameter 17:11
ab5tract that honestly sounds so confusing. what's wrong with *.map ~~ ThingImChecking 17:12
sorry, *.map: { $_ ~~ ThingImChecking }
roguerakudev It just feels needlessly roundabout I suppose?
the reason I say this thing about constraints applying on elements is that we don't do my Array[Int] @ints for an array of ints, but rather my Int @ints 17:14
to me that behavior implies that the type constraint is not a constraint on the container as a whole, but rather on the contained elements (whatever the structure of the container may be - same applies for hashes and with slightly different logic to callables) 17:15
taking callables into consideration, maybe a better phrasing is "the type constraint constrains what sort of element(s) we'll get out of this thing" 17:16
whether it be the values in a hash or the return value of some code 17:17
etc.
17:17 hudo joined
ab5tract m: my Int @a = 1,2,3; sub s(Int @a) { dd :@a }; s @a 17:18
camelia :a(Array[Int].new(1, 2, 3))
17:18 hudo left
ab5tract it looks like parity to me? 17:18
I guess I'm still missing your main gist :/ 17:19
17:20 hudo joined, hudo_ left
roguerakudev Hm, I suppose what I'm saying is, if we start learning "how Raku works" at a conceptual level by seeing that we can assign, as in your example, a literal with no explicit type (1, 2, 3 is never labeled as List[Int]) into a type-constrained container 17:22
that makes being unable to pass 1, 2, 3 directly into your sub s surprising 17:23
again as more experienced devs we know that the underlying difference is essentially the difference between assignment and binding
but it still feels gotcha-ish
ab5tract that I do agree with 17:24
roguerakudev because being able to assign 1, 2, 3 into my Int @a implies what I was saying before about the constraint working on elements rather than the whole container
so if type constraints conceptually constrain what we can get out of (and sometimes put into) various containers, why should that logic stop working at the boundary of calling some routine 17:25
ab5tract we do somehow manage it here.. 17:26
m: my Int @a = [1,2,3]; sub s(Int @a) { dd :@a }; s @a
camelia :a(Array[Int].new(1, 2, 3))
[Coke] isn't the key difference checking at assignment time versus runtime? 17:27
ab5tract roguerakudev: I'd be interested in what dicussions might come out of a problem solving ticket
m: my $two = 2; my Int @a = [1,$two,3]; sub s(Int @a) { dd :@a }; s @a 17:28
camelia :a(Array[Int].new(1, 2, 3))
roguerakudev Yeah, I may open one up and try to phrase what I've said a little more clearly/concisely :)
[Coke] +1
ab5tract [Coke]: yeah, I'd have to look into what's happening in the grammar/actions for the assignment case. 17:31
[Coke] Would love to see a page in the docs about this, esp. if we can point to any performance improvements for the typed version. (I'm sure the calling is faster with strictly typed, but I'm wondering if the memory usage or array access is better for a typed version. Esp. if native typed) 17:35
m: my int @a = [1,2,3]; sub s(int @a) { dd :@a}; s @a;
camelia :a(array[int].new(1, 2, 3))
librasteve +2 on the problem solving ticket 17:40
roguerakudev github.com/Raku/problem-solving/issues/426 17:58
18:00 reportable6 left 18:01 reportable6 joined
ugexe m: sub foo(Int @a) { say @a.raku }; my Int @foo = 1,2,3; foo(@foo.grep(* > 2)) 18:04
camelia Type check failed in binding to parameter '@a'; expected Positional[Int] but got Seq ((3,).Seq)
in sub foo at <tmp> line 1
in block <unit> at <tmp> line 1
ugexe i thikn that is how i usually run into it
18:14 haxxelotto_ left
librasteve yeah, I get a lot of jarring from Array degenerating to Seq too ... but I have always thought this was a necessary sacrifice to the lazy gods ... and adding an | or .flat or .Array or .list is a bit of a minefield 18:20
m: sub foo(@a) { say @a.raku }; my Int @foo = 1,2,3; foo([@foo.grep(* > 2)]) 18:25
evalable6 [3]
Raku eval [3]
librasteve just noodling on extending circumfix [] maybe to [].Int ... 18:28
roguerakudev as another lesson in "everybody wants the colon", maybe new syntax that doesn't look method-callish would be preferable, e.g. [Int: 1, 2, 3] 18:29
librasteve arrrrgh - Rust
roguerakudev I'm sure there's already some other meaning for that syntax, though
[Coke] m: dd [Int: 1, 2, 3]
camelia [1, 2, 3]
roguerakudev fascinating... I would have expected something different, maybe an error 18:30
m: dd(Int: 2)
evalable6 (exit code 1) No such method 'dd' for invocant of type 'Int'
in block <unit> at /tmp/Q9Xdz3hOjB line 1
Raku eval Exit code: 1 No such method 'dd' for invocant of type 'Int' in block <unit> at main.raku line 1
librasteve itsa label
roguerakudev Ahh, righto 18:31
Well, label inside array doesn't make a whole ton of sense, so maybe it's viable
sadly any syntax for this doesn't solve the non-compile-time case, though
18:35 haxxelotto_ joined
librasteve true that - tweaking literal [] or maybe circumfix [] is more a case of pragmatism vs. adjusting the type system (and nothing I saw here yet makes me think that there is a path between Array[Int] and Array and ArrayInt that solves this concern) 18:36
sub foo(Int[] @a) { say @a.raku }; my Int @foo = 1,2,3; foo(@foo.grep(* > 2)) maybe? 18:41
^^ extend coercion syntax to play nice with array items 18:44
(good job I didn't pin my career as a langiage designer - this is hard!) 18:45
&afk
dr.shuppet It's mostly that having both typeless arrays (Array) like in Perl or Python and typed arrays (Array[something]) like in Haskell is a syntactically tricky 18:52
IMO using $ as the sigil for typed arrays is fine, it's a different type of object than what @ is used for 18:54
roguerakudev I want to say that Array is still technically typed, just with Mu... it does descend from Positional which has a type parameter that defaults to Mu 19:04
I'm not sure whether that's true and it displays as Array instead of Array[Mu] because someone simplified that serialization, or whether there truly is a distinction 19:05
Come to think of it, I don't know how type parameters get inherited... if I did, this question would probably answer itself 19:06
dr.shuppet Can't you easily check that?
m: say Array[Mu]
evalable6 (Array[Mu])
Raku eval (Array[Mu])
roguerakudev ah, very good point
gfldex m: say Array ~~ Array[Mu]
camelia False
gfldex Array is simply older then parameterised roles. If we would have had it in the beginning of Perl 6, it would have been a good idea to use that generalisation. 19:07
dr.shuppet Perhaps yes, having a parameterless Array is also fine IMO, it keeps things simple 19:08
roguerakudev maybe bringing that into alignment would be a worthy corrolary to tack onto this type-constrained parameters discussion should anything come of it...
gfldex In fact, typed Arrays are still partly NYI. Same for fixed sized Arrays. That's why it's a good idea to always `use v6.d`. 19:09
roguerakudev looking at Array.rakumod doesn't reveal much - github.com/rakudo/rakudo/blob/881c...rakumod#L8
Array ~~ List yet this definition doesn't have is List, though there is a comment with it...
I could quickly drive myself insane peering through rakudo's source, though :^) 19:11
dr.shuppet m: say Array.^parents 19:12
evalable6 ((List))
Raku eval ((List))
dr.shuppet Back to the array typing issue: if we are fine with runtime checking, we can do something like this: 19:21
m: use MONKEY-TYPING; augment class Array { method typed { Array[self[0].WHAT].new(|self) } } say [1, 2, 3].WHAT; say [1, 2, 3].typed.WHAT; 19:22
evalable6 (exit code 1) 4===SORRY!4=== Er…
Raku eval (Array) (Array[Int])
evalable6 dr.shuppet, Full output: gist.github.com/e1613c809e934f752f...8e01a3fcc8
[Coke] Don't like having two eval bots responding. 19:28
dr.shuppet Also not a fan of that, especially when one of them evaluates a broken version of the code and fails... 19:29
[Coke] I assume there's a newline in the discord send? 19:36
dr.shuppet [Coke]: Multiple newlines actually. If they were turned into spaces, it would execute correctly 19:38
ugexe no, newlines need to end with a ; if they are going to be turned into one line
m: sub foo() { } say 42 19:39
camelia ===SORRY!=== Error while compiling <tmp>
Strange text after block (missing semicolon or comma?)
at <tmp>:1
------> sub foo() { }⏏ say 42
expecting any of:
infix
infix stopper
statement end
…
ugexe m: sub foo() { }; say 42
camelia 42
[Coke] didn't we use to have one eval for each side of the bridge that ignored the other side? 19:40
dr.shuppet I think yes, IIRC it didn't do the double eval like two weeks ago? 19:41
roguerakudev That's weird, because I haven't changed anything 19:42
maybe Discord's API changed a bit
dr.shuppet It might have been because I used eval on a channel that is not bridged to IRC
roguerakudev nah people have been doing that for a long time 19:43
dr.shuppet ugexe: You are right of course, actually, it does turn newlines into spaces 19:44
At least it looks like that in Discord
19:57 Altai-man left 19:59 sena_kun joined 20:10 thaewrapt left 20:11 thaewrapt joined 20:13 thaewrapt left, thaewrapt joined 20:14 thaewrapt left 20:25 thaewrapt joined 20:52 jpn joined 21:23 squashable6 left 21:26 squashable6 joined
whistlingzephyr is evalable6 a new IRC bot? iirc only camelia used to eval before 22:02
while evalable6 seems to be picking up eval commands from Discord without proper formatting
22:22 jpn left 22:36 MasterDuke joined 23:06 sena_kun left

Powered by Cro and the Raku® Programming Language.

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

Thank you!