QPQ-AG/hakuzaru
10
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Fix coerce/3 when applied to namespace types, and type parameters inside record types. #1

Merged
spivee merged 8 commits from spivee/coerce-fixes into master 2025-02-27 21:17:11 +09:00
Conversation 4 Commits 8 Files Changed 1 +12 -8
1 changed files with 12 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files
Showing only changes of commit 36a9b17b78 - Show all commits

20
src/hz.erl
View File

@ -2210,19 +2210,23 @@ eu(N, Size) ->
%%% Simple coerce/3 tests
% Round trip coerce run for the eunit tests below. If these results don't match
% then the test should fail.
try_coerce(Type, Sophia, Fate) ->
FateActual = coerce(Type, Sophia, to_fate),
SophiaActual = coerce(Type, Fate, from_fate),
case {ok, Fate} == FateActual of
true ->
% Run both first, to see if they fail to produce any result.
{ok, FateActual} = coerce(Type, Sophia, to_fate),
{ok, SophiaActual} = coerce(Type, Fate, from_fate),
% Now check that the results were what we expected.
case FateActual of
Fate ->
ok;
false ->
_ ->
erlang:error({to_fate_failed, Fate, FateActual})
end,
case {ok, Sophia} == SophiaActual of
true ->
case SophiaActual of
Sophia ->
ok;
zxq9 marked this conversation as resolved
zxq9 commented 2025-02-27 20:50:11 +09:00
Review
Copy Link

OOC, what is the reason behind the erlang:error instead of a return tuple? Is there a reason for a non-local return?
The reason I ask is that there is a lot of serialization and bytecode library code that throws or errors, and it winds up complicating the calling code, which is sort of the opposite of the approach I tend to prefer (granted, sometimes it is annoying to actually play the return-tuple game).

OOC, what is the reason behind the erlang:error instead of a return tuple? Is there a reason for a non-local return? The reason I ask is that there is a lot of serialization and bytecode library code that throws or errors, and it winds up complicating the calling code, which is sort of the opposite of the approach I tend to prefer (granted, sometimes it is annoying to actually play the return-tuple game).
zxq9 commented 2025-02-27 20:58:28 +09:00
Review
Copy Link

You just told me out of context that this is for the benefit of eunit. Makes sense now. Thanks.

You just told me out of context that this is for the benefit of eunit. Makes sense now. Thanks.
spivee commented 2025-02-27 21:16:05 +09:00
Review
Copy Link

Yeah, it's just to crash eunit tests that aren't giving the correct results. I have fixed up the redundant case A == B of true bit though, something you pointed out a while ago.

Yeah, it's just to crash eunit tests that aren't giving the correct results. I have fixed up the redundant `case A == B of true` bit though, something you pointed out a while ago.
false ->
_ ->
erlang:error({from_fate_failed, Sophia, SophiaActual})
end,
ok.