curry-frontend issueshttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues2023-05-26T02:35:19Zhttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/132Instances with equivalent heads from different imported modules are not reported2023-05-26T02:35:19ZLeif-Erik KrügerInstances with equivalent heads from different imported modules are not reportedConsider the following modules `M`, `N` and `O`:
```haskell
module M where
instance Eq (a -> b) where
_ == _ = True
```
```haskell
module N where
instance Eq (a -> b) where
_ == _ = False
```
```haskell
module O where
import M
...Consider the following modules `M`, `N` and `O`:
```haskell
module M where
instance Eq (a -> b) where
_ == _ = True
```
```haskell
module N where
instance Eq (a -> b) where
_ == _ = False
```
```haskell
module O where
import M
import N
testExp :: Bool
testExp = not == id
```
The instances defined in `M` and `N` have the same instance head and are both imported in `O`, but when compiling the latter with PAKCS 3.2.0 (or 3.4.1-b6), no error is reported despite this. Instead, the instance from `M` is "overwritten" by the one from `N` and `testExp` evaluates to `False`.
This bug originates from the `Imports` module, where all imported instances are entered into the instance environment without checking them. Here, instances with equivalent heads overwrite each other. To fix the bug, we either must report such instances in this module or use a different kind of instance environment (for example a list of `InstEnv`s) during the first compilation steps and transform it to a regular `InstEnv` while reporting such errors in the instance check.
Another option, which would allow such imports if the instances with equivalent heads are not used, would be to rework the `InstEnv` data type such that multiple instances with equivalent heads from different modules can be stored in it. This seems to be the option used by the GHC, but it would require some changes in many modules working with instances to fully implement it in the Curry frontend.https://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/130Class methods that are not in scope can cause internal errors2021-07-06T16:48:42ZLeif-Erik KrügerClass methods that are not in scope can cause internal errorsConsider the following modules:
```haskell
module M where
class C a where
methodC :: a
```
```haskell
module N (C) where
import M
```
```haskell
module O where
import N
f :: C a => a
f = methodC
```
In `O`, `methodC` should not be...Consider the following modules:
```haskell
module M where
class C a where
methodC :: a
```
```haskell
module N (C) where
import M
```
```haskell
module O where
import N
f :: C a => a
f = methodC
```
In `O`, `methodC` should not be in scope and when compiling the module with PAKCS, an appropriate error message should be reported. Instead, we get the following internal error, which basically states that `funType` in the dictionary transformation module has not found `M.methodC` in the value environment:
```
Prelude> :l O
[1 of 4] Skipping Prelude ( /home/leif/pakcs-3.2.0/lib/Prelude.curry, /home/leif/pakcs-3.2.0/lib/.curry/pakcs-3.2.0/Prelude.fcy )
[2 of 4] Compiling M ( M.curry, .curry/pakcs-3.2.0/M.fcy )
[3 of 4] Compiling N ( N.curry, .curry/pakcs-3.2.0/N.fcy )
[4 of 4] Compiling O ( O.curry, .curry/pakcs-3.2.0/O.fcy )
pakcs-frontend: Internal error: Dictionary.funType QualIdent {qidSpanInfo = SpanInfo {srcSpan = Span {file = ".curry/pakcs-3.2.0/N.icurry", start = Position {file = ".curry/pakcs-3.2.0/N.icurry", line = 3, column = 7}, end = Position {file = ".curry/pakcs-3.2.0/N.icurry", line = 3, column = 15}}, srcInfoPoints = []}, qidModule = Just (ModuleIdent {midSpanInfo = SpanInfo {srcSpan = Span {file = ".curry/pakcs-3.2.0/N.icurry", start = Position {file = ".curry/pakcs-3.2.0/N.icurry", line = 3, column = 7}, end = Position {file = ".curry/pakcs-3.2.0/N.icurry", line = 3, column = 8}}, srcInfoPoints = []}, midQualifiers = ["M"]}), qidIdent = Ident {idSpanInfo = SpanInfo {srcSpan = Span {file = ".curry/pakcs-3.2.0/N.icurry", start = Position {file = ".curry/pakcs-3.2.0/N.icurry", line = 4, column = 3}, end = Position {file = ".curry/pakcs-3.2.0/N.icurry", line = 4, column = 9}}, srcInfoPoints = [Span {file = ".curry/pakcs-3.2.0/N.icurry", start = Position {file = ".curry/pakcs-3.2.0/N.icurry", line = 4, column = 3}, end = Position {file = ".curry/pakcs-3.2.0/N.icurry", line = 4, column = 9}}]}, idName = "methodC", idUnique = 0}}
CallStack (from HasCallStack):
error, called at src/Base/Messages.hs:78:21 in curry-frontend-2.0.0-2OM1MZb8aCM4fBMC351o4R:Base.Messages
ERROR occurred during parsing!
```
<br>
Interestingly, if we skip module `N`, but change `M` to export class `C` without `methodC` (as seen in the modified modules below), then `methodC` is in scope in `O`, so `O` compiles without problems. This is probably not intended. At any rate, it is different than the behavior of the GHC, which reports `Variable not in scope` errors for both the unmodified and modified versions of the modules `M`, `N`, and `O`.
```haskell
module M (C) where
class C a where
methodC :: a
```
```haskell
module O where
import M
f :: C a => a
f = methodC
```https://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/119Type class contexts are ignored for external functions2020-12-08T14:28:04ZFinn TeegenType class contexts are ignored for external functionsDue to the fact that type class context in signatures of external functions are completely ignored during type checking, one could write expressions like `id =:= id` without type error.Due to the fact that type class context in signatures of external functions are completely ignored during type checking, one could write expressions like `id =:= id` without type error.https://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/118Type class contexts are missing for external functions in AbstractCurry2020-12-08T14:28:25ZFinn TeegenType class contexts are missing for external functions in AbstractCurryFinn TeegenFinn Teegenhttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/110Allow Data instances for external data types2020-11-25T11:09:14ZFinn TeegenAllow Data instances for external data typesCurrently, the frontend only allows custom data instances in the prelude. It should also allow data instances for external data types in every module. Moreover, the frontend currently does not check whether there is another Data instance...Currently, the frontend only allows custom data instances in the prelude. It should also allow data instances for external data types in every module. Moreover, the frontend currently does not check whether there is another Data instance in the Prelude for normal data types. That way, it is possible to have two Data instances at once for one data type. This issue would be fixed by allowing custom Data instances only for external data types.https://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/109Wrong transformation of some type class instances2020-12-01T10:12:08ZFinn TeegenWrong transformation of some type class instancesConsider the following program:
```
data A = A
class B a where
b :: a -> Bool
instance B A where
b = (\_ -> True) ? (\_ -> False)
bs x = [b x, b x]
test = bs A
```
Evaluating `test` results in only two value, namely `[True, Tru...Consider the following program:
```
data A = A
class B a where
b :: a -> Bool
instance B A where
b = (\_ -> True) ? (\_ -> False)
bs x = [b x, b x]
test = bs A
```
Evaluating `test` results in only two value, namely `[True, True]` and `[False, False]` instead of four values. This is a severe bug that is not tackled by the proposal from Wolfgang Lux that is implemented with the augmentation during the dictionary transformation.Finn TeegenFinn Teegenhttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/80Translate user's type annotations correctly2020-01-28T13:51:26ZFinn TeegenTranslate user's type annotations correctlyAlthough currently not relevant due to the lack of support for scoped type variables, a user's type annotation should be transformed correctly during the dictionary translation. Currently, any context gets dropped.Although currently not relevant due to the lack of support for scoped type variables, a user's type annotation should be transformed correctly during the dictionary translation. Currently, any context gets dropped.https://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/77Type variable escapes when encoding existential types2020-07-13T19:14:55ZFinn TeegenType variable escapes when encoding existential typesConsider the following program.
```haskell
{-# LANGUAGE RankNTypes #-}
data Showable = Showable (forall b. (forall a. Show a => a -> b) -> b)
showable x = Showable (\f -> f x)
f :: Showable -> String
f showable = case showable of
...Consider the following program.
```haskell
{-# LANGUAGE RankNTypes #-}
data Showable = Showable (forall b. (forall a. Show a => a -> b) -> b)
showable x = Showable (\f -> f x)
f :: Showable -> String
f showable = case showable of
Showable f -> let k x = show x in f k
```
While this program compiles in GHC, our frontend rejects it with the following error message.
```
Ambiguous type variable _17
in type Prelude.Show _17 => Showable -> [Prelude.Char]
inferred for equation
f showable =
case showable of
Showable f -> let k x = show x in f k
```Jan-Hendrik MatthesJan-Hendrik Mattheshttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/73Fix pretty printing of OPTIONS pragma2020-02-12T13:02:23ZFinn TeegenFix pretty printing of OPTIONS pragmaA pragma like `{-# OPTIONS_FRONTEND -ddump-all #-}` is pretty-printed as `{-# OPTIONS _FRONTEND -ddump-all #-}`.A pragma like `{-# OPTIONS_FRONTEND -ddump-all #-}` is pretty-printed as `{-# OPTIONS _FRONTEND -ddump-all #-}`.https://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/52Check if position information is missing if the usage of a minus is ambiguous2019-10-28T10:05:19ZKai ProttCheck if position information is missing if the usage of a minus is ambiguoushttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/41Error when compiling a class definition with `NoImplicitPrelude`2019-10-07T16:20:36ZJan-Hendrik MatthesError when compiling a class definition with `NoImplicitPrelude`Compiling the following Curry program with the frontend
```haskell
{-# LANGUAGE NoImplicitPrelude #-}
class A a where
funA :: a -> a
```
produces the following error message.
```
curry-frontend: Internal error: Dictionary.funType Q...Compiling the following Curry program with the frontend
```haskell
{-# LANGUAGE NoImplicitPrelude #-}
class A a where
funA :: a -> a
```
produces the following error message.
```
curry-frontend: Internal error: Dictionary.funType QualIdent {qidSpanInfo = SpanInfo {srcSpan = Span {file = "", start = NoPos, end = NoPos}, srcInfoPoints = []}, qidModule = Just (ModuleIdent {midSpanInfo = NoSpanInfo, midQualifiers = ["Prelude"]}), qidIdent = Ident {idSpanInfo = NoSpanInfo, idName = "error", idUnique = 0}}
```
The problem is a result of the default implementation of the class method `funA`, which uses the `error` function from the `Prelude`. But the `Prelude` is not available due to the language extension `NoImplicitPrelude`.https://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/32Show an error when desugaring of language constructs fails2019-11-08T17:14:00ZKai ProttShow an error when desugaring of language constructs failsThe frontend throws an internal error when de-sugaring something to a function that is not in scope.
This can happen if the Prelude is not imported entirely (or not at all via NoImplicitPrelude).The frontend throws an internal error when de-sugaring something to a function that is not in scope.
This can happen if the Prelude is not imported entirely (or not at all via NoImplicitPrelude).