You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original corset accepts purefun_09, whilst this currently reports an error. The issue is really arising from the fact that we are type checking within the body of the defun. This makes sense, but its not backwards compatible. Specifically, we have something like this:
(defun (id (x :binary)) x)
(defun (f x) (id x))
Currently, f will not compile because id requires its parameter to be :binary. The fix is very simple: explicitly declare f as accepting (x :binary).
The text was updated successfully, but these errors were encountered:
Overall, I think this is actually something we shouldn't fix. The error message simply forces us to put a parameter on the enclosing defun declaration, which is entirely sensible. It means we'll have to update the constraints to match this. If there are a large number of problem sites, then we may need to revisit this decision.
DavePearce
changed the title
Type checking for defpurefun is too restrictive
Modular Type checking for Functions
Dec 21, 2024
Original corset accepts
purefun_09
, whilst this currently reports an error. The issue is really arising from the fact that we are type checking within the body of thedefun
. This makes sense, but its not backwards compatible. Specifically, we have something like this:Currently,
f
will not compile becauseid
requires its parameter to be:binary
. The fix is very simple: explicitly declaref
as accepting(x :binary
).The text was updated successfully, but these errors were encountered: