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
This came up while exploring the native AST in a little more depth for a future version.
type renameable =Named string |Renamed{ name: string, original: string }type symbol =Symbol{ line: int, name: renameable }let symbol_rename (Symbol{line=l, name=Named n}) new_name =Symbol{line=l, name=Renamed{name=new_name, original=n}}-- Interesting! This is not a type error, but rather requires that the record-- coming in simply has `orig` in addition to `name` and `original`. Didn't think of-- this at all as a possible library-writer-side problem.let symbol_rename (Symbol{line=l, name=Renamed{orig=o}}) new_name =Symbol{line=l, name=Renamed{name=new_name, original=o}}
Two problems:
Serious: instead of warning that symbol_rename performs an incomplete match (no wildcard for Renamed, no checks for original or name), we get a {badkey, orig} error.
Less immediate, if still serious: while Renamed { orig=o } is completely legitimate, the type system right now would actually forget the orig: String member per Records lose information in type constructors #125 without additional work to define renameable with an explicit row variable (and this is a hypothetical solution that I'm not sure would work properly), meaning that a caller could never satisfy this pattern.
Closesalpaca-lang#260.
Just adds a default value indicating that a record field is extraneous
if it can't be found in the actual specified type (e.g. via type
constructor.)
This came up while exploring the native AST in a little more depth for a future version.
Two problems:
symbol_rename
performs an incomplete match (no wildcard forRenamed
, no checks fororiginal
orname
), we get a{badkey, orig}
error.Renamed { orig=o }
is completely legitimate, the type system right now would actually forget theorig: String
member per Records lose information in type constructors #125 without additional work to definerenameable
with an explicit row variable (and this is a hypothetical solution that I'm not sure would work properly), meaning that a caller could never satisfy this pattern.Full stack trace from eunit:
The text was updated successfully, but these errors were encountered: