[Libre-soc-bugs] [Bug 835] add support for smtlib2 floating-point to yosys and nmigen

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=835

--- Comment #31 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #29)
> (In reply to Jacob Lifshay from comment #28)
> > > this was
> > > touted as a "feature" but it's a serious problem when adding the
> > > up-casting we discussed a few months back.
> > 
> > that's because ValueCastable is the wrong tool for that job [1]. 
> 
> the problem is that ValueCastable fails "isinstance(Value)" as well as base
> class chain inheritance detection. upcasting critically relies on detecting
> the highest inherited class, and casting all objects specifically to that
> type.

There's a simple solution, which you're missing because you're still trying to
cram ValueCastable into a Value-shaped hole where it doesn't fit -- a
ValueCastable *isn't* a Value and doesn't need to behave like one: just call
as_value() on all ValueCastable instances and do all the inheritance detection
and highest inherited class stuff on the objects you get:

e.g.:
def Cat(*args):
    args_l = []
    for arg in flatten(args):
        if not isinstance(arg, Value):
            # converts ValueCastable, skipped for UserValue
            arg = Value.cast(arg)
        args_l.append(arg)
    # now calculate most-derived class based on args_l
    ...
> 
> the fact that ValueCastable derivatives may be mixed with UserValue
> derivatives
> makes it impossible to establish the up-casting chain and consequently
> ValueCastable has to go.
> 
> if you can come up with an upcasting function which guarantees that an
> arbitrary
> list of objects that are of multiple inheritance types from *both* UserValue
> *and* ValueCastable across *multiple third party libraries* then it can stay.

I did, see above.

> no, throwing an exception if a mix is detected is not acceptable because the
> up-casting function must cope with arbitrary mixed third party objects.
> 
> > [1] assuming you want simd values to be nmigen Values -- i strongly
> > disagree, but we can argue about that some other time.
> 
> sorry to have to say this, but tough. i know full well that you want a total
> duplication of the entire ast.py source code: i have already explained
> multiple times that that is a maintenance nightmare, is utterly unnecessary,
> and even worse than that it implies that there exists an API difference when
> there is absolutely none at all in any way shape or form. please re-read the
> RFC if you are not familiar with the logical reasoning.

we can argue about that some other time.

-- 
You are receiving this mail because:
You are on the CC list for the bug.