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 0c0fc4417166764c49d491a94c6974f20cfb9483)
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
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.
The current implementation of
ImlValue::Unresolved(Rc<RefCell<ImlValue>>introduces more problems then it solves. Especially the case, that anImlValueis 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:
Option<ImlValue>(already fixed by 0c0fc4417166764c49d491a94c6974f20cfb9483)ImlValueintoImlWanted)Now the problem is with the references. An
ImlWantedmust 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 theRc<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 asenum ImlFuzzy { Known(ImlValue), Unknown(ImlWanted) }struct ImlRefValue(Rc<RefCell<ImLFuzzy>>)This leads in the problem, that every current
ImlValuebecomes aImlRefValue. IMHO an overhead of complexity which isn't required in most cases.The simple Tokay expression
1would lead in the monster of anImlOp::Load(ImlRefValue(Rc(RefCell(ImlFuzzy::Known(ImlValue::Value(value)))))), which currently is just anImlOp::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 }(thenameis required to check if a value is consumable, and gets the display string of theImlWanted).Then, a new scope level and structure
ImlModulemust be implemented, which holds the unresolved usages (ImlWanted) of a module asResult<ImlValue, ImlWanted>. This ImlModule reference must be covered within the entire compilation process to allow resolvingImlValue::Unknowninto 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&mutin the Scope, for quick access in all situations). IntroducingImlModulewould 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
ImlValueproblematic. 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.