2012-05-30 12 views
6

Ich habe einen funktionierenden Scala-Parser, aber die Lösung ist nicht so sauber wie ich es möchte. Das Problem ist, dass einige der Produktionen Leerzeichen als Teil des Tokens betrachten müssen, aber die "höheren" Produktionen sollten in der Lage sein, das Leerzeichen zu ignorieren/überspringen.Scala Parser, der manchmal Leerzeichen überspringt und manchmal nicht

Wenn ich das typische Scala-Parser-Muster verwende, um die Parser der unteren Ebene zu erweitern, dann werden die Einstellungen von skipWhitespace vererbt, und die Dinge werden sehr schnell unordentlich.

Ich denke, ich wäre besser dran, wenn ich den extends-Ansatz nicht verwende, sondern eine Instanz des Low-Level-Parsers in der Klasse der höheren Parser - aber ich bin mir nicht sicher, wie ich das machen soll Jede Instanz würde nur einen Strom von Eingabezeichen sehen.

Hier ist ein Teil der untersten Ebene Parser -

class VulgarFractionParser extends RegexParsers { 
    override type Elem = Char 

override val whiteSpace = "".r 

dann, dass ich verlängern wie

class NumberParser extends VulgarFractionParser with Positional { 

Aber an diesem Punkt die NumberParser explizit Leerzeichen genau wie die FractionParser handhaben müssen. Für den NumberParser ist es immer noch ziemlich überschaubar - aber auf der nächsten Ebene möchte ich wirklich nur Produktionen definieren können, die Leerzeichen als Trennzeichen verwenden, genau wie ein normaler regexParser.

wäre ein Beispiel so etwas wie:

IBM 33.33/ 1200.00 
or 
IBM 33.33/33.50 1200.00 

Der zweite Wert manchmal haben zwei durch eine getrennten Teile „/“ und manchmal nur einen einzigen Teil mit nichts hinter dem Schrägstrich (oder sogar einen Schrägstrich nicht enthält, überhaupt).

+0

Können Sie einige Beispiele von Produktionen nennen, die Whitespace berücksichtigen sollten, und einige Beispiele von Produktionen, die Whitespace nicht berücksichtigen sollten? – sarnold

+0

aktualisiert die Frage mit einem Beispiel für die Daten und eines der whitespace-sensitiven Elemente. – malsmith

Antwort

2

Macht es nicht mehr Sinn machen, den ersten Parser in einen Token-Parser (a Lexer, wirklich) zu drehen, und die zweite Parser Lese machen, dass statt von einfach Char?

+1

Ich habe kein Beispiel für diesen Ansatz gesehen, aber es klingt mehr wie ich will. – malsmith

Verwandte Themen