Extended error reporting #89
Comments
|
This causes e.g. derived singletons [d|data Foo = Foo deriving (Enum)|]Minimized, the issue is that this no longer compiles: type family Foo (a :: ()) :: Bool where
Foo '() = Error (FromString "bad")(which makes sense, i.e. if the value-level Reverting 077aee5 fixes the error, but there are other conceivable fixes, but I am not even sure whether this should even be fixed; as I have no idea whether it is even expected/desired to ensure that all TH deriving also works in the presence of |
|
@amesgen, that is a very good observation. Indeed, the type While this issue predates me becoming a co-maintainer of the library, I can't help but wonder if the original motivation still holds true. The original motivation from #89 (comment) is:
Nowadays, there is a type-level
Alternatively, we could keep Thoughts on this, @lykahb? |
Previously, we had generalized the argument kind to `Error` in commit 077aee5 to permit passing things to `Error` besides `Symbol`s. Back then, there was no way to `show` things at the type level, nor was there a way to manipulate `Symbol`s in any meaningful fashion, so this seemed like a reasonable choice. Nowadays, however, the story is different. There is a type-level `Show_` function, and the API for manipulating `Symbol`s is nearly as expressive as the API for manipulating `String`s. What's more, making `Error`'s argument kind more general introduces ambiguity-related issues when deriving `Enum` instances with `OverloadedStrings` enabled, as observed in #89. In light of this, I have changed the API such that: * The kind of the argument to `Error` (as well as the related `ErrorWithoutStackTrace` function) is now `Symbol`. In this sense, this patch reverts 077aee5. * There is now a new `Data.Singletons.Base.PolyError` module that provides a `PolyError` function. `PolyError` provides a kind-polymorphic `Error` interface much like what the previous type of `Error` was, so any existing code that relied on the argument of `Error` being kind-polymorphic can be migrated over to use `PolyError`. Resolves #89 (hopefully for good this time).
Previously, we had generalized the argument kind to `Error` in commit 077aee5 to permit passing things to `Error` besides `Symbol`s. Back then, there was no way to `show` things at the type level, nor was there a way to manipulate `Symbol`s in any meaningful fashion, so this seemed like a reasonable choice. Nowadays, however, the story is different. There is a type-level `Show_` function, and the API for manipulating `Symbol`s is nearly as expressive as the API for manipulating `String`s. What's more, making `Error`'s argument kind more general introduces ambiguity-related issues when deriving `Enum` instances with `OverloadedStrings` enabled, as observed in #89. In light of this, I have changed the API such that: * The kind of the argument to `Error` (as well as the related `ErrorWithoutStackTrace` function) is now `Symbol`. In this sense, this patch reverts 077aee5. * There is now a new `Data.Singletons.Base.PolyError` module that provides a `PolyError` function. `PolyError` provides a kind-polymorphic `Error` interface much like what the previous type of `Error` was, so any existing code that relied on the argument of `Error` being kind-polymorphic can be migrated over to use `PolyError`. Resolves #89 (hopefully for good this time).
|
I've opened #554 with a patch that implements the |
Previously, we had generalized the argument kind to `Error` in commit 077aee5 to permit passing things to `Error` besides `Symbol`s. Back then, there was no way to `show` things at the type level, nor was there a way to manipulate `Symbol`s in any meaningful fashion, so this seemed like a reasonable choice. Nowadays, however, the story is different. There is a type-level `Show_` function, and the API for manipulating `Symbol`s is nearly as expressive as the API for manipulating `String`s. What's more, making `Error`'s argument kind more general introduces ambiguity-related issues when deriving `Enum` instances with `OverloadedStrings` enabled, as observed in #89. In light of this, I have changed the API such that: * The kind of the argument to `Error` (as well as the related `ErrorWithoutStackTrace` function) is now `Symbol`. In this sense, this patch reverts 077aee5. * There is now a new `Data.Singletons.Base.PolyError` module that provides a `PolyError` function. `PolyError` provides a kind-polymorphic `Error` interface much like what the previous type of `Error` was, so any existing code that relied on the argument of `Error` being kind-polymorphic can be migrated over to use `PolyError`. Resolves #89 (hopefully for good this time).
The error function tries to mimic the original one by accepting only Symbols. This significantly constrains error reporting because on the type level there is no show function and symbol manipulation.
I suggest to make its argument kind-polymorphic so that we can pass details on the error site.
The text was updated successfully, but these errors were encountered: