Bugfix/parse once

[leissa]

Fixes:

• Externals in Dialects #99
• Import of files #116
  For now, the XXX within .import XXX must be a single name in your search paths
• optimization exhibits non-deterministic behavior #143
  There were multiple reads of some files that sometimes caused funny behavior.
• Automatic Dialect Loading #171
  You can now load a plugin using .plugin XXX; in your .thorin file.

Changes

• All the bits and pieces which have been passed around manually to make the plugin architecture work are now streamlined and centrally manged in Driver.
• File names & paths now use fs::path - including Loc.
• The c++ sources now use the term plugin instead of dialect
• more migration from const Def* -> Ref
• a little bit more of Infer magic
• Wrapper assert_emplace(container, val) to assert that an insertion actually took place
• Wrapper lookup(map, key) that returns a pointer to value if found or nullptr otherwise.

Remarks

Although we can define now all kind things in our imports, I'm reluctant to actually use this feature because right now everything lives in a global namespace. We probably want to have sth smarter.

[NeuralCoder3]

For clarification:

plugin
=> make passes normalizers ... available
import
=> makes axioms, local definitions, ... in thorin available

Is this correct?

And the relation would be:
plugin -> import
but not import -> plugin
.

In other words:
import remains as it is and
plugin = import + -d name.

[NeuralCoder3]

Although we can define now all kind things in our imports, I'm reluctant to actually use this feature because right now everything lives in a global namespace. We probably want to have sth smarter.

Prefixes like %name.name are reserved for axioms (we can not prefix other declarations/definitions), right?

[NeuralCoder3]

Is it currently just not necessary that dialects load other dialects using plugin or should this be avoided in general?

[leissa]

For clarification:

plugin => make passes normalizers ... available import => makes axioms, local definitions, ... in thorin available

Is this correct?

And the relation would be: plugin -> import but not import -> plugin .

In other words: import remains as it is and plugin = import + -d name.

For clarification:

plugin => make passes normalizers ... available import => makes axioms, local definitions, ... in thorin available

Is this correct?

And the relation would be: plugin -> import but not import -> plugin .

In other words: import remains as it is and plugin = import + -d name.

correct.

[leissa]

Although we can define now all kind things in our imports, I'm reluctant to actually use this feature because right now everything lives in a global namespace. We probably want to have sth smarter.

Prefixes like %name.name are reserved for axioms (we can not prefix other declarations/definitions), right?

correct. I'd like to change this but this is sth for another PR.

[leissa]

Is it currently just not necessary that dialects load other dialects using plugin or should this be avoided in general?

So right now, you can load a plugin via CLI or via .plugin XXX. In a perfect world, I would remove the -d (or -p) switch entirely but there is this thing that e.g. the clos plugin has some bugs and will break some test cases if loaded. For this reason, our standard opt plugin cannot just blindly load the clos plugin. But yes, using .plugin XXX is the preferred way. When I later on touch all test cases because we want to rename -d -> -p I will use .plugin XXX instead, if possible.

[leissa]

One more remark: In bootstrap mode .plugin has the same effect as .import. I also thought to make bootstrapping more explicit in the CLI. So our bootstrap command would look like this:

thorin --bootstrap mem.thorin --output-h mem.h --output-md mem.md

But this is again sth for another day.