| 02:11:42 | * | [2]charles quit (Ping timeout: 276 seconds) |
| 02:19:21 | * | q66 quit (Quit: Leaving) |
| 02:46:52 | * | Associ8or quit (Quit: Associ8or) |
| 04:32:08 | * | OrionPK quit (Read error: Connection reset by peer) |
| 04:48:51 | * | Sergio965 joined #nimrod |
| 04:50:36 | * | Endeg joined #nimrod |
| 05:11:15 | * | xilo quit (Ping timeout: 245 seconds) |
| 05:14:52 | * | Boscop joined #nimrod |
| 06:03:56 | * | Sergio965 quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 06:48:14 | * | Boscop quit (Ping timeout: 246 seconds) |
| 06:50:11 | * | Boscop joined #nimrod |
| 07:13:57 | * | Araq_ joined #nimrod |
| 08:11:53 | * | BitPuffin_ quit (*.net *.split) |
| 08:12:08 | * | BitPuffin joined #nimrod |
| 08:32:51 | * | [1]charles quit (Ping timeout: 256 seconds) |
| 08:34:15 | * | Associat0r joined #nimrod |
| 08:34:15 | * | Associat0r quit (Changing host) |
| 08:34:15 | * | Associat0r joined #nimrod |
| 09:10:44 | * | EvilAww is now known as _EvilAww |
| 09:10:47 | * | _EvilAww is now known as EvilAww |
| 09:34:58 | * | EXetoC joined #nimrod |
| 11:27:47 | * | Associ8or joined #nimrod |
| 11:27:47 | * | Associ8or quit (Changing host) |
| 11:27:47 | * | Associ8or joined #nimrod |
| 11:29:52 | * | Associat0r quit (Ping timeout: 264 seconds) |
| 11:38:33 | * | q66 joined #nimrod |
| 12:55:02 | * | Sergio965 joined #nimrod |
| 12:59:30 | EXetoC | suup |
| 13:04:17 | dom96 | yo |
| 13:04:28 | dom96 | how's the procrastination going? |
| 13:04:42 | EXetoC | good |
| 13:05:18 | Araq_ | I think I figured out all the details of the "write" tracking algorithm |
| 13:05:55 | Araq_ | which is a "const" system done right, IMHO anyway |
| 13:07:29 | * | Associ8or quit (Quit: Associ8or) |
| 13:08:21 | * | Sergio965 quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 13:09:43 | EXetoC | what's the difference compared to const in C++ for example? |
| 13:10:40 | Araq_ | the differences are huge, instead of adding 'const' to the type system, 'write' is added to the effect system |
| 13:10:58 | Araq_ | proc treeDepth(n: PNode): int {.writes: [].} |
| 13:11:14 | Araq_ | but it's mostly all inferred |
| 13:11:27 | Araq_ | no need to write 'writes: []' explicitly |
| 13:12:51 | dom96 | why is it a list? what would you put there if you do want to write? |
| 13:14:46 | Araq_ | dom96: a list of so called "path" expressions |
| 13:15:02 | Araq_ | a path is something like obj.field[i].fieldB |
| 13:16:33 | dom96 | So basically the actual 'thing' which gets written? |
| 13:17:01 | dom96 | so if in your example I do: n = PNode(...). writes will equal [n] ? |
| 13:17:38 | Araq_ | yes |
| 13:17:54 | Araq_ | but for local variable it's not interesting |
| 13:20:53 | dom96 | hrm, so instead of immutable data type we will get this then? |
| 13:20:55 | dom96 | *types |
| 13:22:52 | dom96 | wouldn't it be more convenient to mark data types immutable instead of marking each proc with 'writes: []' ? |
| 13:26:30 | EXetoC | being able to push and pop pragmas helps, I guess |
| 13:27:07 | dom96 | although you do say it will be inferred. |
| 13:27:17 | dom96 | I think I see what you mean. |
| 13:29:16 | EXetoC | right. you might want to force it though, but it's a good default |
| 13:30:12 | EXetoC | is the dot after { a way of minimizing ambiguities? |
| 13:32:24 | * | Araq_ quit (Read error: Connection timed out) |
| 13:33:11 | * | Araq_ joined #nimrod |
| 13:36:47 | * | Associat0r joined #nimrod |
| 13:37:12 | EXetoC | but I don't think you can have set literals in the same places, so I don't know about that |
| 13:49:32 | * | BitPuffin quit (Read error: Operation timed out) |
| 13:49:45 | Araq_ | EXetoC: it's an artifact; it was planned to support 3 syntaxes for nimrod |
| 13:50:03 | Araq_ | indentation based or using {} or using 'end X' |
| 13:50:14 | Araq_ | (which is why 'end' is a keyword btw) |
| 13:50:22 | EXetoC | oh |
| 13:50:35 | Araq_ | but I've never gotten around to implement that |
| 13:51:32 | Araq_ | and maintaining 3 parsers doesn't help me |
| 13:52:02 | Araq_ | so ... I don't know. I don't think it'll ever be implemented |
| 13:55:53 | Araq_ | dom96: immutability is hard to design properly |
| 13:55:59 | * | BitPuffin joined #nimrod |
| 13:56:13 | Araq_ | C++ and D have lots of issues with 'const' so I don't want to take that route |
| 13:56:41 | Araq_ | I'm not entirely sure how Rust avoids D's problems with 'const' |
| 13:58:07 | * | BitPuffin quit (Read error: Connection reset by peer) |
| 14:00:43 | Araq_ | bbl |
| 14:00:48 | * | Araq_ quit (Quit: ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]) |
| 14:02:52 | * | BitPuffin joined #nimrod |
| 14:04:00 | * | BitPuffin quit (Read error: Connection reset by peer) |
| 14:04:11 | EXetoC | well, there's no per-field mutability, but I don't know if that helps |
| 14:08:19 | * | BitPuffin joined #nimrod |
| 14:09:33 | EXetoC | but making individual struct fields const in D is a bad idea |
| 14:10:50 | EXetoC | and I don't know if this has anything to do with the const system, but having to cast away const when using the find function template for example is pretty stupid. good luck dealing with that if you're a newbie |
| 14:13:06 | Associat0r | mutability is the wrong default |
| 14:40:53 | * | Associat0r quit (Quit: Associat0r) |
| 16:20:40 | EXetoC | dom96: 0ad? |
| 16:26:15 | dom96 | ehh, later. |
| 16:27:12 | * | Mat2 joined #nimrod |
| 16:27:14 | Mat2 | hello |
| 16:28:35 | EXetoC | hi |
| 16:28:40 | EXetoC | dom96: ok, will do something useful instead :> |
| 16:28:47 | Mat2 | hi EXetoC |
| 16:33:38 | Mat2 | hi all |
| 16:34:12 | Mat2 | exist there an enum equivalent in Nimrod ? |
| 16:34:27 | Mat2 | (not shure if I asked that question before) |
| 16:37:35 | EXetoC | yes, it's called enum :> |
| 16:38:09 | Mat2 | wha, sorry, I mean something like an union in C |
| 16:42:24 | EXetoC | only tagged unions, but you can always achieve something similar using casts |
| 16:43:04 | Mat2 | yes, well - that is what I try to avoid |
| 16:53:24 | * | Sergio965 joined #nimrod |
| 16:54:07 | EXetoC | you can wrap it |
| 16:58:54 | Mat2 | I mask the bit slots out (and hope the compiler generate decent machine-code) |
| 17:15:16 | * | Associat0r joined #nimrod |
| 17:15:16 | * | Associat0r quit (Changing host) |
| 17:15:16 | * | Associat0r joined #nimrod |
| 17:21:04 | Mat2 | if I define an object x and another y which inherits x, can I invoke a public y.func (...) which is a method of x ? |
| 17:25:45 | EXetoC | I think so |
| 17:26:06 | Sergio965 | Mat2: That's pretty much what it means to inherit. |
| 17:28:45 | EXetoC | not always, but it might be a bit limited otherwise |
| 17:33:42 | Mat2 | Sergio965: thanks |
| 17:34:15 | Mat2 | ExetoC: Do you mean polymorphism ? |
| 17:37:02 | EXetoC | yeah, but you get one with the other in most languages I guess |
| 17:51:02 | Mat2 | polymorphism is really a bad idea if I think about it... |
| 17:57:10 | EXetoC | in general, or in your case? |
| 17:57:36 | Mat2 | in my case |
| 17:58:01 | EXetoC | ok |
| 17:58:45 | EXetoC | btw, dynamic dispatch is only used for methods |
| 18:01:46 | Araq | Associat0r: mutability is NOT the wrong default for systems programming |
| 18:02:27 | Araq | and it would be nice if there was a single benchmark to backup the claims from the "everything should be immutable camp" |
| 18:06:51 | * | Sergio965 quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 18:09:00 | Mat2 | hi Araq |
| 18:09:46 | Araq | hi Mat2 |
| 18:12:50 | Associat0r | Araq: I never said everything should be immutable |
| 18:13:32 | Associat0r | it's just the wrong defaulf for most things, even in systems programming |
| 18:14:06 | Araq | systems programming is about arrays, immutability is about trees |
| 18:14:23 | Araq | arrays are fundamentally mutable IMHO anyway |
| 18:14:40 | Associat0r | that's the represention |
| 18:15:38 | Araq | systems programming is all about representation |
| 18:17:17 | Mat2 | representation fits it quite well in my optinion |
| 18:17:24 | Mat2 | ^opinion |
| 18:17:50 | Araq | last time I checked Rust code was full of 'mut' |
| 18:18:11 | Araq | and as soon as you start to optimize it by hand more and more things become 'mut' |
| 18:19:39 | Associat0r | you could abstract away most mut in combinators |
| 18:19:51 | * | Sergio965 joined #nimrod |
| 18:20:19 | * | Endeg quit (Ping timeout: 264 seconds) |
| 18:21:07 | Araq | I could also simply use Haskell instead |
| 18:21:33 | Araq | somehow the Rust guys don't consider it appropriate for systems programming either |
| 18:22:47 | Mat2 | there exist indeed two projects exporing functional-programming languages for OS development because of similar reasons |
| 18:23:07 | Araq | only two, Mat2 ? ;-) |
| 18:23:07 | Mat2 | at moment |
| 18:23:13 | Associat0r | Haskell is non-strict by default and using mut is a pain there |
| 18:23:49 | Araq | well that seems to be exactly what you want though, making 'mut' a pain |
| 18:24:04 | Associat0r | and predictable perf and representation control is also more difficult in Haskell |
| 18:24:06 | Araq | also the non-strict by default has benefits for modularity |
| 18:24:08 | Mat2 | Araq: I expect some more approaches in time ;) |
| 18:24:25 | Araq | Mat2: history is full of these attempts |
| 18:25:11 | Mat2 | yes, the only succesful attempt I know is LispOS however |
| 18:25:14 | Associat0r | Araq: mut shouldn't be too much of a pain and it should have predictable perf |
| 18:25:46 | Associat0r | Lisp isn't really a FPL |
| 18:26:32 | Mat2 | I don't buy this |
| 18:26:39 | Araq | the compiler knows about the state monad and produces predictable perf in Haskell I think |
| 18:26:39 | Associat0r | I'm sure they used plenty of mutation in LispOS |
| 18:26:56 | Araq | Associat0r: indeed and you might ask yourself why |
| 18:27:14 | Araq | and no |
| 18:27:17 | Araq | the reason is not |
| 18:27:23 | Araq | "Lispers didn't get FP" |
| 18:28:25 | Associat0r | Lisp's didn't really encourage immutability |
| 18:29:14 | Associat0r | Araq: anyway my point is to not use mutation blindly |
| 18:29:20 | Mat2 | ehm, even a 'pure' FPL like Q is not completly free of immutability |
| 18:29:27 | Associat0r | but abstract that away properly |
| 18:30:35 | Associat0r | with combinators/DSLs etc |
| 18:31:04 | Araq | for word in allwords(file): countable.inc(word) # pseudocode for 'wc' |
| 18:31:37 | Araq | note the inherent mutability of 'counttable' in this solution |
| 18:31:56 | Araq | you can dance it around it with some functional data structure |
| 18:32:32 | Araq | but inherently the solution requires mutability and the workarounds are just that -- workarounds |
| 18:33:09 | Araq | and I don't see how a workaround improves things |
| 18:33:30 | Associat0r | the point is to isolate the mutatation |
| 18:36:39 | Araq | no the point is to be careful about mutations when you have aliases to the data |
| 18:36:52 | Araq | aliases are the problem, not mutation |
| 18:52:54 | Associat0r | Araq: btw why not just "let count = length(allwords(file))" |
| 18:53:49 | Associat0r | no need to make the client circus around with mutation needlesly |
| 18:54:04 | Araq | the point of a counttable is to count distinct words |
| 18:54:14 | Araq | ok that's not 'wc', my bad |
| 18:54:54 | Araq | counttable["wordA"] == 3, counttable["wordB"] == 2 etc. |
| 18:54:59 | Mat2 | both points have reasons: For 'pure' FPL's immutability is a demandment for assuring efficient parallel processing (obviously I know no common FP language which supporting auto-parallelization) |
| 18:55:07 | Associat0r | let count = length(set(allwords(word))) |
| 18:55:22 | Araq | that's still not the same Associat0r |
| 18:55:42 | Araq | unless your 'count' is not an int |
| 18:55:57 | Araq | but then your 'set' is wrong too |
| 18:56:19 | Araq | you don't have a single result in my example but a lookup table |
| 18:56:34 | BitPuffin | to be fair, things aren't mutable by default in nimrod |
| 18:56:43 | BitPuffin | I mean you can choose var or let or const |
| 18:56:46 | BitPuffin | there isn't a default |
| 18:56:58 | * | BitPuffin 's opinion |
| 18:57:09 | Araq | and sure ... you can hide everything behind a function call and pretend it doesn't use mutability under the hood |
| 18:57:31 | Associat0r | I was talking about default mutation in general |
| 18:58:13 | Associat0r | the point is if you abstract it behind functions it becomes composable |
| 18:58:38 | Araq | BitPuffin: true but the immutability is only shallow in Nimrod, let somePointer = p(); somePointer[] = 12 # no problem |
| 18:59:19 | Araq | though I never use that, I use 'var' here to improve readability |
| 18:59:29 | BitPuffin | is that really all that good? |
| 18:59:43 | BitPuffin | a let wants to be _let_ alone lol |
| 19:00:33 | BitPuffin | what lisp is totally mutable |
| 19:00:37 | Araq | I had no choice, 'let' needs to have the same semantics as argument passing for consistency |
| 19:02:04 | BitPuffin | you sure? I mean you shouldn't be able to pass a let variable to a var argument |
| 19:02:19 | Araq | that's not what I mean |
| 19:02:19 | BitPuffin | that just screams gotchas |
| 19:02:24 | Araq | that's not what I mean |
| 19:02:38 | BitPuffin | yes I saw it the first time, mind the delay from you to me :) |
| 19:03:09 | Araq | the 'let' variable is immutable but not what it points to |
| 19:03:16 | BitPuffin | my messages were sent before I got yours |
| 19:03:19 | BitPuffin | ah |
| 19:03:23 | BitPuffin | well I guess that makes sense |
| 19:03:28 | BitPuffin | memory isn't immutable |
| 19:03:50 | BitPuffin | but that pointer can't start pointing at some other address right? |
| 19:03:57 | Araq | right |
| 19:04:08 | BitPuffin | although I am not sure what kind of safety that provides |
| 19:04:13 | Mat2 | reads very rational to me |
| 19:04:58 | Mat2 | BitPuffin: No typless pointer arithmetic ? |
| 19:05:22 | Araq | BitPuffin: it only helps readability really, the compiler can do more optimizations with 'let' but it might as easily compute whether a 'var' is used as a 'let' |
| 19:05:33 | BitPuffin | Mat2: true, you don't crash because you tried accessing memory you don't have access to, I think? |
| 19:05:34 | EXetoC | I haven't had to care all that much about this, although I'm not sure how relevant it'll be with respect to the upcoming parallelization changes |
| 19:05:35 | Araq | instead and optimize these |
| 19:05:44 | EXetoC | or whichever term is more accurate |
| 19:06:22 | Araq | EXetoC: well the 'write' effects tracking is in preparation for the concurrency changes |
| 19:06:41 | EXetoC | makes sense |
| 19:08:56 | BitPuffin | Araq: guess we get slightly increased compile times for using let then hehe |
| 19:09:22 | BitPuffin | Araq: and also, just like noSideEffect it is a good noobgrammer blocker |
| 19:09:51 | Araq | BitPuffin: no you get slightly decreased compile times in theory as the compiler doesn't need to compute the 'let' variables |
| 19:10:09 | BitPuffin | Araq: yeah I ment decreased, sorry |
| 19:10:10 | Araq | in practice it's irrelevant |
| 19:10:28 | BitPuffin | I was probably gonna say increased compile time speed |
| 19:11:57 | BitPuffin | I am not sure I am confident immutability is the ultimate solution for parallelization |
| 19:12:40 | Araq | it's not, but it helps |
| 19:12:47 | BitPuffin | sure it does |
| 19:12:51 | BitPuffin | but it also imposes some problems |
| 19:12:52 | BitPuffin | anyways |
| 19:12:59 | * | BitPuffin is gonna continue reading |
| 19:13:37 | BitPuffin | I think you get enough benefits from making pure functions than just making everything immutable, it is a nice compromise since you also get very maintainable code |
| 19:21:09 | Associat0r | yeah if you have proper effect tracking, but explicit visible ques about what's mutable might still be usefull |
| 19:22:11 | Araq | Associat0r: the effects are annotated by the docgen |
| 19:22:18 | Araq | so you will be able to see them |
| 19:22:36 | Associat0r | I mean within the code itself |
| 19:23:49 | Araq | *shrug* thats just some IDE feature I guess; you can also write them down and the compiler checks them for you |
| 19:30:11 | * | gradha joined #nimrod |
| 19:38:26 | Mat2 | hmm, I have these backend object x and an inherited frontend object y. If I now call a procedure which has x as object parameter but is called with y I get a type error |
| 19:38:56 | Mat2 | so x has a different type as y |
| 19:39:54 | BitPuffin | Mat2: change it to a method? |
| 19:41:09 | Mat2 | hmm, have to read about method definations in the docs |
| 19:41:46 | BitPuffin | yeah I am not sure how it works |
| 19:42:08 | BitPuffin | I don't see why a proc wouldn't be able to take an object b of a where it expects an a |
| 19:43:38 | Araq | Mat2: that does work, it's likely some other problem |
| 19:44:19 | BitPuffin | in fact I can't even figure out what methods are for and why procs can't do their jobs, it feels like the things should be possible to determine statically but what do I know after all |
| 19:47:18 | gradha | methods are for dynamic dispatch, see if http://nimrod-code.org/manual.html#multi-methods helps explaining that |
| 19:47:27 | BitPuffin | well I have read it |
| 19:47:35 | BitPuffin | I just don't know when dynamic dispatch is needed |
| 19:48:17 | gradha | it looks like C++ virtual methods, if that's of any help |
| 19:48:39 | BitPuffin | well I know |
| 19:48:49 | BitPuffin | but I am not sure I still get the point |
| 19:49:03 | BitPuffin | it should be able to be figured out statically shouldn't it? |
| 19:49:17 | Mat2 | ok found the error, I have forget an parameter... ehm |
| 19:49:27 | EXetoC | if you don't want it to be overridden, you make it a proc |
| 19:49:45 | Mat2 | (the error messages are somewhat unclear to me I must say) |
| 19:50:53 | BitPuffin | EXetoC: so a proc is essentially an explicit form of saying don't override me? |
| 19:52:15 | EXetoC | usually it's not used in such a context, but yeah I guess |
| 19:52:29 | BitPuffin | if b is an object of a, the I don't see why I couldn't override proc foo(p: a) and create a proc foo(p: b) and if there is no foo for b it should call foo for a |
| 19:52:33 | EXetoC | you can overload it, but then you must rely on using the correct concrete type |
| 19:54:48 | EXetoC | yes, but then the overload is chosen at compile-time. no vtable indirections in other words |
| 19:55:19 | BitPuffin | but isn't it always possible to know it at compile time+ |
| 19:55:22 | BitPuffin | When would it not be? |
| 19:56:40 | Araq | BitPuffin: when you actually use inheritance to model polymorphic containers |
| 19:56:44 | gradha | as the author of "library code" you don't know the type of subclasses |
| 19:57:06 | Mat2 | Araq: Probably it is a good idea to tak a look at the error messages, I found them somewhat irritating |
| 19:57:15 | Mat2 | ^take |
| 19:58:03 | Araq | create a bug report then |
| 19:58:16 | BitPuffin | Araq: Well I still don't get why that wouldn't work with static dispatch, is it because the executable size would grow tremendously because it would have to compile each procedure for every polymorphic type? |
| 19:58:31 | Araq | I think they are excellent but I'm weird and know how the compiler works |
| 19:58:34 | Mat2 | Araq: ok |
| 19:58:59 | BitPuffin | sometimes the error messages are a bit.. well unhelpful |
| 19:59:14 | gradha | BitPuffin: if your library code calls "proc(type a)", no matter how much you subclass it the library code will still not call your override |
| 19:59:46 | BitPuffin | gradha: because it is already compiled and done? |
| 20:00:01 | gradha | no, because you are calling proc(type a), with type a |
| 20:00:37 | BitPuffin | but if be is of a, then why can't the proc that takes an a take a b? |
| 20:00:51 | BitPuffin | they should have the same fields after all |
| 20:00:54 | Araq | BitPuffin: it can |
| 20:01:03 | BitPuffin | Araq: then why have methods? |
| 20:01:32 | gradha | the b type is accepted by your proc using type a, but your implementation for b is not called |
| 20:01:33 | BitPuffin | if it isn't because it is already compiled and done I can't see why |
| 20:02:04 | BitPuffin | gradha: because the library doesn't know about b's implementation? |
| 20:02:32 | gradha | yes, to the module where it uses a, b doesn't exists, so it can't statically call the proc version accepting b |
| 20:02:37 | BitPuffin | but shouldn't it know about b's implementation if they are compiled together? |
| 20:02:53 | BitPuffin | like if it is not a library |
| 20:02:56 | BitPuffin | or whatever |
| 20:03:06 | BitPuffin | you know that they will be compiled into the same executable |
| 20:03:15 | BitPuffin | can you safely use a proc like a method in that case? |
| 20:03:16 | gradha | well, if it's not a library you don't need methods, because you know all the procs for all types |
| 20:03:32 | gradha | usually end user code doesn't need methods at all |
| 20:04:26 | BitPuffin | okay so if I am writing library-like code, except it isn't compiled as a library but is instead compiled with the full project it should work like a method because the proc will know about b's implementation in this case? |
| 20:04:40 | BitPuffin | if yes, then I understand |
| 20:05:19 | BitPuffin | if not, well then fuck programming :P |
| 20:05:19 | gradha | that's something you can answer yourself: does your module implementing the a type "import b"? |
| 20:06:16 | BitPuffin | well no, but if b has inherited from a and overrides a method that a module in a calls for a types, shouldn't the compiler be able to figure it out? |
| 20:06:37 | gradha | err... no |
| 20:06:39 | * | Mat2 compiler frontend is finished (so port is comlete), only left some testing |
| 20:06:45 | Mat2 | ^complete |
| 20:07:21 | Araq | BitPuffin: no, nimrod is not java where everything is virtual per default |
| 20:07:51 | BitPuffin | Araq: but if it is all during the same compilation process I don't see why it couldn't somehow figure it out |
| 20:08:00 | BitPuffin | guess it is because I haven't written a compiler |
| 20:08:02 | gradha | well, maybe you don't want that? |
| 20:08:05 | Araq | you use 'proc' and get static binding or you use 'method' and get dynamic binding |
| 20:08:40 | gradha | imagine I'm writing some security procs, would I want random people to override them and mess with whatever I'm doing? |
| 20:08:45 | BitPuffin | hmm |
| 20:08:51 | BitPuffin | well then I guess the final question is |
| 20:09:37 | BitPuffin | if it is all in the same project, and you use method to get the dynamic binding, shouldn't you be able to optimize it so that it works like dynamic binding (ie call the overriden version) but use static dispatch instead because you already know the definition of the overriden method? |
| 20:09:42 | BitPuffin | performance++ |
| 20:10:57 | gradha | couldn't you load dynamic libraries at runtime though? |
| 20:11:02 | gradha | like dlls |
| 20:11:02 | Araq | that's an optimization called devirtualization |
| 20:11:15 | BitPuffin | Araq: does nimrod have it? |
| 20:11:24 | Araq | no |
| 20:11:28 | BitPuffin | will it? |
| 20:11:42 | BitPuffin | gradha: why not blow up your computer :P |
| 20:11:52 | Araq | sure it's not hard to do |
| 20:12:09 | BitPuffin | coolio |
| 20:12:20 | Araq | but that doesn't mean it's important or a good idea ;-) |
| 20:12:22 | gradha | BitPuffin: plugins? anyway, if you care so much you could implement the method as a template now |
| 20:12:29 | BitPuffin | Araq: why would it be a bad idea? |
| 20:12:48 | Araq | I don't feel like encouraging people to use methods |
| 20:12:55 | BitPuffin | gradha: well this way you would get both |
| 20:12:57 | Araq | I consider methods evil |
| 20:13:10 | BitPuffin | Araq: why? (I might already know wh) |
| 20:13:17 | BitPuffin | but I want to know your opinion |
| 20:13:34 | BitPuffin | is it because you can get unexpected behaviour? |
| 20:13:56 | Araq | well closures are often the nicer alternative to polymorphic objects |
| 20:14:30 | BitPuffin | Araq: then why have methods at all? make clojures neater than methods and no-one would miss them |
| 20:15:06 | BitPuffin | although I guess I don't see why clojures don't have the same problems as methods |
| 20:15:07 | Araq | well we have closures and they are "neat" and yet you don't even know the bijection between them :P |
| 20:15:16 | Araq | it's *closure* btw |
| 20:15:22 | BitPuffin | oops |
| 20:15:25 | Araq | clojure is a programming language |
| 20:15:34 | * | BitPuffin knew that |
| 20:15:36 | dom96 | I still have not once used methods, I don't even get why I would use them. |
| 20:15:41 | BitPuffin | brains can fart you know |
| 20:16:30 | Araq | BitPuffin: I prefer enum+cases over inheritance and dynamic binding almost always |
| 20:17:00 | BitPuffin | Araq: but then why do we have dynamic binding? |
| 20:17:19 | BitPuffin | if it is a bad thing, shouldn't people be taught to use the better option |
| 20:17:22 | Araq | as the enum way forces you to do a state enumeration and this tends to produce more readable code and makes you think about all the states |
| 20:17:24 | BitPuffin | (closures)? |
| 20:18:56 | BitPuffin | anyways brb read |
| 20:20:55 | reactormonk | dom96, is "foo"[1..2] not valid in nimrod? |
| 20:21:38 | dom96 | I think so, why not check? |
| 20:23:04 | gradha | Araq: you mentioned you prefer to write ALL_CAPS for mutable stuff, so all your object fields are ALL_CAPS? |
| 20:25:11 | gradha | shiny... new Diablo 3 expansion: Reaper of Wallets |
| 20:26:08 | Araq | gradha: no I said, "if anything, global mutable variables should scream at you" |
| 20:26:26 | Araq | I don't use ALL_CAPS |
| 20:28:33 | gradha | I'm experimenting with ALL_CAPS for all mutable variables, but it gets weird with object hierarchies |
| 20:28:49 | Araq | fields are not variables |
| 20:29:14 | gradha | composition of objects sort of makes them variables, maybe, who knows |
| 20:29:37 | Araq | a compiler doesn't know about "sort of" |
| 20:29:54 | Araq | I guess I think too much like a compiler now ... |
| 20:30:30 | gradha | if I pass an object to a proc, not using var, can't I modify it's field if it's say a mutable string? |
| 20:30:53 | Araq | that's correct you can't |
| 20:34:41 | gradha | nice |
| 20:41:33 | gradha | I like the IF_MUTABLE_ITS_ALL_CAPS_SCREAMING_AT_YOU, so I'll be making my effort to start this new coding trend, sorry for attributing it to you |
| 20:42:06 | gradha | rereading your post again makes me wonder what happens in my mind |
| 20:45:31 | Araq | gradha: I often use a 'g' prefix for globals fwiw |
| 21:28:34 | gradha | trying to use the xmltree <> macro I get "lib/core/macros.nim(336, 25) Error: undeclared identifier: 'newStringTable'" |
| 21:29:26 | Araq | that can be fixed now |
| 21:29:37 | Araq | the language wasn't up to it until recently :P |
| 21:30:01 | Araq | well ... some year ago but whatever |
| 21:34:32 | gradha | did it ever work? |
| 21:35:49 | Araq | well it still works but you need to import strtabs |
| 21:36:16 | Araq | that you need to import it on your own can be avoided nowadays |
| 21:36:33 | gradha | ok, thanks |
| 21:38:30 | gradha | recently I used C macros to generate xml trees for a string, quite crippled |
| 21:39:17 | Araq | that's sad |
| 21:39:23 | Araq | you should have used Nimrod |
| 21:40:27 | gradha | the worst part was the #defines could only build the static string, you still need to manually keep track of parameters for %s formatting |
| 21:40:55 | gradha | still, it was an improvement over manually typing the tags |
| 21:41:45 | gradha | did you get a chance to try the ouroboros module? |
| 21:43:39 | * | Sergio965 quit (Quit: Bye! :)) |
| 21:44:22 | Araq | sorry no |
| 21:44:28 | Araq | I'm very busy these days |
| 21:44:40 | Araq | not much time for any productive work |
| 21:45:56 | gradha | hmm... still get an error for echo(<>a(href="http://nimrod-code.org", "Nimrod rules.")) |
| 21:46:22 | gradha | it works if I remove the "Nimrod rules" part |
| 21:46:29 | Araq | what's the error message? |
| 21:46:37 | gradha | deferred_minus_gallery.nim(250, 9) Error: type mismatch: got (string, Array constructor[0..0, string], PStringTable) |
| 21:46:37 | gradha | but expected one of: |
| 21:46:38 | gradha | xmltree.newXmlTree(tag: string, children: openarray[PXmlNode], attributes: PXmlAttributes): PXmlNode |
| 21:48:14 | gradha | I guess I'll use cgi.XMLencode and report a bug on that |
| 21:48:57 | Araq | well I don't get it, iirc dom96 uses <> and it works |
| 21:49:21 | dom96 | huh |
| 21:49:34 | dom96 | why are you using xmltree? why not htmlgen |
| 21:49:42 | dom96 | I use htmlgen not xmltree iirc |
| 21:49:45 | Araq | but the error message is clear I think |
| 21:50:00 | Araq | and the example is wrong :P |
| 21:50:15 | dom96 | with htmlgen you can just omit the <> |
| 21:50:38 | gradha | dom96: I'm just testing the example, I was creating random non html tags |
| 21:50:38 | Araq | <>a(href="http://nimrod-code.org", <>"Nimrod rules.") # might work |
| 21:50:49 | dom96 | i see |
| 21:51:23 | gradha | that changes slightly the error |
| 21:51:24 | gradha | deferred_minus_gallery.nim(271, 42) Error: type mismatch: got (string) |
| 21:51:24 | gradha | but expected one of: |
| 21:51:24 | gradha | xmltree.newXmlTree(tag: string, children: openarray[PXmlNode], attributes: PXmlAttributes): PXmlNode |
| 22:00:13 | Araq | ah yeah |
| 22:01:40 | Araq | <>a(href= "http://nimrod-code.org", newText("Nimrod rules.")) |
| 22:02:39 | gradha | bingo |
| 22:03:53 | Araq | well that looks like I never tested it :-/ |
| 22:04:19 | Araq | or maybe there used to be another overloaded newXmlTree |
| 22:06:14 | * | [2]charles quit (Ping timeout: 264 seconds) |
| 22:09:55 | Mat2 | ciao |
| 22:10:02 | gradha | bye bye |
| 22:10:21 | * | Mat2 quit (Quit: Verlassend) |
| 22:26:08 | * | OrionPK joined #nimrod |
| 22:56:53 | * | EXetoC quit (Quit: WeeChat 0.4.1) |
| 22:59:14 | * | EvilAww quit (Quit: ZNC - http://znc.in) |
| 23:11:06 | gradha | good night |
| 23:11:10 | * | gradha quit (Quit: bbl, need to watch http://www.youtube.com/watch?v=OzrkmcBMPYo again) |
| 23:56:55 | * | noam quit (Ping timeout: 264 seconds) |