curry-frontend issueshttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues2024-02-15T22:09:21Zhttps://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/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/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/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/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/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/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/116Refactor to distinguish Decl and LocalDecl2020-11-29T16:54:52ZFinn TeegenRefactor to distinguish Decl and LocalDeclhttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/114Avoid pattern matching on () for dictionaries2020-11-27T15:29:04ZFinn TeegenAvoid pattern matching on () for dictionariesThe current augmentation introduces `()` arguments on which is pattern matched. This causes additional `case` expressions to be generated. We should avoid that. The same applies for the new method coming with a fix for #109.The current augmentation introduces `()` arguments on which is pattern matched. This causes additional `case` expressions to be generated. We should avoid that. The same applies for the new method coming with a fix for #109.Finn TeegenFinn Teegenhttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/111Cleanup frontend targets2020-11-25T11:09:51ZFinn TeegenCleanup frontend targetshttps://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/107Check which information of instances needs to be considered2020-11-25T11:13:02ZFinn TeegenCheck which information of instances needs to be consideredCurrently, the instance environment contains all implemented instance methods along with their arities. However, it seems as if the information about the arity is no longer needed. Only the interface check seems to compare the arities. F...Currently, the instance environment contains all implemented instance methods along with their arities. However, it seems as if the information about the arity is no longer needed. Only the interface check seems to compare the arities. Furthermore, there is a remark in the deriving check and the deriving transformation stating that the later generated instances have to match the arity entered in the instance environment. It is not clear whether this is still true.
Considering that the implemented methods in an instance do not affect the interface of a module, it might be unnecessary at all to save the implemented methods in the instance environment.https://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/106Unqualify built-in types2020-11-27T15:27:40ZFinn TeegenUnqualify built-in typesFinn TeegenFinn Teegenhttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/105Add option to disable automatic deriving of Data2020-11-20T10:01:21ZFinn TeegenAdd option to disable automatic deriving of DataFinn TeegenFinn Teegenhttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/104Do not exceed 80 characters in frontend messages2020-11-19T16:30:10ZFinn TeegenDo not exceed 80 characters in frontend messagesSome error or warning messages exceed the 80 character limit. This behavior results in difficult to read messages in standard terminal windows.Some error or warning messages exceed the 80 character limit. This behavior results in difficult to read messages in standard terminal windows.https://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/103Add support for EmptyDataDeriving2020-11-19T16:28:29ZFinn TeegenAdd support for EmptyDataDerivingAs a fix for #101 will most likely result in a general support for empty data type deriving, this feature could also be made available via a language extension.As a fix for #101 will most likely result in a general support for empty data type deriving, this feature could also be made available via a language extension.Fredrik WieczerkowskiFredrik Wieczerkowskihttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/98Set Haskell case mode as default2020-11-11T20:23:00ZFinn TeegenSet Haskell case mode as defaultFinn TeegenFinn Teegenhttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/95Emit colored messages2020-10-29T15:33:01ZFredrik WieczerkowskiEmit colored messagesIt would be nice to have GHC-style colored error and warning messages:
![image](/uploads/5ad3843ffebff82130135f1f7a6c84f9/image.png)
Emitting these requires using an ANSI color library, for example [`ansi-terminal`](https://hackage.has...It would be nice to have GHC-style colored error and warning messages:
![image](/uploads/5ad3843ffebff82130135f1f7a6c84f9/image.png)
Emitting these requires using an ANSI color library, for example [`ansi-terminal`](https://hackage.haskell.org/package/ansi-terminal).
It would, however, be preferable to have color support directly in the pretty printing library rather than just including raw ANSI escape sequences as text. There are a bunch of options here, but none of them really are a fitting 'drop-in-replacement' for the currently used pretty printer:
* **Hughes/PJ pretty printers**:
* [`pretty`](https://hackage.haskell.org/package/pretty) is currently used and does not support ANSI coloring
* **Wadler/Leijen pretty printers**:
* [`ansi-wl-pprint`](https://hackage.haskell.org/package/ansi-wl-pprint) has ANSI coloring support, but [may get deprecated](https://github.com/ekmett/ansi-wl-pprint/issues/18)
* [`ansi-pretty`](https://hackage.haskell.org/package/ansi-pretty) is an extension of `ansi-wl-pprint`
* [`prettyprinter`](https://hackage.haskell.org/package/prettyprinter) is modern and supports ANSI coloring, but uses `Data.Text` instead of `String`
Additionally, Wadler/Leijen pretty printers have a lot of subtle differences in their API compared to Hughes/PJ printers, thereby complicating a potential migration. This includes many of them providing their own `Pretty` class.https://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/94Remove double errors2020-10-30T12:22:32ZFinn TeegenRemove double errorsConsider the following function.
```
mTestFunction :: Int
mTestFunction = length [unknown]
```
The frontend yields the following errors.
```
Test.curry:2:1-2:32 Error:
Ambiguous type variable _4
in type Prelude.Data _4 => Prel...Consider the following function.
```
mTestFunction :: Int
mTestFunction = length [unknown]
```
The frontend yields the following errors.
```
Test.curry:2:1-2:32 Error:
Ambiguous type variable _4
in type Prelude.Data _4 => Prelude.Int
inferred for equation
mTestFunction = length [unknown]
|
2 | mTestFunction = length [unknown]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Test.curry:2:1-2:32 Error:
Ambiguous type variable _4
in type Prelude.Data _4 => Prelude.Int
inferred for function `mTestFunction'
|
2 | mTestFunction = length [unknown]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ERROR occurred during parsing!
```
As both errors refer to the same issue (even with the same spans), one error should not be raised.https://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/92Provide quick fixes for error/warning messages2024-02-15T21:06:11ZFredrik WieczerkowskiProvide quick fixes for error/warning messages### Idea
Attach recommended fixes to error/warning messages that can be solved "easily", e.g.:
* Unused variables/type parameters/imports
* This could have multiple 'fixes':
* Remove the variable
* Rename the variable to `_` ...### Idea
Attach recommended fixes to error/warning messages that can be solved "easily", e.g.:
* Unused variables/type parameters/imports
* This could have multiple 'fixes':
* Remove the variable
* Rename the variable to `_` in the case of parameters
* Prefix the variable with `_` if #135 were to be implemented etc.
* Duplicate imports
* Required (but undeclared) language extensions
* Redundant (implied) language extensions
* Missing top-level type signatures
* Uninitialized record fields (see #125)
* Unused do-bindings (see #134)
* Migrations in the case of source breaks (e.g. if #135 were to be implemented)
* Case mode rename suggestions
* etc.
### Motivation
Having a unified solution for attaching fixes to a message, would make it easy to emit messages like this one from GHC:
```haskell
import Prelude (True)
```
```
src/ImportSyntaxCheck/ImportDataConstr.hs:1:17: error:
In module ‘Prelude’:
‘True’ is a data constructor of ‘Bool’
To import it use
import Prelude( Bool( True ) )
or
import Prelude( Bool(..) )
|
1 | import Prelude (True)
| ^^^^
```
This would also enable downstream features like [language server support](https://github.com/fwcd/curry-language-server/issues/10) for fixable errors and subsequently improve the editing experience for Curry in LSP-supporting editors, as in this Rust example:
![Screenshot](/uploads/912a320592c563c3a30602094f761645/Screenshot_from_2020-06-10_21-00-52.png)