Re: [myhdl-list] MEP 107 - update assessment

[Christopher F. <chr...@gm...>]

On 6/15/2012 5:26 AM, Jan Decaluwe wrote:
> MEP 107 has been rewritten with support for attribute
> lookup only - ok.
>
> Comments:
>
> 1) the proposal is to support attribute lookup with an
> arbitrary depth. Until now I had only considered a
> single level of lookup.
>
> I think support for arbitrary depth may complicate
> things significantly, and I am not sure that there is
> good use case that warrants the effort.


My thought is, if depth greater than 1 requires too
much effort in the near-term we can add an implementation
amendment listing the limitations to the MEP.  But I
think to cover the general case we should investigate
depth greater than 1.

I have prototyped, generically, decoding arbitrary lookup
depths and it seems plausible.  At least in the generic
sense (not the actual conversion code).  I will try and
add this to the MEP.

>
> 2) I miss lists of signals. I believe people will want
> to use the container as a namespace for all signal-like
> objects that are currently supported, including lists.
> I expect this would not add too much additional
> difficulties to implement.

Good suggestion, it is worthwhile repeating in the MEP that
all convertible types are intended to be supported in
the attribute Signal containers (lookup) and what that
might look like.

>
> 3) I don't think the difference between class attributes
> and instances attributes is subtle. I also think that
> the overwhelming usage of the lookup feature will be
> for instance attributes. In short: I would remove the
> explication of the difference; I think it will only
> confuse people without adding value.
>
> We could restrict the examples to instance variables,
> but add a note in the end that attribute lookup is
> general (as I think it can be without too much problems).
> This would include class attributes, but also lookup
> in modules or in NamedTuples.

Sounds fine, will make the changes.

NamedTuples?  Would this cause confusion?  A NamedTuple
access via attributes would convert via the lookup but
what happens if the NamedTuple is indexed?  Would indexing
of a NamedTuple be supported?  Also, wouldn't a NamedTuple
be identified by the converter as a MemObj?

>
> 4) Currently, MyHDL supports only local variables (this
> may change with Python 3.0 in the future) that do not
> take part in hierarchy extraction. Therefore, the way
> they are named in conversion should also be different
> and local.
>
> That having said, I have not thought about lookup
> support for variables and it may prove to be very
> different from signals.
>
> I think the most "urgent" need is for signals,
> to emulate interfaces. We could consider to
> keep variable support for a future MEP, after we see
> how the signal lookup support turns out.

Sure, limiting to only Signals simplifies and as you
state covers majority of the intended use.  Sounds
good to me, I will remove the references to variables.

Regards,
Chris