curry-frontend issueshttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues2023-07-26T16:17:34Zhttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/138Default all type variables2023-07-26T16:17:34ZKai ProttDefault all type variablesCurrently not all type variables occurring in a flat curry expression are bound in the type of the surrounding function declaration.
Consider the following example:
```haskell
test = length []
```
Here, both `length` and `[]` will be ty...Currently not all type variables occurring in a flat curry expression are bound in the type of the surrounding function declaration.
Consider the following example:
```haskell
test = length []
```
Here, both `length` and `[]` will be typed with a free type variable.
While the resulting FlatCurry Code is certainly correct, all typed back ends need to default these type variables.
If I remember correctly, KiCS2 does not even do this in all required cases, e.g. when the type variable has a kind different than `Type`/`*`.
We'd like these type variables to be defaulted in the frontend directly.
Currently our idea is to create a new transformation phase on the IL where the AST is traversed and a new data type is created for each unique kind that occurrs in a type variable that needs to be defaulted.
Additionally, each type variable is replaced with the respective type constructor that has been generated.
Note that the generated data types need no constructors. Although it is not possible for a user to write a data type with arbitrary kind but without constructors (all type variables will be phantom and defaulted to `*`), we can generate these data types internally.
I am not sure if and when the frontend adds a dummy constructor to external data types or a data type without constructors, but this should be kept in mind.
Also, all environments should be updated with the new data types and they should not be exported to keep the transformation and compilation local and without name clashes.
@fte @mh @fwcd: Anyone got a better Idea?
@fwcd Do you have time to implement this? Should not be too complicated.
Note that in GHC with `-XPolyKinds`, Just two data types are sufficient for all possible kinds.
```haskell
data Zero
data One (a :: k)
```
In Curry we need:
```haskell
data Zero
data One (a :: *)
data Two (a :: *) (b :: *)
data OneTwo (a :: * -> *) (b :: *)
...
```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/68Make recompilation robust w.r.t. different compilers2019-11-18T11:09:12ZFinn TeegenMake recompilation robust w.r.t. different compilershttps://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/31Properly represent a missing module header in the AST2018-12-17T10:53:25ZKai ProttProperly represent a missing module header in the ASTCurrently there is no "proper" way to detect, whether or not a module header was present (based solely on the structure of the generated AST).Currently there is no "proper" way to detect, whether or not a module header was present (based solely on the structure of the generated AST).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/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/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/64Remove token stream as output format2019-11-13T12:57:00ZFinn TeegenRemove token stream as output formatThe token stream was originally introduced by Katharina Rahf as a new output format in the process of her master's thesis. However, because the frontend supports an abstract syntax tree containing span information by now, we no longer ha...The token stream was originally introduced by Katharina Rahf as a new output format in the process of her master's thesis. However, because the frontend supports an abstract syntax tree containing span information by now, we no longer have need of this output format.https://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/60Rework `Simplify.sharePatternRhs`2019-10-28T10:31:24ZKai ProttRework `Simplify.sharePatternRhs`https://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/59Rework Record desugaring2019-10-28T10:19:16ZKai ProttRework Record desugaringhttps://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/53Update `overview.md`2019-11-08T17:14:25ZKai ProttUpdate `overview.md`https://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/67Use explicit ForallTypes in FlatCurry representation2019-11-25T08:39:32ZFinn TeegenUse explicit ForallTypes in FlatCurry representationIn the FlatCurry representation, the two functions
```id :: a -> a```
and
```id :: forall a. a -> a```
should have the same normalized representation that uses the `ForallType` constructor in both cases.
In general, type variable qu...In the FlatCurry representation, the two functions
```id :: a -> a```
and
```id :: forall a. a -> a```
should have the same normalized representation that uses the `ForallType` constructor in both cases.
In general, type variable quantification should be explicit in the FlatCurry representation and type should be in weak prenex form.Jan-Hendrik MatthesJan-Hendrik Mattheshttps://git.ps.informatik.uni-kiel.de/curry/curry-frontend/-/issues/63Use MultiParamTypeClasses in `Base.Types`2019-10-28T10:31:31ZKai ProttUse MultiParamTypeClasses in `Base.Types`Or at least delete the TODOOr at least delete the TODO