roc/compiler/parse/src
ayazhafiz 4e942b3e5d Make nested datatypes into errors
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
2022-01-31 22:58:01 -05:00
..
ast.rs Make nested datatypes into errors 2022-01-31 22:58:01 -05:00
blankspace.rs fmt 2022-01-01 18:20:05 -08:00
expr.rs Remove accidental trailing spaces 2022-01-18 22:25:46 -07:00
header.rs Parse hosted modules 2022-01-30 20:40:49 -05:00
ident.rs Use UppercaseIdent over PlatformRigids 2022-01-23 11:13:23 -05:00
keyword.rs add expect keyword 2021-04-22 21:17:09 +02:00
lib.rs extract state 2021-12-16 17:13:53 -08:00
module.rs Parse hosted modules 2022-01-30 20:40:49 -05:00
number_literal.rs fmt 2022-01-01 18:20:05 -08:00
parser.rs Drop some unused variants 2022-01-30 20:40:49 -05:00
pattern.rs Simplify advancing 2022-01-01 18:20:05 -08:00
problems.rs s/CodePoint/CodePt/g 2021-08-07 21:46:20 -04:00
state.rs Remove debug_assert that may legally check a false value 2022-01-29 23:58:46 -05:00
string_literal.rs Simplify advancing 2022-01-01 18:20:05 -08:00
test_helpers.rs Refactor ParseProblem 2022-01-03 20:10:50 -08:00
type_annotation.rs Fixup type annotations 2022-01-01 18:20:05 -08:00