- 25 Mar, 2015 2 commits
-
-
Kim Nguyễn authored
Fix various bugs in the pretty-printer (union of atoms not parenthesized, | instead of & for some toplevel variables)
-
Kim Nguyễn authored
-
- 24 Mar, 2015 1 commit
-
-
Kim Nguyễn authored
-
- 23 Mar, 2015 1 commit
-
-
Kim Nguyễn authored
Add a wrapper around the type printing function to prevent them from outputing illegal code (such as [(Char | (*--2)*)* ]. (which contains CDuce comments).
-
- 20 Mar, 2015 1 commit
-
-
Kim Nguyễn authored
Implement some semantic simplification of BDDs. This fixes the exponential beahviour during the typing of the application of flatten.
-
- 18 Mar, 2015 3 commits
-
-
Kim Nguyễn authored
Refactor the Bool/BoolVar code so that they share the same interface. Give access to the underlying atom module in BoolVar.
-
Kim Nguyễn authored
Improve pretty printing of Bdds and add debug directive to interactively inspect the internal representation of types.
-
Kim Nguyễn authored
exponentially large types in some cases. This simplifies types of the form: T & 'a | T \ 'a into T.
-
- 06 Mar, 2015 1 commit
-
-
https://git.cduce.org/cduceKim Nguyễn authored
-
- 04 Mar, 2015 6 commits
-
-
Kim Nguyễn authored
because they appeared both on negative and positive occurences in bdds that are equivalent to the empty type. For instance t = ('a | (Int\'a) | Int) We use product normalization to clean up this. Use the new debugging infrastructure to see what is going on during constraint solving.
-
Kim Nguyễn authored
-
Kim Nguyễn authored
-
Kim Nguyễn authored
-
Kim Nguyễn authored
-
Kim Nguyễn authored
Add a workaround in case pattern compilation failed (after typechecking) due to the presence of type variables in some types.
-
- 03 Mar, 2015 1 commit
-
-
Kim Nguyễn authored
Fix a stupid typo which made the constraint solver prefer monomorphic variables over polymorphic ones. This prevented one from applying a polymorphic function in the body of another function.
-
- 28 Feb, 2015 3 commits
-
-
Kim Nguyễn authored
-
Kim Nguyễn authored
-
Kim Nguyễn authored
Make it so that the substitution function preserves as much sharing as possible from the original type.
-
- 27 Feb, 2015 2 commits
-
-
-
Kim Nguyễn authored
-
- 26 Feb, 2015 2 commits
-
-
Kim Nguyễn authored
-
Kim Nguyễn authored
-
- 21 Feb, 2015 2 commits
-
-
Kim Nguyễn authored
-
Kim Nguyễn authored
This reverts commit a8ba6ab6. This commit introduces a regression where suprious type variables are introduced in the final type.
-
- 20 Feb, 2015 2 commits
-
-
Kim Nguyễn authored
-
Kim Nguyễn authored
Seal the representation of SortedList.Make(X).t (by making the type private). Expose Var.Set as a SortedList.S
-
- 19 Feb, 2015 2 commits
-
-
Kim Nguyễn authored
Perform a more aggressive memoization of substituted types and register the name if the original type was named. Make the pretty-printer re-entrant.
-
Kim Nguyễn authored
-
- 18 Feb, 2015 1 commit
-
-
Kim Nguyễn authored
remain regular. Within their recursive definitions, parametric types must always be instantiated with their original parameters and all types of mutually recursive definitions must have the same parameters. We use Tarjan's strongly connected components algorithm to group type definitions accordingly.
-
- 17 Feb, 2015 2 commits
-
-
Kim Nguyễn authored
[ 'abc'ab ] is now parsed as [ 'abc' ab ] to maintain backward compatibility. Change the warning message accordingly.
-
Kim Nguyễn authored
-
- 16 Feb, 2015 6 commits
-
-
Kim Nguyễn authored
correctly handle insantiated types in regular expressions.
-
Kim Nguyễn authored
suggest to put a space before the second quote. Move the auxiliary 'warning' function from the typechecker to the Cduce_loc module. Re-indent some comments in ulexer.ml
-
Kim Nguyễn authored
"\n" after the ;; token.
-
Kim Nguyễn authored
to use two lexers (depending on whether we are between square brackets or not) is too brittle (it crudely tries to parse ``( [whitespace] 'a [whitespace] )'' as a variable, to force the user to write the variable beetween parenthesis. However this does not scale to types with two arguments (says [ t ('a, 'b) ]). We use a simpler heuristic (with look ahead) (1) try to see if the regular expression ' (anything but ', \n)* '(anything but the first letter of an identifier) can be found. If so, we put back the lexeme in the buffer and parse it as as a string. (2) if (1) failed, try to parse it as a variable (3) if (3) failed, try to parse it again as a string. We are guaranteed to fail here but it means we have a malformed string, so we parse as a string to get a proper error message. The only thing this does not cover are cases like type t = [ 'abcd'Int ] which was tokenized before as [, 'abcd', Int, ] and is now tokenized as [, 'abcd, 'Int, ] It does not seem to be a problem in practice though (since in the code I have seen thus far, people were at least putting a space). it is easy to emmit a warning in this case, suggesting the user to add a whitespace to get the old behaviour back.
-
Kim Nguyễn authored
-
Kim Nguyễn authored
requiring an abscence of whitespace between ``t'' and ``(''. Outside of regular expression contexts, ``t (t1, …, tn)'' is parsed with a higher precedence than & and \, to allow one to write ``t (Int) & Bool'' without extra parentheses (i.e. ``(t (Int)) & Bool''). Inside a regular expression, type instantiation and sequencing become ambiguous, and there is no way to distinguish syntactically: ``[ Int (Int, Int) ]'' from ``[ t (Int, Int) ]''. The former should resolve to a sequence while the latter only makes sense as an instantiation (if ``t'' is a parametric type). Both are treated as element sequencing and disambiguated during identifier resolution (more precisely during the "derecurse" phase, before typechecking). Note that due to the lower precedence of sequencing w.r.t to other regular expression constructs, a type ``[ t (Int)* ]'' will be parsed correctly, but yield an error message saying that t is not fully intantiated. One has to write ``[ (t (Int))* ]'' which is similar to function applications for expressions. Finally, we also re-order sequencing after typing to always group a potential type instantiation with its argument, i.e. we transform sequences such as ``[ t1 t2 t3 ... tn ]'' (which are parsed as ``[ (((t1 t2) t3) ... tn) ]'' because sequence concatenation is left-associative) into ``[ ... (ti tj) ... ]'' if ``ti'' is an identifier and ``tj'' is of the form ``(s1,...,sk)''. This is sound because concatenation of regular expression is associative (and the original sequence would fail, anyway).
-
- 15 Feb, 2015 2 commits
-
-
Kim Nguyễn authored
containing variables but no toplevel variables would not be printed as regular expressions but nested pairs.
-
Kim Nguyễn authored
Now functions such as let fun f (x:Int):Int = ... are parsed correctly (that is, its parameter is 'x' with type Int).
-