Generating Software from Specifications WS 2013/14 - File TryScanLsg.fw
@=~ ~p maximum_input_line_length = infinity The concrete grammar specifies a sequence of Elements separated by commas. The elements are named terminals. ~O~<TryScan.con~>~{ Specification: Sequence. Sequence: Sequence ',' Element / Element. Element: Ident / Number / CarPlate. ~} A production alternative is added for a new non-literal terminal CarPlate. Two tokens are specified here. Replace them by your favorite token notations and test the generated scanner and parser: ~O~<TryScan.gla~>~{ Ident: $[a-zA-Z][a-zA-Z0-9]* [myToken] Number: $[0-9]+ [myToken] CarPlate: $[A-Z]{1,3}-([A-Z]{1,2}-)?[1-9]([0-9]{1,3})? [myToken] ~} The notation of the non-literal terminal CarPlate is specified by a regular expression. It states rules for car plates in German style - specific exemptions are omitted. Here is a correct input file. You can extract it in Eli commands by TryScanLsg.fw:fwGen/in.ok, for example in . +cmd=(TryScanLsg.fw:exe) (TryScanLsg.fw:fwGen/in.ok) :run ~O~<in.ok~>~{ a, b, 1, c,22, 1234567890, PB-UK-6666, D-X-42, B-P-1, NRW-1 ~} Here is an erroneous input file. ~O~<in.err~>~{ 123 , # 25a, ? PB--123, HSK-, B-12345 ~} The following three macros implement a little C module. It defines a function to be called as a token encoding function. In the present state it only prints some information on every accepted token: ~O~<TryScan.HEAD.phi~>~{ #include "TryScan.h" ~} ~O~<TryScan.h~>~{ extern void myToken (char *start, int length, int *class, int *intrinsic); ~} ~O~<TryScan.c~>~{ #include <stdio.h> #include "TryScan.h" int count = 0; void myToken (char *start, int length, int *class, int *intrinsic) { count++; printf ("token %d first char >%c<\n", count, *start); } ~}
Generiert mit Camelot | Probleme mit Camelot? | Geändert am: 31.10.2013