kuilpd wrote: > > single interface to traverse the AST tree: > > That's the part that would change in this setup. Instead of one API, we'd > have two: `EvaluateValueNode()` and `EvaluateScalarNode()`, and we'd have two > node hierarchies: ValueNode and ScalarNode. MemberOfNode would be a ValueNode > because it produces a value object. AddNode would be a ScalarNode because it > produces a number. ArraySubscriptNode would be a ValueNode (the result is a > value), but its `index` member would be a ScalarNode, because we need to use > it for indexing. > > The correct types would be ensured when parsing, possibly with the addition > of the "rvalue" nodes. `a[1]` would be parsed as `Subscript(Identifier(a), > Scalar(1))`, while `a[b]` would turn into `Subscript(Identifier(a), > RValue(Identifier(b)))`. `a[b+1]` would be something like > `Subscript(Identifier(a), Add(RValue(Identifier(b)), Scalar(1)))`. The > evaluator would have access to the right types, so it could invoke the right > function. This has nothing to do with the types of the variables, its about > the types (kinds) of AST nodes. > > I'm not saying you have to do this, but I find the idea of not constantly > wrapping and unwrapping scalars appealing.
I don't know about this... wouldn't this `RValue(ValueNode)` function be pretty much the same process of unwrapping Scalar from ValueObject? We will still need to wrap/unwrap Scalar from ValueObject whenever they interact, so this will only cut down the wraps when Scalar/Scalar interact, which is pretty much just arithmetics with constant literals and subscript with a constant index. I think for now it's better to implement a clean interface in ValueObject to create it from a Scalar, and we can optimize the arithmetics the way you suggested later, if this ends up being a performance bottleneck. https://github.com/llvm/llvm-project/pull/147064 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
