1 / 5

Review of Core

Review of Core. MoZ. EBNF without apparent spaces. I'm not found of the proposed form of EBNF Even if it become difficult to read, we SHOULD say where the spaces are allowed and where they are not.

dara
Download Presentation

Review of Core

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Review of Core MoZ

  2. EBNF without apparent spaces • I'm not found of the proposed form of EBNF Even if it become difficult to read, we SHOULD say where the spaces are allowed and where they are not

  3. The syntax is clearly ambiguous: I fear it would need a difficult to write (and maintain) parser with an important LookAhead • Example : '_'SORTNAME is the beginning of Const or Var depending on the next character (" or ?) • There need to be proposed a clear definition of CONSTNAME : for the moment it is clear that CONSTNAME cannot be equal to a reserved word, cannot start by ?, _, (, ), and " I think it should be worth thinking to start reserved words by a particular prefix • The reserved word list is for the moment "And", "Or", "Exists", "Const", "ForAll", "if", "then" • What is the Meaning and use cases for empty Or(), And() and Const() ? • In some places in the document ForAll is also spelled FORALL : isn't it case sensitive? • Why do we have 'Exists' Var+, but 'ForAll' Var* ? what is the use case for a ForAll without vars ? • The EBNF extension for introducing of "if" and "then" construct is absent • The DTD is proposing a "type" attribute but it is spelled "sortal" in the spec

  4. DateTime • Here is an excerp of the definition of DateTime • << dateTime. This sort contains constants of the form _dateTime"SYYYY-NN-DDTHH:MM:SS.sZHH:MM", where YYYY represents the year with an optional minus sign S in front, NN represents a month in the range of 1..12, and DD represents the day of that month. The subsequent part HH:MM:SS.s represents time and is optional (see the description of time). The part that follows time, ZHH:MM represents the time zone. Here Z is a sign (+ or -), HH represents the difference in hours and MM in minutes. • The symbols -, :, and . are part of the syntax. dateTime is also allowed to have the form _dateTime"SYYYY-NN-DDTHH:MM:SS.sZ. Here the last Z is part of the syntax. • It have been forgot to precise that the T letter is part of the syntax • It seems unhappy to have S and SS have different meaning and further more to have HH and MM have two different kind of value

  5. Naïve question • Why a Uniterms ( Const() ) cannot be typed ? example _integer#Const(...)

More Related