EiffelStudio: an EiffelSoftware project - User contributions [en]

User:Maser

2011-12-11T13:53:44Z

Maser: /* Martin Luder */ removing my contact information

=Martin Luder=

==Work==
[[Syntax checking]] project

Syntax checking/Parser

2006-07-11T08:49:11Z

Maser: /* TODO */

[[Category:Projects]]
[[Category:Editor]]
[[Syntax_checking|back to Syntax checking page]]

== TODO ==

=== Refactoring ===
* change indirect inheritance of EIFFEL_PARSER_SKELETON via EIFFEL_PARSER_ERROR_REPORTER in EIFFEL_PARSER.

=== report a lot more errors ===

=== classes with errors to check if parser works ===
* See [http://origo.ethz.ch/pipermail/es-devel/2006-June/000372.html this post] on the es-devel mailing list. It's probably better to wait, as we don't really have too much time left.

==Important Classes/Files==

====eiffel.y / eiffel.l====
* Eiffel grammar description.
* create EIFFEL_SCANNER, EIFFEL_PARSER and EIFFEL_TOKENS from these files using the makefile in $EIFFEL_SRC/Eiffel/parser/parser/
====EIFFEL_TOKENS====
* defines the tokens
====EIFFEL_SCANNER====
* reads list of tokens from file/string
====EIFFEL_PARSER====
* inherits from EIFFEL_PARSER_SKELETON (where the features parse, parse_string, make_with_factory are implemented)
* make_with_factory (a_factory: AST_FACTORY): give argument of type AST_NULL_FACTORY (inherits from AST_FACTORY)
** AST_NULL_FACTORY doesn't build an AST (AST_FACTORY does, the AST is in EIFFEL_PARSER.root_node after parsing)
* parse (a_file: KL_BINARY_INPUT_FILE) and parse_from_string (a_string: STRING).
====EIFFEL_PARSER_ERROR_REPORTER====
* provides error reporting features (report_*)
====EIFFEL_AST====
* base class of AST nodes
====ERROR====
* deferred; superclass of all error types like EIFFEL_ERROR or SYNTAX_ERROR
* features line, column: INTEGER give location of error
====ERROR_HANDLER====
* feature error_list: ERROR is a list of errors found by the parser
====SHARED_ERROR_HANDLER====
* singleton used by all relevant classes
====EIFFEL_CLASS_C====
* features build_ast and parse_ast show how the parser can be used.

== creating a project that uses the parser ==
The new build (June 11 2006) finally has the new system configuration GUI. It's quite easy to create a project that uses the parser:
# set ISE_LIBRARY to your checkout (ie. the directory that contains the 'library' subdirectory)
# start EiffelStudio and create a new project
# open Project > Project settings...
# go to Target > Group (on the left)
# click on the library icon (the one with books on it) and add the gobo library
# click on the icon again, type 'parser' in the Name field and set the location to $ISE_LIBRARY/Eiffel/parser/parser.ecf

Now you can use the parser.

* [http://n.ethz.ch/student/luderm/es/root_class.e example of an application that uses the parser]

== Tools ==
* [http://meld.sourceforge.net/ meld]
* [http://furius.ca/xxdiff/ xxdiff]
* [http://www.gobosoft.com/eiffel/gobo/geyacc/ geyacc]

== Grammar definition file (eiffel.y) ==

some general information:
* capitalized names like TE_STR_LT are tokens. Search for them in eiffel.l (lower case L):
\""<"\" {
ast_factory.set_buffer (token_buffer2, Current)
last_token := TE_STR_LT
}
So TE_STR_LT corresponds to '<' (\""<"\" is a regular expression)
* all other names are non-terminals, so you can find them in eiffel.y. If you don't know what a non-terminal means, you can always look it up in eiffel.y or ask the person responsible for that part of the file.

=== changes ===
There are several types of changes we can do to the eiffel.y file while merging Paul's eiffel.y and the current eiffel.y:

==== renaming ====
This doesn't really change the functionality and shouldn't really be a problem.

Example: Paul renamed infix_operator to infix_string (for whatever reasons).

==== new non-terminals ====
new Non-terminals are introduced because they simplify an existing rule or simplify error handling.

Example:

current version:
Default_manifest_string:
Non_empty_string
{ $$ := $1 }
| TE_EMPTY_STRING
{
$$ := ast_factory.new_string_as ("", line, column, string_position, position + text_count - string_position, token_buffer2)
}
| TE_EMPTY_VERBATIM_STRING
{
$$ := ast_factory.new_verbatim_string_as ("", verbatim_marker.substring (2, verbatim_marker.count), not has_old_verbatim_strings and then verbatim_marker.item (1) = ']', line, column, string_position, position + text_count - string_position, token_buffer2)
}
;

changed to:
Default_manifest_string:
Non_empty_string
{ $$ := $1 }
| Empty_string
{ $$ := $1 }
;

Empty_string:
TE_EMPTY_STRING
{ $$ := ast_factory.new_string_as ("", line, column, string_position, position + text_count - string_position, token_buffer2) }
| TE_EMPTY_VERBATIM_STRING
{ $$ := ast_factory.new_verbatim_string_as ("", verbatim_marker.substring (2, verbatim_marker.count), not has_old_verbatim_strings and then verbatim_marker.item (1) = ']', line, column, string_position, position + text_count - string_position, token_buffer2) }
;

==== new rules for error handling ====
Rules added to non-terminals to do error handling

Example:

current Obsolete non-terminal:

Obsolete: -- Empty
-- { $$ := Void }
| TE_OBSOLETE Manifest_string
{
$$ := ast_factory.new_keyword_string_pair ($1, $2)
}
;

Paul's Obsolete non-terminal:

Obsolete: -- Empty
-- { $$ := Void }
| TE_OBSOLETE Manifest_string
{
$$ := ast_factory.new_keyword_string_pair ($1, $2)
}
| TE_OBSOLETE error { report_expected_after_error (parser_errors.obsolete_keyword, $1, parser_errors.obsolete_string, False) }
;

==== changed error handling ====
Already existing error handling in eiffel.y is usually longer than Paul's error handling. That's mainly because he put that code into features.

Example:

current version:

Inheritance: -- Empty
-- { $$ := Void }
| TE_INHERIT ASemi
{
if has_syntax_warning then
Error_handler.insert_warning (
create {SYNTAX_WARNING}.make (line, column, filename,
"Use `inherit ANY' or do not specify an empty inherit clause"))
end
--- $$ := Void
$$ := ast_factory.new_eiffel_list_parent_as (0)
if $$ /= Void then
$$.set_inherit_keyword ($1)
end
}
[...]
;

Paul's version:

Inheritance: -- Empty
-- { $$ := Void }
| TE_INHERIT ASemi
{
report_warning (parser_errors.empty_inherit_clause_warning, Void)
$$ := ast_factory.new_eiffel_list_parent_as (0)
if $$ /= Void then
$$.set_inherit_keyword ($1)
end
}
[...]
;

== BON diagrams ==

=== Parser ===

[[Image:SynChé BON PARSER.png]]

=== SYNTAX_MESSAGE descendants ===

[[Image:SynChé BON SYNTAX MESSAGE.png]]

Syntax checking/Parser

2006-06-30T10:27:06Z

Maser: added BON diagrams

[[Category:Projects]]
[[Category:Editor]]
[[Syntax_checking|back to Syntax checking page]]

== TODO ==

=== eiffel.y & eiffel.l: merging current file with Paul's (done) ===
==== didn't work out too good! ====
* Ueli: 0 - 844: Parent_List (done)
* Marko: 845 - 1494 Formal Generics (done)
* Michi: 1495 - 2130 Instruction Call (done)
* Martin: 2131 - end, eiffel.l (done)

=== error handling classes (done) ===
*Chrigu

=== get recoverable parser working in ES (done) ===

=== classes with errors to check if parser works ===
* See [http://origo.ethz.ch/pipermail/es-devel/2006-June/000372.html this post] on the es-devel mailing list. It's probably better to wait, as we don't really have too much time left.

==Important Classes/Files==

====eiffel.y / eiffel.l====
* Eiffel grammar description.
* create EIFFEL_SCANNER, EIFFEL_PARSER and EIFFEL_TOKENS from these files using the makefile in $EIFFEL_SRC/Eiffel/parser/parser/
====EIFFEL_TOKENS====
* defines the tokens
====EIFFEL_SCANNER====
* reads list of tokens from file/string
====EIFFEL_PARSER====
* inherits from EIFFEL_PARSER_SKELETON (where the features parse, parse_string, make_with_factory are implemented)
* make_with_factory (a_factory: AST_FACTORY): give argument of type AST_NULL_FACTORY (inherits from AST_FACTORY)
** AST_NULL_FACTORY doesn't build an AST (AST_FACTORY does, the AST is in EIFFEL_PARSER.root_node after parsing)
* parse (a_file: KL_BINARY_INPUT_FILE) and parse_from_string (a_string: STRING).
====EIFFEL_PARSER_ERROR_REPORTER====
* provides error reporting features (report_*)
====EIFFEL_AST====
* base class of AST nodes
====ERROR====
* deferred; superclass of all error types like EIFFEL_ERROR or SYNTAX_ERROR
* features line, column: INTEGER give location of error
====ERROR_HANDLER====
* feature error_list: ERROR is a list of errors found by the parser
====SHARED_ERROR_HANDLER====
* singleton used by all relevant classes
====EIFFEL_CLASS_C====
* features build_ast and parse_ast show how the parser can be used.

== creating a project that uses the parser ==
The new build (June 11 2006) finally has the new system configuration GUI. It's quite easy to create a project that uses the parser:
# set ISE_LIBRARY to your checkout (ie. the directory that contains the 'library' subdirectory)
# start EiffelStudio and create a new project
# open Project > Project settings...
# go to Target > Group (on the left)
# click on the library icon (the one with books on it) and add the gobo library
# click on the icon again, type 'parser' in the Name field and set the location to $ISE_LIBRARY/Eiffel/parser/parser.ecf

Now you can use the parser.

* [http://n.ethz.ch/student/luderm/es/root_class.e example of an application that uses the parser]

== Tools ==
* [http://meld.sourceforge.net/ meld]
* [http://furius.ca/xxdiff/ xxdiff]
* [http://www.gobosoft.com/eiffel/gobo/geyacc/ geyacc]

== Grammar definition file (eiffel.y) ==

some general information:
* capitalized names like TE_STR_LT are tokens. Search for them in eiffel.l (lower case L):
\""<"\" {
ast_factory.set_buffer (token_buffer2, Current)
last_token := TE_STR_LT
}
So TE_STR_LT corresponds to '<' (\""<"\" is a regular expression)
* all other names are non-terminals, so you can find them in eiffel.y. If you don't know what a non-terminal means, you can always look it up in eiffel.y or ask the person responsible for that part of the file.

=== changes ===
There are several types of changes we can do to the eiffel.y file while merging Paul's eiffel.y and the current eiffel.y:

==== renaming ====
This doesn't really change the functionality and shouldn't really be a problem.

Example: Paul renamed infix_operator to infix_string (for whatever reasons).

==== new non-terminals ====
new Non-terminals are introduced because they simplify an existing rule or simplify error handling.

Example:

current version:
Default_manifest_string:
Non_empty_string
{ $$ := $1 }
| TE_EMPTY_STRING
{
$$ := ast_factory.new_string_as ("", line, column, string_position, position + text_count - string_position, token_buffer2)
}
| TE_EMPTY_VERBATIM_STRING
{
$$ := ast_factory.new_verbatim_string_as ("", verbatim_marker.substring (2, verbatim_marker.count), not has_old_verbatim_strings and then verbatim_marker.item (1) = ']', line, column, string_position, position + text_count - string_position, token_buffer2)
}
;

changed to:
Default_manifest_string:
Non_empty_string
{ $$ := $1 }
| Empty_string
{ $$ := $1 }
;

Empty_string:
TE_EMPTY_STRING
{ $$ := ast_factory.new_string_as ("", line, column, string_position, position + text_count - string_position, token_buffer2) }
| TE_EMPTY_VERBATIM_STRING
{ $$ := ast_factory.new_verbatim_string_as ("", verbatim_marker.substring (2, verbatim_marker.count), not has_old_verbatim_strings and then verbatim_marker.item (1) = ']', line, column, string_position, position + text_count - string_position, token_buffer2) }
;

==== new rules for error handling ====
Rules added to non-terminals to do error handling

Example:

current Obsolete non-terminal:

Obsolete: -- Empty
-- { $$ := Void }
| TE_OBSOLETE Manifest_string
{
$$ := ast_factory.new_keyword_string_pair ($1, $2)
}
;

Paul's Obsolete non-terminal:

Obsolete: -- Empty
-- { $$ := Void }
| TE_OBSOLETE Manifest_string
{
$$ := ast_factory.new_keyword_string_pair ($1, $2)
}
| TE_OBSOLETE error { report_expected_after_error (parser_errors.obsolete_keyword, $1, parser_errors.obsolete_string, False) }
;

==== changed error handling ====
Already existing error handling in eiffel.y is usually longer than Paul's error handling. That's mainly because he put that code into features.

Example:

current version:

Inheritance: -- Empty
-- { $$ := Void }
| TE_INHERIT ASemi
{
if has_syntax_warning then
Error_handler.insert_warning (
create {SYNTAX_WARNING}.make (line, column, filename,
"Use `inherit ANY' or do not specify an empty inherit clause"))
end
--- $$ := Void
$$ := ast_factory.new_eiffel_list_parent_as (0)
if $$ /= Void then
$$.set_inherit_keyword ($1)
end
}
[...]
;

Paul's version:

Inheritance: -- Empty
-- { $$ := Void }
| TE_INHERIT ASemi
{
report_warning (parser_errors.empty_inherit_clause_warning, Void)
$$ := ast_factory.new_eiffel_list_parent_as (0)
if $$ /= Void then
$$.set_inherit_keyword ($1)
end
}
[...]
;

== BON diagrams ==

=== Parser ===

[[Image:SynChé BON PARSER.png]]

=== SYNTAX_MESSAGE descendants ===

[[Image:SynChé BON SYNTAX MESSAGE.png]]

File:SynChé BON SYNTAX MESSAGE.png

2006-06-30T10:22:33Z

Maser: BON diagram of the syntax message classes

BON diagram of the syntax message classes

File:SynChé BON PARSER.png

2006-06-30T10:21:33Z

Maser: BON diagram of the parser library with the changes of the SynChé group

BON diagram of the parser library with the changes of the SynChé group

Internationalization/plural forms

2006-06-28T13:34:39Z

Maser: /* Rules */ added arabic

[[Category:Internationalization]]

The information about the plural form selection has to be stored in the header entry of the PO file (the one with the empty msgid string). The plural form information looks like this:
::Plural-Forms: nplurals=2; plural=n == 1 ? 0 : 1;

The ''nplurals'' value must be a decimal number which specifies how many different plural forms exist for this language. The string following plural is an expression which is using the C language syntax. Exceptions are that no negative numbers are allowed, numbers must be decimal, and the only variable allowed is ''n''. This expression will be evaluated whenever one of the [[internationalization/translation_function|translation function]] for a "plural form" is called. The numeric value passed to these functions is then substituted for all uses of the variable n in the expression. The resulting value then must be greater or equal to zero and smaller than the value given as the value of ''nplurals''.

==Rules==
The (at this point) known rules are:
===Only one form===

Some languages only require one single form. There is no distinction between the singular and plural form. An appropriate header entry would look like this:

:Plural-Forms: nplurals=1; plural=0;

:Languages with this property include:
:*Finno-Ugric family
:**Hungarian
:*Asian family
:**Japanese, Korean
:*Turkic/Altaic family
:**Turkish

===Two forms, singular used for one only===

This is the form used in most existing programs since it is what English is using. A header entry would look like this:

:Plural-Forms: nplurals=2; plural=n != 1;
:::(Note: this uses the feature of C expressions that boolean expressions have to value zero or one.)

:Languages with this property include:
:*Germanic family
:**Danish, Dutch, English, German, Norwegian, Swedish
:*Finno-Ugric family
:**Estonian, Finnish
:*Latin/Greek family
:**Greek
:*Semitic family
:**Hebrew
:*Romanic family
:**Italian, Portuguese, Spanish
:*Artificial
:**Esperanto

===Two forms, singular used for zero and one===

Exceptional case in the language family. The header entry would be:

:Plural-Forms: nplurals=2; plural=n>1;

:Languages with this property include:
:*Romanic family
:**French, Brazilian Portuguese

===Three forms, special case for zero===

The header entry would be:

:Plural-Forms: nplurals=3; plural=n%10==1 && n%100!=11 ? 0 : n != 0 ? 1 : 2;

:Languages with this property include:
:*Baltic family
:**Latvian

===Three forms, special cases for one and two===
The header entry would be:

:Plural-Forms: nplurals=3; plural=n==1 ? 0 : n==2 ? 1 : 2;

:Languages with this property include:
:*Celtic
:**Gaeilge (Irish)
:*Semitic family
:**Arabic

===Three forms, special case for numbers ending in 1[2-9]===

The header entry would look like this:

:Plural-Forms: nplurals=3; \
::plural=n%10==1 && n%100!=11 ? 0 : \
::::::::n%10>=2 && (n%100<10 || n%100>=20) ? 1 : 2;

:Languages with this property include:
:*Baltic family
:**Lithuanian

===Three forms, special cases for numbers ending in 1 and 2, 3, 4, except those ending in 1[1-4]===

The header entry would look like this:

:Plural-Forms: nplurals=3; \
::plural=n%10==1 && n%100!=11 ? 0 : \
::::n%10>=2 && n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2;

:Languages with this property include:
:*Slavic family
:**Croatian, Czech, Russian, Slovak, Ukrainian

===Three forms, special case for one and some numbers ending in 2, 3, or 4===

The header entry would look like this:

:Plural-Forms: nplurals=3; \
::plural=n==1 ? 0 : \
::::n%10>=2 && n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2;

:Languages with this property include:
:*Slavic family
:**Polish

===Four forms, special case for one and all numbers ending in 02, 03, or 04===

The header entry would look like this:

:Plural-Forms: nplurals=4; \
::plural=n%100==1 ? 0 : n%100==2 ? 1 : n%100==3 || n%100==4 ? 2 : 3;

:Languages with this property include:
:*Slavic family
:**Slovenian

Syntax checking/Parser

2006-06-26T14:42:02Z

Maser: /* eiffel.y & eiffel.l: merging current file with Paul's */ done

Syntax checking/Parser

2006-06-25T17:11:25Z

Maser: /* TODO */ updated

[[Category:Projects]]
[[Category:Editor]]
[[Syntax_checking|back to Syntax checking page]]

== TODO ==

=== eiffel.y & eiffel.l: merging current file with Paul's===
==== didn't work out too good! ====
* Ueli: 0 - 844: Parent_List (done)
* Marko: 845 - 1494 Formal Generics (done)
* Michi: 1495 - 2130 Instruction Call (done)
* Martin: 2131 - end, eiffel.l (done)

=== error handling classes (done) ===
*Chrigu

=== get recoverable parser working in ES (done) ===

=== classes with errors to check if parser works ===
* See [http://origo.ethz.ch/pipermail/es-devel/2006-June/000372.html this post] on the es-devel mailing list. It's probably better to wait, as we don't really have too much time left.

==Important Classes/Files==

====eiffel.y / eiffel.l====
* Eiffel grammar description.
* create EIFFEL_SCANNER, EIFFEL_PARSER and EIFFEL_TOKENS from these files using the makefile in $EIFFEL_SRC/Eiffel/parser/parser/
====EIFFEL_TOKENS====
* defines the tokens
====EIFFEL_SCANNER====
* reads list of tokens from file/string
====EIFFEL_PARSER====
* inherits from EIFFEL_PARSER_SKELETON (where the features parse, parse_string, make_with_factory are implemented)
* make_with_factory (a_factory: AST_FACTORY): give argument of type AST_NULL_FACTORY (inherits from AST_FACTORY)
** AST_NULL_FACTORY doesn't build an AST (AST_FACTORY does, the AST is in EIFFEL_PARSER.root_node after parsing)
* parse (a_file: KL_BINARY_INPUT_FILE) and parse_from_string (a_string: STRING).
====EIFFEL_PARSER_ERROR_REPORTER====
* provides error reporting features (report_*)
====EIFFEL_AST====
* base class of AST nodes
====ERROR====
* deferred; superclass of all error types like EIFFEL_ERROR or SYNTAX_ERROR
* features line, column: INTEGER give location of error
====ERROR_HANDLER====
* feature error_list: ERROR is a list of errors found by the parser
====SHARED_ERROR_HANDLER====
* singleton used by all relevant classes
====EIFFEL_CLASS_C====
* features build_ast and parse_ast show how the parser can be used.

== creating a project that uses the parser ==
The new build (June 11 2006) finally has the new system configuration GUI. It's quite easy to create a project that uses the parser:
# set ISE_LIBRARY to your checkout (ie. the directory that contains the 'library' subdirectory)
# start EiffelStudio and create a new project
# open Project > Project settings...
# go to Target > Group (on the left)
# click on the library icon (the one with books on it) and add the gobo library
# click on the icon again, type 'parser' in the Name field and set the location to $ISE_LIBRARY/Eiffel/parser/parser.ecf

Now you can use the parser.

* [http://n.ethz.ch/student/luderm/es/root_class.e example of an application that uses the parser]

== Tools ==
* [http://meld.sourceforge.net/ meld]
* [http://furius.ca/xxdiff/ xxdiff]
* [http://www.gobosoft.com/eiffel/gobo/geyacc/ geyacc]

== Grammar definition file (eiffel.y) ==

some general information:
* capitalized names like TE_STR_LT are tokens. Search for them in eiffel.l (lower case L):
\""<"\" {
ast_factory.set_buffer (token_buffer2, Current)
last_token := TE_STR_LT
}
So TE_STR_LT corresponds to '<' (\""<"\" is a regular expression)
* all other names are non-terminals, so you can find them in eiffel.y. If you don't know what a non-terminal means, you can always look it up in eiffel.y or ask the person responsible for that part of the file.

=== changes ===
There are several types of changes we can do to the eiffel.y file while merging Paul's eiffel.y and the current eiffel.y:

==== renaming ====
This doesn't really change the functionality and shouldn't really be a problem.

Example: Paul renamed infix_operator to infix_string (for whatever reasons).

==== new non-terminals ====
new Non-terminals are introduced because they simplify an existing rule or simplify error handling.

Example:

current version:
Default_manifest_string:
Non_empty_string
{ $$ := $1 }
| TE_EMPTY_STRING
{
$$ := ast_factory.new_string_as ("", line, column, string_position, position + text_count - string_position, token_buffer2)
}
| TE_EMPTY_VERBATIM_STRING
{
$$ := ast_factory.new_verbatim_string_as ("", verbatim_marker.substring (2, verbatim_marker.count), not has_old_verbatim_strings and then verbatim_marker.item (1) = ']', line, column, string_position, position + text_count - string_position, token_buffer2)
}
;

changed to:
Default_manifest_string:
Non_empty_string
{ $$ := $1 }
| Empty_string
{ $$ := $1 }
;

Empty_string:
TE_EMPTY_STRING
{ $$ := ast_factory.new_string_as ("", line, column, string_position, position + text_count - string_position, token_buffer2) }
| TE_EMPTY_VERBATIM_STRING
{ $$ := ast_factory.new_verbatim_string_as ("", verbatim_marker.substring (2, verbatim_marker.count), not has_old_verbatim_strings and then verbatim_marker.item (1) = ']', line, column, string_position, position + text_count - string_position, token_buffer2) }
;

==== new rules for error handling ====
Rules added to non-terminals to do error handling

Example:

current Obsolete non-terminal:

Obsolete: -- Empty
-- { $$ := Void }
| TE_OBSOLETE Manifest_string
{
$$ := ast_factory.new_keyword_string_pair ($1, $2)
}
;

Paul's Obsolete non-terminal:

Obsolete: -- Empty
-- { $$ := Void }
| TE_OBSOLETE Manifest_string
{
$$ := ast_factory.new_keyword_string_pair ($1, $2)
}
| TE_OBSOLETE error { report_expected_after_error (parser_errors.obsolete_keyword, $1, parser_errors.obsolete_string, False) }
;

==== changed error handling ====
Already existing error handling in eiffel.y is usually longer than Paul's error handling. That's mainly because he put that code into features.

Example:

current version:

Inheritance: -- Empty
-- { $$ := Void }
| TE_INHERIT ASemi
{
if has_syntax_warning then
Error_handler.insert_warning (
create {SYNTAX_WARNING}.make (line, column, filename,
"Use `inherit ANY' or do not specify an empty inherit clause"))
end
--- $$ := Void
$$ := ast_factory.new_eiffel_list_parent_as (0)
if $$ /= Void then
$$.set_inherit_keyword ($1)
end
}
[...]
;

Paul's version:

Inheritance: -- Empty
-- { $$ := Void }
| TE_INHERIT ASemi
{
report_warning (parser_errors.empty_inherit_clause_warning, Void)
$$ := ast_factory.new_eiffel_list_parent_as (0)
if $$ /= Void then
$$.set_inherit_keyword ($1)
end
}
[...]
;

Syntax checking/Parser

2006-06-21T12:28:23Z

Maser: moved TODO to the top

[[Category:Projects]]
[[Category:Editor]]
[[Syntax_checking|back to Syntax checking page]]

== TODO ==

=== eiffel.y & eiffel.l: merging current file with Paul's===
* Ueli: 0 - 844: Parent_List (done)
* Marko: 845 - 1494 Formal Generics (done)
* Michi: 1495 - 2130 Instruction Call (done)
* Martin: 2131 - end, eiffel.l (done)

=== error handling classes ===
*Chrigu

=== correct bugs in parser (that we introduced) ===

=== get recoverable parser working in ES ===

=== extend/improve error reporting ===
There will probably be not enough time to do this.
* there's no error reporting with TUPLEs yet

=== classes with errors to check if parser works ===
* See [http://origo.ethz.ch/pipermail/es-devel/2006-June/000372.html this post] on the es-devel mailing list. It's probably better to wait, as we don't really have too much time left.

==Important Classes/Files==

====eiffel.y / eiffel.l====
* Eiffel grammar description.
* create EIFFEL_SCANNER, EIFFEL_PARSER and EIFFEL_TOKENS from these files using the makefile in $EIFFEL_SRC/Eiffel/parser/parser/
====EIFFEL_TOKENS====
* defines the tokens
====EIFFEL_SCANNER====
* reads list of tokens from file/string
====EIFFEL_PARSER====
* inherits from EIFFEL_PARSER_SKELETON (where the features parse, parse_string, make_with_factory are implemented)
* make_with_factory (a_factory: AST_FACTORY): give argument of type AST_NULL_FACTORY (inherits from AST_FACTORY)
** AST_NULL_FACTORY doesn't build an AST (AST_FACTORY does, the AST is in EIFFEL_PARSER.root_node after parsing)
* parse (a_file: KL_BINARY_INPUT_FILE) and parse_from_string (a_string: STRING).
====EIFFEL_PARSER_ERROR_REPORTER====
* provides error reporting features (report_*)
====EIFFEL_AST====
* base class of AST nodes
====ERROR====
* deferred; superclass of all error types like EIFFEL_ERROR or SYNTAX_ERROR
* features line, column: INTEGER give location of error
====ERROR_HANDLER====
* feature error_list: ERROR is a list of errors found by the parser
====SHARED_ERROR_HANDLER====
* singleton used by all relevant classes
====EIFFEL_CLASS_C====
* features build_ast and parse_ast show how the parser can be used.

== creating a project that uses the parser ==
The new build (June 11 2006) finally has the new system configuration GUI. It's quite easy to create a project that uses the parser:
# set ISE_LIBRARY to your checkout (ie. the directory that contains the 'library' subdirectory)
# start EiffelStudio and create a new project
# open Project > Project settings...
# go to Target > Group (on the left)
# click on the library icon (the one with books on it) and add the gobo library
# click on the icon again, type 'parser' in the Name field and set the location to $ISE_LIBRARY/Eiffel/parser/parser.ecf

Now you can use the parser.

* [http://n.ethz.ch/student/luderm/es/root_class.e example of an application that uses the parser]

== Tools ==
* [http://meld.sourceforge.net/ meld]
* [http://furius.ca/xxdiff/ xxdiff]
* [http://www.gobosoft.com/eiffel/gobo/geyacc/ geyacc]

== Grammar definition file (eiffel.y) ==

some general information:
* capitalized names like TE_STR_LT are tokens. Search for them in eiffel.l (lower case L):
\""<"\" {
ast_factory.set_buffer (token_buffer2, Current)
last_token := TE_STR_LT
}
So TE_STR_LT corresponds to '<' (\""<"\" is a regular expression)
* all other names are non-terminals, so you can find them in eiffel.y. If you don't know what a non-terminal means, you can always look it up in eiffel.y or ask the person responsible for that part of the file.

=== changes ===
There are several types of changes we can do to the eiffel.y file while merging Paul's eiffel.y and the current eiffel.y:

==== renaming ====
This doesn't really change the functionality and shouldn't really be a problem.

Example: Paul renamed infix_operator to infix_string (for whatever reasons).

==== new non-terminals ====
new Non-terminals are introduced because they simplify an existing rule or simplify error handling.

Example:

current version:
Default_manifest_string:
Non_empty_string
{ $$ := $1 }
| TE_EMPTY_STRING
{
$$ := ast_factory.new_string_as ("", line, column, string_position, position + text_count - string_position, token_buffer2)
}
| TE_EMPTY_VERBATIM_STRING
{
$$ := ast_factory.new_verbatim_string_as ("", verbatim_marker.substring (2, verbatim_marker.count), not has_old_verbatim_strings and then verbatim_marker.item (1) = ']', line, column, string_position, position + text_count - string_position, token_buffer2)
}
;

changed to:
Default_manifest_string:
Non_empty_string
{ $$ := $1 }
| Empty_string
{ $$ := $1 }
;

Empty_string:
TE_EMPTY_STRING
{ $$ := ast_factory.new_string_as ("", line, column, string_position, position + text_count - string_position, token_buffer2) }
| TE_EMPTY_VERBATIM_STRING
{ $$ := ast_factory.new_verbatim_string_as ("", verbatim_marker.substring (2, verbatim_marker.count), not has_old_verbatim_strings and then verbatim_marker.item (1) = ']', line, column, string_position, position + text_count - string_position, token_buffer2) }
;

==== new rules for error handling ====
Rules added to non-terminals to do error handling

Example:

current Obsolete non-terminal:

Obsolete: -- Empty
-- { $$ := Void }
| TE_OBSOLETE Manifest_string
{
$$ := ast_factory.new_keyword_string_pair ($1, $2)
}
;

Paul's Obsolete non-terminal:

Obsolete: -- Empty
-- { $$ := Void }
| TE_OBSOLETE Manifest_string
{
$$ := ast_factory.new_keyword_string_pair ($1, $2)
}
| TE_OBSOLETE error { report_expected_after_error (parser_errors.obsolete_keyword, $1, parser_errors.obsolete_string, False) }
;

==== changed error handling ====
Already existing error handling in eiffel.y is usually longer than Paul's error handling. That's mainly because he put that code into features.

Example:

current version:

Inheritance: -- Empty
-- { $$ := Void }
| TE_INHERIT ASemi
{
if has_syntax_warning then
Error_handler.insert_warning (
create {SYNTAX_WARNING}.make (line, column, filename,
"Use `inherit ANY' or do not specify an empty inherit clause"))
end
--- $$ := Void
$$ := ast_factory.new_eiffel_list_parent_as (0)
if $$ /= Void then
$$.set_inherit_keyword ($1)
end
}
[...]
;

Paul's version:

Inheritance: -- Empty
-- { $$ := Void }
| TE_INHERIT ASemi
{
report_warning (parser_errors.empty_inherit_clause_warning, Void)
$$ := ast_factory.new_eiffel_list_parent_as (0)
if $$ /= Void then
$$.set_inherit_keyword ($1)
end
}
[...]
;

Syntax checking/Parser

2006-06-21T12:27:06Z

Maser: /* Important Classes/Files */

[[Category:Projects]]
[[Category:Editor]]
[[Syntax_checking|back to Syntax checking page]]

==Important Classes/Files==

====eiffel.y / eiffel.l====
* Eiffel grammar description.
* create EIFFEL_SCANNER, EIFFEL_PARSER and EIFFEL_TOKENS from these files using the makefile in $EIFFEL_SRC/Eiffel/parser/parser/
====EIFFEL_TOKENS====
* defines the tokens
====EIFFEL_SCANNER====
* reads list of tokens from file/string
====EIFFEL_PARSER====
* inherits from EIFFEL_PARSER_SKELETON (where the features parse, parse_string, make_with_factory are implemented)
* make_with_factory (a_factory: AST_FACTORY): give argument of type AST_NULL_FACTORY (inherits from AST_FACTORY)
** AST_NULL_FACTORY doesn't build an AST (AST_FACTORY does, the AST is in EIFFEL_PARSER.root_node after parsing)
* parse (a_file: KL_BINARY_INPUT_FILE) and parse_from_string (a_string: STRING).
====EIFFEL_PARSER_ERROR_REPORTER====
* provides error reporting features (report_*)
====EIFFEL_AST====
* base class of AST nodes
====ERROR====
* deferred; superclass of all error types like EIFFEL_ERROR or SYNTAX_ERROR
* features line, column: INTEGER give location of error
====ERROR_HANDLER====
* feature error_list: ERROR is a list of errors found by the parser
====SHARED_ERROR_HANDLER====
* singleton used by all relevant classes
====EIFFEL_CLASS_C====
* features build_ast and parse_ast show how the parser can be used.

== creating a project that uses the parser ==
The new build (June 11 2006) finally has the new system configuration GUI. It's quite easy to create a project that uses the parser:
# set ISE_LIBRARY to your checkout (ie. the directory that contains the 'library' subdirectory)
# start EiffelStudio and create a new project
# open Project > Project settings...
# go to Target > Group (on the left)
# click on the library icon (the one with books on it) and add the gobo library
# click on the icon again, type 'parser' in the Name field and set the location to $ISE_LIBRARY/Eiffel/parser/parser.ecf

Now you can use the parser.

* [http://n.ethz.ch/student/luderm/es/root_class.e example of an application that uses the parser]

== TODO ==

=== eiffel.y & eiffel.l: merging current file with Paul's===
* Ueli: 0 - 844: Parent_List (done)
* Marko: 845 - 1494 Formal Generics (done)
* Michi: 1495 - 2130 Instruction Call (done)
* Martin: 2131 - end, eiffel.l (done)

=== error handling classes ===
*Chrigu

=== correct bugs in parser (that we introduced) ===

=== get recoverable parser working in ES ===

=== extend/improve error reporting ===
There will probably be not enough time to do this.
* there's no error reporting with TUPLEs yet

=== classes with errors to check if parser works ===
* See [http://origo.ethz.ch/pipermail/es-devel/2006-June/000372.html this post] on the es-devel mailing list. It's probably better to wait, as we don't really have too much time left.

== Tools ==
* [http://meld.sourceforge.net/ meld]
* [http://furius.ca/xxdiff/ xxdiff]
* [http://www.gobosoft.com/eiffel/gobo/geyacc/ geyacc]

== Grammar definition file (eiffel.y) ==

some general information:
* capitalized names like TE_STR_LT are tokens. Search for them in eiffel.l (lower case L):
\""<"\" {
ast_factory.set_buffer (token_buffer2, Current)
last_token := TE_STR_LT
}
So TE_STR_LT corresponds to '<' (\""<"\" is a regular expression)
* all other names are non-terminals, so you can find them in eiffel.y. If you don't know what a non-terminal means, you can always look it up in eiffel.y or ask the person responsible for that part of the file.

=== changes ===
There are several types of changes we can do to the eiffel.y file while merging Paul's eiffel.y and the current eiffel.y:

==== renaming ====
This doesn't really change the functionality and shouldn't really be a problem.

Example: Paul renamed infix_operator to infix_string (for whatever reasons).

==== new non-terminals ====
new Non-terminals are introduced because they simplify an existing rule or simplify error handling.

Example:

current version:
Default_manifest_string:
Non_empty_string
{ $$ := $1 }
| TE_EMPTY_STRING
{
$$ := ast_factory.new_string_as ("", line, column, string_position, position + text_count - string_position, token_buffer2)
}
| TE_EMPTY_VERBATIM_STRING
{
$$ := ast_factory.new_verbatim_string_as ("", verbatim_marker.substring (2, verbatim_marker.count), not has_old_verbatim_strings and then verbatim_marker.item (1) = ']', line, column, string_position, position + text_count - string_position, token_buffer2)
}
;

changed to:
Default_manifest_string:
Non_empty_string
{ $$ := $1 }
| Empty_string
{ $$ := $1 }
;

Empty_string:
TE_EMPTY_STRING
{ $$ := ast_factory.new_string_as ("", line, column, string_position, position + text_count - string_position, token_buffer2) }
| TE_EMPTY_VERBATIM_STRING
{ $$ := ast_factory.new_verbatim_string_as ("", verbatim_marker.substring (2, verbatim_marker.count), not has_old_verbatim_strings and then verbatim_marker.item (1) = ']', line, column, string_position, position + text_count - string_position, token_buffer2) }
;

==== new rules for error handling ====
Rules added to non-terminals to do error handling

Example:

current Obsolete non-terminal:

Obsolete: -- Empty
-- { $$ := Void }
| TE_OBSOLETE Manifest_string
{
$$ := ast_factory.new_keyword_string_pair ($1, $2)
}
;

Paul's Obsolete non-terminal:

Obsolete: -- Empty
-- { $$ := Void }
| TE_OBSOLETE Manifest_string
{
$$ := ast_factory.new_keyword_string_pair ($1, $2)
}
| TE_OBSOLETE error { report_expected_after_error (parser_errors.obsolete_keyword, $1, parser_errors.obsolete_string, False) }
;

==== changed error handling ====
Already existing error handling in eiffel.y is usually longer than Paul's error handling. That's mainly because he put that code into features.

Example:

current version:

Inheritance: -- Empty
-- { $$ := Void }
| TE_INHERIT ASemi
{
if has_syntax_warning then
Error_handler.insert_warning (
create {SYNTAX_WARNING}.make (line, column, filename,
"Use `inherit ANY' or do not specify an empty inherit clause"))
end
--- $$ := Void
$$ := ast_factory.new_eiffel_list_parent_as (0)
if $$ /= Void then
$$.set_inherit_keyword ($1)
end
}
[...]
;

Paul's version:

Inheritance: -- Empty
-- { $$ := Void }
| TE_INHERIT ASemi
{
report_warning (parser_errors.empty_inherit_clause_warning, Void)
$$ := ast_factory.new_eiffel_list_parent_as (0)
if $$ /= Void then
$$.set_inherit_keyword ($1)
end
}
[...]
;

Syntax checking/Parser

2006-06-21T12:21:56Z

Maser: /* Implementation */ removed

[[Category:Projects]]
[[Category:Editor]]
[[Syntax_checking|back to Syntax checking page]]

==Important Classes/Files==

====eiffel.y====
* Eiffel grammar description.
* use [http://www.gobosoft.com/eiffel/gobo/geyacc/ geyacc] to generate eiffel_parser.e from this file
====EIFFEL_PARSER====
* inherits from EIFFEL_PARSER_SKELETON (where the features parse, parse_string, make_with_factory are implemented)
* make_with_factory (a_factory: AST_FACTORY): give argument of type AST_NULL_FACTORY (inherits from AST_FACTORY)
** AST_NULL_FACTORY doesn't build an AST (AST_FACTORY does, the AST is in EIFFEL_PARSER.root_node after parsing)
* parse (a_file: KL_BINARY_INPUT_FILE) and parse_from_string (a_string: STRING).

====CLASS_AS====
* AST of a class
====ERROR====
* deferred; superclass of all error types like EIFFEL_ERROR or SYNTAX_ERROR
* features line, column: INTEGER give location of error
====ERROR_HANDLER====
* feature error_list: ERROR is a list of errors found by the parser
====SHARED_ERROR_HANDLER====
* singleton used by all relevant classes
====EIFFEL_CLASS_C====
* features build_ast and parse_ast show how the parser can be used.

== creating a project that uses the parser ==
The new build (June 11 2006) finally has the new system configuration GUI. It's quite easy to create a project that uses the parser:
# set ISE_LIBRARY to your checkout (ie. the directory that contains the 'library' subdirectory)
# start EiffelStudio and create a new project
# open Project > Project settings...
# go to Target > Group (on the left)
# click on the library icon (the one with books on it) and add the gobo library
# click on the icon again, type 'parser' in the Name field and set the location to $ISE_LIBRARY/Eiffel/parser/parser.ecf

Now you can use the parser.

* [http://n.ethz.ch/student/luderm/es/root_class.e example of an application that uses the parser]

== TODO ==

=== eiffel.y & eiffel.l: merging current file with Paul's===
* Ueli: 0 - 844: Parent_List (done)
* Marko: 845 - 1494 Formal Generics (done)
* Michi: 1495 - 2130 Instruction Call (done)
* Martin: 2131 - end, eiffel.l (done)

=== error handling classes ===
*Chrigu

=== correct bugs in parser (that we introduced) ===

=== get recoverable parser working in ES ===

=== extend/improve error reporting ===
There will probably be not enough time to do this.
* there's no error reporting with TUPLEs yet

=== classes with errors to check if parser works ===
* See [http://origo.ethz.ch/pipermail/es-devel/2006-June/000372.html this post] on the es-devel mailing list. It's probably better to wait, as we don't really have too much time left.

== Tools ==
* [http://meld.sourceforge.net/ meld]
* [http://furius.ca/xxdiff/ xxdiff]
* [http://www.gobosoft.com/eiffel/gobo/geyacc/ geyacc]

== Grammar definition file (eiffel.y) ==

some general information:
* capitalized names like TE_STR_LT are tokens. Search for them in eiffel.l (lower case L):
\""<"\" {
ast_factory.set_buffer (token_buffer2, Current)
last_token := TE_STR_LT
}
So TE_STR_LT corresponds to '<' (\""<"\" is a regular expression)
* all other names are non-terminals, so you can find them in eiffel.y. If you don't know what a non-terminal means, you can always look it up in eiffel.y or ask the person responsible for that part of the file.

=== changes ===
There are several types of changes we can do to the eiffel.y file while merging Paul's eiffel.y and the current eiffel.y:

==== renaming ====
This doesn't really change the functionality and shouldn't really be a problem.

Example: Paul renamed infix_operator to infix_string (for whatever reasons).

==== new non-terminals ====
new Non-terminals are introduced because they simplify an existing rule or simplify error handling.

Example:

current version:
Default_manifest_string:
Non_empty_string
{ $$ := $1 }
| TE_EMPTY_STRING
{
$$ := ast_factory.new_string_as ("", line, column, string_position, position + text_count - string_position, token_buffer2)
}
| TE_EMPTY_VERBATIM_STRING
{
$$ := ast_factory.new_verbatim_string_as ("", verbatim_marker.substring (2, verbatim_marker.count), not has_old_verbatim_strings and then verbatim_marker.item (1) = ']', line, column, string_position, position + text_count - string_position, token_buffer2)
}
;

changed to:
Default_manifest_string:
Non_empty_string
{ $$ := $1 }
| Empty_string
{ $$ := $1 }
;

Empty_string:
TE_EMPTY_STRING
{ $$ := ast_factory.new_string_as ("", line, column, string_position, position + text_count - string_position, token_buffer2) }
| TE_EMPTY_VERBATIM_STRING
{ $$ := ast_factory.new_verbatim_string_as ("", verbatim_marker.substring (2, verbatim_marker.count), not has_old_verbatim_strings and then verbatim_marker.item (1) = ']', line, column, string_position, position + text_count - string_position, token_buffer2) }
;

==== new rules for error handling ====
Rules added to non-terminals to do error handling

Example:

current Obsolete non-terminal:

Obsolete: -- Empty
-- { $$ := Void }
| TE_OBSOLETE Manifest_string
{
$$ := ast_factory.new_keyword_string_pair ($1, $2)
}
;

Paul's Obsolete non-terminal:

Obsolete: -- Empty
-- { $$ := Void }
| TE_OBSOLETE Manifest_string
{
$$ := ast_factory.new_keyword_string_pair ($1, $2)
}
| TE_OBSOLETE error { report_expected_after_error (parser_errors.obsolete_keyword, $1, parser_errors.obsolete_string, False) }
;

==== changed error handling ====
Already existing error handling in eiffel.y is usually longer than Paul's error handling. That's mainly because he put that code into features.

Example:

current version:

Inheritance: -- Empty
-- { $$ := Void }
| TE_INHERIT ASemi
{
if has_syntax_warning then
Error_handler.insert_warning (
create {SYNTAX_WARNING}.make (line, column, filename,
"Use `inherit ANY' or do not specify an empty inherit clause"))
end
--- $$ := Void
$$ := ast_factory.new_eiffel_list_parent_as (0)
if $$ /= Void then
$$.set_inherit_keyword ($1)
end
}
[...]
;

Paul's version:

Inheritance: -- Empty
-- { $$ := Void }
| TE_INHERIT ASemi
{
report_warning (parser_errors.empty_inherit_clause_warning, Void)
$$ := ast_factory.new_eiffel_list_parent_as (0)
if $$ /= Void then
$$.set_inherit_keyword ($1)
end
}
[...]
;

Syntax checking/Parser

2006-06-21T12:19:00Z

Maser: /* TODO */

[[Category:Projects]]
[[Category:Editor]]
[[Syntax_checking|back to Syntax checking page]]

==Important Classes/Files==

====eiffel.y====
* Eiffel grammar description.
* use [http://www.gobosoft.com/eiffel/gobo/geyacc/ geyacc] to generate eiffel_parser.e from this file
====EIFFEL_PARSER====
* inherits from EIFFEL_PARSER_SKELETON (where the features parse, parse_string, make_with_factory are implemented)
* make_with_factory (a_factory: AST_FACTORY): give argument of type AST_NULL_FACTORY (inherits from AST_FACTORY)
** AST_NULL_FACTORY doesn't build an AST (AST_FACTORY does, the AST is in EIFFEL_PARSER.root_node after parsing)
* parse (a_file: KL_BINARY_INPUT_FILE) and parse_from_string (a_string: STRING).

====CLASS_AS====
* AST of a class
====ERROR====
* deferred; superclass of all error types like EIFFEL_ERROR or SYNTAX_ERROR
* features line, column: INTEGER give location of error
====ERROR_HANDLER====
* feature error_list: ERROR is a list of errors found by the parser
====SHARED_ERROR_HANDLER====
* singleton used by all relevant classes
====EIFFEL_CLASS_C====
* features build_ast and parse_ast show how the parser can be used.

== creating a project that uses the parser ==
The new build (June 11 2006) finally has the new system configuration GUI. It's quite easy to create a project that uses the parser:
# set ISE_LIBRARY to your checkout (ie. the directory that contains the 'library' subdirectory)
# start EiffelStudio and create a new project
# open Project > Project settings...
# go to Target > Group (on the left)
# click on the library icon (the one with books on it) and add the gobo library
# click on the icon again, type 'parser' in the Name field and set the location to $ISE_LIBRARY/Eiffel/parser/parser.ecf

Now you can use the parser.

* [http://n.ethz.ch/student/luderm/es/root_class.e example of an application that uses the parser]

==Implementation==
* based on Paul's code
===ERROR classes===
* Create new SYNTAX_ERROR classes that correspond to Paul's classes, but fit into the current hierarchy
* store start and end position of the error
===extend parser to generate the right ERRORs===
* Integrate Paul's changes to eiffel.l and eiffel.y into the current versions.
* add facilities from Paul's EIFFEL_PARSER_ERROR_REPORTER
** in existing class like EIFFEL_PARSER_SKELETON (EP_ERROR_REPORTER only inherits SHARED_ERROR_HANDLER and so does EP_SKELETON
** in new class

== TODO ==

=== eiffel.y & eiffel.l: merging current file with Paul's===
* Ueli: 0 - 844: Parent_List (done)
* Marko: 845 - 1494 Formal Generics (done)
* Michi: 1495 - 2130 Instruction Call (done)
* Martin: 2131 - end, eiffel.l (done)

=== error handling classes ===
*Chrigu

=== correct bugs in parser (that we introduced) ===

=== get recoverable parser working in ES ===

=== extend/improve error reporting ===
There will probably be not enough time to do this.
* there's no error reporting with TUPLEs yet

=== classes with errors to check if parser works ===
* See [http://origo.ethz.ch/pipermail/es-devel/2006-June/000372.html this post] on the es-devel mailing list. It's probably better to wait, as we don't really have too much time left.

== Tools ==
* [http://meld.sourceforge.net/ meld]
* [http://furius.ca/xxdiff/ xxdiff]
* [http://www.gobosoft.com/eiffel/gobo/geyacc/ geyacc]

== Grammar definition file (eiffel.y) ==

some general information:
* capitalized names like TE_STR_LT are tokens. Search for them in eiffel.l (lower case L):
\""<"\" {
ast_factory.set_buffer (token_buffer2, Current)
last_token := TE_STR_LT
}
So TE_STR_LT corresponds to '<' (\""<"\" is a regular expression)
* all other names are non-terminals, so you can find them in eiffel.y. If you don't know what a non-terminal means, you can always look it up in eiffel.y or ask the person responsible for that part of the file.

=== changes ===
There are several types of changes we can do to the eiffel.y file while merging Paul's eiffel.y and the current eiffel.y:

==== renaming ====
This doesn't really change the functionality and shouldn't really be a problem.

Example: Paul renamed infix_operator to infix_string (for whatever reasons).

==== new non-terminals ====
new Non-terminals are introduced because they simplify an existing rule or simplify error handling.

Example:

current version:
Default_manifest_string:
Non_empty_string
{ $$ := $1 }
| TE_EMPTY_STRING
{
$$ := ast_factory.new_string_as ("", line, column, string_position, position + text_count - string_position, token_buffer2)
}
| TE_EMPTY_VERBATIM_STRING
{
$$ := ast_factory.new_verbatim_string_as ("", verbatim_marker.substring (2, verbatim_marker.count), not has_old_verbatim_strings and then verbatim_marker.item (1) = ']', line, column, string_position, position + text_count - string_position, token_buffer2)
}
;

changed to:
Default_manifest_string:
Non_empty_string
{ $$ := $1 }
| Empty_string
{ $$ := $1 }
;

Empty_string:
TE_EMPTY_STRING
{ $$ := ast_factory.new_string_as ("", line, column, string_position, position + text_count - string_position, token_buffer2) }
| TE_EMPTY_VERBATIM_STRING
{ $$ := ast_factory.new_verbatim_string_as ("", verbatim_marker.substring (2, verbatim_marker.count), not has_old_verbatim_strings and then verbatim_marker.item (1) = ']', line, column, string_position, position + text_count - string_position, token_buffer2) }
;

==== new rules for error handling ====
Rules added to non-terminals to do error handling

Example:

current Obsolete non-terminal:

Obsolete: -- Empty
-- { $$ := Void }
| TE_OBSOLETE Manifest_string
{
$$ := ast_factory.new_keyword_string_pair ($1, $2)
}
;

Paul's Obsolete non-terminal:

Obsolete: -- Empty
-- { $$ := Void }
| TE_OBSOLETE Manifest_string
{
$$ := ast_factory.new_keyword_string_pair ($1, $2)
}
| TE_OBSOLETE error { report_expected_after_error (parser_errors.obsolete_keyword, $1, parser_errors.obsolete_string, False) }
;

==== changed error handling ====
Already existing error handling in eiffel.y is usually longer than Paul's error handling. That's mainly because he put that code into features.

Example:

current version:

Inheritance: -- Empty
-- { $$ := Void }
| TE_INHERIT ASemi
{
if has_syntax_warning then
Error_handler.insert_warning (
create {SYNTAX_WARNING}.make (line, column, filename,
"Use `inherit ANY' or do not specify an empty inherit clause"))
end
--- $$ := Void
$$ := ast_factory.new_eiffel_list_parent_as (0)
if $$ /= Void then
$$.set_inherit_keyword ($1)
end
}
[...]
;

Paul's version:

Inheritance: -- Empty
-- { $$ := Void }
| TE_INHERIT ASemi
{
report_warning (parser_errors.empty_inherit_clause_warning, Void)
$$ := ast_factory.new_eiffel_list_parent_as (0)
if $$ /= Void then
$$.set_inherit_keyword ($1)
end
}
[...]
;

Syntax checking

2006-06-20T16:32:41Z

Maser: /* M6: June 27th */

[[Category:Projects]]
[[Category:Editor]]
=Overview=
The aim of this project is to provide adequate, but non intrusive feedback to user about syntax errors. This is done by checking syntax as you type and underlining syntax errors by the well knwon wavy red line. Furthermore, error descriptions and possible solutions should be provided.

The Project is named '''SynChé''', which is a combination of syntax and checking.
The ''é'' at the end is important, as a cool name needs either a recursive acronym or a special character from a non English language.

=Software Requirement Specification (SRS)=
You can find our SRS [[Syntax_checking/SRS|here]]

=Groups=

* [[Syntax_checking/Visualisation|Visualisation]]
* [[Syntax_checking/Parser|Parser]]

=Milestones=

==M1: April 25th==
* Get home-grown EiffelStudio up and running.

==M2: May 2nd==
* '''Put your name in this Wiki!'''
* Analyse source code to certain degree, so discussion about interfaces between parser and visual is possible

==M3: May 9th==
* SRS written
* Overview of relevant classes (BON diagram or more)
* Further Project Milestones specified, based on SRS and knowledge about code

== May 12th ==
'''Results of the Meeting:''' [[Syntax_checking/Visualisation| Visualisation]]

== May 17th ==
'''Results of Parser Group:''' [[Syntax_checking/Parser| Parser]]

==M4: May 23rd==
*'''Parser Group''': Find out what results you get from the parser
*'''Visualisation Group''': Write a feature that draw the red underline

==M6: June 27th==
*'''Parser Group''': Multi Error Parser (don't stop parsing after first error encountered)
*'''Visualisation Group''': Draw the mouseover boxes; find how to use stones (especially x,y coordinates -> stones/tokens); collect all parser errors into information window on bottom

=Team=
Everyone intrested in this project is welcome to join our mailinglist [http://origo.ethz.ch/cgi-bin/mailman/listinfo/es-ui es-ui@origo.ethz.ch].
At this point, the team is divided into two groups at this point, one responsible for the parser, the other one for visual feedback (like underlininig).

== Visual Feedback ==
* [[User:jabernet| Janick Bernet]] (project leader)
* [[User:fdevries| Fabien de Vries]]
* [[User:indermum| Matthias Indermühle]]
* [[User:clerco| Olivier Clerc]]

== Parser ==
* [[User:maser| Martin Luder]]
* [[User:Chrigu| Christoph Huber]]
* [[User:goalgettah| Ueli Etter]]
* [[User:Squeezie| Michael Schär]]
* [[User:MarkoR| Marko Ristin]]

== Assistant ==
* [[User:classens| Stephan Classen]]

Syntax checking

2006-06-15T13:07:44Z

Maser: /* M4: May 23rd */

[[Category:Projects]]
[[Category:Editor]]
=Overview=
The aim of this project is to provide adequate, but non intrusive feedback to user about syntax errors. This is done by checking syntax as you type and underlining syntax errors by the well knwon wavy red line. Furthermore, error descriptions and possible solutions should be provided.

The Project is named '''SynChé''', which is a combination of syntax and checking.
The ''é'' at the end is important, as a cool name needs either a recursive acronym or a special character from a non English language.

=Software Requirement Specification (SRS)=
You can find our SRS [[Syntax_checking/SRS|here]]

=Groups=

* [[Syntax_checking/Visualisation|Visualisation]]
* [[Syntax_checking/Parser|Parser]]

=Milestones=

==M1: April 25th==
* Get home-grown EiffelStudio up and running.

==M2: May 2nd==
* '''Put your name in this Wiki!'''
* Analyse source code to certain degree, so discussion about interfaces between parser and visual is possible

==M3: May 9th==
* SRS written
* Overview of relevant classes (BON diagram or more)
* Further Project Milestones specified, based on SRS and knowledge about code

== May 12th ==
'''Results of the Meeting:''' [[Syntax_checking/Visualisation| Visualisation]]

== May 17th ==
'''Results of Parser Group:''' [[Syntax_checking/Parser| Parser]]

==M4: May 23rd==
*'''Parser Group''': Find out what results you get from the parser
*'''Visualisation Group''': Write a feature that draw the red underline

==M6: June 15th==
*'''Parser Group''': Multi Error Parser (don't stop parsing after first error encountered)
*'''Visualisation Group''': Draw the mouseover boxes; find how to use stones (especially x,y coordinates -> stones/tokens); collect all parser errors into information window on bottom

=Team=
Everyone intrested in this project is welcome to join our mailinglist [http://origo.ethz.ch/cgi-bin/mailman/listinfo/es-ui es-ui@origo.ethz.ch].
At this point, the team is divided into two groups at this point, one responsible for the parser, the other one for visual feedback (like underlininig).

== Visual Feedback ==
* [[User:jabernet| Janick Bernet]] (project leader)
* [[User:fdevries| Fabien de Vries]]
* [[User:indermum| Matthias Indermühle]]
* [[User:clerco| Olivier Clerc]]

== Parser ==
* [[User:maser| Martin Luder]]
* [[User:Chrigu| Christoph Huber]]
* [[User:goalgettah| Ueli Etter]]
* [[User:Squeezie| Michael Schär]]
* [[User:MarkoR| Marko Ristin]]

== Assistant ==
* [[User:classens| Stephan Classen]]

Syntax checking/Parser

2006-06-12T16:19:51Z

Maser: /* classes with errors to check if parser works */

[[Syntax_checking|back to Syntax checking page]]

==Important Classes/Files==

====eiffel.y====
* Eiffel grammar description.
* use [http://www.gobosoft.com/eiffel/gobo/geyacc/ geyacc] to generate eiffel_parser.e from this file
====EIFFEL_PARSER====
* inherits from EIFFEL_PARSER_SKELETON (where the features parse, parse_string, make_with_factory are implemented)
* make_with_factory (a_factory: AST_FACTORY): give argument of type AST_NULL_FACTORY (inherits from AST_FACTORY)
** AST_NULL_FACTORY doesn't build an AST (AST_FACTORY does, the AST is in EIFFEL_PARSER.root_node after parsing)
* parse (a_file: KL_BINARY_INPUT_FILE) and parse_from_string (a_string: STRING).

====CLASS_AS====
* AST of a class
====ERROR====
* deferred; superclass of all error types like EIFFEL_ERROR or SYNTAX_ERROR
* features line, column: INTEGER give location of error
====ERROR_HANDLER====
* feature error_list: ERROR is a list of errors found by the parser
====SHARED_ERROR_HANDLER====
* singleton used by all relevant classes
====EIFFEL_CLASS_C====
* features build_ast and parse_ast show how the parser can be used.

== creating a project that uses the parser ==
The new build (June 11 2006) finally has the new system configuration GUI. It's quite easy to create a project that uses the parser:
# set ISE_LIBRARY to your checkout (ie. the directory that contains the 'library' subdirectory)
# start EiffelStudio and create a new project
# open Project > Project settings...
# go to Target > Group (on the left)
# click on the library icon (the one with books on it) and add the gobo library
# click on the icon again, type 'parser' in the Name field and set the location to $ISE_LIBRARY/Eiffel/parser/parser.ecf

Now you can use the parser.

* [http://n.ethz.ch/student/luderm/es/root_class.e example of an application that uses the parser]

==Implementation==
* based on Paul's code
===ERROR classes===
* Create new SYNTAX_ERROR classes that correspond to Paul's classes, but fit into the current hierarchy
* store start and end position of the error
===extend parser to generate the right ERRORs===
* Integrate Paul's changes to eiffel.l and eiffel.y into the current versions.
* add facilities from Paul's EIFFEL_PARSER_ERROR_REPORTER
** in existing class like EIFFEL_PARSER_SKELETON (EP_ERROR_REPORTER only inherits SHARED_ERROR_HANDLER and so does EP_SKELETON
** in new class

== Work distribution==

=== eiffel.y ===
* Ueli: 0 - 844: Parent_List
* Marko: 845 - 1494 Formal Generics
* Michi: 1495 - 2130 Instruction Call
* Martin: 2131 - end (done)

=== eiffel.l ===
* Martin: added TE_BAD_ID (done)

=== error classes ===
*Chrigu

=== classes with errors to check if parser works ===
* See [http://origo.ethz.ch/pipermail/es-devel/2006-June/000372.html this post] on the es-devel mailing list. It's probably better to wait, as we don't really have too much time left.

== Tools ==
* [http://meld.sourceforge.net/ meld]
* [http://furius.ca/xxdiff/ xxdiff]
* [http://www.gobosoft.com/eiffel/gobo/geyacc/ geyacc]

== Grammar definition file (eiffel.y) ==

some general information:
* capitalized names like TE_STR_LT are tokens. Search for them in eiffel.l (lower case L):
\""<"\" {
ast_factory.set_buffer (token_buffer2, Current)
last_token := TE_STR_LT
}
So TE_STR_LT corresponds to '<' (\""<"\" is a regular expression)
* all other names are non-terminals, so you can find them in eiffel.y. If you don't know what a non-terminal means, you can always look it up in eiffel.y or ask the person responsible for that part of the file.

=== changes ===
There are several types of changes we can do to the eiffel.y file while merging Paul's eiffel.y and the current eiffel.y:

==== renaming ====
This doesn't really change the functionality and shouldn't really be a problem.

Example: Paul renamed infix_operator to infix_string (for whatever reasons).

==== new non-terminals ====
new Non-terminals are introduced because they simplify an existing rule or simplify error handling.

Example:

current version:
Default_manifest_string:
Non_empty_string
{ $$ := $1 }
| TE_EMPTY_STRING
{
$$ := ast_factory.new_string_as ("", line, column, string_position, position + text_count - string_position, token_buffer2)
}
| TE_EMPTY_VERBATIM_STRING
{
$$ := ast_factory.new_verbatim_string_as ("", verbatim_marker.substring (2, verbatim_marker.count), not has_old_verbatim_strings and then verbatim_marker.item (1) = ']', line, column, string_position, position + text_count - string_position, token_buffer2)
}
;

changed to:
Default_manifest_string:
Non_empty_string
{ $$ := $1 }
| Empty_string
{ $$ := $1 }
;

Empty_string:
TE_EMPTY_STRING
{ $$ := ast_factory.new_string_as ("", line, column, string_position, position + text_count - string_position, token_buffer2) }
| TE_EMPTY_VERBATIM_STRING
{ $$ := ast_factory.new_verbatim_string_as ("", verbatim_marker.substring (2, verbatim_marker.count), not has_old_verbatim_strings and then verbatim_marker.item (1) = ']', line, column, string_position, position + text_count - string_position, token_buffer2) }
;

==== new rules for error handling ====
Rules added to non-terminals to do error handling

Example:

current Obsolete non-terminal:

Obsolete: -- Empty
-- { $$ := Void }
| TE_OBSOLETE Manifest_string
{
$$ := ast_factory.new_keyword_string_pair ($1, $2)
}
;

Paul's Obsolete non-terminal:

Obsolete: -- Empty
-- { $$ := Void }
| TE_OBSOLETE Manifest_string
{
$$ := ast_factory.new_keyword_string_pair ($1, $2)
}
| TE_OBSOLETE error { report_expected_after_error (parser_errors.obsolete_keyword, $1, parser_errors.obsolete_string, False) }
;

==== changed error handling ====
Already existing error handling in eiffel.y is usually longer than Paul's error handling. That's mainly because he put that code into features.

Example:

current version:

Inheritance: -- Empty
-- { $$ := Void }
| TE_INHERIT ASemi
{
if has_syntax_warning then
Error_handler.insert_warning (
create {SYNTAX_WARNING}.make (line, column, filename,
"Use `inherit ANY' or do not specify an empty inherit clause"))
end
--- $$ := Void
$$ := ast_factory.new_eiffel_list_parent_as (0)
if $$ /= Void then
$$.set_inherit_keyword ($1)
end
}
[...]
;

Paul's version:

Inheritance: -- Empty
-- { $$ := Void }
| TE_INHERIT ASemi
{
report_warning (parser_errors.empty_inherit_clause_warning, Void)
$$ := ast_factory.new_eiffel_list_parent_as (0)
if $$ /= Void then
$$.set_inherit_keyword ($1)
end
}
[...]
;

Syntax checking/Parser

2006-06-12T16:19:31Z

Maser: /* Tools */

[[Syntax_checking|back to Syntax checking page]]

==Important Classes/Files==

====eiffel.y====
* Eiffel grammar description.
* use [http://www.gobosoft.com/eiffel/gobo/geyacc/ geyacc] to generate eiffel_parser.e from this file
====EIFFEL_PARSER====
* inherits from EIFFEL_PARSER_SKELETON (where the features parse, parse_string, make_with_factory are implemented)
* make_with_factory (a_factory: AST_FACTORY): give argument of type AST_NULL_FACTORY (inherits from AST_FACTORY)
** AST_NULL_FACTORY doesn't build an AST (AST_FACTORY does, the AST is in EIFFEL_PARSER.root_node after parsing)
* parse (a_file: KL_BINARY_INPUT_FILE) and parse_from_string (a_string: STRING).

====CLASS_AS====
* AST of a class
====ERROR====
* deferred; superclass of all error types like EIFFEL_ERROR or SYNTAX_ERROR
* features line, column: INTEGER give location of error
====ERROR_HANDLER====
* feature error_list: ERROR is a list of errors found by the parser
====SHARED_ERROR_HANDLER====
* singleton used by all relevant classes
====EIFFEL_CLASS_C====
* features build_ast and parse_ast show how the parser can be used.

== creating a project that uses the parser ==
The new build (June 11 2006) finally has the new system configuration GUI. It's quite easy to create a project that uses the parser:
# set ISE_LIBRARY to your checkout (ie. the directory that contains the 'library' subdirectory)
# start EiffelStudio and create a new project
# open Project > Project settings...
# go to Target > Group (on the left)
# click on the library icon (the one with books on it) and add the gobo library
# click on the icon again, type 'parser' in the Name field and set the location to $ISE_LIBRARY/Eiffel/parser/parser.ecf

Now you can use the parser.

* [http://n.ethz.ch/student/luderm/es/root_class.e example of an application that uses the parser]

==Implementation==
* based on Paul's code
===ERROR classes===
* Create new SYNTAX_ERROR classes that correspond to Paul's classes, but fit into the current hierarchy
* store start and end position of the error
===extend parser to generate the right ERRORs===
* Integrate Paul's changes to eiffel.l and eiffel.y into the current versions.
* add facilities from Paul's EIFFEL_PARSER_ERROR_REPORTER
** in existing class like EIFFEL_PARSER_SKELETON (EP_ERROR_REPORTER only inherits SHARED_ERROR_HANDLER and so does EP_SKELETON
** in new class

== Work distribution==

=== eiffel.y ===
* Ueli: 0 - 844: Parent_List
* Marko: 845 - 1494 Formal Generics
* Michi: 1495 - 2130 Instruction Call
* Martin: 2131 - end (done)

=== eiffel.l ===
* Martin: added TE_BAD_ID (done)

=== error classes ===
*Chrigu

=== classes with errors to check if parser works ===
* See [[http://origo.ethz.ch/pipermail/es-devel/2006-June/000372.html this post]] on the es-devel mailing list. It's probably better to wait, as we don't really have too much time left.

== Tools ==
* [http://meld.sourceforge.net/ meld]
* [http://furius.ca/xxdiff/ xxdiff]
* [http://www.gobosoft.com/eiffel/gobo/geyacc/ geyacc]

== Grammar definition file (eiffel.y) ==

some general information:
* capitalized names like TE_STR_LT are tokens. Search for them in eiffel.l (lower case L):
\""<"\" {
ast_factory.set_buffer (token_buffer2, Current)
last_token := TE_STR_LT
}
So TE_STR_LT corresponds to '<' (\""<"\" is a regular expression)
* all other names are non-terminals, so you can find them in eiffel.y. If you don't know what a non-terminal means, you can always look it up in eiffel.y or ask the person responsible for that part of the file.

=== changes ===
There are several types of changes we can do to the eiffel.y file while merging Paul's eiffel.y and the current eiffel.y:

==== renaming ====
This doesn't really change the functionality and shouldn't really be a problem.

Example: Paul renamed infix_operator to infix_string (for whatever reasons).

==== new non-terminals ====
new Non-terminals are introduced because they simplify an existing rule or simplify error handling.

Example:

current version:
Default_manifest_string:
Non_empty_string
{ $$ := $1 }
| TE_EMPTY_STRING
{
$$ := ast_factory.new_string_as ("", line, column, string_position, position + text_count - string_position, token_buffer2)
}
| TE_EMPTY_VERBATIM_STRING
{
$$ := ast_factory.new_verbatim_string_as ("", verbatim_marker.substring (2, verbatim_marker.count), not has_old_verbatim_strings and then verbatim_marker.item (1) = ']', line, column, string_position, position + text_count - string_position, token_buffer2)
}
;

changed to:
Default_manifest_string:
Non_empty_string
{ $$ := $1 }
| Empty_string
{ $$ := $1 }
;

Empty_string:
TE_EMPTY_STRING
{ $$ := ast_factory.new_string_as ("", line, column, string_position, position + text_count - string_position, token_buffer2) }
| TE_EMPTY_VERBATIM_STRING
{ $$ := ast_factory.new_verbatim_string_as ("", verbatim_marker.substring (2, verbatim_marker.count), not has_old_verbatim_strings and then verbatim_marker.item (1) = ']', line, column, string_position, position + text_count - string_position, token_buffer2) }
;

==== new rules for error handling ====
Rules added to non-terminals to do error handling

Example:

current Obsolete non-terminal:

Obsolete: -- Empty
-- { $$ := Void }
| TE_OBSOLETE Manifest_string
{
$$ := ast_factory.new_keyword_string_pair ($1, $2)
}
;

Paul's Obsolete non-terminal:

Obsolete: -- Empty
-- { $$ := Void }
| TE_OBSOLETE Manifest_string
{
$$ := ast_factory.new_keyword_string_pair ($1, $2)
}
| TE_OBSOLETE error { report_expected_after_error (parser_errors.obsolete_keyword, $1, parser_errors.obsolete_string, False) }
;

==== changed error handling ====
Already existing error handling in eiffel.y is usually longer than Paul's error handling. That's mainly because he put that code into features.

Example:

current version:

Inheritance: -- Empty
-- { $$ := Void }
| TE_INHERIT ASemi
{
if has_syntax_warning then
Error_handler.insert_warning (
create {SYNTAX_WARNING}.make (line, column, filename,
"Use `inherit ANY' or do not specify an empty inherit clause"))
end
--- $$ := Void
$$ := ast_factory.new_eiffel_list_parent_as (0)
if $$ /= Void then
$$.set_inherit_keyword ($1)
end
}
[...]
;

Paul's version:

Inheritance: -- Empty
-- { $$ := Void }
| TE_INHERIT ASemi
{
report_warning (parser_errors.empty_inherit_clause_warning, Void)
$$ := ast_factory.new_eiffel_list_parent_as (0)
if $$ /= Void then
$$.set_inherit_keyword ($1)
end
}
[...]
;

Syntax checking/Parser

2006-06-12T16:19:16Z

Maser: /* creating a project that uses the parser */

[[Syntax_checking|back to Syntax checking page]]

==Important Classes/Files==

====eiffel.y====
* Eiffel grammar description.
* use [http://www.gobosoft.com/eiffel/gobo/geyacc/ geyacc] to generate eiffel_parser.e from this file
====EIFFEL_PARSER====
* inherits from EIFFEL_PARSER_SKELETON (where the features parse, parse_string, make_with_factory are implemented)
* make_with_factory (a_factory: AST_FACTORY): give argument of type AST_NULL_FACTORY (inherits from AST_FACTORY)
** AST_NULL_FACTORY doesn't build an AST (AST_FACTORY does, the AST is in EIFFEL_PARSER.root_node after parsing)
* parse (a_file: KL_BINARY_INPUT_FILE) and parse_from_string (a_string: STRING).

====CLASS_AS====
* AST of a class
====ERROR====
* deferred; superclass of all error types like EIFFEL_ERROR or SYNTAX_ERROR
* features line, column: INTEGER give location of error
====ERROR_HANDLER====
* feature error_list: ERROR is a list of errors found by the parser
====SHARED_ERROR_HANDLER====
* singleton used by all relevant classes
====EIFFEL_CLASS_C====
* features build_ast and parse_ast show how the parser can be used.

== creating a project that uses the parser ==
The new build (June 11 2006) finally has the new system configuration GUI. It's quite easy to create a project that uses the parser:
# set ISE_LIBRARY to your checkout (ie. the directory that contains the 'library' subdirectory)
# start EiffelStudio and create a new project
# open Project > Project settings...
# go to Target > Group (on the left)
# click on the library icon (the one with books on it) and add the gobo library
# click on the icon again, type 'parser' in the Name field and set the location to $ISE_LIBRARY/Eiffel/parser/parser.ecf

Now you can use the parser.

* [http://n.ethz.ch/student/luderm/es/root_class.e example of an application that uses the parser]

==Implementation==
* based on Paul's code
===ERROR classes===
* Create new SYNTAX_ERROR classes that correspond to Paul's classes, but fit into the current hierarchy
* store start and end position of the error
===extend parser to generate the right ERRORs===
* Integrate Paul's changes to eiffel.l and eiffel.y into the current versions.
* add facilities from Paul's EIFFEL_PARSER_ERROR_REPORTER
** in existing class like EIFFEL_PARSER_SKELETON (EP_ERROR_REPORTER only inherits SHARED_ERROR_HANDLER and so does EP_SKELETON
** in new class

== Work distribution==

=== eiffel.y ===
* Ueli: 0 - 844: Parent_List
* Marko: 845 - 1494 Formal Generics
* Michi: 1495 - 2130 Instruction Call
* Martin: 2131 - end (done)

=== eiffel.l ===
* Martin: added TE_BAD_ID (done)

=== error classes ===
*Chrigu

=== classes with errors to check if parser works ===
* See [[http://origo.ethz.ch/pipermail/es-devel/2006-June/000372.html this post]] on the es-devel mailing list. It's probably better to wait, as we don't really have too much time left.

== Tools ==
* [[http://meld.sourceforge.net/ meld]]
* [[http://furius.ca/xxdiff/ xxdiff]]
* [[http://www.gobosoft.com/eiffel/gobo/geyacc/ geyacc]]

== Grammar definition file (eiffel.y) ==

some general information:
* capitalized names like TE_STR_LT are tokens. Search for them in eiffel.l (lower case L):
\""<"\" {
ast_factory.set_buffer (token_buffer2, Current)
last_token := TE_STR_LT
}
So TE_STR_LT corresponds to '<' (\""<"\" is a regular expression)
* all other names are non-terminals, so you can find them in eiffel.y. If you don't know what a non-terminal means, you can always look it up in eiffel.y or ask the person responsible for that part of the file.

=== changes ===
There are several types of changes we can do to the eiffel.y file while merging Paul's eiffel.y and the current eiffel.y:

==== renaming ====
This doesn't really change the functionality and shouldn't really be a problem.

Example: Paul renamed infix_operator to infix_string (for whatever reasons).

==== new non-terminals ====
new Non-terminals are introduced because they simplify an existing rule or simplify error handling.

Example:

current version:
Default_manifest_string:
Non_empty_string
{ $$ := $1 }
| TE_EMPTY_STRING
{
$$ := ast_factory.new_string_as ("", line, column, string_position, position + text_count - string_position, token_buffer2)
}
| TE_EMPTY_VERBATIM_STRING
{
$$ := ast_factory.new_verbatim_string_as ("", verbatim_marker.substring (2, verbatim_marker.count), not has_old_verbatim_strings and then verbatim_marker.item (1) = ']', line, column, string_position, position + text_count - string_position, token_buffer2)
}
;

changed to:
Default_manifest_string:
Non_empty_string
{ $$ := $1 }
| Empty_string
{ $$ := $1 }
;

Empty_string:
TE_EMPTY_STRING
{ $$ := ast_factory.new_string_as ("", line, column, string_position, position + text_count - string_position, token_buffer2) }
| TE_EMPTY_VERBATIM_STRING
{ $$ := ast_factory.new_verbatim_string_as ("", verbatim_marker.substring (2, verbatim_marker.count), not has_old_verbatim_strings and then verbatim_marker.item (1) = ']', line, column, string_position, position + text_count - string_position, token_buffer2) }
;

==== new rules for error handling ====
Rules added to non-terminals to do error handling

Example:

current Obsolete non-terminal:

Obsolete: -- Empty
-- { $$ := Void }
| TE_OBSOLETE Manifest_string
{
$$ := ast_factory.new_keyword_string_pair ($1, $2)
}
;

Paul's Obsolete non-terminal:

Obsolete: -- Empty
-- { $$ := Void }
| TE_OBSOLETE Manifest_string
{
$$ := ast_factory.new_keyword_string_pair ($1, $2)
}
| TE_OBSOLETE error { report_expected_after_error (parser_errors.obsolete_keyword, $1, parser_errors.obsolete_string, False) }
;

==== changed error handling ====
Already existing error handling in eiffel.y is usually longer than Paul's error handling. That's mainly because he put that code into features.

Example:

current version:

Inheritance: -- Empty
-- { $$ := Void }
| TE_INHERIT ASemi
{
if has_syntax_warning then
Error_handler.insert_warning (
create {SYNTAX_WARNING}.make (line, column, filename,
"Use `inherit ANY' or do not specify an empty inherit clause"))
end
--- $$ := Void
$$ := ast_factory.new_eiffel_list_parent_as (0)
if $$ /= Void then
$$.set_inherit_keyword ($1)
end
}
[...]
;

Paul's version:

Inheritance: -- Empty
-- { $$ := Void }
| TE_INHERIT ASemi
{
report_warning (parser_errors.empty_inherit_clause_warning, Void)
$$ := ast_factory.new_eiffel_list_parent_as (0)
if $$ /= Void then
$$.set_inherit_keyword ($1)
end
}
[...]
;

Talk:Syntax checking/Parser

2006-06-12T16:14:57Z

Maser: /* acex for parser application */

==find more than one error==
As far as I've seen, the Parser throws an ERROR as soon as it doesn't like something in the source, which aborts parsing. The found error is in the SHARED_ERROR_HANDLER's error_list (I've never seen more than one error in there, why is it a list anyway?). Has anybody found a way to tell the parser to parse the whole file?

[[User:Maser|maser]] 14:55, 17 May 2006 (CEST)

Hmmm... I don't know how to get all the errors with one call. But you haven't to parse the whole file, so you can parse piecewise and if an error occurs, you have to parse after the string that occurs the error. This is a way to get all errors, it's complicated, but it should work!?

[[User:Chrigu|Chrigu]] 17:19, 17 May 2006 (CEST)

Actually read http://www.gobosoft.com/eiffel/gobo/geyacc/error.html for more info on how modifying `eiffel.y' to recover from error and therefore detect more than one error at a time.

--[[User:Manus|manus]] 18:10, 17 May 2006 (CEST)

Chrigu: How exactly do you parse piecewise? Though it wouldn't solve the problem because there can be several errors in one piece.
Manu: Thanks for the hint! Looks very promising!

[[User:Maser|maser]] 22:55, 17 May 2006 (CEST)

Maser: Couldn't we read several strings of the file and use parse_with_string instead of parse? I'm not sure...

[[User:Chrigu|Chrigu]] 15:52, 18 May 2006 (CEST)

Chrigu: A normal EIFFEL_PARSER accepts just classes, but you can use set_expression_parser (or some other `Parser type setting' feature) to create a parser that parses Eiffel expressions (I knew I had seen something like that before, but couldn't find it yesterday). But changing the eiffel.y file seems like a better solution. Maybe we should use expression and/or feature parsers while checking if a previously found error has been corrected by the user (I assume parsing just one expression is pretty fast).

I've looked through the documentation of gayacc and I think it shouldn't be too difficult to change eiffel.y to our needs, the file's size will probably bethe biggest problem.

[[User:Maser|maser]] 16:31, 18 May 2006 (CEST)

Everyone, I've sent Martin something that I worked on a couple a months ago. It's be no means finished or polished. It got put on the back burner because I need to work on other parts of EiffelEnvision. I also do not think it is the most recent version but I will need to check at home for the latest bits.

Basically I sent him what I started implementing for a recoverable parser in the new EiffelEnvision editor. It supported recovering from errors (more complex cannot be support with ease because it's hard to find a recoverable token - Eiffel does not have mandatory end-of-statement tokens like C/C++/C#), precise error/warning reporting (a real message stating excatly what is wrong) and absolute error positions (if you notice EiffelStudio does not always give the exact error location.)

One thing that I started doing, which you guys are going to need to address too, is error/warning spans. It would be nice if the error reporting indicated the start and end coordinates (x1, y1 - x2, y2) of the error, without draining performance.

The parser is common to EiffelStudio/Compiler, EiffelEnvision and a number of internal tools, which is something you need to be aware of. That means do not add any references to anything related to the compiler or EiffelStudio. The parser itself is a stand-alone cluster.

Creating a recoverable parser is hard and placement of those error token is a black art (that's what O'Reilly say and I agree)! Good luck :)

--[[User:Paulb|Paulb]] 17:59, 18 May 2006 (CEST)

Thanks a lot for the code, Paul!

I quickly looked through it and I'll summarize how (I think) it works: eiffel.y is extended is modified like described on the page Manu mentioned (according to Paul it contains bugs because he didn't finish it, and it isn't up to date because eiffel.y was extended to support new language features), so that it reports multiple errors (and stores them in SHARED_ERROR_HANDLER.error_list). It's about a thousand lines longer than the version in the repository. Additionally, there are new ERROR classes that describe the found syntax errors and some helper classes. Paul also mentioned that he made changes to EIFFEL_PARSER_SKELETON, but he couldn't find them.

[[User:Maser|maser]] 20:15, 18 May 2006 (CEST)

The ERROR classes in Paul's code aren't compatible with the ones in the current version (mainly the versions of SYNTAX_ERROR and SYNTAX_MESSAGE are quite different).

[[User:Maser|maser]] 00:54, 19 May 2006 (CEST)

That's correct. The existing error classes did not support everything they needed to support, so I reworte them. If you actually look at the parser error/warning classes in the parser cluster (not EiffelStudio's error classes) you'll see that the warning class is not even implemented!

As I said, the parser is a stand-alone library. The parser cluster was only moved under Src/Eiffel for ease to users to check out and compile Eiffel. In that respect you should just create an application that uses the parser library, as I did. I then sent a generated error string, from the error classes, to the the command-line shell.

[[User:Paulb|Paulb]] 22:14, 20 May 2006 (CEST)

I'm not sure if I understand what you mean. Basically, I should be able to take just the parser cluster and write a program that parses Eiffel files? But that's not possible, because EIFFEL_PARSER_SKELETON inherits from SHARED_ERROR_HANDLER, which is in the compiler cluster. Also, the error/warning classes in the parser cluster aren't used in ES, only the ones in the compiler cluster. I'd really like to create an application that uses the parser library, but I don't understand how it's going to work without the compiler cluster.

[[User:Maser|maser]] 01:38, 21 May 2006 (CEST)

If you take the configuration file parser.ecf in $EIFFEL_SRC/Eiffel/parser then it should include all you need.

--[[User:Manus|manus]] 19:30, 21 May 2006 (CEST)

Oh, you're right, everything's there, I just didn't see it. I could create a new project based on that file and it seems like there's really a lot to do in the ERROR classes.

[[User:Maser|maser]] 00:36, 22 May 2006 (CEST)

== Interface to visualization group ==

As the parser produces ERROR objects and they contain information about position and description of the error and stores them in SHARED_ERROR_HANDLER.error_list, I suggest we use this as interface to exchange the data between the parser and visualisation groups.

[[User:Maser|maser]] 16:43, 18 May 2006 (CEST)

I didn't look into it too much, but the ERROR classes can do some stuff with TEXT_FORMATTERs (several elements of the GUI inherit from TEXT_FORMATTER) which could be useful to display information about the ERROR.

[[User:Maser|maser]] 02:22, 21 May 2006 (CEST)

== suggestion for implementation ==

I've added a suggestion how to implement our changes. How bad is it? Comments? Improvements?

[[User:Maser|maser]] 16:35, 19 May 2006 (CEST)

It's not bad, it sounds good ;)

[[User:Chrigu|Chrigu]] 12:39, 21 May 2006 (CEST)

== acex for parser application ==

I've uploaded a [http://n.ethz.ch/student/luderm/parser.acex parser.acex] (Edit: removed, there's information on this topic in [[Syntax checking/Parser]]). You can also use parser.ecf file in Eiffel/parser/ in the current trunk as Manu pointed out.

[[User:Maser|maser]] 17:01, 23 May 2006 (CEST)

== error classes ==

I've studied Paul's error classes. They all inherit of syntax_error. And they can be called by the eiffel_parser_error_reporter. But where you decide, which class you should choose to represent the error?

[[User:Chrigu|Chrigu]] 13:18, 5 June 2006 (CEST)

It's decided in eiffel.y, as far as I know. There's a 'report_*' feature for each error class and in the eiffel.y the appropriate one is called with the right string from the EIFFEL_PARSER_ERRORS class.

[[User:Maser|maser]] 13:54, 5 June 2006 (CEST)

Syntax checking/Parser

2006-06-12T16:12:32Z

Maser: added walkthrough for using the parser library

[[Syntax_checking|back to Syntax checking page]]

==Important Classes/Files==

====eiffel.y====
* Eiffel grammar description.
* use [http://www.gobosoft.com/eiffel/gobo/geyacc/ geyacc] to generate eiffel_parser.e from this file
====EIFFEL_PARSER====
* inherits from EIFFEL_PARSER_SKELETON (where the features parse, parse_string, make_with_factory are implemented)
* make_with_factory (a_factory: AST_FACTORY): give argument of type AST_NULL_FACTORY (inherits from AST_FACTORY)
** AST_NULL_FACTORY doesn't build an AST (AST_FACTORY does, the AST is in EIFFEL_PARSER.root_node after parsing)
* parse (a_file: KL_BINARY_INPUT_FILE) and parse_from_string (a_string: STRING).

====CLASS_AS====
* AST of a class
====ERROR====
* deferred; superclass of all error types like EIFFEL_ERROR or SYNTAX_ERROR
* features line, column: INTEGER give location of error
====ERROR_HANDLER====
* feature error_list: ERROR is a list of errors found by the parser
====SHARED_ERROR_HANDLER====
* singleton used by all relevant classes
====EIFFEL_CLASS_C====
* features build_ast and parse_ast show how the parser can be used.

== creating a project that uses the parser ==
The new build (June 11 2006) finally has the new system configuration GUI. It's quite easy to create a project that uses the parser:
# set ISE_LIBRARY to your checkout (ie. the directory that contains the 'library' subdirectory)
# start EiffelStudio and create a new project
# open Project > Project settings...
# go to Target > Group (on the left)
# click on the library icon (the one with books on it) and add the gobo library
# click on the icon again, type 'parser' in the Name field and set the location to $ISE_LIBRARY/Eiffel/parser/parser.ecf

Now you can use the parser.

==Implementation==
* based on Paul's code
===ERROR classes===
* Create new SYNTAX_ERROR classes that correspond to Paul's classes, but fit into the current hierarchy
* store start and end position of the error
===extend parser to generate the right ERRORs===
* Integrate Paul's changes to eiffel.l and eiffel.y into the current versions.
* add facilities from Paul's EIFFEL_PARSER_ERROR_REPORTER
** in existing class like EIFFEL_PARSER_SKELETON (EP_ERROR_REPORTER only inherits SHARED_ERROR_HANDLER and so does EP_SKELETON
** in new class

== Work distribution==

=== eiffel.y ===
* Ueli: 0 - 844: Parent_List
* Marko: 845 - 1494 Formal Generics
* Michi: 1495 - 2130 Instruction Call
* Martin: 2131 - end (done)

=== eiffel.l ===
* Martin: added TE_BAD_ID (done)

=== error classes ===
*Chrigu

=== classes with errors to check if parser works ===
* See [[http://origo.ethz.ch/pipermail/es-devel/2006-June/000372.html this post]] on the es-devel mailing list. It's probably better to wait, as we don't really have too much time left.

== Tools ==
* [[http://meld.sourceforge.net/ meld]]
* [[http://furius.ca/xxdiff/ xxdiff]]
* [[http://www.gobosoft.com/eiffel/gobo/geyacc/ geyacc]]

== Grammar definition file (eiffel.y) ==

some general information:
* capitalized names like TE_STR_LT are tokens. Search for them in eiffel.l (lower case L):
\""<"\" {
ast_factory.set_buffer (token_buffer2, Current)
last_token := TE_STR_LT
}
So TE_STR_LT corresponds to '<' (\""<"\" is a regular expression)
* all other names are non-terminals, so you can find them in eiffel.y. If you don't know what a non-terminal means, you can always look it up in eiffel.y or ask the person responsible for that part of the file.

=== changes ===
There are several types of changes we can do to the eiffel.y file while merging Paul's eiffel.y and the current eiffel.y:

==== renaming ====
This doesn't really change the functionality and shouldn't really be a problem.

Example: Paul renamed infix_operator to infix_string (for whatever reasons).

==== new non-terminals ====
new Non-terminals are introduced because they simplify an existing rule or simplify error handling.

Example:

current version:
Default_manifest_string:
Non_empty_string
{ $$ := $1 }
| TE_EMPTY_STRING
{
$$ := ast_factory.new_string_as ("", line, column, string_position, position + text_count - string_position, token_buffer2)
}
| TE_EMPTY_VERBATIM_STRING
{
$$ := ast_factory.new_verbatim_string_as ("", verbatim_marker.substring (2, verbatim_marker.count), not has_old_verbatim_strings and then verbatim_marker.item (1) = ']', line, column, string_position, position + text_count - string_position, token_buffer2)
}
;

changed to:
Default_manifest_string:
Non_empty_string
{ $$ := $1 }
| Empty_string
{ $$ := $1 }
;

Empty_string:
TE_EMPTY_STRING
{ $$ := ast_factory.new_string_as ("", line, column, string_position, position + text_count - string_position, token_buffer2) }
| TE_EMPTY_VERBATIM_STRING
{ $$ := ast_factory.new_verbatim_string_as ("", verbatim_marker.substring (2, verbatim_marker.count), not has_old_verbatim_strings and then verbatim_marker.item (1) = ']', line, column, string_position, position + text_count - string_position, token_buffer2) }
;

==== new rules for error handling ====
Rules added to non-terminals to do error handling

Example:

current Obsolete non-terminal:

Obsolete: -- Empty
-- { $$ := Void }
| TE_OBSOLETE Manifest_string
{
$$ := ast_factory.new_keyword_string_pair ($1, $2)
}
;

Paul's Obsolete non-terminal:

Obsolete: -- Empty
-- { $$ := Void }
| TE_OBSOLETE Manifest_string
{
$$ := ast_factory.new_keyword_string_pair ($1, $2)
}
| TE_OBSOLETE error { report_expected_after_error (parser_errors.obsolete_keyword, $1, parser_errors.obsolete_string, False) }
;

==== changed error handling ====
Already existing error handling in eiffel.y is usually longer than Paul's error handling. That's mainly because he put that code into features.

Example:

current version:

Inheritance: -- Empty
-- { $$ := Void }
| TE_INHERIT ASemi
{
if has_syntax_warning then
Error_handler.insert_warning (
create {SYNTAX_WARNING}.make (line, column, filename,
"Use `inherit ANY' or do not specify an empty inherit clause"))
end
--- $$ := Void
$$ := ast_factory.new_eiffel_list_parent_as (0)
if $$ /= Void then
$$.set_inherit_keyword ($1)
end
}
[...]
;

Paul's version:

Inheritance: -- Empty
-- { $$ := Void }
| TE_INHERIT ASemi
{
report_warning (parser_errors.empty_inherit_clause_warning, Void)
$$ := ast_factory.new_eiffel_list_parent_as (0)
if $$ /= Void then
$$.set_inherit_keyword ($1)
end
}
[...]
;

Syntax checking/Parser

2006-06-12T14:13:24Z

Maser: /* classes with errors to check if parser works */

[[Syntax_checking|back to Syntax checking page]]

==Important Classes/Files==

====eiffel.y====
* Eiffel grammar description.
* use [http://www.gobosoft.com/eiffel/gobo/geyacc/ geyacc] to generate eiffel_parser.e from this file
====EIFFEL_PARSER====
* inherits from EIFFEL_PARSER_SKELETON (where the features parse, parse_string, make_with_factory are implemented)
* make_with_factory (a_factory: AST_FACTORY): give argument of type AST_NULL_FACTORY (inherits from AST_FACTORY)
** AST_NULL_FACTORY doesn't build an AST (AST_FACTORY does, the AST is in EIFFEL_PARSER.root_node after parsing)
* parse (a_file: KL_BINARY_INPUT_FILE) and parse_from_string (a_string: STRING).

====CLASS_AS====
* AST of a class
====ERROR====
* deferred; superclass of all error types like EIFFEL_ERROR or SYNTAX_ERROR
* features line, column: INTEGER give location of error
====ERROR_HANDLER====
* feature error_list: ERROR is a list of errors found by the parser
====SHARED_ERROR_HANDLER====
* singleton used by all relevant classes
====EIFFEL_CLASS_C====
* features build_ast and parse_ast show how the parser can be used.

==Implementation==
* based on Paul's code
===ERROR classes===
* Create new SYNTAX_ERROR classes that correspond to Paul's classes, but fit into the current hierarchy
* store start and end position of the error
===extend parser to generate the right ERRORs===
* Integrate Paul's changes to eiffel.l and eiffel.y into the current versions.
* add facilities from Paul's EIFFEL_PARSER_ERROR_REPORTER
** in existing class like EIFFEL_PARSER_SKELETON (EP_ERROR_REPORTER only inherits SHARED_ERROR_HANDLER and so does EP_SKELETON
** in new class

== Work distribution==

=== eiffel.y ===
* Ueli: 0 - 844: Parent_List
* Marko: 845 - 1494 Formal Generics
* Michi: 1495 - 2130 Instruction Call
* Martin: 2131 - end (done)

=== eiffel.l ===
* Martin: added TE_BAD_ID (done)

=== error classes ===
*Chrigu

=== classes with errors to check if parser works ===
* See [[http://origo.ethz.ch/pipermail/es-devel/2006-June/000372.html this post]] on the es-devel mailing list. It's probably better to wait, as we don't really have too much time left.

== Tools ==
* [[http://meld.sourceforge.net/ meld]]
* [[http://furius.ca/xxdiff/ xxdiff]]
* [[http://www.gobosoft.com/eiffel/gobo/geyacc/ geyacc]]

== Grammar definition file (eiffel.y) ==

some general information:
* capitalized names like TE_STR_LT are tokens. Search for them in eiffel.l (lower case L):
\""<"\" {
ast_factory.set_buffer (token_buffer2, Current)
last_token := TE_STR_LT
}
So TE_STR_LT corresponds to '<' (\""<"\" is a regular expression)
* all other names are non-terminals, so you can find them in eiffel.y. If you don't know what a non-terminal means, you can always look it up in eiffel.y or ask the person responsible for that part of the file.

=== changes ===
There are several types of changes we can do to the eiffel.y file while merging Paul's eiffel.y and the current eiffel.y:

==== renaming ====
This doesn't really change the functionality and shouldn't really be a problem.

Example: Paul renamed infix_operator to infix_string (for whatever reasons).

==== new non-terminals ====
new Non-terminals are introduced because they simplify an existing rule or simplify error handling.

Example:

current version:
Default_manifest_string:
Non_empty_string
{ $$ := $1 }
| TE_EMPTY_STRING
{
$$ := ast_factory.new_string_as ("", line, column, string_position, position + text_count - string_position, token_buffer2)
}
| TE_EMPTY_VERBATIM_STRING
{
$$ := ast_factory.new_verbatim_string_as ("", verbatim_marker.substring (2, verbatim_marker.count), not has_old_verbatim_strings and then verbatim_marker.item (1) = ']', line, column, string_position, position + text_count - string_position, token_buffer2)
}
;

changed to:
Default_manifest_string:
Non_empty_string
{ $$ := $1 }
| Empty_string
{ $$ := $1 }
;

Empty_string:
TE_EMPTY_STRING
{ $$ := ast_factory.new_string_as ("", line, column, string_position, position + text_count - string_position, token_buffer2) }
| TE_EMPTY_VERBATIM_STRING
{ $$ := ast_factory.new_verbatim_string_as ("", verbatim_marker.substring (2, verbatim_marker.count), not has_old_verbatim_strings and then verbatim_marker.item (1) = ']', line, column, string_position, position + text_count - string_position, token_buffer2) }
;

==== new rules for error handling ====
Rules added to non-terminals to do error handling

Example:

current Obsolete non-terminal:

Obsolete: -- Empty
-- { $$ := Void }
| TE_OBSOLETE Manifest_string
{
$$ := ast_factory.new_keyword_string_pair ($1, $2)
}
;

Paul's Obsolete non-terminal:

Obsolete: -- Empty
-- { $$ := Void }
| TE_OBSOLETE Manifest_string
{
$$ := ast_factory.new_keyword_string_pair ($1, $2)
}
| TE_OBSOLETE error { report_expected_after_error (parser_errors.obsolete_keyword, $1, parser_errors.obsolete_string, False) }
;

==== changed error handling ====
Already existing error handling in eiffel.y is usually longer than Paul's error handling. That's mainly because he put that code into features.

Example:

current version:

Inheritance: -- Empty
-- { $$ := Void }
| TE_INHERIT ASemi
{
if has_syntax_warning then
Error_handler.insert_warning (
create {SYNTAX_WARNING}.make (line, column, filename,
"Use `inherit ANY' or do not specify an empty inherit clause"))
end
--- $$ := Void
$$ := ast_factory.new_eiffel_list_parent_as (0)
if $$ /= Void then
$$.set_inherit_keyword ($1)
end
}
[...]
;

Paul's version:

Inheritance: -- Empty
-- { $$ := Void }
| TE_INHERIT ASemi
{
report_warning (parser_errors.empty_inherit_clause_warning, Void)
$$ := ast_factory.new_eiffel_list_parent_as (0)
if $$ /= Void then
$$.set_inherit_keyword ($1)
end
}
[...]
;

Syntax checking/Parser

2006-06-12T13:27:22Z

Maser: added information on eiffel.y and some examples

[[Syntax_checking|back to Syntax checking page]]

==Important Classes/Files==

====eiffel.y====
* Eiffel grammar description.
* use [http://www.gobosoft.com/eiffel/gobo/geyacc/ geyacc] to generate eiffel_parser.e from this file
====EIFFEL_PARSER====
* inherits from EIFFEL_PARSER_SKELETON (where the features parse, parse_string, make_with_factory are implemented)
* make_with_factory (a_factory: AST_FACTORY): give argument of type AST_NULL_FACTORY (inherits from AST_FACTORY)
** AST_NULL_FACTORY doesn't build an AST (AST_FACTORY does, the AST is in EIFFEL_PARSER.root_node after parsing)
* parse (a_file: KL_BINARY_INPUT_FILE) and parse_from_string (a_string: STRING).

====CLASS_AS====
* AST of a class
====ERROR====
* deferred; superclass of all error types like EIFFEL_ERROR or SYNTAX_ERROR
* features line, column: INTEGER give location of error
====ERROR_HANDLER====
* feature error_list: ERROR is a list of errors found by the parser
====SHARED_ERROR_HANDLER====
* singleton used by all relevant classes
====EIFFEL_CLASS_C====
* features build_ast and parse_ast show how the parser can be used.

==Implementation==
* based on Paul's code
===ERROR classes===
* Create new SYNTAX_ERROR classes that correspond to Paul's classes, but fit into the current hierarchy
* store start and end position of the error
===extend parser to generate the right ERRORs===
* Integrate Paul's changes to eiffel.l and eiffel.y into the current versions.
* add facilities from Paul's EIFFEL_PARSER_ERROR_REPORTER
** in existing class like EIFFEL_PARSER_SKELETON (EP_ERROR_REPORTER only inherits SHARED_ERROR_HANDLER and so does EP_SKELETON
** in new class

== Work distribution==

=== eiffel.y ===
* Ueli: 0 - 844: Parent_List
* Marko: 845 - 1494 Formal Generics
* Michi: 1495 - 2130 Instruction Call
* Martin: 2131 - end (done)

=== eiffel.l ===
* Martin: added TE_BAD_ID (done)

=== error classes ===
*Chrigu

=== classes with errors to check if parser works ===
* nobody yet

== Tools ==
* [[http://meld.sourceforge.net/ meld]]
* [[http://furius.ca/xxdiff/ xxdiff]]
* [[http://www.gobosoft.com/eiffel/gobo/geyacc/ geyacc]]

== Grammar definition file (eiffel.y) ==

some general information:
* capitalized names like TE_STR_LT are tokens. Search for them in eiffel.l (lower case L):
\""<"\" {
ast_factory.set_buffer (token_buffer2, Current)
last_token := TE_STR_LT
}
So TE_STR_LT corresponds to '<' (\""<"\" is a regular expression)
* all other names are non-terminals, so you can find them in eiffel.y. If you don't know what a non-terminal means, you can always look it up in eiffel.y or ask the person responsible for that part of the file.

=== changes ===
There are several types of changes we can do to the eiffel.y file while merging Paul's eiffel.y and the current eiffel.y:

==== renaming ====
This doesn't really change the functionality and shouldn't really be a problem.

Example: Paul renamed infix_operator to infix_string (for whatever reasons).

==== new non-terminals ====
new Non-terminals are introduced because they simplify an existing rule or simplify error handling.

Example:

current version:
Default_manifest_string:
Non_empty_string
{ $$ := $1 }
| TE_EMPTY_STRING
{
$$ := ast_factory.new_string_as ("", line, column, string_position, position + text_count - string_position, token_buffer2)
}
| TE_EMPTY_VERBATIM_STRING
{
$$ := ast_factory.new_verbatim_string_as ("", verbatim_marker.substring (2, verbatim_marker.count), not has_old_verbatim_strings and then verbatim_marker.item (1) = ']', line, column, string_position, position + text_count - string_position, token_buffer2)
}
;

changed to:
Default_manifest_string:
Non_empty_string
{ $$ := $1 }
| Empty_string
{ $$ := $1 }
;

Empty_string:
TE_EMPTY_STRING
{ $$ := ast_factory.new_string_as ("", line, column, string_position, position + text_count - string_position, token_buffer2) }
| TE_EMPTY_VERBATIM_STRING
{ $$ := ast_factory.new_verbatim_string_as ("", verbatim_marker.substring (2, verbatim_marker.count), not has_old_verbatim_strings and then verbatim_marker.item (1) = ']', line, column, string_position, position + text_count - string_position, token_buffer2) }
;

==== new rules for error handling ====
Rules added to non-terminals to do error handling

Example:

current Obsolete non-terminal:

Obsolete: -- Empty
-- { $$ := Void }
| TE_OBSOLETE Manifest_string
{
$$ := ast_factory.new_keyword_string_pair ($1, $2)
}
;

Paul's Obsolete non-terminal:

Obsolete: -- Empty
-- { $$ := Void }
| TE_OBSOLETE Manifest_string
{
$$ := ast_factory.new_keyword_string_pair ($1, $2)
}
| TE_OBSOLETE error { report_expected_after_error (parser_errors.obsolete_keyword, $1, parser_errors.obsolete_string, False) }
;

==== changed error handling ====
Already existing error handling in eiffel.y is usually longer than Paul's error handling. That's mainly because he put that code into features.

Example:

current version:

Inheritance: -- Empty
-- { $$ := Void }
| TE_INHERIT ASemi
{
if has_syntax_warning then
Error_handler.insert_warning (
create {SYNTAX_WARNING}.make (line, column, filename,
"Use `inherit ANY' or do not specify an empty inherit clause"))
end
--- $$ := Void
$$ := ast_factory.new_eiffel_list_parent_as (0)
if $$ /= Void then
$$.set_inherit_keyword ($1)
end
}
[...]
;

Paul's version:

Inheritance: -- Empty
-- { $$ := Void }
| TE_INHERIT ASemi
{
report_warning (parser_errors.empty_inherit_clause_warning, Void)
$$ := ast_factory.new_eiffel_list_parent_as (0)
if $$ /= Void then
$$.set_inherit_keyword ($1)
end
}
[...]
;

Syntax checking/Parser

2006-06-09T12:43:04Z

Maser: /* eiffel.y */

Syntax checking/Parser

2006-06-09T12:33:36Z

Maser: /* Work distribution */ typo

Syntax checking/Parser

2006-06-06T11:10:40Z

Maser: /* Tools */ added geyacc

Syntax checking/Parser

2006-06-06T11:09:56Z

Maser: added links to tools

Syntax checking/Parser

2006-06-05T21:43:40Z

Maser: /* EIFFEL_PARSER */

Talk:Syntax checking/Parser

2006-06-05T11:54:24Z

Maser: /* error classes */

==find more than one error==
As far as I've seen, the Parser throws an ERROR as soon as it doesn't like something in the source, which aborts parsing. The found error is in the SHARED_ERROR_HANDLER's error_list (I've never seen more than one error in there, why is it a list anyway?). Has anybody found a way to tell the parser to parse the whole file?

[[User:Maser|maser]] 14:55, 17 May 2006 (CEST)

Hmmm... I don't know how to get all the errors with one call. But you haven't to parse the whole file, so you can parse piecewise and if an error occurs, you have to parse after the string that occurs the error. This is a way to get all errors, it's complicated, but it should work!?

[[User:Chrigu|Chrigu]] 17:19, 17 May 2006 (CEST)

Actually read http://www.gobosoft.com/eiffel/gobo/geyacc/error.html for more info on how modifying `eiffel.y' to recover from error and therefore detect more than one error at a time.

--[[User:Manus|manus]] 18:10, 17 May 2006 (CEST)

Chrigu: How exactly do you parse piecewise? Though it wouldn't solve the problem because there can be several errors in one piece.
Manu: Thanks for the hint! Looks very promising!

[[User:Maser|maser]] 22:55, 17 May 2006 (CEST)

Maser: Couldn't we read several strings of the file and use parse_with_string instead of parse? I'm not sure...

[[User:Chrigu|Chrigu]] 15:52, 18 May 2006 (CEST)

Chrigu: A normal EIFFEL_PARSER accepts just classes, but you can use set_expression_parser (or some other `Parser type setting' feature) to create a parser that parses Eiffel expressions (I knew I had seen something like that before, but couldn't find it yesterday). But changing the eiffel.y file seems like a better solution. Maybe we should use expression and/or feature parsers while checking if a previously found error has been corrected by the user (I assume parsing just one expression is pretty fast).

I've looked through the documentation of gayacc and I think it shouldn't be too difficult to change eiffel.y to our needs, the file's size will probably bethe biggest problem.

[[User:Maser|maser]] 16:31, 18 May 2006 (CEST)

Everyone, I've sent Martin something that I worked on a couple a months ago. It's be no means finished or polished. It got put on the back burner because I need to work on other parts of EiffelEnvision. I also do not think it is the most recent version but I will need to check at home for the latest bits.

Basically I sent him what I started implementing for a recoverable parser in the new EiffelEnvision editor. It supported recovering from errors (more complex cannot be support with ease because it's hard to find a recoverable token - Eiffel does not have mandatory end-of-statement tokens like C/C++/C#), precise error/warning reporting (a real message stating excatly what is wrong) and absolute error positions (if you notice EiffelStudio does not always give the exact error location.)

One thing that I started doing, which you guys are going to need to address too, is error/warning spans. It would be nice if the error reporting indicated the start and end coordinates (x1, y1 - x2, y2) of the error, without draining performance.

The parser is common to EiffelStudio/Compiler, EiffelEnvision and a number of internal tools, which is something you need to be aware of. That means do not add any references to anything related to the compiler or EiffelStudio. The parser itself is a stand-alone cluster.

Creating a recoverable parser is hard and placement of those error token is a black art (that's what O'Reilly say and I agree)! Good luck :)

--[[User:Paulb|Paulb]] 17:59, 18 May 2006 (CEST)

Thanks a lot for the code, Paul!

I quickly looked through it and I'll summarize how (I think) it works: eiffel.y is extended is modified like described on the page Manu mentioned (according to Paul it contains bugs because he didn't finish it, and it isn't up to date because eiffel.y was extended to support new language features), so that it reports multiple errors (and stores them in SHARED_ERROR_HANDLER.error_list). It's about a thousand lines longer than the version in the repository. Additionally, there are new ERROR classes that describe the found syntax errors and some helper classes. Paul also mentioned that he made changes to EIFFEL_PARSER_SKELETON, but he couldn't find them.

[[User:Maser|maser]] 20:15, 18 May 2006 (CEST)

The ERROR classes in Paul's code aren't compatible with the ones in the current version (mainly the versions of SYNTAX_ERROR and SYNTAX_MESSAGE are quite different).

[[User:Maser|maser]] 00:54, 19 May 2006 (CEST)

That's correct. The existing error classes did not support everything they needed to support, so I reworte them. If you actually look at the parser error/warning classes in the parser cluster (not EiffelStudio's error classes) you'll see that the warning class is not even implemented!

As I said, the parser is a stand-alone library. The parser cluster was only moved under Src/Eiffel for ease to users to check out and compile Eiffel. In that respect you should just create an application that uses the parser library, as I did. I then sent a generated error string, from the error classes, to the the command-line shell.

[[User:Paulb|Paulb]] 22:14, 20 May 2006 (CEST)

I'm not sure if I understand what you mean. Basically, I should be able to take just the parser cluster and write a program that parses Eiffel files? But that's not possible, because EIFFEL_PARSER_SKELETON inherits from SHARED_ERROR_HANDLER, which is in the compiler cluster. Also, the error/warning classes in the parser cluster aren't used in ES, only the ones in the compiler cluster. I'd really like to create an application that uses the parser library, but I don't understand how it's going to work without the compiler cluster.

[[User:Maser|maser]] 01:38, 21 May 2006 (CEST)

If you take the configuration file parser.ecf in $EIFFEL_SRC/Eiffel/parser then it should include all you need.

--[[User:Manus|manus]] 19:30, 21 May 2006 (CEST)

Oh, you're right, everything's there, I just didn't see it. I could create a new project based on that file and it seems like there's really a lot to do in the ERROR classes.

[[User:Maser|maser]] 00:36, 22 May 2006 (CEST)

== Interface to visualization group ==

As the parser produces ERROR objects and they contain information about position and description of the error and stores them in SHARED_ERROR_HANDLER.error_list, I suggest we use this as interface to exchange the data between the parser and visualisation groups.

[[User:Maser|maser]] 16:43, 18 May 2006 (CEST)

I didn't look into it too much, but the ERROR classes can do some stuff with TEXT_FORMATTERs (several elements of the GUI inherit from TEXT_FORMATTER) which could be useful to display information about the ERROR.

[[User:Maser|maser]] 02:22, 21 May 2006 (CEST)

== suggestion for implementation ==

I've added a suggestion how to implement our changes. How bad is it? Comments? Improvements?

[[User:Maser|maser]] 16:35, 19 May 2006 (CEST)

It's not bad, it sounds good ;)

[[User:Chrigu|Chrigu]] 12:39, 21 May 2006 (CEST)

== acex for parser application ==

I've uploaded a [http://n.ethz.ch/student/luderm/parser.acex parser.acex] (why can't I upload it to the wiki?). You can also use parser.ecf file in Eiffel/parser/ in the current trunk as Manu pointed out.

[[User:Maser|maser]] 17:01, 23 May 2006 (CEST)

== error classes ==

I've studied Paul's error classes. They all inherit of syntax_error. And they can be called by the eiffel_parser_error_reporter. But where you decide, which class you should choose to represent the error?

[[User:Chrigu|Chrigu]] 13:18, 5 June 2006 (CEST)

It's decided in eiffel.y, as far as I know. There's a 'report_*' feature for each error class and in the eiffel.y the appropriate one is called with the right string from the EIFFEL_PARSER_ERRORS class.

[[User:Maser|maser]] 13:54, 5 June 2006 (CEST)

Syntax checking/Parser

2006-06-01T11:47:32Z

Maser:

Syntax checking/Parser

2006-06-01T10:48:50Z

Maser: work distribution

Talk:Syntax checking/Parser

2006-05-23T15:01:30Z

Maser: acex for parser application

==find more than one error==
As far as I've seen, the Parser throws an ERROR as soon as it doesn't like something in the source, which aborts parsing. The found error is in the SHARED_ERROR_HANDLER's error_list (I've never seen more than one error in there, why is it a list anyway?). Has anybody found a way to tell the parser to parse the whole file?

[[User:Maser|maser]] 14:55, 17 May 2006 (CEST)

Hmmm... I don't know how to get all the errors with one call. But you haven't to parse the whole file, so you can parse piecewise and if an error occurs, you have to parse after the string that occurs the error. This is a way to get all errors, it's complicated, but it should work!?

[[User:Chrigu|Chrigu]] 17:19, 17 May 2006 (CEST)

Actually read http://www.gobosoft.com/eiffel/gobo/geyacc/error.html for more info on how modifying `eiffel.y' to recover from error and therefore detect more than one error at a time.

--[[User:Manus|manus]] 18:10, 17 May 2006 (CEST)

Chrigu: How exactly do you parse piecewise? Though it wouldn't solve the problem because there can be several errors in one piece.
Manu: Thanks for the hint! Looks very promising!

[[User:Maser|maser]] 22:55, 17 May 2006 (CEST)

Maser: Couldn't we read several strings of the file and use parse_with_string instead of parse? I'm not sure...

[[User:Chrigu|Chrigu]] 15:52, 18 May 2006 (CEST)

Chrigu: A normal EIFFEL_PARSER accepts just classes, but you can use set_expression_parser (or some other `Parser type setting' feature) to create a parser that parses Eiffel expressions (I knew I had seen something like that before, but couldn't find it yesterday). But changing the eiffel.y file seems like a better solution. Maybe we should use expression and/or feature parsers while checking if a previously found error has been corrected by the user (I assume parsing just one expression is pretty fast).

I've looked through the documentation of gayacc and I think it shouldn't be too difficult to change eiffel.y to our needs, the file's size will probably bethe biggest problem.

[[User:Maser|maser]] 16:31, 18 May 2006 (CEST)

Everyone, I've sent Martin something that I worked on a couple a months ago. It's be no means finished or polished. It got put on the back burner because I need to work on other parts of EiffelEnvision. I also do not think it is the most recent version but I will need to check at home for the latest bits.

Basically I sent him what I started implementing for a recoverable parser in the new EiffelEnvision editor. It supported recovering from errors (more complex cannot be support with ease because it's hard to find a recoverable token - Eiffel does not have mandatory end-of-statement tokens like C/C++/C#), precise error/warning reporting (a real message stating excatly what is wrong) and absolute error positions (if you notice EiffelStudio does not always give the exact error location.)

One thing that I started doing, which you guys are going to need to address too, is error/warning spans. It would be nice if the error reporting indicated the start and end coordinates (x1, y1 - x2, y2) of the error, without draining performance.

The parser is common to EiffelStudio/Compiler, EiffelEnvision and a number of internal tools, which is something you need to be aware of. That means do not add any references to anything related to the compiler or EiffelStudio. The parser itself is a stand-alone cluster.

Creating a recoverable parser is hard and placement of those error token is a black art (that's what O'Reilly say and I agree)! Good luck :)

--[[User:Paulb|Paulb]] 17:59, 18 May 2006 (CEST)

Thanks a lot for the code, Paul!

I quickly looked through it and I'll summarize how (I think) it works: eiffel.y is extended is modified like described on the page Manu mentioned (according to Paul it contains bugs because he didn't finish it, and it isn't up to date because eiffel.y was extended to support new language features), so that it reports multiple errors (and stores them in SHARED_ERROR_HANDLER.error_list). It's about a thousand lines longer than the version in the repository. Additionally, there are new ERROR classes that describe the found syntax errors and some helper classes. Paul also mentioned that he made changes to EIFFEL_PARSER_SKELETON, but he couldn't find them.

[[User:Maser|maser]] 20:15, 18 May 2006 (CEST)

The ERROR classes in Paul's code aren't compatible with the ones in the current version (mainly the versions of SYNTAX_ERROR and SYNTAX_MESSAGE are quite different).

[[User:Maser|maser]] 00:54, 19 May 2006 (CEST)

That's correct. The existing error classes did not support everything they needed to support, so I reworte them. If you actually look at the parser error/warning classes in the parser cluster (not EiffelStudio's error classes) you'll see that the warning class is not even implemented!

As I said, the parser is a stand-alone library. The parser cluster was only moved under Src/Eiffel for ease to users to check out and compile Eiffel. In that respect you should just create an application that uses the parser library, as I did. I then sent a generated error string, from the error classes, to the the command-line shell.

[[User:Paulb|Paulb]] 22:14, 20 May 2006 (CEST)

I'm not sure if I understand what you mean. Basically, I should be able to take just the parser cluster and write a program that parses Eiffel files? But that's not possible, because EIFFEL_PARSER_SKELETON inherits from SHARED_ERROR_HANDLER, which is in the compiler cluster. Also, the error/warning classes in the parser cluster aren't used in ES, only the ones in the compiler cluster. I'd really like to create an application that uses the parser library, but I don't understand how it's going to work without the compiler cluster.

[[User:Maser|maser]] 01:38, 21 May 2006 (CEST)

If you take the configuration file parser.ecf in $EIFFEL_SRC/Eiffel/parser then it should include all you need.

--[[User:Manus|manus]] 19:30, 21 May 2006 (CEST)

Oh, you're right, everything's there, I just didn't see it. I could create a new project based on that file and it seems like there's really a lot to do in the ERROR classes.

[[User:Maser|maser]] 00:36, 22 May 2006 (CEST)

== Interface to visualization group ==

As the parser produces ERROR objects and they contain information about position and description of the error and stores them in SHARED_ERROR_HANDLER.error_list, I suggest we use this as interface to exchange the data between the parser and visualisation groups.

[[User:Maser|maser]] 16:43, 18 May 2006 (CEST)

I didn't look into it too much, but the ERROR classes can do some stuff with TEXT_FORMATTERs (several elements of the GUI inherit from TEXT_FORMATTER) which could be useful to display information about the ERROR.

[[User:Maser|maser]] 02:22, 21 May 2006 (CEST)

== suggestion for implementation ==

I've added a suggestion how to implement our changes. How bad is it? Comments? Improvements?

[[User:Maser|maser]] 16:35, 19 May 2006 (CEST)

It's not bad, it sounds good ;)

[[User:Chrigu|Chrigu]] 12:39, 21 May 2006 (CEST)

== acex for parser application ==

I've uploaded a [http://n.ethz.ch/student/luderm/parser.acex parser.acex] (why can't I upload it to the wiki?). You can also use parser.ecf file in Eiffel/parser/ in the current trunk as Manu pointed out.

[[User:Maser|maser]] 17:01, 23 May 2006 (CEST)

Talk:Syntax checking/Parser

2006-05-21T22:36:31Z

Maser: /* find more than one error */

Talk:Syntax checking/Parser

2006-05-21T22:04:22Z

Maser: /* find more than one error */

==find more than one error==
As far as I've seen, the Parser throws an ERROR as soon as it doesn't like something in the source, which aborts parsing. The found error is in the SHARED_ERROR_HANDLER's error_list (I've never seen more than one error in there, why is it a list anyway?). Has anybody found a way to tell the parser to parse the whole file?

[[User:Maser|maser]] 14:55, 17 May 2006 (CEST)

Hmmm... I don't know how to get all the errors with one call. But you haven't to parse the whole file, so you can parse piecewise and if an error occurs, you have to parse after the string that occurs the error. This is a way to get all errors, it's complicated, but it should work!?

[[User:Chrigu|Chrigu]] 17:19, 17 May 2006 (CEST)

Actually read http://www.gobosoft.com/eiffel/gobo/geyacc/error.html for more info on how modifying `eiffel.y' to recover from error and therefore detect more than one error at a time.

--[[User:Manus|manus]] 18:10, 17 May 2006 (CEST)

Chrigu: How exactly do you parse piecewise? Though it wouldn't solve the problem because there can be several errors in one piece.
Manu: Thanks for the hint! Looks very promising!

[[User:Maser|maser]] 22:55, 17 May 2006 (CEST)

Maser: Couldn't we read several strings of the file and use parse_with_string instead of parse? I'm not sure...

[[User:Chrigu|Chrigu]] 15:52, 18 May 2006 (CEST)

Chrigu: A normal EIFFEL_PARSER accepts just classes, but you can use set_expression_parser (or some other `Parser type setting' feature) to create a parser that parses Eiffel expressions (I knew I had seen something like that before, but couldn't find it yesterday). But changing the eiffel.y file seems like a better solution. Maybe we should use expression and/or feature parsers while checking if a previously found error has been corrected by the user (I assume parsing just one expression is pretty fast).

I've looked through the documentation of gayacc and I think it shouldn't be too difficult to change eiffel.y to our needs, the file's size will probably bethe biggest problem.

[[User:Maser|maser]] 16:31, 18 May 2006 (CEST)

Everyone, I've sent Martin something that I worked on a couple a months ago. It's be no means finished or polished. It got put on the back burner because I need to work on other parts of EiffelEnvision. I also do not think it is the most recent version but I will need to check at home for the latest bits.

Basically I sent him what I started implementing for a recoverable parser in the new EiffelEnvision editor. It supported recovering from errors (more complex cannot be support with ease because it's hard to find a recoverable token - Eiffel does not have mandatory end-of-statement tokens like C/C++/C#), precise error/warning reporting (a real message stating excatly what is wrong) and absolute error positions (if you notice EiffelStudio does not always give the exact error location.)

One thing that I started doing, which you guys are going to need to address too, is error/warning spans. It would be nice if the error reporting indicated the start and end coordinates (x1, y1 - x2, y2) of the error, without draining performance.

The parser is common to EiffelStudio/Compiler, EiffelEnvision and a number of internal tools, which is something you need to be aware of. That means do not add any references to anything related to the compiler or EiffelStudio. The parser itself is a stand-alone cluster.

Creating a recoverable parser is hard and placement of those error token is a black art (that's what O'Reilly say and I agree)! Good luck :)

--[[User:Paulb|Paulb]] 17:59, 18 May 2006 (CEST)

Thanks a lot for the code, Paul!

I quickly looked through it and I'll summarize how (I think) it works: eiffel.y is extended is modified like described on the page Manu mentioned (according to Paul it contains bugs because he didn't finish it, and it isn't up to date because eiffel.y was extended to support new language features), so that it reports multiple errors (and stores them in SHARED_ERROR_HANDLER.error_list). It's about a thousand lines longer than the version in the repository. Additionally, there are new ERROR classes that describe the found syntax errors and some helper classes. Paul also mentioned that he made changes to EIFFEL_PARSER_SKELETON, but he couldn't find them.

[[User:Maser|maser]] 20:15, 18 May 2006 (CEST)

The ERROR classes in Paul's code aren't compatible with the ones in the current version (mainly the versions of SYNTAX_ERROR and SYNTAX_MESSAGE are quite different).

[[User:Maser|maser]] 00:54, 19 May 2006 (CEST)

That's correct. The existing error classes did not support everything they needed to support, so I reworte them. If you actually look at the parser error/warning classes in the parser cluster (not EiffelStudio's error classes) you'll see that the warning class is not even implemented!

As I said, the parser is a stand-alone library. The parser cluster was only moved under Src/Eiffel for ease to users to check out and compile Eiffel. In that respect you should just create an application that uses the parser library, as I did. I then sent a generated error string, from the error classes, to the the command-line shell.

[[User:Paulb|Paulb]] 22:14, 20 May 2006 (CEST)

I'm not sure if I understand what you mean. Basically, I should be able to take just the parser cluster and write a program that parses Eiffel files? But that's not possible, because EIFFEL_PARSER_SKELETON inherits from SHARED_ERROR_HANDLER, which is in the compiler cluster. Also, the error/warning classes in the parser cluster aren't used in ES, only the ones in the compiler cluster. I'd really like to create an application that uses the parser library, but I don't understand how it's going to work without the compiler cluster.

[[User:Maser|maser]] 01:38, 21 May 2006 (CEST)

If you take the configuration file parser.ecf in $EIFFEL_SRC/Eiffel/parser then it should include all you need.

--[[User:Manus|manus]] 19:30, 21 May 2006 (CEST)

Oh, you're right, everything's there, I just didn't see it.

[[User:Maser|maser]] 00:04, 22 May 2006 (CEST)

== Interface to visualization group ==

As the parser produces ERROR objects and they contain information about position and description of the error and stores them in SHARED_ERROR_HANDLER.error_list, I suggest we use this as interface to exchange the data between the parser and visualisation groups.

[[User:Maser|maser]] 16:43, 18 May 2006 (CEST)

I didn't look into it too much, but the ERROR classes can do some stuff with TEXT_FORMATTERs (several elements of the GUI inherit from TEXT_FORMATTER) which could be useful to display information about the ERROR.

[[User:Maser|maser]] 02:22, 21 May 2006 (CEST)

== suggestion for implementation ==

I've added a suggestion how to implement our changes. How bad is it? Comments? Improvements?

[[User:Maser|maser]] 16:35, 19 May 2006 (CEST)

It's not bad, it sounds good ;)

[[User:Chrigu|Chrigu]] 12:39, 21 May 2006 (CEST)

Talk:Syntax checking/Parser

2006-05-21T00:22:26Z

Maser: /* Interface to visualization group */

==find more than one error==
As far as I've seen, the Parser throws an ERROR as soon as it doesn't like something in the source, which aborts parsing. The found error is in the SHARED_ERROR_HANDLER's error_list (I've never seen more than one error in there, why is it a list anyway?). Has anybody found a way to tell the parser to parse the whole file?

[[User:Maser|maser]] 14:55, 17 May 2006 (CEST)

Hmmm... I don't know how to get all the errors with one call. But you haven't to parse the whole file, so you can parse piecewise and if an error occurs, you have to parse after the string that occurs the error. This is a way to get all errors, it's complicated, but it should work!?

[[User:Chrigu|Chrigu]] 17:19, 17 May 2006 (CEST)

Actually read http://www.gobosoft.com/eiffel/gobo/geyacc/error.html for more info on how modifying `eiffel.y' to recover from error and therefore detect more than one error at a time.

--[[User:Manus|manus]] 18:10, 17 May 2006 (CEST)

Chrigu: How exactly do you parse piecewise? Though it wouldn't solve the problem because there can be several errors in one piece.
Manu: Thanks for the hint! Looks very promising!

[[User:Maser|maser]] 22:55, 17 May 2006 (CEST)

Maser: Couldn't we read several strings of the file and use parse_with_string instead of parse? I'm not sure...

[[User:Chrigu|Chrigu]] 15:52, 18 May 2006 (CEST)

Chrigu: A normal EIFFEL_PARSER accepts just classes, but you can use set_expression_parser (or some other `Parser type setting' feature) to create a parser that parses Eiffel expressions (I knew I had seen something like that before, but couldn't find it yesterday). But changing the eiffel.y file seems like a better solution. Maybe we should use expression and/or feature parsers while checking if a previously found error has been corrected by the user (I assume parsing just one expression is pretty fast).

I've looked through the documentation of gayacc and I think it shouldn't be too difficult to change eiffel.y to our needs, the file's size will probably bethe biggest problem.

[[User:Maser|maser]] 16:31, 18 May 2006 (CEST)

Everyone, I've sent Martin something that I worked on a couple a months ago. It's be no means finished or polished. It got put on the back burner because I need to work on other parts of EiffelEnvision. I also do not think it is the most recent version but I will need to check at home for the latest bits.

Basically I sent him what I started implementing for a recoverable parser in the new EiffelEnvision editor. It supported recovering from errors (more complex cannot be support with ease because it's hard to find a recoverable token - Eiffel does not have mandatory end-of-statement tokens like C/C++/C#), precise error/warning reporting (a real message stating excatly what is wrong) and absolute error positions (if you notice EiffelStudio does not always give the exact error location.)

One thing that I started doing, which you guys are going to need to address too, is error/warning spans. It would be nice if the error reporting indicated the start and end coordinates (x1, y1 - x2, y2) of the error, without draining performance.

The parser is common to EiffelStudio/Compiler, EiffelEnvision and a number of internal tools, which is something you need to be aware of. That means do not add any references to anything related to the compiler or EiffelStudio. The parser itself is a stand-alone cluster.

Creating a recoverable parser is hard and placement of those error token is a black art (that's what O'Reilly say and I agree)! Good luck :)

--[[User:Paulb|Paulb]] 17:59, 18 May 2006 (CEST)

Thanks a lot for the code, Paul!

I quickly looked through it and I'll summarize how (I think) it works: eiffel.y is extended is modified like described on the page Manu mentioned (according to Paul it contains bugs because he didn't finish it, and it isn't up to date because eiffel.y was extended to support new language features), so that it reports multiple errors (and stores them in SHARED_ERROR_HANDLER.error_list). It's about a thousand lines longer than the version in the repository. Additionally, there are new ERROR classes that describe the found syntax errors and some helper classes. Paul also mentioned that he made changes to EIFFEL_PARSER_SKELETON, but he couldn't find them.

[[User:Maser|maser]] 20:15, 18 May 2006 (CEST)

The ERROR classes in Paul's code aren't compatible with the ones in the current version (mainly the versions of SYNTAX_ERROR and SYNTAX_MESSAGE are quite different).

[[User:Maser|maser]] 00:54, 19 May 2006 (CEST)

That's correct. The existing error classes did not support everything they needed to support, so I reworte them. If you actually look at the parser error/warning classes in the parser cluster (not EiffelStudio's error classes) you'll see that the warning class is not even implemented!

As I said, the parser is a stand-alone library. The parser cluster was only moved under Src/Eiffel for ease to users to check out and compile Eiffel. In that respect you should just create an application that uses the parser library, as I did. I then sent a generated error string, from the error classes, to the the command-line shell.

[[User:Paulb|Paulb]] 22:14, 20 May 2006 (CEST)

I'm not sure if I understand what you mean. Basically, I should be able to take just the parser cluster and write a program that parses Eiffel files? But that's not possible, because EIFFEL_PARSER_SKELETON inherits from SHARED_ERROR_HANDLER, which is in the compiler cluster. Also, the error/warning classes in the parser cluster aren't used in ES, only the ones in the compiler cluster. I'd really like to create an application that uses the parser library, but I don't understand how it's going to work without the compiler cluster.

[[User:Maser|maser]] 01:38, 21 May 2006 (CEST)

== Interface to visualization group ==

As the parser produces ERROR objects and they contain information about position and description of the error and stores them in SHARED_ERROR_HANDLER.error_list, I suggest we use this as interface to exchange the data between the parser and visualisation groups.

[[User:Maser|maser]] 16:43, 18 May 2006 (CEST)

I didn't look into it too much, but the ERROR classes can do some stuff with TEXT_FORMATTERs (several elements of the GUI inherit from TEXT_FORMATTER) which could be useful to display information about the ERROR.

[[User:Maser|maser]] 02:22, 21 May 2006 (CEST)

== suggestion for implementation ==

I've added a suggestion how to implement our changes. How bad is it? Comments? Improvements?

[[User:Maser|maser]] 16:35, 19 May 2006 (CEST)

Talk:Syntax checking/SRS

2006-05-21T00:16:40Z

Maser: Martin

== Janick ==
Please give some feedback regarding SRS so far

==Manus==
It is great. For the syntax validity, create an instance of EIFFEL_PARSER with the AST_NULL_FACTORY for the factory. That way it is quite efficient for the parsing.

[[User:Manus|manus]] 19:03, 2 May 2006 (CEST)

==Janick==
Manu, thanks for the feedback and hints.

Some people thaught that an timing-based parser would be better. Who is of the same opionion? Please use this discussion, as we need to finalize the specifications soon.

May 5th 2006 (CEST)

== Martin ==

What exactly do you mean by timing-based? As specified in the SRS but with a timeout before it starts parsing or really independent of user input? I think it's good the way it is now (if it is efficient enough). Just a little remark to the notes: If the state of an expression can only change when the cursor leaves it, does that include the items under 1.1.1? I think it should, although I guess you should get a little time to resume typing.

[[User:Maser|Maser]] 23:57, 5 May 2006 (CEST)

==Janick==
Timing based would mean that the document gets parsed and highlighted in specific intervals (like every 50ms). This would also imply that while writing not yet completed feature names etc. would get underlined.

Stephan added that "when the cursor" leaves part, so he should answer that question. IMO if we have event-based parsing, that coursor leaves clause could be removed.

01:59, May 6th 2006 (CEST)

== Martin ==

I've got a question to the interface section. Do you mean EDITOR_TOKEN or really the TOKEN class in the lex library? IMO it's not possible to do it this way, because the parser doesn't know that there is an editor. It can only generate a list of error descriptions, but cannot access the editor's data (if you use ec on the command line, there even is no editor whose data it could access). In a nutshell: the editor has to use the parser, not the other way around.

(should this be in the SRS as it concerns implementation?)

And something else: There can be syntax warnings (eg. when you use the word 'only' you get a warning that this could become a keyword in a future version of the language), so we can either ignore them (display nothing), treat them as errors (not a good idea) or use a different colour.

[[User:Maser|maser]] 02:16, 21 May 2006 (CEST)

Talk:Syntax checking/Parser

2006-05-20T23:38:20Z

Maser: /* find more than one error */

==find more than one error==
As far as I've seen, the Parser throws an ERROR as soon as it doesn't like something in the source, which aborts parsing. The found error is in the SHARED_ERROR_HANDLER's error_list (I've never seen more than one error in there, why is it a list anyway?). Has anybody found a way to tell the parser to parse the whole file?

[[User:Maser|maser]] 14:55, 17 May 2006 (CEST)

Hmmm... I don't know how to get all the errors with one call. But you haven't to parse the whole file, so you can parse piecewise and if an error occurs, you have to parse after the string that occurs the error. This is a way to get all errors, it's complicated, but it should work!?

[[User:Chrigu|Chrigu]] 17:19, 17 May 2006 (CEST)

Actually read http://www.gobosoft.com/eiffel/gobo/geyacc/error.html for more info on how modifying `eiffel.y' to recover from error and therefore detect more than one error at a time.

--[[User:Manus|manus]] 18:10, 17 May 2006 (CEST)

Chrigu: How exactly do you parse piecewise? Though it wouldn't solve the problem because there can be several errors in one piece.
Manu: Thanks for the hint! Looks very promising!

[[User:Maser|maser]] 22:55, 17 May 2006 (CEST)

Maser: Couldn't we read several strings of the file and use parse_with_string instead of parse? I'm not sure...

[[User:Chrigu|Chrigu]] 15:52, 18 May 2006 (CEST)

Chrigu: A normal EIFFEL_PARSER accepts just classes, but you can use set_expression_parser (or some other `Parser type setting' feature) to create a parser that parses Eiffel expressions (I knew I had seen something like that before, but couldn't find it yesterday). But changing the eiffel.y file seems like a better solution. Maybe we should use expression and/or feature parsers while checking if a previously found error has been corrected by the user (I assume parsing just one expression is pretty fast).

I've looked through the documentation of gayacc and I think it shouldn't be too difficult to change eiffel.y to our needs, the file's size will probably bethe biggest problem.

[[User:Maser|maser]] 16:31, 18 May 2006 (CEST)

Everyone, I've sent Martin something that I worked on a couple a months ago. It's be no means finished or polished. It got put on the back burner because I need to work on other parts of EiffelEnvision. I also do not think it is the most recent version but I will need to check at home for the latest bits.

Basically I sent him what I started implementing for a recoverable parser in the new EiffelEnvision editor. It supported recovering from errors (more complex cannot be support with ease because it's hard to find a recoverable token - Eiffel does not have mandatory end-of-statement tokens like C/C++/C#), precise error/warning reporting (a real message stating excatly what is wrong) and absolute error positions (if you notice EiffelStudio does not always give the exact error location.)

One thing that I started doing, which you guys are going to need to address too, is error/warning spans. It would be nice if the error reporting indicated the start and end coordinates (x1, y1 - x2, y2) of the error, without draining performance.

The parser is common to EiffelStudio/Compiler, EiffelEnvision and a number of internal tools, which is something you need to be aware of. That means do not add any references to anything related to the compiler or EiffelStudio. The parser itself is a stand-alone cluster.

Creating a recoverable parser is hard and placement of those error token is a black art (that's what O'Reilly say and I agree)! Good luck :)

--[[User:Paulb|Paulb]] 17:59, 18 May 2006 (CEST)

Thanks a lot for the code, Paul!

I quickly looked through it and I'll summarize how (I think) it works: eiffel.y is extended is modified like described on the page Manu mentioned (according to Paul it contains bugs because he didn't finish it, and it isn't up to date because eiffel.y was extended to support new language features), so that it reports multiple errors (and stores them in SHARED_ERROR_HANDLER.error_list). It's about a thousand lines longer than the version in the repository. Additionally, there are new ERROR classes that describe the found syntax errors and some helper classes. Paul also mentioned that he made changes to EIFFEL_PARSER_SKELETON, but he couldn't find them.

[[User:Maser|maser]] 20:15, 18 May 2006 (CEST)

The ERROR classes in Paul's code aren't compatible with the ones in the current version (mainly the versions of SYNTAX_ERROR and SYNTAX_MESSAGE are quite different).

[[User:Maser|maser]] 00:54, 19 May 2006 (CEST)

That's correct. The existing error classes did not support everything they needed to support, so I reworte them. If you actually look at the parser error/warning classes in the parser cluster (not EiffelStudio's error classes) you'll see that the warning class is not even implemented!

As I said, the parser is a stand-alone library. The parser cluster was only moved under Src/Eiffel for ease to users to check out and compile Eiffel. In that respect you should just create an application that uses the parser library, as I did. I then sent a generated error string, from the error classes, to the the command-line shell.

[[User:Paulb|Paulb]] 22:14, 20 May 2006 (CEST)

I'm not sure if I understand what you mean. Basically, I should be able to take just the parser cluster and write a program that parses Eiffel files? But that's not possible, because EIFFEL_PARSER_SKELETON inherits from SHARED_ERROR_HANDLER, which is in the compiler cluster. Also, the error/warning classes in the parser cluster aren't used in ES, only the ones in the compiler cluster. I'd really like to create an application that uses the parser library, but I don't understand how it's going to work without the compiler cluster.

[[User:Maser|maser]] 01:38, 21 May 2006 (CEST)

== Interface to visualization group ==

As the parser produces ERROR objects and they contain information about position and description of the error and stores them in SHARED_ERROR_HANDLER.error_list, I suggest we use this as interface to exchange the data between the parser and visualisation groups.

[[User:Maser|maser]] 16:43, 18 May 2006 (CEST)

== suggestion for implementation ==

I've added a suggestion how to implement our changes. How bad is it? Comments? Improvements?

[[User:Maser|maser]] 16:35, 19 May 2006 (CEST)

Talk:Syntax checking/Parser

2006-05-19T14:35:55Z

Maser: suggestion for implementation

Syntax checking/Parser

2006-05-19T14:34:38Z

Maser: suggestion for implementation

Talk:Syntax checking/Parser

2006-05-18T22:54:07Z

Maser: /* find more than one error */

Syntax checking/Parser

2006-05-18T22:48:01Z

Maser: added eiffel.y

Talk:Syntax checking/Parser

2006-05-18T18:15:06Z

Maser: /* find more than one error */

Talk:Syntax checking/Parser

2006-05-18T14:43:40Z

Maser: Interface to visualization group

Talk:Syntax checking/Parser

2006-05-18T14:31:24Z

Maser:

Talk:Syntax checking/Parser

2006-05-17T20:55:40Z

Maser:

Talk:Syntax checking/Parser

2006-05-17T12:55:20Z

Maser:

User:Maser

2006-05-16T15:43:05Z

Maser:

=Martin Luder=

*email: luderm (at) student_ethz_ch
*mobile phone: 076 480 17 83
*MSN: martin_luder [AT] hotmail.com (this email address does not exist!)
*gtalk: martin.luder [AT] gmail.com

==Work==
[[Syntax checking]] project

Syntax checking/Parser

2006-05-16T15:41:20Z

Maser: added link to Syntax checking page

__NOTOC__

[[Syntax_checking|back to Syntax checking page]]

==Important Classes==

====EIFFEL_PARSER====
* has a feature parse(file)
====CLASS_AS====
* AST of a class
====ERROR====
* deferred; superclass of all error types like EIFFEL_ERROR or SYNTAX_ERROR
* features line, column: INTEGER give location of error
====ERROR_HANDLER====
* feature error_list: ERROR is a list of errors found by the parser
====SHARED_ERROR_HANDLER====
* singleton used by all relevant classes

====EIFFEL_CLASS_C====
* features build_ast and parse_ast show how the parser can be used.

Syntax checking/Parser

2006-05-16T14:01:16Z

Maser: /* SHARED_ERROR_HANDLER */

==important classes==

====EIFFEL_PARSER====
* has a feature parse(file)
====CLASS_AS====
* AST of a class
====ERROR====
* deferred; superclass of all error types like EIFFEL_ERROR or SYNTAX_ERROR
* features line, column: INTEGER give location of error
====ERROR_HANDLER====
* feature error_list: ERROR is a list of errors found by the parser
====SHARED_ERROR_HANDLER====
* singleton used by all relevant classes

====EIFFEL_CLASS_C====
* features build_ast and parse_ast show how the parser can be used.

Syntax checking/Parser

2006-05-16T13:55:57Z

Maser:

==important classes==

====EIFFEL_PARSER====
* has a feature parse(file)
====CLASS_AS====
* AST of a class
====ERROR====
* deferred; superclass of all error types like EIFFEL_ERROR or SYNTAX_ERROR
* features line, column: INTEGER give location of error
====ERROR_HANDLER====
* feature error_list: ERROR is a list of errors found by the parser
====SHARED_ERROR_HANDLER====
* singleton
====EIFFEL_CLASS_C====
* features build_ast and parse_ast show how the parser can be used.

Syntax checking

2006-05-16T13:39:58Z

Maser: /* Groups */

[[Category:Projects]]
[[Category:Editor]]

=Overview=
The aim of this project is to provide adequate, but non intrusive feedback to user about syntax errors. This is done by checking syntax as you type and underlining syntax errors by the well knwon wavy red line. Furthermore, error descriptions and possible solutions should be provided.

The Project is named '''SynChé''', which is a combination of syntax and checking.
The ''é'' at the end is important, as a cool name needs either a recursive acronym or a special character from a non English language.

=Software Requirement Specification (SRS)=
You can find our SRS [[Syntax_checking/SRS|here]]

=Groups=

* [[Syntax_checking/Visualisation|Visualisation]]
* [[Syntax_checking/Parser|Parser]]

=Milestones=

==M1: April 25th==
* Get home-grown EiffelStudio up and running.

==M2: May 2nd==
* '''Put your name in this Wiki!'''
* Analyse source code to certain degree, so discussion about interfaces between parser and visual is possible

==M3: May 9th==
* SRS written
* Overview of relevant classes (BON diagram or more)
* Further Project Milestones specified, based on SRS and knowledge about code

== May 12th ==
'''Results of the Meeting:''' [[Syntax_checking/Visualisation| Visualisation]]

==M4: May 23th==
*'''Parser Group''': Find out what results you get from the parser
*'''Visualisation Group''': Write a feature that draw the red underline

=Team=
Everyone intrested in this project is welcome to join our mailinglist [http://origo.ethz.ch/cgi-bin/mailman/listinfo/es-ui es-ui@origo.ethz.ch].
At this point, the team is divided into two groups at this point, one responsible for the parser, the other one for visual feedback (like underlininig).

== Visual Feedback ==
* [[User:jabernet| Janick Bernet]] (project leader)
* [[User:fdevries| Fabien de Vries]]
* [[User:indermum| Matthias Indermühle]]
* [[User:clerco| Olivier Clerc]]

== Parser ==
* [[User:maser| Martin Luder]]
* [[User:Chrigu| Christoph Huber]]
* [[User:goalgettah| Ueli Etter]]
* [[User:Squeezie| Michael Schär]]
* [[User:MarkoR| Marko Ristin]]

== Assistant ==
* [[User:classens| Stephan Classen]]

Syntax checking

2006-05-16T13:39:26Z

Maser: added section with links to groups

[[Category:Projects]]
[[Category:Editor]]

=Overview=
The aim of this project is to provide adequate, but non intrusive feedback to user about syntax errors. This is done by checking syntax as you type and underlining syntax errors by the well knwon wavy red line. Furthermore, error descriptions and possible solutions should be provided.

The Project is named '''SynChé''', which is a combination of syntax and checking.
The ''é'' at the end is important, as a cool name needs either a recursive acronym or a special character from a non English language.

=Software Requirement Specification (SRS)=
You can find our SRS [[Syntax_checking/SRS|here]]

=Groups=

* [[Syntax_checking/Visualisation]]
* [[Syntax_checking/Parser]]

=Milestones=

==M1: April 25th==
* Get home-grown EiffelStudio up and running.

==M2: May 2nd==
* '''Put your name in this Wiki!'''
* Analyse source code to certain degree, so discussion about interfaces between parser and visual is possible

==M3: May 9th==
* SRS written
* Overview of relevant classes (BON diagram or more)
* Further Project Milestones specified, based on SRS and knowledge about code

== May 12th ==
'''Results of the Meeting:''' [[Syntax_checking/Visualisation| Visualisation]]

==M4: May 23th==
*'''Parser Group''': Find out what results you get from the parser
*'''Visualisation Group''': Write a feature that draw the red underline

=Team=
Everyone intrested in this project is welcome to join our mailinglist [http://origo.ethz.ch/cgi-bin/mailman/listinfo/es-ui es-ui@origo.ethz.ch].
At this point, the team is divided into two groups at this point, one responsible for the parser, the other one for visual feedback (like underlininig).

== Visual Feedback ==
* [[User:jabernet| Janick Bernet]] (project leader)
* [[User:fdevries| Fabien de Vries]]
* [[User:indermum| Matthias Indermühle]]
* [[User:clerco| Olivier Clerc]]

== Parser ==
* [[User:maser| Martin Luder]]
* [[User:Chrigu| Christoph Huber]]
* [[User:goalgettah| Ueli Etter]]
* [[User:Squeezie| Michael Schär]]
* [[User:MarkoR| Marko Ristin]]

== Assistant ==
* [[User:classens| Stephan Classen]]