diff --git a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/eiffel-class-and-feature-names.wiki b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/eiffel-class-and-feature-names.wiki index 8ecabdfb..9f689577 100644 --- a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/eiffel-class-and-feature-names.wiki +++ b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/eiffel-class-and-feature-names.wiki @@ -59,7 +59,7 @@ In summary, Eiffel class names and type names from .NET assemblies made availabl ===Eiffel Names for .NET Types=== -How Eiffel compliant names are derived from .NET type names is fairly simple in most cases. The "simple" class name, that is, the word following the rightmost dot in the full class name, is converted to an Eiffel compliant name by making it upper case and separating in embedded words by underscore. In the example above, System.Collection.ArrayList becomes ARRAY_LIST . +How Eiffel compliant names are derived from .NET type names is fairly simple in most cases. The "simple" class name, that is, the word following the rightmost dot in the full class name, is converted to an Eiffel compliant name by making it upper case and separating in embedded words by underscore. In the example above, System.Collection.ArrayList becomes ARRAY_LIST. The other cases in the example are not quite so simple. If the basic derivation produces a name which conflicts with a classname in the Eiffel Base Library, then it will be disambiguated. The simple derivation of System.String would be STRING, but this would conflict with Eiffel's STRING class, so System.String becomes available to Eiffel for .NET programmers as SYSTEM_STRING. @@ -69,7 +69,7 @@ You'll see a little more about namespaces, assemblies, and Eiffel clusters in [[ ===Similar Types from Both Libraries=== -You may have noticed a similarity in the names and descriptions from the Eiffel Base Library and those from the .NET "mscorlib" library. This is not by accident. The Eiffel class STRING is a different class from the .NET type System.String , which Eiffel programmers see represented as Eiffel class SYSTEM_STRING . There is more on this subject in [[Similar Types Occurring in Both Libraries|Similar Types Occurring in Both Libraries]] . +You may have noticed a similarity in the names and descriptions from the Eiffel Base Library and those from the .NET "mscorlib" library. This is not by accident. The Eiffel class STRING is a different class from the .NET type System.String, which Eiffel programmers see represented as Eiffel class SYSTEM_STRING. There is more on this subject in [[Similar Types Occurring in Both Libraries|Similar Types Occurring in Both Libraries]] . ==Eiffel Feature Names== @@ -125,7 +125,7 @@ Member of type System.Text.StringBuilder The Eiffel language does not allow overloading routine names. That means that you cannot code multiple routines with the same name in a single class. That in itself is not a problem. But it also means that to work in the .NET environment, where overloading is allowed some compromise has to be made. So, what happens is this: if you are programming in Eiffel for .NET and you are using types from a .NET assembly, those types will be presented to you as if they are Eiffel classes. We have already seen that the type and feature names will be shown in the Eiffel naming convention. With overloaded feature names, the presentation will use name augmentation to disambiguate the overloaded versions. What you see is a distinct feature name for each overloaded version. The basic feature name is augmented by adding the types of its respective arguments, separated by underscore. -Let's look again at the two Append functions from System.Text.StringBuilder . +Let's look again at the two Append functions from System.Text.StringBuilder. .NET function signature: Append(System.String) @@ -153,17 +153,17 @@ Properties in .NET provide: * the opportunity to '''strengthen encapsulation,''' because values cannot be receive assignment without executing the property's "set" code * '''uniform access ''' queries because properties are queries, but unlike previous C-style OO languages in which properties did not exist, if a property is used in programming a client class, the programmer does not need to know whether the data provided by the property was done so from memory or through computation. This leaves the producer of the class with the property the latitude to change the implementation without breaking existing clients. -In Eiffel, the same goals are fulfilled, but a little differently. Simple attributes are well-encapsulated, because the Eiffel language does not allow direct assignment to them from outside the control of their class. So any assignment of the form x . f := y is not valid in Eiffel. To allow client to set values of the attribute f , the producer of the class of which x is an instance would have built a command (a " set_ " procedure) to do so. Then the code in a client to set f would look like this: x . set_f ( y ). +In Eiffel, the same goals are fulfilled, but a little differently. Simple attributes are well-encapsulated, because the Eiffel language does not allow direct assignment to them from outside the control of their class. So any assignment of the form x. f := y is not valid in Eiffel. To allow client to set values of the attribute f, the producer of the class of which x is an instance would have built a command (a " set_" procedure) to do so. Then the code in a client to set f would look like this: x. set_f ( y). -Uniform access is achieved in Eiffel through the way in which clientssee features which are queries. The code " print ( x . count )" applies the query count to the object attached to x and prints the result. You cannot tell by looking at this code whether count is an attribute or a function, that is, whether the count is returned from memory or through computation. In fact, it could be either, but that is a matter for its producer to deal with. As reuse consumers the implementation of count is not important to us ...but the fact that the producer can change the implementation without causing our code to need modification is very important to us. +Uniform access is achieved in Eiffel through the way in which clientssee features which are queries. The code " print ( x. count)" applies the query count to the object attached to x and prints the result. You cannot tell by looking at this code whether count is an attribute or a function, that is, whether the count is returned from memory or through computation. In fact, it could be either, but that is a matter for its producer to deal with. As reuse consumers the implementation of countis not important to us ...but the fact that the producer can change the implementation without causing our code to need modification is very important to us. Because Eiffel does not support properties directly, the propertiesof typeswhich Eiffel for .NET programmers usefrom .NET assemblies have to be mapped to Eiffel features. -In order to ask for the property's current value (technically, receiving the result of the property's get routine), a query feature is generated for the property. The query will be namedthe Eiffel name of the property. +In order to ask for the property's current value (technically, receiving the result of the property's get routine), a query feature is generated for the property. The query will be namedthe Eiffel name of the property. -As noted above, setting the value of a property cannot be done in Eiffel as it is done in C# and VB.NET because Eiffel disallows assignments of the form x . f := y . So, for each writable property, an Eiffel command feature is available to set the value of the property. The name for this command will be set_ followed by the Eiffel name for the property. +As noted above, setting the value of a property cannot be done in Eiffel as it is done in C# and VB.NET because Eiffel disallows assignments of the form x. f := y. So, for each writable property, an Eiffel command feature is available to set the value of the property. The name for this command will be set_ followed by the Eiffel name for the property. -As a result, the code for using a .NET property looks very much like the code to use an Eiffel attribute. In the following code fragment, an instance of the type System.Windows.Forms.Form which is available in Eiffel for .NET as WINFORMS_FORM is used by an Eiffel client. System.Windows.Forms.Form has a property Text which is of type System.String . Here the Text property is being set using the set_text feature, and then being recalled by using the query text . +As a result, the code for using a .NET property looks very much like the code to use an Eiffel attribute. In the following code fragment, an instance of the type System.Windows.Forms.Form which is available in Eiffel for .NET as WINFORMS_FORM is used by an Eiffel client. System.Windows.Forms.Form has a property Text which is of type System.String. Here the Text property is being set using the set_text feature, and then being recalled by using the query text. local my_window: WINFORMS_FORM @@ -199,9 +199,9 @@ In order to use .NET types that include static members, a special syntax has bee -The type System.Windows.Forms.Application is used here. It is available to Eiffel under the name WINFORMS_APPLICATION . The static member being used is Run , in particular the overloaded version of Run which takes an argument of type System.Windows.Forms.Form . That version is available in Eiffel under the name run_form . +The type System.Windows.Forms.Application is used here. It is available to Eiffel under the name WINFORMS_APPLICATION. The static member being used is Run, in particular the overloaded version of Run which takes an argument of type System.Windows.Forms.Form. That version is available in Eiffel under the name run_form. -The important thing to see here is that when you need to apply a static member, you introduce the call with the keyword feature . Then enclose the type name in braces and apply the feature as if it were targeted to an object. This isfairly close to the way that the call would be made in C#, where the feature name would be applied to the type name, versus a target object: +The important thing to see here is that when you need to apply a static member, you introduce the call with the keyword feature. Then enclose the type name in braces and apply the feature as if it were targeted to an object. This isfairly close to the way that the call would be made in C#, where the feature name would be applied to the type name, versus a target object: { Form my_window; diff --git a/documentation/current/solutions/preferences/eiffelpreferences/eiffelpreferences-class-reference.wiki b/documentation/current/solutions/preferences/eiffelpreferences/eiffelpreferences-class-reference.wiki index e1b6288f..060a7b38 100644 --- a/documentation/current/solutions/preferences/eiffelpreferences/eiffelpreferences-class-reference.wiki +++ b/documentation/current/solutions/preferences/eiffelpreferences/eiffelpreferences-class-reference.wiki @@ -1,6 +1,5 @@ -[[Property:title|EiffelPreference Class Reference]] -[[Property:link_title|EiffelPreferences Class Reference]] +[[Property:title|EiffelPreferences Class Reference]] [[Property:weight|1]] [[Property:uuid|9929ec96-07e2-1e6c-26db-d19ab947e1be]] -==View the [[ref:libraries/preferences/reference/index|EiffelPreference Class Reference]]== +==View the [[ref:libraries/preferences/reference/index|EiffelPreferences Class Reference]]== diff --git a/documentation/current/solutions/preferences/eiffelpreferences/eiffelpreferences-sample.wiki b/documentation/current/solutions/preferences/eiffelpreferences/eiffelpreferences-sample.wiki index 14e9d7ec..4599f118 100644 --- a/documentation/current/solutions/preferences/eiffelpreferences/eiffelpreferences-sample.wiki +++ b/documentation/current/solutions/preferences/eiffelpreferences/eiffelpreferences-sample.wiki @@ -1,5 +1,4 @@ -[[Property:title|EiffelPreference Sample]] -[[Property:link_title|EiffelPreferences Sample]] +[[Property:title|EiffelPreferences Sample]] [[Property:weight|2]] [[Property:uuid|f492e71c-07a8-9b1d-f72a-d59330acbf16]]
diff --git a/documentation/current/solutions/preferences/eiffelpreferences/eiffelpreferences-tutorial/index.wiki b/documentation/current/solutions/preferences/eiffelpreferences/eiffelpreferences-tutorial/index.wiki index e83b7dd4..cc13be39 100644 --- a/documentation/current/solutions/preferences/eiffelpreferences/eiffelpreferences-tutorial/index.wiki +++ b/documentation/current/solutions/preferences/eiffelpreferences/eiffelpreferences-tutorial/index.wiki @@ -1,8 +1,7 @@ -[[Property:title|EiffelPreference Tutorial]] -[[Property:link_title|EiffelPreferences Tutorial]] +[[Property:title|EiffelPreferences Tutorial]] [[Property:weight|0]] [[Property:uuid|0c717db7-fb53-80b3-e32f-cc8356afa5f8]] -The preference library is a platform independent library that can be used to add preference and configuration settings to your application. Briefly, the library provides support for creating fully configurable preference values, on a per application or per user basis. It also provides a graphical interface for manipulation of these values, and a easily extendible design for you to add your own custom preference types. +The EiffelPreferences library is a platform independent library that can be used to add preference and configuration settings to your application. Briefly, the library provides support for creating fully configurable preference values, on a per application or per user basis. It also provides a graphical interface for manipulation of these values, and a easily extensible design for you to add your own custom preference types. diff --git a/documentation/current/solutions/preferences/eiffelpreferences/eiffelpreferences-tutorial/initialization.wiki b/documentation/current/solutions/preferences/eiffelpreferences/eiffelpreferences-tutorial/initialization.wiki index d33a82c4..03187a92 100644 --- a/documentation/current/solutions/preferences/eiffelpreferences/eiffelpreferences-tutorial/initialization.wiki +++ b/documentation/current/solutions/preferences/eiffelpreferences/eiffelpreferences-tutorial/initialization.wiki @@ -74,33 +74,33 @@ As you can see creating preferences is very easy. Also you will notice that colo When you create a preference using a factory class you will provide a manager, a name for the preference, and a value. For example, in BASIC_PREFERENCE_FACTORY you create an integer preference by calling new_integer_resource_value: - new_integer_resource_value (a_manager: PREFERENCE_MANAGER; a_name: STRING; a_fallback_value: INTEGER): INTEGER_PREFERENCE is - -- Add a new integer resource with name `a_name'. If preference cannot be found in - -- underlying datastore or in a default values then `a_fallback_value' is used for the value. - require - name_valid: a_name /= Void - name_not_empty: not a_name.is_empty - not_has_resource: not a_manager.known_resource (a_name) - ensure - has_result: Result /= Void - resource_name_set: Result.name.is_equal (a_name) - resource_added: a_manager.preferences.has_resource (a_name) - end + new_integer_resource_value (a_manager: PREFERENCE_MANAGER; a_name: STRING; a_fallback_value: INTEGER): INTEGER_PREFERENCE + -- Add a new integer resource with name `a_name'. If preference cannot be found in + -- underlying datastore or in a default values then `a_fallback_value' is used for the value. + require + name_valid: a_name /= Void + name_not_empty: not a_name.is_empty + not_has_resource: not a_manager.known_resource (a_name) + ensure + has_result: Result /= Void + resource_name_set: Result.name.is_equal (a_name) + resource_added: a_manager.preferences.has_resource (a_name) + end An appropriate example in code of this could be: -window_width_preference: INTEGER_PREFERENCE - -- Preference holding value for width of application main window + window_width_preference: INTEGER_PREFERENCE + -- Preference holding value for width of application main window -initialize_my_preferences is - -- Initialize the application preferences - local - factory: BASIC_PREFERENCE_FACTORY - do - create factory - window_width_preference := factory.new_integer_resource_value (my_manager, "window_width", 480) - end + initialize_my_preferences + -- Initialize the application preferences + local + factory: BASIC_PREFERENCE_FACTORY + do + create factory + window_width_preference := factory.new_integer_resource_value (my_manager, "window_width", 480) + end This will create a new preference, which you can then use in your application to get, set and save the corresponding value when necessary. The issue to be aware of here though involves the value that the preference will contain when it is created. You see in the code above we pass the integer value 480. '''This does not mean, however, the initial value of the preference will be 480'''. This may sound odd, so let me explain... The value of a preference when initialized is determined by a number of factors. The first of these is the underlying data store value. If a preference value was changed in a previous session, by the user or by the application directly, and was saved to the underlying data store, then this value will be given priority. This makes sense, since if a user changes their preferences they don't want to have to do it every time they use your program. So, if they want the default window width to be larger, say 600, then this will be the value of the preference named "window_width" when initialized next time. Following this, if there is no previously saved value then the library will look for a default value to use. If a default file was given when the preferences were created (see above), and this default specifies a default value of 240 for the integer preference called "window_width", then this will be used. Finally, if no preference value was previously stored ''and'' no value is provided as a default value then the supplied value in the code is used - our 480 value from the example above. Although this process may seem confusing it is infact very simple and intuitive way to initialze the preferences. The process chart below illustrates more clearly the various permutations. @@ -110,11 +110,13 @@ The value of a preference when initialized is determined by a number of factors. Now you have preferences created you may use them from your application. Using the example preference above, window_width_preference, you can query the value of the preferences by simply querying the preference directly: window_width := window_width_preference.value Or for a value which should always be associated to the preference: -window_width: INTEGER is - -- Width of window - do - Result := window_width_preference.value - end + + window_width: INTEGER + -- Width of window + do + Result := window_width_preference.value + end + If you need to react when a preference value is changed you can hook up an agent to the change_actions of the preference: window_width_preference.change_actions.extend (agent my_agent_routine) To manually set the value of the preference call set_value or set_value_from_string, and to set a value for the default value call set_default_value. To reset a preference value back to it's original default value use reset. diff --git a/documentation/current/solutions/preferences/eiffelpreferences/eiffelpreferences-tutorial/interface-preferences.wiki b/documentation/current/solutions/preferences/eiffelpreferences/eiffelpreferences-tutorial/interface-preferences.wiki index 4a6630e5..726e6668 100644 --- a/documentation/current/solutions/preferences/eiffelpreferences/eiffelpreferences-tutorial/interface-preferences.wiki +++ b/documentation/current/solutions/preferences/eiffelpreferences/eiffelpreferences-tutorial/interface-preferences.wiki @@ -30,7 +30,7 @@ The preference library contains a cluster called interface. Thi |} All of these widgets inherit the abstract base class PREFERENCE_WIDGET and implement the required deferred features therein. Each implementation implements handling of an EV_GRID_ITEM widget from EiffelVision2 for use in the EV_GRID control, which allows for viewing and editing of the underlying preference value. For example, BOOLEAN_PREFERENCE_WIDGET uses an EV_GRID_COMBO_ITEM to display the 'True' and 'False' properties of a BOOLEAN_PREFERENCE. When the widget is loaded it displays the current value of the associated preference in the combo box. When the user changes the combo box value the preference value is changed also, and optionally saved. -Using these supplied widgets in your interface is simply a matter of creating the object and adding the change_item_widget to an instance of EV_GRID. By default the library provides such a view, in the form of PREFERENCES_WINDOW, which is a control that contains an EV_GRID and has all the necessary logic to handle graphical manipulation of the prefernce types provided in the library. This is an EV_TITLED_WINDOW with a navigable tree for finding groups of related preferences (i.e. managers), and a grid for displaying each preference. It is a useful, general purpose interface for preference manipulation. As with preferences themselves you may create your own custom view if this dialog is not sufficient for your needs, and can use the code therein as a template for your owm code. Below is an image of the supplied window as it appears in the EiffelStudio preferences environment. +Using these supplied widgets in your interface is simply a matter of creating the object and adding the change_item_widget to an instance of EV_GRID. By default the library provides such a view, in the form of PREFERENCES_WINDOW, which is a control that contains an EV_GRID and has all the necessary logic to handle graphical manipulation of the prefernce types provided in the library. This is an EV_TITLED_WINDOW with a navigable tree for finding groups of related preferences (i.e. managers), and a grid for displaying each preference. It is a useful, general purpose interface for preference manipulation. As with preferences themselves you may create your own custom view if this dialog is not sufficient for your needs, and can use the code therein as a template for your own code. Below is an image of the supplied window as it appears in the EiffelStudio preferences environment. [[Image:preference-window]] diff --git a/documentation/current/solutions/preferences/eiffelpreferences/eiffelpreferences-tutorial/overview.wiki b/documentation/current/solutions/preferences/eiffelpreferences/eiffelpreferences-tutorial/overview.wiki index b9dbdf62..5f8d8fcb 100644 --- a/documentation/current/solutions/preferences/eiffelpreferences/eiffelpreferences-tutorial/overview.wiki +++ b/documentation/current/solutions/preferences/eiffelpreferences/eiffelpreferences-tutorial/overview.wiki @@ -1,29 +1,31 @@ [[Property:title|Overview]] [[Property:weight|0]] [[Property:uuid|8f90ea04-493b-0e00-1327-c707a49e1c04]] -This document gives a brief overview of the preference library. +This document gives a brief overview of the EiffelPreferences library. ==Introduction== -Simply, preferences are name-value pairs. All preferences are descendents of the deferred class PREFERENCE, and therefore all inherit the common properties of name, value, default values and string representations. Common to all PREFERENCE objects is the notion of `manager'. All preferences belong to a manager, which is a helper class used for organizational and hierarchical management of your applications preferences. +Simply, preferences are name-value pairs. All preferences are descendants of the deferred class PREFERENCE, and therefore all inherit the common properties of name, value, default values and string representations. Common to all PREFERENCE objects is the notion of `manager'. All preferences belong to a manager, which is a helper class used for organizational and hierarchical management of your applications preferences. -So, all preferences belong to a PREFERENCE_MANAGER. The manager itself belongs to a set of related PREFERENCES. Infact, when you create a new manager for a group of preferences you must provide a PREFERENCES object to the creation routine to indicate which set of preferences the new manager will be associated: -make (a_preferences: PREFERENCES; a_namespace: STRING) is - -- New manager. - require - preferences_not_void: a_preferences /= Void - namespace_not_void: a_namespace /= Void - namespace_not_empty: not a_namespace.is_empty - ensure - has_preferences: preferences /= Void - inserted_in_preferences: preferences.has_manager (namespace) - has_namespace: namespace /= Void - namesapce_valid: not a_namespace.is_empty - end +So, all preferences belong to a PREFERENCE_MANAGER. The manager itself belongs to a set of related PREFERENCES. In fact, when you create a new manager for a group of preferences you must provide a PREFERENCES object to the creation routine to indicate which set of preferences the new manager will be associated: + + make (a_preferences: PREFERENCES; a_namespace: STRING) + -- New manager. + require + preferences_not_void: a_preferences /= Void + namespace_not_void: a_namespace /= Void + namespace_not_empty: not a_namespace.is_empty + ensure + has_preferences: preferences /= Void + inserted_in_preferences: preferences.has_manager (namespace) + has_namespace: namespace /= Void + namesapce_valid: not a_namespace.is_empty + end + You can see in the post-condition inserted_in_preferences that indeed the PREFERENCES object will have the new manager in its list of managers. -For every group of preferences or configuration values you therefore wish to create for your project, you will need a corresponding PREFERENCES object. In general one PREFERENCE object should be sufficient for most applications, and will be the point of reference for all preference values in the entire application. This class may be initialized in a number of ways, depending on the specific configuration of your application. It will be used to create new managers, store default preference values, and handle the saving and retrieval of preference values to and from the underlying data store between sessions. In between sessions the preference name and value pairs are persisted to an underlying data store. This may be any imaginable datastore, such as a file, database or external storage device. Support for XML and the Windows Registry is provided in the library by default, but it would not be be too difficult to provide an implementation for your needs (such as SQL database store). +For every group of preferences or configuration values you therefore wish to create for your project, you will need a corresponding PREFERENCES object. In general one PREFERENCES object should be sufficient for most applications, and will be the point of reference for all preference values in the entire application. This class may be initialized in a number of ways, depending on the specific configuration of your application. It will be used to create new managers, store default preference values, and handle the saving and retrieval of preference values to and from the underlying data store between sessions. In between sessions the preference name and value pairs are persisted to an underlying data store. This may be any imaginable datastore, such as a file, database or external storage device. Support for XML and the Windows Registry is provided in the library by default, but EiffelPreferences allows you to provide an implementation tailored to your specific needs (such as SQL database store). diff --git a/documentation/current/solutions/preferences/eiffelpreferences/index.wiki b/documentation/current/solutions/preferences/eiffelpreferences/index.wiki index 9f25643c..0baf9320 100644 --- a/documentation/current/solutions/preferences/eiffelpreferences/index.wiki +++ b/documentation/current/solutions/preferences/eiffelpreferences/index.wiki @@ -1,8 +1,7 @@ -[[Property:title|EiffelPreference]] -[[Property:link_title|EiffelPreferences]] +[[Property:title|EiffelPreferences]] [[Property:weight|1]] [[Property:uuid|f56ec405-6032-67dd-55e1-5a5ff7a4193c]] -==EiffelPreference Library== +==EiffelPreferences Library== Type: Library
Platform: Any
diff --git a/documentation/current/solutions/text-processing/eiffellex/eiffellex-tutorial.wiki b/documentation/current/solutions/text-processing/eiffellex/eiffellex-tutorial.wiki index 3a9afcf0..d814d881 100644 --- a/documentation/current/solutions/text-processing/eiffellex/eiffellex-tutorial.wiki +++ b/documentation/current/solutions/text-processing/eiffellex/eiffellex-tutorial.wiki @@ -5,7 +5,7 @@ When analyzing a text by computer, it is usually necessary to split it into individual components or '''tokens'''. In human languages, the tokens are the words; in programming languages, tokens are the basic constituents of software texts, such as identifiers, constants and special symbols. -The process of recognizing the successive tokens of a text is called lexical analysis. This chapter describes the Lex library, a set of classes which make it possible to build and apply lexical analyzers to many different languages. +The process of recognizing the successive tokens of a text is called lexical analysis. This chapter describes the EiffelLex library, a set of classes which make it possible to build and apply lexical analyzers to many different languages. Besides recognizing the tokens, it is usually necessary to recognize the deeper syntactic structure of the text. This process is called '''parsing''' or '''syntax analysis''' and is studied in the next chapter. @@ -16,9 +16,9 @@ Figure 1 shows the inheritance structure of the classes discussed in this chapte Figure 1: Lexical classes -==AIMS AND SCOPE OF THE LEX LIBRARY== +==AIMS AND SCOPE OF THE EIFFELLEX LIBRARY== -To use the Lex library it is necessary to understand the basic concepts and terminology of lexical analysis. +To use the EiffelLex library it is necessary to understand the basic concepts and terminology of lexical analysis. ===Basic terminology=== @@ -30,11 +30,11 @@ To define a lexical grammar is to specify a number of token types by describing A lexical analyzer is an object equipped with operations that enable it to read a text according to a known lexical grammar and to identify the text's successive tokens. -The classes of the Lex library make it possible to define lexical grammars for many different applications, and to produce lexical analyzers for these grammars. +The classes of the EiffelLex library make it possible to define lexical grammars for many different applications, and to produce lexical analyzers for these grammars. ===Overview of the classes=== -For the user of the Lex libraries, the classes of most direct interest are [[ref:/libraries/lex/reference/token_chart|TOKEN]] , [[ref:/libraries/lex/reference/lexical_chart|LEXICAL]] , [[ref:/libraries/lex/reference/metalex_chart|METALEX]] and [[ref:/libraries/lex/reference/scanning_chart|SCANNING]] . +For the user of the EiffelLex library, the classes of most direct interest are [[ref:/libraries/lex/reference/token_chart|TOKEN]] , [[ref:/libraries/lex/reference/lexical_chart|LEXICAL]] , [[ref:/libraries/lex/reference/metalex_chart|METALEX]] and [[ref:/libraries/lex/reference/scanning_chart|SCANNING]] . An instance of [[ref:/libraries/lex/reference/token_chart|TOKEN]] describes a token read from an input file being analyzed, with such properties as the token type, the corresponding string and the position in the text (line, column) where it was found. @@ -51,7 +51,7 @@ These classes internally rely on others, some of which may be useful for more ad ===Library example=== -The EiffelStudio delivery includes (in the examples/library/lex subdirectory) a simple example using the Lexical Library classes. The example applies Lex library facilities to the analysis of a language which is none other than Eiffel itself. +The EiffelStudio delivery includes (in the examples/library/lex subdirectory) a simple example using the EiffelLex library classes. The example applies EiffelLex library facilities to the analysis of a language which is none other than Eiffel itself. The root class of that example, EIFFEL_SCAN, is only a few lines long; it relies on the general mechanism provided by [[ref:/libraries/lex/reference/scanning_chart|SCANNING]] (see below). The actual lexical grammar is given by a lexical grammar file (a concept explained below): the file of name eiffel_regular in the same directory. @@ -222,7 +222,7 @@ This scheme is used by procedure analyze of class [[ref:/librar ==REGULAR EXPRESSIONS== -The Lex library supports a powerful set of construction mechanisms for describing the various types of tokens present in common languages such as programming languages, specification languages or just text formats. These mechanisms are called '''regular expressions'''; any regular expression describes a set of possible tokens, called the '''specimens''' of the regular expression. +The EiffelLex library supports a powerful set of construction mechanisms for describing the various types of tokens present in common languages such as programming languages, specification languages or just text formats. These mechanisms are called '''regular expressions'''; any regular expression describes a set of possible tokens, called the '''specimens''' of the regular expression. Let us now study the format of regular expressions. This format is used in particular for the lexical grammar files needed by class [[ref:/libraries/lex/reference/scanning_chart|SCANNING]] and (as seen below) by procedure read_grammar of class [[ref:/libraries/lex/reference/metalex_chart|METALEX]] . The ''eiffel_regular'' grammar file in the examples directory provides an extensive example.