PEG Library - Revision history

Sandrod: /* Internal DSL */

2009-08-24T15:58:53Z

‎Internal DSL

2009-08-19T21:39:56Z

‎Debugging the parser

2009-08-19T19:01:39Z

2009-08-19T19:00:20Z

‎Internal DSL

2009-08-19T18:53:57Z

‎Internal DSL

2009-08-19T18:52:22Z

‎Internal DSL

2009-08-19T18:50:34Z

‎Basic classes

2009-08-19T18:49:37Z

‎Basic classes

2009-08-17T15:54:01Z

‎Internal DSL

2009-08-12T17:13:52Z

‎Advanced error handling

← Older revision		Revision as of 15:58, 24 August 2009
Line 28:		Line 28:


−	Additionally there is the operator '\|+' which ~~acts~~ like the binary '+' operator. In contrast to it, ~~it inserts~~ a <code>whitespace*</code> parser between the two operands. As it is often needed it makes sense to define it as ~~an operator~~.	+	Additionally there is the operator '\|+' and the '\|&' operator which act like the binary '+' operator. In contrast to it, they insert a <code>whitespace*</code> (for '\|+') or a <code>whitespace+</code> (for '\|&') parser between the two operands. As it is often needed it makes sense to define them as operators.

	Be aware of a common mistake in combination with the binary '\|'/'+' operators. If for instance you define an identifier as:		Be aware of a common mistake in combination with the binary '\|'/'+' operators. If for instance you define an identifier as:

← Older revision		Revision as of 21:39, 19 August 2009
Line 130:		Line 130:
	</code>		</code>
	==Debugging the parser==		==Debugging the parser==
		+	Mostly, while building a parser, we want to know what exactly is being parsed and why for instance the parse process failed. For this purpose the debug option "peg" can be activated in Eiffel Studio.
		+	Now when you try to parse a string you will always see a short serialization of the current parser, the current character and the string left to parse.
		+	While this is useful, in big grammars it is difficult to keep an overview and we may not know where we are in the grammar. That's why parsers can have a 'name'. The name is display instead of the serialization and helps navigate the "parsing stack".
		+
		+	<code>
		+	identifier.set_name ("identifier")
		+	</code>

@@ Line 36: / Line 36: @@
 If you go on and define two new parsers based on the latter one:
 <code>
-identifier2 := identifier |+ identifier
+identifier2 := identifier + a
-identifier3 := identifier |+ identifier |+ identifier
+identifier3 := identifier + a + b
 </code>
 To prevent this problem identifier has to be fixated:
 <code>

@@ Line 32: / Line 32: @@
 Be aware of a common mistake in combination with the binary '|'/'+' operators. If for instance you define an identifier as:
 <code>
-identifier := a_to_z + (- (a_to_z + underscore))
+identifier := a_to_z + (- (a_to_z | underscore))
 </code>
 If you go on and define two new parsers based on the latter one:

@@ Line 11: / Line 11: @@
 ==Internal DSL==
-Objects can be combined via features, but the easier way is to use the defined operators. For instance if we want to define the simple grammar <code>'a' 'b' 'c'* </code> we will simply write:
+Objects can be combined via features, but the easier way is to use the defined operators. For instance if we want to define the simple grammar
-<code>a + b + (-c)</code>
+<code>
 Where a, b, c are already defined as character parsers parsing the right character (PEG_CHARACTER). The '+' operator concatenates the parsers to a sequence (PEG_SEQUENCE), while the prefix operator '-' wraps c into a one or more parser (PEG_ONE_OR_MORE).
 All the operators are:

@@ Line 4: / Line 4: @@
 All parsers inherit from PEG_ABSTRACT_PEG which defines the common functionalities. The parsers are the same as in the definition of Wikipedia with additional classes like whitespace support.
-The parsers are combined to a object hierarchy which defines the grammar. A string can then be parsed via the the feature <code>parser.parse_string ("Some source")</code> on the root object.
+The parsers are combined to a object hierarchy which defines the grammar. A string can then be parsed via the feature
 ==Internal DSL==

@@ Line 2: / Line 2: @@
 ==Basic classes==
-All the parsers inherit from PEG_ABSTRACT_PEG which defines the common functionalities. The parsers are the same as in the definition of Wikipedia with the additional classes like whitespace support.
+All parsers inherit from PEG_ABSTRACT_PEG which defines the common functionalities. The parsers are the same as in the definition of Wikipedia with additional classes like whitespace support.
 The parsers are combined to a object hierarchy which defines the grammar. A string can then be parsed via the the feature <code>parser.parse_string ("Some source")</code> on the root object.

@@ Line 29: / Line 29: @@
 identifier3 := identifier |+ identifier |+ identifier
 </code>
-.. then you won't get the expected result. Since the + operator (as well as |+ and |) reuse the Sequence instance, identifier32 use the sequence of identifier and add this very same instance to it. identifier3 will then use that corrupted identifier object which leads to unexpected behaviour while parsing.
+.. then you won't get the expected result. Since the + operator (as well as |+ and |) reuses the Sequence instance, <code>identifier2</code> uses the sequence of <code>identifier</code> and adds this very same instance to it. identifier3 will then use that corrupted identifier object which leads to unexpected behaviour while parsing.
 To prevent this problem identifier has to be fixated:
 <code>

@@ Line 94: / Line 94: @@
 ===Advanced error handling===
 Most of the times source code can have semantic errors which can't be detected directly via the syntax. There is the possibility of analyzing the domain model ''after'' it has been generated. With PEGs we can directly interfere with the parsing process and add errors/warnings to the output (<code>PEG_PARSER_RESULT</code>).
-If we have the building agents defined we can validate them in the same feature. As an example we take the previously defined list grammar and expand it:
+If we have the building agents defined we can validate them in the same feature. As an example we take the previously defined list grammar and expand it by raising an error and stopping the parsing process, if the name is not in the database (assuming there is a database of names):
 <code>
 build_list_item (a_result: PEG_PARSER_RESULT): PEG_PARSER_RESULT
@@ Line 102: / Line 102: @@
 	do
 		Result := a_result
+		create l_list_item.make
 		if attached {STRING} Result.internal_result.first as l_name then
-			create l_list_item.make_with_name (l_name)
+			if database.has (l_name)
 		end
-		Result.replace_result (l_name)
+		Result.replace_result (l_list_item)
 	end
 </code>