1. 16 Feb, 2015 2 commits
    • Kim Nguyễn's avatar
      Fix the handling of polymorphic variables in the lexer. The solution · 36b83c45
      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.
      36b83c45
    • Kim Nguyễn's avatar
      Implement the syntax ``t (t1, …, tn)'' for type instantiation, without · 07bc7bc1
      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).
      07bc7bc1
  2. 14 Dec, 2014 1 commit
  3. 05 Oct, 2014 1 commit
  4. 14 Sep, 2014 1 commit
  5. 12 Sep, 2014 1 commit
  6. 09 Sep, 2014 1 commit
    • Pietro Abate's avatar
      New syntax for parametric types · f1235de1
      Pietro Abate authored
      now we can write types as
      type t( 'a) = <a>'a
      
      and patterns can contain type instantiations
      let f = fun (t('a) -> [ t('a)* ]) x -> [ x ];;
      let id = fun (t(Int) -> [ t(Int)* ]) x -> [ x ];;
      
      Note: parametric types must be written as "IDENT(" without space.
      f1235de1
  7. 08 Sep, 2014 1 commit
    • Pietro Abate's avatar
      Add parametric type to patterns · 0d3a9e60
      Pietro Abate authored
      - change syntax to avoid conflicts ( tried "((", "[<", "<[", "(" )
         type t {[ 'a,'b ]} = (Int,[ 'b* ]) ;;
         let app (f : 'a -> t {[Int,Int]} )(a : 'a) : t = f a;;
      0d3a9e60
  8. 25 Aug, 2014 2 commits
  9. 11 Jul, 2014 1 commit
  10. 10 Jul, 2014 1 commit
  11. 09 Jul, 2014 2 commits
  12. 08 Jul, 2014 1 commit
  13. 27 Jun, 2014 1 commit
    • Julien Lopez's avatar
      We don't need parentheses for type variables in regexp anymore, the syntax is · 9b94eb11
      Julien Lopez authored
      now as such:
      	- ['a] is the regexp matching the type variable "a";
      	- ['a'] is the regexp matching the string "a";
      	- ['a' 'a] is the regexp matching the string "a" followed by the type
      	variable "a";
      	- ['a''a] is a syntax error (a string in single quotes in a regexp MUST
      	be followed by a character that cannot be the beginning of a name for a
      	type variable, a blank character will do).
      
      Bug: At this point, when using CDuce at toplevel, one will have to press enter
      twice when typing a regexp with type variables.
      9b94eb11
  14. 26 Jun, 2014 1 commit
  15. 24 Jun, 2014 1 commit
  16. 20 Jun, 2014 1 commit
  17. 19 Jun, 2014 5 commits
  18. 03 Dec, 2013 1 commit
  19. 08 Mar, 2011 1 commit
  20. 03 Mar, 2011 1 commit
  21. 05 Oct, 2007 13 commits