| 00:31:35 | * | q66 quit (Remote host closed the connection) |
| 00:32:04 | * | q66 joined #nimrod |
| 01:11:23 | * | q66 quit (Remote host closed the connection) |
| 04:56:02 | * | Boscop quit (Read error: Connection reset by peer) |
| 04:56:21 | * | Boscop joined #nimrod |
| 06:23:22 | * | gour joined #nimrod |
| 08:02:20 | * | Araq_ joined #nimrod |
| 08:22:40 | * | Araq_ quit (Quit: ChatZilla 0.9.90 [Firefox 19.0/20130215130331]) |
| 11:49:24 | * | fowl joined #nimrod |
| 11:54:28 | * | Araq_ joined #nimrod |
| 12:03:25 | * | Araq_ quit (Quit: ChatZilla 0.9.90 [Firefox 19.0/20130215130331]) |
| 12:07:32 | * | fowl quit (Quit: Leaving) |
| 12:51:21 | * | fowl joined #nimrod |
| 13:12:09 | * | q66 joined #nimrod |
| 14:23:20 | * | Trix[a]r_za is now known as Trixar_za |
| 14:58:01 | * | gour quit (Disconnected by services) |
| 14:58:03 | * | gour_ joined #nimrod |
| 15:54:03 | * | Trixar_za is now known as Trix[a]r_za |
| 19:54:04 | * | gradha joined #nimrod |
| 19:54:51 | Araq | gradha: I have some ideas about the m&s bug you encountered but I'd like some remote access to the testing machine :P |
| 19:55:11 | Araq | but not now, tbh I don't consider it that important ;-) |
| 19:57:28 | gradha | yuck, looks like I'll have to reconfigure the network to allow sshd |
| 19:58:37 | gradha | why don't we have ipv6 and have to keep using nat |
| 19:59:30 | Araq | why don't we have a module system for C and have to keep using #include? |
| 20:00:24 | gradha | which segways into the forum post http://forum.nimrod-code.org/t/134, asking about providing nimrod "binaries" or static libraries without source, I guess |
| 20:01:27 | Araq | I answered that multiple times already |
| 20:01:57 | gradha | easy then, point to the documentation |
| 20:04:02 | Araq | why does not nobody ask why Nimrod doesn't provide the Second Futamura Projection instead of a macro system? |
| 20:04:26 | gradha | the second season of futurama? sign me in! |
| 20:05:02 | gradha | ok, that's niche, there's no wikipedia page for second futamura projection |
| 20:06:41 | dom96 | http://en.wikipedia.org/wiki/Partial_evaluation#Futamura_projections |
| 20:07:13 | gradha | but http://blog.sigfpe.com/2009/05/three-projections-of-doctor-futamura.html has pictures, it has to be better |
| 20:10:45 | * | FreeArtMan joined #nimrod |
| 20:18:18 | gradha | Araq, after reading about futamura fishes I ask you this question: why would you ever want to do any futamura projection when you have macros? |
| 20:19:52 | gradha | meh, ignore this question, I'm more certain now I don't understand anything I've read in the last 10 minutes |
| 20:19:58 | Araq | futamura projections lead to less code when you have a DSL that should work at runtime and at compile-time |
| 20:20:30 | Araq | you only need to define the runtime version and some specialization rules |
| 20:21:07 | Araq | but I think it can be done this way already because of Nimrod's awesomeness |
| 20:21:25 | gradha | I'll have to meditate on the subject |
| 20:21:33 | Araq | so do I |
| 20:22:12 | gradha | I'm really glad I have youtube, the world would be such a pain if I started to really think |
| 20:25:16 | Araq | gradha: tell me again what static methods look like in obj-c please |
| 20:25:32 | Araq | I mean the call syntax |
| 20:25:51 | gradha | the syntax is [classname methodname:args] |
| 20:26:15 | gradha | they are differentiated from instance methods by using a + instead of a - in their declaration |
| 20:26:21 | Araq | and args are named? |
| 20:26:35 | gradha | there's no other difference with regards to instance methods |
| 20:26:44 | gradha | they just replace the object with the class name |
| 20:26:50 | Araq | [classname methodname a:arg1 b:arg2] ? |
| 20:27:05 | gradha | that would likely be [classname methodname:arg1 b:arg2] |
| 20:27:15 | Araq | ah yeah |
| 20:27:36 | Araq | objc's syntax is absurd crap |
| 20:28:57 | gradha | here's a class prototype with both static and instance methods https://github.com/gradha/ELHASO-iOS-snippets/blob/master/src/EHActivityView.h |
| 20:29:18 | Araq | I came up with a pretty general solution for these things |
| 20:29:19 | gradha | this one has a parameter, just like a normal instance method: https://github.com/gradha/ELHASO-iOS-snippets/blob/master/src/UIImageView%2BELHASO.h |
| 20:29:30 | Araq | turns out it doesn't work :-/ |
| 20:29:45 | Araq | because objc's syntax is too hard to generalize over |
| 20:30:01 | gradha | I think the self naming convention I described in the github ticket should be enough |
| 20:30:21 | gradha | but why are you worrying about that? It's on my plate |
| 20:30:30 | gradha | I only have to learn about futurama fishes first |
| 20:30:42 | Araq | you mean you'll implement that in the compiler? |
| 20:30:43 | gradha | sorry, about macros |
| 20:30:55 | gradha | I was planning to do that with a normal macro |
| 20:31:04 | gradha | and when I was capable, look at the compiler one |
| 20:31:13 | Araq | dunno if it can be done with a macro |
| 20:31:26 | Araq | macro emitting an 'emit' ... hrm |
| 20:31:33 | gradha | that's a bad thing to say to a motivated person |
| 20:31:46 | Araq | ok ok, it's possible :P |
| 20:31:51 | gradha | yay! |
| 20:32:01 | gradha | you only have to wait, that's the worst part |
| 20:32:47 | gradha | you could also implement it and say in the commit "minor cleanup fixes", so I don't see it |
| 20:36:35 | NimBot | Araq/Nimrod 2306e0e Araq [+0 ±2 -0]: bugfix: tvtable works again |
| 20:36:35 | NimBot | Araq/Nimrod cdb3453 Araq [+0 ±3 -0]: fixed some typos |
| 20:36:44 | Araq | there you go, gradha ;-) |
| 20:36:58 | gradha | I won't look at that |
| 20:37:40 | gradha | why is the objc syntax absurd crap? all in general or just for static methods? I guess both, since the only difference between one and the other is the use of self/classname |
| 20:37:52 | Araq | both |
| 20:38:47 | gradha | IIRC that syntax grew out of the need to not break existing C code, have any other languages done it in a different way also supporting C? |
| 20:40:06 | gradha | don't know if the C++ broke any C in the process |
| 20:41:30 | Araq | iirc that syntax was copied from smalltalk with no consideration if it fits C's style or not |
| 20:42:37 | Araq | and it's weird anyway: [x foo: a withArg: b] # so a's parameter name is missing? |
| 20:42:57 | reactormonk | Araq, wikipedia says so anyway |
| 20:43:28 | gradha | yes, the first param name missing is why objc naming convention tells you to embed it in the method name |
| 20:44:29 | Araq | objc fits macosx quite well |
| 20:44:52 | reactormonk | looks fancy and does the job somewhat? |
| 20:45:14 | Araq | unix + lay some bullshit on top that has a completely different philosophy |
| 20:45:38 | reactormonk | like NextStep? |
| 20:45:47 | gradha | if they weren't different they wouldn't be another platform, just a unix variant |
| 20:47:00 | gradha | you don't have to use the bullshit on top, though, so you get the unix philosphy |
| 20:47:12 | Araq | yay ... |
| 20:47:37 | Araq | but I hate the unix stuff too ;-) |
| 20:49:05 | gradha | I really dislike how the industry is trying to retrofit security into the current platforms instead of creating a new proper one from scratch |
| 20:49:43 | Araq | the "new proper one from scratch" has been tried too; it's called "Java" |
| 20:50:08 | gradha | surely you jest, is there a JavaOS |
| 20:50:10 | gradha | ? |
| 20:50:25 | gradha | oh, maybe inferno/limbo/what was that called? |
| 20:50:32 | Araq | there have been a couple of JavaOSes |
| 20:50:38 | Araq | they all failed |
| 20:50:54 | Araq | but then the chance for an OS to succeed are tiny anyway |
| 20:51:19 | gradha | the thing is, javaos doesn't mean anything at all with regards to security, just maybe an implementation detail, if your security model is wrong, it's still wrong |
| 20:51:48 | Araq | don't let me rant about "security" |
| 20:52:31 | gradha | in my previous fluffy statement I was thinking how current OSes are top/down, which doesn't make sense and allows any bug to be a potential security risk |
| 20:52:51 | Araq | whenever you do ./configure && make && make install the 40K configure script could easily upload all your home directory to some unknown server |
| 20:53:06 | Araq | or at least delete it |
| 20:53:31 | gradha | yes, that's why in a secure minded platform the configure would not be allowed to connect to the network or remove files outside it's reach |
| 20:53:45 | gradha | but these things are implemented now in the top/down systems, so any bug allows everything |
| 20:53:58 | Araq | you can prevent it already |
| 20:54:02 | Araq | but nobody does so |
| 20:54:39 | gradha | I recall software like apparmor for linux which did stuff like this, restrict access on a fine grained level |
| 20:54:53 | reactormonk | gradha, yeah, I think ubuntu uses some of it |
| 20:55:13 | gradha | macs have been trying to force developers to use such "access profiles" too for some years |
| 20:55:33 | Araq | hey, why bother? at least it can't delete the stuff that was copied from the installation CD ... :P |
| 20:55:40 | reactormonk | well, android and ios base on that |
| 20:56:06 | gradha | reactormonk: app store on macs does the same thing, if you allow it to |
| 20:56:26 | reactormonk | gradha, that's just the app store from the ios transitioned |
| 20:56:40 | Araq | useful thing that is ... so it can only damage my work |
| 20:57:07 | Araq | but the admin doesn't have any work with it |
| 20:57:52 | reactormonk | Araq, yeah, *nix stuff comes from mainframes where user data wasn't overly important :-/ |
| 20:57:57 | gradha | reactormonk: you could do so previous to the appstore too, at https://www.romab.com/ironsuite/ they had some "hardened" profiles for common apps using the basic OS support |
| 20:58:56 | gradha | in typical apple fashion this part of the security on the os was "poorly documented", until they released the actual app store |
| 20:59:26 | reactormonk | why document something they don't use |
| 20:59:42 | gradha | why implement something they don't use |
| 21:01:41 | * | FreeArtMan quit (Ping timeout: 245 seconds) |
| 21:03:30 | Araq | ok attention please! |
| 21:03:34 | gradha | yes sir! |
| 21:04:03 | Araq | syntax question: TObject(a: 1, b: 1) will be an object constructor |
| 21:04:36 | Araq | however: how to make a 'ref object' instead? |
| 21:05:16 | gradha | can't that be done by looking at what you are assigning that to? |
| 21:05:26 | Araq | PObject(a: 1, b: 2) ? # requires type name |
| 21:05:43 | Araq | gradha: no that's too ambiguous |
| 21:06:20 | Araq | TObject.new(a: 1, b: 2) ? |
| 21:07:08 | gradha | how about not having to declare Pobject variants? You could then use PObject without requring an explicit type |
| 21:07:26 | Araq | how can that work? |
| 21:07:50 | Araq | type TObject = object # compiler declares PObject for you? |
| 21:07:58 | gradha | yes |
| 21:08:02 | Araq | that's too much magic |
| 21:08:13 | gradha | but people love magic |
| 21:08:28 | Araq | plus a lot of people dislike T/P prefixes for types |
| 21:08:43 | Araq | so we'd better not hardcode them in the compiler |
| 21:08:54 | gradha | they don't like them because they don't come with the magic, it's all manual now, which is the part they don't like |
| 21:09:12 | Araq | it's not all manual now |
| 21:09:24 | Araq | you can do type PObject = ref object |
| 21:09:44 | Araq | or you can use a template to fight the boilerplate |
| 21:09:53 | Araq | the manual even contains an example of how to do that |
| 21:11:08 | reactormonk | Araq, TObject.new(a:1) and TObject.newref(a:1) ? |
| 21:11:27 | reactormonk | or different keywords for value and ref? |
| 21:11:32 | Araq | reactormonk: nah that's confusing |
| 21:11:48 | Araq | TObject(a: 1) is already set in stone :P |
| 21:11:54 | reactormonk | Araq, or fuck it and go for ref TObject(a: 1, b: 1) |
| 21:12:05 | gradha | hmm... so if I have a TObject, and create a ref of TObject, am I creating an "anonymous ref TObject" at compile time? |
| 21:12:41 | Araq | reactormonk: 'ref TObject()' is worse than 'new TObject()' |
| 21:12:47 | reactormonk | Araq, why? |
| 21:13:20 | Araq | because you mean in fact: (ref TObject)(a: 1, b: 2) |
| 21:13:33 | Araq | but of course you left out the () |
| 21:13:53 | Araq | which doesn't parse well however |
| 21:14:06 | reactormonk | wouldn't ref TObject be PObject which would result in PObject(a: 1) |
| 21:14:31 | reactormonk | or create an anonymous object and create a reference to it |
| 21:14:54 | Araq | currently 'ref TObject(a: 1, b: 2)' is parsed as 'ref (TObject(a: 1, b: 2))' |
| 21:15:28 | gradha | use square brackets for the ref version TObject[a: 1, b: 2] |
| 21:15:45 | gradha | that will make people love declaring their Pobjects and using PObject constructors |
| 21:15:47 | Araq | well either you mean 'ref' as a sort of 'new' operator or you mean the type, reactormonk |
| 21:16:07 | reactormonk | Araq, Syntax would be mostly the same in most of the cases. |
| 21:16:25 | Araq | reactormonk: yeah that's why it's confusing :P |
| 21:16:38 | reactormonk | Araq, hm. which of the two paths would you prefer? |
| 21:16:49 | gradha | for dereferencing you use [], so maybe TObject[](a: 1, b:2) implies a ref object returned |
| 21:17:02 | Araq | I am thinking of making 'new' a keyword and supporting 'new TObject(...)' |
| 21:17:03 | reactormonk | gradha, oh, I see |
| 21:17:19 | reactormonk | Araq, aww, factory pattern :-( ^^ |
| 21:17:32 | Araq | reactormonk: yeah :-( |
| 21:18:00 | reactormonk | Araq, I'd prefer TObject(). Have you seen the way scala does it? |
| 21:18:05 | reactormonk | with apply n stuff |
| 21:18:24 | Araq | how does scala do it? |
| 21:18:48 | Araq | scala doesn't have ref object vs. object though |
| 21:19:01 | reactormonk | besides the fact it's all reference they give you the ability to create companion objects where you can define apply so you have Object() |
| 21:19:32 | reactormonk | change of location |
| 21:23:11 | Araq | hrm TObject.new(a: 1, b: 1) can be supported with some minor syntactic sugar |
| 21:23:17 | dom96 | I like 'new TObject(...)' because it's quite similar to how it works currently. (We use new() for refs) |
| 21:24:04 | Araq | TObject.new(a: 1, b: 1) can be sugar for: TObject.new((a: 1, b: 2)) |
| 21:24:52 | Araq | and then we have: proc new(typ: typedesc, tup: tuple) |
| 21:25:56 | gradha | why the need for a tuple, is there a problem if you called proc new(typ: typedesc, a, b: something)? |
| 21:26:24 | Araq | dom96: you can already use 'var x = TObject.new' btw |
| 21:26:43 | Araq | gradha: named parameters are with '=' in nimrod |
| 21:27:28 | gradha | does that mean I could call TObject.new() and not pass all parameters? |
| 21:27:38 | Araq | you'd need a variadic argument with parameter names that correspond to the object's fields |
| 21:27:52 | Araq | gradha: yeah |
| 21:28:16 | gradha | oh, so you don't like magic, but this is implementing magic for avoiding to write constructor methods? |
| 21:29:05 | Araq | it's not magic in the sense it injects arbitrary symbols into your scope |
| 21:29:24 | Araq | and it's not about avoiding to write constructor methods |
| 21:29:44 | Araq | the current language NEEDS a constructor built-in for various reasons |
| 21:30:32 | Araq | the most important reason is that 'case objects' cannot be made safe otherwise |
| 21:31:09 | gradha | have you tried nested case objects? |
| 21:31:23 | Araq | no. have you? |
| 21:31:45 | gradha | I saw it yesterday on my todo, might be good to consider it for these constructor syntaxes |
| 21:32:29 | Araq | I already have: TObject(discriminator: value, TSubObject(x: 1)) |
| 21:34:28 | gradha | TObject(discriminator: value, (ref TSubObject(x: 1)) sounds evil |
| 21:34:54 | Araq | not really |
| 21:35:08 | Araq | but I dislike 'ref' for 'new' |
| 21:35:34 | Araq | and I think I'll go with my TObject.new(a: 1, b: 2) idea |
| 21:36:41 | Araq | but ugh |
| 21:36:59 | Araq | type PObject = ref object |
| 21:37:16 | Araq | PObject.new(a: 1, b: 2) # creates a ref ref object? o.O |
| 21:37:41 | Araq | and with 'ref object' you can't access the value type necessary for 'new' :-/ |
| 21:37:41 | reactormonk | Araq, why not simply PObject(a:1, b:2) ? |
| 21:38:05 | Araq | reactormonk: I guess that's better then, yeah |
| 21:38:20 | gradha | just a moment ago you argued against that |
| 21:38:42 | Araq | yeah that's why I'm talking about it |
| 21:38:56 | reactormonk | and fuck with the precedence such that ref TObject(a:1, b:2) => (ref TObject)(a:1, b:2) ;-) |
| 21:38:59 | Araq | I wouldn't talk about it when I knew the solution |
| 21:39:33 | Araq | nah, introduce a type alias for 'ref TObject' instead :P |
| 21:40:09 | reactormonk | Araq, hmm, a shortcut would be nice. But TObject[] is a bit wierd |
| 21:40:26 | reactormonk | because it's dereference on values and reference on types |
| 21:40:37 | gradha | use C++ &: TObject&(a:1, b:2) |
| 21:40:53 | Araq | TObject[] is out of the discussion |
| 21:41:03 | reactormonk | gradha, no, & is string concat |
| 21:41:22 | gradha | come on, we could grab some confused TCL programmers |
| 21:41:39 | reactormonk | no upval in nimrod |
| 21:41:42 | Araq | gradha: operator symbols don't work well for built-in syntaxes in nimrod |
| 21:42:03 | Araq | because all operator symbols are available for the users ;-) |
| 21:42:18 | gradha | if you go with TObject.new(a:1, b:2) why not introduce TObject.ref(a:1, b:2)? |
| 21:42:35 | Araq | what would that mean? |
| 21:42:48 | gradha | the first means construct a var, the second a ref var |
| 21:43:06 | gradha | so you don't need PObject |
| 21:43:10 | Araq | but 'new' should construct a ref for consistency |
| 21:43:30 | Araq | and how do you handle 'ref ref' anyway then? |
| 21:43:39 | reactormonk | Araq, double pointer? |
| 21:43:50 | gradha | can you write ref ref object now? |
| 21:43:50 | Araq | reactormonk: yes |
| 21:44:03 | Araq | I dunno :-) |
| 21:44:31 | Araq | but 'ref ref TOjbect' is definitely possible |
| 21:45:04 | gradha | another crazy one: normal constructor TObject.(a:1, b2), ref constructor TObject:(a:1, b:2) |
| 21:45:18 | gradha | oh, that will lead to nasty bugs |
| 21:45:23 | reactormonk | gradha, likely. |
| 21:45:29 | gradha | or maybe confused people confusing colons |
| 21:45:33 | reactormonk | Araq, so which solutions are you considering currently? |
| 21:45:37 | Araq | looks perlish to me |
| 21:46:23 | Araq | reactormonk: TObject(x: 1, y: 2) and PObject(x: 1, y: 2) |
| 21:47:02 | gradha | I like TObject(x:1, y:2) and TObject[x:1, y:2], but I've been brainwashed already by the brackets-are-what-god-wanted-you-to-write language |
| 21:47:21 | reactormonk | Araq, what would happen if (ref TObject)(x:1) aka ref TObject(x:1)? |
| 21:47:24 | reactormonk | gradha, objc? |
| 21:47:31 | gradha | reactormonk: yes |
| 21:48:29 | gradha | oh, using <> would confuse C++ programmers: TObject(x:1, y:2) and TObject<x:1, y:2> |
| 21:48:52 | Araq | reactormonk: hard to tell, the grammar will barf about it |
| 21:48:58 | dom96 | please stick with () |
| 21:49:06 | reactormonk | ^ sign |
| 21:49:27 | Araq | TObject<x: 1, y:2> is ambiguous |
| 21:49:48 | Araq | and a major reason why C++ is such pita to parse |
| 21:49:51 | reactormonk | Araq, I'd like ref TObject(a:1) to work as PObject(a:1) but otherwise that's fine with me. |
| 21:50:40 | Araq | but then if you work with 'ref TObject', you likely work with it everywhere and want the PObject shortcut anyway |
| 21:50:48 | reactormonk | would also solve #75 :-) |
| 21:51:02 | reactormonk | Araq, hm, true again. |
| 21:51:05 | gradha | I think TObject[] is only out of the discussion because [] already feels wrong for dereferencing something, maybe change both and replace dereferencing with new syntax? |
| 21:51:35 | Araq | deref used to be ^ but I changed it to [] because |
| 21:51:40 | reactormonk | gradha, maybe that's because [] dereferences in C... :-/ |
| 21:51:42 | Araq | a) it was a special case in the grammar |
| 21:51:57 | Araq | b) ^ is better left for exp |
| 21:52:24 | reactormonk | gradha, what to use for dereferencing iyo? |
| 21:52:25 | Araq | c) explicit deref is rare in nimrod anyway |
| 21:52:41 | Araq | no, I don't want to change it again |
| 21:52:57 | reactormonk | oke. |
| 21:53:05 | gradha | I thought dereferencing in C is done with &, not [] |
| 21:53:16 | Araq | gradha: it's done with * |
| 21:53:16 | reactormonk | gradha, an array with [] - more or less |
| 21:53:30 | gradha | ah, yes, wrong direction |
| 21:54:03 | reactormonk | Araq, how would I define initialization in () ? |
| 21:55:55 | Araq | reactormonk: TObject(...) already is an expression |
| 21:56:25 | reactormonk | Araq, rephrase: how would I redefine what happens in TObject(...) ? |
| 21:56:25 | Araq | dunno what you mean with "init in ()" |
| 21:56:49 | Araq | hrm good question |
| 21:57:13 | reactormonk | proc TObject() = {} ? |
| 21:57:30 | Araq | I guess you can't |
| 21:57:56 | Araq | but then it's really supposed to not be exported |
| 21:58:13 | Araq | the constructor procs the stdlib is full of are here to stay |
| 21:58:31 | reactormonk | well, it's possible to name a proc the same as the object? |
| 21:58:37 | Araq | yes |
| 21:58:43 | Araq | but the problem is: |
| 21:58:50 | Araq | f(a: 1, b: 2) |
| 21:58:55 | Araq | is no valid call syntax |
| 21:59:15 | reactormonk | call-by-param? |
| 21:59:21 | Araq | f(a=1, b=2) is the valid syntax |
| 21:59:35 | reactormonk | so why not TObject(x=1) ? |
| 21:59:51 | Araq | hm |
| 22:00:11 | Araq | I liked the TObject(x: 1) better for consistency with tuple construction |
| 22:00:20 | Araq | which is (x: 1) |
| 22:00:50 | reactormonk | I guess I see a constructor like any other proc, given my ruby roots |
| 22:01:13 | reactormonk | And the syntax is also similar to what scala does |
| 22:01:34 | Araq | well that's how it works today in nimrod, constructors are ordinary procs |
| 22:01:57 | reactormonk | auto-generate some default procs then |
| 22:01:57 | Araq | but unfortunately it doesn't work for edge cases |
| 22:03:09 | gradha | if you add constructors to make safe object variants, is the normal way going to be deprecated and later invalid? |
| 22:03:23 | dom96 | How about something like this: init typedesc(...) = ... |
| 22:03:26 | Araq | gradha: yes |
| 22:03:59 | dom96 | Not sure about how the params should work. |
| 22:04:27 | Araq | dom96: that doesn't solve anything |
| 22:04:42 | Araq | we're discussing invokation syntax, not definition syntax |
| 22:05:05 | Araq | there is no problem with a definition syntax because there is no definition in the first place |
| 22:05:08 | gradha | hrm, couldn't you define a constructor for an object variant which doesn't really define the variant and thus creates an unsafe object? |
| 22:05:17 | dom96 | well what's the problem with TObject(x: 1, y: 2)? |
| 22:05:46 | Araq | dom96: you can't overload/redefine it |
| 22:06:03 | Araq | but then that's kind of the point ... |
| 22:06:38 | reactormonk | Araq, edgecases like? |
| 22:08:08 | reactormonk | Araq, basically an allocate? |
| 22:08:25 | reactormonk | would proc TObject() still work? |
| 22:08:42 | reactormonk | imho we should change the convention to that :-) |
| 22:08:59 | Araq | reactormonk: it would still work I think |
| 22:11:29 | gradha | Araq: how will you guarantee that a constructor for an object variant defines the type? |
| 22:11:44 | reactormonk | gradha, huh? |
| 22:12:17 | gradha | previously Araq said constructors are to deprecate current object variant creation, which is unsafe |
| 22:12:37 | gradha | but if you can write your own constructor, you could not initialise it properly and still have an unsafe object variant |
| 22:12:43 | Araq | gradha: let me elaborate: |
| 22:13:05 | Araq | proc ctor(): TCaseObj = |
| 22:13:11 | Araq | # old way: |
| 22:13:21 | Araq | result.kind = k |
| 22:13:30 | Araq | result.fieldA = 1 |
| 22:13:52 | reactormonk | Araq, is ctor a "keyword"? |
| 22:14:01 | Araq | --> new way: forbid assignment to 'kind': |
| 22:14:10 | gradha | reactormonk: no |
| 22:14:15 | reactormonk | kk |
| 22:14:39 | Araq | proc ctor(): TCaseObj = return TCaseObj(kind: k, fieldA: 1) |
| 22:14:49 | gradha | oh, so you basically disallow assigning to any kind variable and force it in the constructor? |
| 22:14:58 | Araq | yes |
| 22:15:22 | reactormonk | so you want to go with the semantics that objects are basically named tuples? |
| 22:16:02 | Araq | reactormonk: your question doesn't make sense |
| 22:16:10 | Araq | objects stay the way they are |
| 22:16:22 | Araq | and yeah we haven't talked about inheritance yet |
| 22:16:34 | Araq | I think it'll be done like so: |
| 22:16:35 | reactormonk | Araq, yes, but the syntax somehow conveys how stuff should be understood. |
| 22:16:59 | Araq | TObject(TBaseObj(a: 1), b: 2) |
| 22:19:47 | reactormonk | Araq, what is TBaseObj? |
| 22:20:16 | Araq | oh come on, it's the super class of TObject in this example |
| 22:20:33 | dom96 | Araq: I think it should simply be TObject(a: 1, b:2) |
| 22:20:39 | reactormonk | ^ yes |
| 22:21:56 | Araq | hm, perhaps, yeah |
| 22:22:35 | dom96 | In regards to redefining, it should be possible. |
| 22:23:49 | dom96 | hrm, but then again. Perhaps we should keep it simple. |
| 22:24:16 | reactormonk | dom96, if objects are named tuples, nope. |
| 22:24:24 | reactormonk | the syntax make sense too this way. |
| 22:24:44 | reactormonk | If objects are meant to have constructors, go with TObject(foo=bar) and a default proc TObject() |
| 22:25:18 | Araq | reactormonk: ah that's what you mean |
| 22:25:30 | Araq | ugh ... difficult decision |
| 22:25:39 | reactormonk | Araq, need to improve my communcation skillz :-/ |
| 22:26:09 | reactormonk | Araq, why not both? ;-) |
| 22:26:44 | Araq | reactormonk: then some poor soul uses TObject(a: 1) and it can't be overridden |
| 22:26:53 | reactormonk | Araq, ... duh. |
| 22:27:40 | Araq | well since I despise inheritance I guess I'll go with the tuple-like syntax/behaviour |
| 22:27:44 | reactormonk | Araq, implement both, do not export TFoo(a:1) |
| 22:28:24 | Araq | it's also easier to implement and 'proc TObject' is not what the stdlib now uses |
| 22:29:04 | reactormonk | deprecation is evil, isn't it? |
| 22:29:40 | Araq | it is because we really like to see 1.0 some day |
| 22:29:40 | reactormonk | shouldn't be too hard to deprecate the old one imo |
| 22:29:57 | reactormonk | Yes, but you can't change that once you reach 1.0 |
| 22:30:17 | Araq | I can break whatever I want for 2.0 |
| 22:30:17 | gradha | you only need to develop 2.0 faster |
| 22:30:39 | reactormonk | gradha, 0.x is defined to not be as stable as 1.x |
| 22:30:47 | gradha | nimrod 3000, sounds right |
| 22:30:49 | Araq | there are no plans for a 2.0 though |
| 22:31:25 | reactormonk | Araq, I'd change the whole stuff in stdlib and add deprecation if you so desire |
| 22:31:49 | reactormonk | for implementing both and use proc TObject outside the file (as above) |
| 22:32:05 | Araq | reactormonk: I'd rather work on nimrod's concurrency design/implementation |
| 22:32:46 | reactormonk | Araq, how hard is it to attach a TObject() proc to each type? |
| 22:32:57 | * | gour_ quit (Quit: WeeChat 0.4.0) |
| 22:33:39 | Araq | reactormonk: more work than you think I bet :P |
| 22:34:02 | reactormonk | Araq, No, I consider it would require a substantional hack in the compiler. |
| 22:34:50 | Araq | not really |
| 22:35:07 | Araq | we'll get the necessary ingredients anyway |
| 22:35:16 | reactormonk | from? |
| 22:36:30 | reactormonk | Araq, imo, for now, implement tuple syntax, but do not export. |
| 22:36:32 | dom96 | wait, so what's happening for constructors? |
| 22:37:00 | reactormonk | dom96, imo proc... |
| 22:37:08 | Araq | reactormonk: the required additions are also necessary for destructors and overloading of the assignment operator |
| 22:37:08 | dom96 | still not decided? |
| 22:37:44 | reactormonk | my vote is for tuple not export and default constructor proc TObject(a=1) export. |
| 22:38:20 | reactormonk | question: where does that break? |
| 22:38:58 | dom96 | I'm not a big fan of having an implicit constructor for each proc. |
| 22:39:05 | dom96 | er |
| 22:39:09 | reactormonk | dom96, s/proc/type/ |
| 22:39:11 | dom96 | s/proc/type/ |
| 22:39:12 | dom96 | yeah |
| 22:39:25 | reactormonk | dom96, what problems do you see? |
| 22:40:10 | reactormonk | btw, what happens to a proc that returns a type that is not exported? |
| 22:40:10 | dom96 | Lots of ambiguous errors. |
| 22:40:43 | reactormonk | dom96, so one type of proc you can't leave the () off? |
| 22:41:11 | dom96 | huh? |
| 22:41:14 | Araq | reactormonk: why is that a problem? 'var x= p()' works then and 'var x: typ = p()' does not ;-) |
| 22:41:27 | reactormonk | Araq, just asking. |
| 22:41:34 | Araq | (if 'typ' is not exported) |
| 22:41:48 | reactormonk | Araq, I considered it to be a problem when you have default constructors that you could construct such an object... but you could anyway. |
| 22:42:02 | dom96 | I think that the "tuple syntax" should be available for any types which are in scope. |
| 22:42:31 | dom96 | So basically if the type is exported, so is the constructor. |
| 22:42:35 | reactormonk | I think that would lead to the problem of not being overwritable |
| 22:42:57 | Araq | dom96: I'll implement the TObject(a: 1), PObject(a: 1) stuff |
| 22:43:25 | Araq | can't be overwritten but then you should export a constructor proc anyway if you're after information hiding |
| 22:43:26 | dom96 | Well that depends on how you think of constructors. |
| 22:43:57 | dom96 | Yeah, constructors should be a simple syntax sugar for obj.field1 = ...; obj.field2 = ... |
| 22:47:53 | Araq | yeah, dom96, I agree |
| 22:49:49 | reactormonk | so they aren't constructors but sugar :-) |
| 22:50:25 | Araq | yeah |
| 22:57:05 | * | gradha quit (Quit: bbl, have youtube videos to watch) |
| 23:13:01 | dom96 | 'night |