Refactor ImlValue to avoid using Rc<RefCell<ImlValue>>

[phorward]

The current implementation of ImlValue::Unresolved(Rc<RefCell<ImlValue>> introduces more problems then it solves. Especially the case, that an ImlValue is either a defined value, a variable address or an unresolved named or an instance description is very fuzzy.

After starting several approaches to make the concept more clear, I've always came to a point where there are huger conceptional changes required, which break the current concept.

This issue serves as a reminder, for some kind of good and bad ideas.

Splitting up ImlValue

This idea has already proven to be useful:

• Replace ImlValue::Unset into Option<ImlValue> (already fixed by 0c0fc44)
• Split ImlValue into
  • Defined values
    • ImlValue::SelfValue
    • ImlValue::SelfToken
    • ImlValue::VoidToken
    • ImlValue::Value
    • ImlValue::Parselet
    • ImlValue::Variable
    • ImlValue::Generic
  • Unknown values (ImlWanted)
    • ImlWanted::Name
    • ImlWanted::Instance

Now the problem is with the references. An ImlWanted must either be directly resolvable or kept in the scope, to become resolved later. This requires for two references to the same object, which was the reason for the Rc<RefCell<ImlValue>>, but this object must be able to replace itself by the resolved counterpart.

ImlRefValue-idea

One idea now could be to generally work with ImlRefValues, defined as

• enum ImlFuzzy { Known(ImlValue), Unknown(ImlWanted) }
• struct ImlRefValue(Rc<RefCell<ImLFuzzy>>)

This leads in the problem, that every current ImlValue becomes a ImlRefValue. IMHO an overhead of complexity which isn't required in most cases.

The simple Tokay expression 1 would lead in the monster of an ImlOp::Load(ImlRefValue(Rc(RefCell(ImlFuzzy::Known(ImlValue::Value(value)))))), which currently is just an ImlOp::Load(ImlValue::Value(value)).

Indexing-idea

This idea brings back the Usage-indexing from previous Tokay versions. It would required for an ImlValue::Unknown{ wanted: usize, name: String } (the name is required to check if a value is consumable, and gets the display string of the ImlWanted).

Then, a new scope level and structure ImlModule must be implemented, which holds the unresolved usages (ImlWanted) of a module as Result<ImlValue, ImlWanted>. This ImlModule reference must be covered within the entire compilation process to allow resolving ImlValue::Unknown into their specific values.

This idea would avoid the use of the Rc<RefCell<ImlValue>> and the recursive resolving, but requires for huger compiler rewrite of several parts, as the module scope must be made available (it could be a &mut in the Scope, for quick access in all situations). Introducing ImlModule would also pave the way for the upcoming modularization feature that is planned.

---

Well... this is now a dump of my current brain status regarding the ImlValue problematic. I'm not happy with both implementations, but one of them will be a solution.

This issue relates to #134, #127, #128.
Edit: #138 makes the old attempt better, but still uses the uniform ImlValue. Maybe this already suffices.