curry-frontend issueshttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues2020-12-01T10:12:08Zhttps://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/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/96Perform general refactoring2020-11-04T12:04:30ZFredrik WieczerkowskiPerform general refactoringAfter the merge of curry-base in !34, a general refactoring of the modules may be due, e.g. considering that the curry-base hierarchy (now located under `src/Curry/...`) duplicates some functionality of the rest of the frontend.After the merge of curry-base in !34, a general refactoring of the modules may be due, e.g. considering that the curry-base hierarchy (now located under `src/Curry/...`) duplicates some functionality of the rest of the frontend.https://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)https://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/80Translate user's type annotations correctly2020-01-28T13:51:26ZFinn TeegenTranslate user's type annotations correctlyAlthough currently not relevant due to the lack of support for scoped type variables, a user's type annotation should be transformed correctly during the dictionary translation. Currently, any context gets dropped.Although currently not relevant due to the lack of support for scoped type variables, a user's type annotation should be transformed correctly during the dictionary translation. Currently, any context gets dropped.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).https://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/77Type variable escapes when encoding existential types2020-07-13T19:14:55ZFinn TeegenType variable escapes when encoding existential typesConsider the following program.
```haskell
{-# LANGUAGE RankNTypes #-}
data Showable = Showable (forall b. (forall a. Show a => a -> b) -> b)
showable x = Showable (\f -> f x)
f :: Showable -> String
f showable = case showable of
...Consider the following program.
```haskell
{-# LANGUAGE RankNTypes #-}
data Showable = Showable (forall b. (forall a. Show a => a -> b) -> b)
showable x = Showable (\f -> f x)
f :: Showable -> String
f showable = case showable of
Showable f -> let k x = show x in f k
```
While this program compiles in GHC, our frontend rejects it with the following error message.
```
Ambiguous type variable _17
in type Prelude.Show _17 => Showable -> [Prelude.Char]
inferred for equation
f showable =
case showable of
Showable f -> let k x = show x in f k
```Jan-Hendrik MatthesJan-Hendrik Mattheshttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/76Remove type synonyms from FlatCurry2020-01-21T14:36:17ZFinn TeegenRemove type synonyms from FlatCurryhttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/74Drop support for OPTIONS_CYMAKE pragma2019-12-16T21:45:06ZFinn TeegenDrop support for OPTIONS_CYMAKE pragmahttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/73Fix pretty printing of OPTIONS pragma2020-02-12T13:02:23ZFinn TeegenFix pretty printing of OPTIONS pragmaA pragma like `{-# OPTIONS_FRONTEND -ddump-all #-}` is pretty-printed as `{-# OPTIONS _FRONTEND -ddump-all #-}`.A pragma like `{-# OPTIONS_FRONTEND -ddump-all #-}` is pretty-printed as `{-# OPTIONS _FRONTEND -ddump-all #-}`.