https://kotlinlang.org logo
Join Slack
Powered by
Should we rewrite <arrow-kt.io/learn/typed-errors/...
# arrow-contributors
c
Should we rewrite arrow-kt.io/learn/typed-errors/working-with-typed-errors to use context parameters?
➕ 1
👍 1
y
I would prefer that since they're stable now. Alternatively, we could have a code tab for them (similar to 
accumulate
tab that's there already)
s
Yes, I would keep 
Either<E, A> = either {
to compare it to 
Raise
but I would make all (?) cases where 
Raise
is the extension receiver into a context parameter.
c
If I submit a PR using context parameters, how much can I change from the current pages?
s
If I submit a PR using context parameters, how much can I change from the current pages?
As much as you feel is needed for it to be more beneficial to the community ☺️
c
👀
it's dangerous to tell me this, you know
😄 1
s
Nah, only good things can come from it. It's dangerous for you 😜
😂 2
c
First draft so we agree on the code style before I do larger pages: https://github.com/arrow-kt/arrow-website/pull/501
❤️ 1
👀 1
It's very small (20 lines), can you take a look ASAP? If we're happy with that I can write a lot more tonight
y
Thank you so much for leading the charge on this! Just a couple thoughts: • We don't really need the 
raise
context param named. I believe it's unlikely that one will be passing 
raise
instances around explicitly, and in that instance, they can choose to name the parameter or use 
contextOf
. However, there's a minor advantage to this which is that callers can use Explicit Context Arguments (I.e. pass it by name). I think it's fine either way, but I personally use 
_: Raise
all the time. • 
accumulate { }
could be replaced with 
context(_: Accumulate<Error>
. But, It's still experimental, so I'm happy with 
accumulate { }
for now
c
I wouldn't normally name the context parameter either, but now that I've been bit by https://kotlinlang.slack.com/archives/C5UPMM0A0/p1786642066677449 I'm thinking it's a better habit?
I have not really followed the new accumulate DSL so I honestly don't know how to use it. For the Quickstart page I think it's better to only use stable stuff, but the dedicated page should probably mention both at least until the new DSL is stable
➕ 1
y
Even in that case, differentiating by type is probably more natural (I.e. 
ensure<Foo>(condition) { someFooValue }
instead of naming the specific raise. I think 
_: Raise
helps communicate the effect-iness of it more? FWIW, Alejandro said on his blog:
Raise should never be the spotlight, it just provides additional convenience for describing non-happy paths. On a separate note, this group is for me the only one in which using unnamed context parameters (_) is advisable.
Although that might've been before explicit context arguments
c
Oh, I didn't realise I could disambiguate by type argument there. That begs the question of why the compiler can't do that itself though
But yeah, I'll go with 
_
then
though honestly I don't find 
_: Raise<E>
very pretty and there's a chance it might irk people more than 
raise: Raise<E>
?
y
I looked into the internals a few months back, so my recollection may be off. Basically, context parameters are resolved earlier than lambdas are, so you get an ambiguity error. I believe this doesn't happen with extensions because the receiver choice is deferred somehow. There's probably some worry about combinatorial explosion here (you can only have max 2 receivers, but an unlimited number of context params) Specifying the type or using a function reference instead of a lambda removes the ambiguity. Re aesthetics: what happens when you have multiple `Raise`s? 
raise1
, 
raise2
feels like a step back. It's really just bike shedding though. I'd say use 
raise: Raise
for now, and we can always Find and Replace it if we want to later
👍 1
s
Hey @CLOVIS, I've been working on a accumulating post after experimenting with 
Accumulate
which covers all accumulating use-cases pretty nicely. github.com/nomisRev/ktor-arrow-example/compare/website?expand=1 Also made this PR in Arrow-kt to improve the AP (unreleased).
2 Views
Open in Slack
PreviousNext
Powered by