| 01:58:21 | * | shevy quit (Ping timeout: 252 seconds) |
| 02:11:27 | * | shevy joined #nimrod |
| 03:12:20 | * | Psyclonic quit (Quit: Leaving) |
| 03:30:44 | * | avenidadebelgica joined #nimrod |
| 07:00:28 | * | llm joined #nimrod |
| 08:04:18 | * | Araq_ quit (Quit: ChatZilla 0.9.88.2 [Firefox 12.0/20120420145725]) |
| 08:08:44 | Araq | llm: so my point was basically: "eval" is nice, but you can hack around with "include" + recompilations |
| 08:09:02 | Araq | and gain all sorts of static checks |
| 10:19:49 | * | zahary joined #nimrod |
| 10:43:01 | llm | Araq, but isn't it that i was talking about days ago? |
| 10:45:16 | llm | Araq, an runtime-compilation based eval |
| 10:50:32 | Araq | llm: perhaps, but 'include' exists today and provides a workaround |
| 10:51:02 | Araq | ping zahary |
| 10:52:52 | llm | what does mean include here excatly - using code beeing on harddisk - or? |
| 10:53:27 | Araq | I'll only skimmed your changes and dislike your "optimizations with globals", I prefer to keep it readable and make the compiler perform the hoisting instead; transformations dealing with destructors should hardly become a speed issue anyway. |
| 10:54:20 | Araq | and every global requires a complex data flow analysis for the incremental compilation feature |
| 10:54:56 | Araq | llm: yes, very much like C's #include |
| 10:55:02 | Araq | brb |
| 10:56:09 | llm | but string based "inclusion" will come later? |
| 11:11:20 | zahary | hi Araq |
| 11:13:34 | Araq | llm: what do you mean "string based inclusion"? you can do that with a macro today |
| 11:13:37 | Araq | hi zahary |
| 11:14:15 | Araq | llm: but the string has to be a compile-time value ;-) |
| 11:14:49 | llm | Araq, why can't it be a runtime-value, if the compiler works as an service |
| 11:15:20 | llm | Araq, maybe i just don't get what you want to archiv |
| 11:17:17 | Araq | we talked about it already, an 'eval' feature requires scope injection |
| 11:17:45 | Araq | if you have a 'compile(string)' in the stdlib that's only 50% of the solution |
| 11:18:32 | Araq | eval supports: 'var x, y: int; compile("x + y")' |
| 11:20:04 | Araq | in fact, if you implement a plugin feature, you provide an API for a plugin to use |
| 11:20:34 | Araq | and this API needs to be provided in some way; scope injection is one solution |
| 11:26:59 | Araq | so zahary, do we want a 'hoist' pragma |
| 11:27:19 | Araq | or do we want to wait until the term rewriting macros are ready? |
| 11:28:22 | zahary | with the global pragma and gensymed consts produced from templates I don't see much need for specialized hoist pragma |
| 11:29:45 | zahary | we both understand hoist as "move the computation out of the function (at program startup)" and not "move it out of the loop", right? |
| 11:30:40 | Araq | right |
| 11:30:54 | Araq | if the arguments are constant |
| 11:31:27 | Araq | I'd argue the optimization is common enough to warrant a special pragma |
| 11:31:45 | Araq | especially since the compiler already does the "is arg const?" analysis already |
| 11:34:22 | zahary | maybe if we had the active pragmas, hoist could be a library helper that just rewrites to the lower level idiom. I like the DIY approach, because it's using the more orthogonal basic building blocks that can be used in other situations too and thus they are something the users should know how to use |
| 11:35:56 | zahary | proc re(p: expr{string} or string) is not much longer than proc re(p: string {.hoist.}) |
| 11:36:27 | Araq | proc re(p: expr{string} or string) is bizarre ... |
| 11:36:31 | zahary | I and would argue it reads better too |
| 11:36:55 | Araq | it's confusing even for me :P |
| 11:36:57 | zahary | static{string} or string ? |
| 11:37:34 | Araq | better |
| 11:37:42 | Araq | but doesn't make sense |
| 11:38:04 | Araq | if it's either or static{string} or a string ... |
| 11:38:14 | Araq | *either a static string or a string ... |
| 11:38:24 | zahary | yes, that's what it means |
| 11:38:32 | Araq | and how would I look it up what it means? |
| 11:38:44 | Araq | 'hoist' is easy to lookup |
| 11:39:12 | Araq | in fact |
| 11:39:17 | Araq | you'd need: |
| 11:39:40 | Araq | proc re(p: static{string}): TRegex = ... optimized version ... |
| 11:39:51 | zahary | well, my point is that people should be comfortable with static params - this is something that's important part of the language |
| 11:39:53 | Araq | proc re(p: string): TRegex = ... ordinary version ... |
| 11:40:07 | Araq | right? |
| 11:40:39 | zahary | not necessarily, because you can still use a when clause inside the proc if the difference between them is very minor |
| 11:40:47 | Araq | ok |
| 11:40:54 | zahary | if they are very different, then 2 overloads make more sense |
| 11:41:05 | Araq | but if you use a macro you can inspect the argument |
| 11:41:14 | Araq | and don't mention this fact in the header |
| 11:42:24 | zahary | it's true, you are giving up part of overload resolution then as the macro won't play nice with other overloads |
| 11:42:27 | Araq | static{string} is a subset of string |
| 11:42:44 | zahary | more specific, yes |
| 11:42:54 | Araq | so it's strange to write it as |
| 11:43:01 | Araq | static{string} or string |
| 11:47:13 | zahary | well, If you find it weird, they you find it weird and I probably can't convince you, but I personally like it much better than a specialized pragma with just a single purpose - the constraints with this approach can be arbitrary and it's much more general. it's also possible to say: type hoisted[T] = static{T} or T |
| 11:47:43 | zahary | *, then you find it weird * |
| 11:47:52 | Araq | alright |
| 11:51:26 | Araq | 'type hoisted[T] = static{T} or T' is not bad |
| 11:53:36 | Araq | I stil prefer a hoist pragma though as it's easy to implement and can easily merge different occurances of re"[abc]" |
| 11:54:27 | Araq | but yes you can do the same in a macro |
| 11:56:51 | Araq | on the other hand, if you have re(pattern, flags) your solution starts to win |
| 11:57:10 | Araq | ;-) |
| 11:58:15 | zahary | why so? I the hoist pragma still would have been applied to the param? |
| 11:58:40 | Araq | no in my mind it belongs to the proc |
| 11:58:51 | Araq | not to a single param |
| 11:59:35 | zahary | I see. then yes, per param gives some additional value |
| 11:59:53 | Araq | hm |
| 12:00:21 | Araq | but you can't hoist re("static", variable) |
| 12:00:50 | zahary | with my approach? |
| 12:01:02 | Araq | no in principle |
| 12:01:40 | Araq | so it's a property of the proc, not of the param |
| 12:02:24 | zahary | depends on the "re" library writer. If he figures out that there is some regular expression processing that's not affected by the variable, then he can still apply some optimizations |
| 12:03:14 | Araq | that's true |
| 12:03:27 | Araq | but it's a very specialized hoist operation then |
| 12:03:37 | Araq | in fact, I thought you meant: |
| 12:04:05 | Araq | macro hoist() = ... # general optimization |
| 12:04:13 | Araq | proc p {.hoist.} = ... |
| 12:04:29 | Araq | and in fact, macros as pragmas are planned |
| 12:04:48 | zahary | I suggested them after all :) |
| 12:05:03 | Araq | yes, but I always had them in mind :P |
| 12:06:03 | zahary | but I had some doubts whether we need them after all, because they are easily mappable to |
| 12:06:03 | zahary | pragma: |
| 12:06:03 | zahary | affected defs |
| 12:06:03 | zahary | …. |
| 12:06:18 | Araq | so it's only a small difference wether the macro hoist exists in system.nim or wether it's in the compiler |
| 12:06:58 | Araq | yes they are easily mappable, but needed for consistency |
| 12:07:05 | zahary | well, if it's in the compiler I strongly suggest that it just remaps the param to static{T} or T |
| 12:07:16 | zahary | no need for multiple paths in the compiler doing the same thing |
| 12:07:46 | Araq | true, but the code generator already has a "constant data merge" operation we could make use of |
| 12:08:34 | zahary | that's not the most important part of the implementation. it's caching the "instantiations" of the proc for each unique compile-time value |
| 13:17:38 | * | llm quit (Quit: ChatZilla 0.9.88.2 [Firefox 13.0/20120601045813]) |
| 13:41:59 | * | apriori_ joined #nimrod |
| 14:47:04 | * | filwit joined #nimrod |
| 14:47:54 | filwit | hi guys |
| 14:48:06 | Araq | hi filwit |
| 14:48:33 | Araq | zahary: I forgot to ask: can we use your destructor lifting for '=' too? cause that was my plan |
| 14:48:58 | filwit | so last night I found time to make a couple Nimrod logos |
| 14:49:28 | filwit | there's still sorta rough, but I'm happy with the overall design direction. want to see? |
| 14:49:36 | Araq | sure |
| 14:49:40 | filwit | let me load them to the web |
| 14:52:21 | zahary | yes, I was thinking how to handle = too. one difference is that you can have multiple overloaded procs for = with different "copy-from" types. |
| 14:53:32 | filwit | http://reign-studios.com/nimrod/logo-mock1.png |
| 14:53:50 | zahary | so, there is a small difference in the first part of the algorithm "is there a destructor/operator = defined by the user?", but it's not much of a problem |
| 14:54:49 | Araq | hm but if you have multiple "copy-from" types that shouldn't be lifted |
| 14:55:02 | Araq | there is a canonical '='(x: var T, y: T) |
| 14:55:35 | Araq | and only that is to be lifted |
| 14:56:10 | Araq | I don't think the other '=' should be lifted |
| 14:56:57 | Araq | filwit: it's nice but I prefer some gold :-) |
| 14:57:44 | zahary | yes, I know, my plan was to keep this canonical assign in a TType field just like a destructor, but you still have to run overload resolution first (or at least check that it's needed) |
| 14:57:48 | filwit | btw, every time I build Nimrod, do I need to re-extract the csources? |
| 14:58:36 | filwit | Araq: the thoughts behind the colors are: purple=regal, blue=clinical (code). but I will try one with Gold in it |
| 14:58:54 | filwit | Araq: usually Gold and purple go well with each other |
| 14:59:35 | Araq | meh, I don't like purple :-) |
| 14:59:53 | Araq | gold and blue could work ... |
| 15:00:09 | filwit | you don't like the purple that's there at all? |
| 15:00:41 | Araq | I don't like purple. anywhere. ;-) |
| 15:00:48 | filwit | lol, okay |
| 15:00:56 | filwit | I'll try without gold instead |
| 15:01:16 | Araq | good, also try *with* gold ;-) |
| 15:01:37 | filwit | ;-P |
| 15:02:17 | filwit | I don't need to re-extract csources after pulling Nimrod do I? |
| 15:02:30 | filwit | (before building Nimrod) |
| 15:02:42 | Araq | filwit: no, not in general |
| 15:02:58 | Araq | sometimes the older version can't compile the newer one |
| 15:03:06 | Araq | and then it's needed to go through the C step |
| 15:03:18 | filwit | I see |
| 15:03:39 | Araq | zahary: I'd check at definition time of '=' wether it's (var T, T) |
| 15:04:14 | Araq | dunno why you need to run overload resolution on it |
| 15:04:26 | zahary | I meant at call sites |
| 15:04:38 | filwit | btw, zahary, you closed the case/of issue on github but I still get a "invalid indentation" error when I try to compile with 'of' tabbed out |
| 15:04:52 | filwit | has that code not been merged to master yet? |
| 15:05:18 | zahary | filwit, hmm, can you provide exact example? |
| 15:05:26 | filwit | one sec |
| 15:05:32 | zahary | it's merged in the latest head |
| 15:06:40 | filwit | well I just pulled and rebuilt, and have a case/of/else (else is tabbed as well) in a simple file and it fails |
| 15:06:58 | filwit | the case/of is in a 'proc main =' |
| 15:07:44 | filwit | basically the full code looks like: |
| 15:07:49 | filwit | type Day = enum |
| 15:07:54 | filwit | Mon, Tue, Wed, Thu, Fri, Sat, Sun |
| 15:08:00 | filwit | proc main = |
| 15:08:07 | filwit | var d = Wed |
| 15:08:12 | filwit | case d: |
| 15:08:20 | filwit | of mon, tue: echo "life sux" # error here |
| 15:08:26 | filwit | of wed, thu: echo "life's ok" |
| 15:08:31 | filwit | else: echo "life rox" |
| 15:08:38 | filwit | .. that's it |
| 15:09:39 | dom96 | filwit: holy wow, those logos are beautiful! |
| 15:09:41 | zahary | I've just tried it and it works for me |
| 15:10:01 | filwit | dom96, :-) |
| 15:10:33 | filwit | zahary, :S, there's a couple other things in the file, let me clear and try again |
| 15:10:54 | filwit | nope |
| 15:11:09 | Araq | filwit: you need to bootstrap again |
| 15:11:17 | filwit | csources? |
| 15:11:21 | zahary | are you sure the correct nimrod is in your path? |
| 15:11:34 | filwit | yes I have it softlinked |
| 15:11:42 | filwit | to the directory I build to |
| 15:11:56 | filwit | let me relink |
| 15:12:03 | Araq | well check what 'nimrod's output is |
| 15:12:13 | filwit | command? |
| 15:12:24 | dom96 | nimrod -v |
| 15:12:25 | Araq | just 'nimrod' |
| 15:12:45 | filwit | version 0.8.15 |
| 15:12:50 | Araq | mine says: Nimrod Compiler Version 0.8.15 (2012-06-02) [Linux: amd64] |
| 15:12:54 | Araq | check the date |
| 15:13:07 | Araq | every development version is 0.8.15 ... |
| 15:13:12 | filwit | ah, mine says 2012-04-21 |
| 15:14:48 | Araq | btw the symlink works strangely at least on mac os x |
| 15:15:02 | Araq | I now advise against symlinking |
| 15:15:15 | Araq | and to edit your $PATH instead |
| 15:15:59 | filwit | I'm no Linux expert, so I'm not sure how to do that correctly. syslink has worked well before, but I'll look up the alternative later |
| 15:16:25 | Araq | edit your ~/bash.rc |
| 15:16:44 | filwit | apparently it's not the syslink, the new built version still says the same date |
| 15:17:01 | filwit | maybe I'm not pulling correctly? |
| 15:17:02 | Araq | well building from C sources is not enough |
| 15:17:17 | Araq | you need to do 'koch boot -d:release' to get a recent version |
| 15:17:30 | Araq | the C sources are only a fallback mechanism |
| 15:18:03 | Araq | https://github.com/Araq/Nimrod/wiki/Bootstrapping |
| 15:18:11 | filwit | k |
| 15:20:27 | filwit | is 'koch' a common linux command? |
| 15:20:35 | filwit | or did you mean: nimrod koch ... |
| 15:20:47 | dom96 | koch is a nimrod application |
| 15:21:00 | filwit | ah, right |
| 15:21:01 | dom96 | You compile it by running 'nimrod c koch' |
| 15:21:08 | filwit | okay |
| 15:23:33 | filwit | so after I pull I always run koch? |
| 15:24:02 | filwit | there we go, now I have the right version |
| 15:24:05 | dom96 | yep |
| 15:24:21 | filwit | so koch just builds the compiler? |
| 15:24:30 | filwit | (correctly) |
| 15:25:09 | dom96 | It compiles the compiler, and the compiles the compiler again with the newly compiled compiler to make sure that it compiled correctly. |
| 15:25:25 | dom96 | What a nice sentence heh |
| 15:25:31 | dom96 | *and then |
| 15:25:44 | filwit | duude, where's my car? |
| 15:26:13 | filwit | sorry, lol, odd reference |
| 15:26:52 | filwit | you just reminded me of that part with the drive-through guy going "and theeennnnn....?" |
| 15:27:06 | filwit | well the case/of stuff builds correctly now :) |
| 15:27:10 | dom96 | heh, I remember that scene. |
| 15:27:40 | zahary | Araq, I'm about to add support for unsigned integers. looking at what needs to be done, there are several possible paths: |
| 15:27:40 | zahary | 1) add unsigned literals and unsigned node kinds and doesn't allow any implicit signed -> unsigned conversion (thus making them uglier on purpose) |
| 15:27:40 | zahary | 2) allow implicit conversion only for literals that are positive |
| 15:27:40 | zahary | 3) allow more freely implicit conversions (like in C) |
| 15:27:40 | zahary | any preferences? |
| 15:29:23 | filwit | I would like implicit conversion between strings and unsigned ints (specifically) |
| 15:29:39 | filwit | so, 10 + "50" == 60 |
| 15:29:45 | zahary | the horror :) |
| 15:29:48 | filwit | hahaha |
| 15:32:38 | Araq | 1) |
| 15:33:29 | zahary | ok, 12'u will be the suffix |
| 15:34:36 | Araq | yeah good, we also need 'u8, 'u16 etc. |
| 15:35:05 | Araq | well I also want tyInt + typ.node to denote an integer literal |
| 15:35:19 | Araq | that is compatible with tyInt* and tyUInt if it fits |
| 15:35:42 | Araq | I mean if the encoded value fits |
| 15:37:30 | zahary | var x: uint = 10 should be ok? |
| 15:37:37 | * | JStoker quit (Excess Flood) |
| 15:46:04 | * | JStoker joined #nimrod |
| 15:47:47 | Araq | zahary: yes |
| 15:48:54 | Araq | though it may be preferable to change sigmatch finally and get rid of the distance based approach |
| 15:49:03 | Araq | and use the "partial order" approach instead |
| 15:49:13 | Araq | or perhaps keep the distance for speed reasons |
| 15:49:25 | Araq | and only use the partial order if ambiguous |
| 15:49:45 | Araq | currently for instance inheritance depth is not considered in sigmatch and that sucks |
| 15:50:28 | Araq | I'm a bit worried if every integer literal ends up allocating a new TType ... |
| 15:51:03 | Araq | but we can always optimize it with a lookup array [-10..100, PType] |
| 15:56:30 | zahary | why would that happen? (each literals would get its own PType). Right now, with destructors I'm having trouble that if a type is copied, the compiler may incorrectly decide that it doesn't have a destructor even when the user defined one (because multiple TType instances get created for a single type in the program). I don't what to revert to solution where hashmap with type ID is used to store the destructor, so instead I want to eliminate most of the copies |
| 15:59:25 | Araq | eliminating copies is a worthy goal |
| 16:00:27 | Araq | my lookup array is only for speed reasons |
| 16:06:16 | filwit | btw, why can 'case' be used without ':'? |
| 16:06:48 | filwit | is that so that variance types don't conflict? |
| 16:08:04 | Araq | because it's consistent |
| 16:08:16 | Araq | after 'case expr' no statement follows |
| 16:08:33 | Araq | 'if x:' <-- statement follows |
| 16:08:51 | Araq | but for consistency with macro syntax the colon is needed |
| 16:08:57 | Araq | so I made it optional |
| 16:09:10 | filwit | okay |
| 16:18:17 | filwit | okay, one last question before I head off |
| 16:18:38 | filwit | why isn't there a `++`, `--` operator defined for common types? |
| 16:18:55 | filwit | you just don't like those operators? |
| 16:20:03 | Araq | I couldn't care less about them, but they have the problem that i-- and --i are different and nimrod can't support that |
| 16:20:18 | Araq | in fact, nimrod only supports prefix operators |
| 16:20:43 | Araq | well |
| 16:21:04 | Araq | they are ugly because they modify and return at the same time |
| 16:21:18 | filwit | i see |
| 16:21:32 | dom96 | It isn't that hard to become accustomed to '.inc' and '.dec' |
| 16:22:21 | filwit | okay folks, I've gotta run |
| 16:22:26 | filwit | talk to you later |
| 16:22:28 | Araq | alright |
| 16:22:33 | Araq | thanks for the images |
| 16:22:36 | Araq | bye |
| 16:22:46 | filwit | np, I'll play with the colors |
| 16:23:14 | filwit | and in a few days I hope to have time to pick up on Aporia again |
| 16:23:17 | filwit | bye! |
| 16:23:19 | * | filwit quit (Quit: Leaving) |
| 17:11:35 | shevy | :) |
| 22:08:22 | dom96 | You know what filwit's logos would look good on? A t-shirt ;) |
| 22:12:54 | Araq | hm perhaps |
| 22:13:06 | Araq | yes. |
| 22:15:00 | dom96 | :D |
| 22:25:02 | dom96 | good night |
| 22:25:24 | Araq | night |