<< 23-06-2024 >>

01:00:02*nazgulsenpai quit (Quit: ZNC 1.8.2 - https://znc.in)
01:03:27*nazgulsenpai joined #nim
01:27:05*krux02 quit (Remote host closed the connection)
07:02:51*coldfeet joined #nim
07:37:37*ntat joined #nim
08:58:10*coldfeet quit (Remote host closed the connection)
09:19:59*coldfeet joined #nim
09:23:47FromDiscord<orzogc> Can the official vscode extension format codes on save? I didn't get it to work.
09:26:54FromDiscord<zumi.dxy> there's a separate unofficial extension called `nph`
09:27:00FromDiscord<zumi.dxy> that will do the formatting for you
09:32:28FromDiscord<orzogc> I get it, thanks
09:38:42*beholders_eye joined #nim
09:49:21*beholders_eye quit (Ping timeout: 256 seconds)
09:51:29*beholders_eye joined #nim
09:57:15*beholders_eye quit (Ping timeout: 264 seconds)
10:04:21FromDiscord<kots> sent a code paste, see https://play.nim-lang.org/#pasty=REmFOusd
10:05:14FromDiscord<zumi.dxy> how does it change?
10:05:40FromDiscord<kots> no more ugly double-indent when splitting a long parameter list into multiple lines, and no more separating parameters with commas
10:22:17*ntat quit (Quit: Leaving)
10:29:29FromDiscord<zumi.dxy> i kinda see the point of the double indent as awful as it looks
11:27:07NimEventerNew thread by phoenix27: Problem with object oriented programming, see https://forum.nim-lang.org/t/11829
11:53:21FromDiscord<amjadhd> Why is sort `cmp` declared with `{.closure.}` ?
11:53:37FromDiscord<amjadhd> (edit) "?" => "?↵https://github.com/nim-lang/Nim/blob/830153323af0fce9ca5c73030c2374f03367a412/lib/pure/algorithm.nim#L369"
11:55:33FromDiscord<kots> At the risk of stating the obvious... So that you can pass closures in?
12:00:22FromDiscord<amjadhd> In reply to @k0ts "At the risk of": You can pass them without: https://play.nim-lang.org/#pasty=EtwasfLh.
12:01:25FromDiscord<Phil> In reply to @amjadhd "Why is sort `cmp`": Otherwise it would assume the proc your passing in is Nimcall, which would mean it couldn't accept a closure as those come with an environment of variables they capture, unlike Nimcall procs
12:02:22FromDiscord<Phil> Since a Nimcall proc can easily be converted into a closure without logic changes one could argue there should be some kind of converter that allows Nimcall procs everywhere that closures are specified
12:02:29FromDiscord<Phil> Sadly we don't have that
12:02:49FromDiscord<kots> In reply to @amjadhd "You can pass them": Looks like it was added before closure became the default calling convention for proc types, judging by this commit message:↵https://github.com/nim-lang/Nim/commit/8d99753d6320489e4de8cf186415b0a7be8260b4#diff-cbc4d5016c6d92af2c107522f0312d77f3935fa34c90e433dbcfba6f2138d159
12:02:54FromDiscord<Phil> So it's a closure to accept the maximum possible types of procs
12:04:13FromDiscord<Phil> In reply to @k0ts "Looks like it was": Whether closure or Nimcall is the default heavily depends on which syntax you're in. ↵Iirc in a type declaration it assumes closure automatically. ↵In top level procs it assumes Nimcall.↵I forgot what it assumes for procs defined in procs
12:05:00FromDiscord<kots> Default is closure for proc types:↵https://wandbox.org/permlink/Di8Eht1VtCf0iBmp
12:06:00FromDiscord<Phil> In reply to @k0ts "Default is closure for": As a pro parameter.↵I would not bet that foo is a closure
12:06:05FromDiscord<ieltan> In reply to @k0ts "Default is closure for": well you're creating a lambda which is a closure in this case
12:06:11FromDiscord<Phil> (edit) "pro parameter.↵I" => "proc parameter of foo.↵I"
12:06:44FromDiscord<Robyn [She/Her]> In reply to @isofruit "Whether closure or Nimcall": Ooooh so that's why I need to explicitly cast my functions to my Parser type, but weirdly enough this only applies for varargs
12:07:22FromDiscord<kots> https://wandbox.org/permlink/uqIWoIULXXyKkjh3
12:07:23FromDiscord<ieltan> i think this part of Nim sucks so much lol
12:07:27FromDiscord<kots> It's still a closure guys
12:07:48FromDiscord<kots> (edit) "a" => "~~a~~"
12:08:08FromDiscord<Phil> Calling convention between Nimcall and Closure is one of those things that ideally would be transparent
12:08:19FromDiscord<Robyn [She/Her]> In reply to @ieltan "i think this part": The fact nimcall is distinct from closure?
12:08:49FromDiscord<Phil> In reply to @k0ts "It's still ~~a~~ closure": You're still passing it into the proc, messaging Nim likely does the calling convention of closure implicitly. ↵Try the same echo for foo itself
12:09:06FromDiscord<Phil> (edit) "messaging" => "meaning"
12:09:21FromDiscord<ieltan> In reply to @chronos.vitaqua "The fact nimcall is": the fact that you think you're passing a nimcall but it's actually closure
12:09:42FromDiscord<ieltan> and you need to anotate `{.nimcall.}` to avoid that
12:09:47FromDiscord<ieltan> 😐
12:09:50FromDiscord<kots> https://nim-lang.github.io/Nim/manual.html#types-procedural-type
12:10:01FromDiscord<kots> It says proc types are closure by default
12:10:03FromDiscord<Robyn [She/Her]> In reply to @ieltan "and you need to": I mean, it makes sense
12:10:15FromDiscord<kots> Can someone show me when this isn't the case?
12:10:46FromDiscord<Phil> is the default convention used for a Nim proc. It is the same as fastcall, but only for C compilers that support fastcall.
12:10:52FromDiscord<Phil> For nimcall
12:11:03FromDiscord<Phil> Closure is the default for proc types
12:11:11FromDiscord<kots> That's what I've been saying though...
12:11:21FromDiscord<kots> I'm not sure what we are disagreeing about here...
12:12:06FromDiscord<Phil> And we've been telling you it depends on which syntax you're in and it's a mixed bag.↵Outside of your proc on top level, chances are that the Nimcall calling convention is used
12:12:49FromDiscord<Phil> I'm on phone and in between exercises so I can't exactly write code rn
12:12:50FromDiscord<kots> It's not a mixed bag, when you write a proc it's nimcall, when you write a proc type it's closure
12:13:34FromDiscord<kots> When you declare a proc parameter its type is a proc type so its default convention is closure
12:13:55FromDiscord<kots> The only question here is why it was declared explicitly when it defaults to closure anyway
12:14:14FromDiscord<ieltan> In reply to @chronos.vitaqua "I mean, it makes": i'm just sauying it sucks, i remember making a custom `map`, i had to make like two versions because of the compiler crying about`{.nimcall.}` and`{.closure.}` . But now you have no clue which one is being used at call site loo
12:14:22FromDiscord<kots> If I'm missing something please point it out explicitly, I feel like I'm retarded
12:15:03FromDiscord<kots> (edit) removed "proc" | "parameter ... its" added "that is a proc,"
12:16:46FromDiscord<Robyn [She/Her]> In reply to @ieltan "i'm just sauying it": I'd say that's a non-issue since functionality is still identical, no?
12:18:05FromDiscord<ieltan> In reply to @chronos.vitaqua "I'd say that's a": erm no, if i would want to avoid closures whenever i can because they have bigger overhead. so i have to make a `{.nimcall.}` version...
12:18:16FromDiscord<ieltan> (edit) removed "if"
12:19:26FromDiscord<Robyn [She/Her]> True, didn't think of that
12:20:17FromDiscord<Robyn [She/Her]> It's a non-issue in my case since my parser combinator does parser combination at compile-time when possible
12:21:47FromDiscord<ieltan> well in my case i just have no way to know which one is called because nimcall implicitly converts to closures.
12:22:28FromDiscord<Robyn [She/Her]> Couldn't you make two functions that accepts either one?
12:22:56FromDiscord<Robyn [She/Her]> Then the one that accepts a closure can just be annotated with `{.error.}`
12:23:25FromDiscord<ieltan> yes but sometimes i need to closure too, i mean a `map` that cannot accept closure is kinda useless
12:23:37FromDiscord<Robyn [She/Her]> Fair enough
12:24:12FromDiscord<ieltan> `{.nimcall.}` is accepted because not everything is a closure and it's a good way to avoid overhead
12:25:10FromDiscord<Robyn [She/Her]> Makes sense
12:25:38FromDiscord<amjadhd> In reply to @isofruit "Since a Nimcall proc": It is converted implicitly to a closure: https://play.nim-lang.org/#pasty=xIugyPRA
12:26:43FromDiscord<kots> the answer to the original question is that it was marked as closure before closure became the default:↵https://github.com/nim-lang/Nim/commit/8d99753d6320489e4de8cf186415b0a7be8260b4↵https://github.com/nim-lang/Nim/commit/033dc50c691f37808e021856bcd0d385cf427ec2
12:27:43FromDiscord<ieltan> i tried looking up how the stdlib does it, hoping they're not just sticking with `{.closure.}`
12:27:53FromDiscord<ieltan> nope, of course theyre are
12:28:12FromDiscord<Phil> In reply to @amjadhd "It is converted implicitly": ... I'm highly wondering why that conversion didn't work for me when also dealing with async procs elsewhere, but likely a caveat of sorts
12:30:05FromDiscord<ieltan> In reply to @isofruit "... I'm highly wondering": async are totally different thing
12:35:45FromDiscord<ieltan> i guess this answers my problem: https://play.nim-lang.org/#pasty=oaLihBns
12:36:13FromDiscord<ieltan> but it's very unintuitive
12:40:06FromDiscord<ieltan> In reply to @ieltan "i guess this answers": or not, why is `baz()` calling the closure version ?
12:42:19FromDiscord<kots> cause baz is a closure, isn't it
12:42:37FromDiscord<ieltan> ah
12:42:47FromDiscord<ieltan> yeah sorry i missed the `x`
12:43:13FromDiscord<ieltan> nvm
13:49:36*xet7 joined #nim
13:59:59*xtr00 joined #nim
15:16:02*xtr00 quit (Ping timeout: 250 seconds)