Code structure

[lixitrixi]

Here I begin defining a possible project structure.

Basic ideas (adapted from conversations with Nik today and #23)

1. Solver-independent data types specific to Conjure are defined in src/common, such as ast
2. Conjure-independent data types, like the solver interfaces, are included outside of the project's source as they can technically be their own crates
3. We will have a "Tailor" or "TailoredSolver" type which accepts a Conjure Model and returns a Conjure Solution. We'll refine the the Solution class (e.g. it could support lazy evaluation), but the important point is that everything solver-dependent is handled through one choke point, above which everything is general Conjure stuff

[ozgurakgun]

I don't know why this rustfmt thing is failing by the way. It's definitely not your fault...

[ozgurakgun]

did you sync your fork before the last commit? I still see RefCells in there.

[lixitrixi]

did you sync your fork before the last commit? I still see RefCells in there.

I just pushed more often than I should have haha

[lixitrixi]

This should now be done I believe; anything to add @ozgurakgun ?

[ozgurakgun]

did you sync your fork before the last commit? I still see RefCells in there.

I just pushed more often than I should have haha

kein problem, committing&pushing often is a good idea!

[ozgurakgun]

turning the old ugly mainX functions into tests maybe?

[lixitrixi]

turning the old ugly mainX functions into tests maybe?

Word! Will do before this is merged.

[lixitrixi]

I've moved the integration tests Oz wrote to model- and rewrite-testing directories runnable by cargo test. As we write more permanent AST simplification methods we will be able to test those instead of using helper functions.

[lixitrixi]

@ozgurakgun The format tests still seem to be failing after merging