| 00:17:30 | * | q66 quit (Remote host closed the connection) |
| 01:27:28 | * | Mathnerd626 quit (Read error: Connection reset by peer) |
| 10:40:41 | * | Trix[a]r_za is now known as Trixar_za |
| 11:18:35 | * | q66 joined #nimrod |
| 12:35:46 | * | Trixar_za is now known as Trix[a]r_za |
| 12:48:21 | * | Trix[a]r_za is now known as Trixar_za |
| 15:12:36 | * | q66 quit (Remote host closed the connection) |
| 15:12:57 | * | q66 joined #nimrod |
| 16:34:29 | reactormonk | Araq, the longer you wait, the more a BTC is worth... wait. |
| 16:46:35 | Araq | reactormonk: yeah I noticed :-) |
| 16:47:12 | Araq | btw you wanted to fix that times.nim doesn't compile anymore for the JS target |
| 16:47:14 | Araq | iirc |
| 17:02:49 | reactormonk | possible |
| 17:38:55 | dom96 | hello |
| 17:39:37 | dom96 | Araq: How's that blog coming along? |
| 17:39:39 | reactormonk | dom96, mooorning |
| 17:39:40 | dom96 | :P |
| 17:39:48 | dom96 | reactormonk: 'afternoon! |
| 17:42:18 | dom96 | wow, github can now show stl files. Fancy |
| 17:43:11 | reactormonk | they had some fun |
| 18:26:57 | apotheon | I'm waiting for 1 BTC to be 1M USD. |
| 18:28:51 | reactormonk | apotheon, yup :-) |
| 18:29:01 | apotheon | . . . 'cause 1 BTC is what I have. |
| 18:29:48 | apotheon | I'm also waiting for someone to fix the bitcoin port on FreeBSD. The upstream maintainers of the software are apparently ignoramuses who think the correct way to deal with the fact that nobody on the team has a FreeBSD box handy is to close all bug reports related to FreeBSD, though. |
| 18:31:32 | reactormonk | apotheon, got almost |
| 18:31:37 | reactormonk | ... 10 of them. Let's see |
| 18:32:21 | apotheon | 2K USD |
| 18:33:03 | apotheon | It'll only take a 500000% increase in value for you to be a millionaire! |
| 18:33:58 | apotheon | Err, too many of those zero things. |
| 18:34:09 | apotheon | 50000% |
| 18:34:14 | apotheon | not 500000% |
| 19:20:00 | * | gradha joined #nimrod |
| 19:20:43 | Araq | gradha: I've been thinking for a feature for fancyos |
| 19:20:55 | Araq | couldn't come up with any though :P |
| 19:21:12 | Araq | os.nim is already complete and perfect ;-) |
| 19:22:11 | gradha | so is genieos, it's nice to write perfect software |
| 19:26:22 | Araq | what about a mechanism for "start only 1 instance of this program"? |
| 19:26:25 | Araq | ha |
| 19:26:34 | Araq | there you go, I found a missing feature |
| 19:26:53 | gradha | isn't that solved through socket opening? I would add a helper to that module |
| 19:27:25 | Araq | yeah but on windows it's more common to use an interprocess mutex |
| 19:28:20 | gradha | maybe there's also a macosx non portable way of doing that |
| 19:31:39 | gradha | there you go https://github.com/gradha/genieos/issues/1 |
| 19:34:14 | gradha | I have to make a gh-page for genieos, I wonder if there's any pink theme |
| 19:34:40 | Araq | a joke can be taken too far ... :P |
| 19:37:57 | gradha | muahaha, time to go through my directory of animated gifs |
| 19:38:10 | dom96 | get some pink unicorns in there. |
| 19:39:44 | gradha | crap, I forgot to link Jessica's baseball epic throw fail, at least I uploaded the link to her hating cucumbers |
| 19:40:21 | dom96 | gradha: You know what you should do? Write a nimrod tutorial which includes all the humour from your readmes :D |
| 19:40:41 | Araq | indeed |
| 19:40:59 | Araq | or even better a "nimrod for python programmers" tutorial |
| 19:42:18 | Araq | wow, forum action again |
| 19:42:36 | dom96 | yay |
| 19:44:42 | Araq | oh yay |
| 19:44:47 | Araq | and he crashed the compiler |
| 19:45:05 | Araq | new user, new compiler crash ... |
| 19:45:16 | * | Araq wonders when this will end ... |
| 19:45:26 | dom96 | ugh, stop getting depressed. |
| 19:45:29 | gradha | when you stop getting new users? |
| 19:45:33 | dom96 | He's using something no one uses. |
| 19:45:48 | Araq | yeah but still |
| 19:48:06 | dom96 | And you never notice when a new user doesn't crash the compiler... |
| 19:48:20 | Araq | does that happen? ;-9 |
| 19:48:47 | dom96 | i'm sure it does |
| 20:00:54 | reactormonk | Araq, have you seend the new namespace collision? ^^ |
| 20:04:57 | Araq | reactormonk: what? |
| 20:05:22 | Araq | the "I can't name the file 'test' bug?" |
| 20:05:29 | Araq | yes I saw that |
| 20:05:56 | reactormonk | xactly. |
| 20:39:47 | Araq | so ... what's left for 0.9.2? |
| 20:40:11 | Araq | - range checking bug needs to be fixed |
| 20:40:38 | dom96 | better async implementation perhaps |
| 20:40:56 | Araq | not essential for 0.9.2 I think |
| 20:41:06 | dom96 | I think it is. |
| 20:41:18 | dom96 | It shouldn't take /that/ long. |
| 20:41:33 | Araq | very well then, go ahead :P |
| 20:41:37 | dom96 | lol |
| 20:41:44 | dom96 | yeah, maybe it isn't essential :P |
| 20:41:53 | dom96 | What about caas? |
| 20:42:18 | Araq | dunno, ask zahary |
| 20:42:54 | dom96 | It would be nice to get a release of Aporia which is compatible with a release of Nimrod :P |
| 20:44:40 | dom96 | Also it would be nice if you fixed those issues with templates that jester is having |
| 20:47:08 | Araq | yeah but then I may as well change the symbol binding rules for templates |
| 20:47:16 | Araq | and that's left for 0.9.4 on purpose |
| 20:47:43 | Araq | also this template stuff is always very time consuming |
| 20:50:15 | dom96 | what about other issues on github? |
| 20:51:05 | dom96 | I think it's quite important that the mac issue is fixed. |
| 20:51:55 | Araq | I can't fix it |
| 20:52:06 | Araq | zahary, please fix it ;-) |
| 20:52:51 | dom96 | what about package management? |
| 20:53:16 | dom96 | btw I feel like our news is missing quite a lot of things :P |
| 20:53:17 | Araq | not for 0.9.2 |
| 20:53:39 | * | dom96 wonders if you will just tell him "not for 0.9.2" to anything he suggests |
| 20:53:56 | Araq | well 0.9.2 is overdue since forever |
| 20:54:42 | dom96 | ok, any other serious bugs you're aware of? |
| 20:55:09 | dom96 | perhaps we should have a small 'freeze' period to make sure there aren't any silly bugs. |
| 20:56:13 | Araq | this shouldn't be necessary |
| 20:58:48 | dom96 | hrm |
| 21:05:01 | dom96 | what about implicit returns? |
| 21:05:16 | * | gradha quit (Quit: bbl, have youtube videos to watch) |
| 21:05:31 | Araq | that's no bug |
| 21:05:42 | Araq | that's the supposed behaviour |
| 21:06:07 | Araq | no implicit ': auto' return type, sorry |
| 21:06:10 | dom96 | no, i mean. |
| 21:06:28 | dom96 | What about this functional style where you don't need to write 'return' |
| 21:06:37 | Araq | what about it? |
| 21:06:59 | Araq | it's a bit weird right now, I agree |
| 21:07:04 | dom96 | yeah |
| 21:07:13 | dom96 | How does it work currently? |
| 21:07:13 | Araq | but then this feature really conflicts with 'discardable' |
| 21:07:18 | dom96 | Is the behaviour documented? |
| 21:07:25 | Araq | hrm good point |
| 21:07:32 | dom96 | how will it work? |
| 21:07:43 | Araq | I don't know |
| 21:07:56 | Araq | proc p(): int = 12 # works today |
| 21:08:00 | Araq | proc p(): int = |
| 21:08:05 | Araq | 12 # does not |
| 21:08:28 | dom96 | yes, it sucks IMO :P |
| 21:08:43 | Araq | yeah I will allow the second one too |
| 21:09:01 | Araq | but apart from that not much else, I think |
| 21:09:09 | dom96 | I think we should talk about how it should work. |
| 21:09:17 | dom96 | Perhaps we can come up with some nice scheme. |
| 21:09:18 | Araq | well we are |
| 21:09:28 | Araq | the problem is: |
| 21:09:34 | Araq | proc p(): int = |
| 21:09:48 | dom96 | perhaps we should state what we want first :P |
| 21:09:49 | Araq | q() # should discard its return value |
| 21:09:57 | dom96 | but go ahead |
| 21:10:31 | Araq | it happens quite often that you do want to discard the value |
| 21:10:46 | Araq | well the better example is: |
| 21:10:49 | Araq | proc p(): int = |
| 21:10:53 | Araq | result = 23 |
| 21:11:14 | Araq | q() # some C stuff that returns an int as error code that you want to ignore |
| 21:11:37 | Araq | you want to return the 23 though, not q's result |
| 21:12:12 | Araq | so it's pretty confusing stuff with the 'result' design |
| 21:13:22 | dom96 | It should be an error then |
| 21:13:42 | dom96 | but then it's kinda meh |
| 21:14:01 | dom96 | I can see how this would cause confusion. |
| 21:14:09 | Araq | no it should implicitly discard q as q has been declared as such |
| 21:14:42 | Araq | yeah, perhaps I shouldn't have introduced 'result' in the first place, but now it's too late and it's quite handy anyway |
| 21:14:49 | dom96 | I'm sure other languages which employ this suffer from similar problems. |
| 21:15:00 | dom96 | IIRC rust solves this by using the semicolon |
| 21:15:06 | Araq | yeah |
| 21:15:10 | Araq | rust's solution sucks too |
| 21:15:22 | dom96 | why so? |
| 21:15:22 | Araq | so actually the current solution is not bad |
| 21:15:34 | Araq | it simply needs to allow for a few more special cases |
| 21:15:46 | Araq | because semicolons suck to begin with |
| 21:16:07 | Araq | and now it affects semantics |
| 21:17:44 | dom96 | perhaps, but it's a simple rule |
| 21:18:02 | Araq | well you can always do: |
| 21:18:15 | dom96 | It seems that the only solutions we can come up with will be very complex. |
| 21:18:25 | Araq | template `^`(x: expr): stmt {.immediate.} = return x |
| 21:18:40 | Araq | and then you have smalltalk's aweseomeness in nimrod |
| 21:18:52 | Araq | where ^q means 'return q' |
| 21:19:15 | Araq | and no, my solution is not complex at all |
| 21:19:29 | dom96 | Describe your solution then. |
| 21:19:50 | Araq | "if the body is a single statement (ignoring comment statements), its result is forwarded" |
| 21:20:59 | Araq | "to make the whole body an expression, wrap it in ()" <-- that's an optional rule we could introduce |
| 21:21:04 | Araq | the ()-rule is for |
| 21:21:09 | Araq | proc p(): int = |
| 21:21:16 | Araq | (if ...) # now an expression |
| 21:21:41 | dom96 | ugh, that's ugly. |
| 21:21:41 | Araq | as opposed to an if statement which may lack an 'else' ;-) |
| 21:21:49 | Araq | is it? |
| 21:21:50 | dom96 | That's like using {} but () |
| 21:22:07 | Araq | but it's rarely necessary |
| 21:22:13 | Araq | so it's not like using {} |
| 21:23:19 | Araq | and the ()-rule exists already I think |
| 21:23:56 | dom96 | yes, I dislike it. |
| 21:24:08 | * | XAMPP_ joined #nimrod |
| 21:24:11 | dom96 | :P |
| 21:24:13 | Araq | well come up with a better solution then |
| 21:24:24 | Araq | I think it's cool |
| 21:24:42 | Araq | but yeah, seems like the expr/stmt distinction will stay a while :P |
| 21:25:15 | Araq | but ugh |
| 21:25:26 | Araq | 'if' can be disambiguated differently |
| 21:25:35 | Araq | so hrm |
| 21:25:47 | Araq | maybe the ()-rule ain't necessary |
| 21:26:02 | dom96 | How much work is it to get rid of the expr/stmt distinction? |
| 21:26:31 | Araq | I don't know |
| 21:26:58 | Araq | well for the: |
| 21:27:03 | Araq | proc p(): int = |
| 21:27:06 | Araq | result = 1 |
| 21:27:07 | Araq | q() |
| 21:27:18 | Araq | case, it's necessary |
| 21:27:51 | Araq | but never mind, I have a solution for that too |
| 21:28:14 | dom96 | The rules list only increases... |
| 21:29:14 | Araq | not really |
| 21:29:23 | Araq | but I'm not sure my new rule is better: |
| 21:29:59 | Araq | "if the list of statements contains an assignment statement, its type shall be 'void'" |
| 21:30:18 | Araq | "otherwise it's the type of the last statement of the list" |
| 21:31:07 | Araq | that's the real problem description btw; "which expressions yield 'void'?" |
| 21:31:37 | dom96 | wait what |
| 21:32:05 | dom96 | I'm not sure I follow. Did you just describe what should happen if you have a proc with a return type of ': auto" |
| 21:32:07 | dom96 | ? |
| 21:32:15 | Araq | no |
| 21:32:21 | Araq | 'auto' has nothing to do with it |
| 21:33:21 | Araq | but under the premise there is no syntactic distinction between expr/stmt we need a rule which expressions are of type 'void' |
| 21:33:34 | * | XAMPP quit (*.net *.split) |
| 21:34:25 | Araq | and 'result = 34; q()' should have type 'void' |
| 21:34:29 | dom96 | so one expression could refer to a number of "statements" |
| 21:35:05 | Araq | well yeah, it could be a list of "statements" |
| 21:35:17 | Araq | also sometimes written as: (;;) |
| 21:35:26 | Araq | or rather (e1; e2) |
| 21:36:28 | Araq | so ... the type of (e1; e2) is the type of e2 |
| 21:36:32 | dom96 | making that expression void seems incorrect |
| 21:36:33 | Araq | but not always :P |
| 21:37:18 | Araq | making it void is not incorrect, it's how it has to be done for our sanity |
| 21:37:32 | dom96 | ok. |
| 21:37:55 | dom96 | but: 'var foo = 13; q()' is not 'void'? |
| 21:38:14 | Araq | that's void too |
| 21:38:28 | Araq | or maybe it isn't, I don't know |
| 21:38:42 | Araq | an 'if' without an 'else' is void for sure |
| 21:38:43 | dom96 | I was thinking that it's only void if you assign to the 'result' var |
| 21:38:59 | dom96 | what about: |
| 21:39:09 | dom96 | if q: blah |
| 21:39:13 | dom96 | foo() |
| 21:39:15 | Araq | but that makes 'result' rather special |
| 21:39:36 | dom96 | hrm |
| 21:39:36 | Araq | so the rule should be weaker |
| 21:39:45 | dom96 | well foo will always be called anyway |
| 21:39:59 | dom96 | so it should not be 'void' |
| 21:40:21 | Araq | (if q: blah; foo()) may have foo's return type |
| 21:40:54 | Araq | but it's getting quite too arbitrary here |
| 21:41:14 | Araq | really hard to design this right |
| 21:41:32 | dom96 | I think it's fairly straightforward. |
| 21:41:51 | Araq | alright |
| 21:41:52 | dom96 | Look at last expression in a proc. |
| 21:42:09 | dom96 | If result is not assigned to, the last expression is the type. |
| 21:42:40 | dom96 | (also in the case of 'if' and 'case' expressions, the type of each branch must be the same, otherwise compile time error) |
| 21:42:48 | Araq | (yeah of course) |
| 21:43:13 | Araq | so (if q: blah; foo()) has foo's type? |
| 21:43:20 | Araq | *foo's return type |
| 21:43:21 | dom96 | yes |
| 21:43:41 | Araq | and only assignment to 'result' is special? |
| 21:43:47 | dom96 | indeed |
| 21:44:08 | Araq | but what if: |
| 21:44:16 | Araq | proc p() = |
| 21:44:18 | Araq | q() |
| 21:44:36 | Araq | and q yields a non-void type and is implicitly discardable? |
| 21:45:01 | dom96 | 'yields'? |
| 21:45:06 | dom96 | As in, it's an iterator? |
| 21:45:12 | Araq | no |
| 21:45:15 | dom96 | ok lol |
| 21:45:19 | Araq | an expression yields a type |
| 21:45:33 | Araq | has nothing to do with iterators in this context |
| 21:46:27 | dom96 | hrm |
| 21:46:32 | Araq | well 'discardable' causes some troubles too |
| 21:46:49 | Araq | it's then a "do what I mean" type ... |
| 21:47:45 | dom96 | I'm assuming p has a return type btw? |
| 21:47:54 | Araq | no it has none |
| 21:48:03 | Araq | that's the point of the example |
| 21:48:18 | dom96 | well then it's pretty obvious no? |
| 21:48:41 | dom96 | The real problem is when p does have a return type. |
| 21:48:51 | dom96 | And the return type of p matches that of q |
| 21:49:03 | Araq | yeah that's a problem too |
| 21:50:51 | dom96 | Well, I don't see the problem with your example. |
| 21:50:58 | dom96 | Where is the ambiguity? |
| 21:51:31 | Araq | it's not ambiguous but it's another "do what i mean" special case for the compiler |
| 21:51:42 | dom96 | how so? |
| 21:51:53 | Araq | where it has to discard it because later it figures out p has no return type |
| 21:52:37 | Araq | I think the rule should be 'discardable means void unless assigned to something' |
| 21:52:55 | dom96 | I still don't understand |
| 21:53:04 | Araq | meh |
| 21:53:11 | Araq | it's not that important |
| 21:53:15 | dom96 | Is the problem that the compiler doesn't know that the return type of p is void? |
| 21:53:44 | dom96 | well at least at that point. |
| 21:53:53 | Araq | yes. |
| 21:54:18 | dom96 | Well, I thought we were just talking about rules. |
| 21:54:29 | dom96 | Don't mix implementation problems in here. |
| 21:54:34 | Araq | lol |
| 21:54:55 | Araq | yeah it's not like somebody has to implement the rules you dream up here |
| 21:56:02 | dom96 | Well up until now I've been dreaming up features and they were implemented like magic. :D |
| 21:58:02 | dom96 | anyway |
| 21:58:18 | dom96 | Start a thread on the forum maybe, or github issues. |
| 22:00:47 | Araq | that sends the wrong sign though |
| 22:00:54 | dom96 | how so? |
| 22:01:11 | dom96 | including the community in design decisions is valued by many. |
| 22:01:26 | Araq | Nimrod is not that language that's discussed |
| 22:01:49 | Araq | Nimrod is the language where simply the right thing comes out of magic |
| 22:02:50 | dom96 | Why are we discussing it then? :P |
| 22:03:03 | dom96 | Do you want to just make all decisions on your own? |
| 22:03:44 | dom96 | Most likely you will make the right decision, but more likely you will have some people complaining and might have to waste more time changing things... |
| 22:07:24 | Araq | yeah, I'm kidding |
| 22:07:42 | dom96 | good :P |
| 22:07:45 | Araq | now somebody need to write that forum post ... |
| 22:08:06 | dom96 | not it |
| 22:08:13 | dom96 | In fact |
| 22:08:22 | dom96 | What you need to do is write that blog post of yours |
| 22:10:27 | Araq | hrm ok |
| 22:24:39 | NimBot | nimrod-code/Aporia e6c07c9 Dominik Picheta [+0 ±2 -0]: Fixes #33 |
| 22:28:27 | * | q66 quit (Remote host closed the connection) |
| 22:42:10 | dom96 | good night |
| 23:15:36 | * | fowl joined #nimrod |
| 23:40:58 | * | Mathnerd626 joined #nimrod |