00:04:28 | * | oz quit (Ping timeout: 240 seconds) |
00:12:11 | * | ox joined #nim |
00:24:39 | FromDiscord | <auxym> wrapping liblzma (with futhark if you want) is an option for xz |
00:30:52 | * | derpydoo joined #nim |
00:54:44 | FromDiscord | <arathanis> out of curiosity, if you use ref types with `--mm:none` is there a way to explicitly free the references? |
00:55:00 | FromDiscord | <arathanis> or since ref is just GC managed ptr, is the expectation "what are you doing just use ptr" |
00:55:09 | FromDiscord | <arathanis> (edit) "ptr"" => "ptr if you turn the GC off"" |
01:06:37 | * | jmd_ quit (Ping timeout: 240 seconds) |
01:07:05 | FromDiscord | <Elegantbeef> I imagine you can call `=destroy` but i've not checked |
01:55:11 | FromDiscord | <kcvinker> sent a code paste, see https://play.nim-lang.org/#ix=4xNm |
01:57:06 | FromDiscord | <graveflo> what do you mean the program won't run? The proc appears to do nothing or a crash in the entire program? |
01:57:47 | FromDiscord | <!&luke> sent a code paste, see https://play.nim-lang.org/#ix=4xNn |
01:58:16 | FromDiscord | <kcvinker> In reply to @graveflo "what do you mean": If I remove that echo statement, it won't run |
01:58:28 | FromDiscord | <arathanis> In reply to @Elegantbeef "I imagine you can": i was toying with this and it was not working, so i wondered if i was missing something |
01:58:38 | FromDiscord | <graveflo> In reply to @kcvinker "If I remove that": what is "it" |
01:59:05 | FromDiscord | <kcvinker> It is a dll and I am calling from a scripting lang called AutoIt |
01:59:08 | FromDiscord | <arathanis> what does "it wont run" mean |
01:59:53 | FromDiscord | <graveflo> ok well the `addItems` proc seems to interact via `sendMsg` is this what is failing to happen? |
01:59:54 | FromDiscord | <kcvinker> In reply to @arathanis "what does "it wont": Oh, I don't know how to explain that |
02:00:05 | FromDiscord | <arathanis> does it crash? |
02:00:25 | FromDiscord | <arathanis> like "it wont run" is too nebulous for anyone to help |
02:00:30 | FromDiscord | <kcvinker> In reply to @graveflo "ok well the `addItems`": At that time, listbox handle is not created. So send message line will not run |
02:00:45 | FromDiscord | <kcvinker> In reply to @arathanis "like "it wont run"": Sorry for that |
02:01:08 | FromDiscord | <arathanis> that is better, in order to help diagnose the issue we need to know how its failing |
02:01:15 | FromDiscord | <arathanis> can you check the generated code? |
02:01:31 | FromDiscord | <kcvinker> Nim's generated code is for aliens |
02:01:41 | FromDiscord | <arathanis> some of it sure |
02:01:49 | FromDiscord | <arathanis> but its usually pretty easy to find your functions and get the ist of it |
02:01:51 | FromDiscord | <arathanis> (edit) "ist" => "jist" |
02:02:01 | FromDiscord | <arathanis> what i suggest is this |
02:02:03 | FromDiscord | <kcvinker> Okay |
02:02:11 | FromDiscord | <arathanis> im assuming you are using VS code |
02:02:17 | FromDiscord | <kcvinker> Yes |
02:02:19 | FromDiscord | <arathanis> compile with the echo statement |
02:02:25 | FromDiscord | <arathanis> go grab the generated file and save it somewhere |
02:02:26 | FromDiscord | <kcvinker> Yes |
02:02:28 | FromDiscord | <arathanis> compile w/o |
02:02:31 | FromDiscord | <arathanis> grab the file again |
02:02:32 | FromDiscord | <arathanis> do a diff |
02:02:34 | FromDiscord | <arathanis> and see just where they differ |
02:02:37 | FromDiscord | <kcvinker> Okay |
02:02:45 | FromDiscord | <kcvinker> Sounds great |
02:02:49 | FromDiscord | <kcvinker> Thanks' |
02:02:51 | FromDiscord | <arathanis> maybe you will find something silly like "the compiler is optimizing out something" |
02:02:52 | FromDiscord | <kcvinker> Let me try |
02:02:56 | FromDiscord | <arathanis> np |
02:03:04 | FromDiscord | <arathanis> yeah it can be hard to read but a diff should narrow it way down |
02:03:04 | FromDiscord | <arathanis> GL! |
02:03:16 | FromDiscord | <kcvinker> Thanks |
02:15:01 | FromDiscord | <graveflo> sent a code paste, see https://play.nim-lang.org/#ix=4xNq |
02:18:16 | * | tiorock joined #nim |
02:18:16 | * | tiorock quit (Changing host) |
02:18:16 | * | tiorock joined #nim |
02:18:16 | * | rockcavera quit (Killed (tantalum.libera.chat (Nickname regained by services))) |
02:18:16 | * | tiorock is now known as rockcavera |
02:22:43 | FromDiscord | <kcvinker> sent a code paste, see https://play.nim-lang.org/#ix=4xNr |
02:22:52 | FromDiscord | <kcvinker> That slicing |
02:24:15 | * | hochata joined #nim |
02:27:44 | * | azimut quit (Ping timeout: 240 seconds) |
02:50:38 | FromDiscord | <Elegantbeef> @graveflo\: what are you trying to do? |
02:51:25 | FromDiscord | <graveflo> populate a seq with ref types restricted to a generic of type `GenObj` or its descendants without making a proxy baseclass |
02:51:55 | FromDiscord | <graveflo> or an concrete type generated from a generic |
02:52:15 | FromDiscord | <Elegantbeef> Right you have a base type which is the root node |
02:52:27 | FromDiscord | <Elegantbeef> `WhyDoIExist` exists cause you need a base node |
02:52:34 | FromDiscord | <Elegantbeef> Also do `ref object of RootObj` |
02:52:41 | FromDiscord | <graveflo> sent a code paste, see https://play.nim-lang.org/#ix=4xNu |
02:53:29 | FromDiscord | <graveflo> well thats kinda stoopid that you have to make an explicit type for that to work since there should be nothing restricting the behavior apart from illogical semantics |
02:53:59 | FromDiscord | <graveflo> and I wouldn't make it a ref type because then I can't use it as a non-ref type and `ref GenObj` is more explicit |
02:55:11 | FromDiscord | <Elegantbeef> I mean you need a concrete type |
02:55:38 | FromDiscord | <Elegantbeef> You can make a non ref type it's just very very verbose |
02:55:48 | FromDiscord | <graveflo> I realize that is the issue with `GenObj` by itself |
02:57:25 | FromDiscord | <graveflo> and `ref` is not that varbose and `RefGenObj` is just as verbose. between the two `ref GenObj` is better because it uses language directives to communicate it's meaning instead of arbitrary programmer decisions. Also less pollution |
02:58:26 | FromDiscord | <graveflo> making a whole new alias just to wrap a core lang feature is like making a function for a one liner |
03:02:06 | * | oldpcuser joined #nim |
03:02:50 | FromDiscord | <heysokam> In reply to @auxym "wrapping liblzma (with futhark": problem is wrapping a library just to call `unzip( filepath )` 😔↵but yeah, i guess its an option, if nothing else |
03:03:51 | FromDiscord | <heysokam> In reply to @graveflo "if you don't find": does this have lzma? `zippy` also has support for tar, but not for xz |
03:04:09 | FromDiscord | <graveflo> sent a long message, see http://ix.io/4xNx |
03:04:53 | FromDiscord | <graveflo> (edit) "http://ix.io/4xNx" => "http://ix.io/4xNy" |
03:06:15 | FromDiscord | <Elegantbeef> i'm so lost |
03:06:22 | FromDiscord | <graveflo> In reply to @heysokam "does this have lzma?": no it doesn't I misread his post and thought he had the lzma but no tar parser |
03:07:21 | FromDiscord | <graveflo> Beef T.T I keep trying to explain these things to you. I might be missing something but this and the last text wall I sent you are legitimate concerns about the language. Theres no reason that a generic object should have to inherit from a dummy base to enable `ref` semantics |
03:09:42 | FromDiscord | <Elegantbeef> "enable ref semantics" |
03:09:46 | FromDiscord | <Elegantbeef> No you're not after ref semantics |
03:09:52 | FromDiscord | <Elegantbeef> You're after inheritance |
03:10:10 | FromDiscord | <graveflo> that is a ref semantic in this context |
03:10:12 | FromDiscord | <Elegantbeef> Ref semantics does not include type erasure |
03:10:30 | FromDiscord | <Elegantbeef> Well a type that does not inherit doesnt have type information on the type |
03:11:23 | FromDiscord | <graveflo> how else are you supposed to popular a contiguous array of arbitrarily sized data structures? You have to use pointers. Or in managed terms refs |
03:11:33 | FromDiscord | <graveflo> I could call it pointer semantics but its the same thing |
03:11:37 | FromDiscord | <Elegantbeef> Then you share the parent |
03:11:40 | FromDiscord | <Elegantbeef> It's not pointer semantics |
03:11:51 | FromDiscord | <Elegantbeef> It's type erasure which requires type information which means inheritance |
03:12:30 | FromDiscord | <graveflo> ok fine. Since this is interacting with the type system they are type semantics |
03:13:30 | FromDiscord | <graveflo> still there is no reason why I cant define a generic object and make a seq of refs on that type without making a base class alias |
03:13:49 | FromDiscord | <Elegantbeef> Yea there is a type that doesnt inherit doesnt have RTTI on the data |
03:14:06 | FromDiscord | <Elegantbeef> There also is no reason to include the RTTI on it unless you need it |
03:14:29 | FromDiscord | <graveflo> inheriting from `RootObj` has this right? |
03:14:44 | FromDiscord | <Elegantbeef> Inheriting has type information stored on the value |
03:15:00 | FromDiscord | <Elegantbeef> If you really really want this type erasure just make a box type and problem solved |
03:15:27 | FromDiscord | <Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=4xNB |
03:15:43 | FromDiscord | <Elegantbeef> There you go you now have boxed values which means you can store any value inside a collection |
03:15:56 | FromDiscord | <graveflo> that's not problem solved if you are an API dev. I will need to do that for every type I inherit from `RootObj` because I do not decide how the type will be used |
03:16:44 | FromDiscord | <Elegantbeef> Well you want arbitrary types inside a collection, something that is rarely the best solution |
03:17:26 | FromDiscord | <graveflo> sent a code paste, see https://paste.rs/y81vn |
03:17:41 | FromDiscord | <graveflo> this could be just how the language works and there is nothing to gain from needing this arbitrary restriction |
03:17:58 | FromDiscord | <Elegantbeef> Except you now need RTTI on every single type |
03:18:01 | FromDiscord | <graveflo> forcing people to use box types doesn't do anything useful it takes away useful things for no reason |
03:18:47 | FromDiscord | <graveflo> so a type without a box type will not have RTTI even if they inherit from `RootObj`? |
03:19:04 | FromDiscord | <Elegantbeef> They have RTTI if they inherit |
03:19:18 | FromDiscord | <Elegantbeef> you can do `seq[RootRef]` if you want to enable all ref types in a collection |
03:19:38 | FromDiscord | <graveflo> but not all refs restricted to a base class though |
03:20:08 | FromDiscord | <graveflo> alright if inheriting from a class adds complexity then I guess there is a reason to make it explicit |
03:20:33 | FromDiscord | <graveflo> well besides the obvious complexity that is |
03:20:54 | FromDiscord | <Elegantbeef> So then what's the issue |
03:20:59 | FromDiscord | <Elegantbeef> Well it adds RTTI that is otherwise not present |
03:21:07 | FromDiscord | <Elegantbeef> And it also means that interop gets more awful |
03:21:58 | FromDiscord | <graveflo> sent a code paste, see https://play.nim-lang.org/#ix=4xNC |
03:22:12 | FromDiscord | <graveflo> so why doesn't `GenObj` need rti if it is inheriting from `RootObj` ? |
03:22:49 | FromDiscord | <Elegantbeef> They both have RTTI |
03:23:01 | FromDiscord | <Elegantbeef> `type GenObj[T] = object` does not have RTTI |
03:23:05 | FromDiscord | <graveflo> then this whole RTTI thing is a complete misdirection |
03:23:25 | FromDiscord | <graveflo> Ive said multiple times I am talking about things that inherit from `RootObj` |
03:23:25 | FromDiscord | <Elegantbeef> I thought you wanted to get rid of `Base = object of RootObj`? |
03:23:41 | FromDiscord | <Elegantbeef> You have to have a concrete type to be your base |
03:24:14 | FromDiscord | <graveflo> but `WhyDoIExist[X[RootObj]]` is a concrete type for `X` so there is no need to manually make a box~ |
03:24:44 | FromDiscord | <graveflo> you can make that during it's definition. There could always be a static route to get the "Box" without making it |
03:24:53 | FromDiscord | <Elegantbeef> I'm so lost at your point |
03:24:54 | FromDiscord | <Elegantbeef> You want to get rid of the `Base = object of RootObj` |
03:24:56 | FromDiscord | <graveflo> so its just a useless restriction |
03:25:06 | FromDiscord | <graveflo> theres no need for it |
03:25:19 | FromDiscord | <graveflo> besides one that is arbitrarily enforced by the lang |
03:25:39 | FromDiscord | <Elegantbeef> Sure we agree here then |
03:25:48 | FromDiscord | <Elegantbeef> I thought you wanted to make all objects convertible to `RootRef` |
03:26:16 | FromDiscord | <Elegantbeef> You sure do write convoluted things instead of just making your point 😛 |
03:26:35 | FromDiscord | <graveflo> sent a code paste, see https://play.nim-lang.org/#ix=4xND |
03:26:56 | FromDiscord | <Elegantbeef> So much work to get around a non issue |
03:27:00 | FromDiscord | <graveflo> I'm trying 😅 |
03:27:21 | FromDiscord | <graveflo> its not a non-issue when you are making an API and you don't want to restrict the use cases of your objects |
03:27:31 | FromDiscord | <Elegantbeef> It's pretty much a non issue |
03:27:51 | FromDiscord | <graveflo> I'll have to make a box for all the objects that inherit from `RootOb` just to enable something that gets disabled for no reason |
03:28:49 | FromDiscord | <Elegantbeef> You're just pointlessly implementing things that no one will need/use |
03:30:03 | FromDiscord | <graveflo> its not implementing things its re-enabling things that should not be disabled from a flaw. Theres no reason to implement it bc there should be no reason to. It's also presumptuous to assume that no one is going to want to do that. Why enable data abstraction in the first place then? |
03:30:20 | FromDiscord | <graveflo> the lang might as well have no mechanism for it if there are no use cases |
03:30:44 | FromDiscord | <Elegantbeef> What's even disabled? |
03:31:09 | FromDiscord | <arathanis> In reply to @kcvinker "<@136570191038513152> Found the problem": nice! |
03:31:15 | FromDiscord | <arathanis> sounds like doing that worked out for you? |
03:31:23 | FromDiscord | <arathanis> did you also find a solution or still figuring that part out? |
03:32:39 | FromDiscord | <graveflo> sent a code paste, see https://play.nim-lang.org/#ix=4xNH |
03:33:57 | FromDiscord | <Elegantbeef> Nothing cause there is no type language for this specific scenario |
03:34:31 | FromDiscord | <graveflo> ok its not a bug its a feature sure |
03:34:33 | * | oldpcuser_ joined #nim |
03:34:42 | FromDiscord | <Elegantbeef> I mean it's a lacking place in the language |
03:34:45 | FromDiscord | <Elegantbeef> It's not disabling anything |
03:35:11 | FromDiscord | <graveflo> if you made a box you would enable it! if it wasn't generic it would work! It is disabled because there is a flaw |
03:35:17 | FromDiscord | <Elegantbeef> You need to have a common ancestor and `GenObj` is not a common ancestor |
03:35:21 | FromDiscord | <graveflo> I proved that there is an easy way to generate the solution to the flaw |
03:36:13 | * | oldpcuser_ quit (Max SendQ exceeded) |
03:36:15 | FromDiscord | <graveflo> I'm not saying it should be `GenObj` beef |
03:36:35 | FromDiscord | <graveflo> I'm saying the box method is a work around at best |
03:36:37 | * | oldpcuser quit (Ping timeout: 240 seconds) |
03:36:52 | FromDiscord | <Elegantbeef> I say it's a solution as it gives a common ancestor |
03:37:15 | FromDiscord | <graveflo> it should have one already. Making one automatically has a 0 cost |
03:37:21 | FromDiscord | <Elegantbeef> Like how do you express "any GenObj" in your ideal world? |
03:37:34 | FromDiscord | <Elegantbeef> `(ref GenObj)`? |
03:37:39 | FromDiscord | <Elegantbeef> You now overloaded a typeclass |
03:37:44 | * | oldpcuser_ joined #nim |
03:38:04 | FromDiscord | <graveflo> I'm not sure.. what would `GenObj[RootObj]` mean here |
03:38:07 | FromDiscord | <graveflo> could that be it? |
03:38:17 | FromDiscord | <Elegantbeef> Nope |
03:38:22 | FromDiscord | <graveflo> or `GenObj[object]` |
03:38:34 | * | oldpcuser_ quit (Remote host closed the connection) |
03:38:37 | FromDiscord | <graveflo> how about `GenObj[]` |
03:38:54 | FromDiscord | <Elegantbeef> The issue is you cannot use that either |
03:39:14 | FromDiscord | <Elegantbeef> It creates ambiguity with generic instantitations |
03:39:16 | FromDiscord | <graveflo> ok how about this `RootObj[GenObj]` that is more similar to my automated solution |
03:39:27 | FromDiscord | <Elegantbeef> That could work |
03:39:50 | FromDiscord | <graveflo> and in fact the in lang work around could just make RootObj or another RootObj type generic |
03:39:57 | FromDiscord | <graveflo> and just do it the exact way I solved it |
03:40:02 | * | oldpcuser joined #nim |
03:40:06 | FromDiscord | <Elegantbeef> That's not even required really |
03:40:18 | FromDiscord | <graveflo> good it looks weird |
03:40:33 | FromDiscord | <Elegantbeef> `RootObj[T]` could be special cased in typematching that checks if the type is convertible to T |
03:40:50 | * | oldpcuser quit (Max SendQ exceeded) |
03:41:01 | FromDiscord | <graveflo> well I think it would be a good idea |
03:41:05 | FromDiscord | <Elegantbeef> Well `T[auto...]` |
03:41:22 | FromDiscord | <Elegantbeef> Where you insert auto for all the generic parameters |
03:41:38 | FromDiscord | <Elegantbeef> It still is a convoluted change for something that is easily expressed |
03:42:47 | FromDiscord | <graveflo> the problem with that when you are wiring APIs professionally you are supposed to make your code as extensible and usable as possible. This FORCES you to make all `RootObj` s have a box |
03:42:48 | FromDiscord | <graveflo> period |
03:42:54 | FromDiscord | <graveflo> you dont know who is using your code |
03:42:59 | FromDiscord | <graveflo> its bad if you have to change it |
03:43:16 | FromDiscord | <graveflo> (edit) "wiring" => "writing" |
03:43:51 | * | oldpcuser joined #nim |
03:44:19 | FromDiscord | <Elegantbeef> It really doesnt cause you shouldnt be using inheritance for all types |
03:45:01 | FromDiscord | <graveflo> if you are making an object that is inheriting from `RootObj` you are telling me you aren't using inheritance? |
03:45:36 | * | oldpcuser quit (Remote host closed the connection) |
03:45:40 | FromDiscord | <Elegantbeef> I'm saying you shouldnt make all objects use inheritance cause someone might want to inherit from it |
03:46:19 | FromDiscord | <graveflo> anything that has usefulness being inherited from would inherit from `RootObj` yes |
03:46:45 | FromDiscord | <graveflo> but that's neither here nor there. This is about inheriting from `RootObj` not when should we inherit from `RootObj` |
03:48:17 | FromDiscord | <Elegantbeef> Given the alternative explicitly declaring a Root branch type is the lesser of the evils, in my opinion |
03:48:43 | FromDiscord | <Elegantbeef> Aside from maybe `seq[ref object of GenObj]` everything is much more convoluted |
03:48:55 | FromDiscord | <Elegantbeef> And conflates existent syntax |
03:49:07 | FromDiscord | <graveflo> how? it has 0 overhead and you would only use it if you need it |
03:49:12 | FromDiscord | <Elegantbeef> Write an RFC if you really feel like this is required |
03:49:21 | FromDiscord | <Elegantbeef> I know the compiler's type match and type system |
03:49:45 | FromDiscord | <Elegantbeef> Adding in a feature like this isnt too complicated but it needs to be added in and a chosen syntax that isnt conflated needs to be chosen |
03:50:05 | FromDiscord | <graveflo> I get that. I'm not saying that people should get to work and make this happen. I'm just saying that it is a flaw. Perhaps a minor one but worth noting. People will notice things like this |
03:50:22 | FromDiscord | <Elegantbeef> `RootObj[T]` is an odd syntax that implies `RootObj` is a generic which it is not. `GenObj[object]` implies `GenObj[int]` doesnt match |
03:50:27 | FromDiscord | <graveflo> I'll submit an RFC maybe if we have confirmed that there is no way to do this |
03:50:59 | FromDiscord | <graveflo> right I'm not sure about the syntax. That was just what I gathered from my ghastly generic Box workaround |
03:51:02 | * | oldpcuser joined #nim |
03:51:13 | FromDiscord | <Elegantbeef> `ref object of GenObj` is the only solution that is readable and not presently valid, it also is wordy and not aliasable |
03:51:14 | FromDiscord | <graveflo> which tbh isn't that bad if I just make the macro pragma |
03:51:39 | * | oldpcuser quit (Read error: Connection reset by peer) |
03:51:49 | * | hochata quit (Ping timeout: 250 seconds) |
03:52:03 | FromDiscord | <graveflo> hmm well maybe I'll just implement my work around and save this for when I actually have time to read the compiler source |
04:18:12 | * | oldpcuser joined #nim |
04:19:13 | FromDiscord | <arathanis> @graveflo are you trying to trick the language into letting you make arbitrary collections of any type without having to use the type system to generate a root box object that actually stores the time so you can just make seqs for example that contain strings, and int, and floats, and whatever you want? |
04:19:31 | FromDiscord | <Elegantbeef> Nah they just want to not have to box inheriting types |
04:19:54 | FromDiscord | <arathanis> im not even sure i understand what "boxing inhereting types" means in this context |
04:19:58 | FromDiscord | <graveflo> no you can just make a seq with `RootObj` for that |
04:20:04 | FromDiscord | <arathanis> (edit) "inhereting" => "inheriting" |
04:20:12 | FromDiscord | <arathanis> In reply to @graveflo "no you can just": dont think "int" is an object |
04:20:27 | FromDiscord | <Elegantbeef> A generic inheritance type does not presently have a way to represent "shared parent" |
04:20:28 | FromDiscord | <graveflo> its not. This only makes sense for objects with RTTI |
04:20:38 | FromDiscord | <graveflo> as beef has taught me this acronym now 😛 |
04:20:44 | FromDiscord | <Elegantbeef> `type MyType[T] = ref object of RootObj` there is no way of making a `seq[MyType]` |
04:21:21 | FromDiscord | <Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=4xNT |
04:21:51 | FromDiscord | <arathanis> ahh they want sequences of a arbitrary instantiated generics w/o an intermediary |
04:22:04 | FromDiscord | <Elegantbeef> Which I personally thing is the most simple solution to this problem since it doesnt require any complex compiler sigmatch changes or new syntax |
04:22:21 | FromDiscord | <arathanis> (edit) removed "a" |
04:22:25 | FromDiscord | <arathanis> does RootObj not function as an intermediary? |
04:22:40 | FromDiscord | <Elegantbeef> You can have `RootRef` or `ref RootObj` yes |
04:22:46 | FromDiscord | <Elegantbeef> But the issue is they want only their types |
04:22:58 | FromDiscord | <Elegantbeef> Which means there just is no way without declaring your own base to branch `RootObj` |
04:23:35 | FromDiscord | <Elegantbeef> Concepts dont work cause they're not concrete `seq[MyType]` doesnt work cause it's not concrete |
04:23:35 | FromDiscord | <arathanis> Ah they dont want to support anything that inherits from RootObj |
04:23:47 | FromDiscord | <graveflo> Its the same thing you would be going if there were no generic but there is a generic |
04:23:55 | FromDiscord | <arathanis> how long have you been working on this? |
04:24:06 | FromDiscord | <graveflo> me? |
04:24:16 | FromDiscord | <Elegantbeef> I mean that generic is a very big differentiater 😛 |
04:24:30 | FromDiscord | <Elegantbeef> It means there is no injected concrete symbol to convert to |
04:25:02 | FromDiscord | <arathanis> In reply to @graveflo "me?": yes |
04:25:13 | FromDiscord | <graveflo> I get that but the point of generics is to have something that behaves just like an object would otherwise |
04:25:24 | FromDiscord | <graveflo> In reply to @arathanis "yes": working on what though? This isn't a project |
04:25:29 | FromDiscord | <arathanis> working on this problem |
04:25:35 | FromDiscord | <arathanis> trying to get this to work |
04:25:42 | FromDiscord | <graveflo> I just ran into it about 20 min before I made my initial post |
04:26:10 | FromDiscord | <arathanis> In reply to @graveflo "I get that but": i dont think this is the point of generics |
04:26:41 | FromDiscord | <Elegantbeef> Well not in Nim |
04:26:41 | FromDiscord | <Elegantbeef> Generics in Nim are just templated types |
04:26:45 | FromDiscord | <Elegantbeef> Which is a shame |
04:26:56 | FromDiscord | <arathanis> is there a language where this is the point of generics? |
04:27:12 | FromDiscord | <arathanis> everything ive ever read about generics is that they are for code reuse |
04:27:22 | FromDiscord | <arathanis> let me find the quote i bet its on wikipedia |
04:27:32 | FromDiscord | <graveflo> the point of generics is to not have to make multiple variants of a common form when the form can be generated. You use the generic form as it were a normal object when the code is generic and then disambiguate them. It lets you use the same language constructs for theoretical types and concrete types |
04:27:40 | FromDiscord | <arathanis> found it |
04:27:41 | FromDiscord | <arathanis> https://media.discordapp.net/attachments/371759389889003532/1116584376843636877/image.png |
04:28:03 | FromDiscord | <Elegantbeef> Cool that quote has no reflection in the real world |
04:28:15 | FromDiscord | <arathanis> ¯\_(ツ)_/¯ |
04:28:30 | FromDiscord | <Elegantbeef> There is no reason you cannot have `any(MyType)` or similar work in Nim |
04:28:45 | FromDiscord | <Elegantbeef> It has RTTI and is heap allocated |
04:28:48 | FromDiscord | <Elegantbeef> So it's totally possible |
04:29:10 | FromDiscord | <arathanis> @graveflo there must be a language whose feature you are trying to duplicate, can I ask what it is? |
04:29:15 | FromDiscord | <arathanis> i want to go see the semantics you are going for in practice |
04:29:22 | FromDiscord | <Elegantbeef> Generics can exist as real types not just templates |
04:29:48 | FromDiscord | <Elegantbeef> But Nim doesnt see `MyType` as anything but a typeclass which means it's impossible to use where a concrete type is required |
04:30:27 | FromDiscord | <graveflo> xD no this isn't a copy job its a completeness thing. I understand the mechanics of the system and see a gap. The gap appears to be because the language has no way to refer to a simple concept when (i say) it should |
04:31:09 | FromDiscord | <graveflo> again if you just think about it as if these were not generics but concrete types and see how being disambiguate generics and it should be obvious why someone would reason about this issue |
04:31:18 | FromDiscord | <graveflo> thats how the "box method" is known in the first place |
04:31:47 | FromDiscord | <odexine> I just got here what is happening |
04:32:05 | FromDiscord | <graveflo> (edit) "being" => "people" |
04:32:47 | FromDiscord | <Elegantbeef> Talking about generic inheritance not having a base type |
04:33:31 | FromDiscord | <odexine> Generic inheritance..? |
04:35:05 | FromDiscord | <arathanis> sent a code paste, see https://play.nim-lang.org/#ix=4xNV |
04:35:11 | FromDiscord | <graveflo> In reply to @graveflo "This is just an": rika maybe see here for problem definition |
04:35:16 | FromDiscord | <arathanis> (edit) "https://play.nim-lang.org/#ix=4xNV" => "https://play.nim-lang.org/#ix=4xNW" |
04:35:38 | FromDiscord | <Elegantbeef> Well Nim allows you to use uninstantiated generics, it's just a typeclass 😛 |
04:35:43 | FromDiscord | <graveflo> In reply to @arathanis "ok, i get it.": yea but that makes sense that it doesn't work |
04:35:54 | FromDiscord | <Elegantbeef> Since this is a technical conversation pedantry is required |
04:36:13 | FromDiscord | <arathanis> In reply to @graveflo "yea but that makes": i must have misunderstood your goal if this is not what we were just talking about |
04:36:32 | FromDiscord | <graveflo> no it is mb |
04:36:46 | FromDiscord | <Elegantbeef> The issue is mainly that there is no way to make what arath posted work |
04:36:51 | FromDiscord | <graveflo> my thing is that there should be something to refer to in the seq's generics |
04:36:56 | FromDiscord | <Elegantbeef> The only way is to explicitly declare a base type |
04:37:01 | FromDiscord | <odexine> In reply to @graveflo "rika maybe see here": I’ll take a look thanks |
04:37:19 | FromDiscord | <Elegantbeef> Since there is no implicitly made base type for generics inheriting from `RootObj` |
04:38:20 | FromDiscord | <odexine> I don’t understand, you want to mix generics and inheritance? |
04:39:01 | FromDiscord | <Elegantbeef> Fuuuuck |
04:39:09 | FromDiscord | <Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=4xNY |
04:39:11 | FromDiscord | <graveflo> not necessarily. I do want type information though. I also want the ability to override my procs |
04:39:16 | FromDiscord | <Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=4xNZ |
04:39:17 | FromDiscord | <Elegantbeef> They do not want to explictly declare that base type |
04:39:41 | FromDiscord | <Elegantbeef> They want the compiler to give them a way to refer to "A Base of MyType that is distinct from RootObj" |
04:40:04 | FromDiscord | <odexine> That sounds strange |
04:40:39 | FromDiscord | <Elegantbeef> It's strange to represent |
04:40:50 | FromDiscord | <Elegantbeef> Mainly due to Nim's type language |
04:41:03 | FromDiscord | <arathanis> So if i understand correctly |
04:41:11 | FromDiscord | <arathanis> the full issue is the example I typed |
04:41:21 | FromDiscord | <arathanis> but slightly extended |
04:41:39 | FromDiscord | <arathanis> mainly that `seq[ref RootObj]` would work, but we dont want to accept any ref object |
04:41:43 | FromDiscord | <arathanis> just our type |
04:41:51 | FromDiscord | <arathanis> and currently you have to specify an empty intermediary type |
04:41:55 | FromDiscord | <arathanis> if you want to provide that kind of limit |
04:42:40 | FromDiscord | <Elegantbeef> Correct |
04:42:51 | FromDiscord | <odexine> I mean I don’t think there’s a construction to do that, how does one distinguish between something you want to allow and don’t want to allow |
04:42:58 | FromDiscord | <arathanis> sent a code paste, see https://play.nim-lang.org/#ix=4xO0 |
04:43:12 | FromDiscord | <arathanis> i think i have an extra ref |
04:43:17 | FromDiscord | <Elegantbeef> There is no implicit branch of `RootObj` made for a generic inheritance which makes sense as there is no implicit type |
04:43:26 | FromDiscord | <Elegantbeef> No that's correct |
04:43:31 | FromDiscord | <graveflo> sent a code paste, see https://play.nim-lang.org/#ix=4xO2 |
04:43:38 | FromDiscord | <Elegantbeef> Also you can just do `e1 = Example[int](val: 10)` 😛 |
04:44:00 | FromDiscord | <Elegantbeef> I mean you didnt really fix it grave |
04:44:05 | FromDiscord | <Elegantbeef> All you did was the exact same thing |
04:44:05 | FromDiscord | <arathanis> In reply to @Elegantbeef "Also you can just": dont need new? |
04:44:14 | FromDiscord | <Elegantbeef> Ref types heap allocate on construction |
04:44:18 | FromDiscord | <odexine> In reply to @graveflo "and the kicker is": The T of the why type doesn’t really do anything here I don’t think? |
04:44:19 | FromDiscord | <arathanis> nice! til |
04:44:27 | FromDiscord | <Elegantbeef> Indeed rika |
04:44:56 | FromDiscord | <graveflo> wdym it doesn't do anything? |
04:45:10 | FromDiscord | <odexine> It’s not functional in the program and can be safely removed with nothing changing IIRC |
04:45:15 | FromDiscord | <Elegantbeef> You've 'solved' it by turning the manually written code into a generic |
04:45:24 | FromDiscord | <Elegantbeef> Well rika it's type attached to differentiate between |
04:45:47 | FromDiscord | <Elegantbeef> the idea is you can do `seq[MyBase[Example[RootObj]]` and `seq[Mybase[OtherType[RootObj]]` |
04:45:48 | FromDiscord | <graveflo> thats my point is that it doesn't need to be manual! |
04:45:58 | FromDiscord | <odexine> Ah but then it’s just making a generic base type |
04:46:05 | FromDiscord | <graveflo> yes |
04:46:06 | FromDiscord | <odexine> And if you’re trying to remove the base type |
04:46:10 | FromDiscord | <odexine> What does it matter |
04:46:21 | FromDiscord | <Elegantbeef> It's the same thing but way less readable |
04:46:26 | FromDiscord | <graveflo> indeed |
04:47:18 | FromDiscord | <graveflo> its not supposed to be an example of how it should look. It's an example of the problem being automated away |
04:47:35 | FromDiscord | <Elegantbeef> Well it's not really automated away imo, but you do you |
04:49:13 | FromDiscord | <graveflo> how? every time I make a subclass of `RootObj` I could say `object of WhyDoIExist[X[RootObj]]` and refer to it as `WhyDoIExist[Example[RootObj]]`. It looks like total trash but the point is that the language can do this with simple substitutions |
04:49:23 | FromDiscord | <graveflo> (edit) "`WhyDoIExist[Example[RootObj]]`." => "`WhyDoIExist[X[RootObj]]`." |
04:49:51 | FromDiscord | <Elegantbeef> You're still doing the exact same thing but using a generic instead of an explicit type |
04:50:05 | FromDiscord | <graveflo> you really think I dont know that |
04:50:16 | FromDiscord | <Elegantbeef> It's the difference of `ref object of RootObj` |
04:50:32 | FromDiscord | <Elegantbeef> which is pretty much lost when you have to do `import mybasemodule` |
04:51:04 | FromDiscord | <Elegantbeef> And you have to export that type so if anyone wants to use it they can do the same |
04:51:59 | FromDiscord | <graveflo> I don't want it to work like this. I'm saying that it can't be too hard to fix if an automated version of it exists and the mechanism is simple |
04:52:08 | FromDiscord | <Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=4xO5 |
04:52:16 | * | rockcavera quit (Remote host closed the connection) |
04:53:04 | FromDiscord | <Elegantbeef> Well the difficult part is all on how do you refer to this type |
04:53:08 | FromDiscord | <leorize> what is this problem that we are discussing? |
04:53:15 | FromDiscord | <Elegantbeef> Fucking hell |
04:53:16 | FromDiscord | <Elegantbeef> Scroll up leo |
04:53:22 | FromDiscord | <Elegantbeef> This is the 12th time we've talked about it |
04:53:33 | FromDiscord | <graveflo> ok thats fine beef. I clearly have not been calling this `WhyDoIExist` generic practical. Its like math. Its supposed to just represent logic. This problem is reducible |
04:54:02 | FromDiscord | <leorize> I read it but I don't even know what are you guys talking about by now |
04:54:19 | FromDiscord | <Elegantbeef> It doesnt really matter what you call it |
04:54:19 | FromDiscord | <Elegantbeef> You still need to have it in all your modules and probably want to export it |
04:54:24 | FromDiscord | <Elegantbeef> Replacing this |
04:54:25 | FromDiscord | <Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=4xNZ |
04:54:33 | FromDiscord | <Elegantbeef> Making it so `MyTypeBase` is not needed to do type erasures |
04:56:34 | FromDiscord | <graveflo> or just have a way to refer to something that clearly already exists without imports or anything more then inheriting from `RootObj` , like your `ref object of GenObj` for instance |
05:00:41 | * | oldpcuser_ joined #nim |
05:01:09 | * | oldpcuser_ quit (Read error: Connection reset by peer) |
05:01:52 | * | oldpcuser_ joined #nim |
05:02:07 | * | oldpcuser quit (Ping timeout: 240 seconds) |
05:02:29 | FromDiscord | <graveflo> sent a long message, see http://ix.io/4xO7 |
05:02:43 | * | oldpcuser_ is now known as oldpcuser |
05:04:00 | FromDiscord | <odexine> Okay |
05:04:08 | FromDiscord | <odexine> So you want a root object that can be tagged |
05:04:27 | FromDiscord | <odexine> Without manually making a type that acts as that tag |
05:05:45 | FromDiscord | <graveflo> yea because thats how the rest of the lang work. It has 0 overhead. It wouldn't require refactoring to "enable" data abstraction for generic RootObjs. If you really think about it there should already be a way to do this but there isn't |
05:06:08 | FromDiscord | <odexine> Because I don’t think anyone who has had the need to yet |
05:06:17 | FromDiscord | <odexine> (edit) removed "who" |
05:06:23 | FromDiscord | <odexine> So no one has made it |
05:06:36 | FromDiscord | <graveflo> like if you just have a seq of pointers and there is an easy way to reason about how the data are constrained in the type system you should be able to make that seq right? |
05:07:12 | FromDiscord | <graveflo> and I mean pointers in the raw mem sense not nim's `pointer` type |
05:07:38 | FromDiscord | <odexine> In reply to @graveflo "like if you just": I understand what you say but don’t see what you mean |
05:07:54 | FromDiscord | <graveflo> the whole point of these types is to represent the raw mem. Just now there is not type of a seq of pointers that are all of "this" generic object type |
05:08:05 | * | oldpcuser quit (Ping timeout: 250 seconds) |
05:08:27 | FromDiscord | <graveflo> (edit) "not" => "no" | "of" => "for" |
05:08:50 | FromDiscord | <odexine> There is, just not for generics AND inheritance without the base type as well |
05:09:01 | FromDiscord | <odexine> Which I think a good amount of us would say is very specific |
05:09:38 | FromDiscord | <graveflo> well without inheritance I think you cannot disambiguate the data anyway. You pull the data out of RAM and what type is it? There no type info |
05:09:51 | FromDiscord | <odexine> It would be… the generic type |
05:10:29 | FromDiscord | <odexine> ?? I’m honestly just completely confused as to what you are intending to do or say at this rate |
05:10:39 | FromDiscord | <graveflo> but then how would you know how much memory to copy? |
05:11:06 | FromDiscord | <odexine> The generic type is made concrete at compile time and that is the only type you would be able to store in the sequence |
05:11:20 | * | oldpcuser joined #nim |
05:11:27 | FromDiscord | <odexine> Maybe it would be best to talk about the use case |
05:11:37 | FromDiscord | <graveflo> right ok |
05:11:40 | FromDiscord | <odexine> Because I don’t know why you’d mix them, sorry |
05:12:02 | * | oldpcuser quit (Read error: Connection reset by peer) |
05:12:45 | FromDiscord | <graveflo> if you aren't using `method` you have to rely on generics for polymorphism. If you do say `varags` now you have a situation where you can have multiple types and that is fine |
05:13:02 | FromDiscord | <graveflo> the problem is you cant formulate the `varargs` statement bc its not possible with a shim alias |
05:13:28 | FromDiscord | <graveflo> if you are an API dev that is bad. `varargs` are only one in many cases where this abstraction matters |
05:13:54 | * | oldpcuser joined #nim |
05:15:18 | * | oldpcuser is now known as oldpcuser_afk |
05:15:26 | FromDiscord | <odexine> What would varargs come up for this i don't know either sorry, im still trying to think how this can be reformulayed |
05:15:37 | FromDiscord | <graveflo> basically you use inheritance for data abstraction and you use generics for proc abstraction. If you aren't using `method` I dont see how making extensible code is possible with generic inheritance |
05:15:40 | FromDiscord | <Elegantbeef> You could use a tuple instead of varargs |
05:15:50 | FromDiscord | <graveflo> thats a good point |
05:16:06 | FromDiscord | <graveflo> wait what type is the tuple then? |
05:16:17 | FromDiscord | <graveflo> it would still need to be box typed no? |
05:16:19 | FromDiscord | <Elegantbeef> The type of each field |
05:16:22 | FromDiscord | <Elegantbeef> Of course not |
05:16:24 | FromDiscord | <odexine> Tuples would have whatever types are declared in it |
05:16:34 | FromDiscord | <odexine> They can be homogeneous |
05:16:37 | FromDiscord | <Elegantbeef> Tuples are a product type |
05:16:45 | FromDiscord | <graveflo> each field can by any of the generic instances tho |
05:16:49 | FromDiscord | <Elegantbeef> Right |
05:17:01 | FromDiscord | <Elegantbeef> We do not need inheritance to do anything there |
05:17:50 | FromDiscord | <graveflo> hmmm ok I think I see what you are saying. As long as there is no way to make a proc call with variable length arguments at run time that should work |
05:18:07 | FromDiscord | <graveflo> which the lang itself prob restricts that. I'm not sure if that even makes sense |
05:18:21 | FromDiscord | <graveflo> but anyway the `seq` example is a good one because that is something that people do often |
05:18:37 | FromDiscord | <Elegantbeef> Eh people use sumtypes there more often than inheritance |
05:18:58 | FromDiscord | <graveflo> you are supposed to be able to do data abstraction. You need generic objects for polymorphism without `method` you shouldn't have generic `methods` and that leaves you with only one choice rly |
05:19:03 | FromDiscord | <odexine> When it comes to homogeneous sequences we mostly point people at sum types yeah |
05:19:08 | FromDiscord | <Elegantbeef> The only time I've use inheritance is in places that it's hard to represent the data statically, like GUI |
05:19:26 | FromDiscord | <graveflo> who needs those right? |
05:19:39 | FromDiscord | <Elegantbeef> My game sadly |
05:19:53 | FromDiscord | <Elegantbeef> I mean my gui doesnt even use type erasure anymore really |
05:20:05 | FromDiscord | <Elegantbeef> So I dont even use inheritance there for that reason |
05:20:09 | FromDiscord | <Elegantbeef> I use it purely for field copying 😄 |
05:20:12 | FromDiscord | <graveflo> gui are a good example of a complex program |
05:20:24 | FromDiscord | <graveflo> inheritance helps with modeling complexity lets just leave it at that |
05:20:39 | FromDiscord | <graveflo> i mean idc we can keep talking about it but it is that simple |
05:20:40 | FromDiscord | <Elegantbeef> Eh composition is nicer than inheritance 😛 |
05:21:09 | FromDiscord | <graveflo> I agree but it doesn't solve everything |
05:21:09 | FromDiscord | <Elegantbeef> The main nice thing that inheritance gives you is easy field copying |
05:22:29 | FromDiscord | <Elegantbeef> `join(AType, BType)` seems like a fantastic idea now that I think about it |
05:23:03 | FromDiscord | <Elegantbeef> making a new object with the fields of all objects inside `join` |
05:23:07 | FromDiscord | <graveflo> is that like a glue operation that composes a new type via concatenation basically? |
05:23:31 | FromDiscord | <Elegantbeef> Then one can use concepts and expose the procedures and a "base" type |
05:23:46 | FromDiscord | <graveflo> as long as it allowed the procs of both types to work and understand their correct offsets that would be very useful |
05:24:09 | FromDiscord | <graveflo> i meant hey would have to be generic ofc |
05:24:37 | FromDiscord | <Elegantbeef> I mean the procs that operate would be generics |
05:25:21 | FromDiscord | <graveflo> so this is why I'm using inheritance. I need to give the people who use my api the ability to override many of the procs I write. You dont get that without name clashes in nim unless you inherit |
05:25:23 | FromDiscord | <graveflo> as far as I know |
05:25:29 | FromDiscord | <Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=4xOa |
05:25:45 | FromDiscord | <Elegantbeef> You do not need inheritance to override |
05:25:55 | FromDiscord | <Elegantbeef> Nim has overloading built in |
05:26:06 | FromDiscord | <graveflo> but they will have the same parameters and types? |
05:26:12 | FromDiscord | <graveflo> nim will say its too ambigous |
05:26:20 | FromDiscord | <graveflo> (edit) "ambigous" => "ambiguous" |
05:26:29 | FromDiscord | <Elegantbeef> Uhh |
05:27:00 | FromDiscord | <Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=4xOb |
05:27:30 | FromDiscord | <graveflo> LOL |
05:28:12 | FromDiscord | <graveflo> maybe I have to refactor again |
05:28:36 | FromDiscord | <Elegantbeef> Perhaps, I do know I have an odd thing with my GUI due to inheritance and generics |
05:28:53 | FromDiscord | <graveflo> wait but how do you call the api version and not the override version |
05:28:55 | FromDiscord | <Elegantbeef> I'm tempted to rewrite the GUI to be inheritance free using that `join` idea |
05:29:44 | FromDiscord | <Elegantbeef> sent a code paste, see https://paste.rs/FOi4y |
05:29:49 | FromDiscord | <Elegantbeef> That's one way |
05:29:53 | FromDiscord | <graveflo> also this will take away the ability to have abstraction layers I think |
05:30:23 | FromDiscord | <Elegantbeef> The above only works due to the concrete type |
05:30:30 | * | disso-peach quit (Quit: Leaving) |
05:31:13 | FromDiscord | <Elegantbeef> Fuuck that join macro is going to fester in my head |
05:31:33 | FromDiscord | <graveflo> well you dont want something to match for all objects when its not meant to |
05:31:40 | FromDiscord | <graveflo> and thats only a hack that works on 1 level |
05:31:52 | FromDiscord | <graveflo> because technically object is below any user type |
05:32:23 | FromDiscord | <Elegantbeef> There are plenty of libraries that use generic dispatch to allow overriding |
05:32:24 | FromDiscord | <graveflo> inheritance is difficult to get rid of when you are modeling complex systems its jut the way it is |
05:32:42 | FromDiscord | <graveflo> I dont need a library beef. Nim works so well im pretty much floored |
05:32:47 | FromDiscord | <Elegantbeef> It's really not that difficult to git rid if cause like I said I'm not using inheritance |
05:32:48 | FromDiscord | <graveflo> its just missing a thing or two |
05:32:56 | FromDiscord | <Elegantbeef> Reread what i said |
05:33:24 | FromDiscord | <graveflo> I dont need to get rid of it bc I dont use it unless I need it. I dont use it for everything thats when you get horror stories |
05:33:46 | FromDiscord | <Elegantbeef> > There are plenty of libraries that use generic dispatch to allow overriding |
05:33:57 | FromDiscord | <Elegantbeef> "that use" |
05:34:13 | FromDiscord | <graveflo> that wasn't the part I thought was significant |
05:34:16 | FromDiscord | <graveflo> wdym |
05:34:31 | FromDiscord | <Elegantbeef> There are libraries that use generic dispatch to allow overriding built in functionality |
05:34:55 | FromDiscord | <Elegantbeef> Pretty much any Nim parsing library `std/jsonutils` `jsony`, `jason` uses it |
05:35:17 | FromDiscord | <Elegantbeef> you can easily do `myModule.doThing(myArg)` to call the base procedure |
05:35:54 | FromDiscord | <graveflo> I'll look into them. Sometimes you just don't need something complicated though. Inheritance can be very simple and elegant. So many times Ive seen people re-implement OOP and call it something else |
05:36:43 | FromDiscord | <Elegantbeef> I mean I'd be re-implementing the field copying of inheritance, but ideally without making dispatch rules convoluted |
05:37:14 | FromDiscord | <graveflo> hey sounds good to me |
05:37:18 | FromDiscord | <Elegantbeef> Ah nvm I take it back it'd have the same issues |
05:37:44 | FromDiscord | <Elegantbeef> It'd actually be worse 😄 |
05:40:54 | FromDiscord | <graveflo> sent a code paste, see https://play.nim-lang.org/#ix=4xOe |
05:41:15 | FromDiscord | <graveflo> because I never really figured it out |
05:42:31 | FromDiscord | <Elegantbeef> It works |
05:42:44 | FromDiscord | <Elegantbeef> I told you before though |
05:43:06 | FromDiscord | <Elegantbeef> `[T: object]` and `[Y; T: GenericObj[Y]]` are the same mismatch level |
05:43:10 | FromDiscord | <Elegantbeef> Both are generic mismatches |
05:43:15 | FromDiscord | <Elegantbeef> or matches |
05:43:26 | FromDiscord | <Elegantbeef> `[T](param: GenericObj[T])` works |
05:44:00 | FromDiscord | <Elegantbeef> Cause the when doing sigmatch it sees "hey this is a GenericObj`and`T`matches, in the otherway it just sees`T`constrained to`GenericObj\` |
05:44:04 | FromDiscord | <Elegantbeef> Whoops |
05:44:38 | FromDiscord | <Elegantbeef> Anyway point is constraining a generic does not make it more correct match |
05:44:41 | FromDiscord | <graveflo> ok so matching happens in the `()` and the `[]` is just preamble basically? |
05:45:04 | FromDiscord | <Elegantbeef> in both cases `param: T` is hit and it goes "Hey these are both generic parameters so equivalent matches" |
05:45:45 | FromDiscord | <graveflo> then why doesn't `Something()` match `T` in the first example |
05:45:53 | FromDiscord | <graveflo> an unconstrained generic should match |
05:46:06 | FromDiscord | <Elegantbeef> It is constrained though |
05:46:33 | FromDiscord | <graveflo> so in this verbage constraints != binding rules |
05:46:47 | FromDiscord | <Elegantbeef> constraint means `T: Y` |
05:46:51 | FromDiscord | <Elegantbeef> Y is the constraint |
05:47:15 | FromDiscord | <graveflo> so in the fist example the constraint is `T` |
05:47:22 | FromDiscord | <Elegantbeef> No |
05:47:30 | FromDiscord | <Elegantbeef> `object` and `GenObj[Y]` |
05:47:41 | FromDiscord | <graveflo> oh oops right |
05:48:38 | FromDiscord | <Elegantbeef> In the first example you call a procedure it goes "Ok no generic parameters specified let's look at the first parameter, oh it's constrained to GenObj[Y], do we match that? No... ok it's a overload error" |
05:48:41 | FromDiscord | <graveflo> so in the second example the constraint is `GenObj[Y]` and then `object` |
05:49:07 | FromDiscord | <Elegantbeef> In the second example that first dispatch doesnt match so it goes to the next procedure, finds `object` it passes so is dispatched |
05:49:20 | FromDiscord | <Elegantbeef> In the third example it passes for obvious reasons |
05:49:45 | FromDiscord | <Elegantbeef> In the fourth example it hits `object` and that's a match, but so is `GenObj[Y]` as they're equal matches it errors |
05:50:36 | FromDiscord | <Elegantbeef> Now you're looking at your screen pointing "But one is GenObj", right but it's a constraint not an instantiation, so it's checked ever so slightly different |
05:50:47 | FromDiscord | <Elegantbeef> That difference can benefit in some cases |
05:51:20 | FromDiscord | <Elegantbeef> Like with a concept `proc doThing[T: SomeConcept](t: T) = echo typeof(t)` prints the actual type whereas `proc doThing(t: SomeConcept) = echo typeof(t)` will always print "SomeConcept" |
05:51:21 | FromDiscord | <graveflo> I don't understand how `GenObj[Y]` doesn't match "better" then `object` . I'm able to override procs that match `object` and the type all the time |
05:51:31 | FromDiscord | <graveflo> that would make `object` matched procs complete hogs |
05:51:36 | FromDiscord | <Elegantbeef> Right but you do not overload them in the generic procedure |
05:51:59 | FromDiscord | <Elegantbeef> You are attempting to overload object with a generic parameter, that does not work |
05:53:06 | FromDiscord | <Elegantbeef> This sadly only applies to generics |
05:54:28 | FromDiscord | <graveflo> sent a code paste, see https://play.nim-lang.org/#ix=4xOh |
05:54:47 | FromDiscord | <graveflo> but if you are sure that this is correct maybe I just need to take a minute and come back to it another time |
05:55:32 | FromDiscord | <Elegantbeef> I mean Nim's generics are never 'correct' 😛 |
05:55:32 | FromDiscord | <Elegantbeef> They're a travesty |
05:55:33 | FromDiscord | <Elegantbeef> But it is what it is |
05:55:35 | FromDiscord | <graveflo> (edit) "this is correct" => "the matching rules are understandable" |
05:55:40 | FromDiscord | <Elegantbeef> sent a code paste, see https://paste.rs/8bsos |
05:56:08 | FromDiscord | <Elegantbeef> It's simply that a generic inside generic parameters is considered the same level as a typeclass |
05:57:04 | FromDiscord | <Elegantbeef> As such both matching does not work, this can be disambiguated using the thing i show above by only putting the generic parameter inside the generic parameter list |
06:03:28 | FromDiscord | <graveflo> ok so it's just that they match generically at the class level and the compiler does no further reasoning about them at that stage |
06:05:02 | FromDiscord | <graveflo> wait no then `GenericObj` should have the same problem but it doesn't... Ah nvm I'll just have to wait to figure this one out I think |
06:05:04 | FromDiscord | <graveflo> thanks though |
08:29:47 | * | PMunch joined #nim |
08:54:22 | * | oldpcuser_ joined #nim |
08:56:04 | * | oldpcuser_ quit (Max SendQ exceeded) |
08:56:28 | * | oldpcuser_afk quit (Ping timeout: 240 seconds) |
08:57:21 | * | oldpcuser_ joined #nim |
09:08:36 | * | junaid_ joined #nim |