curry-frontend issueshttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues2020-12-09T09:23:14Zhttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/120Add check for empty contexts for external functions2020-12-09T09:23:14ZFinn TeegenAdd check for empty contexts for external functionshttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/122Generate aValue using overlapping rules instead of ? operator2020-12-11T14:53:04ZFinn TeegenGenerate aValue using overlapping rules instead of ? operatorFinn TeegenFinn Teegenhttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/124Emit an AST even if errors occur during semantic analysis2021-03-26T00:19:01ZFredrik WieczerkowskiEmit an AST even if errors occur during semantic analysisCurrently, the Curry compiler monad (`CYT` for the transformer variant and `CYM` for the IO-based variant) implements warning messages using a `WriterT` and error messages using an `ExceptT`.
This, however, prevents tools like the Curry...Currently, the Curry compiler monad (`CYT` for the transformer variant and `CYM` for the IO-based variant) implements warning messages using a `WriterT` and error messages using an `ExceptT`.
This, however, prevents tools like the Curry language server from taking advantage of the 'broken' AST, which may still be syntactically correct, e.g. for features like context-aware code completion as the user types.
It would therefore be nice to have at least a `Maybe`-wrapped version of the AST if parsing succeeds, but one of the semantic checks fails.https://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/125Emit a warning for non-fully-initialized records2021-04-21T09:16:35ZFredrik WieczerkowskiEmit a warning for non-fully-initialized recordsNon-initialized record fields make it easy to accidentally introduce nondeterminism. Consider the following Curry example, which emits no warnings or errors:
```haskell
data X = X { n :: Int, m :: Bool }
mkX :: X
mkX = X { n = 3 }
tes...Non-initialized record fields make it easy to accidentally introduce nondeterminism. Consider the following Curry example, which emits no warnings or errors:
```haskell
data X = X { n :: Int, m :: Bool }
mkX :: X
mkX = X { n = 3 }
test :: Bool
test = not $ m mkX -- whoops
```
Since uninitialized fields (like `m` in this case) are interpreted as free variables in Curry, `test` evaluates to `False` and `True` nondeterministically.
Even if this is what the user intends, making it explicit might be better style:
```haskell
data X = X { n :: Int, m :: Bool }
mkX :: X
mkX = X { n = 3, m = m' }
where m' free
test :: Bool
test = not $ m mkX -- whoops
```
It would therefore be nice to have a warning message, perhaps similar to the one that GHC emits:
```
NonFullyInitializedRecord.hs:4:7: warning: [-Wmissing-fields]
• Fields of ‘X’ not initialised:
m :: Int
• In the expression: X {n = 3}
In an equation for ‘mkX’: mkX = X {n = 3}
|
4 | mkX = X { n = 3 }
|
```
If #92 would get integrated at some point, the compiler could potentially generate a quick fix for making the free fields explicit, similar to the example above.https://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/126Add hint to overloading errors2021-04-21T09:24:49ZMichael HanusAdd hint to overloading errorsThe definition
main = snd (x, True) where x free
produces the following error message:
Ambiguous type variable _3
in type Prelude.Data _3 => Prelude.Bool
Since this is difficult to understand for newbies, maybe the front...The definition
main = snd (x, True) where x free
produces the following error message:
Ambiguous type variable _3
in type Prelude.Data _3 => Prelude.Bool
Since this is difficult to understand for newbies, maybe the front end
can add a hint for such cases, i.e., when a type variable is ambiguous
but does not occur in the top-level type expression. E.g.:
Hint: add type annotation to local variable or declarationhttps://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/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/134Emit warnings about unused do-bindings2022-03-03T15:17:01ZFredrik WieczerkowskiEmit warnings about unused do-bindingsIt would be nice if unused do-bindings (i.e. non-unit values) such as `getLine` in
```curry
unused :: IO ()
unused = do
getLine
return ()
```
would emit a warning similar to GHC (with `-Wall`):
```
UnusedDo.hs:5:3: warning: [-Wunu...It would be nice if unused do-bindings (i.e. non-unit values) such as `getLine` in
```curry
unused :: IO ()
unused = do
getLine
return ()
```
would emit a warning similar to GHC (with `-Wall`):
```
UnusedDo.hs:5:3: warning: [-Wunused-do-bind]
A do-notation statement discarded a result of type ‘String’
Suppress this warning by saying ‘_ <- getLine’
|
5 | getLine
| ^^^^^^^
```
This would also be a good candidate for a quick fix as proposed in #92.
Related: #62.https://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/135Idea: Allow underscore-prefixed identifiers2022-03-03T15:16:22ZFredrik WieczerkowskiIdea: Allow underscore-prefixed identifiersIn Haskell, prefixing an identifier with an underscore is allowed. E.g. the following snippet compiles in Haskell, but not in Curry:
```curry
_test :: Int
_test = 3
```
```
Anonymous.curry:3:2 Error:
Unexpected token identifier `te...In Haskell, prefixing an identifier with an underscore is allowed. E.g. the following snippet compiles in Haskell, but not in Curry:
```curry
_test :: Int
_test = 3
```
```
Anonymous.curry:3:2 Error:
Unexpected token identifier `test'
|
3 | _test :: Int
| ^
```
Such identifiers could be useful for a variety of reasons:
- In Haskell, a common pattern is to name the implementation of a function (possibly taking additional parameters) `_f` and the exported, public interface function `f`
- In Haskell, underscore-prefixed identifiers can be used to silence warnings about unused parameters. This could be useful if a parameter is explicitly to be marked as unused, but still assigned a name. For example:
```curry
const :: a -> b -> a
const x _y = y
```
would not emit a warning in Haskell. There is an additional challenge that this example shows, however:
**Allowing underscore-prefixed identifiers is a breaking change**, since the current Curry parser reads the function above as
```curry
const x _ y = y
```
(and thus throws a type error). If we were to implement a change that allows such identifiers, e.g. the following snippet would no longer be valid Curry:
```curry
const2 :: a -> b -> c -> a
const2 x _y = x
```
Same goes for the (currently) equivalent spelling
```curry
const2 :: a -> b -> c -> a
const2 x __ = x
```
While such formatting is usually considered unidiomatic, if we were to implement this feature, we should detect such cases and emit a descriptive error message along with a fix to rewrite the function as:
```curry
const2 x _ _ = x
```https://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/136Idea: Support shebangs in Curry source files2022-06-17T18:41:44ZFredrik WieczerkowskiIdea: Support shebangs in Curry source filesGHC allows a shebang line (starting with `#!`) to appear at the beginning of a Haskell source file, making it convenient to write directly executable scripts in Haskell. For example, writing the following is allowed:
```haskell
#!/usr/b...GHC allows a shebang line (starting with `#!`) to appear at the beginning of a Haskell source file, making it convenient to write directly executable scripts in Haskell. For example, writing the following is allowed:
```haskell
#!/usr/bin/env runhaskell
main = putStrLn "Hello world!"
```
For a hypothetical `runcurry` (or `runpakcs`/`runkics2`) tool it would be nice if the Curry frontend could similarly allow the user to write a single line starting with `#!` at the beginning of a source file (and just ignore it).https://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/138Default all type variables2023-07-26T16:17:34ZKai ProttDefault all type variablesCurrently not all type variables occurring in a flat curry expression are bound in the type of the surrounding function declaration.
Consider the following example:
```haskell
test = length []
```
Here, both `length` and `[]` will be ty...Currently not all type variables occurring in a flat curry expression are bound in the type of the surrounding function declaration.
Consider the following example:
```haskell
test = length []
```
Here, both `length` and `[]` will be typed with a free type variable.
While the resulting FlatCurry Code is certainly correct, all typed back ends need to default these type variables.
If I remember correctly, KiCS2 does not even do this in all required cases, e.g. when the type variable has a kind different than `Type`/`*`.
We'd like these type variables to be defaulted in the frontend directly.
Currently our idea is to create a new transformation phase on the IL where the AST is traversed and a new data type is created for each unique kind that occurrs in a type variable that needs to be defaulted.
Additionally, each type variable is replaced with the respective type constructor that has been generated.
Note that the generated data types need no constructors. Although it is not possible for a user to write a data type with arbitrary kind but without constructors (all type variables will be phantom and defaulted to `*`), we can generate these data types internally.
I am not sure if and when the frontend adds a dummy constructor to external data types or a data type without constructors, but this should be kept in mind.
Also, all environments should be updated with the new data types and they should not be exported to keep the transformation and compilation local and without name clashes.
@fte @mh @fwcd: Anyone got a better Idea?
@fwcd Do you have time to implement this? Should not be too complicated.
Note that in GHC with `-XPolyKinds`, Just two data types are sufficient for all possible kinds.
```haskell
data Zero
data One (a :: k)
```
In Curry we need:
```haskell
data Zero
data One (a :: *)
data Two (a :: *) (b :: *)
data OneTwo (a :: * -> *) (b :: *)
...
```https://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/142Display diffs in failing tests2024-02-15T20:57:52ZFredrik WieczerkowskiDisplay diffs in failing testsIt would be cool if failing tests, instead of just noting the missing/unexpected message(s) could display a, potentially colored, diff between the actual and the expected message.
Here's a good example of a library that does this well: ...It would be cool if failing tests, instead of just noting the missing/unexpected message(s) could display a, potentially colored, diff between the actual and the expected message.
Here's a good example of a library that does this well: https://github.com/rust-pretty-assertions/rust-pretty-assertionshttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/143Add support for line pragmas2024-02-15T22:09:21ZFredrik WieczerkowskiAdd support for line pragmasGHC, like the C preprocessor, has [support for line pragmas](https://downloads.haskell.org/~ghc/7.0.3/docs/html/users_guide/pragmas.html#line-pragma), which let the user alter the line number and filename in warnings and errors:
```hask...GHC, like the C preprocessor, has [support for line pragmas](https://downloads.haskell.org/~ghc/7.0.3/docs/html/users_guide/pragmas.html#line-pragma), which let the user alter the line number and filename in warnings and errors:
```haskell
{-# LINE 82 "Foo.hs" #-}
f :: Int
f = "abc"
```
```
[1 of 2] Compiling Main ( LinePragma.hs, LinePragma.o )
Foo.hs:83:5: error: [GHC-83865]
• Couldn't match type ‘[Char]’ with ‘Int’
Expected: Int
Actual: String
• In the expression: "abc"
In an equation for ‘f’: f = "abc"
```
For us these pragmas would be primarily of interest in the automatically generated Curry interfaces (`.icurry`) where they could be used to refer to the original source locations. This in turn would be nice to have in the language server, which could accurately map definitions to their original locations in source code, even if the Curry compiler uses a cached interface file.https://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/144-Werror is not respected in OPTIONS_FRONTEND pragmas2024-03-28T01:40:45ZFredrik Wieczerkowski-Werror is not respected in OPTIONS_FRONTEND pragmasPresumably this is because the option is applied at the very top-level where only command-line options are available. Perhaps we could make this work on a module-level, by making sure messages get correctly emitted as warning/error as th...Presumably this is because the option is applied at the very top-level where only command-line options are available. Perhaps we could make this work on a module-level, by making sure messages get correctly emitted as warning/error as they are produced?