2.0 KiB
Hey, thank you for taking a look! I'll try answer your questions:
Q: I had a question about why MonadReader was preferred over ReaderT?
A: ReaderT is actually an instance of MonadReader! The difference, though, is that the types are kind of simplified. Instead of having to write ReaderT [Term] ... a, we just write m a. This also allows us to add additional effects to the monad without changing the type signature. For instance, none of the code would change if we wanted to add a state effect via StateT s, because the signatures only require constraints on the types, rather than specifying what the types are.
Q: I had a question about how instances for this monad were created.
A: Check out LoadingImpl, which contains a PathT monad transformer which implements MonadModulePath. I defined it as a newtype
around a ReaderT because you can't have two of the same tranformer in the same monad transformer
stack, and I didn't want PathT to interfere with other ReaderTs in the API.
Q: As you rightly mentioned bundling an environment for all operations is a viable option, please let me know if the operations are then stored in a stack format?
A: Our functions would be kept in a Map String Definition or something of that sort. The lookups
would not be linear time, but probably logarithmic, if that's what you're wondering about.
Q: Kindly let me know if you are referring to type equality?
A: Well, we are referring to type equality, but within our object language (Maypop), and nor our metalanguage (Haskell). Although the library you linked would help with equality of Haskell types, it wouldn't help us with Maypop.
Q: I think using some kind of plugin for haskell might help in doing tactics.
A: It would if we were trying to add tactics to Haskell, but we're trying to add tactics to Maypop. We have full control of the language; the real question is, what will our design be like?