JavaCC Tokens

[Ka55i0peia]

Hallo Leute,

kleine Knobelei:

Es geht um die Definition von Token bei einem mit javacc erzeugten Parser:

TOKEN :
{
  < #decimal_point : ("." | ",") >
|   < #sign : ( "+" | "-" ) >
|   < #mantissa : <exact_numeric_literal> >
|   < #signed_integer : (<sign>)? <UINT> >
|   < #exponent : <signed_integer> >
|   < #approximate_numeric_literal : <mantissa> ("E"|"e") <exponent> >
|   < exact_numeric_literal : < UINT > | ( <decimal_point> <UINT>  ) | ( <UINT> <decimal_point> (<UINT> )?) >
|   < #unsigned_numeric_literal : <exact_numeric_literal> | <approximate_numeric_literal> >
|   < COORD : (<sign>)? <unsigned_numeric_literal> >
}

Soll einen Token COORD beschreiben, der eine Koordinate erläutert.
Es ist fast perfekt:
1.0
-1.0
.1
-.1
werden akzeptiert. Allerdings eine ganz normale
1
nicht (??)

Es kommt die Meldung:

Encountered " <UINT> "1 "" at line 1, column 1.
Was expecting:
    <COORD> ...

Außerdem wird die Warnung:

Regular Expression choice : UINT can never be matched as : 
 exact_numeric_literal

beim javacc compilieren ausgeworfen.

Ich glaub ich seh den Wald vor lauter Bäumen nicht. :bahnhof:
Sieht jemand das Problem?

Unten ein Minimalbeispiel.
Danke für eure Hilfe,
Jan.

Wäre sehr dankbar!!

 

[Marco13]

Ich habe GAR keine Ahnung davon, und sollte eigentlich nichts dazu schreiben. Aber stelle zumindest eine Frage - sieh' es als Off-Topic-Frage an

Warum steht bei

exact_numeric_literal : < UINT > | ( <decimal_point> <UINT>  ) | ( <UINT> <decimal_point> (<UINT> )?) >

kein '#' davor, und warum sind da einmal Leerzeichen bei dem < UINT > und sonst überall nicht?

 

[Ka55i0peia]

Hallo Marco,

danke für deine Spitzfindigkeit

Warum steht bei [...] kein '#' davor

Das definiert einen lokalen Token. D.h. er ist nur innerhalb dieser Tokendefinition

TOKEN :
{...}

gültig. Dort steht keiner, weil sonst der Hinweis aus der Warnmeldung nicht generiert wird -- warum das so ist kann ich auchnicht sagen.

Das Leerzeichen um UINT ist nicht weiter tragisch. Ich nutze das eclipse-plugin für javacc und der editor macht da automatisch leerzeichen, finde aber dass das unübersichtlich wird.

Ich habe GAR keine Ahnung davon,

Hier eine gute deutschsprachige seite:
JavaCC

Grüße,
Jan

 

[Marco13]

Hmja, hätte ja sein können, dass es nur ein Tippfehler war Eigentlich und ganz Intuitiv sieht die Ableitung ansonsten ja sehr "straightforward" aus:
1 -> UINT -> exact_numeric_literal -> unsigned_numeric_literal --(weil sign optional ist)--> COORD
aber irgendwas stimmt offenbar nicht - und solche Details, wie das Leerzeichen

Encountered " <UINT> "1 "" at line 1, column 1. Was e 
                       ^ hier

sehen eben erstmal "verdächtig" aus, als könnte man das beheben, indem man eine Erweiterung der Grammatik einbaut, die besagt "Jaja, Leerzeichen dürfen da auch dabei sein". Aber das war's dann wohl nicht...

 

[Ka55i0peia]

OMG!!

Manchmal hilft eine Pause und neu anschauen Wunder:

Es kommt auf die Reihenfolge an! exact_numeric_literal kann nicht gematcht werden, weil UINT zuvor als Token erkannt wurde ...

TOKEN :
{
    < COORD : (<sign>)? <unsigned_numeric_literal> >
|   < #unsigned_numeric_literal : <exact_numeric_literal> | <approximate_numeric_literal> >
|   < #exact_numeric_literal :
				< UINT >
			| 	( <decimal_point> < UINT > )
			| 	( < UINT > <decimal_point> (< UINT >)? ) 
	>
|   < #approximate_numeric_literal : <mantissa> ("E"|"e") <exponent> >
|   < #exponent : <signed_integer> >
|   < #signed_integer : (<sign>)? (["0"-"9"])+ >
|   < #mantissa : <exact_numeric_literal> >
|   < #sign : ["+","-"] >
|  	< #decimal_point : [".",","] >
| 	< #DIGIT : [ "0"-"9" ] >
|   < UINT : (< DIGIT >)+ >
}

Vielen Dank Marco13 für dein Bemühen! Als Tipp, der hat mich auf die Lösung gebracht: im examples-Ordner

javacc-5.0\examples\JavaCCGrammar

sind jede Menge Token definiert (INTEGER_LITERAL, FLOATING_POINT_LITERAL, CHARACTER_LITERAL, STRING_LITERAL usw)

Viele Grüße
und schönen Abend bzw. N8!