On 9/28/20 11:27 AM, Martin Sebor wrote:
On 9/25/20 11:41 AM, Andrew MacLeod wrote:
Since you have replied to this thread, whats your opinion whether
there should be an extra API entry point for range/value_after_stmt
or whether that should be rolled into the range_of_stmt routine, and
any ssa-name specified would be the it's range after the stmt..
perhaps renaming it to something like "range_post_stmt" and if no
ssa-name is specified, it applies to the stmt result.
I prefer API parameterization over distinct names. It makes APIs
easier for me to reason about, and when implementing them, often
lets me avoid duplicating code between. A good rule of thumb is
to ask if it might ever make sense to defer the decision to call
one or the other alternative until runtime. If the answer isn't
an unequivocal "no" then a single entry point with a parameter is
probably a better choice.
By the way, your question about API design makes me think about
something else. A range is a generalization of a singleton value
(it's a collection of singletons, which is particularly true with
the new multi-range design). Conversely, a singleton value is
a specialization of a range. It always makes sense to ask for
the range of an expression, even if it evaluates to a constant.
It only makes sense to ask for its value if it's know to evaluate
to a constant. So if it's expected to be useful to make
a distinction between the two concepts in the type system I would
think it natural to model the relationship by having value_query
derive from range_query rather than the other way around.
We've considered a single class for queries rather than the existing
derived structure, but it all depends on your point of view.
You can have values without knowing about ranges, but you can't have
ranges without knowing about values. Its persepective, so there isnt a
really a "right" answer. Either can be implemented in terms of the other.
Lots of places in the compiler deal with value callbacks, only a few
know or care about ranges, and those usually care about both ranges and
values... thus the current structure.
Regardless, its a starting point and easy to combine as a single class
later should that be worthwhile.
Andrew
