Aurélien Geron (Jun 17 2026 at 03:15): Aurélien Geron (Jun 17 2026 at 03:15):I'm porting an exercise solution that contained this code:
Score : U64
latest : List Score -> Result Score [ListWasEmpty]
latest = |scores|
List.last(scores)
So I changed it to this:
Score := U64
latest : List(Score) -> Try(Score, [ListWasEmpty])
latest = |scores| {
scores.last()
}
However, this fails because the Score type does not define is_eq.
It looks like Score is treated like a brand new type, and no methods from U64 are preserved. I can see why this would make sense for a brand new type definition, but in this case the exercise just uses Score as an alias for U64. I tried Score = U64 but it did not work.
Is there a way to define a type alias, not a type definition?
Luke Boswell (Jun 17 2026 at 03:17):You are using := here (nominal type def) which is not an alias :
Aurélien Geron (Jun 17 2026 at 03:17):Oh, does : still exist? Cool, my apologies.
Richard Feldman (Jun 17 2026 at 03:17):we also have a way to derive is_eq (and a few others - I forget which ones are implemented at the moment)
Luke Boswell (Jun 17 2026 at 03:17):Yes
:= nominal type def:: opaque type def: type alias Richard Feldman (Jun 17 2026 at 03:18):inside Score := ... you can define a method like is_eq = _
Richard Feldman (Jun 17 2026 at 03:18):also for Score :: ...
Richard Feldman (Jun 17 2026 at 03:18):and give it a type annotation if you like
Aurélien Geron (Jun 17 2026 at 03:18):Ahhhh, makes total sense now, thanks! :folded_hands:
Richard Feldman (Jun 17 2026 at 03:18):I don't know if anyone has actually used that outside of tests though, so you may be the first to battle-test it! :smile:
Luke Boswell (Jun 17 2026 at 03:19):The langref section for this isn't finished yet, it doesn't have aliases
Aurélien Geron (Jun 17 2026 at 03:19):I'm up to 25 exercises ported now, and I'm not running into many issues. There are just 3 that cause the compiler to crash, I've opened issues and I think a few have been fixed, I'll try again.
Richard Feldman (Jun 17 2026 at 03:24):yeah thank you for those bug reports!
Richard Feldman (Jun 17 2026 at 03:25):do you remember how this compiler compared to the original when you were doing those exercises, in terms of bugginess?
Aurélien Geron (Jun 17 2026 at 04:48):Richard Feldman said:
yeah thank you for those bug reports!
Thank you for the fixes! :+1:
Aurélien Geron (Jun 17 2026 at 04:52):Richard Feldman said:
do you remember how this compiler compared to the original when you were doing those exercises, in terms of bugginess?
To be very honest I think it's still a bit less stable, but it's improving quickly, I'm confident it will get there soon.
However, I'm using the compiler compiled from source on my MacBook, and I find it pretty slow compared to the old Roc. Is that because by default it builds a debug version or something?
Luke Boswell (Jun 17 2026 at 05:17):The debug build is defintely a lot slower than release builds, Zig has a lot of extra work going on around allocators.
Luke Boswell (Jun 17 2026 at 06:17):I've also found a few bugs recently where things were being done the naive way and it blows up exponentially etc. I've made GH Issues for those and Richard has been been able to fix those pretty quickly. I had one today where compile times were > 10 minutes and it dropped to ~100s on this one app I had.
Aurélien Geron (Jun 17 2026 at 06:54):Cool! Yes, the exercises take 5 to 15 seconds to run, when it used to be milliseconds. I think it's mostly compilation time, but I'll double check.
Luke Boswell (Jun 17 2026 at 06:58):For the run thing, I suspect 95% of the time is dominated by just loading the builtins each time. @Anton has an idea to cache the checked artefact so that should eliminate that I think.
Anton (Jun 17 2026 at 09:47):@Aurélien Geron if you build with zig build build-release, it will be a lot faster. By the way, the binary will still be in the same place as before (./zig-out/bin/roc).
Aurélien Geron (Jun 17 2026 at 11:17):Oh wow, thanks @Anton, it's waaay faster!
Last updated: Jul 23 2026 at 13:15 UTC