why have frontend and middleware? (in-person discussion)

[tideofwords]

Do we want to have separate frontend and middleware?

WHY WE DO
Our intention was: frontend is what the user sees; middleware is what the circuit sees. There are some differences:

• Frontend strings; middleware hashes
• Frontend dicts, sets, arrays; middleware Merkle roots
• Frontend syntactic sugar; middleware healthy food...
  • Frontend greater than and less than; middleware only one
  • Frontend SetContains, ArrayContains, DictContains; middleware only one Contains

WHY WE DON'T PART 1
In order to accommodate these relatively minor differences, we have duplicated an awful lot of code

• frontend::Value vs middleware::Value
• frontend::Statement vs middleware::Statement
• frontend::Operation vs middleware::Operation
• etc

Edu suggests
#145 (comment)
that the frontend have Contains statements to make compiling to middleware easier -- this is erasing one piece of syntactic sugar.

At the same time, Rob points out
#166 (comment)
that having two copies of everything makes it harder to maintain.

WHY WE DON'T PART 2
At the same time, we have several different threads working on a true "frontend to the frontend" that would be meaningfully easier to use -- our Rust "frontend" is clearly not going to be a user-facing product.

So... why do we need the Rust frontend? Do we want to work on a unified design of Rust pod, merging frontend and middleware into one?

[robknight]

Outcomes from in-person discussion: https://hackmd.io/@9keBdbG_QOG4EuX38KZ01A/SkepUY2ake

[ed255]

I'm working on a refactor that merges most of the frontend/middleware dual types.