Syntax

• Case conversion
  SIC would no longer convert the command line in upper case. Commands, keywords, variables and mathematics expressions would be recognized whatever the case, but the rest of the command string would be taken ``as typed''

  Example:
  SIC EXTENSION .class and Sic EXtension .class are equivalent
  but not SIC EXTENSION .CLASS

• Separators
  The only separator would be the space (`` ''). Slashes (``/'') would no longer be a separator, but could either be an option delimiter or just part of a string. This allows the use of / as the division token.

  A pending question is whether a slash can begin a string without double quotes. This would allow file names to be typed directly, but would prevent the user of being warned by an error message in case of mistyped option. Robert Lucas and Stephane Guilloteau propose that
  - Single slash necessarily begins an option
  - Double slash can be used to begin an absolute path/file name

  Example
  

     file out /usr /new        ! Returns error "No such option /usr"
     file out /usr/toto/new    ! Returns error "No such option /usr/toto/new"
     file out //usr/toto /new  ! Creates file /usr/toto  (option /new)
     file out "/usr/toto" /new ! Creates file /usr/toto  (option /new)
  

  4 voted in favor, 2 against (noting that double slash creates unecessary exception, quotes can be used instead), 2 did not comment. This issue is still pending (there is no programming problem).
• Double Quotes
  Double quotes will be handled in character strings as follows: two consecutive double quotes will produce one double quote in the string. (The current behaviour was to produce TWO separate strings by inserting a space between the two double quotes)

    SAY "toto = ""toto""!"
  

  will result in

    toto = "toto"!
  

• Better Syntax Checking
  SIC now tries to complain on ``invalid syntax'' as much as possible at parsing time. De facto, the only allowed characters before a " are ( ' . and space, and after a " are ) ' . and space.

  This cleans up a previously strange behaviour, which gave error message, but still produced some (clumsy) output.
  Example:

       command "toto"TATA"titi"     !
       command "toto"'TATA'"titi"   !
       command "toto"/titi          !
       command "toto"+titi          !
       command "toto"titi           !
  

  are all invalid, and recognized as such at parsing time.

       command "toto"'titi'         ! TITI is a known variable
  

  is valid (because titi is a known variable), but

       command "toto"'titi'         ! TITI is NOT a variable
       command "toto".eq.           !
  

  are both invalid, but recognized only as such at execution time.