curry-frontend issueshttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues2020-11-11T20:23:00Zhttps://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/93Improve spans for error messages2020-10-30T12:28:13ZFinn TeegenImprove spans for error messagesConsider the following program.
```
test = not (f True True)
f :: Bool -> Bool -> String
f _ _ = ""
```
The compiler prints the following (correct) error message when trying to compile the program.
```
1:6-1:24 Error:
Type error in ...Consider the following program.
```
test = not (f True True)
f :: Bool -> Bool -> String
f _ _ = ""
```
The compiler prints the following (correct) error message when trying to compile the program.
```
1:6-1:24 Error:
Type error in application
not (f True True)
Term: (f True True)
Inferred type: [Prelude.Char]
Expected type: Prelude.Bool
Types Prelude.Bool and [Prelude.Char] are incompatible
|
1 | test = not (f True True)
| ^^^^^^^^^^^^^^^^^^^
```
However, the highlighted part seems to be a bit off (or at least starting to early).Fredrik WieczerkowskiFredrik Wieczerkowskihttps://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)https://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/91Update the readme file2020-07-21T07:58:54ZFredrik WieczerkowskiUpdate the readme fileThe readme file in this repository has last been updated 15 years ago and does not accurately reflect more recent versions of the frontend. Possible improvements include:
* Converting the file to UTF-8 (the most widely used text encodin...The readme file in this repository has last been updated 15 years ago and does not accurately reflect more recent versions of the frontend. Possible improvements include:
* Converting the file to UTF-8 (the most widely used text encoding)
* Adding build instructions for Cabal
* Translating the text to English for consistency, since the rest of the repository is kept in English (comments, issues, etc)
* Updating references to `cymake` to `curry-frontend`
* Converting the file to Markdown
* Renaming it to `README(.md/.txt)`, so that GitLab displays it on the repository pagehttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/89Create a cabal.project file and make the build "non-stateful"2020-10-23T16:21:33ZFredrik WieczerkowskiCreate a cabal.project file and make the build "non-stateful"### Problem
Currently, to compile the frontend, the user has to manually clone and install the `curry-base` package, since this project depends on a newer version (1.2.0) than the latest version from Hackage (1.1.1).
### Motivation
Si...### Problem
Currently, to compile the frontend, the user has to manually clone and install the `curry-base` package, since this project depends on a newer version (1.2.0) than the latest version from Hackage (1.1.1).
### Motivation
Since Cabal ist moving towards non-stateful, reproducible builds with version 2 ([see here](https://www.haskell.org/cabal/users-guide/nix-local-build-overview.html)), it would be nice to have this package "just build" when running `cabal v2-build`, without any preliminary steps.
Additionally, a non-stateful build could enable automatic CI builds/deployments, if so desired, in the future.
### Solution
Adding a `cabal.project` file that declares a `source-repository-package` (as introduced by Cabal 2.4, [see here](https://cabal.readthedocs.io/en/latest/nix-local-build.html#specifying-packages-from-remote-version-control-locations)) pointing towards the `curry-base` repository would fix the issue, since Cabal could automatically download and build `curry-base` from source.Fredrik WieczerkowskiFredrik Wieczerkowskihttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/87GHC-like line snippets in warning messages2020-10-20T14:36:14ZFredrik WieczerkowskiGHC-like line snippets in warning messagesCurrently, warning messages only contain an abstract representation of the problem in the user's source code:
```
..\curry-playground\MultiBranch.curry, line 4.5: Warning:
Pattern matches are potentially unreachable
In a case al...Currently, warning messages only contain an abstract representation of the problem in the user's source code:
```
..\curry-playground\MultiBranch.curry, line 4.5: Warning:
Pattern matches are potentially unreachable
In a case alternative:
_ -> ...
```
It would be nice to have a GHC-like message printing the relevant line(s) in the source code:
```
..\curry-playground\MultiBranch.hs:6:5: warning: [-Woverlapping-patterns]
Pattern match is redundant
In a case alternative: _ -> ...
|
6 | _ -> 4
| ^^^^^^
```https://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/86Split multi-branch unreachability warnings2020-10-20T15:29:33ZFredrik WieczerkowskiSplit multi-branch unreachability warningsCurrently, if multiple branches in a case expression are unreachable, a single warning message is emitted:
```haskell
module MultiBranch where
test x = case x of
1 -> 2
_ -> 3
_ -> 4
_ -> 5
_ -> 6
```
```
..\curry-...Currently, if multiple branches in a case expression are unreachable, a single warning message is emitted:
```haskell
module MultiBranch where
test x = case x of
1 -> 2
_ -> 3
_ -> 4
_ -> 5
_ -> 6
```
```
..\curry-playground\MultiBranch.curry, line 4.5: Warning:
Pattern matches are potentially unreachable
In a case alternative:
_
_
_ -> ...
```
It would be nice, however, to split this up into multiple warning messages to provide accurate line information for each branch:
```
..\curry-playground\MultiBranch.curry, line 6.5: Warning:
Pattern match is potentially unreachable
In a case alternative:
_ -> ...
..\curry-playground\MultiBranch.curry, line 7.5: Warning:
Pattern match is potentially unreachable
In a case alternative:
_ -> ...
..\curry-playground\MultiBranch.curry, line 8.5: Warning:
Pattern match is potentially unreachable
In a case alternative:
_ -> ...
```https://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/84Improve locations when warning for unreachable/overlapping patterns2020-04-01T09:45:24ZFinn TeegenImprove locations when warning for unreachable/overlapping patternsCurrently, the warnings for unreachable/overlapping patterns refer to the position of the first branch of the case expression. However, the position of the warning should refer to the relevant (i.e., the unreachable or overlapping) branc...Currently, the warnings for unreachable/overlapping patterns refer to the position of the first branch of the case expression. However, the position of the warning should refer to the relevant (i.e., the unreachable or overlapping) branch (or maybe the case expression itself in case of overlappings). Consider the following examples.
```
f x = case x of
_ -> False
_ -> True
```
For this file, the front end produces the following warning
```
Test.curry, line 2.3: Warning:
Pattern matches are potentially unreachable
In a case alternative:
_ -> ...
```
while the GHC outputs the following (better) message.
```
Test.hs:3:3: warning: [-Woverlapping-patterns]
Pattern match is redundant
In a case alternative: _ -> ...
|
3 | _ -> True
| ^^^^^^^^^
```
Similarly, the warnings for overlapping patterns should be improved as the following example shows.
```
g x = fcase x of
_ -> False
_ -> True
```
The following message gets printed.
```
Test.curry, line 2.3: Warning:
An fcase expression is potentially non-deterministic due to overlapping rules
```
While the message refers to the fcase expression, the message's location refers to its first branch. It would be better to refer to the position of the case expression itself.Fredrik WieczerkowskiFredrik Wieczerkowskihttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/83Transform type expressions into weak prenex normal form2020-01-31T12:20:38ZFinn TeegenTransform type expressions into weak prenex normal formAll type signatures in FlatCurry should be transformed into weak prenex normal form (see https://www.microsoft.com/en-us/research/publication/practical-type-inference-for-arbitrary-rank-types/ for a definition). As a side effect, all typ...All type signatures in FlatCurry should be transformed into weak prenex normal form (see https://www.microsoft.com/en-us/research/publication/practical-type-inference-for-arbitrary-rank-types/ for a definition). As a side effect, all type variables would become explicitely quantified. The latter will simplify the translation into Haskell considerably, especially when considering the generation of Curry contexts.Kai ProttKai Protthttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/82Reduce dependencies between compilation phases2020-01-28T13:56:00ZFinn TeegenReduce dependencies between compilation phasesCurrently, there are various dependencies between compilation phases, e.g., between the case completion and the translation into the IL, i.e., one phase imports the other to use specific functionality from it. We should reduce these depe...Currently, there are various dependencies between compilation phases, e.g., between the case completion and the translation into the IL, i.e., one phase imports the other to use specific functionality from it. We should reduce these dependencies.https://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/81Parametrize AST with location information2020-01-28T13:53:29ZFinn TeegenParametrize AST with location informationParametrizing the AST with location information via an additional type variable `l` (analogous to the haskell-src-exts) should allow for mapping all location information to `()` and thus reducing the clutter when raw-printing the AST.Parametrizing the AST with location information via an additional type variable `l` (analogous to the haskell-src-exts) should allow for mapping all location information to `()` and thus reducing the clutter when raw-printing the AST.https://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/79Remove TypedFlatCurry format2020-01-28T13:49:38ZFinn TeegenRemove TypedFlatCurry formatIn order to reduce the number of different output formats, we should drop the specialized TypedFlatCurry format.In order to reduce the number of different output formats, we should drop the specialized TypedFlatCurry format.https://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/78Add flag options similar to the GHC2020-01-27T16:56:26ZFinn TeegenAdd flag options similar to the GHCThe GHC supports multiple flags using the `-f` options (see https://downloads.haskell.org/ghc/latest/docs/html/users_guide/flags.html). The front end currently only supports `-f` to force recompilation. Since we plan to add several flags...The GHC supports multiple flags using the `-f` options (see https://downloads.haskell.org/ghc/latest/docs/html/users_guide/flags.html). The front end currently only supports `-f` to force recompilation. Since we plan to add several flags (e.g., for translating free variables to `aValue` calls), the `-f` option should be generalized to support multiple flags (similar to the `-O` option).