curry-frontend issueshttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues2020-11-19T16:30:10Zhttps://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/55Document derive transformation2019-10-28T10:14:16ZKai ProttDocument derive transformationIn `Transformations.Derive`In `Transformations.Derive`https://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/54Document module headers2019-10-28T10:12:47ZKai ProttDocument module headers* [ ] `Base.AnnotExpr`
* [ ] `Base.PrettyKinds`
* [ ] `Base.PrettyTypes`
* [ ] `CondCompile`
* [ ] `Il.Typing`
* [ ] `Transformations.Derive`
* [ ] `Transformations.Dictionary`* [ ] `Base.AnnotExpr`
* [ ] `Base.PrettyKinds`
* [ ] `Base.PrettyTypes`
* [ ] `CondCompile`
* [ ] `Il.Typing`
* [ ] `Transformations.Derive`
* [ ] `Transformations.Dictionary`https://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/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/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/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/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/41Error when compiling a class definition with `NoImplicitPrelude`2019-10-07T16:20:36ZJan-Hendrik MatthesError when compiling a class definition with `NoImplicitPrelude`Compiling the following Curry program with the frontend
```haskell
{-# LANGUAGE NoImplicitPrelude #-}
class A a where
funA :: a -> a
```
produces the following error message.
```
curry-frontend: Internal error: Dictionary.funType Q...Compiling the following Curry program with the frontend
```haskell
{-# LANGUAGE NoImplicitPrelude #-}
class A a where
funA :: a -> a
```
produces the following error message.
```
curry-frontend: Internal error: Dictionary.funType QualIdent {qidSpanInfo = SpanInfo {srcSpan = Span {file = "", start = NoPos, end = NoPos}, srcInfoPoints = []}, qidModule = Just (ModuleIdent {midSpanInfo = NoSpanInfo, midQualifiers = ["Prelude"]}), qidIdent = Ident {idSpanInfo = NoSpanInfo, idName = "error", idUnique = 0}}
```
The problem is a result of the default implementation of the class method `funA`, which uses the `error` function from the `Prelude`. But the `Prelude` is not available due to the language extension `NoImplicitPrelude`.https://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/13Erweiterung der Cabal-Testsuite2018-12-06T14:29:57ZFinn TeegenErweiterung der Cabal-TestsuiteDie bisherigen Testfälle sollten noch sinnvoll erweitert werden.
Hierbei könnte man sich beispielsweise an den Tests für den ExportCheck orientieren und entsprechende Testfälle für die anderen Überprüfungen des Frontends entwickeln.Die bisherigen Testfälle sollten noch sinnvoll erweitert werden.
Hierbei könnte man sich beispielsweise an den Tests für den ExportCheck orientieren und entsprechende Testfälle für die anderen Überprüfungen des Frontends entwickeln.https://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/27Extend support for disabling optimizations2018-12-17T10:36:33ZKai ProttExtend support for disabling optimizationsAdd options to disable inlining, etc.Add options to disable inlining, etc.https://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/62Extend WarnCheck2022-03-01T18:22:21ZKai ProttExtend WarnCheckshadowing, etc.shadowing, etc.https://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 #-}`.https://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/65Fully implement the C preprocessor2019-11-15T12:45:57ZKai ProttFully implement the C preprocessorCurrently only `#define` `#ifdef`, ... are supported, but not `#include`Currently only `#define` `#ifdef`, ... are supported, but not `#include`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/20Generate warnings for unused imports2022-03-02T14:35:57ZFinn TeegenGenerate warnings for unused importsThe frontend should detect unused imports and give a warning if there are imported modules or explicitly imported functions that are neither used nor reexported.The frontend should detect unused imports and give a warning if there are imported modules or explicitly imported functions that are neither used nor reexported.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/14Implement further simplifications2018-12-06T14:29:57ZFinn TeegenImplement further simplifications- Case-of-case
- Case-of-constructor
- Case-of-literal
- Inlining of ```let```-bindings
- ```let```-floating?- Case-of-case
- Case-of-constructor
- Case-of-literal
- Inlining of ```let```-bindings
- ```let```-floating?https://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/17Improve type error messages2018-12-06T14:29:57ZFinn TeegenImprove type error messagesExtend error messages of the type checker (and maybe others, too) with the origin of the inferred types in case of a type conflict.Extend error messages of the type checker (and maybe others, too) with the origin of the inferred types in case of a type conflict.