frgo has quit [Read error: Connection reset by peer]
buganini has joined #amaranth-lang
buganini has quit [Ping timeout: 246 seconds]
buganini has joined #amaranth-lang
buganini has quit [Ping timeout: 252 seconds]
Degi_ has joined #amaranth-lang
sorear has quit [Read error: Connection reset by peer]
sorear has joined #amaranth-lang
Degi has quit [Ping timeout: 276 seconds]
Degi_ is now known as Degi
jjsuperpower__ has quit [Ping timeout: 252 seconds]
buganini has joined #amaranth-lang
buganini has quit [Ping timeout: 246 seconds]
buganini has joined #amaranth-lang
buganini has quit [Ping timeout: 248 seconds]
buganini has joined #amaranth-lang
frgo_ has quit [Quit: Leaving...]
le-million[m] has quit [Quit: Idle timeout reached: 172800s]
<zyp[m]>
I've been thinking a bit about the compatibility check hook, and a major question is what should be responsible for imposing stricter checks, with the obvious options being wiring.Signature or ShapeCastable
<zyp[m]>
an argument for the latter is that it would make sense for e.g. fixed.Shape to reject connecting a 8.8 fixedpoint number to a 1.15 fixedpoint number regardless of what interface it's used in
<zyp[m]>
and it wouldn't be unreasonable for data.Layout to reject connections between incompatible layouts either
<zyp[m]>
which I seem to recall you've suggested before
<zyp[m]>
* which I seem to recall Catherine has suggested before
<whitequark[cis]>
i think it would have to be Signature, with a default behavior for incompatible ShapeCastables
buganini has quit [Ping timeout: 260 seconds]
<zyp[m]>
«both» is a valid option too
buganini has joined #amaranth-lang
buganini has quit [Ping timeout: 252 seconds]
<whitequark[cis]>
<zyp[m]> "«both» is a valid option too" <- those would have to be different APIs
<whitequark[cis]>
and whatever is done for ShapeCastable should probably be done for bare .eq too
<zyp[m]>
.eq is different in that .eq itself is already a hook that value-castables can implement and handle
<zyp[m]>
e.g. fixed.Value.eq would look at the assigned value and take care of adjusting precision if it's being assigned to a value with a different precision
<whitequark[cis]>
.connect calls .eq so that seems fine then?
<zyp[m]>
connect calls Value.cast first, so the value-castable's .eq doesn't get called in that case
<whitequark[cis]>
oh, you're right
<whitequark[cis]>
should we change that?
<zyp[m]>
that might be a reasonable change, as long as we're fine by implicitly mandating that every value-castable must then implement a roundtrippable .eq
<whitequark[cis]>
what do you mean by roundtrippable?
<whitequark[cis]>
oh, reflexive?
<zyp[m]>
as in a.eq(b) must be valid and equivalent to Value.cast(a).eq(Value.cast(b)) for a and b with identical shapes
<zyp[m]>
I don't see a case where we wouldn't want that, but currently there's nothing mandating it
<whitequark[cis]>
oh yeah
<whitequark[cis]>
we should definitely mandate that
<zyp[m]>
right now I believe a value-castable doesn't even need to implement .eq
<whitequark[cis]>
yeah
<whitequark[cis]>
some would be inherently not assignable
<zyp[m]>
so how about a RFC with the following scope:
<zyp[m]>
- change `wiring.connect()` to not do `Value.cast()` before `.eq()`
<zyp[m]>
- change `data.View.eq()` to check the type of `other` and verify they have matching layouts if it's another `View`
<zyp[m]>
I figure that should be enough for connect to be able to reject connecting e.g. streams with equally wide but mismatched payload structures
<whitequark[cis]>
sgtm
<whitequark[cis]>
we'd need a migration path, so a warning for 0.6 with a fallback on Value.cast on 0.6
RobTaylor[m] has joined #amaranth-lang
<RobTaylor[m]>
should the reqs for amaranth-soc and amaranth-stdio be bumped to >=0.5,<0.7 ?
<whitequark[cis]>
probably, yeah
<whitequark[cis]>
>=0.5.2,<0.7
<whitequark[cis]>
* >=0.5.2,<0.7
buganini has joined #amaranth-lang
FFY00_ has joined #amaranth-lang
FFY00 has quit [Read error: Connection reset by peer]