Bonne grammaire pour le type de données de date pour l'analyseur de descente récursif LL (1)

Question

Je construis un analyseur d'expression et un évaluateur d'expression personnalisés pour l'environnement de production afin de fournir un accès DSL limité aux utilisateurs. L'analyseur lui-même en tant que DSL, doit être simple. L'analyseur va être construit dans un langage exotique qui ne supporte pas l'analyse dynamique de l'expression ni aucun outil générateur d'analyseur disponible. Ma décision actuelle est d'opter pour une approche de descente récursive avec la grammaire LL (1), de sorte que même les programmeurs n'ayant aucune expérience dans l'évaluation de l'expression pourraient rapidement apprendre comment le code fonctionne.

Il doit gérer des expressions mixtes composées de plusieurs types de données: décimales, pourcentages, chaînes et dates. Et les dates au format jj/mm/aaaa sont faciles à confondre avec une série d'opérations de division.

Est-ce qu'une bonne solution à ce problème?

ma propre solution qui vise à maintenir le simple analyseur et implique les dates préfixer avec un symbole spécial, disons apostrophe:

<date> ::= <apostr><digit><digit>/<digit><digit>/<digit><digit><digit><digit> 

<apostr> ::= ' 

<digit> ::= '0'..'9' 

Answer 1

Tout d'abord, je suis un fan de LL parseurs, donc j'approuve de votre approche chaleureusement. Notez que l'un des plus récents générateurs d'analyseurs populaires (ANTLR) est LL. Si vous autorisez plus de prévisualisation, plutôt que de vous limiter à LL (1), vous pouvez faire à peu près tout ce que vous voudrez faire avec un parseur LR (1), mais le code sera beaucoup plus clair, plus fiable, et plus facile à déboguer. Je ne connais pas assez votre grammaire générale pour être capable de le dire. Il est possible que vous soyez capable de concevoir des choses de telle sorte que l'analyseur LL puisse toujours dire à partir du contexte s'il s'agit d'une expression entière ou d'une constante de date. Cependant, en supposant que vous ne pouvez pas, oui, vous auriez besoin d'une façon de faire la différence. La seule autre chose que je peux penser serait d'utiliser le backslash comme séparateur au lieu de slash, mais c'est plutôt moche.

Answer 2

Un analyseur sans lexle de type LL avec un lookahead infini est ce dont vous avez besoin. Et, à savoir, c'est PEG.

http://en.wikipedia.org/wiki/Parsing_expression_grammar

Avec un choix ordonné il est assez facile d'éviter cette date par rapport à la confusion de la division littéraux constante.

Answer 3

Quand une langue est destinée à l'entrée humaine, définir est autant une question de

• ajoutant des contraintes de syntaxe pour assurer l'analyse sans ambiguïté et facile
• suppression/syntaxe pliage pour faire en sorte que la langue se sent intuitive , "naturel", à l'auditoire humain prévu.

Satisfaire la deuxième exigence est beaucoup plus difficile que la première, et exige un aperçu des

• cas d'utilisation prévue de la langue
  Quel type de dispositif clavier/entrée est disponible? Y a-t-il des caractères parmi les caractères autorisés qui sont difficiles à produire ou à voir sur l'écran?
  Quels jetons/expressions seront fréquemment utilisés, ce qui ne sera requis qu'occasionnellement? Les utilisateurs sont-SAISIE souvent courts extraits de code ad hoc, ou sont les programmes destinés à être réutilisés et modifiés sur de longues périodes
  ... etc.
fond/culture
• du public visé
  Quelles pratiques/idiomes d'autres langues régulières (et naturelles) peuvent ou devraient être réutilisés si possible?
  Faut-il privilégier un style concis mais cryptique, ou un style plus explicite, mais plus bavard?
  etc ...

Fondamentalement, il est difficile de faire des suggestions sur une syntaxe de langage, sans une bonne connaissance de l'usage prévu et les utilisateurs.
Néanmoins, je voudrais suggérer ce qui suit pour la question du format de la date:

Utilisez un autre format pour les valeurs de date en tout; celui qui serait assez «naturel» pour les utilisateurs, mais assez distinctif pour qu'une grammaire régulière puisse décrire.
Par exemple, celui qui utilise une abréviation de 3 lettres pour le mois (baisse DSL devient liée à l'anglais ou autre langue, mais aussi avantage, l'ambiguïté pour les humains dont le jour est et qui est enlevé mois). Provisoirement:

dd-mmm-yyyy (may seem unnatural in cultures where the prevailing date order 
        starts with the month maybe yyyy-mmm-dd then ?) 
    mmm-dd-yyyy (better for the above mentioned cultures) 
    ddmmmyyyy  (avoid the dashes, but impose leading zeros) 

    MnnDnnYyyyy (using "M", "D" and "Y" (or others) as explicit prefixes; now, 
        this is completely culture neutral, but maybe a bit awkward...) 

Quoi qu'il en soit, à quelques idées ... Application varieront en fonction des facteurs humains/culturels mentionnés, et avec le reste de la syntaxe. Par exemple, ce qui précède peut impliquer que les variables soient marquées explicitement (c'est l'une des raisons pour lesquelles de nombreuses langues utilisent le préfixe $ par exemple), pour éviter un conflit possible avec les identificateurs de variable [impair, mais possible]. En un mot, l'idée est de substituer le besoin d'un préfixe de caractère spécial (qui peut ensuite entrer en collision avec l'utilisation de ces caractères pour des expressions mathématiques et autres), en faisant de l'étiquette de 12 mois un discriminant suffisant pour l'analyseur.