<attie>
whitequark: do I see it correctly that in nmigen module.submodules.name is write-only, so you can't refer to it after adding it? Is there a reason why?
<whitequark>
attie: mmm, sort of
<whitequark>
Module() is really syntactic sugar, and it doesn't stay around beyond your elaborate() function
<whitequark>
also, Module in general doesn't do setattr() and so on
<whitequark>
e.g. the clock domains are all confined to m.d.<name>, which means you can have pretty much any domain name you want (except comb)
<attie>
yeah I remember there was some discussion about namespace conflicts in module
<whitequark>
it would be pretty easy to add m.submodules.foo as a reader
<whitequark>
but that seems more verbose than assigning it with a local in elaborate()
<attie>
but I always found it a bit unintuitive that if I write "m.submodules.a = x; m.submodules.a" that gives an AttributeError
<whitequark>
I agree
<whitequark>
feel free to file an issue and/or PR
<attie>
ok
<attie>
should adding two submodules with the same name be a problem?
<attie>
do they overwrite each other?
<whitequark>
mmm, good question
<whitequark>
they do not currently overwrite each other
<whitequark>
because submodule names are advisory and only affect naming in the netlist
<whitequark>
I think either disallowing duplicate submodule names, or disallowing m.submodules.<x> when there are more than one submodule with that name is equally acceptable
<attie>
throwing an error if you assign the same submodule twice would be the most explicit I think
<whitequark>
sure
<whitequark>
i think then the internal representation needs to be refactored into something like a dict
<whitequark>
where anonymous modules are represented with numbers
<attie>
although I guess if you're adding submodules in a for loop, being able to suggest a name but not have to fiddle with disambiguation might be borderline useful...
<whitequark>
yes
<whitequark>
iirc that's the original motivation
<attie>
could keep the list, and search from the back to always return the last assigned module of that name, too
<whitequark>
that seems like it would have surprising behavior
<attie>
would it? it's analogous to "x=a;x=b;x" returning b
<whitequark>
but a is garbage collected in your example
<whitequark>
you're not *replacing* an old submodule with that name
<attie>
yes, but you're already not doing that
<attie>
I guess there's danger in making it behave more like a regular variable name in that then you might assume it behaves like that in all ways
<whitequark>
yes
<attie>
so error on duplicate assignment for least amount of footgun?
<whitequark>
sure. let's do that.
<attie>
at the minor inconvenience of not being able to suggest a name when assigning in a loop
<whitequark>
we have m.submodules[] anyway
<attie>
does that have a getter?
<whitequark>
doesn't
<attie>
whitequark: is there actually a reason to keep a single _submodules and not split into named and unnamed submodules (thereby avoiding having to assign numbers to anon modules)?
<whitequark>
Fragment uses the same representation
<whitequark>
but I think it's OK to lower it from a different one in Module
<whitequark>
certainly a list and a dict would be good enough
<_whitenotifier-3>
[nmigen] nakengelhardt opened pull request #156: add getters to m.submodules - https://git.io/fjMv1