curry-frontend issueshttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues2023-11-16T13:41:35Zhttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/139No Prelude import for lists and apply2023-11-16T13:41:35ZMichael HanusNo Prelude import for lists and applyThe FlatCurry of the following program use lists and the operation `Prelude.apply`:
```
f = []
ap g x = g x
```
However, the Prelude does not occur in the import list.The FlatCurry of the following program use lists and the operation `Prelude.apply`:
```
f = []
ap g x = g x
```
However, the Prelude does not occur in the import list.Kai ProttKai Protthttps://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/131Recursive module imports cause confusing error messages2023-05-26T08:59:58ZLeif-Erik KrügerRecursive module imports cause confusing error messagesConsider the following module `M`:
```haskell
module M where
import M
```
Compiling this module with PAKCS 3.2.0 (or 3.4.1-b6) causes the following error message, which does not point towards the actual error:
```
Error:
Could not...Consider the following module `M`:
```haskell
module M where
import M
```
Compiling this module with PAKCS 3.2.0 (or 3.4.1-b6) causes the following error message, which does not point towards the actual error:
```
Error:
Could not inspect modification time of file
".curry/pakcs-3.2.0/M.icurry"
ERROR occurred during parsing!
```
Interestingly, there seems to be an error message especially for this case in `errCyclicImport` in the `Interfaces` module, but for some reason, the error `errModificationTime` from the `CurryBuilder` module is reported instead.Fredrik WieczerkowskiFredrik Wieczerkowskihttps://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/129Constraints with Type Variables Applied to Multiple Types Cause Illegal Class...2021-07-06T09:51:49ZLeif-Erik KrügerConstraints with Type Variables Applied to Multiple Types Cause Illegal Class Constraint ErrorsThe function
```haskell
f :: Eq (a Bool Bool) => a Bool Bool -> a Bool Bool -> Bool
f = (==)
```
should be accepted by PAKCS, but the following error message is reported:
```
Illegal class constraint Eq (a Bool Bool)
Constrain...The function
```haskell
f :: Eq (a Bool Bool) => a Bool Bool -> a Bool Bool -> Bool
f = (==)
```
should be accepted by PAKCS, but the following error message is reported:
```
Illegal class constraint Eq (a Bool Bool)
Constraints must be of the form C u or C (u t1 ... tn),
where C is a type class, u is a type variable and t1, ..., tn are types.
|
1 | f :: Eq (a Bool Bool) => a Bool Bool -> a Bool Bool -> Bool
| ^^
```
This error is caused by the function `rootType`, which is a subfunction of `checkConstraint`:
```haskell
checkConstraint :: Constraint -> TSCM Constraint
checkConstraint c@(Constraint spi qcls ty) = do
checkClass False qcls
ty' <- checkType ty
unless (isVariableType $ rootType ty') $ report $ errIllegalConstraint c
return $ Constraint spi qcls ty'
where
rootType (ApplyType _ ty' _) = ty'
rootType ty' = ty'
```
`rootType` is not defined recursively and only removes a single `ApplyType`, which means that type variables that are applied to multiple types are not identified as type variables. For example, `a Bool Bool` is represented in the AST by `ApplyType (ApplyType (VariableType "a") (ConstructorType "Bool")) (ConstructorType "Bool")` (simplified), so `rootType` returns `ApplyType (VariableType "a") (ConstructorType "Bool")`, which is not identified as a type variable by `isVariableType`.Leif-Erik KrügerLeif-Erik Krügerhttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/128Tuple Constructors in Interface Instance Declarations Cause Illegal Instance ...2021-07-01T11:25:35ZLeif-Erik KrügerTuple Constructors in Interface Instance Declarations Cause Illegal Instance Type ErrorsConsider the following module:
```haskell
module TupleConstructorInstance where
class C a where
methodC :: a Bool Bool
instance C (,) where
methodC = (True, False)
testExp :: (Bool, Bool)
testExp = methodC
```
Compiling this mod...Consider the following module:
```haskell
module TupleConstructorInstance where
class C a where
methodC :: a Bool Bool
instance C (,) where
methodC = (True, False)
testExp :: (Bool, Bool)
testExp = methodC
```
Compiling this module works without problems, but using it interactively in PAKCS causes an `Illegal instance type` error:
```
TupleConstructorInstance> testExp
Tests/.curry/pakcs-3.2.0/TupleConstructorInstance.icurry:8:12-8:14 Error:
Illegal instance type (,)
The instance type must be of the form (T u_1 ... u_n),
where T is not a type synonym and u_1, ..., u_n are
mutually distinct, non-anonymous type variables.
|
8 | instance C (,) {
| ^^^
ERROR occurred during parsing!
```
The cause of this error is the `checkTypeConstructor` function in the interface syntax check (only the first part of it is displayed here):
```haskell
checkTypeConstructor :: SpanInfo -> QualIdent -> ISC TypeExpr
checkTypeConstructor spi tc = do
tyEnv <- getTypeEnv
case qualLookupTypeKind tc tyEnv of
[] | not (isQualified tc) -> return $ VariableType spi $ unqualify tc
| otherwise -> do
report $ errUndefinedType tc
return $ ConstructorType spi tc
```
Unlike its counterpart `checkType` in the type syntax check, `checkTypeConstructor` does not have a special case for tuple constructors. You can see the `isQTupleId tc` guard of the `checkType` function here:
```haskell
checkType :: TypeExpr -> TSCM TypeExpr
checkType c@(ConstructorType spi tc) = do
m <- getModuleIdent
tEnv <- getTypeEnv
case qualLookupTypeKind tc tEnv of
[]
| isQTupleId tc -> return c
| not (isQualified tc) -> return $ VariableType spi $ unqualify tc
| otherwise -> report (errUndefinedType tc) >> return c
```
This missing guard in `checkTypeConstructor` means that the instance type `(,)` is identified as a type variable in the interface syntax check. Type variables are not allowed as instance types however, therefore an `Illegal instance type` error is reported.Leif-Erik KrügerLeif-Erik Krügerhttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/127Tuple Constructors in Interface Instance Declarations Cause Illegal Instance ...2021-07-06T09:52:08ZLeif-Erik KrügerTuple Constructors in Interface Instance Declarations Cause Illegal Instance Type ErrorsConsider the following module:
```haskell
module TupleConstructorInstance where
class C a where
methodC :: a Bool Bool
instance C (,) where
methodC = (True, False)
testExp :: (Bool, Bool)
testExp = methodC
```
Compiling this mod...Consider the following module:
```haskell
module TupleConstructorInstance where
class C a where
methodC :: a Bool Bool
instance C (,) where
methodC = (True, False)
testExp :: (Bool, Bool)
testExp = methodC
```
Compiling this module works without problems, but using it interactively in PAKCS causes an `Illegal instance type` error:
```
TupleConstructorInstance> testExp
Tests/.curry/pakcs-3.2.0/TupleConstructorInstance.icurry:8:12-8:14 Error:
Illegal instance type (,)
The instance type must be of the form (T u_1 ... u_n),
where T is not a type synonym and u_1, ..., u_n are
mutually distinct, non-anonymous type variables.
|
8 | instance C (,) {
| ^^^
ERROR occurred during parsing!
```
The cause of this error is the `checkTypeConstructor` function in the interface syntax check (only the first part of it is displayed here):
```haskell
checkTypeConstructor :: SpanInfo -> QualIdent -> ISC TypeExpr
checkTypeConstructor spi tc = do
tyEnv <- getTypeEnv
case qualLookupTypeKind tc tyEnv of
[] | not (isQualified tc) -> return $ VariableType spi $ unqualify tc
| otherwise -> do
report $ errUndefinedType tc
return $ ConstructorType spi tc
```
Unlike its counterpart `checkType` in the type syntax check, `checkTypeConstructor` does not have a special case for tuple constructors. You can see the `isQTupleId tc` guard of the `checkType` function here:
```haskell
checkType :: TypeExpr -> TSCM TypeExpr
checkType c@(ConstructorType spi tc) = do
m <- getModuleIdent
tEnv <- getTypeEnv
case qualLookupTypeKind tc tEnv of
[]
| isQTupleId tc -> return c
| not (isQualified tc) -> return $ VariableType spi $ unqualify tc
| otherwise -> report (errUndefinedType tc) >> return c
```
This missing guard in `checkTypeConstructor` means that the instance type `(,)` is identified as a type variable in the interface syntax check. Type variables are not allowed as instance types however, therefore an `Illegal instance type` error is reported.Leif-Erik KrügerLeif-Erik Krügerhttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/123Type-annotated FlatCurry is not generated if it is the only target2020-12-14T11:08:23ZFinn TeegenType-annotated FlatCurry is not generated if it is the only targetFinn TeegenFinn Teegenhttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/121Missing Data context for non-linear as-patterns2020-12-10T13:26:19ZFinn TeegenMissing Data context for non-linear as-patternsConsider the function `f x@(Just _) x = ()`. Its inferred type should be `f :: Data a => Maybe a -> Maybe a -> ()`, however, it is `f :: Maybe a -> Maybe a -> ()`.Consider the function `f x@(Just _) x = ()`. Its inferred type should be `f :: Data a => Maybe a -> Maybe a -> ()`, however, it is `f :: Maybe a -> Maybe a -> ()`.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/117Wrong desugaring of type synonyms2020-11-29T19:40:01ZFinn TeegenWrong desugaring of type synonymsThe program
```
type A _ _ c = c
f = error "" :: A x x y
```
gets desugared to
```
type A _ _ c = c
f = error "" :: x
```
while the local type signature should be `:: y`. This is due to the double occurence of the variable `x` that is...The program
```
type A _ _ c = c
f = error "" :: A x x y
```
gets desugared to
```
type A _ _ c = c
f = error "" :: x
```
while the local type signature should be `:: y`. This is due to the double occurence of the variable `x` that is not handled properly.https://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/115Remove type synonyms completely in desugaring2020-11-29T19:40:00ZFinn TeegenRemove type synonyms completely in desugaringCurrently, type synonyms remain in data constructor declarations (while they get properly replaced in signatures). Concerning that FC should not contain type synonyms anymore, desugaring should get rid of them.
Note that the dictionary ...Currently, type synonyms remain in data constructor declarations (while they get properly replaced in signatures). Concerning that FC should not contain type synonyms anymore, desugaring should get rid of them.
Note that the dictionary transformation performs this task at the moment. However, it is merely a side effect and does generally not belong in that phase. Moreover, having no type synonyms at all after desugaring simplifies all subsequent phases (including the dictionary transformation that currently has to deal with synonyms).https://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/113Frontend crash during parsing2020-11-26T20:50:18ZFinn TeegenFrontend crash during parsingAny error during parsing leads to a crash of the frontend with the error message `pakcs-frontend: Prelude.!!: index too large`.Any error during parsing leads to a crash of the frontend with the error message `pakcs-frontend: Prelude.!!: index too large`.Fredrik WieczerkowskiFredrik Wieczerkowskihttps://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/102Fix error message for explicitly derived Data2020-11-19T16:25:50ZFredrik WieczerkowskiFix error message for explicitly derived DataExplicitly deriving `Data` currently generates an incorrect span in the error message:
```haskell
data X = X deriving (Data)
```
```
Error:
Instances of type class `Prelude.Data' cannot be derived
|
1 | interface Prelude where...Explicitly deriving `Data` currently generates an incorrect span in the error message:
```haskell
data X = X deriving (Data)
```
```
Error:
Instances of type class `Prelude.Data' cannot be derived
|
1 | interface Prelude where {
| ^^^^^^^^^^^^
```https://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/101Deriving fails for empty data types2020-11-23T13:00:04ZFinn TeegenDeriving fails for empty data typesWhen trying to compile a program like
```
data A
```
the compiler fails with the following error message.
```
pakcs-frontend: Prelude.head: empty list
```
This is most likely due to the current way of generating the equations for binary ...When trying to compile a program like
```
data A
```
the compiler fails with the following error message.
```
pakcs-frontend: Prelude.head: empty list
```
This is most likely due to the current way of generating the equations for binary operations (in this case the generation of the equations of the `Data` class; for all other classes the DeriveCheck should throw an error that classes can't be derived for abstract data types). The obvious solution would be to add an additional check in the DeriveTransformation (see `hasDataInstance`) to rule out abstract data types.Finn TeegenFinn Teegenhttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/100Prelude is not imported in FCY2020-11-17T18:48:46ZMichael HanusPrelude is not imported in FCYTry the following program:
head (x:_) = x
The Prelude is not imported in the generated FCYTry the following program:
head (x:_) = x
The Prelude is not imported in the generated FCYhttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/99Fix generation of AbstractCurry2020-11-17T17:17:23ZMichael HanusFix generation of AbstractCurryThe new frontend generates .acy files which are different (buggy)
compared to the previous version. Type declarations have the following
structure in AbstractCurry (version 2.0), see `AbstractCurry.Types`
in package `abstract-curry`:
...The new frontend generates .acy files which are different (buggy)
compared to the previous version. Type declarations have the following
structure in AbstractCurry (version 2.0), see `AbstractCurry.Types`
in package `abstract-curry`:
data CTypeDecl
= CType QName CVisibility [CTVarIName] [CConsDecl] [QName]
| CTypeSyn QName CVisibility [CTVarIName] CTypeExpr
| CNewType QName CVisibility [CTVarIName] CConsDecl [QName]
deriving (Eq, Show)
Consider the following minimal program:
data List = Empty
PAKCS/KiCS2 version generates the following acy file for this program:
{- AbstractCurry 2.0 -}
CurryProg "T"
["Prelude"]
Nothing
[]
[]
[CType ("T","List") Public [] [CCons [] (CContext []) ("T","Empty") Public []] []]
[]
[]
Unfortunately, the current frontend produces the following acy file:
{- AbstractCurry 2.0 -}
CurryProg "T"
[]
Nothing
[]
[]
[CType ("T","List") Public [] [CCons ("T","Empty") Public []] []]
[]
[]
As a consequence, many important Curry tools (CurryCheck, CurryDoc,
CurryPP) required for a basic Curry system do not work in
the new version!Finn TeegenFinn Teegen