<cr1901>
I feel silly asking this, but... no meeting today?
whitequark_ has joined #amaranth-lang
<whitequark_>
cr1901: the libera bridge is down, it seems
<whitequark_>
I was wondering why no one is attending
<whitequark_>
okay, irc->matrix works, but matrix->irc does not
<whitequark_>
let's take a roll call. cr1901? vup? adamgreig? crzwdjk? anuejn? nelgau?
<whitequark_>
agg ^
<whitequark_>
jfng is participating from the other side of the bridge, I can copy his messages or he can join through web.libera.chat
<agg>
ah, I see, matrix->irc isn't going through
<cr1901>
I'm here
jfng_ has joined #amaranth-lang
<agg>
but irc->matrix is, weird
<cr1901>
Probably time to poke a Libera mod again
<whitequark_>
I have no idea what's going on. I'm unhappy with how unreliable it is, we might have to move to Zulip eventually or something
<agg>
the heisenbridge irc<->matrix bridge I run for rust-embedded has been reliable lately, but is a bit annoying for irc users as it works like d1b2 does
<agg>
anyway sorry, where did we get to on RFCs?
<whitequark_>
good afternoon everyone, it is time for our regular Monday meeting
<whitequark_>
please respond with your comments and proposed disposition: close or merge
<agg>
I like the result and haven't thought in depth about the implementation details but seems fine, merge
whitequark_ has quit [Quit: Client closed]
whitequark_ has joined #amaranth-lang
<whitequark_>
combined with RFC 8 we get a situation where ShapeCastables are effectively required (for interop with data.View) to implement __call__ which wraps a value-castable and returns an instance of the shape-castable
<whitequark_>
if we merge RFC 8 + RFC 9 as it is, then __call__ always takes a value-castable and returns whatever (but realistically an instance of the shape-castable), and .const takes whatever (but realistically a literal of some sort) and returns a Const
<whitequark_>
this seemed preferable than one superpolymorphic __call__ that takes whatever and returns whatever, but specific things in specific cases
<whitequark_>
but one could also see the superpolymorphic __call__ to be implementing casting as a concept
<cr1901>
>The reset= argument becomes dependently typed. <-- what does this mean?
<whitequark_>
right now the type of reset is just int, but with this change, if you tried to write the type for Signal, it would become something like `Signal : forall T: ShapeCastable. T -> reset=T::ConstCastableFrom -> Signal`
<whitequark_>
you know GATs in Rust? it's that
<whitequark_>
I would expect no Python type system to be able to handle that
<agg>
at least you could just say the type is "integer or const-castable"?
<whitequark_>
well {"foo": 1} is not const-castable in general, you can't `Const.cast({"foo": 1})`
<whitequark_>
that's what I mean when I say it's dependently typed
<jfng_>
will this break existing code that define ShapeCastables ?
<whitequark_>
is there existing code? ShapeCastable hasn't been in a release yet
<cr1901>
I don't see the GAT comparison, but I can ask about that after the meeting. It doesn't _sound_ like a huge cognitive burden
<cr1901>
for Amaranth users*
<jfng_>
i haven't used it yet, indeed
<whitequark_>
oh wait it's not GAT, it's just associated types
<whitequark_>
I completely misremembered what GATs were, sorry
<cr1901>
AFAIR, GAT is "generic on LHS of associate type decl"
<whitequark_>
yeah I was just wrong
<cr1901>
Well, I don't think it's a huge cognitive burden to make reset dependently-typed
<agg>
for users it seems like "it will just do the thing you expect", it seems
<whitequark_>
I want to emphasize that `f: unsigned(8)` is not a valid Python type hint and AFAIK cannot be made a valid Python type (without a typechecker plugin, or possibly at all); it's considered syntactically invalid. `f: Value[unsigned(8)]` is also considered syntactically invalid for typechecking, *but* pyright/pylance accept it enough to autocomplete
<whitequark_>
f.<cursor> to the various Value methods
<whitequark_>
both of these show `f` in the autocomplete list for the struct
<whitequark_>
so as it is, both options presented in the RFC are only useful for autocomplete, and Value[] is only marginally more useful. RFC 11 is not necessary to get autocompletion of field names, including for nested structs
<whitequark_>
if we ever decide to ship something with full typechecking support it will have to be either a plugin, or yet another different syntax
<cr1901>
I'm predisposed to don't merge... this seems to be a not-very-nice workaround to limitations in Python
<cr1901>
And also, I don't care that much about type annotations
<whitequark_>
I think I want to hear the most from the folks using IDEs since this is who this RFC is for
<jfng_>
i don't like the syntax, struct layouts are much more readable without
<cr1901>
Is vscode an IDE?
<whitequark_>
yes, vscode uses pylance
<whitequark_>
(pylance is a language server. pyright is a language server too that is usable in vim/st/etc. they are more or less the same for our purposes)
<cr1901>
I don't like the syntax either. But yes, I'm not wanting for type annotations, so wait for others to chime in who want it
<whitequark_>
agg?
<cr1901>
Well, at least you can opt-out of this syntax
<cr1901>
Sigh, well... I guess I'll get over myself if this is merged
<cr1901>
FWIW, I like emilazy's idea for mypy too
<cr1901>
along w/ a typing module
<whitequark_>
I'm not sure if mypy will ever be usable
<whitequark_>
re: this being merged, we have no consensus, and so far my policy has been "merge if there is full consensus"
<whitequark_>
actually we seem to be going towards "consensus to close"
<cr1901>
I want to close, but I also don't want to say "this is a bad design"
<whitequark_>
why not?
<whitequark_>
(and yeah you can just say that your proposed disposition is to close)
<cr1901>
Because just because _I'm_ having a visceral reaction to the syntax and deprecating/removing the old syntax doesn't mean that I have a profound insight
<whitequark_>
right. well, honestly I don't like it at all either, and I proposed it
<cr1901>
into what ppl who want typechecking are thinking
<cr1901>
Alright, predisposition to close
<jfng_>
how about a "hold" decision, and we re-discuss it later ?
<whitequark_>
we can postpone it, yes
<cr1901>
whitequark_: Basically: If I say "I don't like it", I want to interrogate that rather than say "close instantly", if that makes sense
<whitequark_>
it does
<cr1901>
I'm for the new postpone/rework option
<cr1901>
otherwise, close for me
<whitequark_>
it's really an old option, Rust has it and I didn't pull it because I didn't feel it was relevant to our process. well, it is relevant now
<whitequark_>
I'll update the process section later
<jfng_>
merge, the benefits outweigh the drawbacks imo
<whitequark_>
do you expect to use it in more than just enums? (for enums, I can do an implicit conversion to a const integer in amaranth.lib.enum)
<whitequark_>
for context, I'm thinking about close, since it's pulling out a really big hammer and makes code more fragile in a way I've so far tried to avoid, but I'm open to comments as it is an RFC
<cr1901>
I'm in preference to the "implicit lift" alternative, otherwise close
<jfng_>
hmm, reset values come to mind too, but rfc9 handles that
crzwdjk has joined #amaranth-lang
<whitequark_>
I don't think RFC 7 will help much with reset values?
<cr1901>
"Implicit lift" seems to be analogous to something like Rust's coercion sites, which are a minimal set of sites where type conversions implicitly happen. There was pushback when they were introduced (AIUI), but in practice work just fine
<whitequark_>
oh I see, you mean Cat(...)
<jfng_>
yes
<whitequark_>
yeah, RFC 9 will handle that
<whitequark_>
cr1901: hold on, the only alternative i put in is "do not do this"
<whitequark_>
I'm confused
<cr1901>
whitequark_: Disregard everything above, I confused myself reading the RFC. Would take too long to explain
<whitequark_>
crzwdjk: feel free to comment on RFCs we already discussde (8-10) as well as this one
<whitequark_>
8-11, sorry
<cr1901>
I will trust your judgment to close, is there a way to make the error message better for now?
<whitequark_>
for Enum or in general?
<cr1901>
In the motivating example, I certainly would not understand the error "Attempted to convert Amaranth value to Python boolean"
<cr1901>
for Enum
<cr1901>
(without the text that follows, anyway)
<whitequark_>
for Enum, if you use amaranth.lib.enum, I can do the cast already
<whitequark_>
if you don't, unfortunately it's out of my hands
<whitequark_>
or... well, ok, no it's not, I could inspect the frame above and see if it comes from the enum module. this is exceptionally cursed but it would work
<cr1901>
if isinstance(var, enum.Enum): print("you tried using enum.Enum, please use amaranth.lib.enum")
<cr1901>
ahhh
<cr1901>
And how cursed is using inspect, really :P?
<whitequark_>
you can't do isinstance(var, enum)
<whitequark_>
because the EnumMeta code runs == directly on Amaranth values
<jfng_>
if you did a cast instead, what would Instr.ADD.value return ? an int ?
<whitequark_>
yes
<jfng_>
what i like about this rfc, is that the Cat() information isn't lost
<whitequark_>
that was the original idea. but it's really difficult to do anything about the == in EnumMeta
<whitequark_>
it's a 100 line method in which we need to customize one line
<whitequark_>
I don't want to vendor the entirety of it, I'm sure we will regret it if I do
<cr1901>
>because the EnumMeta code runs == directly on Amaranth values <-- I'm going to have to look this up to understand this
<cr1901>
Right now, vote to close, possibly w/ the cursed inspect workaround to make the error less cryptic
<cr1901>
I'm also receptive to postpone
<whitequark_>
agg? (though he didn't respond to RFC 11 either)
<whitequark_>
I guess we also ran out of time half a hour ago
<crzwdjk>
I would also say postpone or close this one
<crzwdjk>
For the other ones, RFC 9: merge, RFC 10: merge. breaks back-compat but it's a pretty minor annoyance. RFC 8: merge.
<agg>
(sorry yea, I had to run, though no particular opinion on typing for 11 and haven't looked into 7)
<crzwdjk>
RFC 11: abstain, I don't know much about type annotations.
<whitequark_>
okay, I think we should call it quits for today. RFC 8, 9, 10 will be merged. RFC 7, 11 will be discussed again on the next meeting
<whitequark_>
thanks everyone for the input
<cr1901>
Seems like decent progress?
<whitequark_>
there is progress yeah
<crzwdjk>
Seems like pretty great progress as far as I'm concerned
<cr1901>
(And the RFCs _were_ in order from least to most controversial :P)
<FireFly>
re the bridging issues, I didn't want to interrupt the meeting, but https://github.com/matrix-org/synapse/issues/15216 was linked elsewhere earlier and is the issue I guess, seems like some problem in the bridge
<_whitenotifier-9>
[amaranth-lang/amaranth-lang.github.io] whitequark e967d1a - Deploying to main from @ amaranth-lang/amaranth@32eabd9372b877f916e0f81cf3d2e0489e48e18e 🚀