<charlottia>
It gets a shape that fits its argument (which is the signal's shape if it is one), a name from context if not specified, and its reset/reset_less/attrs/decoder.
<_whitenotifier-6>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] ed5cd60 - Deploying to main from @ amaranth-lang/amaranth@99417d6499b006a172d5b8cba413fd6181737374 🚀
robtaylor has quit [Server closed connection]
robtaylor has joined #amaranth-lang
indy has quit [Server closed connection]
indy has joined #amaranth-lang
ebb has quit [Server closed connection]
ebb has joined #amaranth-lang
nyanotech has quit [Remote host closed the connection]
nyanotech has joined #amaranth-lang
Guest96 has joined #amaranth-lang
Guest96 has quit [Client Quit]
<whitequark>
regarding the weird dual role of Signature.apply(): I think I agree with the people who raised concerns now
<whitequark>
I think the best approach here is to keep only Signature.create() since really the only use case for apply() is adding attributes to an Elaboratable
<whitequark>
and for that purpose we can have the default Signature.create() make an object, the attributes of which are then transferred to that elaboratable
<whitequark>
this has an issue though, which is that in order to override the object Signature.create creates, someone would have to reimplement the member assignment code too
<whitequark>
what might make the most sense is Signature.create_members() that returns a dict, and Signature.create() which just makes an object() and updates its dict with whatever create_members() return
<whitequark>
* what might make the most sense is Signature.create_members() that returns a dict, and Signature.create() which just makes an object() and updates its dict with whatever create_members() returns
<whitequark>
I'm prototyping the RFC and so far there are 16 distinct new diagnostics its functionality can raise...
<zyp[m]>
how about def create(self): obj = object(); self.apply(obj); return obj?
<whitequark>
well the point is to avoid having that argument to apply since it has weird semantics
<whitequark>
apply on a fresh object doesn't need to check for what signature is, for attribute presence, and so on
<whitequark>
so having all those checks when it's only used, in practice, on fresh objects is kind of pointless
<zyp[m]>
ah, right
<whitequark>
it'll be used on either just object() or whatever a subclass of Signature creates or on a new Elaboratable
<whitequark>
in all of those cases, it's easier to both implement and understand to delegate the assignment to the caller
<zyp[m]>
it kinda would make more sense for apply() to be a free function then
<whitequark>
I don't think apply() should exist at all
<whitequark>
much less as a free function? why would that even be a thing?
<whitequark>
if you want to add members to an existing object, obj.__dict__.update(signature.create_members()) does it
<whitequark>
(provided name conflicts are not a consideration, which is the case for ~all of the call sites of apply I anticipate)
<whitequark>
s/members/attributes/, s//`/, s//`/
<adamgreig[m]>
I was imagining I'd be calling self.signature.apply() a lot in my Elaboratable initialisers, seems nicer than having to go through dict.update()?
<adamgreig[m]>
But I'm maybe not following how you imagine using signature.create() here
<whitequark>
adamgreig: oh so the idea is that instead of using bare Elaboratable and signature.apply (this would be the other major place where apply is called, besides apply itself) you'd use amaranth.lib.component.Component which does it for you (and also converts variable annotations in the class definition into a signature if you specify them)
<adamgreig[m]>
What use remains for non-Component Elaboratable?
<whitequark>
legacy code, for one; people who refuse to use Component because ... idk, no matter what interface i come up with, there are people who arbitrarily dislike it
<whitequark>
well, Module itself is also an Elaboratable
<whitequark>
lib.component is a library which happens to work out really well for those people,
<whitequark>
* lib.component is a library which happens to work out really well for those people
<adamgreig[m]>
and Component is just a convenient Elaboratable that applies the signature for you?
<whitequark>
yep
<galibert[m]>
Catherine: amaranth is your vision, you don't have to please everyone
<galibert[m]>
What I find interesting is that from what I understand, the aim is to have non-Component Elaboratable go away eventually. Which makes it de-facto part of the core language. So you probably start thinking of it as such. For instance, do you want the Elaborate name to, for all intents and purposes, go away? If yes, do you want the method to still be called elaborate?
<galibert[m]>
* So you should probably start
skipwich has quit [Ping timeout: 264 seconds]
<whitequark>
sure
<whitequark>
elaboration is a well known term in HDL
<galibert[m]>
for sure
skipwich has joined #amaranth-lang
<whitequark>
also, "Which makes it de-facto part of the core language." well, no? just like lib.data is expected to be used everywhere but it's not "de facto part of core language"
<galibert[m]>
To do a C simile, you can write a C program without structs, you can't write one without functions
<whitequark>
I never said that non-Component Elaboratable goes away
<galibert[m]>
Well, in your view of the language, should it?
<galibert[m]>
(in my view it should go away, but it's your view that matters)
<whitequark>
I don't see a reason why
<galibert[m]>
Ok then
<galibert[m]>
(for me signatures are equivalent to prototypes, and I wouldn't touch K&R-C with a ten foot pole anymore. But it's once again my software background showing)
<whitequark>
sure, but post-elaboration, signatures aren't going to matter anyway
<galibert[m]>
post-elaboration you're done. Well, there's a lot of work under the covers, but from the POV of making your circuit you're done
<whitequark>
(right now this isn't the case, but after a necessary internals rewrite, immediately after elaboration Amaranth is going to work on one huge flat netlist that it then hallucinates back hierarchy into_
<whitequark>
s/into_/into)/
<galibert[m]>
While the implementation is important, I tend to consider the language itself way more important
<whitequark>
that's not really an implementation detail considering that the semantics of clocks is only defined on that huge netlist
<whitequark>
(semantics of clocks for CDC analysis, I mean)