<< 26-05-2014 >>
00:14:53*askatasuna quit (Quit: WeeChat 0.4.3)
00:16:57*Kazimuth quit (Ping timeout: 245 seconds)
00:18:35*q66 quit (Quit: Leaving)
00:24:26*Kazimuth joined #nimrod
00:25:54*boydgreenfield quit (Quit: boydgreenfield)
01:12:53*saml_ joined #nimrod
01:42:32*New-Guy joined #nimrod
01:42:41New-GuyHey everyone.
01:43:02New-GuyHaving a problem/misunderstanding with tuples.
01:43:07New-Guyhttp://pastebin.com/7EVqyBLK
01:43:40New-GuyThe manual says ("blah", "blah") should be compatible with tuple[field1: string, field2: string]
01:43:48New-GuyBut it ain't workin' for me.
01:45:26New-GuyI'd appreciate some help if anyone has some time; I'll be right back myself.
01:46:56flaviu1New-Guy: addSet((symbol, value))?
01:48:37New-GuyWell I feel like a damn fool.
01:50:51New-Guyflaviul: Thanks, I appreciate it.
01:50:56*New-Guy quit (Quit: Page closed)
01:57:13OrionPKanyone know how to call a static method in C++ from nimrod
01:57:19OrionPKe.g. foo::bar()
02:11:11*superfunc quit (Ping timeout: 252 seconds)
02:27:59*boydgreenfield joined #nimrod
03:13:10*xtagon joined #nimrod
03:18:53*flaviu1 quit (Ping timeout: 264 seconds)
03:27:21*Kazimuth quit (Remote host closed the connection)
03:51:41*boydgreenfield quit (Quit: boydgreenfield)
04:13:41*saml_ quit (Quit: Leaving)
04:31:47*xtagon quit (Quit: Leaving)
04:50:08*Demos_ quit (Read error: Connection reset by peer)
05:02:58*Puffin joined #nimrod
05:05:26*BitPuffin quit (Ping timeout: 252 seconds)
05:24:59*hoverbear quit ()
05:32:26*OrionPK quit (Remote host closed the connection)
05:36:34*superfunc joined #nimrod
05:49:59*superfunc quit (Ping timeout: 252 seconds)
07:04:14*kunev joined #nimrod
07:33:40VarriountHm. Do we currently use '(..)' for any particular construct?
07:51:34*kunev_ joined #nimrod
07:54:14*kunev_ quit (Client Quit)
07:54:21*kunev_ joined #nimrod
07:54:22*kunev_ quit (Client Quit)
07:54:39*kunev_ joined #nimrod
07:54:53*kunev quit (Ping timeout: 264 seconds)
08:47:48*genivf joined #nimrod
08:57:12*Puffin is now known as BitPuffin
09:54:17*BitPuffin quit (Ping timeout: 264 seconds)
09:55:04*io2 joined #nimrod
10:07:15*freezerburnv joined #nimrod
10:20:06AraqVarriount: no we don't and some people think they look like boobs
10:21:52dom96what boobs have you been looking at?
10:22:17Araqhey it wasn't me who said that
10:22:25Araqit was ddl_smurf
10:22:43dom96sure, blame it on the guy who isn't here :P
10:22:46Araqand yes, he said something like "maybe my former girlfriends were all ... special"
10:24:46VarriountAraq: I'm documenting the lexer, and I noticed that there's special tokens for '[.' '.]' and '(.' '.)'
10:25:18Araqthe spec mentions them too, you know
10:26:03Araqmy plan was to use [. .] for generics when it's otherwise ambiguous
10:26:28Araqlike foo[.T.](a, b) vs foo[T](a, b)
10:27:20VarriountAraq: Any other compiler bugs that I could fix?
10:27:22Araqvar x: Container[T] # still [] because it's obviously a generic instantiation here
10:27:31AraqVarriount: of course, let's see
10:28:28Varriountdom96: Why are not on the VNUG, keeping me company?
10:28:39*ehaliewicz quit (Read error: Connection reset by peer)
10:28:46AraqVarriount: bug #1216 is likely simply a wrong assertion
10:28:50dom96Varriount: I literally just woke up
10:29:46Araqbug #1203 --> there is types.typeAllowed or somilar which needs the logic to dismiss 'ptr void'
10:31:06Araqcheck if bug #1162 still is open, I think we fixed it
10:32:05EXetoCdom96: yeah well get in there, stop wasting time!
10:32:35VarriountEXetoC: You're not in there either. :P
10:33:01Araqbug #1156 is no bug afaict
10:33:50Araqunknown opcode opcNGetType #1152 --> implement this opcode
10:34:32Araqbug #1149 --> should have been fixed now
10:34:43Araqso ... that should be enough for now :P
10:34:46Araqbbl
10:34:53VarriountAraq: Thanks
10:36:08*core-ix joined #nimrod
10:36:17VarriountHello core-ix
10:37:00EXetoCis #1226 too general?
10:37:22EXetoC(C keyword issue)
10:38:37VarriountEXetoC: I think the mangle procedure in the codegen just needs to be updated.
10:38:47EXetoC1ok
10:39:43EXetoCfowl: so, you wanted an EFL interface? it's not very portable, which greatly reduces its usefulness
10:41:56EXetoCthey should do something about that. otherwise they've spent all this time developing something that only a few people will consider using
10:42:34VarriountEXetoC: What's an EFL interface?
10:43:39EXetoCVarriount: Enlightenment Foundation Libraries. it has a couple of components, including a widget toolkit
10:44:00VarriountEXetoC: Ah.
10:46:55EXetoCI don't know much about it, but it seems nice. some people don't like GTK for example
10:47:18EXetoCand something written in C would be preferable, even though we have a C++ target
10:50:01EXetoCAraq: why was the C++ target issue closed? do you want me to split it up into multiple issues?
10:50:50*BitPuffin joined #nimrod
10:54:48*core-ix quit (Remote host closed the connection)
10:56:14AraqEXetoC: I simply merged your PR and that closes it
10:56:18AraqI think
10:56:43EXetoCoh
10:58:14Araqbut sure, reopen it
10:58:27Araqany idea what's still causing it to fail?
11:26:56VarriountAraq: What does 'factImplies' do? What is it for? I know it relates to 'guards', however are these compiletime guards, or runtime guards?
11:43:08*c0re-ix joined #nimrod
11:55:34*q66 joined #nimrod
11:55:34*q66 quit (Changing host)
11:55:34*q66 joined #nimrod
11:59:15*genivf quit (Quit: Leaving)
12:08:43*c0re-ix quit (Remote host closed the connection)
12:12:09*untitaker quit (Ping timeout: 252 seconds)
12:16:26EXetoCAraq: no I haven't looked into it
12:16:42EXetoCI don't have permission to modify the repository
12:18:48*untitaker joined #nimrod
12:20:06EXetoCif that's even the issue
12:31:26*rixx joined #nimrod
12:33:01*rixx left #nimrod (#nimrod)
12:54:04*noam__ joined #nimrod
12:57:17*noam_ quit (Ping timeout: 264 seconds)
13:01:49BitPuffinI wonder if nimrod deals better with differences in libc on windows and the others
13:04:38BitPuffinI guess since it's ANSI it should be alright
13:09:02*noam_ joined #nimrod
13:11:49*noam__ quit (Ping timeout: 240 seconds)
13:25:44VarriountAraq: I've found where the bug allowing casting's to ptr void is (the procedure isCastable)
13:28:52VarriountAraq: isCastable does not contain a call to typeAllowed. Should I add one, checking whether the casting type is allowed?
13:33:17VarriountAraq: The other option is to modify computedSize to return > 0 for ptr void's
13:34:23*darkf quit (Quit: Leaving)
13:44:05*q66 quit (Ping timeout: 252 seconds)
13:56:02*q66 joined #nimrod
13:56:02*q66 quit (Changing host)
13:56:02*q66 joined #nimrod
14:01:19AraqVarriount: yeah add it to isCastable please
14:19:14VarriountWho added colors to the koch output? It's quite pretty.
14:19:24VarriountEr, the koch test out.
14:19:30Varriount*output
14:32:50*boydgreenfield joined #nimrod
14:33:31*flaviu1 joined #nimrod
14:38:16flaviu1EXetoC: I'll send a pull request fixing #1226 in a few minutes. Really embarrassing bug
14:38:49Varriountflaviu1: Try and document any internal compiler structures and procedures you've touched.
14:39:23flaviu1Ok, I'll drop a few comments in too
14:45:56flaviu1Varriount: https://github.com/Araq/Nimrod/pull/1230
14:46:44Varriountflaviu1: Thanks.
14:47:33Varriountflaviu1: We might as well document the compiler as we fix and improve things. I would liken it to charting unexplored territory.
14:55:32VarriountAraq: What is opcNGetType supposed to do? Get the type of.. what?
14:55:44flaviu1what do the with and without keywords do? They don't seem to be covered in the manual.
14:56:10Varriountflaviu1: They might be unused for now.
14:59:39flaviu1Any idea what the eventual purpose would be?
15:00:45Varriountflaviu1: Maybe thread resource sychronization? context managers? specialized assignment?
15:05:49*boydgreenfield quit (Ping timeout: 240 seconds)
15:07:24*kunev_ quit (Quit: leaving)
15:11:58BitPuffinVarriount: cock*
15:12:50*Varriount slaps BitPuffin around a bit with a average-sized minnow.
15:16:01*EXetoC slaps Varriount with a confused roach
15:17:47flaviu1!seen filwit
15:17:47NimBotfilwit was last seen on Tue May 20 06:41:25 2014 quitting with message: Ping timeout: 276 seconds
15:18:47Varriountflaviu1: I've heard that filwit is/was sick.
15:18:58VarriountI hope he didn't get run over by a bus or something.
15:20:05flaviu1I hope he gets better then
15:20:53flaviu1It must be pretty serious if he's gone for so long
15:23:13*boydgreenfield joined #nimrod
15:32:27*boydgreenfield quit (Quit: boydgreenfield)
16:01:55flaviu1Varriount: I've tested dom's bug, I can't replicate it either
16:02:10Varriountflaviu1: What OS are you on?
16:02:15flaviu1linux x64
16:02:25flaviu1I've been able to reproduce it before
16:02:40Varriountflaviu1: And which bug? There are two that Araq mentioned that should already be fixed.
16:02:54flaviu1https://github.com/Araq/Nimrod/issues/1149
16:03:27Varriountflaviu1: Ok. I'm closing it.
16:03:54flaviu1I can do a PR with a test, but it may be easier for you to do it, IDK
16:04:23Varriountflaviu1: Actually, I have to leave in a bit, so it would probably be easier for you.
16:04:38Varriount(Although, trying to write a unit test on my phone would be... interesting)
16:04:39flaviu1Ok, give me a few minutes then
16:05:01dom96Varriount: dude. I can still reproduce it
16:05:04dom96Don't close it
16:05:15Varriountdom96: Have you updated your local repo?
16:05:15flaviu1dom96: Pull the very latest nimrod
16:05:24dom96I did
16:05:48Varriountdom96: Neither flaviu1 nor I can reproduce your bug.
16:06:10dom96Ok, let me pull again and see.
16:06:11flaviu1dom96: What commit hash is your head? Works for me on 97fa3391f2e7e8fefe247117bc2da9a848c4fd15
16:06:26dom96Perhaps it was fixed really recently.
16:07:05flaviu1brb
16:07:13dom96Yeah, I guess i'm not as up to date as I thought lol
16:07:41dom96Must have been related to OrionPK's bug.
16:08:31dom96Yep, works now.
16:08:32dom96My bad.
16:15:01flaviu1Varriount: https://github.com/Araq/Nimrod/pull/1231
16:15:44flaviu1Wait, no
16:16:47flaviu1dom96: It runs without error, but shouldn't it also echo "a\ns\nd\nf\n"?
16:17:10*hoverbear joined #nimrod
16:17:23dom96yeah, that's what it echos for me
16:17:25flaviu1NM, that happens at compiletime
16:17:31dom96yep
16:17:45flaviu1ok, its good then, it shouldn't have any output
16:25:07dom96flaviu1: The tester can verify compile-time output
16:26:13flaviu1dom96: Which command is that?
16:26:30dom96I'm looking that up now
16:26:39*dom96 thinks we should document that somewhere
16:28:44dom96flaviu1: I think it's "msg"
16:31:58*flaviu1 quit (Ping timeout: 240 seconds)
16:42:52*eigenlicht quit (Ping timeout: 276 seconds)
16:54:30*freezerburnv quit (Quit: freezerburnv)
16:54:42*eigenlicht joined #nimrod
16:58:21*silven quit (Remote host closed the connection)
16:59:42*bjz joined #nimrod
17:05:30*zahary joined #nimrod
17:07:01VarriountHi zahary
17:13:41*silven joined #nimrod
17:14:04*freezerburnv joined #nimrod
17:15:45*bjz quit (Ping timeout: 252 seconds)
17:16:02*flaviu1 joined #nimrod
17:16:05*bjz joined #nimrod
17:17:43flaviu1dom96: Yes, `msg`
17:20:41*bjz quit (Ping timeout: 264 seconds)
17:22:57Araqwe need another tag for bugs
17:23:04Araqbetween minor and major
17:23:53Araqany suggestions?
17:23:56flaviu1http://www.haskell.org/haskellwiki/Package_versioning_policy#Version_numbers
17:24:07flaviu1I like how they do version numbers
17:25:19flaviu1Major.BackwardsIncompatible.MinorBackwardsCompatible.patch
17:25:48Araqflaviu1: that's how we do it... in theory
17:26:16Araqin practice we don't want 0.10.x ... so
17:26:40Araqit's always 0.9.x until 1.0.0 is out
17:27:06flaviu1We're going to run out of the 9s soon
17:27:23Araqwell look at our roadmap
17:27:26dom96Araq: Let's rename minor to low, major to high and add medium
17:27:40Araqdom96: ok, sounds good
17:27:42dom96or better yet, Low Priority etc
17:29:01flaviu1Instead of having odd numbers be development builds, have the minor version increment as if a release build, and append '-dcommithash'
17:29:40Araqflaviu1: nah; also changing things now would be weird
17:30:02Araqthe odd vs even scheme works quite nicely
17:30:48AraqI dislike adding random stuff to the version number
17:31:19Araqa version number should be good enough on its own, no 0.9.4alpha-crap
17:32:36flaviu1Not all 0.9.5 builds are the same, appending the commit hash would reduce ambiguity. Doesn't matter much though
17:33:28Araqgood point but then 0.9.5 means "doesn't exist really"
17:34:09flaviu1Araq: I can't find a roadmap on google, just forum posts about it
17:34:14dom96-v should output the commit hash
17:34:17dom96bbl
17:35:10Araqflaviu1: it's a wiki page
17:36:11flaviu1Oh, its the Feature Matrix
17:36:38Araqoh yeah lol
17:37:07*BitPuffin quit (Ping timeout: 240 seconds)
17:37:16flaviu1What's planned for the with/without keywords?
17:37:38Araqreplacement for .push
17:43:31*q66_ joined #nimrod
17:43:49*q66_ quit (Changing host)
17:43:49*q66_ joined #nimrod
17:43:53*q66 quit (Disconnected by services)
17:43:55*q66_ is now known as q66
18:15:04*Matthias247 joined #nimrod
18:21:12Araqanything I should review?
18:25:56dom96ye
18:25:57dom96s
18:26:03dom96Start with the oldest PR
18:27:06flaviu1dom96: That PR hasn't been resolved yet, some people want the it to fail-fast
18:27:45dom96Yeah, so Araq should resolve it.
18:32:12dom96I'd say this PR is pretty important too.
18:36:54fowlEXetoC, i have no knowledge of EFL
18:46:17*BitPuffin joined #nimrod
18:48:14EXetoCok
18:51:38*Skrylar joined #nimrod
18:52:10Araqwell I don't know
18:52:26Araqfail fast is nice as is chaining
18:52:56AraqJSon in general is quirky though
18:53:07Araqso I guess we should prefer chaining
18:53:11dom96so we should introduce a new operator for chaining
18:53:37Skrylari think i missed what the problem was
18:53:43Araqfoo{i} is the obvious candidate
18:54:48dom96I think the "cool" and functional way to handle this is to use a Maybe type
18:55:13flaviu1How about a dot operator for chaining?
18:55:33SkrylarI'm assuming by fail-fast you mean functions sanity checking their arguments before the chain is executed
18:57:20flaviu1Ok, so in javascript `{a: "asd"}["b"] == undefined`, `{a: "asd"}["b"]["c"] == TypeError`, and `{a: "asd"}.b == undefined` `{a: "asd"}.b.c == undefined`
18:57:52flaviu1So, `[]` should quick-fail, current behavior. The dot operator versions should chain, like in javascript
18:58:00SkrylarI'm not sure a new operator is needed for that; there are already exceptions to break control if you are writing a chainable API
18:58:14flaviu1Then we also get consistency between indexing arrays.
18:59:23dom96flaviu1: I don't think you can overload the dot operator in such a way.
19:00:23SkrylarI guess I'd have to see a full description of the problem to offer much help with that *shrugs*
19:00:25flaviu1dom96: Sure you can. You know it'll return nil, but the compiler doesn't, it thinks its returning a PJsonNode
19:00:51dom96Skrylar: http://build.nimrod-lang.org/irclogs/
19:01:03flaviu1Skrylar: https://github.com/Araq/Nimrod/pull/1089
19:01:29*eigenlicht quit (Ping timeout: 264 seconds)
19:02:20Araqlet foo = a[i][j]; echo foo # still fails fast enough, I think
19:02:44Araqand avoids more operators which are slightly different
19:03:03Araqso I vote for pulling it as it is
19:04:21Skrylarwell [] is expected to either crash or throw an out of bounds, so consistency demands foo[a][b] crap out if a or b is not available
19:04:51Araqconsistency for quirky json protocol processing is a weak argument though
19:04:55VarriountWait, what are we talking about?
19:05:02flaviu1I think that the dot operator corresponds better with javascript, but I'm fine either way.
19:05:06Skrylarhaving a distinction between foo[a][b] and foo[a,b] which actually have behavioral distances might be pushing the nuance a bit
19:05:51AraqSkrylar: well I suggested {} vs []
19:05:52Skrylarif i were writing it for skylight, i would probably just make an openarray function so you'd say blahjson.path("foo", "bar") just because it reads as "hey, this is a special function"
19:06:21SkrylarAraq: adding {} notation just for JSON seems like unnecessary bloat though
19:06:43Araqthe notation already exists, Skrylar
19:06:51Araqthe compiler itself uses it even
19:06:52flaviu1Yeah, making `[]` fail fast and adding a `passthrough()` method might be best. Its the most readable
19:06:53Skrylari don't think i've seen it in the manual :\
19:07:13VarriountPlus that's like, the third use for {} that we'll have.
19:07:21*superfunc joined #nimrod
19:07:33Skrylarflaviu1: i would agree to that; if nothing else because [] is already expected by programmers to either crash or throw an error if an element doesn't exist
19:07:37Skrylarprincipal of least surprise and all that
19:07:48flaviu1I personally don't like {} being used for anything but value-value maps
19:08:06Araqthere is also `{}=`, it is completely consistent with []
19:08:09VarriountAraq: There's always '[. foo .]'
19:08:17fowlwow
19:08:19fowl{}= :))
19:08:24AraqVarriount: no *that* does not exist :P
19:08:34Araqexcept on the token level
19:08:50Skrylarflaviu1: the passthrough(a, b, c) method seems the most intuitive to me, if nothing else because its ounds like what you're trying to solve is just grabbing elements without error checking each step
19:09:29Skrylarat that point you will also want to specify a default in case the value doesn't exist, just so you can say blah.getvaluewithdefault(thedefault, "i", "am", "a", "path") or else you're back to nil checking anyway
19:10:14flaviu1I wonder how optional arguments interact with varargs
19:11:20flaviu1I vote for `chain("a", "b", "c")`
19:13:07VarriountAre you guys talking about this -> http://forum.nimrod-lang.org/t/385
19:13:22flaviu1Varriount: https://github.com/Araq/Nimrod/pull/1089
19:21:23Araqsorry but {} is simply to cool
19:21:29Araq"chain" doesn't cut it
19:21:50Araqalso we can make it create subobjects via overloading of {}=
19:22:13Araqfoo{"create", "everything", "on", "the", "path"} = value
19:22:28flaviu1I have to eat, but I'll amend the pull request in a few minutes
19:25:16*Jehan_ joined #nimrod
19:26:54fowlAraq, how about ()=? :D
19:27:03*Varriount|Mobile joined #nimrod
19:31:15Araqfowl: I don't know if we support that, I think we don't
19:31:24flaviu1I like () better too, I don't like overloading {} for anything but construction
19:34:19Araqer that's not really possible. Note that a[i] is very different from [i], and the same is for {}
19:34:33Araqa{i} is an accessor, not a constructor
19:35:07Araqit's perfectly consistent and you simply dislike it because Ruby didn't think of it :P
19:35:36flaviu1Oddly enough, I've never used Ruby
19:36:27Araqwas just an example
19:36:44Araqinsert the language you're most familiar with
19:36:52flaviu1I know, but I've heard a lot of stuff I've liked about ruby
19:37:05*eigenlicht joined #nimrod
19:38:03*Varriount|Mobile prepares for rash decision fallout
19:38:38Araq"rash"? what is that?
19:39:20*Demos joined #nimrod
19:40:56flaviu1IDK what you're asking, but the word rash can mean a decision that was reached too quickly
19:43:18Skrylarflaviu1: I donno. I can't say much, I write eccentric code too =p
19:56:57*Kazimuth joined #nimrod
19:59:34*ehaliewicz joined #nimrod
20:01:46flaviu1Araq: I'm not sure that `foo{"asd", "asd"} = value` is possible. I get errors about type mismatches, it may only be possible to do `foo{["asd", "asd"]} = value`
20:03:06Jehan_What is a{b} supposed to mean?
20:03:28*perturbation joined #nimrod
20:03:37Araqflaviu1: hmm that should work though
20:04:15AraqJehan_: it's an accessor, shorthand for `{}`(a, b)
20:04:24flaviu1`got (PJsonNode, string, string, PJsonNode)`, `expected json.{}=(node: PJsonNode, names: varargs[string], value: PJsonNode)`
20:04:44Araqah, that's a limitation of 'varargs'
20:05:48*Mat3 joined #nimrod
20:05:52Mat3good afternoon
20:05:56Araqso make it foo{["a", "b"]} for now, flaviu1
20:06:14Araqwe'll change the compiler later to support it
20:06:29Araqhi perturbation welcome
20:06:32Araqhi Mat3
20:06:44Jehan_Hmm, you learn something new every day, I guess. :)
20:07:51flaviu1Jehan_: It hasn't even been implemented yet :P
20:08:20Jehan_Okay, that explains why I didn't know about it. :)
20:08:45Mat3hi Araq
20:09:24perturbationhi Araq... just downloaded Nimrod a few days ago. I've been using it for some Problem Euler stuff so far to try and get used to it.
20:11:19Mat3hello perturbation
20:11:29AraqJehan_: the compiler itself uses it, it *has* been implemented
20:11:44Araqit's in fact quite old
20:11:48Jehan_Okay, in this case I'm just ignorant. :)
20:11:52perturbationhi Mat3
20:14:33Jehan_Hmm, looking at it in ast.nim. It looks like a separate indexing operator the way it's used there.
20:15:19flaviu1Araq: Ok, sent
20:16:15Araqyes it's an indexing operator just like '[]'
20:19:36Araqyes it doesn't match the "principle of least surprise". Which is a fancy saying for "let's copy Awk and C".
20:21:50Mat3oO
20:25:58fowldid not know this works in gcc
20:26:06fowlint x = 2; int nums[x];
20:27:00Araqfowl: that's C99
20:28:04fowlah
20:30:24Jehan_Araq: Not sure why it'd violate the principle of least surprise.
20:30:56Jehan_Incidentally, one of the computer algebra systems I'm working with also uses it as an indexing operator, so there's precedent (it's pretty old).
20:32:05Jehan_Speaking of which, I'm still curious why a language with a syntax influenced by Pascal uses '=' for assignment and '==' for equality. :)
20:32:31flaviu1Jehan_: Implementing := is trivial
20:32:42Jehan_Not that I care that much (that ship sailed a few decades ago), it's more academic curiosity.
20:32:54AraqI wasn't serious about the principle of least surprise btw
20:33:18Jehan_flaviu1: I know, but what would the point be when most Nimrod code doesn't?
20:33:41Araqpascal's := is ugly and not that logical
20:33:53Jehan_"When in Rome, do as the Romans do."
20:34:04Araqconst foo = bar # somehow := is not important here
20:34:11flaviu1Jehan_: You can do do AST manipulations to process the code into something you like
20:34:39Araqeven though you can't flip it, const bar = foo defines 'bar'
20:35:13*bjz joined #nimrod
20:35:19*xtagon joined #nimrod
20:35:20Jehan_flaviu1: I really don't like it when you have to learn a dozen different coding styles to understand code. That way lies madness, and Perl scripts.
20:36:30Jehan_Consistent style is a virtue, even if I would prefer a different style.
20:37:03Jehan_s/would prefer/prefer/
20:37:04Araqprocedure foo(x: integer = 8) // = or := here?
20:37:12Araqprocedure foo(x: integer = 8 ) // = or := here?
20:37:29flaviu1Jehan_: You can already use macros and custom parsers to write perl in nimrod, but I agree that style should be consistent.
20:37:40Jehan_Araq: I didn't mean to question your decision, I really was just curious. :)
20:37:56Jehan_flaviu1: Yeah, and I hope people won't do it. :)
20:38:35AraqI hope people will use it when appropriate :P
20:38:59Mat3Araq: true (beside ':=' is well understood because originated in Algol)
20:39:20Jehan_Araq: I'm not so optimistic about programmer self-restraint, given the problems that Scala has had with abuse of operator overloading. :)
20:39:44flaviu1LOL, SBT
20:39:51Araqwhat problems?
20:39:54flaviu1Everything but simple
20:40:00Jehan_flaviu1: Yeah, precisely. :)
20:40:23Araqand why is Scala's operator overloading worse than the extensive dynamic binding everywhere?
20:40:36Jehan_Zinc was a godsend so that I didn't have to deal with sbt. :)
20:40:57Araqbashing operators is common, but doesn't make much sense
20:41:13flaviu1Jehan_: I personally had good experiences with Gradle. I got to keep Maven :)
20:41:13Jehan_Araq: linenoise is generally less readable than well-chosen identifiers.
20:41:33*bjz quit (Ping timeout: 252 seconds)
20:41:38Jehan_flaviu1: Given the choice, I'd love to be able to dump Maven, I have to say. :)
20:41:59Jehan_And I'd kill for a Scala implementation that's not tied to the JVM ecosystem.
20:42:11AraqJehan_: no, that's a common misconception
20:42:32Jehan_Araq: Clearly, you haven't had to deal with sbt. :)
20:42:54flaviu1Araq: I was going to propose at some point requiring a text identifier for operators
20:43:14Araqa[i] = a[j] + b[k] # ok, formula is obvious
20:43:48Araqtables.set(a, i, tables.get(a, j).add(tables.get(b, k)) # ok, it's obvious where stuff comes from
20:43:59Araqbut the formula is not recognizable
20:44:15Jehan_My choice for my own language has been to support Smalltalk-style operators, i.e. identifiers followed by colons.
20:45:00flaviu1`+` `-` `*` `/` I'm fine with, as long as they keep their meaning as numeric operators and don't become something else
20:45:03Araqthere is an inherent tension between shortness and explictness
20:45:13Jehan_Araq: I didn't mean to not support operators with well-understood meaning, such as indexing, but making up completely new ones.
20:45:30Araqand both are readable for different use cases
20:45:40flaviu1Araq: https://github.com/runarorama/scala-machines/blob/master/build.sbt
20:45:52flaviu1Let me see if I can find a longer one
20:45:59Jehan_Even those I don't have a problem with in small amounts ("sola dosis facit venenum"), but apparently programmers have issues with self-restraint.
20:46:33Jehan_flaviu1: That's actually one of the more readable ones.
20:46:46flaviu1I know, but I can't find the ones that are horrible
20:47:08Jehan_flaviu1: Writing them is still a mess. :)
20:47:36Jehan_As I said, zinc > sbt. A classical case of less is more (because zinc is a part of sbt).
20:48:05Araqflaviu1: '+' is however not trivial
20:48:28flaviu1hmm?
20:48:40Araqyou want saturated arithmetic, arithmetic that wraps around, raising an exception or perhaps converting to bignums implicitly
20:49:10Araqso it's a family like +, +! +% +&
20:49:23flaviu1That would depend on the types of the operands
20:49:34Araqnot always
20:49:51AraqI keep wanting saturated arithmetic for ordinary ints
20:50:45Jehan_Hmm, I haven't seen a good application for saturation arithmetic. But maybe that's because my typical use cases are different.
20:50:51flaviu1Araq: https://github.com/non/spire/blob/3d2a41e91a1f6946fac63660f6157d4a6e4a281d/project/Build.scala
20:51:01superfuncexit
20:51:02*superfunc quit (Quit: leaving)
20:52:31flaviu1I like raising an exception. You don't really want modular arithmetic unless you're doing something low-level or writing crypto code
20:52:59flaviu1And then if I want saturated arithmatic, I'll convert my ints to SaturatedInt and do it that way
20:54:52flaviu1Couldn't lambda lifting be put into its own pass, and then rerun enough times for everything to be lifted?
20:59:32Araqit is its own pass
21:00:10Araqrunning it in a fixpoint computation simply makes it far worse to debug though
21:01:33AraqJehan_: IMHO saturated arithmetic is what the hardware should do per default ;-)
21:02:42Jehan_Araq: Not seeing why?
21:03:15Araqalloc(N * sizeof(foo) + M) # fail for too big request
21:03:19*perturbation quit (Quit: Leaving)
21:03:35Jehan_Overflow etc. is generally an error state. That high level languages don't expose the CPU flags is a different story.
21:04:05Jehan_Araq: Hmm, I'd say that the overflow should trigger an error there.
21:04:06flaviu1Ideally, processors should do modular arithmetic and store overflow somewhere. Backwards compatibility and maximum flexibility.
21:04:49Jehan_Saturation arithmetic may create different problems there.
21:04:58Araqflaviu1: processors do that already but turning the flag into an exception is not free
21:05:16Jehan_For example, if you use an int type that's not the full wordsize, then allocs quietly get capped at a much too low value.
21:06:20AraqJehan_: how is that worse than wrap around "too early"?
21:06:51Jehan_The alternative is not "wrap around" but "make it an error".
21:07:21Araqwell you can easily raise an exception for high(int)
21:07:41Araq"make it an error" is always possible
21:08:08Jehan_Requires you to expressly consider that case and may not do what is expected if you mix up different int sizes.
21:08:28Jehan_Araq: I mean, make _every_ integer arithmetic overflow an error by default.
21:08:29flaviu1Araq: Why would it be expensive? Just branch on a register's contents
21:08:41Jehan_It's almost always not going to be what you intended.
21:09:49AraqI'm arguing that saturation is far better than wrapping around
21:10:00Araqyou're arguing for something else :P
21:10:13*wan joined #nimrod
21:10:16flaviu1I'm arguing that wrapping around is the most flexible possible solution
21:10:26Jehan_You said that hardware should do saturation by default?
21:11:00Araqyes but I didn't mean it shouldn't provide overflow flags
21:11:31flaviu1Wrapping around allows the code to most easily implement saturation, modular, and exceptions on wraparound
21:11:46Araqhow so?
21:12:10Araqthat's enabled by the overflow flags
21:12:52Jehan_Araq: One problem with saturation arithmetic is that it would make big integer operations more difficult to implement.
21:13:14Jehan_Speaking of which, I still need to wrap up the gmp module ...
21:13:16flaviu1for signed operations, do the operation as usual, and branch on OF into storing MaxValue instead. Modular arithmetic is already implemented, and throwing an exception on overflow is just a branch on OF again
21:13:19AraqJehan_: only if you don't *have* wrap around ops
21:13:42Araqyes they are useful. no they shouldn't be the default
21:14:04Jehan_Okay, so you want different arithmethic operations supported by the CPU?
21:14:42Araqand exposed by languages like C which lack exceptions
21:15:46*boydgreenfield joined #nimrod
21:15:54Jehan_I still consider C to be a portable assembly language. :)
21:15:57AraqJehan_: the classic example for saturated arithmetic is pixel ops. "make it darker until it gets brighter again" is not useful
21:16:07Jehan_(With C++ being the matching macro assembler. :) )
21:16:59Jehan_Araq: Saturation arithmetic isn't terribly difficult to implement in assembly if you really need it?
21:17:55Mat3it is not
21:18:26Mat3(only for floating-point values maybe)
21:18:43flaviu1My whole idea is that modular arithmetic with flag registers is the most flexible format. You can convert it to any other type of arithmetic with very minimal hassle
21:19:33Mat3hmm, as written it depend on the value type
21:19:59flaviu1You can implement saturation arithmetic on top of modular arithmetic with all of two instructions and a probable branch mispredict
21:20:13Araqjo overflow; overflow: call overflowHandler; for every single arithmetic operation is not cheap
21:20:54flaviu1branches are cheap if they are predicted correctly
21:21:12Araqyes, but code size still is an issue
21:21:26Araqwell sometimes it is
21:21:28flaviu1Your code size will increase by two instructions per add
21:21:41Araqthat's 6-8 bytes
21:21:56Araqthe call likely takes an expensive large immediate value
21:22:46Mat3if a satured value is hold in one of the 16 possible registers, saturation can be done though a conditional cmov instruction
21:23:36Mat3(no branch mispediction, but a possible extra cycle)
21:23:52AraqMat3: yes saturation doesn't take a 'call'
21:24:12Araqthinking about it, the CPU should have a special exception handler register
21:24:14flaviu1Araq: I think you're overoptimizng if you're worrying about cache lines
21:24:15*io2 quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist)
21:24:48flaviu1The only real way to mess up the instruction cache is with insane levels of OOP
21:24:58*Kazimuth quit (Ping timeout: 276 seconds)
21:25:59Mat3I know another example: static superinstructions (bytecode interpreters)
21:26:33Mat3or static instruction replication (another interpreter related optimization)
21:26:40Demosflaviu1: and self-modifying code :D
21:27:03*boydgreenfield quit (Quit: boydgreenfield)
21:27:32Mat3or trampolines, or branch tables
21:28:04flaviu1Mat3: How big are your branch tables?
21:28:43Mat316*16 instructions * 2
21:28:51Mat3(quads)
21:29:42Mat3= 4 KiB
21:29:52flaviu1Wow, big
21:31:31Mat3the main problem is not the size here but 30-50% BTB mispredictions (which cost a lot of cycles) for interpreters
21:33:21Mat3the same problem exist for all kind of code which relate on multible, conditional dispatching
21:33:55Araqlike checking for overflow on every single arithemtic op, Mat3 ? ;-)
21:34:18Mat3probably,yes
21:35:46Mat3the common algorithm is simple prediction though assuming that the next branch equals the last occured one
21:36:27*Varriount|Mobile quit (Ping timeout: 252 seconds)
21:36:59Jehan_I think most people worry about performance too much.
21:37:17Mat3so if a call to a saturation-handling subroutine occurs often this is not the problem
21:37:45flaviu1Mat3: I'd assume that saturation handling would be inline
21:38:03flaviu1so you don't get any procedure calling
21:39:09Mat3this is not always possible for a conventional compiler because processing values can not always be known at compile time
21:40:57Mat3and saturation is a conditional operation which *depend* on specific values
21:41:46Mat3however, for an interpreter that is not the problem because the whole runtime state is always be known
21:42:59flaviu1Mat3: I might be missing something, but have a macro replace `+` with the asmebler equvilent of `a+b; if(CF ne 0) result |= 0x7FFF`
21:46:45Mat3that's exactly what I'm written before; You must process the stauration at compile time which means, you must process all arithmetic and logic operations which are related to the value state at invocation
21:49:25Mat3^stauration=conditional saturation
21:50:57*Mat3 is now known as Mat3-coding
22:02:26*Mat3-coding quit (Quit: Verlassend)
22:04:47flaviu1It doesn't look like I can get a parse tree from a PEG
22:17:45dom96The compiler code should really use $ instead of *toString
22:18:57fowlhi dom
22:19:01dom96I guess this style is a remnant from Pascal.
22:19:06dom96hi fowl
22:52:33NimBotAraq/Nimrod implements_78 8eee1bf Dominik Picheta [+3 ±2 -0]: Implements #78.
23:04:49dom96This is odd: https://github.com/Araq/Nimrod/issues/140
23:05:03dom96There is a commit which fixes this issue
23:05:09dom96and it seems to have been made in the devel branch
23:05:13dom96and yet somehow it's not?
23:07:31*Matthias247 quit (Read error: Connection reset by peer)
23:07:37*Jehan_ quit (Quit: Leaving)
23:13:15flaviu1dom96: Yeah, I saw that a while back too. Rebasing may have occurred or something
23:14:10flaviu1Araq: What did you use as reference for the PEGs module?
23:14:49flaviu1dom96: It only took you three years to fix that :P
23:14:54dom96:D
23:15:20Araqflaviu1: read the paper from the Lua guys
23:15:43AraqI developed it entirely on my own though after reading it
23:16:16Araqin case you didn't notice, parsers are finger exercises for me ;-)
23:17:42*darkf joined #nimrod
23:25:42Araqgood night
23:25:48flaviu1night
23:27:43BitPuffinAraq: is this module obsolete? https://github.com/Araq/Nimrod/blob/devel/compiler/wordrecg.nim
23:27:53BitPuffinit says it's to work around a limitation in pascal
23:28:05BitPuffinand the compiler isn't written in pascal anymore
23:29:37*hoverbear quit ()
23:38:21flaviu1BitPuffin: Yes, `s/wordrecg,?//g` fails to compile
23:38:35flaviu1Err, no it isn't
23:39:03flaviu1I accidentally wrote yes when I should have written no
23:40:44BitPuffinlol
23:44:49*aboutGod joined #nimrod
23:46:41dom96hello aboutGod!
23:48:07flaviu1aboutGod: dom96 made pun of your name after you left :P
23:52:42dom96ssshhh
23:53:37BitPuffinssh
23:53:43BitPuffinsecure shell
23:54:55*aboutGod left #nimrod (#nimrod)
23:56:45dom96flaviu1: see what you did :(