cduce issueshttps://gitlab.math.univ-paris-diderot.fr/cduce/cduce/-/issues2022-12-09T16:09:24+01:00https://gitlab.math.univ-paris-diderot.fr/cduce/cduce/-/issues/36Review and sanitize the pretty-printing of errors2022-12-09T16:09:24+01:00Kim NguyễnReview and sanitize the pretty-printing of errorsCDuce's internal code base relies heavily on exceptions for error messages. Due to the various places error can occur, exceptions are not always correctly handled when they should. Some examples :
- Lexing/Parsing errors (static)
- Typin...CDuce's internal code base relies heavily on exceptions for error messages. Due to the various places error can occur, exceptions are not always correctly handled when they should. Some examples :
- Lexing/Parsing errors (static)
- Typing errors (static)
- Compilation errors (static but should be an internal failure, since compilation is not supposed to fail)
- CDuce exceptions (exceptions raised by CDuce code on purpose, dynamic)
- OCaml exceptions (exceptions raised by OCaml code on purpose, dynamic, e.g. if a user calls `OCaml.Stdlib.List.hd []`)
- Runtime exceptions (some corner features of CDuce require dynamic checks, such that pattern-matching against a primitive or polymorphic function)
And there are also warnings. And internal exceptions used for control flow that should never be used.
The use of all these exceptions should be surveyed, sanitized and documented. Most exceptions are caught in
[lang/lib/cduce_driver](https://gitlab.math.univ-paris-diderot.fr/cduce/cduce/-/blob/main/lang/lib/cduce_driver.ml#L316)
in a way that is not completely satisfactory (and maybe some are not).
This might require cleaning up the handling of locations first which is its own can of worm ([lang/parser/cduce_loc.ml](https://gitlab.math.univ-paris-diderot.fr/cduce/cduce/-/blob/main/lang/parser/cduce_loc.ml)).
In particular, it is still polluted by remnants of the HTML output (CDuce could be run as a CGI script for the online toplevel, which has been replaced by the JavaScript back-end that do not require a server-side component).
Once the surveying is done, a more robust error/warning infrastructure can be put in place.Usabilityhttps://gitlab.math.univ-paris-diderot.fr/cduce/cduce/-/issues/35Improve pretty-printing /parsing of types using UTF-8 Symbols2022-09-29T17:37:04+02:00Kim NguyễnImprove pretty-printing /parsing of types using UTF-8 SymbolsIt would be nice if CDuce was able to pretty-print types with UTF-8 connectives. This would depend on #34. Some requirements :
- It needs to be automatically disabled for terminals that don't support UTF-8
- A user must be able to disabl...It would be nice if CDuce was able to pretty-print types with UTF-8 connectives. This would depend on #34. Some requirements :
- It needs to be automatically disabled for terminals that don't support UTF-8
- A user must be able to disable it with a command-line flag
- This should also work for parsing. A rule of thumb to ensure the correct pretty-printing of types is that CDuce should always be able to parse a type it has pretty-printed (such that both types are equivalent).Usabilityhttps://gitlab.math.univ-paris-diderot.fr/cduce/cduce/-/issues/34Add a lowlevel module to pretty print in UTF-8 and color2022-12-09T16:09:24+01:00Kim NguyễnAdd a lowlevel module to pretty print in UTF-8 and colorA module for pretty printing and color should be added. The right place, imho is in cduce-types, that is in :
[types/misc/](https://gitlab.math.univ-paris-diderot.fr/cduce/cduce/-/tree/main/types/misc).
Once this module is available it ...A module for pretty printing and color should be added. The right place, imho is in cduce-types, that is in :
[types/misc/](https://gitlab.math.univ-paris-diderot.fr/cduce/cduce/-/tree/main/types/misc).
Once this module is available it could be used for :
- pretty-printing of types (with nice type connectives)
- pretty-printing of error messages or warning in color
- pretty-printing of error messages in tools (configure, dtd2cduce, …)Usabilityhttps://gitlab.math.univ-paris-diderot.fr/cduce/cduce/-/issues/32Add positive_vars(t) and negative_vars(t) in the Subst API2022-07-30T21:46:47+02:00Mickael LaurentAdd positive_vars(t) and negative_vars(t) in the Subst APIThere is no way in the current Types.Subst API to determine, given a variable v and a type t, whether v appears only in a covariant position in t, contravariant position, or both.
Adding such a function would be useful, or alternatively ...There is no way in the current Types.Subst API to determine, given a variable v and a type t, whether v appears only in a covariant position in t, contravariant position, or both.
Adding such a function would be useful, or alternatively (depending on the performance), a function positive_vars(t) that returns all the variables appearing in a covariant position in t, and negative_vars(t) that returns all the variables appearing in a contravariant position in t.https://gitlab.math.univ-paris-diderot.fr/cduce/cduce/-/issues/31Add optional parameter to the tally function to specify the order to use2022-08-22T10:25:53+02:00Mickael LaurentAdd optional parameter to the tally function to specify the order to useIt could be useful to be able to specify to the tally function which order to use on the type variables, as this order will determine which variables will be expressed as a function of the others (and which ones will remain unchanged).
T...It could be useful to be able to specify to the tally function which order to use on the type variables, as this order will determine which variables will be expressed as a function of the others (and which ones will remain unchanged).
This order should probably be given as a list of type variables in increasing order. Type variables that do not appear in this list should be considered greater (I think?? or maybe smaller) that all the variables present in the list, so that if we give as order to the tally function the list of our monomophic variables in the context of an inference, then these variables will remain unchanged whenever possible (and variables not present in this list will be expressed in function of our monomorphic variables, except when it is not possible, in which case a monomorphic variable will not remain unchanged).https://gitlab.math.univ-paris-diderot.fr/cduce/cduce/-/issues/24Packaging2022-01-17T16:54:50+01:00MattiasPackagingWhen we're happy with everything, let's have cduce as an opam package, a debian package too and other distros.
I think this will be the first milestone before going further with more "algorithmic" improvementsWhen we're happy with everything, let's have cduce as an opam package, a debian package too and other distros.
I think this will be the first milestone before going further with more "algorithmic" improvementsPackaginghttps://gitlab.math.univ-paris-diderot.fr/cduce/cduce/-/issues/22Optional dependencies2022-08-22T10:40:24+02:00MattiasOptional dependenciesOptional dependencies are handled in the libraries stanza of dune files by providing either an empty file if the dependency does not exist or providing the proper file if it does (see https://gitlab.math.univ-paris-diderot.fr/cduce/cduce...Optional dependencies are handled in the libraries stanza of dune files by providing either an empty file if the dependency does not exist or providing the proper file if it does (see https://gitlab.math.univ-paris-diderot.fr/cduce/cduce/-/blob/polymorphic/backend/native/dune for example).
Let's see what are other possibilities.Packaginghttps://gitlab.math.univ-paris-diderot.fr/cduce/cduce/-/issues/21Unit tests with dune2022-04-04T15:39:03+02:00MattiasUnit tests with duneTests are currently done from a generated dune file (see https://gitlab.math.univ-paris-diderot.fr/cduce/cduce/-/blob/polymorphic/tests/full/good/dune.auto for example)
Is there a better way of doing it?Tests are currently done from a generated dune file (see https://gitlab.math.univ-paris-diderot.fr/cduce/cduce/-/blob/polymorphic/tests/full/good/dune.auto for example)
Is there a better way of doing it?Packaginghttps://gitlab.math.univ-paris-diderot.fr/cduce/cduce/-/issues/16Pretty printing of arrow type could be simplified2017-10-16T08:48:07+02:00Kim NguyễnPretty printing of arrow type could be simplifiedArrows of the form A -> B & A -> C could be printed as a single arrow A -> B|CArrows of the form A -> B & A -> C could be printed as a single arrow A -> B|CKim NguyễnKim Nguyễnhttps://gitlab.math.univ-paris-diderot.fr/cduce/cduce/-/issues/9Polymorphic typing of record operations2022-03-16T16:21:58+01:00Kim NguyễnPolymorphic typing of record operationsHow to type the operations on records, concatenation e1 + e2 and field suppression e\ l in the presence of polymorphic variables. For the time being we do a safe but gross approximation. For instance
```
'a & r \ l = r \ l
```
Can ...How to type the operations on records, concatenation e1 + e2 and field suppression e\ l in the presence of polymorphic variables. For the time being we do a safe but gross approximation. For instance
```
'a & r \ l = r \ l
```
Can we do better?
https://gitlab.math.univ-paris-diderot.fr/cduce/cduce/-/issues/6Git subtree merge needed2017-10-16T08:48:07+02:00Kim NguyễnGit subtree merge neededSince the migration to Git the _website_ and cduce are in two distinct repositories. As a consequence the documentation that is in cduce/web and that is distributed with the language is no longer in synchro with the one one the website, ...Since the migration to Git the _website_ and cduce are in two distinct repositories. As a consequence the documentation that is in cduce/web and that is distributed with the language is no longer in synchro with the one one the website, which is the one up-to-date.
Solution: partially reorganize the files so that the directories manual tutorial examples img are directly taken by a subtree merge from the website gitGiuseppe CastagnaGiuseppe Castagnahttps://gitlab.math.univ-paris-diderot.fr/cduce/cduce/-/issues/4Fix pretty printing of Top types2017-10-16T08:48:07+02:00Kim NguyễnFix pretty printing of Top types```
# let max (x: 'a) (y: 'a): 'a = if ( x >> y) then x else y;;
val max : 'a -> 'a -> 'a = <fun>
# max (42 : Int);;
- : (('a \ (Int)) | Int) -> (('a \ (Int)) | Int) = <fun>
# max (42 : 42|AnyXml|Atom|Arrow);;
- : (('a \ ((Arrow | ...```
# let max (x: 'a) (y: 'a): 'a = if ( x >> y) then x else y;;
val max : 'a -> 'a -> 'a = <fun>
# max (42 : Int);;
- : (('a \ (Int)) | Int) -> (('a \ (Int)) | Int) = <fun>
# max (42 : 42|AnyXml|Atom|Arrow);;
- : (('a \ ((Arrow | Atom))) | (Arrow | AnyXml | Atom | 42)) -> (('a \ (
(Arrow |
Atom))) |
(Arrow |
AnyXml |
Atom | 42)) = <fun>
# max (42 : 42|AnyXml|Atom);;
- : (('a \ (Atom)) | (AnyXml | Atom | 42)) -> (('a \ (Atom)) |
(AnyXml | Atom | 42)) = <fun>
```