curry-packages issueshttps://git.ps.informatik.uni-kiel.de/groups/curry-packages/-/issues2022-07-16T13:35:22Zhttps://git.ps.informatik.uni-kiel.de/curry-packages/json/-/issues/4Add FromJSON/ToJSON type classes for converting between custom data types and...2022-07-16T13:35:22ZFredrik WieczerkowskiAdd FromJSON/ToJSON type classes for converting between custom data types and JValuesWhen working on projects that depend on the `json` package, I frequently find myself defining a pair of type classes for converting between `JValue`s and custom types:
```haskell
class FromJSON a where
-- | Converts from a JSON value ...When working on projects that depend on the `json` package, I frequently find myself defining a pair of type classes for converting between `JValue`s and custom types:
```haskell
class FromJSON a where
-- | Converts from a JSON value to the type.
fromJSON :: JValue -> Either String a
-- | Converts from a JSON value to the list type.
-- Useful for providing a separate overload for strings and other arrays,
-- similar to showList and show.
listFromJSON :: JValue -> Either String [a]
listFromJSON j = case j of
JArray vs -> mapM fromJSON vs
_ -> Left $ "Expected array but was: " ++ ppJSON j
class ToJSON a where
-- | Converts from the type to JSON.
toJSON :: a -> JValue
-- | Converts from the list type to JSON.
listToJSON :: [a] -> JValue
listToJSON = JArray . (toJSON <$>)
-- | Generates a JSON string from a value of type.
toJSONString :: a -> String
toJSONString = ppJSON . toJSON
```
([see here](https://github.com/fwcd/curry-lsp/blob/7e519d982ebb0ed57a91f84c185ce604b562a09b/src/LSP/Utils/JSON.curry#L15-L41))
By implementing these type classes for custom types, especially complex structures, serializing and deserializing data to and from JSON becomes a lot more convenient. While it is of course easy to define these classes downstream, especially libraries could probably benefit from standardized conversion classes.
This approach is inspired by [`aeson`'s `FromJSON`/`ToJSON` classes](https://hackage.haskell.org/package/aeson-2.1.0.0/docs/Data-Aeson.html#t:FromJSON) in Haskell.https://git.ps.informatik.uni-kiel.de/curry-packages/abstract-curry/-/issues/2Cannot generate instances from other modules when using default qualification...2022-07-15T14:52:29ZFredrik WieczerkowskiCannot generate instances from other modules when using default qualification optionsUnless I am missing something, generating instances for instances from other modules is currently not possible. Consider the following class declaration:
```
module M where
class C a where
doSomething :: a -> String
```
Generating a...Unless I am missing something, generating instances for instances from other modules is currently not possible. Consider the following class declaration:
```
module M where
class C a where
doSomething :: a -> String
```
Generating a syntax tree with qualified identifiers yields
```
module N where
import qualified M
data X = X
instance M.C X where
M.doSomething = ...
```
The problem is that `M.doSomething` is not a valid left-hand side of a function rule. Using an unqualified `doSomething` identifier, however, also results in an error, in that case that the method is not visible, which makes sense given that the import is only qualified.
So I see two (not necessarily mutually exclusive) solutions here:
- Have the prettyprinter deal with the correct imports and generate an unqualified function name even if the name is qualified in the tree
- Let the user specify unqualified importshttps://git.ps.informatik.uni-kiel.de/curry-packages/json/-/issues/3Represent integers separately2022-07-16T13:37:22ZFredrik WieczerkowskiRepresent integers separatelyMany JSON-based protocols treat integers separately from floating-point values. Since this can become important especially during prettyprinting (if the reading party e.g. expects the numbers to not have a decimal separator), it would be...Many JSON-based protocols treat integers separately from floating-point values. Since this can become important especially during prettyprinting (if the reading party e.g. expects the numbers to not have a decimal separator), it would be cool if the library could represent integers using a separate constructors (e.g. `JInteger` or `JInt`).https://git.ps.informatik.uni-kiel.de/curry-packages/abstract-curry/-/issues/1Add ability to represent and prettyprint (doc) comments on type declarations ...2022-07-14T20:39:27ZFredrik WieczerkowskiAdd ability to represent and prettyprint (doc) comments on type declarations and record fieldsIt would be pretty cool if the Curry syntax types would support representing comments, in particular documentation comments, on type declarations (`CTypeDecl`) and fields (`CFieldDecl`), perhaps similar to how functions with a comment ar...It would be pretty cool if the Curry syntax types would support representing comments, in particular documentation comments, on type declarations (`CTypeDecl`) and fields (`CFieldDecl`), perhaps similar to how functions with a comment are represented by the `CmtFunc` constructor.https://git.ps.informatik.uni-kiel.de/curry-packages/cpm/-/issues/5Add 'cypm run' command2022-07-14T17:22:28ZFredrik WieczerkowskiAdd 'cypm run' commandWhile developing a package with one or more executables it can be convenient to simply compile and run the executable directly without installing it first. Similar to other build tools (`stack`, `cabal`, `cargo`, ...) it would be very co...While developing a package with one or more executables it can be convenient to simply compile and run the executable directly without installing it first. Similar to other build tools (`stack`, `cabal`, `cargo`, ...) it would be very convenient if we could have a `cypm run` command for executing the package's main (as declared in the `executable`/`executables`). If the main is ambiguous, the tool could require passing the name of the executable as a second argument, i.e. `cypm run [executable]`.
For example, suppose a package had the following executables in the `package.json`:
```json
{
"executables": [
{
"name": "kics2c",
"main": "KiCS2.Compile"
},
{
"name": "kics2i",
"main": "KiCS2.REPL"
}
]
}
```
Then `cypm run kics2c` could be effectively equivalent to `curry :load KiCS2.Compile :eval main :quit`. If only one executable exists, `cypm run` would simply execute the (unambiguous) main.
Thoughts?https://git.ps.informatik.uni-kiel.de/curry-packages/json/-/issues/2Represent booleans with JBool Bool instead of JTrue and JFalse2022-07-16T13:37:30ZFredrik WieczerkowskiRepresent booleans with JBool Bool instead of JTrue and JFalseSince `true` and `false` naturally map to Curry's `True` and `False`, a more natural representation for booleans would be `JBool Bool` instead of encoding them as separate `JValue` constructors `JTrue` and `JFalse`.Since `true` and `false` naturally map to Curry's `True` and `False`, a more natural representation for booleans would be `JBool Bool` instead of encoding them as separate `JValue` constructors `JTrue` and `JFalse`.https://git.ps.informatik.uni-kiel.de/curry-packages/currycheck/-/issues/2Show failing value in case of an exception2022-03-09T15:33:04ZFredrik WieczerkowskiShow failing value in case of an exceptionIt would be cool if, even when an exception occurs during a tested property, the failing value could be shown. E.g. consider the following EasyCheck property from the `json` module:
```curry
-- Test property of pretty printing and parsi...It would be cool if, even when an exception occurs during a tested property, the failing value could be shown. E.g. consider the following EasyCheck property from the `json` module:
```curry
-- Test property of pretty printing and parsing.
testParsePrint :: JValue -> Prop
testParsePrint json =
always (eqJValue (fromJust (parseJSON (ppJSON json))) json)
```
If parsing fails, we only get the following error:
```
testParsePrint (module SimpleTest, line 33): EXECUTION FAILURE:
user error: Maybe.fromJust: Nothing
==============================================================================
FAILURES OCCURRED IN SOME TESTS:
testParsePrint (module SimpleTest, line 33)
==============================================================================
Evaluation terminated with non-zero status 1
```
Here, it would be nice if the `JValue` that caused the test to fail could be printed.https://git.ps.informatik.uni-kiel.de/curry-packages/det-parse/-/issues/1Implement Functor, Applicative, Monad and Alternative for Parser2022-03-09T15:20:41ZFredrik WieczerkowskiImplement Functor, Applicative, Monad and Alternative for ParserMonadic parsing would let us take advantage of the polymorphic `(<$>)`, `(<*>)`, `(<|>)`, `(>>=)`, `yield` as `pure`/`return` ... operators in the standard library and additionally make `do`-notation available. For backwards compatibilit...Monadic parsing would let us take advantage of the polymorphic `(<$>)`, `(<*>)`, `(<|>)`, `(>>=)`, `yield` as `pure`/`return` ... operators in the standard library and additionally make `do`-notation available. For backwards compatibility, this module could reexport the polymorphic versions.https://git.ps.informatik.uni-kiel.de/curry-packages/json/-/issues/1Represent JObjects with Data.Map2022-07-16T13:37:35ZFredrik WieczerkowskiRepresent JObjects with Data.MapThe `[(String, JValue)]`-based representation, while simple to parse, has the disadvantage of having slow (linear-time) lookup. Using `Data.Map` would have the advantage of not requiring consumers of the library to perform the conversion...The `[(String, JValue)]`-based representation, while simple to parse, has the disadvantage of having slow (linear-time) lookup. Using `Data.Map` would have the advantage of not requiring consumers of the library to perform the conversion themselves and additionally be closer to the JSON model itself, e.g. disallowing multiple mappings for a single key and not imposing an order on the mappings.
Haskell's JSON library `aeson` takes a similar approach: https://hackage.haskell.org/package/aeson-2.0.3.0/docs/Data-Aeson-KeyMap.html#t:KeyMap
Thoughts?https://git.ps.informatik.uni-kiel.de/curry-packages/frontend-exec/-/issues/2Make warning options more customizable2022-03-03T11:37:00ZFredrik WieczerkowskiMake warning options more customizableIt would be great to have more flexibility over the warn opts, e.g. a parameter with a `[WarnFlag]`, similar to how the frontend handles this directly. Currently only overlap warnings can be toggled.
The use case I would have in mind is...It would be great to have more flexibility over the warn opts, e.g. a parameter with a `[WarnFlag]`, similar to how the frontend handles this directly. Currently only overlap warnings can be toggled.
The use case I would have in mind is that users of the KiCS2 REPL could easily toggle between different warnings. While passing these options as specials might alternatively be viable, this would also make the overlap warnings less of a special case. Thoughts?https://git.ps.informatik.uni-kiel.de/curry-packages/flatcurry-typed/-/issues/1Add the representation of newtypes.2020-11-12T16:11:14ZFredrik WieczerkowskiAdd the representation of newtypes.Add the representation of newtypes.Add the representation of newtypes.https://git.ps.informatik.uni-kiel.de/curry-packages/flatcurry-annotated/-/issues/3Add representation of newtypes2020-11-12T16:11:21ZFredrik WieczerkowskiAdd representation of newtypesAdd the representation of newtypes.Add the representation of newtypes.https://git.ps.informatik.uni-kiel.de/curry-packages/flatcurry/-/issues/1Add newtypes2020-11-12T16:11:27ZFredrik WieczerkowskiAdd newtypesAdd the representation of newtypes.Add the representation of newtypes.https://git.ps.informatik.uni-kiel.de/curry-packages/flatcurry-annotated/-/issues/1Control.Monad.Extra and Control.Monad.Trans.Error used but not available2020-11-12T16:12:00ZMichael HanusControl.Monad.Extra and Control.Monad.Trans.Error used but not availableThe module FlatCurry.Annotated.TypeInference uses two module which seems to have been introduced
for the transition to version3 but are not available. Solution(?): adapt code to other monad librariesThe module FlatCurry.Annotated.TypeInference uses two module which seems to have been introduced
for the transition to version3 but are not available. Solution(?): adapt code to other monad librariesFredrik WieczerkowskiFredrik Wieczerkowskihttps://git.ps.informatik.uni-kiel.de/curry-packages/currydoc/-/issues/3Wrong type signature for Bounded functions in the CDOC export2018-08-24T09:22:48ZJan-Hendrik MatthesWrong type signature for Bounded functions in the CDOC exportWhen exporting the Prelude to a `.cdoc` file, the functions of the `Bounded` type class have the following wrong type signatures:
```haskell
minBound :: () -> a
maxBound :: () -> a
```
Search for `_def#minBound` or `_def#maxBound` in t...When exporting the Prelude to a `.cdoc` file, the functions of the `Bounded` type class have the following wrong type signatures:
```haskell
minBound :: () -> a
maxBound :: () -> a
```
Search for `_def#minBound` or `_def#maxBound` in the exported file to verify this. The correct type signature for both functions should be `:: a`.https://git.ps.informatik.uni-kiel.de/curry-packages/currydoc/-/issues/2Export to JSON files2018-07-10T10:39:46ZJan-Hendrik MatthesExport to JSON filesAn export option like `--json` for JSON files would be very handy for some use cases (e.g. autocomplete providers such as [autocomplete-curry](https://github.com/matthesjh/autocomplete-curry)). A sample file of a JSON output for the `Pre...An export option like `--json` for JSON files would be very handy for some use cases (e.g. autocomplete providers such as [autocomplete-curry](https://github.com/matthesjh/autocomplete-curry)). A sample file of a JSON output for the `Prelude` can be found [here](https://github.com/matthesjh/autocomplete-curry/blob/2d12ee13af6f0a637bbe7a7fd9e4ab347837adcd/data/completions.json). Please note that the syntax of the JSON output is just a first draft.
With this option the interface of modules can be more easily provided to other programs.https://git.ps.informatik.uni-kiel.de/curry-packages/currydoc/-/issues/1Style Suggestion: ReadTheDocs2017-11-22T08:01:09ZSandra DylusStyle Suggestion: ReadTheDocsI was browsing the documentations of Agda and Idris this week and realised that they use the same tool to generate their docs ([ReadTheDocs](https://readthedocs.org) -- you might want to try it with `Agda` or `Idris`). @mh won't probably...I was browsing the documentations of Agda and Idris this week and realised that they use the same tool to generate their docs ([ReadTheDocs](https://readthedocs.org) -- you might want to try it with `Agda` or `Idris`). @mh won't probably be a big fan of it, since it seems to come with an ad in the free version, but I still want to mention it. I think it looks very "modern" and is simple to use (it, for example, comes with a search utility). When we have a bachelor's student working on CurryDoc, maybe we could think about a ReadTheDocs-backend as well?
The usage is not limited to library/package documentation only, the mentioned languages use it for all kind of guides ("Getting Started", Installation, Tools etc).