<div dir="ltr">I did some reading and realized that the question is  a bit too wide. I've got now Simon Marlow's book on parallel/concurrent haskell and going through it.<div><br></div><div>Files depend on each other because one defines something that the other uses. There's more in SystemVerilog, but assume #define and #ifdef pairs.</div><div>So the dependency is only implicit: you know it only after you've parsed both files.</div><div>Nevertheless, a well organized system will #include files with definitions (and do the same for other SystemVerilog things that cause dependencies) so I'm ok with optimistically assume no dependency and compute a list of "problems" that cause recompilation.</div><div>So if:</div><div>file A:</div><div>...</div><div>#define foo</div><div>...</div><div>file B:</div><div>...</div><div>#ifdef foo</div><div>...</div><div>#endif</div><div>...</div><div>and the command line has the order fileA, fileB we compile both files in parallel, but the result of compiling A will be (ast, [foo], []) and the result of compiling B will be (ast/Error, [], [foo]) since foo is in the use list of B and in the def list of A we know we have to recompile B (and compiling B doesn't pass a def list to a possible C until we're satisfied with it). So when there're dependencies, I'm ok with recompiling multiple times.</div><div><br></div><div>As for the second question, splitting a toplevel across files is even more perverse and should be extremely rare (I think is there only for historical reasons: the first Verilog simulators assumed the entire design available and basically did a 'cat f1..fN' before compiling. Again, I'm happy with redo work in this case. If compilation units are [ [a,b,c], [d,e] ] and you have a parse error in c after having consumed the entire file and d has also a parse error, we restart with a new specification [ [a,b,(c,d)] [e]] where (c,d) means concatenation of the content of file c and d. Parse for a and b are still valid. Parse for e might be valid. But even if we invalidate and redo everything in exchange for simple code, I'm ok with it.</div><div><br></div><div>My question can be abstracted a bit more in terms of list processing.</div><div>We have a list of lists [[a]]. We need to process each leaf element by mapping a function p a e which process an element of type 'a' in an environment 'e' which comes form the evaluation of previous elements. Up to here, would be normal monadic code to hide 'e'. In addition since in our domain, we assume 'e' `intersect` 'u' is often empty (where 'u' are the uses that we discover while processing an element) we'd like to start the processing of all elements in parallel and redo the ones that turned out to be invalidated by previous ones. I'd like to find a solution to this that is in good Haskell style.</div><div><br></div><div>We can forget the toplevel split across files for now, that's can be dealt in a outer layer that restarts everything throwing away all the work.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 28, 2015 at 7:13 AM, Konstantine Rybnikov <span dir="ltr"><<a href="mailto:k-bx@k-bx.com" target="_blank">k-bx@k-bx.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Maurizio,<br><br></div>It's not completely clear how your compiler knows which files depend on which. Does it read files one by one and "updates" dependency list? What about situation when toplevel construct is split in two files, how does this single-file API handle it?<br></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Fri, Mar 27, 2015 at 3:38 PM, Maurizio Vitale <span dir="ltr"><<a href="mailto:mrz.vtl@gmail.com" target="_blank">mrz.vtl@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">G'day,<div>  I'm trying to decide how to architect the frontend of a compiler I'm using as an excuse for learning Haskell.</div><div><br><div>  Suppose we have a language (SystemVerilog) that has the notion of multi-file compilation units.</div><div>This means that specific subset of files form separate scopes for certain things.</div><div>For instance if we represent with lists of lists compilation units:</div><div>[[a,b,c], [d], [e,f]]</div><div>a macro definition in file b, would affect the rest of the file and file c, but wouldn't have effect on files d,e or a.</div><div><br></div><div>Furthermore, if a toplevel construct is split between two files, say c and d, the compiler should treat the original compilation unit specification as if it was:</div><div>[[a,b,(c,d)][e,f]], where (c,d) means we're compiling the logical concatenation of c and d.</div><div>If (c,d) is also incomplete, (c,d,e) should be tried and so on.</div><div><br></div><div>Now in well designed systems, all files can actually be compiled in parallel and so I'd like to optimize for that case and recompile files (either because we need side effects from files before them or because they're incomplete. So I'm not to concerned if wasted work is done for the degenerate cases.</div></div><div><br></div><div>Any suggestion on how to go about this?</div><div>Le's assume that parsing a file is done with a function:</div><div>p :: file -> Either Error (ast, [defs], [use]) where the [defs] are things that might affects files down the line and [use] are things that, if defined by some prior file, cause recompilation.<br></div><div><br></div><div>I'm interested in both a sequential and parallel solution and it would be sweet if they where similar, with the proper abstractions.</div><div><br></div><div>Thanks a lot for any insight/ideas,</div><div><br></div><div>  Maurizio</div></div>
<br></div></div>_______________________________________________<br>
Beginners mailing list<br>
<a href="mailto:Beginners@haskell.org" target="_blank">Beginners@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________<br>
Beginners mailing list<br>
<a href="mailto:Beginners@haskell.org">Beginners@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners</a><br>
<br></blockquote></div><br></div>