<< 09-06-2023 >>
00:04:28*oz quit (Ping timeout: 240 seconds)
00:12:11*ox joined #nim
00:24:39FromDiscord<auxym> wrapping liblzma (with futhark if you want) is an option for xz
00:30:52*derpydoo joined #nim
00:54:44FromDiscord<arathanis> out of curiosity, if you use ref types with `--mm:none` is there a way to explicitly free the references?
00:55:00FromDiscord<arathanis> or since ref is just GC managed ptr, is the expectation "what are you doing just use ptr"
00:55:09FromDiscord<arathanis> (edit) "ptr"" => "ptr if you turn the GC off""
01:06:37*jmd_ quit (Ping timeout: 240 seconds)
01:07:05FromDiscord<Elegantbeef> I imagine you can call `=destroy` but i've not checked
01:55:11FromDiscord<kcvinker> sent a code paste, see https://play.nim-lang.org/#ix=4xNm
01:57:06FromDiscord<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:47FromDiscord<!&luke> sent a code paste, see https://play.nim-lang.org/#ix=4xNn
01:58:16FromDiscord<kcvinker> In reply to @graveflo "what do you mean": If I remove that echo statement, it won't run
01:58:28FromDiscord<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:38FromDiscord<graveflo> In reply to @kcvinker "If I remove that": what is "it"
01:59:05FromDiscord<kcvinker> It is a dll and I am calling from a scripting lang called AutoIt
01:59:08FromDiscord<arathanis> what does "it wont run" mean
01:59:53FromDiscord<graveflo> ok well the `addItems` proc seems to interact via `sendMsg` is this what is failing to happen?
01:59:54FromDiscord<kcvinker> In reply to @arathanis "what does "it wont": Oh, I don't know how to explain that
02:00:05FromDiscord<arathanis> does it crash?
02:00:25FromDiscord<arathanis> like "it wont run" is too nebulous for anyone to help
02:00:30FromDiscord<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:45FromDiscord<kcvinker> In reply to @arathanis "like "it wont run"": Sorry for that
02:01:08FromDiscord<arathanis> that is better, in order to help diagnose the issue we need to know how its failing
02:01:15FromDiscord<arathanis> can you check the generated code?
02:01:31FromDiscord<kcvinker> Nim's generated code is for aliens
02:01:41FromDiscord<arathanis> some of it sure
02:01:49FromDiscord<arathanis> but its usually pretty easy to find your functions and get the ist of it
02:01:51FromDiscord<arathanis> (edit) "ist" => "jist"
02:02:01FromDiscord<arathanis> what i suggest is this
02:02:03FromDiscord<kcvinker> Okay
02:02:11FromDiscord<arathanis> im assuming you are using VS code
02:02:17FromDiscord<kcvinker> Yes
02:02:19FromDiscord<arathanis> compile with the echo statement
02:02:25FromDiscord<arathanis> go grab the generated file and save it somewhere
02:02:26FromDiscord<kcvinker> Yes
02:02:28FromDiscord<arathanis> compile w/o
02:02:31FromDiscord<arathanis> grab the file again
02:02:32FromDiscord<arathanis> do a diff
02:02:34FromDiscord<arathanis> and see just where they differ
02:02:37FromDiscord<kcvinker> Okay
02:02:45FromDiscord<kcvinker> Sounds great
02:02:49FromDiscord<kcvinker> Thanks'
02:02:51FromDiscord<arathanis> maybe you will find something silly like "the compiler is optimizing out something"
02:02:52FromDiscord<kcvinker> Let me try
02:02:56FromDiscord<arathanis> np
02:03:04FromDiscord<arathanis> yeah it can be hard to read but a diff should narrow it way down
02:03:04FromDiscord<arathanis> GL!
02:03:16FromDiscord<kcvinker> Thanks
02:15:01FromDiscord<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:43FromDiscord<kcvinker> sent a code paste, see https://play.nim-lang.org/#ix=4xNr
02:22:52FromDiscord<kcvinker> That slicing
02:24:15*hochata joined #nim
02:27:44*azimut quit (Ping timeout: 240 seconds)
02:50:38FromDiscord<Elegantbeef> @graveflo\: what are you trying to do?
02:51:25FromDiscord<graveflo> populate a seq with ref types restricted to a generic of type `GenObj` or its descendants without making a proxy baseclass
02:51:55FromDiscord<graveflo> or an concrete type generated from a generic
02:52:15FromDiscord<Elegantbeef> Right you have a base type which is the root node
02:52:27FromDiscord<Elegantbeef> `WhyDoIExist` exists cause you need a base node
02:52:34FromDiscord<Elegantbeef> Also do `ref object of RootObj`
02:52:41FromDiscord<graveflo> sent a code paste, see https://play.nim-lang.org/#ix=4xNu
02:53:29FromDiscord<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:59FromDiscord<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:11FromDiscord<Elegantbeef> I mean you need a concrete type
02:55:38FromDiscord<Elegantbeef> You can make a non ref type it's just very very verbose
02:55:48FromDiscord<graveflo> I realize that is the issue with `GenObj` by itself
02:57:25FromDiscord<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:26FromDiscord<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:50FromDiscord<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:51FromDiscord<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:09FromDiscord<graveflo> sent a long message, see http://ix.io/4xNx
03:04:53FromDiscord<graveflo> (edit) "http://ix.io/4xNx" => "http://ix.io/4xNy"
03:06:15FromDiscord<Elegantbeef> i'm so lost
03:06:22FromDiscord<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:21FromDiscord<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:42FromDiscord<Elegantbeef> "enable ref semantics"
03:09:46FromDiscord<Elegantbeef> No you're not after ref semantics
03:09:52FromDiscord<Elegantbeef> You're after inheritance
03:10:10FromDiscord<graveflo> that is a ref semantic in this context
03:10:12FromDiscord<Elegantbeef> Ref semantics does not include type erasure
03:10:30FromDiscord<Elegantbeef> Well a type that does not inherit doesnt have type information on the type
03:11:23FromDiscord<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:33FromDiscord<graveflo> I could call it pointer semantics but its the same thing
03:11:37FromDiscord<Elegantbeef> Then you share the parent
03:11:40FromDiscord<Elegantbeef> It's not pointer semantics
03:11:51FromDiscord<Elegantbeef> It's type erasure which requires type information which means inheritance
03:12:30FromDiscord<graveflo> ok fine. Since this is interacting with the type system they are type semantics
03:13:30FromDiscord<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:49FromDiscord<Elegantbeef> Yea there is a type that doesnt inherit doesnt have RTTI on the data
03:14:06FromDiscord<Elegantbeef> There also is no reason to include the RTTI on it unless you need it
03:14:29FromDiscord<graveflo> inheriting from `RootObj` has this right?
03:14:44FromDiscord<Elegantbeef> Inheriting has type information stored on the value
03:15:00FromDiscord<Elegantbeef> If you really really want this type erasure just make a box type and problem solved
03:15:27FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=4xNB
03:15:43FromDiscord<Elegantbeef> There you go you now have boxed values which means you can store any value inside a collection
03:15:56FromDiscord<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:44FromDiscord<Elegantbeef> Well you want arbitrary types inside a collection, something that is rarely the best solution
03:17:26FromDiscord<graveflo> sent a code paste, see https://paste.rs/y81vn
03:17:41FromDiscord<graveflo> this could be just how the language works and there is nothing to gain from needing this arbitrary restriction
03:17:58FromDiscord<Elegantbeef> Except you now need RTTI on every single type
03:18:01FromDiscord<graveflo> forcing people to use box types doesn't do anything useful it takes away useful things for no reason
03:18:47FromDiscord<graveflo> so a type without a box type will not have RTTI even if they inherit from `RootObj`?
03:19:04FromDiscord<Elegantbeef> They have RTTI if they inherit
03:19:18FromDiscord<Elegantbeef> you can do `seq[RootRef]` if you want to enable all ref types in a collection
03:19:38FromDiscord<graveflo> but not all refs restricted to a base class though
03:20:08FromDiscord<graveflo> alright if inheriting from a class adds complexity then I guess there is a reason to make it explicit
03:20:33FromDiscord<graveflo> well besides the obvious complexity that is
03:20:54FromDiscord<Elegantbeef> So then what's the issue
03:20:59FromDiscord<Elegantbeef> Well it adds RTTI that is otherwise not present
03:21:07FromDiscord<Elegantbeef> And it also means that interop gets more awful
03:21:58FromDiscord<graveflo> sent a code paste, see https://play.nim-lang.org/#ix=4xNC
03:22:12FromDiscord<graveflo> so why doesn't `GenObj` need rti if it is inheriting from `RootObj` ?
03:22:49FromDiscord<Elegantbeef> They both have RTTI
03:23:01FromDiscord<Elegantbeef> `type GenObj[T] = object` does not have RTTI
03:23:05FromDiscord<graveflo> then this whole RTTI thing is a complete misdirection
03:23:25FromDiscord<graveflo> Ive said multiple times I am talking about things that inherit from `RootObj`
03:23:25FromDiscord<Elegantbeef> I thought you wanted to get rid of `Base = object of RootObj`?
03:23:41FromDiscord<Elegantbeef> You have to have a concrete type to be your base
03:24:14FromDiscord<graveflo> but `WhyDoIExist[X[RootObj]]` is a concrete type for `X` so there is no need to manually make a box~
03:24:44FromDiscord<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:53FromDiscord<Elegantbeef> I'm so lost at your point
03:24:54FromDiscord<Elegantbeef> You want to get rid of the `Base = object of RootObj`
03:24:56FromDiscord<graveflo> so its just a useless restriction
03:25:06FromDiscord<graveflo> theres no need for it
03:25:19FromDiscord<graveflo> besides one that is arbitrarily enforced by the lang
03:25:39FromDiscord<Elegantbeef> Sure we agree here then
03:25:48FromDiscord<Elegantbeef> I thought you wanted to make all objects convertible to `RootRef`
03:26:16FromDiscord<Elegantbeef> You sure do write convoluted things instead of just making your point 😛
03:26:35FromDiscord<graveflo> sent a code paste, see https://play.nim-lang.org/#ix=4xND
03:26:56FromDiscord<Elegantbeef> So much work to get around a non issue
03:27:00FromDiscord<graveflo> I'm trying 😅
03:27:21FromDiscord<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:31FromDiscord<Elegantbeef> It's pretty much a non issue
03:27:51FromDiscord<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:49FromDiscord<Elegantbeef> You're just pointlessly implementing things that no one will need/use
03:30:03FromDiscord<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:20FromDiscord<graveflo> the lang might as well have no mechanism for it if there are no use cases
03:30:44FromDiscord<Elegantbeef> What's even disabled?
03:31:09FromDiscord<arathanis> In reply to @kcvinker "<@136570191038513152> Found the problem": nice!
03:31:15FromDiscord<arathanis> sounds like doing that worked out for you?
03:31:23FromDiscord<arathanis> did you also find a solution or still figuring that part out?
03:32:39FromDiscord<graveflo> sent a code paste, see https://play.nim-lang.org/#ix=4xNH
03:33:57FromDiscord<Elegantbeef> Nothing cause there is no type language for this specific scenario
03:34:31FromDiscord<graveflo> ok its not a bug its a feature sure
03:34:33*oldpcuser_ joined #nim
03:34:42FromDiscord<Elegantbeef> I mean it's a lacking place in the language
03:34:45FromDiscord<Elegantbeef> It's not disabling anything
03:35:11FromDiscord<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:17FromDiscord<Elegantbeef> You need to have a common ancestor and `GenObj` is not a common ancestor
03:35:21FromDiscord<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:15FromDiscord<graveflo> I'm not saying it should be `GenObj` beef
03:36:35FromDiscord<graveflo> I'm saying the box method is a work around at best
03:36:37*oldpcuser quit (Ping timeout: 240 seconds)
03:36:52FromDiscord<Elegantbeef> I say it's a solution as it gives a common ancestor
03:37:15FromDiscord<graveflo> it should have one already. Making one automatically has a 0 cost
03:37:21FromDiscord<Elegantbeef> Like how do you express "any GenObj" in your ideal world?
03:37:34FromDiscord<Elegantbeef> `(ref GenObj)`?
03:37:39FromDiscord<Elegantbeef> You now overloaded a typeclass
03:37:44*oldpcuser_ joined #nim
03:38:04FromDiscord<graveflo> I'm not sure.. what would `GenObj[RootObj]` mean here
03:38:07FromDiscord<graveflo> could that be it?
03:38:17FromDiscord<Elegantbeef> Nope
03:38:22FromDiscord<graveflo> or `GenObj[object]`
03:38:34*oldpcuser_ quit (Remote host closed the connection)
03:38:37FromDiscord<graveflo> how about `GenObj[]`
03:38:54FromDiscord<Elegantbeef> The issue is you cannot use that either
03:39:14FromDiscord<Elegantbeef> It creates ambiguity with generic instantitations
03:39:16FromDiscord<graveflo> ok how about this `RootObj[GenObj]` that is more similar to my automated solution
03:39:27FromDiscord<Elegantbeef> That could work
03:39:50FromDiscord<graveflo> and in fact the in lang work around could just make RootObj or another RootObj type generic
03:39:57FromDiscord<graveflo> and just do it the exact way I solved it
03:40:02*oldpcuser joined #nim
03:40:06FromDiscord<Elegantbeef> That's not even required really
03:40:18FromDiscord<graveflo> good it looks weird
03:40:33FromDiscord<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:01FromDiscord<graveflo> well I think it would be a good idea
03:41:05FromDiscord<Elegantbeef> Well `T[auto...]`
03:41:22FromDiscord<Elegantbeef> Where you insert auto for all the generic parameters
03:41:38FromDiscord<Elegantbeef> It still is a convoluted change for something that is easily expressed
03:42:47FromDiscord<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:48FromDiscord<graveflo> period
03:42:54FromDiscord<graveflo> you dont know who is using your code
03:42:59FromDiscord<graveflo> its bad if you have to change it
03:43:16FromDiscord<graveflo> (edit) "wiring" => "writing"
03:43:51*oldpcuser joined #nim
03:44:19FromDiscord<Elegantbeef> It really doesnt cause you shouldnt be using inheritance for all types
03:45:01FromDiscord<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:40FromDiscord<Elegantbeef> I'm saying you shouldnt make all objects use inheritance cause someone might want to inherit from it
03:46:19FromDiscord<graveflo> anything that has usefulness being inherited from would inherit from `RootObj` yes
03:46:45FromDiscord<graveflo> but that's neither here nor there. This is about inheriting from `RootObj` not when should we inherit from `RootObj`
03:48:17FromDiscord<Elegantbeef> Given the alternative explicitly declaring a Root branch type is the lesser of the evils, in my opinion
03:48:43FromDiscord<Elegantbeef> Aside from maybe `seq[ref object of GenObj]` everything is much more convoluted
03:48:55FromDiscord<Elegantbeef> And conflates existent syntax
03:49:07FromDiscord<graveflo> how? it has 0 overhead and you would only use it if you need it
03:49:12FromDiscord<Elegantbeef> Write an RFC if you really feel like this is required
03:49:21FromDiscord<Elegantbeef> I know the compiler's type match and type system
03:49:45FromDiscord<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:05FromDiscord<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:22FromDiscord<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:27FromDiscord<graveflo> I'll submit an RFC maybe if we have confirmed that there is no way to do this
03:50:59FromDiscord<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:13FromDiscord<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:14FromDiscord<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:03FromDiscord<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:13FromDiscord<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:31FromDiscord<Elegantbeef> Nah they just want to not have to box inheriting types
04:19:54FromDiscord<arathanis> im not even sure i understand what "boxing inhereting types" means in this context
04:19:58FromDiscord<graveflo> no you can just make a seq with `RootObj` for that
04:20:04FromDiscord<arathanis> (edit) "inhereting" => "inheriting"
04:20:12FromDiscord<arathanis> In reply to @graveflo "no you can just": dont think "int" is an object
04:20:27FromDiscord<Elegantbeef> A generic inheritance type does not presently have a way to represent "shared parent"
04:20:28FromDiscord<graveflo> its not. This only makes sense for objects with RTTI
04:20:38FromDiscord<graveflo> as beef has taught me this acronym now 😛
04:20:44FromDiscord<Elegantbeef> `type MyType[T] = ref object of RootObj` there is no way of making a `seq[MyType]`
04:21:21FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=4xNT
04:21:51FromDiscord<arathanis> ahh they want sequences of a arbitrary instantiated generics w/o an intermediary
04:22:04FromDiscord<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:21FromDiscord<arathanis> (edit) removed "a"
04:22:25FromDiscord<arathanis> does RootObj not function as an intermediary?
04:22:40FromDiscord<Elegantbeef> You can have `RootRef` or `ref RootObj` yes
04:22:46FromDiscord<Elegantbeef> But the issue is they want only their types
04:22:58FromDiscord<Elegantbeef> Which means there just is no way without declaring your own base to branch `RootObj`
04:23:35FromDiscord<Elegantbeef> Concepts dont work cause they're not concrete `seq[MyType]` doesnt work cause it's not concrete
04:23:35FromDiscord<arathanis> Ah they dont want to support anything that inherits from RootObj
04:23:47FromDiscord<graveflo> Its the same thing you would be going if there were no generic but there is a generic
04:23:55FromDiscord<arathanis> how long have you been working on this?
04:24:06FromDiscord<graveflo> me?
04:24:16FromDiscord<Elegantbeef> I mean that generic is a very big differentiater 😛
04:24:30FromDiscord<Elegantbeef> It means there is no injected concrete symbol to convert to
04:25:02FromDiscord<arathanis> In reply to @graveflo "me?": yes
04:25:13FromDiscord<graveflo> I get that but the point of generics is to have something that behaves just like an object would otherwise
04:25:24FromDiscord<graveflo> In reply to @arathanis "yes": working on what though? This isn't a project
04:25:29FromDiscord<arathanis> working on this problem
04:25:35FromDiscord<arathanis> trying to get this to work
04:25:42FromDiscord<graveflo> I just ran into it about 20 min before I made my initial post
04:26:10FromDiscord<arathanis> In reply to @graveflo "I get that but": i dont think this is the point of generics
04:26:41FromDiscord<Elegantbeef> Well not in Nim
04:26:41FromDiscord<Elegantbeef> Generics in Nim are just templated types
04:26:45FromDiscord<Elegantbeef> Which is a shame
04:26:56FromDiscord<arathanis> is there a language where this is the point of generics?
04:27:12FromDiscord<arathanis> everything ive ever read about generics is that they are for code reuse
04:27:22FromDiscord<arathanis> let me find the quote i bet its on wikipedia
04:27:32FromDiscord<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:40FromDiscord<arathanis> found it
04:27:41FromDiscord<arathanis> https://media.discordapp.net/attachments/371759389889003532/1116584376843636877/image.png
04:28:03FromDiscord<Elegantbeef> Cool that quote has no reflection in the real world
04:28:15FromDiscord<arathanis> ¯\_(ツ)_/¯
04:28:30FromDiscord<Elegantbeef> There is no reason you cannot have `any(MyType)` or similar work in Nim
04:28:45FromDiscord<Elegantbeef> It has RTTI and is heap allocated
04:28:48FromDiscord<Elegantbeef> So it's totally possible
04:29:10FromDiscord<arathanis> @graveflo there must be a language whose feature you are trying to duplicate, can I ask what it is?
04:29:15FromDiscord<arathanis> i want to go see the semantics you are going for in practice
04:29:22FromDiscord<Elegantbeef> Generics can exist as real types not just templates
04:29:48FromDiscord<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:27FromDiscord<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:09FromDiscord<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:18FromDiscord<graveflo> thats how the "box method" is known in the first place
04:31:47FromDiscord<odexine> I just got here what is happening
04:32:05FromDiscord<graveflo> (edit) "being" => "people"
04:32:47FromDiscord<Elegantbeef> Talking about generic inheritance not having a base type
04:33:31FromDiscord<odexine> Generic inheritance..?
04:35:05FromDiscord<arathanis> sent a code paste, see https://play.nim-lang.org/#ix=4xNV
04:35:11FromDiscord<graveflo> In reply to @graveflo "This is just an": rika maybe see here for problem definition
04:35:16FromDiscord<arathanis> (edit) "https://play.nim-lang.org/#ix=4xNV" => "https://play.nim-lang.org/#ix=4xNW"
04:35:38FromDiscord<Elegantbeef> Well Nim allows you to use uninstantiated generics, it's just a typeclass 😛
04:35:43FromDiscord<graveflo> In reply to @arathanis "ok, i get it.": yea but that makes sense that it doesn't work
04:35:54FromDiscord<Elegantbeef> Since this is a technical conversation pedantry is required
04:36:13FromDiscord<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:32FromDiscord<graveflo> no it is mb
04:36:46FromDiscord<Elegantbeef> The issue is mainly that there is no way to make what arath posted work
04:36:51FromDiscord<graveflo> my thing is that there should be something to refer to in the seq's generics
04:36:56FromDiscord<Elegantbeef> The only way is to explicitly declare a base type
04:37:01FromDiscord<odexine> In reply to @graveflo "rika maybe see here": I’ll take a look thanks
04:37:19FromDiscord<Elegantbeef> Since there is no implicitly made base type for generics inheriting from `RootObj`
04:38:20FromDiscord<odexine> I don’t understand, you want to mix generics and inheritance?
04:39:01FromDiscord<Elegantbeef> Fuuuuck
04:39:09FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=4xNY
04:39:11FromDiscord<graveflo> not necessarily. I do want type information though. I also want the ability to override my procs
04:39:16FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=4xNZ
04:39:17FromDiscord<Elegantbeef> They do not want to explictly declare that base type
04:39:41FromDiscord<Elegantbeef> They want the compiler to give them a way to refer to "A Base of MyType that is distinct from RootObj"
04:40:04FromDiscord<odexine> That sounds strange
04:40:39FromDiscord<Elegantbeef> It's strange to represent
04:40:50FromDiscord<Elegantbeef> Mainly due to Nim's type language
04:41:03FromDiscord<arathanis> So if i understand correctly
04:41:11FromDiscord<arathanis> the full issue is the example I typed
04:41:21FromDiscord<arathanis> but slightly extended
04:41:39FromDiscord<arathanis> mainly that `seq[ref RootObj]` would work, but we dont want to accept any ref object
04:41:43FromDiscord<arathanis> just our type
04:41:51FromDiscord<arathanis> and currently you have to specify an empty intermediary type
04:41:55FromDiscord<arathanis> if you want to provide that kind of limit
04:42:40FromDiscord<Elegantbeef> Correct
04:42:51FromDiscord<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:58FromDiscord<arathanis> sent a code paste, see https://play.nim-lang.org/#ix=4xO0
04:43:12FromDiscord<arathanis> i think i have an extra ref
04:43:17FromDiscord<Elegantbeef> There is no implicit branch of `RootObj` made for a generic inheritance which makes sense as there is no implicit type
04:43:26FromDiscord<Elegantbeef> No that's correct
04:43:31FromDiscord<graveflo> sent a code paste, see https://play.nim-lang.org/#ix=4xO2
04:43:38FromDiscord<Elegantbeef> Also you can just do `e1 = Example[int](val: 10)` 😛
04:44:00FromDiscord<Elegantbeef> I mean you didnt really fix it grave
04:44:05FromDiscord<Elegantbeef> All you did was the exact same thing
04:44:05FromDiscord<arathanis> In reply to @Elegantbeef "Also you can just": dont need new?
04:44:14FromDiscord<Elegantbeef> Ref types heap allocate on construction
04:44:18FromDiscord<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:19FromDiscord<arathanis> nice! til
04:44:27FromDiscord<Elegantbeef> Indeed rika
04:44:56FromDiscord<graveflo> wdym it doesn't do anything?
04:45:10FromDiscord<odexine> It’s not functional in the program and can be safely removed with nothing changing IIRC
04:45:15FromDiscord<Elegantbeef> You've 'solved' it by turning the manually written code into a generic
04:45:24FromDiscord<Elegantbeef> Well rika it's type attached to differentiate between
04:45:47FromDiscord<Elegantbeef> the idea is you can do `seq[MyBase[Example[RootObj]]` and `seq[Mybase[OtherType[RootObj]]`
04:45:48FromDiscord<graveflo> thats my point is that it doesn't need to be manual!
04:45:58FromDiscord<odexine> Ah but then it’s just making a generic base type
04:46:05FromDiscord<graveflo> yes
04:46:06FromDiscord<odexine> And if you’re trying to remove the base type
04:46:10FromDiscord<odexine> What does it matter
04:46:21FromDiscord<Elegantbeef> It's the same thing but way less readable
04:46:26FromDiscord<graveflo> indeed
04:47:18FromDiscord<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:35FromDiscord<Elegantbeef> Well it's not really automated away imo, but you do you
04:49:13FromDiscord<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:23FromDiscord<graveflo> (edit) "`WhyDoIExist[Example[RootObj]]`." => "`WhyDoIExist[X[RootObj]]`."
04:49:51FromDiscord<Elegantbeef> You're still doing the exact same thing but using a generic instead of an explicit type
04:50:05FromDiscord<graveflo> you really think I dont know that
04:50:16FromDiscord<Elegantbeef> It's the difference of `ref object of RootObj`
04:50:32FromDiscord<Elegantbeef> which is pretty much lost when you have to do `import mybasemodule`
04:51:04FromDiscord<Elegantbeef> And you have to export that type so if anyone wants to use it they can do the same
04:51:59FromDiscord<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:08FromDiscord<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:04FromDiscord<Elegantbeef> Well the difficult part is all on how do you refer to this type
04:53:08FromDiscord<leorize> what is this problem that we are discussing?
04:53:15FromDiscord<Elegantbeef> Fucking hell
04:53:16FromDiscord<Elegantbeef> Scroll up leo
04:53:22FromDiscord<Elegantbeef> This is the 12th time we've talked about it
04:53:33FromDiscord<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:02FromDiscord<leorize> I read it but I don't even know what are you guys talking about by now
04:54:19FromDiscord<Elegantbeef> It doesnt really matter what you call it
04:54:19FromDiscord<Elegantbeef> You still need to have it in all your modules and probably want to export it
04:54:24FromDiscord<Elegantbeef> Replacing this
04:54:25FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=4xNZ
04:54:33FromDiscord<Elegantbeef> Making it so `MyTypeBase` is not needed to do type erasures
04:56:34FromDiscord<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:29FromDiscord<graveflo> sent a long message, see http://ix.io/4xO7
05:02:43*oldpcuser_ is now known as oldpcuser
05:04:00FromDiscord<odexine> Okay
05:04:08FromDiscord<odexine> So you want a root object that can be tagged
05:04:27FromDiscord<odexine> Without manually making a type that acts as that tag
05:05:45FromDiscord<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:08FromDiscord<odexine> Because I don’t think anyone who has had the need to yet
05:06:17FromDiscord<odexine> (edit) removed "who"
05:06:23FromDiscord<odexine> So no one has made it
05:06:36FromDiscord<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:12FromDiscord<graveflo> and I mean pointers in the raw mem sense not nim's `pointer` type
05:07:38FromDiscord<odexine> In reply to @graveflo "like if you just": I understand what you say but don’t see what you mean
05:07:54FromDiscord<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:27FromDiscord<graveflo> (edit) "not" => "no" | "of" => "for"
05:08:50FromDiscord<odexine> There is, just not for generics AND inheritance without the base type as well
05:09:01FromDiscord<odexine> Which I think a good amount of us would say is very specific
05:09:38FromDiscord<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:51FromDiscord<odexine> It would be… the generic type
05:10:29FromDiscord<odexine> ?? I’m honestly just completely confused as to what you are intending to do or say at this rate
05:10:39FromDiscord<graveflo> but then how would you know how much memory to copy?
05:11:06FromDiscord<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:27FromDiscord<odexine> Maybe it would be best to talk about the use case
05:11:37FromDiscord<graveflo> right ok
05:11:40FromDiscord<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:45FromDiscord<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:02FromDiscord<graveflo> the problem is you cant formulate the `varargs` statement bc its not possible with a shim alias
05:13:28FromDiscord<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:26FromDiscord<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:37FromDiscord<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:40FromDiscord<Elegantbeef> You could use a tuple instead of varargs
05:15:50FromDiscord<graveflo> thats a good point
05:16:06FromDiscord<graveflo> wait what type is the tuple then?
05:16:17FromDiscord<graveflo> it would still need to be box typed no?
05:16:19FromDiscord<Elegantbeef> The type of each field
05:16:22FromDiscord<Elegantbeef> Of course not
05:16:24FromDiscord<odexine> Tuples would have whatever types are declared in it
05:16:34FromDiscord<odexine> They can be homogeneous
05:16:37FromDiscord<Elegantbeef> Tuples are a product type
05:16:45FromDiscord<graveflo> each field can by any of the generic instances tho
05:16:49FromDiscord<Elegantbeef> Right
05:17:01FromDiscord<Elegantbeef> We do not need inheritance to do anything there
05:17:50FromDiscord<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:07FromDiscord<graveflo> which the lang itself prob restricts that. I'm not sure if that even makes sense
05:18:21FromDiscord<graveflo> but anyway the `seq` example is a good one because that is something that people do often
05:18:37FromDiscord<Elegantbeef> Eh people use sumtypes there more often than inheritance
05:18:58FromDiscord<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:03FromDiscord<odexine> When it comes to homogeneous sequences we mostly point people at sum types yeah
05:19:08FromDiscord<Elegantbeef> The only time I've use inheritance is in places that it's hard to represent the data statically, like GUI
05:19:26FromDiscord<graveflo> who needs those right?
05:19:39FromDiscord<Elegantbeef> My game sadly
05:19:53FromDiscord<Elegantbeef> I mean my gui doesnt even use type erasure anymore really
05:20:05FromDiscord<Elegantbeef> So I dont even use inheritance there for that reason
05:20:09FromDiscord<Elegantbeef> I use it purely for field copying 😄
05:20:12FromDiscord<graveflo> gui are a good example of a complex program
05:20:24FromDiscord<graveflo> inheritance helps with modeling complexity lets just leave it at that
05:20:39FromDiscord<graveflo> i mean idc we can keep talking about it but it is that simple
05:20:40FromDiscord<Elegantbeef> Eh composition is nicer than inheritance 😛
05:21:09FromDiscord<graveflo> I agree but it doesn't solve everything
05:21:09FromDiscord<Elegantbeef> The main nice thing that inheritance gives you is easy field copying
05:22:29FromDiscord<Elegantbeef> `join(AType, BType)` seems like a fantastic idea now that I think about it
05:23:03FromDiscord<Elegantbeef> making a new object with the fields of all objects inside `join`
05:23:07FromDiscord<graveflo> is that like a glue operation that composes a new type via concatenation basically?
05:23:31FromDiscord<Elegantbeef> Then one can use concepts and expose the procedures and a "base" type
05:23:46FromDiscord<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:09FromDiscord<graveflo> i meant hey would have to be generic ofc
05:24:37FromDiscord<Elegantbeef> I mean the procs that operate would be generics
05:25:21FromDiscord<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:23FromDiscord<graveflo> as far as I know
05:25:29FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=4xOa
05:25:45FromDiscord<Elegantbeef> You do not need inheritance to override
05:25:55FromDiscord<Elegantbeef> Nim has overloading built in
05:26:06FromDiscord<graveflo> but they will have the same parameters and types?
05:26:12FromDiscord<graveflo> nim will say its too ambigous
05:26:20FromDiscord<graveflo> (edit) "ambigous" => "ambiguous"
05:26:29FromDiscord<Elegantbeef> Uhh
05:27:00FromDiscord<Elegantbeef> sent a code paste, see https://play.nim-lang.org/#ix=4xOb
05:27:30FromDiscord<graveflo> LOL
05:28:12FromDiscord<graveflo> maybe I have to refactor again
05:28:36FromDiscord<Elegantbeef> Perhaps, I do know I have an odd thing with my GUI due to inheritance and generics
05:28:53FromDiscord<graveflo> wait but how do you call the api version and not the override version
05:28:55FromDiscord<Elegantbeef> I'm tempted to rewrite the GUI to be inheritance free using that `join` idea
05:29:44FromDiscord<Elegantbeef> sent a code paste, see https://paste.rs/FOi4y
05:29:49FromDiscord<Elegantbeef> That's one way
05:29:53FromDiscord<graveflo> also this will take away the ability to have abstraction layers I think
05:30:23FromDiscord<Elegantbeef> The above only works due to the concrete type
05:30:30*disso-peach quit (Quit: Leaving)
05:31:13FromDiscord<Elegantbeef> Fuuck that join macro is going to fester in my head
05:31:33FromDiscord<graveflo> well you dont want something to match for all objects when its not meant to
05:31:40FromDiscord<graveflo> and thats only a hack that works on 1 level
05:31:52FromDiscord<graveflo> because technically object is below any user type
05:32:23FromDiscord<Elegantbeef> There are plenty of libraries that use generic dispatch to allow overriding
05:32:24FromDiscord<graveflo> inheritance is difficult to get rid of when you are modeling complex systems its jut the way it is
05:32:42FromDiscord<graveflo> I dont need a library beef. Nim works so well im pretty much floored
05:32:47FromDiscord<Elegantbeef> It's really not that difficult to git rid if cause like I said I'm not using inheritance
05:32:48FromDiscord<graveflo> its just missing a thing or two
05:32:56FromDiscord<Elegantbeef> Reread what i said
05:33:24FromDiscord<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:46FromDiscord<Elegantbeef> > There are plenty of libraries that use generic dispatch to allow overriding
05:33:57FromDiscord<Elegantbeef> "that use"
05:34:13FromDiscord<graveflo> that wasn't the part I thought was significant
05:34:16FromDiscord<graveflo> wdym
05:34:31FromDiscord<Elegantbeef> There are libraries that use generic dispatch to allow overriding built in functionality
05:34:55FromDiscord<Elegantbeef> Pretty much any Nim parsing library `std/jsonutils` `jsony`, `jason` uses it
05:35:17FromDiscord<Elegantbeef> you can easily do `myModule.doThing(myArg)` to call the base procedure
05:35:54FromDiscord<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:43FromDiscord<Elegantbeef> I mean I'd be re-implementing the field copying of inheritance, but ideally without making dispatch rules convoluted
05:37:14FromDiscord<graveflo> hey sounds good to me
05:37:18FromDiscord<Elegantbeef> Ah nvm I take it back it'd have the same issues
05:37:44FromDiscord<Elegantbeef> It'd actually be worse 😄
05:40:54FromDiscord<graveflo> sent a code paste, see https://play.nim-lang.org/#ix=4xOe
05:41:15FromDiscord<graveflo> because I never really figured it out
05:42:31FromDiscord<Elegantbeef> It works
05:42:44FromDiscord<Elegantbeef> I told you before though
05:43:06FromDiscord<Elegantbeef> `[T: object]` and `[Y; T: GenericObj[Y]]` are the same mismatch level
05:43:10FromDiscord<Elegantbeef> Both are generic mismatches
05:43:15FromDiscord<Elegantbeef> or matches
05:43:26FromDiscord<Elegantbeef> `[T](param: GenericObj[T])` works
05:44:00FromDiscord<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:04FromDiscord<Elegantbeef> Whoops
05:44:38FromDiscord<Elegantbeef> Anyway point is constraining a generic does not make it more correct match
05:44:41FromDiscord<graveflo> ok so matching happens in the `()` and the `[]` is just preamble basically?
05:45:04FromDiscord<Elegantbeef> in both cases `param: T` is hit and it goes "Hey these are both generic parameters so equivalent matches"
05:45:45FromDiscord<graveflo> then why doesn't `Something()` match `T` in the first example
05:45:53FromDiscord<graveflo> an unconstrained generic should match
05:46:06FromDiscord<Elegantbeef> It is constrained though
05:46:33FromDiscord<graveflo> so in this verbage constraints != binding rules
05:46:47FromDiscord<Elegantbeef> constraint means `T: Y`
05:46:51FromDiscord<Elegantbeef> Y is the constraint
05:47:15FromDiscord<graveflo> so in the fist example the constraint is `T`
05:47:22FromDiscord<Elegantbeef> No
05:47:30FromDiscord<Elegantbeef> `object` and `GenObj[Y]`
05:47:41FromDiscord<graveflo> oh oops right
05:48:38FromDiscord<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:41FromDiscord<graveflo> so in the second example the constraint is `GenObj[Y]` and then `object`
05:49:07FromDiscord<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:20FromDiscord<Elegantbeef> In the third example it passes for obvious reasons
05:49:45FromDiscord<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:36FromDiscord<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:47FromDiscord<Elegantbeef> That difference can benefit in some cases
05:51:20FromDiscord<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:21FromDiscord<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:31FromDiscord<graveflo> that would make `object` matched procs complete hogs
05:51:36FromDiscord<Elegantbeef> Right but you do not overload them in the generic procedure
05:51:59FromDiscord<Elegantbeef> You are attempting to overload object with a generic parameter, that does not work
05:53:06FromDiscord<Elegantbeef> This sadly only applies to generics
05:54:28FromDiscord<graveflo> sent a code paste, see https://play.nim-lang.org/#ix=4xOh
05:54:47FromDiscord<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:32FromDiscord<Elegantbeef> I mean Nim's generics are never 'correct' 😛
05:55:32FromDiscord<Elegantbeef> They're a travesty
05:55:33FromDiscord<Elegantbeef> But it is what it is
05:55:35FromDiscord<graveflo> (edit) "this is correct" => "the matching rules are understandable"
05:55:40FromDiscord<Elegantbeef> sent a code paste, see https://paste.rs/8bsos
05:56:08FromDiscord<Elegantbeef> It's simply that a generic inside generic parameters is considered the same level as a typeclass
05:57:04FromDiscord<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:28FromDiscord<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:02FromDiscord<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:04FromDiscord<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