curry-frontend issueshttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues2020-11-24T18:34:02Zhttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/57Generate TypedFlatCurry via TypeAnnotatedFlatCurry2020-11-24T18:34:02ZKai ProttGenerate TypedFlatCurry via TypeAnnotatedFlatCurryhttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/53Update `overview.md`2019-11-08T17:14:25ZKai ProttUpdate `overview.md`https://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/33Refactor addition of built-in types to compiler environments2018-12-20T13:19:38ZKai ProttRefactor addition of built-in types to compiler environmentsSome of the compiler environments contain values for all built-in types.
It is unclear, whether or not this is needed everywhere.
Do they have to be qualified with the corresponding original name?
Additionally the types and constructors...Some of the compiler environments contain values for all built-in types.
It is unclear, whether or not this is needed everywhere.
Do they have to be qualified with the corresponding original name?
Additionally the types and constructors are inserted into the generated FlatCurry for the Prelude.
This is not the case for iCurry and AbstractCurry.https://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/30Refactor implicit Prelude-Import2018-12-17T10:54:05ZKai ProttRefactor implicit Prelude-ImportWhen a module does not explicitly import the Prelude, the frontend currently inserts an explicit import into the AST.
This leads to a "wrong" output for the AST-Target.
Instead of adding the Prelude as an Import in the AST, it is suffic...When a module does not explicitly import the Prelude, the frontend currently inserts an explicit import into the AST.
This leads to a "wrong" output for the AST-Target.
Instead of adding the Prelude as an Import in the AST, it is sufficient to add it as an Import in FlatCurry (and AbstractCurry?),
as well as directly enriching all environments with the entities from the Prelude .https://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/29Remove the `ExistentialQuantification` extension2019-05-19T14:57:15ZKai ProttRemove the `ExistentialQuantification` extensionThis includes:
- Simplifying the type schemes
- Removing the `ExistentialQuantification` extension
- Removing support in the parser
- Removing existential quantified type variables and type contexts from the internal data type re...This includes:
- Simplifying the type schemes
- Removing the `ExistentialQuantification` extension
- Removing support in the parser
- Removing existential quantified type variables and type contexts from the internal data type representations
This will be closed with curry/curry-base!11 and !13.Jan-Hendrik MatthesJan-Hendrik Mattheshttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/15Separate compilation of pattern matching and translation into intermediate la...2018-12-06T14:29:57ZFinn TeegenSeparate compilation of pattern matching and translation into intermediate languagehttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/11Remove anonymous labels for data constructors in value environment2018-12-06T14:29:58ZFinn TeegenRemove anonymous labels for data constructors in value environmentWhen a data constructor is entered into the value environment which does not belong to a record type, anonymous labels are created. This seems to be a relict from the MCC where the list of labels is used to determine the arity of a data ...When a data constructor is entered into the value environment which does not belong to a record type, anonymous labels are created. This seems to be a relict from the MCC where the list of labels is used to determine the arity of a data constructor. Since the arity is stored separately, the creation of anonymous labels should no longer be necessary, thus the list of labels can be left empty for normal data constructors.https://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/7Remove addition of Prelude import to AST2018-12-06T14:29:58ZFinn TeegenRemove addition of Prelude import to ASTCurrently, during compilation the AST of a module is extended with a "virtual" import of the `Prelude` module unless the `Prelude` is explicitly imported or the import is deactivated by the `NoImplicitPrelude` language extension.
While ...Currently, during compilation the AST of a module is extended with a "virtual" import of the `Prelude` module unless the `Prelude` is explicitly imported or the import is deactivated by the `NoImplicitPrelude` language extension.
While the consideration of the `Prelude` is important for compilation, the addition to the AST can lead to problems since the AST no longer corresponds to the source program. Thus, this transformation should at least be deferred to the transformation phases.
Involved modules are:
* `Modules`: Contains the function `importPrelude` which should be removed
* `Interfaces`: Contains the function `loadInterfaces` which then has to load the `Prelude` in addition
* `Imports`: Contains the functions `importModules` and `importInterfaces` which then have to load the `Prelude` in additionhttps://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/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/133Shadowing of imported symbols does not emit a warning2022-11-22T10:19:40ZFredrik WieczerkowskiShadowing of imported symbols does not emit a warningE.g.
```curry
f :: a -> a
f failed = failed
```
should warn about `Prelude.failed` being shadowed (similar to what GHC does when `-Wall` is enabled), but currently does not. Adding a function whose parameter shadows the (locally define...E.g.
```curry
f :: a -> a
f failed = failed
```
should warn about `Prelude.failed` being shadowed (similar to what GHC does when `-Wall` is enabled), but currently does not. Adding a function whose parameter shadows the (locally defined) function `f`, however, does emit a warning:
```curry
g :: a -> a
g f = f
```
```
.../src/Shadow.curry:9:3 Warning:
Shadowing symbol `f', bound at: .../src/Shadow.curry, line 6.1
|
9 | g f = f
| ^
```
Not sure if this is already covered by #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/112Remove renaming from type syntax check2020-11-26T17:47:36ZFinn TeegenRemove renaming from type syntax checkThe renaming was necessary when locally quantified type variables could be introduced. As this is no longer the case, the renaming is obsolete.The renaming was necessary when locally quantified type variables could be introduced. As this is no longer the case, the renaming is obsolete.https://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/108Make specialization in dictionary transformation an optional optimization2020-11-23T16:54:00ZFinn TeegenMake specialization in dictionary transformation an optional optimizationThis is very useful for debugging the dictionary transformation.This is very useful for debugging the dictionary transformation.Finn TeegenFinn Teegen