<cr1901>
I vote for making what's described (using "m" in callee and caller) a hard error; seems too difficult to use. But curious if an RFC comes out
Guest54 has joined #amaranth-lang
Guest54 has quit [Client Quit]
<agg>
does that preclude any use of m except in a single big elaborate function? i've somewhat often either bound m to self and called methods on self that use it, or passed it to helper functions, to help abstract/tidy/reuse stuff in elaborate
<cr1901>
I've not used "m" outside of elaborate yet, personally. My modules are small enough to not justify reuse
<agg>
as far as 'm' is concerned it's just being used normally though, I think it would have to do stack frame inspection to even work out what was happening, so I think it's probably materially different to the uses in that issue? maybe?
<whitequark>
agg: yes, it would do stack frame inspection
<whitequark>
in general, mutating your elaboratable from within `elaborate` is something that goes against the concept of elaboratables, which are supposed to be factories of actual RTL (parameterized by the platform)
<agg>
in my particular case the only mutation of the elaboratable is because it's convenient to bind m to self at the start of elabrate and return it at the end, instead of passing it to a bunch of static methods
<agg>
i appreciate it ends up with a bunch of essentially unchecked invariants though, e.g. my methods all require to be called inside "with m.FSM" so it would be easy enough to misuse, though I think that would immediately error out when they call m.State() outside of an FSM
<cr1901>
>instead of passing it to a bunch of static methods
<whitequark>
passing `m` to helper functions should be fine though; I didn't explain it in the issue but the current plan for this involves requiring the annotation of helper functions with a special decorator; you define `@allow_using_Module_as_argument def helper(m, ...)` and inside of `helper` if you write `m.d.sync` then it adds the assignment to the root of the module, without considering any conditionals you may have in the caller
<agg>
would it work for calling m.State inside an FSM?
<cr1901>
My interpretation was that passing it to a bunch of static methods is _also_ unsupported
<whitequark>
agg: no
<agg>
I guess that's spiritually a conditional anyway huh
<whitequark>
yeah
<whitequark>
doing what you're doing in daqnet probably needs to be addressed as a part of FSM rework
<whitequark>
another RFC
<agg>
there are probably other ways to structure such an application, but this sure ended up convenient to use