Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Added `normalizeWith` function. #79
I didn't spend too much time testing the change since I have some doubts whether this is an acceptable regarding the original mission of Dhall.
I think this is a great idea, but I would suggest a different approach, which is to change the type of
normalizeWith :: CtxFun a -> Expr s a -> Expr t a normalizeWith (CtxFun f) e = case f e of ... normalize = normalizeWith (CtxFun id)
The reason why is that you might want to implement functions that cannot be normalized until they are fully saturated. An example of such a function in Dhall is
The other reason I suggest this change is that I expect this to be more efficient. Doing a
I've experimented a little bit with applying
Any opinions how this should be handled? Just
I've now moved the application of CtxFun back to App-case from the top level. The previous attempt at this didn't work out, since the normalization was cut short. Also, having all of the ast available to CtxFun seems like an overkill ("Hey, lets go and replace all True's with 42's"). When it is applied as the last case of App you know that it won't be likely to mess up pre-existing stuff that is outside of the captured App.
There are also two tests, which demonstrate how this works.
This seems fine. My only remaining suggestion is to change the type of the function back to
_ -> ctx (App f' a')
... and then
normalize = normalizeWith id
... for the same reason as before: efficiency
I don't think
What if the
We also can't loop here without looping forever. We need to know if
The other alternative is to require that all custom primitives produce their results in normal form but this is somewhat more limited approach.
I can probably whip up a criterion for testing how much this slows things down if you are really worried. Can you think of a good test case? (Normalize the prelude? The tutorial?).
added a commit
this pull request
Jul 5, 2017
Oh yeah, I hadn't though about the need to continue looping. Then I think it's fine as is
I think the performance impact will probably be minimal since it only affects the case where normalization is blocked, which is not that common and not on the critical path