<<01-06-2012>>
01:37:05*XAMPP joined #nimrod
03:16:08*filwit quit (Quit: Leaving)
05:12:22*XAMPP quit (Quit: There is no such thing as coincidence, only the inevitable.)
06:43:49*llm joined #nimrod
07:48:54*Araq_ joined #nimrod
07:55:58*Araq_ quit (Quit: ChatZilla 0.9.88.2 [Firefox 12.0/20120420145725])
09:52:27*Bosc0p joined #nimrod
09:54:47*Boscop quit (Ping timeout: 244 seconds)
09:59:12*Bosc0p is now known as Boscop
09:59:17*Boscop quit (Changing host)
09:59:22*Boscop joined #nimrod
11:12:08*llm quit (Quit: ChatZilla 0.9.88.2 [Firefox 12.0/20120420145725])
12:42:48*Araq_ joined #nimrod
12:43:58Araq_zahary: I'm gonna implement staticExec and staticRead
12:44:13Araq_and keep the slurp which affects .rod files for now
12:44:38Araq_opinions?
12:45:18Araq_so that means we have both 'slurp' and 'staticRead' until we can deprecate 'slurp' some day once we got the caching API in place
12:47:18zaharyis the only different the rod files handling?
12:48:13zaharysorry for the delay, but there is no need to step in - I'll get to them eventually during the weekend
12:56:48Araq_I have to go, see you later
12:56:53*Araq_ quit (Quit: ChatZilla 0.9.88.2 [Firefox 12.0/20120420145725])
13:34:59*llm joined #nimrod
13:43:09*apriori_ joined #nimrod
13:44:49*apriori_ quit (Remote host closed the connection)
16:33:00Araqzahary: rodfiles + error checking are the difference; slurp requires a constant expression
16:33:30Araqin fact, I consider 'slurp' more as another 'include', not as a built-in proc
16:33:50Araqyou can't 'include myvar' either
17:06:30*llm quit (Quit: ChatZilla 0.9.88.2 [Firefox 12.0/20120420145725])
17:12:10*Boscop quit (Ping timeout: 256 seconds)
17:19:15*Boscop joined #nimrod
18:07:10*Zerathul joined #nimrod
18:08:50*Zerathul quit (Client Quit)
18:28:20*Zerathul joined #nimrod
18:28:55*Zerathul quit (Client Quit)
18:31:50Trixar_za<--- compiling perl
18:32:10Trixar_zaBootstrapping nimrod is faster
18:32:15Trixar_za:/
19:07:30Araqnimbuild is dead ...
19:07:35Araqoh wait
19:07:50Araqwrong link i think
19:08:00Araqno...
19:11:10dom96hrm.
19:11:15dom96it is indeed
19:22:03dom96Trixar_za: Poor you :P
19:22:15dom96!lag
19:22:15NimBot6001ms between me and the server.
19:22:23dom96Araq: Fixed.
19:22:33Araqcool
19:37:38*llm joined #nimrod
19:38:53*llm quit (Client Quit)
20:24:39*Zerathul joined #nimrod
20:33:50*Zerathul quit (Read error: Connection reset by peer)
20:34:05*Zerathul joined #nimrod
20:44:02*Zerathul quit (Ping timeout: 260 seconds)
21:24:40BoscopAraq, how do you typecheck mutually recursive definitions?
21:25:53Araqvia a special final pass over the type structure
21:28:37Trixar_zaaka "M.A.G.I.C"
21:29:10AraqBoscop: no need for mutually recursive
21:29:34Araqtype T = array [0..4, T] # already cyclic and requires infinite amount of memory
21:31:45Boscopbut you could have mutually recursive records that each have a pointer to an instance of each other. how do you typecheck them?
21:32:35Araqwell you need a cycle detector in the type checker
21:32:57Araqand indeed mutually recursive records where the recursion happens through pointers are valid
21:33:38Boscopof course
21:33:42Araqit's actually quite easy, you implement a fixpoint computation and then only need to decide whether "top" or "bottom" is the start value for your algorithm
21:33:46Boscopdo you do several passes?
21:33:59Araqyeah, 3 passes
21:34:26Araqpass 1 -- parse left hand side; adds symbols and basic types to the symbol table
21:34:52Araqpass 2 -- parse right hand sides and refine the type definitions (aka the objects representing the types are mutated)
21:35:07Araqpass 3 -- check for invalid recursions and other invalid types
21:35:29Araqpass 3 is a depth first traversal for the type graph
21:35:34Araq*of
21:38:41BoscopAraq, do you have a symbol table for each scope in each AST node that has a scope?
21:40:15Araqhm
21:40:27Araqthe question doesn't make sense :P
21:40:54Araqthe symbol table is a stack of hash tables
21:41:11Araqand I push a new one if a new scope opens
21:41:18Araqand pop one if the scope closes
21:41:28Araqscopes are not attached to AST nodes
21:41:39Araqnor are symbol tables
21:41:57Araqit's done on the fly and thrown away as quickly as possible
21:43:15Araqentities like records or modules have a table of symbols that belong to them
21:44:08Araqfyi http://shootout.alioth.debian.org/u64q/which-programming-languages-are-fastest.php
21:44:20AraqAda is on par or faster than C :-)
21:44:30Araqand fortran is faster
21:45:36Araqthat of course won't debunk C's efficiency claims; obviously we need an insane amount of undefined behaviour to get speed ... XD
21:53:25Araqgood night guys
21:53:27BoscopAraq, sorry, I was away. you interpreted the question correctly so it made some sense ;)
21:53:46Trixar_zaNight Araq
21:54:26BoscopAraq, but aren't there situations where symbols in deeply nested scopes can only be resolved by looking at the type of other symbols in a deep scope?
21:54:56Boscope.g. mutually recursive static methods in different namespaces
21:55:12Boscopin different nested types even
21:55:20AraqBoscop: nimrod doesn't really allow those
21:55:26Boscopah
21:55:51Araqbut in general there is no problem:
21:56:09Araqa symbol contains its type and the type contains the list of its symbols etc.
21:56:26Araqit's just the *stack* of scopes than can really be thrown away :-/
21:56:54Araqthe type/symbol graphs can't ever be recycled really
21:57:05Boscopso for lookup you only look in the AST nodes?
21:57:29Araqno AST nodes have no symbol table attached to them ...
21:57:30Boscopand use the table only for ensuring that the types are valid
21:57:40Araqer ... no ...
21:58:15Araqin nimrod's compiler there are a) AST nodes b) symbols and c) types
21:58:33AraqAST nodes have not much to do with symbol lookup
21:58:49Araqoh and there is d) the symbol table
21:59:35Boscopso all mutual recursions are confined to the same scope?
21:59:40Araqand the parser does no symbol lookup at all, it builds the AST without any symbol tables
22:00:24Araqdepends on what you mean; recursion wrt types? or recursion wrt to symbols?
22:01:11Boscopany recursive dependencies
22:01:31Boscop*mutual
22:01:58Araqwell what's the problem with them?
22:02:49Araqif you traverse these graphs, you need cycle detection
22:02:55Boscopif they can be in different scopes and you only have the current scope stack for lookup
22:03:31Boscopthen they can't be typechecked unless you also lookup in the AST node where the type info was stored
22:03:39Boscop(for members etc.)
22:04:10Araqbut typechecking does not run arbitrarily through the graph
22:04:47Araqit depends on the language
22:05:11Araqbut in general the definitions require a fixed order of checking
22:05:24Boscopyes, that's why I asked whether in nimrod mutual dependencies are confined to the same scope
22:05:50Boscopbecause then only having the current symbol table stack would suffice
22:06:19Araqbut as a result there are mutual deps
22:06:34Araqit's just that semantic checking is mostly done by then
22:06:47Araqexample:
22:07:06Araqproc p() # forward decl
22:07:06Araqproc q() =
22:07:25Araq p()
22:07:27Araqproc p() =
22:07:27Araq q()
22:07:42Boscopyes, with forward decls it's easy
22:07:58Araqit's the same without really
22:08:32Araqok, pretend the forward decl wasn't there and nimrod wouldn't require it:
22:08:45Araqyou then do 2 passes
22:08:55Araqpass 1: add 'p' and 'q' to your symbol table
22:09:14Araqpass 2: check their bodies
22:09:33Araqdone.
22:09:49Araqthe mutual recursion doesn't hurt
22:10:04Boscopbut p's return type depends on q's return type and vice versa, you could have n functions in a circular dependency
22:10:33Araqso you also want to perform non-local type inference ...
22:10:55Boscopyeah, kind of
22:10:56Araqthat indeed makes things more complex
22:11:09Boscopand I don't want to require forward decls ;)
22:11:27AraqML requires those definitions to be in the same *section* iirccc
22:11:38Araqfun p() = ...
22:11:42BoscopML requires mutually dependent definitions to be linked with 'and'
22:11:44Araqand q() = ...
22:11:49Araqyep
22:11:51Boscopalso for types
22:12:02Boscopbut I don't want to have this restriction
22:12:37Boscoppreviously I did passes over the whole module AST as long as something got resolved. at the end all unresolved types become errors
22:12:55Araqinteresting, how did it work out?
22:15:00BoscopI wrote that code months ago and used an external visitor for that which also had a symbol table stack, I'm in the process of rewriting it using methods in the AST nodes instead of a visitor and keep a symbol table in each AST node that has a scope because they need to be accessible during the typechecking of other scopes
22:15:24BoscopI just wondered whether you knew a better way to do it
22:16:14Boscopto avoid having to rescan the whole module AST (at module level everything is guaranteed to resolve. forward decls are only required for things defined in other modules)
22:18:24BoscopI would check invalid recursive types of infinite size afterwards in a special pass
22:20:39AraqI still don't see the need to attach a symbol table to each AST node
22:21:36Araqbut it depends on your langugge desing I guess
22:21:46Araqif you need it, you need it
22:22:01Boscopconsider this situation: T1::foo and T2::bar are mutually recursive. to typecheck T2::bar it needs the type of T1::foo which wouldn't be in the symbol table stack at that point
22:22:25Araqwhy wouldn't it?
22:23:00Araqin pass 1, you add T1::foo and T2::bar to the symbol table
22:23:09Boscopbecause neither scope is a subscope of the other
22:23:23Araqdoesn't matter much?
22:23:46Araqjust add an 'owner' field to each symbol
22:23:51Boscophm
22:27:20Boscopyeah, if I add all nested symbols to the top-level symbol table
22:28:52Araqyes you then basically give up and don't use a stack
22:29:18Araqbut instead each symbol has a "nesting depth" or something
22:29:35Araqwhich you consider for symbol lookup
22:29:44Araqbut it seems quite nasty
22:29:50Boscopalso I don't have a friend keyword. things are either public or private on module level
22:30:04Araqthat's good :-)
22:30:12Boscopyeah, makes this stuff easier ;)
22:30:20Boscopbut maybe doesn't scale. I don't know yet
22:30:26Boscopfor large projects
22:31:04AraqI don't think it's a problem
22:31:17BoscopI hope so
22:31:37Araqif your code properly uses protected private public package level visibilities you have no life ...
22:31:44Araq:P
22:32:05BoscopI have no life either way ;)
22:32:27Boscopbut I also hate having to write such things, yeah
22:32:46Araqit's cargo cult programming
22:32:49Boscopin D I rarely write 'pure' or 'nothrow' even if it would fit
22:33:01Boscopthe compiler should infer it
22:33:12BoscopI hate having to write stuff that the compiler can infer
22:33:24Boscopbut public/private has to be written manually
22:33:48Araqsure you can't infer that
22:35:52Boscopbut if I have a type T with methods foo,bar,baz and a nested type T2 with methods f1,f2,f3 the symbol table ends up like [T::foo,T::bar,T::baz,T::T2::f1,T::T2::f2,T::T2::f3] at least
22:36:13Araqyes that's what I said
22:36:26Araqyou may as well forget about the stack for scoping then
22:36:55Boscopthen I have to write more complex code for lookup, because T:T2::f3 can be referred to as T::T2::f3,T2::f3 and f3 depending from where
22:37:11AraqI would do it this way anyway
22:37:47Araqcode that deals with these more complex lookup rules is easy to write
22:38:04Araqmuch harder is the type inference anyway
22:38:04Boscopwith symbol table stacks I just have to go up in the stack to find the correct reference
22:38:21Boscopyeah
22:39:14Araqbut I also would restrict the "mutual" stuff to top level symbols
22:39:28Araqso you have T2::foo
22:39:31Araqbut not T2::T3::bar
22:40:13Araqin fact
22:40:17Boscopthe problem is, with the iterative way, if I have functions f1,f2,f3 in that order and f1 calls f2 which calls f3 they take 3 passes to resolve (when f3's type is fully known): in the first pass, f3 is resolved, in the 2nd pass, f2 is resolved, in the 3rd pass, f1 is resolved
22:40:37Boscopeach requiring a full walk of the module AST (skipping resolved symbols though)
22:40:55Araqwhy?
22:40:56Boscopmaybe it becomes too slow
22:41:06Boscopwhy what?
22:41:15Araqyou only need to traverse f3's body, not the whole module
22:41:40Araqand perhaps what f3's dependencies
22:41:52Araqbut not the whole module
22:42:28Boscopso I could keep a set of unresolved symbols that I store as references to AST nodes and only visit those directly instead of finding them on my way through the module AST
22:43:06Boscopright?
22:44:22AraqI think so
22:44:30Araqhttps://github.com/Araq/Nimrod/blob/master/compiler/ast.nim
22:44:40Araqjust use this data structure
22:44:58Araq;-) it doesn't require forward definitions
22:45:20Araqcheck out how PNode, PSym and PType work together
22:45:29AraqI have to sleep now, good night
22:45:41Boscopok, thanks. good night to you too :)
23:00:16*filwit joined #nimrod
23:54:03*filwit quit (Quit: Leaving)