Web-Projects/blog-static
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Fix typesafe interpreter post.

Browse Source
This commit is contained in:
Danila Fedorin 2020-08-11 19:54:45 -07:00
parent 3e9f6a14f2
commit 068d0218b0
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
content/blog/typesafe_interpreter_revisited.md
View File

@ -361,7 +361,7 @@ I think this is a good approach. Should we want to add more types to our languag
lists, and so on, we will be able to extend our `decEq` approach to construct more complex equality lists, and so on, we will be able to extend our `decEq` approach to construct more complex equality
proofs, and keep the `typecheck` method the same. Had we not used this approach, proofs, and keep the `typecheck` method the same. Had we not used this approach,
and instead decided to pattern match on types inside of `typecheck`, we would've quickly and instead decided to pattern match on types inside of `typecheck`, we would've quickly
found that this only works for types with finitely many values. When we add polymorphic tuples found that this only works for languages with finitely many types. When we add polymorphic tuples
and lists, we start being able to construct an arbitrary number of types: `[a]`. `[[a]]`, and and lists, we start being able to construct an arbitrary number of types: `[a]`. `[[a]]`, and
so on. Then, we cease to be able to enumerate all possible pairs of types, and require a recursive so on. Then, we cease to be able to enumerate all possible pairs of types, and require a recursive
solution. I think that this leads us back to `decEq`. solution. I think that this leads us back to `decEq`.