🦋 Welcome to the MAIN() IRC channel of the Raku Programming Language (raku.org). This channel is logged for the purpose of keeping a history about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Log inspection is getting closer to beta. If you're a beginner, you can also check out the #raku-beginner channel!
Set by lizmat on 25 August 2021.
Geth 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](github.com/daaku/nodejs-tmpl) from 1.0.4 to 1.0.5.
  - [Release notes](github.com/daaku/nodejs-tmpl/releases)
  - [Commits](github.com/daaku/nodejs-tmpl/commits/v1.0.5)
  ---
... (6 more lines)		 00:13
setup-raku: dependabot[bot]++ created pull request #16:
Bump tmpl from 1.0.4 to 1.0.5
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](github.com/daaku/nodejs-tmpl) from 1.0.4 to 1.0.5.
  - [Release notes](github.com/daaku/nodejs-tmpl/releases)
  - [Commits](github.com/daaku/nodejs-tmpl/commits/v1.0.5)
  ---
... (6 more lines)		 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		 00:18
CIAvash m: sub f ($a, :$b) { dd $a, $b; }; say &f.assuming(1, :b(2)).signature 07:06
camelia (:$b)
CIAvash is this a bug or expected behavior?
moon-child m: m: sub f ($a, :$b) { dd $a, $b; }; &f.assuming(1, :b(2))(b => 3) 07:09
camelia 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 (:$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 ($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 ($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 ()
moon-child yes, I understand
that doesn't clarify what problem you have with the current scheme 07:26
github.com/Raku/roast/blob/master/...amed.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
moon-child so you expect that, given sub f(:$a) { }, &f.assuming(:a(7))(:a(8)) should be illegal? 07:35
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
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 0
moon-child regardless, it would be inconsistent
CIAvash yeah, `.count` returns the number of positional arguments. still, doesn't make sense to me. 08:01
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
moon-child still finds the current behaviour obviously correct...¯\_(ツ)_/¯
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
moon-child why 'should' that be what it does? 08:37
SmokeMachine it should, in my mind at least... 08:37
SmokeMachine `Returns a Callable that implements the same behavior as the original, but has the values passed to .assuming already bound to the corresponding parameters.`, it doesn't say it changes the default value of parameters, but it values already bound 08:39
SmokeMachine (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 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 ($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
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 0.308274192
Voldenet m: sub f ($a, $b = 2) { state $c = $a }; ->{ f(1) }() for ^10; say now - BEGIN now 09:46
camelia 0.009272104
SmokeMachine Voldenet: that's a reason I like the idea of `-> $a -> $b { $a + $b }` be equivalent of `-> $a { -> $b { $a + $b } }` 12:05
Nemokosch 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 github.com/lizmat/Slang-Subscripts...ts.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
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
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 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 ( 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 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
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
SmokeMachine m: my &add := -> $a { -> $b { $a + $b } }; my &incr := add 1; incr() # error 14:13
camelia 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
Geth 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.		 15:36
Geth 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		 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.
linkable6 Link: docs.raku.org/language/variables
Geth ¦ doc: jubilatious1 self-assigned Deciding whether (for example) `@^` is a twigil, or rather a sigil followed by a twigil... github.com/Raku/doc/issues/3966 16:12
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 nope
codesections I've been trying to wrap my head around that (and similar questions) for a bit now (see stackoverflow.com/questions/692315...re-binding ) and I still am not sure what the rules for re-binding are _supposed_ to be 17:45

Powered by Cro and the Raku® Programming Language.

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

Thank you!