I was hoping to add nested datatypes into the language, but it turns out
doing so is quite tricky and not all that useful with Roc's current
compilation model. Basically every implementation strategy I could think
of ended up requiring a uniform representation for the data layout
(or some ugly workaround). Furhermore it increased the complexity of the
checker/mono IR generator a little bit - basically, we must always pass
around the alias definitions of nested datatypes and instantiate them
at usage sites, rather than being able to unroll aliases as we currently
do during canonicalization.
So, especially because we don't support polymorphic recursion anyway, I
think it may be better to simply disallow any kind of nested datatypes
in the language. In any case, Stephanie Weirich [seems to think nested
datatypes are not needed](https://www.cis.upenn.edu/~plclub/blog/2020-12-04-nested-datatypes/).
Closes#2293
* Remove the `pos` field, which was always being assigned Position::default()
* Remove one use of this `pos`, by removing the never-used SyntaxError::ConditionFailed variant
* Adjust the other use to do what was probably intended - which is to say, pointing to the beginning of the def with the error
* Rename to FileError, reuse `SourceError` as an inner field, to avoid duplicating the `bytes`
This will simplify parsing and make it possible to have a uniform lexer for the language. Previously unquoted package names were allowed to include '-'s, which aren't valid identifiers.
In the future, we'll distinguish local paths from packages in the package-manager by looking for a ".roc" suffix, which should only be present in local paths.
+ Evidently I failed to finish fixing merge conflicts
+ Some of the types that the SingleQuote code mentioned didn't exist according to the build step. I looked around and switched them out for types it LOOKED like they were supposed to be, but someone should probably check this
+ Don't make commits like this; it's multiple unrelated changes thrown together. I'm still figuring out my way around here
This reverts commit 6e4fd5f06a1ae6138659b0073b4e2b375a499588.
This idea didn't work out because cloning the type and storing it on a
variable still resulted in the solver trying to uify the variable with
the type. When there were errors, which there certainly would be if we
tried to unify the variable with a structure that had nested flex/rigid
vars, the nested flex/rigid vars would inherit those errors, and the
program wouldn't typecheck.
Since the motivation here was to expose the signature type to
`reporting` so that we could modify it with suggestions, we should
instead pass that information along in something analogous to the
`Expected` struct.
There is still a potential for conflicts here, because we don't look at
type variables introduced _prior_ to this annotation. However, this
should be okay in most cases.
To provide better error messages and suggestions related to changing
type annotations, we now pass annotation type signatures all the way
down through the constraint solver. At constraint generation we
associate the type signature with a unique variable, and during error
reporting, we pull out an `ErrorType` corresponding to the original type
signature, by looking up the unique variable. This gives us two nice
things:
1. It means we don't have to pass the original, AST-like type
annotation, which can be quite large, to everyone who looks at an
expectation.
2. It gives us a translation from a `Type` to an `ErrorType` for free
using the existing translation procedure in `roc_types::subs`,
without having to create a new translation function.
We now push analysis of when two wildcards are associated with each
other to the time when we try to give tips for a diff between types. Two
wildcards always have a diff, since they are associated with different
types.
This makes it easier for error reporting to find the relevant
annotations that were part of a type error, and display that in the
error message presented to a user.
Previously, a program like
```roc
word = "word"
if True then 1 else "\(word) is a word"
```
would report an error like
```
── TYPE MISMATCH ───────────────────────────────────────────────────────────────
This `if` has an `else` branch with a different type from its `then` branch:
3│ if True then 1 else "\(word) is a word"
^^^^^^^^^^^^^^^^^^
This concat all produces:
Str
but the `then` branch has the type:
Num a
I need all branches in an `if` to have the same type!
```
but this is a little bit confusing, since the user shouldn't have to
know (or care) that string interpolations are equivalent to
concatenations under the current implementation.
Indeed we should make this fully transparent. We now word the error
message by taking into account the way calls are made. To support the
case shown above, we introduce the `CalledVia::Sugar` variant to
represent the fact that some calls may be the result of desugaring the
surface syntax.
This commit also demonstrates the usage of `CalledVia` to produce better
error messages where we use binary comparison operators like `<`. There
are more improvements we can make here for all `CalledVia` variants, but
this is a good starting point to demonstrate the usage of the new
procedure.
Closes#1714
