4 ms·

Ah yeah, you can have incremental structures without an incremental pipeline or vice versa, they’ve just worked well together for me.

seanmcdirmid 9y ago
You can make your pipeline mostly oblivious to the incremental nature of each stage, which has some SE benefits. However, I like to run all my phases as damage/repair work lists after the initial incremental lex stage: token changes dirty trees associated with them, putting them in a list for releasing, which then can cause retyping of those nodes, causing those to go on a work list, though the parsing worklist is cleaned before the type checking one before the execution (for incremental live programming) one. I’ve never seen two IDE-oriented incremental compilers use the same approach actually, there is a lot of diversity here.
- evincarofautumn 9y ago
  That’s an interesting approach. Are you generally working in imperative languages? Last I recall you were using…Scala? I’m new to it, but it seems like there’s a lot of innovation quietly happening in this space. My approach is more like a declarative build system, I guess. To add TAGS support, for example, you add an output that can generate a TAGS file, and declare that it depends on a resolved AST (one with fully qualified names). Then you can make queries like “pull tags from {this set of files, the whole database, everything in this namespace, &c.}”. Dependencies are resolved, and errors reported, mostly automatically unless you want to change the default behaviours. If you want to regenerate tags after changing some input, then as an optimisation you can compute only the diff resulting from whatever dependency was changed upstream (usually a file, ultimately) at the memory cost of caching intermediates (which right now means leaving the server running).
  - seanmcdirmid 9y ago
    I haven't done anything with Scala in a long time. Tree incremental is important for large projects with < 50 ms response times. But it does require memoizing lots of information.

seanmcdirmid 9y ago

You can make your pipeline mostly oblivious to the incremental nature of each stage, which has some SE benefits. However, I like to run all my phases as damage/repair work lists after the initial incremental lex stage: token changes dirty trees associated with them, putting them in a list for releasing, which then can cause retyping of those nodes, causing those to go on a work list, though the parsing worklist is cleaned before the type checking one before the execution (for incremental live programming) one. I’ve never seen two IDE-oriented incremental compilers use the same approach actually, there is a lot of diversity here.

evincarofautumn 9y ago
That’s an interesting approach. Are you generally working in imperative languages? Last I recall you were using…Scala? I’m new to it, but it seems like there’s a lot of innovation quietly happening in this space. My approach is more like a declarative build system, I guess. To add TAGS support, for example, you add an output that can generate a TAGS file, and declare that it depends on a resolved AST (one with fully qualified names). Then you can make queries like “pull tags from {this set of files, the whole database, everything in this namespace, &c.}”. Dependencies are resolved, and errors reported, mostly automatically unless you want to change the default behaviours. If you want to regenerate tags after changing some input, then as an optimisation you can compute only the diff resulting from whatever dependency was changed upstream (usually a file, ultimately) at the memory cost of caching intermediates (which right now means leaving the server running).
- seanmcdirmid 9y ago
  I haven't done anything with Scala in a long time. Tree incremental is important for large projects with < 50 ms response times. But it does require memoizing lots of information.