[libre-riscv-dev] [Bug 64] data handling / io control / data routing API needed

[bugzilla-daemon at libre-riscv.org]

http://bugs.libre-riscv.org/show_bug.cgi?id=64

--- Comment #15 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---

> > * the Data paradigm needs to be much more in line with the
> >   nmigen "Value" object (i.e. the nmigen API, such as
> >   using __iter__ instead of members() (or perhaps ports()),
> >   having an eq (instead of "assign") function etc.
> >   also note that Record is going to have a "connect" function
> >   added (see nmigen-migen Record compat library)
> this will require every new class to actually derive from Data unless they
> want to implement the zillion functions themselves.

Two. Not zillions.  One, it has to be iterable and (eventually, at some nested
depth), start yielding Signals (or Records)

And the second, I added a ports() function due to a workaround associated with
ArrayProxy. This may be possible to remove at some point if the bug in nmigen
is fixed.

That is the full extent of the current data API.

nothing else.

So this is how tuples, generators, lists, iterators, objects that are iterable,
*anything* can be the Data API.

As long as *eventually* the iterator starts returning Signals (or Records), it
is perfectly fine.

Thus there is no *need* to restrict the API to a specific object.

Put another way: if such a Data object is created, the next recommendation is
to allow *lists* of such objects... and we come full circle right back to why
eq() exists.

And if Data object derives from Record, then because Record supports the
"zillions" of functions, and derives from Value, you might as well allow that
list to have Signals and anything else derived from Value in future.

The zillions it turns out aren't zillions, it is actually just iteration
capability, eq, shape and.. there's one more, I forget the name.

Everything else basically is intended to make assignment of one type of Value
derivative compatible transparently with another, including when slices and
arrays are involved.  Bugs notwithstanding.

So the question is, then, with iterables being capable of *being* the Data API,
do we want to cut off that capability?

Or, is it possible to make Data iterable, and for it to transparently be
capable of handling assignment to an iterable (list, tuple, generator,
sequence)?

I suspect that the latter will be quite a bit of work, whereas eq() now
basically already exists.

and works.

with over 45 use cases.

Another way to put it: can you think of a good reason to NOT make the API be "a
arbitrary nested generator that eventually yields derivatives of Value"?

Where one of those objects could be Data (as long as Data derives from Record)

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