|
🦋 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. |
|||
|
00:03
reportable6 left
00:05
reportable6 joined
00:09
_73 left
|
|||
| 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 | ||
|
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 | (:$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 | 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 | |
|
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 | 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 | ||
| 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 | |
|
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
|
|||
| 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 | |
|
08:39
ufobat left
|
|||
| 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 | |
|
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 | 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 | ||
|
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 | |
| 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 | ||
|
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 | 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 | ||
|
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 | 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
|
|||
| 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 | |
|
15:52
[Coke]_ is now known as [Cke,
[Cke is now known as [Coke]
16:03
keutoi left
16:04
tejr left
|
|||
| 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 | ||
|
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... 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 | 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 | |
|
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:59
monkey_ left
23:59
evalable6 left,
linkable6 left
|
|||