curry-frontend issueshttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues2024-03-26T11:11:27Zhttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/141Turn case warnings into errors2024-03-26T11:11:27ZMichael HanusTurn case warnings into errorsIn restricted case modes, like `haskell`, warnings are generated for illegal uppercase/lowercases.
These warning should be turned into errors in order to really enforce the case mode.In restricted case modes, like `haskell`, warnings are generated for illegal uppercase/lowercases.
These warning should be turned into errors in order to really enforce the case mode.Fredrik WieczerkowskiFredrik Wieczerkowskihttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/140Add uppercase/lowercase warnings in default mode2024-03-26T11:11:26ZMichael HanusAdd uppercase/lowercase warnings in default modeUppercase/lowercase warnings that are currently generated in the case mode `haskell` should be generated in the default case mode.
These warnings could be turned off by, e.g., `-W no-haskell-case`.Uppercase/lowercase warnings that are currently generated in the case mode `haskell` should be generated in the default case mode.
These warnings could be turned off by, e.g., `-W no-haskell-case`.Fredrik WieczerkowskiFredrik Wieczerkowskihttps://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/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/137Make option `--extended` default2023-02-06T14:08:59ZMichael HanusMake option `--extended` defaultSince all actual Curry systems compiles programs with option `--extended`, this should be the default as many Curry programs use these extensions. This has also the advantage that the Curry Language Server does not report errors on such ...Since all actual Curry systems compiles programs with option `--extended`, this should be the default as many Curry programs use these extensions. This has also the advantage that the Curry Language Server does not report errors on such programs.
Thus, the options `FunctionalPatterns` and `AnonFreeVars` should be always set and new options `NoFunctionalPatterns` and `NoAnonFreeVars` should be added to enable the old behavior. For compatibility reasons, the option `--extended` should still be allowed.Fredrik WieczerkowskiFredrik Wieczerkowskihttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/133Shadowing of imported symbols does not emit a warning2022-11-22T10:19:40ZFredrik WieczerkowskiShadowing of imported symbols does not emit a warningE.g.
```curry
f :: a -> a
f failed = failed
```
should warn about `Prelude.failed` being shadowed (similar to what GHC does when `-Wall` is enabled), but currently does not. Adding a function whose parameter shadows the (locally define...E.g.
```curry
f :: a -> a
f failed = failed
```
should warn about `Prelude.failed` being shadowed (similar to what GHC does when `-Wall` is enabled), but currently does not. Adding a function whose parameter shadows the (locally defined) function `f`, however, does emit a warning:
```curry
g :: a -> a
g f = f
```
```
.../src/Shadow.curry:9:3 Warning:
Shadowing symbol `f', bound at: .../src/Shadow.curry, line 6.1
|
9 | g f = f
| ^
```
Not sure if this is already covered by #62.https://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/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/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/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/112Remove renaming from type syntax check2020-11-26T17:47:36ZFinn TeegenRemove renaming from type syntax checkThe renaming was necessary when locally quantified type variables could be introduced. As this is no longer the case, the renaming is obsolete.The renaming was necessary when locally quantified type variables could be introduced. As this is no longer the case, the renaming is obsolete.https://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/57Generate TypedFlatCurry via TypeAnnotatedFlatCurry2020-11-24T18:34:02ZKai ProttGenerate TypedFlatCurry via TypeAnnotatedFlatCurryhttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/108Make specialization in dictionary transformation an optional optimization2020-11-23T16:54:00ZFinn TeegenMake specialization in dictionary transformation an optional optimizationThis is very useful for debugging the dictionary transformation.This is very useful for debugging the dictionary transformation.Finn TeegenFinn Teegenhttps://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/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/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 FCY