| 00:02:01 | Amrykid | YAY for MVVM |
| 00:13:33 | * | q66 quit (Remote host closed the connection) |
| 02:08:33 | * | Trix[a]r_za is now known as Trixar_za |
| 03:15:12 | * | Boscop quit (*.net *.split) |
| 03:20:13 | * | Boscop joined #nimrod |
| 03:28:51 | * | Trixar_za is now known as Trix[a]r_za |
| 03:55:33 | * | Madison is now known as MadiKitty |
| 04:39:14 | * | fowl quit (Ping timeout: 258 seconds) |
| 04:50:59 | * | OrionPK quit (Quit: Leaving) |
| 05:08:21 | * | fowl joined #nimrod |
| 05:16:54 | * | apotheon_ joined #nimrod |
| 05:25:29 | * | apotheon quit (*.net *.split) |
| 05:37:44 | * | fowl quit (Read error: Connection reset by peer) |
| 05:39:37 | * | fowl joined #nimrod |
| 06:25:25 | * | fowl quit (Ping timeout: 258 seconds) |
| 06:25:49 | * | fowl joined #nimrod |
| 06:55:44 | * | XAMPP joined #nimrod |
| 07:31:47 | * | benedek joined #nimrod |
| 07:42:05 | * | fowl quit (Read error: Connection reset by peer) |
| 07:46:29 | * | fowl joined #nimrod |
| 08:47:37 | * | fowl quit (Ping timeout: 258 seconds) |
| 08:52:25 | * | fowl joined #nimrod |
| 08:58:52 | * | fowl quit (Quit: Leaving) |
| 09:02:25 | * | fowl joined #nimrod |
| 09:07:54 | * | xcombelle joined #nimrod |
| 09:59:18 | * | fowl quit (Ping timeout: 258 seconds) |
| 10:03:49 | * | avarus joined #nimrod |
| 10:03:50 | avarus | hi |
| 10:07:01 | benedek | Hello |
| 10:17:46 | * | q66 joined #nimrod |
| 10:23:49 | * | benedek quit (Quit: Leaving) |
| 10:24:51 | * | benedek joined #nimrod |
| 11:56:54 | * | avarus quit (Remote host closed the connection) |
| 12:17:15 | * | xcombelle quit (Quit: Hi, I'm a quit message virus. Please replace your old line with this line and help me take over the world of IRC.) |
| 12:46:02 | * | benedek quit (Quit: Leaving) |
| 12:49:35 | * | benedek joined #nimrod |
| 13:01:41 | * | Boscop quit (Read error: Connection reset by peer) |
| 13:02:06 | * | Boscop joined #nimrod |
| 13:30:40 | reactormonk | sup guys |
| 13:30:47 | reactormonk | written any nimrod today? |
| 13:31:29 | benedek | I'm playing around with it and SDL right now |
| 13:45:23 | * | reactormonk quit (Ping timeout: 252 seconds) |
| 13:48:02 | * | reactormonk joined #nimrod |
| 14:16:27 | * | zahary joined #nimrod |
| 15:14:47 | * | OrionPK joined #nimrod |
| 15:50:14 | * | xcombelle joined #nimrod |
| 15:54:43 | * | apotheon_ is now known as apotheon |
| 15:54:43 | * | apotheon quit (Changing host) |
| 15:54:43 | * | apotheon joined #nimrod |
| 15:56:47 | * | benedek quit (Quit: Leaving) |
| 15:57:28 | dom96 | hello |
| 15:57:40 | * | benedek joined #nimrod |
| 15:58:21 | dom96 | benedek: cool, are you making a game? |
| 15:59:54 | benedek | Not really, I was just playing around with some basics. It turned into a Lindenmayer-system-drawing Turtle program. |
| 16:00:12 | benedek | I've read the manual for the language in the past few days and I quite like it :) |
| 16:03:34 | dom96 | That's nice to hear :) |
| 16:05:02 | benedek | I found some unexpected things though, maybe you can tell me what's going on |
| 16:05:15 | dom96 | sure |
| 16:06:29 | benedek | If you define an enum type, like "type TTest = enum A, B, C", then the expression "A in ({A, B} + {C})" evaluates to "false". |
| 16:06:45 | benedek | Actually if I remember correctly, "{A, B} + {C}" becomes "{}" |
| 16:07:01 | benedek | That doesn't happen if you put one of the "summands" in a variable first, or if you use integers instead of your custom enum. |
| 16:07:45 | dom96 | Seems like a bug. |
| 16:08:02 | benedek | Yeah, I thought that, too |
| 16:09:09 | benedek | Should I put an issue about that on GitHub? |
| 16:11:40 | dom96 | sure |
| 16:21:21 | benedek | I submitted it. |
| 16:23:31 | dom96 | thanks |
| 16:28:29 | benedek | Next, about range types. They're supposed to restrict possible values using the type system and add some static guarantees, right? |
| 16:31:02 | benedek | For example, I see that if you use a "case" block with a range-typed value, the compiler makes sure that you handle all the cases, like for range[1..3], it's an error if you don't have "of 1", "of 2" and "of 3" (or an "else"). |
| 16:31:37 | benedek | Or if you assign a value to a range-typed value, a runtime check is usually placed. |
| 16:32:02 | benedek | But the problem is that range types are initialized as 0. |
| 16:32:24 | benedek | So if you use a default-initialized variable like this, these checks aren't done. |
| 16:32:46 | benedek | You can have a "case" which the compiler accepted, but still doesn't handle all the possibilities. |
| 16:34:49 | dom96 | hrm, so a range[1..3] will be initialised to a 0? |
| 16:34:53 | dom96 | That sounds like a bug too :\ |
| 16:36:05 | benedek | It's documented in the manual though |
| 16:36:30 | dom96 | wow, this seems really buggy. |
| 16:37:06 | dom96 | Assigning a value which is out of range does not result in an error. |
| 16:38:03 | benedek | I thought it checked if you assign from another type... |
| 16:39:06 | dom96 | Well this should certainly fail: var s: range[2..4] = 0 |
| 16:40:34 | benedek | Yeah, that gives an error for me |
| 16:41:05 | dom96 | oh, what version of nimrod are you running? |
| 16:41:34 | benedek | HEAD |
| 16:41:42 | benedek | I think ranges were even more troublesome with 0.9.0 |
| 16:42:12 | benedek | I found some more issues with that version, but most of them had disappeared with the newest GitHub versions |
| 16:42:30 | benedek | Right now the only thing I noticed that breaks ranges is the default initial value. |
| 16:44:46 | benedek | Here's the part of the manual I mentioned: http://build.nimrod-code.org/docs/manual.html#var-statement |
| 16:45:59 | dom96 | interesting. So the manual actually states that the value may be out of the valid range. |
| 16:46:54 | dom96 | Also, I just pulled and recompiled. It seems that the bug I encountered was fixed quite recently. |
| 16:47:19 | benedek | That might be, I only started using the language a few days ago :) |
| 16:47:21 | dom96 | Araq may be around later today, safer to ask him about this. |
| 16:47:26 | benedek | Alright |
| 16:48:18 | benedek | I have noted down a few more little quirks, maybe I'll wait until he arrives |
| 16:48:54 | dom96 | sure |
| 16:49:37 | benedek | Also I wanted to mention that I really like the idea of object variants (having a field in an object which decides what other fields that object can have at runtime, like a safe "union"); does any other language that you know have that feature? |
| 16:51:13 | dom96 | I'm not aware of any others sorry. |
| 16:53:21 | benedek | Hehe no problem, this feature might be unique to Nimrod then :D |
| 16:55:42 | dom96 | Have you checked out TR macros yet? That's another cool feature of Nimrod which is most definitely unique ;) |
| 16:57:42 | dom96 | Nimrod as a whole is very unique. There is not other language which combines macros with a python-like syntax and which also compiles to C. |
| 16:57:45 | dom96 | *no |
| 16:58:43 | reactormonk | aaand JS. |
| 16:58:52 | reactormonk | Even though that's slightly buggy ;-) |
| 16:59:20 | dom96 | true |
| 16:59:23 | benedek | What does TR stand for? |
| 16:59:34 | dom96 | term rewriting |
| 16:59:50 | benedek | Ah, like the stuff for optimizations? Or is that a different thing? |
| 17:00:24 | benedek | Oh yeah I see, that is indeed the optimizing feature. |
| 17:01:53 | benedek | Yes, I am very happy this language had that... I learnt a little bit about C++ expression templates in a uni course, and those are very complicated. |
| 17:02:11 | benedek | TR macros seem to simplify those kinds of optimizations a lot :) |
| 17:03:43 | benedek | Proper macros are one of the main reasons I took a look at this language at all. I stared learning a little bit of Common Lisp recently, and I wondered why no other language had such powerful macros. |
| 17:08:53 | benedek | * started |
| 17:12:07 | * | fowl joined #nimrod |
| 17:18:04 | * | exhu joined #nimrod |
| 17:18:06 | benedek | dom96: Have you done any projects with Nimrod? |
| 17:18:39 | dom96 | benedek: yeah, quite a lot actually. Aporia, babel, nimbuild, jester |
| 17:19:02 | benedek | Oh right, I saw that you were involved with Aporia, too. |
| 17:21:10 | Araq | hi benedek, thanks for your testing efforts :-) |
| 17:21:27 | benedek | That's pretty cool. I haven't written any big frameworks or tools like these, I just make small toys involving some physics and graphics. I almost never have the patience to keep working on them after they reach at most 2000 lines of code :) |
| 17:21:28 | reactormonk | Araq, sup ^^ |
| 17:21:34 | benedek | Oh hi Araq! |
| 17:21:50 | Araq | it's a bug that var s: range[1..3] doesn't triggger at least a runtime check |
| 17:21:51 | benedek | It's my pleasure, this language is fun to play around with :) |
| 17:22:05 | exhu | hola! |
| 17:22:14 | reactormonk | Araq, javascript! |
| 17:22:30 | Araq | reactormonk: my new parser now works and compiles most of the Nimrod code that I've around here |
| 17:22:33 | benedek | Ah alright... but do you think that statement should trigger an error? How about setting the default value to the minimum or something like that? |
| 17:23:23 | exhu | Araq, a new parser? are you rewriting the compiler? |
| 17:23:52 | Araq | the problem is not really with scalars, these are easy to deal with, benedek, but I really want the memset(x, 0); for compound types |
| 17:24:14 | Araq | default initialization is required for memory safety |
| 17:24:24 | Araq | but it should be as efficient as possible |
| 17:25:02 | Araq | exhu: well the new parser is based on the old one, so no ... but I wanted to test some ideas I had |
| 17:25:12 | Araq | to make it more flexible |
| 17:25:45 | Araq | turns out the ideas do work, but unfortunately don't make correctness any easier ;-) |
| 17:25:50 | exhu | hidden c++-like static constructors are evil, so initializing with zero (although invalid value for a range type) is better than constructors chain behind the scene |
| 17:27:34 | benedek | Right, but I still think that type safety should be pretty important... I guess there has to be a compromise somewhere :) |
| 17:32:48 | exhu | benedek, compromis is to initialize everything with zero -) |
| 17:33:22 | benedek | Yeah, that's what I meant :) |
| 17:33:33 | exhu | benedek, one needs to be consistent, if you get ranges properly initialized then you must add constructor support for objects, tuples etc. |
| 17:34:40 | exhu | benedek, and it this will bring a whole pack of problems to solve, i.e. order of initialization/cycle dependency of constructors... |
| 17:38:13 | benedek | exhu: Do you think these problems might be tackled in some future version of the language? I understand you can't deal with everything at once in a developing language like this. |
| 17:38:57 | Araq | exhu: order of initialization/cycle deps are no problem with 'range' though |
| 17:39:55 | Araq | benedek: it's actually pretty easy to implement; I like the default of 0 + runtime or compile time check better than "init with min" though |
| 17:40:07 | Araq | so that rule should stay as it is |
| 17:40:49 | exhu | Araq, i am for your "zero init + checks" solution. |
| 17:41:29 | benedek | Araq: When would the extra runtime checks fire? Right at "var x: range[1 .. 3]" or later, like in a "case" or assignment? |
| 17:41:52 | Araq | right at 'var x: range[1..3]' |
| 17:42:15 | Araq | it can be easily done at compile time in this case |
| 17:42:18 | benedek | Then how do you deal with objects that have a range typed element? |
| 17:42:45 | benedek | Objects can't be initialized at declaration, right? |
| 17:42:54 | Araq | sure they can |
| 17:43:03 | Araq | the syntax for it is new though |
| 17:43:17 | Araq | var x = TObject(fieldA: 3, fieldB: "string") |
| 17:43:38 | benedek | Oh cool, I didn't know that |
| 17:44:07 | benedek | How about functions that return an object? They have the implicit "result", right? |
| 17:44:12 | Araq | http://build.nimrod-code.org/docs/documentation.html |
| 17:44:22 | Araq | are the most recent docs |
| 17:44:39 | * | fowl quit (Ping timeout: 258 seconds) |
| 17:45:30 | Araq | what's up with the A in {A, B}+{C} bug? o.O |
| 17:45:43 | Araq | the compiler uses + for sets quite a bit |
| 17:46:05 | benedek | (ah I see, I must have missed the object construction when reading the manual) |
| 17:46:12 | benedek | I don't know, can you reproduce it? |
| 17:46:30 | benedek | I think it even worked correctly in some cases where one of the two literals was replaced by a variable. |
| 17:46:33 | benedek | brb |
| 17:54:32 | benedek | back; If I try to do something like "for i in ({A} + {B, C}): echo i" it prints nothing, either. |
| 17:59:37 | Araq | yeah, I will have a look later |
| 18:00:17 | Araq | looks like constant folding for small sets is broken |
| 18:04:20 | benedek | Are tuple literals with only one field possible? Like a literal corresponding to a "tuple[x: int]", I mean. |
| 18:05:14 | Araq | no, you can do this though: |
| 18:05:31 | Araq | proc makeTup(x: int): tuple[x: int] = result.x = x |
| 18:05:58 | benedek | Oh right, I still wanted to say things about the ranges, in exactly those circumstances. |
| 18:06:04 | Araq | tuples with 1 field are pretty pointless in a statically typed language though ... ;-) |
| 18:06:35 | Araq | oh lol |
| 18:06:38 | benedek | What if you replace the tuple field there with "tuple[x: range[1 .. 3]]", for example? The result variable is always default-initialized, right? |
| 18:06:39 | Araq | I'm wrong |
| 18:06:49 | benedek | (I agree that 1-tuples are pointless :) ) |
| 18:07:05 | Araq | you can use a named tuple literal (x: 1) |
| 18:07:29 | Araq | for some reason I always forget this solution :P |
| 18:07:34 | benedek | Are you sure? If I try that, I get "Error: invalid expression: 'a: 2'" |
| 18:07:50 | Araq | hmm |
| 18:08:06 | benedek | Or x: 1 in this case. The comma seems to be important. |
| 18:08:10 | Araq | you need the () |
| 18:08:27 | Araq | and you need to double it for calls: p((x: 1)) |
| 18:08:51 | benedek | I have this line: "var o: (x: 1)" |
| 18:08:58 | benedek | * "var o = (x: 1)" |
| 18:09:06 | * | fowl joined #nimrod |
| 18:09:25 | Araq | maybe I disallowed it for some reason I can't remember |
| 18:09:56 | benedek | Alright. It's not a big problem. But what about the issue with the ranges? |
| 18:10:34 | Araq | dunno, your point is valid |
| 18:11:38 | Araq | we can check at runtime that the value that escapes is in the valid range though |
| 18:12:20 | benedek | But you would still have the same problem inside the function, for example with "case result.rangedValue ..." |
| 18:12:29 | Araq | yeah |
| 18:12:57 | Araq | we can also require explicit 'result' initialization for this case though |
| 18:13:16 | benedek | Something like with C++ constructors, maybe? |
| 18:14:05 | Araq | it's a simple dataflow analysis; C# and Java do this for locals |
| 18:16:28 | * | exhu quit (Quit: Ex-Chat) |
| 18:17:34 | benedek | That's good. Different question: How flexible is tuple unpacking? I seem to be able to do it only on a separate "var" line, and nowhere else. |
| 18:17:58 | benedek | (sorry for asking so much, I have written a list of things I noticed while learning and testing the language :D) |
| 18:19:18 | Araq | true, it's only allowed in var/let for now |
| 18:19:57 | Araq | I never needed it anywhere else; (x, y) = (y, x) is 'swap' for instance |
| 18:20:18 | Araq | and more general pattern matching should be done with a macro anyway |
| 18:21:49 | benedek | I think it would be nice to have it at more places, at least for consistency... I think I have met a case where it would have been slightly useful, but it's always avoidable, you're right. |
| 18:24:05 | Araq | I have nothing against it, but there are always far more important things to do |
| 18:24:57 | benedek | Of course! This is a very minor thing, I'm sure this is not the biggest issue :) |
| 18:25:16 | reactormonk | benedek, maybe Araq can tell you how to hook a macro in there |
| 18:25:41 | Araq | and most people are busy writing articles about how SSA improved their productivity and how it excels at concurrency ... ;-) |
| 18:26:07 | benedek | SSA? |
| 18:26:22 | Araq | so we can always pretend it's "because it encourages a functional design" :P |
| 18:26:24 | reactormonk | Araq, can you? ;-) |
| 18:26:42 | benedek | It's not that important :) |
| 18:26:49 | Araq | reactormonk: what? |
| 18:27:02 | Araq | match x: |
| 18:27:06 | reactormonk | Araq, the macro |
| 18:27:16 | Araq | of (23, > 3): echo "23 and > 3" |
| 18:27:21 | Araq | etc. ... |
| 18:27:26 | benedek | I haven't experimented with macros too much yet. I've just tried the "debug" macro from the manual, and it seemed to not work with literals... |
| 18:27:35 | * | fowl quit (Ping timeout: 258 seconds) |
| 18:28:24 | Araq | oh damn, I didn't update the example |
| 18:28:29 | benedek | Anyways, I want to ask about the indexing operators, `[]` and `[]=`. |
| 18:29:03 | Araq | add an {.immediate.} to the macro definition and it should work |
| 18:29:13 | benedek | Ah alright, I'll try that later. |
| 18:29:56 | benedek | Say you want to write a custom vector object which allows syntax like "echo v[2]", "v[2] = 23", but also "(v[2]) = 42". |
| 18:30:37 | benedek | I can get the first two to work if I override `[]`(v: TVector ...) and `[]=`(v: var TVector ...). |
| 18:31:03 | benedek | Or I can get the last two to work if I just override `[]`(v: var TVector ...). |
| 18:31:31 | benedek | But if I override both `[]`(v: TVector...) and `[]`(v: var TVector), I get an ambiguity error. |
| 18:32:02 | benedek | (the first, of course, is necessary to index r-values) |
| 18:32:16 | Araq | currently you need both [] and []= but it's a known issue |
| 18:32:47 | Araq | [](v: var TVector): var T # should be enough for '=' support |
| 18:33:01 | Araq | but yeah I know it doesn't work yet |
| 18:33:20 | Araq | you are supposed to get around the ambiguity error with AST based overloading |
| 18:33:24 | benedek | Yeah, that what I've been thinking... C++ does it that way, too, right? The only problem in Nimrod with that is that it clashes with the non-var variant, correct? |
| 18:34:12 | Araq | [](v: (var TVector){lvalue}) # should be preferred over v: TVector then |
| 18:35:46 | Araq | btw 'range' is supposed to work for floating point types too |
| 18:36:02 | Araq | but admittedly it's even less tested for floats :-/ |
| 18:36:49 | Araq | the AST based overloading also makes 'move' operators like C++ superfluous |
| 18:39:31 | benedek | I'm playing around with it, trying to understand it :) |
| 18:42:24 | Araq | AST based overloading evolved from TR macros and I don't think any other language has it :P |
| 18:43:19 | benedek | I can't say I know too many languages, but may things in Nimrod seem very unique to me! |
| 18:43:47 | benedek | I also mentioned object variants to dom96; do other languages have that? |
| 18:45:45 | benedek | Hm, is a `[]=` necessary if you already have a `[]` with "var"? |
| 18:45:49 | * | gradha joined #nimrod |
| 18:46:18 | benedek | Without the `[]=`, I can do "(v[2]) = 7", but not "v[2] = 7". |
| 18:47:01 | Araq | yeah I know it's buggy |
| 18:47:48 | Araq | it gets worse when combined with macros ;-) |
| 18:48:25 | benedek | The executable also seems to crash when I try to do this with a "distinct array" :] |
| 18:49:43 | dom96 | Araq: Is there any documentation regarding how exactly params are passed to procedures? (whether it is by-ref or by-val) |
| 18:49:56 | Araq | object variants are copied over from Ada/Delphi |
| 18:50:12 | Araq | Delphi's are much more like C's unions though |
| 18:50:34 | * | fowl joined #nimrod |
| 18:51:07 | Araq | dom96: it's "use what's more efficient for the type" |
| 18:51:43 | * | zahary quit (Quit: Leaving.) |
| 18:51:46 | dom96 | Araq: Yeah, but is the full behaviour documented anywhere? |
| 18:51:59 | Araq | you can use the bycopy or byref pragmas to override it per type |
| 18:52:17 | Araq | it's in the manual and in the tutorial I think |
| 18:52:44 | benedek | Araq: I see. Alright, I have one final question, then I'll leave you guys alone. Have you considered building in the `&=` for the seq type? I know there's "add", but seq already has `&`, and it might be more consistent with the string type if it had `&=` also :) |
| 18:53:13 | dom96 | Araq: I couldn't find anything about it in the manual, in the tutorial all I found was this: "Parameters are constant in the procedure body. Their value cannot be changed because this allows the compiler to implement parameter passing in the most efficient way." |
| 18:53:57 | Araq | benedek: object variants are quite like "sum types" in functional programming languages, however they are more flexible at the cost of checking at runtime vs. checking at compile time |
| 18:54:43 | Araq | dom96: that's the paragraph I meant though |
| 18:55:46 | Araq | benedek: you can easily do: template `&=`(x, y: expr) = add(x, y) ;-) |
| 18:56:04 | dom96 | Araq: Want me to document this fully in the manual? |
| 18:56:06 | Araq | I considered &= but found 'add' easier to type :P |
| 18:56:22 | dom96 | IMO that paragraph in the tutorial is a bit vague |
| 18:57:05 | Araq | hmm sure but why is it important? |
| 18:57:24 | benedek | I know I know, but I'm thinking about the consistency with strings :]. Strings seem very much like seqs, so I would assume them to have the same basic operations. |
| 18:58:04 | Araq | there is a &= for strings? o.O |
| 18:58:26 | benedek | http://build.nimrod-code.org/docs/system.html#687 |
| 18:59:45 | Araq | alright then 'seq' should have it for consistency ... |
| 18:59:58 | benedek | Yay! |
| 19:00:02 | Araq | oh and please report the crash you got with a distinct array |
| 19:00:41 | Araq | we could also deprecate &= for strings now that I know of its existance ... :P |
| 19:00:57 | dom96 | Araq: I think some people may be worried that their params will be passed by-val. Others may be interested to know how exactly the compiler determines whether to pass by-val or by-ref, like myself :) |
| 19:01:25 | fowl | benedek: hey if you're looking for some code examples https://github.com/Araq/Nimrod/wiki/Community-Projects |
| 19:01:28 | benedek | That would be possible, too :) |
| 19:01:42 | benedek | Although I like &=. |
| 19:01:53 | benedek | fowl: Thanks! |
| 19:02:09 | fowl | Araq: when nimrod hits 1.0 will you get the stdlib tattooed across your body so the api cant change? :p |
| 19:04:45 | Araq | I always thought we never ever need to change the API :P |
| 19:06:11 | benedek | I have submitted the issue with the distinct arrays. The program actually segfaults. |
| 19:06:47 | Araq | the program or the compiler? |
| 19:07:41 | Araq | dom96: why would they worry? the tut sayst the compiler knows better ... ;-) |
| 19:08:01 | benedek | The executable program, not the compiler fortunately :) |
| 19:09:12 | dom96 | Araq: Alright. But i'm still curious how it works exactly. :P |
| 19:10:14 | benedek | I have to go now. I might come back in an hour or so. Bye! |
| 19:10:19 | Araq | bye |
| 19:10:51 | Araq | dom96: it's actually not that simple and may change again ... :P |
| 19:11:18 | dom96 | lol |
| 19:11:23 | dom96 | That explains why it's not documented :P |
| 19:12:05 | Araq | for instance, any type containing a type that refers to GC'ed memory, is passed by reference iirc |
| 19:14:48 | * | benedek quit (Ping timeout: 252 seconds) |
| 19:16:38 | dom96 | ahh, so we're at the mercy of the almighty compiler :P |
| 19:17:58 | Araq | well check out ccgtypes.nim and document it :P |
| 19:23:04 | dom96 | Sounds fun. I should be reading more of the compiler source code. |
| 19:26:25 | fowl | it intimidates me every time i look in there o.o |
| 19:26:42 | dom96 | yeah, same. |
| 19:26:59 | dom96 | ccgtypes so far looks pretty simple |
| 19:27:22 | dom96 | Araq: What does this new parser of yours improve? |
| 19:28:03 | Araq | for a start, it should fix the 'do' parsing bug ... |
| 19:28:25 | Araq | and it allows for things like: |
| 19:28:32 | Araq | p(if x: a |
| 19:28:35 | Araq | else: b) |
| 19:28:50 | Araq | note that 'else' is enforced to be aligned on the 'if' |
| 19:29:10 | Araq | well that's not implemented as it would break code |
| 19:29:20 | dom96 | that makes sense |
| 19:29:27 | Araq | but it could trigger a warning for the next version |
| 19:29:27 | fowl | is that allowed currently? |
| 19:29:37 | gradha | count me against enforcing visual indentation, I use logical indentation |
| 19:29:38 | fowl | i never tried to break an inline if into newlines |
| 19:29:57 | Araq | fowl: I think it works nowadays :P |
| 19:30:09 | Araq | gradha: what do you mean? |
| 19:31:07 | gradha | p could be very long |
| 19:31:20 | Araq | so you prefer: |
| 19:31:27 | Araq | p(if x: a |
| 19:31:31 | gradha | reallylongsomething(if x: a |
| 19:31:33 | gradha | else: b) |
| 19:31:37 | Araq | <any indent>else: b) |
| 19:32:02 | gradha | of course I can't comment on this particular case, as I still don't know how would I use it, but I just prefer logic indentation |
| 19:32:12 | gradha | if something "overflows", you add indentation, when you finish, you reduce |
| 19:32:13 | dom96 | but then what happens with more complicated nested if expressions? |
| 19:32:32 | gradha | in fact, I might do |
| 19:32:35 | gradha | reallylongsomething( |
| 19:32:38 | gradha | if x: a |
| 19:32:40 | gradha | else: b |
| 19:32:47 | Araq | but that would be fine then |
| 19:32:52 | gradha | oh, forgot the closing brace, now some lisp user is dying |
| 19:33:00 | Araq | as the 'else' is aligned to the 'if' |
| 19:34:24 | Araq | anyway, I'll take your opinion into account, gradha; I'm not sure if the idea is a good one yet |
| 19:36:17 | Araq | actually the main goal of the new parser was that the grammar is easier to write down in the spec; this failed as the new way is as complex to document as the old way |
| 19:45:54 | dom96 | cool. I think I found it. Everything is passed by-val except for objects which are not {.final.} and tuples (depending on their size?) |
| 19:47:02 | Araq | that sounds wrong |
| 19:47:19 | Araq | by-val always depends on the size |
| 19:47:47 | dom96 | hrm, perhaps the function I am reading is only a small part of some other function |
| 19:49:32 | * | xcombelle quit (Remote host closed the connection) |
| 19:50:28 | Araq | fowl: I don't mind it to be intimidating and of course I'm biased; however I think the nimrod compiler's sources are much easier to follow than any other production compiler that I've seen |
| 19:51:56 | Araq | most compilers produce (optimized) assembler and this fact alone makes them much harder |
| 19:52:51 | dom96 | Araq: hrm, I dunno. I think the proc I found is the only one used. |
| 19:53:12 | gradha | the interblags are full of comments saying gcc is dying, partially because it's difficult to integrate with other stuff |
| 19:53:29 | gradha | the other part is ego, but doesn't everything come to that at some point? |
| 19:53:46 | dom96 | Araq: I'm looking at the ccgIntroducedPtr proc |
| 19:54:38 | fowl | yeah i think i understand it a bit more every time i check it out |
| 19:56:12 | Araq | dom96: you're right |
| 19:56:36 | Araq | however, for 'tyObject' it contains: or (getSize(pt) > platform.floatSize * 2) |
| 19:56:59 | Araq | so size plays a role for objects too |
| 19:57:18 | dom96 | ahh, yes, of course. Forgot to mention that. |
| 19:58:56 | Araq | gcc might be dying but if so, it lived for 3 decades or something |
| 19:59:24 | Araq | and it's a VERY successful project but most measures |
| 19:59:34 | Araq | *by most |
| 20:00:37 | Araq | and I'm almost more concerned about GCC's shitty build system than about the actual source |
| 20:01:12 | gradha | hah, precisely one of the recent comments I saw was about how it's impossible to build |
| 20:01:14 | Araq | you can treat most of the source as a black box; you can't do the same with the build system |
| 20:01:18 | fowl | Araq: hey are you planning to add array[X, Y] as a shortcut for array[0..X-1, Y] |
| 20:01:29 | fowl | where X is an int |
| 20:01:42 | Araq | make a feature request, I keep forgetting it |
| 20:02:19 | fowl | can this be done with a term rewriting macro? |
| 20:02:27 | Araq | no |
| 20:02:45 | Araq | TR macros are very bad at changing semantics |
| 20:03:04 | Araq | it's however perhaps 3 lines in the compiler |
| 20:09:20 | gradha | can a macro "inspect" the current global variables and get their names? say, I write some const PREFIX_blah and I want a macro to "extract" all PREFIX_blah constants |
| 20:09:44 | gradha | and of course, the macro would do something with these PREFIX_blah consts, hopefully something useful |
| 20:09:51 | Araq | no |
| 20:10:00 | Araq | you can do: |
| 20:10:05 | Araq | register: |
| 20:10:12 | Araq | const PREFIX_Blah = ... |
| 20:10:28 | Araq | and then in 'register' add them to some compiletime global |
| 20:10:41 | Araq | and then query this global later |
| 20:10:43 | gradha | so register is another macro working with the following one using its results |
| 20:10:50 | gradha | will do |
| 20:11:22 | fowl | in that case you would just scan the body passed and do result = body |
| 20:12:38 | Araq | gradha: I'm not a fan of this though, why not pass a larger block to the macro instead? |
| 20:13:03 | gradha | no idea, the question popped in my mind |
| 20:14:00 | gradha | maybe it could be useful for cases involving includes |
| 20:14:12 | Araq | access to the symbol table could be provided via an API |
| 20:14:32 | Araq | though I like to see valid use cases before exposing that |
| 20:14:52 | gradha | otherwise it's lifetime support, like the unofficial macro api |
| 20:17:00 | Araq | it also makes code REALLY hard to read |
| 20:17:26 | Araq | const yeah_you_cant_rename_reliably_anymore = "argh" |
| 20:17:52 | Araq | it's as bad as .NET's reflection |
| 20:18:19 | Araq | where you also can't rename as some fool might access the field via reflection |
| 20:19:12 | gradha | talking about .net, recently heard the stackoverflow podcast, they had some guy from the C# team |
| 20:19:26 | gradha | he said he regreted baking non-nillable types later into the language rather than at the beginning |
| 20:20:18 | Araq | it would be nice if these non-nillable guys would in fact starting to describe how to solve the problem for systems programming language |
| 20:20:40 | Araq | because for now I haven't seen any impressive solution |
| 20:21:12 | gradha | no idea, I like nilable types, though they are a pain in languages were things crash if they find a nil |
| 20:22:00 | gradha | the podcast is this one http://blog.stackoverflow.com/2013/03/podcast-45-keeping-it-sharp/ |
| 20:22:16 | fowl | I can trust myself to not hit a nil, or if nil is ok as a value I can trust myself to guard usage of it |
| 20:22:55 | gradha | the key there is "trust myself", I rarely code against only my code |
| 20:23:29 | fowl | now, in ruby, nil can pop up and bite you in the ass at any time |
| 20:23:29 | Araq | 1) we already have 'not nil' as an annotation in the language |
| 20:23:51 | Araq | 2) I'm however interested in how it would prevent compiler bugs |
| 20:24:01 | gradha | fowl: really? that's awesome |
| 20:24:05 | Araq | it turns out 'not nil' is mostly useless in the compiler |
| 20:24:19 | Araq | as I can't use it in the interesting cases |
| 20:24:50 | Araq | things are a bit different if you make 'class' a reference type as it's done in C# and Java |
| 20:25:20 | Araq | because then you end up using references anywhere and then not nullable types help more |
| 20:29:21 | dom96 | Araq: Use Maybe instead :P |
| 20:30:07 | Araq | dom96: the problem is that you have a nilable type but know it can't be 'nil' in that context |
| 20:30:26 | Araq | and yet the compiler forces you to check against 'nil' |
| 20:30:58 | Araq | and then you do: if x.isNil: crash("can't happen") |
| 20:31:29 | fowl | var s: string not nil; echo s.isNil #=> true |
| 20:31:53 | Araq | fowl: I know it's not implemented for now :P |
| 20:32:47 | Araq | however the 'if' is exactly what old school pointer types gave you for free |
| 20:32:49 | gradha | come on Araq, that's old fashioned, now you would if x.isNil: newException(ESomethingUnCatchable, "Sorry!") |
| 20:32:51 | fowl | ah |
| 20:33:40 | gradha | is there something you can raise but can't catch? |
| 20:33:48 | Araq | yeah |
| 20:33:48 | dom96 | Araq: Have you seen this? http://nickknowlson.com/blog/2013/04/16/why-maybe-is-better-than-null/ |
| 20:34:07 | dom96 | There is!?! My world is shattered. |
| 20:34:52 | gradha | in early versions of python not all exceptions inherited from the same base, so it was fun catching against a "base" type, only there were many of them |
| 20:35:29 | Araq | dom96: no, but the article doesn't contain anything new |
| 20:36:18 | Araq | lets look at the compiler ... node.typ is the type; that can be 'nil' in general, however for expressions after semantic checking it's not nil |
| 20:36:35 | Araq | so ... how do I deal with that at the type system level? |
| 20:36:56 | Araq | you can't really without introducing dependent typing |
| 20:37:17 | Araq | which is a very complex thing |
| 20:37:31 | Araq | how do the blog posts deal with this issue? |
| 20:37:35 | Araq | they don't |
| 20:38:17 | Araq | gradha: you're not supposed to catch EInvalidIndex for instance as the array indexing is not checked in release mode |
| 20:38:44 | Araq | you're supposed to write code that doesn't access invalid array elements instead, believe it or not ;-) |
| 20:39:08 | gradha | you had me at "you're supposed to write code" |
| 20:40:13 | gradha | I don't understand what's the adavantage of wrapping nil in another object, you can still ignore it and crash |
| 20:41:00 | dom96 | gradha: You can't. If you forget to handle it you will get a compiler error. |
| 20:41:06 | dom96 | *compile time error |
| 20:42:01 | Araq | yeah and thus it forces you to write some guard like 'if x.isNil' everywhere |
| 20:42:13 | Araq | so ... lets make it non nillable instead |
| 20:42:17 | gradha | if maybe.isNotNil: doSomethingTo(maybe.data) else: doSomethingTo(maybe.data) |
| 20:42:44 | gradha | does maybe work that way? what magic does it do to trust you don't use the data in the wrong branch? |
| 20:42:47 | Araq | gradha: a proper type system won't be fooled by that |
| 20:43:18 | Araq | it knows you can acess it in the isNotNil branch and not in the other |
| 20:43:34 | gradha | ah, I forget the key here is the maybe gets transformed to the non nil type |
| 20:43:49 | Araq | so ... how do we make it non nilable for our real world example? |
| 20:44:18 | Araq | easy: we'll have a dummy type object and initialize every node with that instead |
| 20:44:22 | Araq | and voila! |
| 20:44:31 | Araq | what was once a crash is now a logical bug |
| 20:44:43 | Araq | good luck fnding those instead |
| 20:44:43 | dom96 | Araq: so your example requires that a field can be null at some point in time, but it cannot be in some other point in time? |
| 20:44:51 | Araq | dom96: yes. |
| 20:44:55 | Araq | 'time' is key here |
| 20:44:58 | dom96 | sounds fun |
| 20:45:04 | gradha | just like object variants |
| 20:45:06 | Araq | type systems don't model time well |
| 20:45:21 | dom96 | Why not have two different types? |
| 20:45:43 | Araq | gradha: except that Nimrod's object variants DO not force you to check the discriminant everywhere either |
| 20:45:50 | Araq | and now you know why ... :P |
| 20:46:37 | Araq | dom96: that's actually a very good idea but then you lose some polymorphism |
| 20:46:50 | Araq | and I tried it in practice for the transf.nim pass |
| 20:47:06 | Araq | it complicates the code and found no bug |
| 20:48:11 | Araq | and btw |
| 20:48:28 | Araq | how come nobody uses ATS, the one language that in fact implements dependent typing? :P |
| 20:48:42 | gradha | so that's this ATS? |
| 20:49:43 | gradha | well, it uses a not-like-c-or-java-syntax, that's why nobody uses it |
| 20:50:37 | Araq | one guy that I spoke with knows it intimately |
| 20:50:55 | Araq | and said the type sytem really starts to suck for strings ... :P |
| 20:53:27 | gradha | sounds like fun for sql interaction |
| 20:54:07 | Araq | or anything web related for that matter |
| 20:54:49 | gradha | dom96: my idea wasn't that crazy about storing json in sql, people are actually using it http://backchannel.org/blog/friendfeed-schemaless-mysql |
| 20:55:09 | gradha | s/sql/full relational database/ |
| 20:56:26 | Araq | "Yes, in Scala you can still get NullPointerExceptions. Scala doesn’t have non-nullable reference types because Martin Odersky (for what were probably good reasons - I’m guessing related to java interop) decided to include null in his language. " |
| 20:56:43 | Araq | ok, I decided to include 'nil' for C interop :p |
| 20:57:19 | Araq | seriously ... what's up with these guys? F# has null too |
| 20:57:32 | Araq | they didn't manage to get rid of it |
| 20:57:49 | Araq | even though it's a new very functional language |
| 20:58:07 | gradha | maybe they didn't consider nil to be the devil? |
| 20:58:46 | Araq | maybe they think crashes are easier to debug than logical errors? |
| 20:58:50 | Araq | ;-) |
| 20:59:50 | gradha | programming in objc taught me to stop worrying and love the nil |
| 21:00:19 | dom96 | Does haskell have nil? |
| 21:01:20 | gradha | dom96: weren't you the one who knew haskell? |
| 21:02:08 | dom96 | Yeah. But I haven't used it enough to warrant dealing with C interop in it. |
| 21:02:27 | dom96 | I can only see it using nil for that. |
| 21:02:28 | Araq | dom96: http://stackoverflow.com/questions/3962939/whats-the-difference-between-undefined-in-haskell-and-null-in-java |
| 21:03:15 | dom96 | Also i'm too lazy to google ^^ :P |
| 21:16:02 | JStoker | Why does nimrod ban use of tabs? I get that you might want all code contributed to nimrod itself using spaces or whatever, but why ban them entirely? |
| 21:17:23 | Araq | mixing tabs and spaces doesn't work well |
| 21:17:51 | Araq | and yet that's what people want to do, "use tabs for indentation, spaces for alignment, dammit" |
| 21:18:48 | Araq | however I have yet to encounter a single code base where this has been done consistently |
| 21:19:01 | OrionPK | fuckin tabbers |
| 21:19:14 | Araq | Guido himself said if he were to do Python again, he forbid tabs |
| 21:20:01 | Araq | most code I see however uses tabs as a compression for 8 spaces |
| 21:20:30 | Araq | and so I can't change my editor settings |
| 21:21:39 | gradha | Araq: whole allegro library uses 8 column hard tabs but logical indentation of 3 |
| 21:21:53 | gradha | I know because I contributed to it |
| 21:22:10 | JStoker | Surely if they want to have horrific codebase, that's their own problem? (I don't like using spaces for alignment, but do prefer using tabs for indentation.) |
| 21:22:52 | Araq | so what would be your solution? |
| 21:23:27 | Araq | python treats tabs as 8 spaces too (or rather that mod 8 thing) |
| 21:24:58 | JStoker | Treating it as 8 spaces would be fine, 4 spaces, 1, whatever. I don't mix them in code (for indentation, at least.) so I don't know. :-) |
| 21:25:04 | gradha | it's hard to take a stand in spaces vs tabs: people who care about them usually have power editors, the kind which can be configured to work in any situation without problem |
| 21:26:19 | Araq | JStoker: what's wrong with making your TAB key produce spaces? |
| 21:26:43 | Araq | it's not that I dislike the key ... ;-) |
| 21:27:07 | JStoker | Araq: I use tabs in all other languages, and don't really want to fork my editor to support adjusting tabs vs spaces based upon the language of the file currently open. |
| 21:27:59 | Araq | which editor is that btw? |
| 21:28:09 | JStoker | nano |
| 21:28:53 | fowl | JStoker: are you sure nano wont do this? i know you can do syntax highlighting, per-language tab settings like one step away from that |
| 21:28:55 | JStoker | I also just prefer tabs anyway, means backspace just gets rid of a level of indentation with only one press, but you know <lazy> |
| 21:29:38 | JStoker | fowl: I'm not 100% sure, I know it supports the syntax highlighting, but as far as i'm aware, it's only supports the colouring stuff in the language specific files... Might have a test. |
| 21:30:21 | JStoker | Error in /home/jstoker/.nano/nimrod.nanorc on line 18: Command "set" not allowed in included file |
| 21:30:28 | JStoker | Damnit, nope, doesn't like it. Awww. |
| 21:31:50 | fowl | JStoker: there are cli options for it http://www.nano-editor.org/dist/v2.3/nano.html |
| 21:32:09 | * | zahary joined #nimrod |
| 21:32:24 | fowl | -T and -E |
| 21:32:28 | fowl | set tabsize "n" |
| 21:32:31 | JStoker | fowl: However, I need to remember to go tell it that i'm wanting to use spaces every time i open a file, heh. |
| 21:32:32 | fowl | set tabstospaces |
| 21:33:01 | JStoker | And that does it across all files I open, including the ones I want to edit with tabs (vast majority of them ;p) |
| 21:35:05 | fowl | alias nimname="nano -T -E" |
| 21:35:09 | fowl | nimnano |
| 21:35:31 | fowl | this if the first time i've met someone committed to nano lol:p |
| 21:36:34 | JStoker | Nano is just brilliant though! :p |
| 21:39:26 | gradha | http://alleg.sourceforge.net/stabledocs/en/ahack.html K&R, with 3 space indentation. On disk, though, tab stops are 8 spaces, so if for example a line was indented by 12 spaces, this would be saved out as either 12 space characters or 1 tab and 4 spaces, not as 4 tabs |
| 21:40:08 | gradha | I'm positive the 5.x codebase doesn't mix spaces and tabs |
| 21:40:38 | Araq | gradha: yeah, lets compress spaces on 100GB HDs ... |
| 21:41:08 | gradha | I think the reson for hard tabs was console output |
| 21:41:20 | fowl | what does this mean? 3 space indentation, but tabs count as 8 |
| 21:41:27 | fowl | how does one indent one level? |
| 21:41:31 | gradha | but then, UNLIKE other stuff, Allegro supported DOS 8.3 and was copied on disks |
| 21:42:37 | gradha | I remember downloading the 1Mb tar.gz on a 28Kb modem |
| 21:43:06 | gradha | fowl: it means you need to have a really special editor for the tab key to do the right thing |
| 21:43:39 | gradha | I was using setedit at that time |
| 21:43:58 | fowl | gradha: allegro is old and dusty, you should try sdl2 :) |
| 21:43:59 | gradha | since rhide got old |
| 21:44:41 | gradha | fowl: I'm not so much into games now, more about command line parsing and stuff |
| 21:47:39 | fowl | gradha: what made you turn from games to command line parsing? are you depressed? |
| 21:48:03 | gradha | pretty much that |
| 21:48:30 | fowl | oh:( |
| 21:49:02 | gradha | it's been like that for the past seven yers, don't think I'll recover |
| 21:52:17 | fowl | hm this is awkward |
| 21:52:56 | Araq | gradha: you know what helps against a depression? checking out new technologies |
| 21:53:15 | Araq | port Nimrod to NaCl :P |
| 21:53:22 | gradha | lol |
| 21:57:30 | dom96 | ugh, screw NaCL |
| 21:57:38 | dom96 | He should write a OpenGL game in Nimrod instead. |
| 22:05:30 | * | fowl quit (Ping timeout: 264 seconds) |
| 22:10:51 | OrionPK | they're not mutually exclusive :P |
| 22:10:57 | OrionPK | (nimrod and nacl) |
| 22:11:16 | gradha | neither opengl and nacl i would hope |
| 22:11:40 | OrionPK | u could use webGL, dunno about full openGL |
| 22:14:30 | Araq | hmm |
| 22:14:36 | Araq | we still need a websockets module |
| 22:16:32 | * | gradha quit (Quit: bbl, have youtube videos to watch) |
| 22:16:56 | OrionPK | that'd be pretty spiff |
| 22:18:56 | * | fowl joined #nimrod |
| 23:03:43 | reactormonk | Araq, socket.io wrapper? |
| 23:20:13 | * | fowl quit (Ping timeout: 240 seconds) |
| 23:28:43 | * | fowl joined #nimrod |
| 23:46:04 | * | fowl quit (Ping timeout: 256 seconds) |
| 23:57:19 | * | fowl joined #nimrod |