Closed 1chb closed 1 year ago
I did some more investigations. Now it seems the problem is that my non-working extension doesn't take an argument. If I add a dummy Natural
argument it works. I also tried to create an extension an argument-less function that results in a Text
and it also fails:
Error: Invalid Dhall.Decoder
Every Decoder must provide an extract function that does not fail with a type
error if an expression matches the expected type. You provided a Decoder that
disobeys this contract
The Decoder provided has the expected dhall type:
↳ Text
and it threw a type error during extraction from the well-typed expression:
↳ ABC/text
So my problem is not related to Enum
at all.
Side note: you can simplify {r1 = r2, r2 = r2, r3 = r3}
to { r1, r2, r3 }
in newer versions of Dhall
Yeah, this seems like a bug. I narrowed down the reproduction to this:
{-# LANGUAGE OverloadedStrings #-}
module ExtensionTest where
import Dhall.Core (Expr(..), ReifiedNormalizer(..), Var(..))
import qualified Dhall
import qualified Dhall.Context as Context
import qualified Lens.Family as Lens
main :: IO ()
main = do
let startingContext = Context.insert "foo" Integer Context.empty
let normalizer (Var (V "foo" 0)) = Just (IntegerLit 0)
normalizer _ = Nothing
let inputSettings = transform Dhall.defaultInputSettings
where
transform =
Lens.set Dhall.normalizer
(Just (ReifiedNormalizer $ pure . normalizer))
. Lens.set Dhall.startingContext startingContext
x <- Dhall.inputWithSettings inputSettings Dhall.auto "foo" :: IO Integer
print x
… which still fails with:
ExtensionTest.hs: Error: Invalid Dhall.Decoder
Every Decoder must provide an extract function that does not fail with a type
error if an expression matches the expected type. You provided a Decoder that
disobeys this contract
The Decoder provided has the expected dhall type:
↳ Integer
and it threw a type error during extraction from the well-typed expression:
↳ foo
What should have happened is that the normalizer should have replaced foo
with 0
before decoding the expression and then the decoding would have succeeded. However, for some reason a non-normalized expression is being decoded, which is unexpected. I'm still investigating why this happens.
Thanks for the quick reply. Yes, it seems like a bug. However, I realized that that this approach will not solve my use case. I planned to provide different contexts for different runs, but this approach is not compatible with the caches.
Yeah, I understand.
Regardless, I found the root cause of the bug and the fix is up here: https://github.com/dhall-lang/dhall-haskell/pull/2464
For me it is not obvious which
Expr
constructor to use for union values, butghci
revealed that it probably should beField
, andembed inject A
confirms that. But I just can't get it to work. Here is my code:Running this gives:
But the value of
r1
is not correct, because I putr1 = r2
in the result of the test program, so my extension functionABC/low
was not used. Also note thatr3
confirms thatembed inject A
builds the sameExpr
asABC/low
. If I instead putr1 = r1
, as it should be, I get:So why am I not just using
(embed . inject)
to convert Haskell to Dhall, i.e.pure $ embed inject A
? Because it doesn't type check:This is due to the type signature of
normailzer
. If I remove it the type error moves to the usage of thenormailizer
, i.e.Lens.set Dhall.normalizer (Just (DCore.ReifiedNormalizer $ pure . normalizer))
:This is also the reason why I hard coded
abcType'
instead of just reusing the generatedabcType
.Hopefully I'm doing it wrongly. This neither is convenient or works.