* add type for Num.toStr
* create new lowlevel
* delete types and Symbol for fromInt and fromFloat
* leave LowLevel::{StrFromFloat,StrFromInt}
* match on LowLevel::NumToStr and figure out the layout to decide
which build function to delegate to
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
With this change, mispellings of things like `true` and `false` will
include a hint to the user that they may want to use `True` and `False`,
respectively, instead.
There are a few ways to implement this, but exposing these common tags
(which compose builtin type aliases) seems the easiest, least expensive,
and doesn't break anything for now.
