<whitequark[cis]>
let's take a roll call first. who's attending today?
* cr1901
raises hand
zyp[m] has joined #amaranth-lang
<zyp[m]>
o/
Chips4MakersakaS has joined #amaranth-lang
<Chips4MakersakaS>
o/
jfng[m] has joined #amaranth-lang
<jfng[m]>
o/
<Chips4MakersakaS>
Catherine: you linked to RFC #28, not RFC #27.
<zyp[m]>
#28 is correct
<whitequark[cis]>
s/27/28/
<whitequark[cis]>
yeah, sorry; typo
<Chips4MakersakaS>
+!
<Chips4MakersakaS>
+1
<whitequark[cis]>
sorry, what do you mean by that?
<Chips4MakersakaS>
Just acknowledged that I saw the correction...
<whitequark[cis]>
does anyone attending have any comments on the RFC text?
<cr1901>
I like everything about this RFC as-is and don't think it makes sense to make Value an ancestor of ValueCastable as an alternative. Not too keen on adding an req() method in the future, but this is a visceral reaction.
<whitequark[cis]>
Value would not ever be an ancestor of ValueCastable
<whitequark[cis]>
a common ancestor is not entirely off the table but unlikely
<cr1901>
Well that's what the alternatives say. s/ancestor/common ancestor/ if you want
<cr1901>
Alternative seems like a lot of work for little gain just to make it play nice w/ Python's default behavior
<whitequark[cis]>
these are two very different options
<whitequark[cis]>
having Value an ancestor of ValueCastable would completely break the point of ValueCastable
<whitequark[cis]>
having a common ancestor (empty class that does nothing) merely goes against our policy for interface classes
<Chips4MakersakaS>
LGTM
<whitequark[cis]>
jfng?
<jfng[m]>
what operations are covered by this RFC ? does it include all binary operations with reflected operands ?
<zyp[m]>
yes
<cr1901>
>Extra logic required around every Value operator. <-- Not that I am particularly worried, but will checking for the existence of reflected ops matter perf-wise for large amaranth designs?
<whitequark[cis]>
probably not; you don't spend that much time calling arithmetic ops
<whitequark[cis]>
it's mostly some of the quadratic algorithms in the backend slowing us down
<whitequark[cis]>
any more questions or comments?
<jfng[m]>
is this also relevant for comparisons (e.g. `__lt__`) ?
<zyp[m]>
yes
<cr1901>
Presumably this is the end of the meeting?
<whitequark[cis]>
we should still vote
<whitequark[cis]>
if there are no further comments, please respond with your proposed disposition: close or merge
<galibert[m]>
What happens if you binout between two ValueCastable?
<galibert[m]>
s/binout/binop/
<galibert[m]>
(sorry, didn't think about the impact of the dst change yesterday, was out shopping)
<zyp[m]>
this RFC only applies to Value
<whitequark[cis]>
I think that depends on whether they have the same ancestor or not, right? zyp
<zyp[m]>
I mean, the added checks in this RFC happens in Value
<galibert[m]>
So you can't use it for the typing checks between two enums?
<galibert[m]>
you can't add two fixed point, etc?
<zyp[m]>
you can, but you don't need this RFC to do so
<zyp[m]>
this is particularly about Value and ValueCastable interop
<galibert[m]>
Ah, to pick up the missing left-association?
<cr1901>
merge
<zyp[m]>
interop between different value-castables would be handled by the operators checking if they understand the other type and returning NotImplemented if not
<galibert[m]>
Ok, I don't see the complete picture, but whatever
<galibert[m]>
Or does that mean there is no binop possible between two ValueCastable or even a ValueCastable and a Value in the first place? as_value() is used only on .eq of Signal and friends?
<zyp[m]>
binops with Value and ValueCastable does .as_value() by default
<zyp[m]>
and IIRC ValueCastable has no operators by default
<whitequark[cis]>
yes
<galibert[m]>
Ok, so imagine you want to implement a one-hot enum which refuses that you add to it. It can intercept Value and ValueCastable on the right through operator overloading, and Value to the left with the new rfc. But not ValueCastable to the left, right?
<zyp[m]>
that would depend on how the operator is implemented in the other ValueCastable, yes
<zyp[m]>
if it's not implemented or returns NotImplemented for that particular other, python would defer to the reflected op
<galibert[m]>
Ahm, so you need to hope it delegates and does not call as_value() itself then
<galibert[m]>
s/Ahm/Ah/, s/as_value/as\_value/
<zyp[m]>
correct
<galibert[m]>
Something to put in the docs somewhere, good manners for interop
<zyp[m]>
as I see it, there's no general solution to your problem, because you don't know which of the two value castables should have the higher priority
<zyp[m]>
unlike Value vs ValueCastable, where it's reasonable to expect the latter knows better if it implements the operator at all
Wanda[cis] has joined #amaranth-lang
<Wanda[cis]>
galibert[m]: for `ValueCastable` on `ValueCastable`, this simply follows normal Python operator rules, which are covered by Python documentation
<galibert[m]>
Wanda: in normal python you don't often have to interop in the numerical operators space between different libraries, while ValueCastables are going to be everywhere
<whitequark[cis]>
I don't know that they're going to be so common in third party libraries
<whitequark[cis]>
ValueCastable is still an advanced feature that provides language extensibility; its overuse is bound to cause problems, and generally you'd want most to come from amaranth.lib
<whitequark[cis]>
fairly few people write new Python numerics either, for similar reasons
<galibert[m]>
they all use numpy :-)
<whitequark[cis]>
in any case, galibert, your disposition: merge or close? the meeting ran out of time
<galibert[m]>
merge
<galibert[m]>
perfect is the enemy of good
<whitequark[cis]>
thanks! RFC #28 will be merged.
<whitequark[cis]>
a doc improvement doesn't depend on the RFC process anyway
<_whitenotifier>
[amaranth-lang/amaranth-lang.github.io] whitequark 20617d1 - Deploying to main from @ amaranth-lang/rfcs@278305234a72ca1afde92c1ad7ed8c999fe42368 🚀
<_whitenotifier>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 612024a - Deploying to main from @ amaranth-lang/amaranth@e55dec9615adfaf6558738930889c74713a3f109 🚀
mindw0rk has quit [Ping timeout: 240 seconds]
mindw0rk has joined #amaranth-lang
nelgau has quit [Ping timeout: 240 seconds]
<cr1901>
I like the reflected decorator approach
RobTaylor[m] has joined #amaranth-lang
<RobTaylor[m]>
<whitequark[cis]> "people seem to really hate the..." <- I am understand that, seems like something to do with requirements 😂
cyrozap_ has joined #amaranth-lang
esden_ has joined #amaranth-lang
benreynwar_ has joined #amaranth-lang
benreynwar has quit [Ping timeout: 264 seconds]
esden has quit [Ping timeout: 264 seconds]
urja has quit [Ping timeout: 264 seconds]
cyrozap has quit [Ping timeout: 264 seconds]
yuriks has quit [Ping timeout: 264 seconds]
esden_ is now known as esden
benreynwar_ is now known as benreynwar
urja has joined #amaranth-lang
yuriks has joined #amaranth-lang
peepsalot has quit [Quit: Connection reset by peep]