#raku


|<   <<<   <<   <   22 September 2021   >   >>   >>>   >|
Search 
Live Today I feel lucky Raw Index Home

§ 00:03 reportable6 left 00:05 reportable6 joined 00:09 _73 left
¦ setup-raku/dependabot/npm_and_yarn/tmpl-1.0.5: 86c89395cb | dependabot[bot]++ (committed using GitHub Web editor) | package-lock.json
   Bump tmpl from 1.0.4 to 1.0.5
  
   Bumps [tmpl](
https://github.com/daaku/nodejs-tmpl) from 1.0.4 to 1.0.5.
   - [Release notes](https://github.com/daaku/nodejs-tmpl/releases)
   - [Commits](https://github.com/daaku/nodejs-tmpl/commits/v1.0.5)
  
   ---
   <…commit message has 6 more lines…>
   review: https://github.com/Raku/setup-raku/commit/86c89395cb
00:13
¦ setup-raku: dependabot[bot]++ created pull request #16: Bump tmpl from 1.0.4 to 1.0.5
   review:
https://github.com/Raku/setup-raku/pull/16
¦ setup-raku: 86c89395cb | dependabot[bot]++ (committed using GitHub Web editor) | package-lock.json
   Bump tmpl from 1.0.4 to 1.0.5
  
   Bumps [tmpl](
https://github.com/daaku/nodejs-tmpl) from 1.0.4 to 1.0.5.
   - [Release notes](https://github.com/daaku/nodejs-tmpl/releases)
   - [Commits](https://github.com/daaku/nodejs-tmpl/commits/v1.0.5)
  
   ---
   <…commit message has 6 more lines…>
   review: https://github.com/Raku/setup-raku/commit/86c89395cb
00:17
¦ setup-raku: 91e4c5aecb | (Shoichi Kaji)++ (committed using GitHub Web editor) | package-lock.json
   Merge pull request #16 from Raku/dependabot/npm_and_yarn/tmpl-1.0.5
  
   Bump tmpl from 1.0.4 to 1.0.5
   review:
https://github.com/Raku/setup-raku/commit/91e4c5aecb
00:18
§ 00:33 avarab joined, avar left 01:11 keutoi joined 01:27 greyrat joined, lucerne joined 02:06 squashable6 left 03:06 linkable6 left, evalable6 left 03:07 evalable6 joined, squashable6 joined 03:21 frost joined 03:25 justsomeguy joined 03:34 justsomeguy left 04:34 releasable6 left, statisfiable6 left, shareable6 left, squashable6 left, unicodable6 left, benchable6 left, committable6 left, quotable6 left, bisectable6 left, notable6 left, sourceable6 left, reportable6 left, nativecallable6 left, bloatable6 left, coverable6 left, evalable6 left, greppable6 left, tellable6 left, nativecallable6 joined 04:35 squashable6 joined, greppable6 joined, reportable6 joined, coverable6 joined 04:36 shareable6 joined, statisfiable6 joined 05:08 linkable6 joined 05:17 dustinm` left 05:21 dustinm` joined 05:34 evalable6 joined 05:35 committable6 joined, quotable6 joined 05:36 sourceable6 joined 06:02 reportable6 left 06:23 ufobat joined 06:36 bisectable6 joined, unicodable6 joined 06:37 bloatable6 joined
CIAvash §
m:
sub f ($a, :$b) { dd $a, $b; }; say &f.assuming(1, :b(2)).signature
07:06
camelia §
rakudo-moar ba15173fd: OUTPUT: «(:$b)␤»
CIAvash §
is this a bug or expected behavior?
§ 07:08 Sgeo left
moon-child §
m:
m: sub f ($a, :$b) { dd $a, $b; }; &f.assuming(1, :b(2))(b => 3)
07:09
camelia §
rakudo-moar ba15173fd: OUTPUT: «1␤3␤»
moon-child §
you can still override the 'b'
CIAvash §
I know, I'm just asking if that is a bug, because I was expecting `$b` to be removed from the signature, just like `$a` 07:11
moon-child §
yes, and I'm explaining why it's not. And optional key arguments are still part of the signature 07:12
s/And/because
you've assumed that b is 2, but you can still revisit that assumption later
CIAvash §
that doesn't explain why it's not a bug (at least to me), that's just explaining the current behavior 07:15
m:
sub f ($a, :$b!) { dd $a, $b; }; say &f.assuming(1, :b(2)).signature.params # not really optional
07:16
camelia §
rakudo-moar ba15173fd: OUTPUT: «(:$b)␤»
moon-child §
why do you say 'not really optional'? 07:18
and why do you expect b to be removed from the signature?
CIAvash §
because that one is not optional(notice the `!` after `:$b`). and because it was applied to the function. Otherwise what's the point of partially applying functions. 07:21
moon-child §
now that you've supplied a default value for b, it has become optional 07:23
m:
sub f ($a, :$b!) { dd $a, $b; }; my &g = &f.assuming(1, :b(2)); say &f.signature.params; say &g.signature.params; g(); g(:b(3))
07:24
camelia §
rakudo-moar ba15173fd: OUTPUT: «($a :$b!)␤1␤(:$b)␤2␤1␤3␤»
moon-child §
hmm, the output seems to have been interleaved
m:
sub f ($a, :$b!) { dd $a, $b; }; my &g = &f.assuming(1, :b(2)); say &f.signature.params; say &g.signature.params; g(); g(:b(3))
camelia §
rakudo-moar ba15173fd: OUTPUT: «($a :$b!)␤1␤(:$b)␤2␤1␤3␤»
CIAvash §
It's not about optional parameters, but about named ones 07:25
m:
sub f ($a, $b?) { dd $a, $b; }; say &f.assuming(1, 2).signature
camelia §
rakudo-moar ba15173fd: OUTPUT: «()␤»
moon-child §
yes, I understand
that doesn't clarify what problem you have with the current scheme 07:26
https://github.com/Raku/roast/blob/master/S06-currying/named.t#L29 does this clarify anything? 07:28
CIAvash §
that clarifies that it's not a bug, but it's still unexpected to me. 07:31
§ 07:34 tellable6 joined, releasable6 joined
moon-child §
so you expect that, given sub f(:$a) { }, &f.assuming(:a(7))(:a(8)) should be illegal? 07:35
§ 07:36 benchable6 joined
CIAvash §
yes, in other words, I expect the applied named parameter to be removed from the signature of the new function. Maybe my expectation is wrong, I don't know. 07:38
§ 07:39 tejr left 07:40 tejr joined
moon-child §
CIAvash: hmm, intuitively that didn't make sense to me, and I think I figured out a solid justification 07:47
given sub f(*@args) { @args }, &f.assuming(5, 6)(7, 8) will be [5, 6, 7, 8] 07:48
similarly, given sub f(*%args) { %args }, &f.assuming(a => 5)(b => 7) will be %(a => 5, b => 7)
so then, sub f(*%args) { %args<a> } would behave differently from sub f(:$a) { $a }, which would be inconsistent 07:49
CIAvash §
the difference is that the `.count` of functions with slurpy params is `Inf`, so you can never fully apply parameters. But you can with named params. 07:53
moon-child §
m:
sub f(*%args) {}; &f.count.say
07:55
camelia §
rakudo-moar ba15173fd: OUTPUT: «0␤»
moon-child §
regardless, it would be inconsistent
§ 08:00 simcop2387 left, perlbot left
CIAvash §
yeah, `.count` returns the number of positional arguments. still, doesn't make sense to me. 08:01
§ 08:04 reportable6 joined 08:07 tejr left, tejr joined 08:09 lichtkind joined 08:10 perlbot joined 08:12 dakkar joined, simcop2387 joined 08:15 archenoth left 08:22 lichtkind left 08:29 Xliff left
SmokeMachine §
CIAvash: I agree... that doesn't make much sense... if you provided :b, it should have been removed from the new signature. 08:32
at least in my mind
moon-child still finds the current behaviour obviously correct...¯\_(ツ)_/¯
08:34
SmokeMachine §
.assuming is providing a new default value for named parameters, that's not what .assuming should be doing, it should provide a value, not a default value 08:35
§ 08:36 lizmat_ joined, TempIRCLogger__ left, ufobat_ joined, gordonfish- joined
moon-child §
why 'should' that be what it does? 08:37
§ 08:37 lizmat left, [Coke]_ joined, unixcat64 left, TempIRCLogger joined
SmokeMachine §
it should, in my mind at least... 08:37
§ 08:37 sena_kun joined, unixcat647 joined, lizmat_ left, lizmat joined 08:38 gordonfish left, Geth left 08:39 Geth joined, [Coke] left, ufobat left
SmokeMachine §
(https://docs.raku.org/routine/assuming) 08:39
moon-child §
what do you think about this? 08:40
m:
sub f(:$x) { say $x }; f(x => 7, x => 8)
camelia §
rakudo-moar ba15173fd: OUTPUT: «8␤»
SmokeMachine §
moon-child: that makes sense...
moon-child §
my mental model of assuming is that &f.assuming(a)(b) is the same as f(a, b) 08:41
SmokeMachine §
I see that differently... in my mind, `f(x => 7, x => 8)` "colapses" when adding both on "the same hash". `.assuming` is returning a new function, and :x was already provided, so it shouldn't have :x on its signature... but I can accept the f(x => 7, x => 8) argument... do not agree, but accept... 08:44
CIAvash §
m:
sub f ($a, $b = 2) {}; say &f.assuming(1).signature
09:03
camelia §
rakudo-moar ba15173fd: OUTPUT: «($b?)␤»
CIAvash §
I don't know how to feel about this one either, it loses the default value
moon-child §
that's probably an oversight that will be corrected with rakuast 09:04
§ 09:07 lichtkind joined 09:31 eseyman joined 09:35 notable6 joined
Voldenet §
.assuming is cool, but there's little reason to use it over plain lambdas 09:45
m:
sub f ($a, $b = 2) { state $c = $a }; (&f.assuming(1))() for ^10; say now - BEGIN now
camelia §
rakudo-moar ba15173fd: OUTPUT: «0.308274192␤»
Voldenet §
m:
sub f ($a, $b = 2) { state $c = $a }; ->{ f(1) }() for ^10; say now - BEGIN now
09:46
camelia §
rakudo-moar ba15173fd: OUTPUT: «0.009272104␤»
§ 09:48 patrickb joined 10:23 holyghost joined 10:30 discord-raku-bot left, discord-raku-bot joined 10:42 JimmyZ joined 10:48 JimmyZ left 11:27 Xliff joined 11:36 JimmyZ joined 12:03 reportable6 left 12:04 reportable6 joined
SmokeMachine §
Voldenet: that's a reason I like the idea of `-> $a -> $b { $a + $b }` be equivalent of `-> $a { -> $b { $a + $b } }` 12:05
discord-raku-bot §
<Nemokosch#9980> what's the difference? the brackets? 12:10
SmokeMachine §
yes, but it makes it easier to read blocks returning blocks... 12:11
and if can be deeper: `-> $a -> $b, $c -> $d -> $e? { ... }` 12:12
it would be equivalent to `-> $a { -> $b, $c{ -> $d { -> $e? { ... } } } }` 12:14
sorry: `-> $a { -> $b, $c { -> $d { -> $e? { ... } } } }`
(I want to try to make a module implementing this anytime soon...) 12:19
grondilu §
lizmat: is this https://github.com/lizmat/Slang-Subscripts/blob/main/lib/Slang/Subscripts.rakumod still supposed to work? 12:35
oh nevermind it does seem to work 12:37
lizmat §
it did last time I checked ? :-) 12:45
grondilu §
"===SORRY!=== 12:55
Invalid to edge 0 in NFA statelist"
I have no idea what that^ means
Xliff §
sub publish-slang (\S) { $*LANG.define_slang: 'MAIN', $*LANG.slang_grammar('MAIN').^mixin: S; } 13:02
^^ Why is that NOT a good idea?
lizmat §
grondilu: /me neither
§ 13:04 evalable6 left, linkable6 left 13:21 JimmyZ left
Voldenet §
SmokeMachine: that syntax sounds good at first, but I thought about that and I'm sure that stack trace would not be too informative about currying (either too verbose or too terse) 13:56
§ 13:56 archenoth joined
Voldenet §
m:
sub f ($a) { }; sub curry(&f) { my @x; my sub curry(|c) { return f(|@x) unless c.elems; @x.push(|c); &curry }}; curry(&f)();
13:57
camelia §
rakudo-moar ba15173fd: OUTPUT: «Too few positionals passed; expected 1 argument but got 0␤ in sub f at <tmp> line 1␤ in sub curry at <tmp> line 1␤ in block <unit> at <tmp> line 1␤␤»
Voldenet §
m:
sub f ($a) { }; sub curry(&f) { my @x; my sub curry(|c) { return f(|@x) unless c.elems; @x.push(|c); &curry }}; curry(&f)(1)();
camelia §
rakudo-moar ba15173fd: ( no output )
Voldenet §
this lies about which `curry` is it, but it's kind of more informative I believe 14:00
SmokeMachine §
Voldenet: I go to get it… what would be the difference? People already do `my &add = -> $a { -> $b { $a +$b } }` (at least I do…) what would that syntax change besides being more readable? 14:03
Voldenet §
m:
sub f ($a, $b) { }; my $x = -> $a { -> $b { f($a) } }; $x(1)(2)
14:05
camelia §
rakudo-moar ba15173fd: OUTPUT: «Too few positionals passed; expected 2 arguments but got 1␤ in sub f at <tmp> line 1␤ in block <unit> at <tmp> line 1␤␤»
Voldenet §
stack trace here is not too informative about where the actual bug is
in larger codebase it's nice to have good stack traces 14:06
§ 14:06 linkable6 joined
SmokeMachine §
But independently of that people already do that 14:06
Having a “special” syntax for that would make it easier to give a better error, I suppose… 14:08
§ 14:11 Sgeo joined
SmokeMachine §
m:
my &add := -> $a { -> $b { $a + $b } }; my &incr := add 1; incr() # error
14:13
camelia §
rakudo-moar ba15173fd: OUTPUT: «Too few positionals passed; expected 1 argument but got 0␤ in block <unit> at <tmp> line 1␤␤»
SmokeMachine §
Would that be possible to show the “variable” name on that error? 14:14
Voldenet §
it sounds hacky to do 14:17
Nested function syntax overall is a nice idea for partial application, because it's more expressive 14:19
§ 14:24 frost left 14:45 patrickb left, patrickb joined 14:49 patrickb left, patrickb joined 14:51 patrickb left, patrickb joined 14:53 patrickb left, patrickb joined 14:55 patrickb left, patrickb joined 14:57 patrickb left 14:58 patrickb joined 15:04 patrickb left, patrickb joined 15:06 patrickb left, patrickb joined 15:07 evalable6 joined 15:08 patrickb left 15:09 patrickb joined 15:10 patrickb left 15:11 patrickb joined, swaggboi joined 15:13 patrickb left, patrickb joined 15:15 patrickb left, patrickb joined 15:17 gordonfish- is now known as gordonfish 15:19 patrickb left, patrickb joined 15:23 patrickb left
¦ doc/non-scalar-twigils: c0f7ca3906 | (Daniel Sockwell)++ | doc/Language/variables.pod6
   Add indexing and crossrefs
  
   This adds additional index entries for various twigils and links to
   the Sigil section rather than repeating that content when describing
   using sigils and twigils together.
   review:
https://github.com/Raku/doc/commit/c0f7ca3906
15:36
§ 15:52 [Coke]_ is now known as [Cke, [Cke is now known as [Coke] 16:03 keutoi left 16:04 tejr left
¦ doc: 803d861930 | (Daniel Sockwell)++ (committed by Juan Julián Merelo Guervós) | doc/Language/variables.pod6
   Describe non-$ sigils with twigils
  
   This commit describes and indexes non-$ sigils with the ^ and : twigils.
  
   Closes #3953
   review:
https://github.com/Raku/doc/commit/803d861930
16:05
¦ doc: 775f37fc9b | (Daniel Sockwell)++ (committed by Juan Julián Merelo Guervós) | doc/Language/variables.pod6
   Add indexing and crossrefs
  
   This adds additional index entries for various twigils and links to
   the Sigil section rather than repeating that content when describing
   using sigils and twigils together.
   review:
https://github.com/Raku/doc/commit/775f37fc9b
linkable6 §
Link: https://docs.raku.org/language/variables
§ 16:05 tejr joined 16:05 discord-raku-bot left 16:05 linkable6 left 16:06 discord-raku-bot joined
Geth §
¦ doc: jubilatious1 self-assigned Deciding whether (for example) `@^` is a twigil, or rather a sigil followed by a twigil... https://github.com/Raku/doc/issues/3966 16:12
§ 16:32 ens__ left 16:41 dakkar left 17:07 linkable6 joined 17:39 dac left
codesections §
Any thoughts on whether this is a bug? 17:43
m:
sub f(Any $a) { $a := 'nope'; $a }; say f 'yep'
17:44
camelia §
rakudo-moar ba15173fd: OUTPUT: «nope␤»
codesections §
I've been trying to wrap my head around that (and similar questions) for a bit now (see https://stackoverflow.com/questions/69231506/what-are-the-rules-for-re-binding ) and I still am not sure what the rules for re-binding are _supposed_ to be 17:45
§ 17:56 dcx joined 18:02 reportable6 left 18:19 immediate joined 18:32 immediate left 18:33 dcx left, notna joined 18:46 dcx joined 18:47 ufobat_ left 18:54 immediate joined 19:04 immediate left 19:05 reportable6 joined 19:13 stoned75 joined 19:15 notna left 19:36 immediate joined 19:37 immediate left 20:37 linkable6 left, evalable6 left 20:39 linkable6 joined 20:42 tejr left, tejr_ joined 21:01 monkey_ joined 21:29 discord-raku-bot left, discord-raku-bot joined 21:39 evalable6 joined 21:54 tejr_ is now known as tejr 22:05 sena_kun left

|<   <<<   <<   <   22 September 2021   >   >>   >>>   >|
Search 
Live Today I feel lucky Raw Index Home