Closed gelisam closed 2 years ago
Thank you for taking a look at this! Sorry for the late reply.
@gelisam the example isn't really an example, it was me playing around and committing it.
Plutarch 2.0 is still not really ready, notably, I'm still trying to figure out how to make embedded data kinds work. This
is relevant to EForall
and such, because really, it should be type EForall :: (a -> EType) -> EType
.
The question is, what constraint do you use? You want to use IsEType
, but it has to be more general.
It has to support types, higher types (e.g. Maybe
), but we also want it to support data kinds.
This is not as trivial as it sounds, because generics only work at the value-level. Perhaps the solution is to abandon generics,
but I'm not quite ready for that.
Albeit, besides the generics stuff, it is pretty settled. I'll probably push the code sometime soon.
Wrt. nested matching, I abandoned this because it didn't seem worth it IMO. It gets very complex, and you have to do all sorts of magic to make it work, either using tons of type classes or using unsafePerformIO
.
It's especially complex when you consider nested constructing.
As you might have noticed, we have an optics draft PR: #13 . Optics seem to solve the same ergonomicity issue AFAICT.
Thanks for showing interest though.
Wrt. doing cabal repl
BTW, you're supposed to do cabal repl --repl-options=-Wwarn
, albeit the warning in question is a bug in GHC I'm pretty sure, since it's completely bogus.
I fixed the examples (and commented out what doesn't work yet).
Thanks!
I first had to remove
-Werror
fromplutarch-core.cabal
in order to get past this unrelated error:Then I got an unbound identifier when loading the example:
Looking at the history, looks like the
UnEf
type family was renamed toEfC
in 8975df7ef941a019d12c78741323fda6e981c81d.After performing the rename, I get a kind error instead:
Looking at the kinds involved, I can fix the kind error by replacing
IsEType (EfC ef)
withEfC ef
, but I don't yet have any idea if that makes any sense semantically.With that "fix", I next encounter a type error:
That is,
ERight
's parameter is already aTerm edsl EUnit
, which is what we need on the right-hand-side, so the code can be simplified to:With this second fix,
Example/Simple.hs
finally typechecks! However, the simplified code is not quite equivalent to the previous code, because we are no longer pattern-matching on EUnit. I get the impression that when the example was written, it was possible to write nested patterns withematch
, but that since then,ematch
has been simplified so that only the outermost constructor is concretized. Thus, if we also want to match on theEUnit
inside theERight
, we need a secondematch
call: