eiffelroom

My three Eiffelwishes, part 3: readable types

dlebansais — Wed, 28 Jul 2010 00:35:44 +0000

In a previous blog entry, I related how I modified my code to split classes in two parts, separating commands and queries. In the conclusion I was suggesting that Eiffel could be extended to provide support for this. I will now formalize the language extension, and demonstrate how to use it to write even more solid code.

Contents

1 Introduction
2 First approach
3 Another approach: types that are only readable
4 Formal rules
5 The choice of readable
6 Application to manifest strings
7 Improper uses of readable types
8 Implementation

Introduction

The Command-Query Separation (CQS) principle states that features of a class should be either commands, that may modify the state of an object but do not return a result, or queries that return a result but don't modify the object. When classes are designed with CQS in mind, assertions are easier to write by simply calling only features that return a result. This guarantees that a program will produce the same output whether assertions are turned on or off: they don't change the state of objects.

The situation becomes more complicated when assertions are called with parameters. They must call only queries on the object being probed, but also on the parameters.

Therefore, for CQS to work properly, every class must follow this principle. The burden, for the programmer, is that each call must then be verified manually. In particular, if a query changes the state of one of its parameters, this state must be restored before the query returns the result. It is easy, in these conditions, to make mistakes.

Eiffel doesn't force programmers to follow CQS, but doesn't assist them in that task either. A feature that modifies one of its parameters and returns a result is a valid feature, by the language rules.

First approach

Let's introduce a new query keyword, to mark features as queries (and therefore, features without it as commands). The syntax would be the following:

query feature_name (parameters_list): return_type
body...end

A feature marked with the query keyword would have to follow some rules:

Only make unqualified calls to features that are also marked as queries.
Only make qualified calls to features that are also marked as queries, unless it applies to a local target.

The first restriction is severe since it forces us to change legacy code to add the query keyword in all classes. This can be alleviated if we trust libraries to follow CQS, and assume all features returning a result are queries.

This approach has some drawbacks:

The code of the feature can make an alias to one of the parameters, then call commands on the alias. The example below demonstrates this problem.

query some_feature (p: SOME_CLASS): ANY
local
    param_alias: like p
do
    ...
    param_alias := p
    param_alias.some_command
    ...
end

It should be possible to call commands on a parameter, if the object referenced by the parameter is restored to its previous state before the feature returns a result. Forbidding calls to commands is too restrictive.

Another approach: types that are only readable

A better option is to provide a finer grain of control over which feature is a query, and when calls are restricted to queries. This is a two steps process:

Mark features of a class that are queries as such.
Mark types for any target (including Current) to accept only calls to queries, when appropriate.

For this purpose, query is abandoned, and I'll use readable instead. This choice is discussed later in the post.

Here is a quick example of how it works, the syntax and rules are formalized in the next sections.

class
    A

feature

    readable some_query: SOME_TYPE
    do
        ...
    end

    some_command
    do
        ...
    end

end

class
    CLIENT

feature

    test (p: readable A)
    local
        x: A
        t: SOME_TYPE
    do
        ...
        t := p.some_query
        t := x.some_query
        ...
        p.some_command -- Compiler error: only features marked with readable can be called on p
        x.some_command
        ...
    end

end

In this example, the parameter p is of a type that has the readable tag. Only attributes, and features marked as readable, are available to p. x doesn't have this tag, and therefore all features of A can be called on the object referenced by x. Obviously, the assignment x := p would work around the restriction, so this assignment will be forbidden by the new rules detailed below.

Note that contrary to the first approach using the query keyword, the some_query feature can do whatever it wants with the object, including change its state. This possibility allows for instance the creation of a data cache, to make next calls to the feature faster.

Formal rules

I introduce a new keyword: readable. This keyword is used in two different contexts: readable features and readable types.

Readable features

The BNF syntax for feature declarations is modified as follow:

Feature_declaration: [readable] New_feature_list Declaration_body

New_feature_list: {New_feature "," …}+

New_feature: [frozen] Extended_feature_name

In this context, all feature names (some can be frozen) refer to a single feature, and this feature has the optional readable mark. This mark will be checked if the target of a call has only restricted access to the class the feature belongs to.

Readable types

Everywhere a construct is declared with a type, the type declaration is modified as follow:

Type: Readable_Type | Anchored

Anchored: [Attachment_mark] like [readable] Anchor

Readable_Type: [readable] Type_With_Access

Type_With_Access: Class_or_tuple_type | Formal_generic_name

These rules allow the following use of readable:

x: readable STRING
x: readable ARRAY[INTEGER]
x: ARRAY[readable STRING]
x: TUPLE[r_str: readable STRING; str: STRING]
x: readable TUPLE[INTEGER; readable BOOLEAN]
x(r_str: readable STRING) do...end
x(a,b,c: INTEGER; str: readable STRING): readable STRING do...end
inspect x when {STRING} ...when {readable STRING} ... end
x := create {readable STRING}.make_empty
create {readable STRING} x.make_empty
if attached {readable STRING} x as r_str then...end
agent f({STRING}?, {readable STRING}?)
x := {readable INTEGER}.min_value
x: like readable feature_name
x: like readable Current

In the non-object call {readable INTEGER}.min_value, there is no object which state can be modified, so in practice there is no difference between {readable INTEGER}.min_value and {INTEGER}.min_value, if one is a valid (or invalid) call, the other is too.

Anchored types

With the rules from the previous section, the syntax x: readable like feature_name is not permitted.

If x is declared as x: like readable feature_name and feature_name's type is already readable, a warning is issued. This is because feature_name can only be redefined in a type that is also readable (see the conformance section below).

Inheriting as readable

The inherit clause of a class is modified as follow:

Inherit_clause: inherit [Non_conformance] Parent_list

Parent_list: {Parent ";" …}+

Parent: [readable] Class_type [Feature_adaptation]

A parent class inherited as readable will not make commands available to the child class. More specifically, the only features available to unqualified calls in the parent class are:

Features that are marked with readable
Attributes
Features listed in the create clause. These are included so the parent can initialize properly.

Note that nothing prevents a feature in the descendant to call one of the creation features of the parent. It's the responsibility of the programmer to call them only the context of an object creation.

Conformance rules will be updated accordingly (see the corresponding section).

Generic constraints

The declaration of formal generics isn't modified, but use the new declaration of types:

Multiple_constraint: "{" Constraint_list "}"

Constraint_list: {Single_constraint "," …}+

Single_constraint: Type [Renaming]

It is therefore possible to write the following:

class A[G->readable ANY]

x: A[readable STRING]
x: A[STRING] -- This shouldn't compile

Conversion

Conversion clauses can be used to convert to and from readable types, with a separate feature for the type tagged as readable if desired. For instance, we can have:

class
    A

create
    make_from_string,
    make_from_readable_string

convert
    make_from_string({STRING}),
    make_from_readable_string({readable STRING}),
    to_string: {STRING},
    to_readable_string: {readable STRING}

feature

    make_from_string(s: STRING) do...end

    make_from_readable_string(s: readable STRING) do...end

    readable to_string: STRING do...end

    readable to_readable_string: readable STRING do...end

end

Most classes will just use the version with a readable input, since they typically don't modify the object being converted. In this example, I marked to_string and to_readable_string as readable, since they are queries.

Call restrictions

In qualified or unqualified calls, there is always a target of some type T. Sometimes this type is explicit, and sometimes it's inferred using many rules, but in the end there is always a type T. This type may or may not have the readable tag. If it doesn't, all usual rules apply to decide if the call is valid, like the export status of the called feature for instance.

If the type T is tagged as readable, there are additional checks to make before the call can be considered valid:

The feature is marked as readable
The feature is an attribute
The call is a creation instruction (or expression)

The later case is needed to allow the creation of objects that have been declared as readable, without making the code uselessly complicated. For instance, we can always write the following:

local
    x: readable STRING
do
    create {STRING} x.make_empty
    ...
end

But it's just easier to use create x.make_empty.

Assignment

Assigning a new value to an attribute can be a regular assignment, a tuple field assignment, a conversion or the call to an assigner. The last two cases are handled with the call restriction rules described above.

The case of a regular attachment, for reference types, is a simple conformance check, described in the next section. For expanded types, assigning to a readable entity is invalid.

For tuples, assigning a field of a readable tuple is invalid. Consider the code below:

x: TUPLE[s: readable STRING]
y: readable TUPLE[s: STRING]

x.s := "" -- Valid, STRING conforms to readable STRING
y.s := "" -- Invalid, y is readable

Conformance

The check of conformance between two types must be extended to handle differences in the readable tag. This can be seen as an extra dimension in the description of classes and type. The rules are simple:

T conforms to readable T, that is if x is of type readable T, and y of type T, x := y is valid.
readable T doesn't conform to T. Some languages may allow it, like C++ with the const_cast operator, but in my experience there is always a way to redesign the code to remove the need for this.
If class B is a descendant of the base class A, but with the inherit readable A clause, readable B conforms to readable A, but B doesn't. Neither conform to A.
If G is a generic parameter with a readable constraint, only readable types conform to the constraint.

Redefinition of a readable feature

If a feature is marked as readable, all redefinitions in descendants must also be readable. The reasoning is that, since the feature is a query, it should remain a query even if the implementation changes in descendants. Remember, readable features can still change the state of the object, it's only a mark to identify the feature as a query, and it doesn't put any constraints on the redefined versions.

Error messages

Along with the introduction of the concept of readable features and types, I created a new category of specific error messages, VURE. They correspond to the following errors:

VURE1
Calling a feature without the readable mark on a target of a readable type.
Details:

Enclosing feature name
Called feature name
Type name (readable)

VURE2
Renaming, changing the export status, redefining, undefining, selecting and otherwise using a feature when the parent class is inherited as readable, and the feature doesn't have the readable mark.
(This replaces VHRC, VLEL, VDRS, VDUS, VMSS, VEEN since it's a special case of these validity rules)
Details: same as the replaced error.

VURE3
A formal generic parameter is constrained to be a readable type, but the actual type is not readable.
(This replaces VTGD2 since it's a special case of constrained genericity rules)
Details: same as the replaced error.

VURE4
Assignment to a target of readable expanded type
(This covers the case of assigning the field of a readable tuple as well)
Details:

Enclosing feature name
Target of the assignment
Type name (readable)

VURE5
A readable type doesn't conform to a non-readable type
(This replaces VNCC since it's a special case of conformance rules)
Details: same as the replaced error.

VURE6
A readable feature is redefined but the redefinition doesn't have a readable mark
(This replaces VDRD since it's a special case of redefinition rules)
Details: same as the replaced error.

The choice of readable

I chose to use only one keyword, when it facts it's used for two separate concepts:

Readable features, making a feature as a query
readable types, an attribute of types used for additional validity rules.

Ideally, I should have kept the query keyword for features, and the readable keyword for types. In my first example, the code would look like this:

class
    A

feature

    query some_query: SOME_TYPE
    do
        ...
    end

    some_command
    do
        ...
    end

end

class
    CLIENT

feature

    test (p: readable A)
    local
        x: A
        t: SOME_TYPE
    do
        ...
    end

end

I think it makes more sense to mark queries with the query keyword, and types that can only be used to read the state of an object with readable. A counter argument is that, since both concepts are related, it makes sense to use just one keyword for both, and readable STRING seems a better choice than query STRING.

There is of course the fact that the number of keywords and reserved identifiers should be kept to a minimum. And finally, since legacy code will sometimes use them and therefore must be updated, it's better to just have one identifier name to change. On this subject, I found that readable is used as an identifier in some classes of EiffelStudio, but replacing it with a different name wasn't too much of an effort.

Application to manifest strings

A special case that could use the concept of readable types is the basic type STRING. In Eiffel, it is possible to modify manifest strings after creation:

local
    s: STRING
do
    s := "Hello"
    s.append(", world");
    s.print -- Prints "Hello, world"
end

Some consider this behavior as normal and expected, while others point out that manifest strings look like constants. A solution to reconcile both views could be the offer the option to have manifest string be of type readable STRING. This way, programmers that want to deal with constants can set the option and write:

local
    s: STRING
do
    create s.make_empty
    s.append("Hello");
    s.append(", world");
    s.print
end

Improper uses of readable types

The concept of readable types doesn't make all programs foolproof. If a class A make one of the objects of class B it references available to clients, even if A is readable the B object can be modified. Consider this example:

class
    B

feature

    some_command
    do
        ...
    end

end

class
    A

feature

    readable some_query: B
    do
        ...
    end

end

class
    CLIENT

feature

    test
    local
        a: readable A
        b: B
    do
        ...
        b := a.some_query
        b.some_command -- Valid since b is of type B, not readable B.
        ...
    end

end

We shouldn't change the design of readable types to force some_query in the example above to return a readable B. Perhaps A is some factory, and some_query is designed to build new objects, intended to be fully modifiable the client.

The workaround is to change the code slightly and handle both cases:

class
    A

feature

    readable some_query_readable: readable B
    do
        Result := some_query
    end

    some_query: B
    do
        ...
    end

end

class
    CLIENT

feature

    test
    local
        a: readable A
        b: readable B
    do
        ...
        b := a.some_query_readable
        ...
    end

end

Notice how some_query lost the readable tag. It is now only available to clients with unrestricted access. The other version some_query_readable returns a readable type, as expected, and is therefore safe.

This pattern is probably pretty common, and leads to some code duplication. If there was a way for the designer of A to indicate that some_query should return a readable B if called on a readable A object, all this code should be unnecessary.

I didn't find a satisfactory syntax without introducing a new keyword. I believe it could be done reusing the like keyword:

readable some_query_readable: B readable like Current

But that's some verbose and confusing English!

Implementation

I have started implementing these changes, based on version 6.6.8.3873 of EiffelStudio (the current official release). Unfortunately, the compiler code is quite complex, and my time limited. I can offer a partial implementation, basically everything that can emit a VURE1 and VURE4 error code, with the exception of the like readable Feature_Name syntax.

It's available for the 32-bits Windows platform at http://www.filefactory.com/file/b2bh3cc/n/ec.zip (for a week). Other platforms available on request, if I can fix the compilation issues I ran into lately and that I fixed for Windows.

If time allows, I hope to realize a complete implementation, although this partial version is sufficient for my own needs.

Another Eiffelwish: A cluster concept with restricted visibility (to avoid name clashes).

helmut.brandl — Tue, 20 Jul 2010 15:12:25 +0000

The Eiffel language in its current definition has no concept of namespaces. However in large programs using many libraries name clashes (i.e. two classes having the same name) become more and more probable.

Different Eiffel compilers have resolved the name clashes with different strategies. This is not satisfactory because it is not portable. Therefore the Eiffel language should be extended to resolve potential name clashes of class names in a manner which is independant from the used compiler.

The following paper contains a proposal for a cluster concept which is capable of handling and resolving class name clashes. All the mechanisms described below are extensions to the Eiffel language. I.e. with that extensions the Eiffel language is capable of handling and resolving name clashes within the language (without the use of some compiler specific configuration files).

The basic concepts are views and clusters. Each class belongs to exactly one cluster and has exactly a view of classes which it can use. This makes it possible that a class does not see all classes of the universe but only a limited set of classes. Furthermore views have the possibility to rename some of the classes. A class rename is local to a view.

Fully qualified names for classes are introduced as a last resort to resolve name clashes.

Having a standardized way to express used clusters within Eiffel, it is possible to simplify small programs as a side effect. Complete Eiffel programs can be contained within one file with all the needed (usually very little to none) cluster information. A "Hello world" program becomes the trivial `do print("Hello world%N") end' without any definition of a root class nor a root procedure and without any necessary configuration file.

Therefore the cluster concept makes Eiffel more scalable in both directions: for small programs and for large programs.

Read the detailed paper at http://tecomp.sourceforge.net/index.php?file=doc/papers/lang/cluster.txt

Proofs for Eiffel SW

helmut.brandl — Wed, 07 Jul 2010 18:42:40 +0000

The following paper describes a proof engine for the Eiffel language.

The proof engine allows the verification of the assertions of Eiffel code. Some language extensions are introduced to express proofs of assertions. Within the proofs the user can enter proof commands and the proof engine can verify the correct use of the proof commands.

Modularization techniques are introduced to the keep the proofs small and expressive.

The proof engine has some improved features to do the burdensome work for the user. It is expected that the developer enters the key assertions and proves them and the proof engine can verify the routines using the key assertions.

In the first chapter the basic concepts are explained.

The second chapter introduces the commands of the proof engine.

The third chapter shows how basic properties of boolean expression can be proved with the proof engine.

The forth chapter applies the proof engine to assertions within the class INTEGER

The fifth chapter shows how routines can be proved.

Find the detailed paper at http://tecomp.sourceforge.net -> white papers -> verification -> proof engine

BALIGN - A multi-functional batch sequence alignment tool

eser.aygun — Thu, 01 Jul 2010 10:23:17 +0000

BALIGN is a multi-functional batch sequence alignment tool. It has been used in several bioinformatics applications by İTÜ Computer Engineering Bioinformatics Group, but its abilities are not limited to biological sequences. Any type of sequence with an ASCII representation and a scoring matrix can be handled by BALIGN. The source code contains generic aligner classes which can be used separately.

Contents

1 Download
2 Citation
3 Features
4 Contact

Download

You can download BALIGN here. There is also an online bioinformatics toolkit including BALIGN for biological sequences here. For example scoring matrices to be used in BALIGN, refer here.

Citation

If you use BALIGN in your research, please cite the following article:

Aygün, E.; Oommen, B. & Cataltepe, Z. Peptide classification using optimal and information theoretic syntactic modeling Pattern Recognition, Elsevier, 2010

Features

Here is an incomplete list of features that has been implemented in BALIGN so far.

Sequence Alignment

Using BALIGN, you can compute pairwise alignments for given lists of sequences. It can perform both global and local alignment with affine gap penalties, and it can produce bit score, conservation score and percent identity matrices. For more information please see:

Needleman, S. & Wunsch, C. A general method applicable to the search for similarities in the amino acid sequence of two proteins J. Mol. Biol, 1970, 48, 443-453
Smith, T. & Waterman, M. Identification of common molecular subsequences J. Mol. Bwl, 1981, 147, 195-197

Transition Probability

Sequence transition probability computation is a fairly new and robust method of sequence comparison. It is formalized by Oommen and Kashyap in 1998 and applied to the peptide classification problem successfully by Aygün, Oommen and Cataltepe in 2009. You can use BALIGN to compute logarithmic transition probability matrices for given lists of sequences. For more information please see:

Oommen, B. & Kashyap, R. A formal theory for optimal and information theoretic syntactic pattern recognition Pattern Recognition, Elsevier, 1998, 31, 1159-1177
Aygün, E.; Oommen, B. & Cataltepe, Z. Peptide classification using optimal and information theoretic syntactic modeling Pattern Recognition, Elsevier, 2010
Aygün, E.; Oommen, B. & Cataltepe, Z. On utilizing optimal and information theoretic syntactic modeling for peptide classification Pattern Recognition in Bioinformatics, IAPR, 2009

Compound Sequence Alignment and Compound Transition Probability

In 2000, Wallqvist et al. showed that aligning amino acid sequences along with secondary structures increases the classification performance significantly. Compound versions of alignment score and transition probability algorithms let you combine primary structure and secondary structure information in a single computation to generate more informative similarity scores. For more information please see:

Wallqvist, A.; Fukunishi, Y.; Murphy, L.; Fadel, A. & Levy, R. Iterative sequence/secondary structure search for protein homologs: comparison with amino acid sequence alignments and application to fold recognition in genome databases. Bioinformatics, Oxford, 2000, 16, 988

Contact

BALIGN is implemented by Eser Aygün.

BALIGN

eser.aygun — Thu, 01 Jul 2010 10:18:45 +0000

Short Description:

Multi-functional batch sequence aligner incorporating Needleman-Wunsch, Smith-Waterman and Oommen-Kashyap algorithms along with compound alignment of secondary sequences.

Contents

1 Download
2 Citation
3 Features
4 Contact

Download

You can download BALIGN here. There is also an online bioinformatics toolkit including BALIGN for biological sequences here. For example scoring matrices to be used in BALIGN, refer here.

Citation

If you use BALIGN in your research, please cite the following article:

Aygün, E.; Oommen, B. & Cataltepe, Z. Peptide classification using optimal and information theoretic syntactic modeling Pattern Recognition, Elsevier, 2010

Features

Here is an incomplete list of features that has been implemented in BALIGN so far.

Sequence Alignment

Needleman, S. & Wunsch, C. A general method applicable to the search for similarities in the amino acid sequence of two proteins J. Mol. Biol, 1970, 48, 443-453
Smith, T. & Waterman, M. Identification of common molecular subsequences J. Mol. Bwl, 1981, 147, 195-197

Transition Probability

Oommen, B. & Kashyap, R. A formal theory for optimal and information theoretic syntactic pattern recognition Pattern Recognition, Elsevier, 1998, 31, 1159-1177
Aygün, E.; Oommen, B. & Cataltepe, Z. Peptide classification using optimal and information theoretic syntactic modeling Pattern Recognition, Elsevier, 2010
Aygün, E.; Oommen, B. & Cataltepe, Z. On utilizing optimal and information theoretic syntactic modeling for peptide classification Pattern Recognition in Bioinformatics, IAPR, 2009

Compound Sequence Alignment and Compound Transition Probability

Wallqvist, A.; Fukunishi, Y.; Murphy, L.; Fadel, A. & Levy, R. Iterative sequence/secondary structure search for protein homologs: comparison with amino acid sequence alignments and application to fold recognition in genome databases. Bioinformatics, Oxford, 2000, 16, 988

Contact

BALIGN is implemented by Eser Aygün.

Dependencies:

EiffelBase

Gobo Eiffel Structure

EiffelTime

URL:

http://balign.sourceforge.net/

Download:

https://sourceforge.net/projects/balign/

Documentation:

http://balign.sourceforge.net/

My three Eiffelwishes, part 2: Unicode

dlebansais — Tue, 29 Jun 2010 12:06:47 +0000

If English is your primary language, you've probably never used characters from a foreign language in Eiffel source files. Perhaps you'll be interested in this little experiment then: create a classic "Hello, world" program and run it, then replace the string with its translation in, say, arabic, and run it again.

The classic "Hello, world" program:

Running the program:

The modifed program with a translated string:

Running the modified program:

As you can see, the result is not exactly the expected one. The reason is simple: EiffelStudio doesn't store characters as unicode, but rather in ASCII format. What you see in the modified text code is a display artifact, and not the string as stored in the source file. Just close and reopen the class text to make this clear. Arabic characters have been lost.

Contents

1 Unicode
2 Benefits of unicode
3 Existing support
4 Solutions

Unicode

Unicode is a standard for storing and manipulating characters from pretty much all languages around the world, including ancient languages that appear only in old texts. The first version of the standard was published in 1991.

Unicode isn't a file format. To store unicode text, an editor has several options, but ASCII isn't one of them and for this reason editors that manipulate ASCII files will not read or write unicode text correctly. This is what's happening with EiffelStudio.

Benefits of unicode

If EiffelStudio could fully support unicode, there would be several benefits for programmers.

Comments

A comment written with characters that don't belong to the ASCII set can be stored and read properly by people using the same language, however it becomes unreadable for foreign reader. This is because these characters are encoded in a format that depends on the language used (if you're unfamiliar with the concept of code page, have a look at this article on Wikipedia). Unicode source files would not have this problem, all comments would be readable regardless of the default language chosen by the reader.

Translated strings

Many programs offer a choice between languages to use when installing or executing. This makes them more accessible to users unfamiliar with English. There is unfortunately no easy way to write strings and their translated versions in Eiffel program. For instance, programs targetting windows must create resource (.rc) files that aren't directly usable, and these .rc files aren't unicode. Unicode source files would offer the possibility to directly create and initialize localized strings, assuming proper classes become available to support that.

Operators

Free operators could be single unicode characters, like ∑ or ∩. Existing character combinations could be better displayed with a single unicode character:

← instead of :=
« and » instead of "[ and ]" (the most commonly used manifest string markers)

Existing support

EiffelStudio already includes classes to manipulate unicode strings, in the "encoding" library. However, each programmer must implement the code to read and write files in one of the unicode formats, convert the string and then use it. In practice, it's not hard to write applications that are properly localized, and use unicode strings. But it could be easier with direct support of unicode in the source code.

Solutions

A simple mechanism could be use to allow unicode characters in source files while remaining backward compatible. Currently, each file can be considered as using an informal code page that depends on the language used by the programmer, in strings and comments. By adding a note associated to the class, this code page can be made explicit:

note
	-- Comments and strings are in French.
	code_page: "fr-FR"
class
	SOME_CLASS

This can be done automatically with tools.

One of the code page can be UTF-8. This format allows encoding of any unicode character while remaining compatible with most of the ASCII characters. A source file encoded using UTF-8 with only English strings and comments will be identical to its ASCII counterpart. Then EiffelStudio can have a setting indicating which code page to use by default, one of them being UTF-8. This enables everyone to keep their source code unchanged, or move to UTF-8 while keeping their old code unchanged if they add the note.

With this mechanism, new source files containing strings and comment in UTF-8 are compatible with versions of EiffelStudio not supporting unicode, old source files remain compatible with new versions of EiffelStudio, and if old/new files are mixed, they can all be displayed correctly thanks to the note clause.

There remains the problem of free operators and other symbols used in the language. A solution to this problem consists of encoding unicode characters using valid characters for free operators, for instance:

Encoding ← with :=
Encoding « with "[ and » with ]"
Encoding ∑ with |+|

Since the set of ASCII characters for free operators is limited, if we don't want long sequences it would be a good idea to restrict unicode characters usable for free operators in a first implementation, then specify how they are encoded. If this becomes a standard, then every sequence of characters used for free operators today can be displayed using its unicode counterpart. I believe the Eiffel community is small enough to agree on a common representation of unicode free operators, and to modify existing source code to make them look better if they want to.

Eiffel Arbitrary Precision Number Library

clemahieu — Thu, 17 Jun 2010 16:46:37 +0000

Short Description:

A pure-Eiffel arbitrary precision integer library based on GMP.

Dependencies:

EiffelBase

URL:

http://code.google.com/p/eapml/

Download:

http://eapml.googlecode.com/files/eapml.7z

Documentation:

http://code.google.com/p/eapml/wiki/FAQ

My three Eiffelwishes, part 1: enums

dlebansais — Sun, 13 Jun 2010 13:04:14 +0000

For people that routinely switch between programming languages like me, it's temping to try to get the best of all and mix language features. The most common example (and likely the most researched) being to add assertions to C++ or C# classes, for instance.

While working on Eiffel code, I repeatedly found that my code could be simpler, and better, if I had access to some features of C-like languages. Today I'd like to talk about one of them: enumerations.

Contents

1 Previous work
2 What's an enum?
3 Expectations
4 Inheritance
5 The new syntax
6 Creation
7 Conclusion

Previous work

There is an article on enums and how to implement them with the current design of Eiffel at this page. While the code could use some improvement with the recent addition of void safety and CAPs, it's a start. In particular, it introduces the necessary features that type-safety and invariants require. It doesn't, however, provide a good solution if the goal is to have simpler code. The ENUM class, for instance, expects a generic parameter, and some code is duplicated. Moreover, the author doesn't investigate improvements that would require a change in the language.

What's an enum?

An enumeration can be defined as a set of named entities, sometimes associated to a known numerical value. Typical examples are club, diamond, heart and spade, each a playing card suit, or jack, queen, king and ace, associated to values 1, 2, 3 and 4 respectively (some readers might have recognized common values used in contract bridge).

An enumeration is a type. And, therefore, eventually a class. Following examples above, we could consider classes SUIT and HONOUR, and it would allow us to write code such as:

class
	PLAYING_CARD
 
feature
	suit: SUIT
	honour: HONOUR
 
end

The definition and behavior of SUIT and HONOUR is the purpose of this post.

Expectations

How should we use enums and how do they make code simpler? It should be possible to use them in place of numerical constants.

In conditional statements:

if suit = {SUIT}.club then
...
end

In inspect statements:

inspect suit
when {SUIT}.club then
...
end

And, of course, assignments:

suit := {SUIT}.club

Note that, in the code above, no actual numerical value is expected. For all we know, the internal representation of {SUIT}.club is a reference and it varies from one execution of the program to the other. Also, while assigning an enum value with an associated constant to a numerical type is possible, the other way around is prohibited.

i: INTEGER
i := honour
honour := i -- Prohibited

It is debatable whether an enum type should have a default initialization value, like other base types do. For some enums there might be an obvious candidate, but for our SUIT example none of the 4 values stands above others.

There is however an important property of enums that can be used or ignored without interfering with the program: values can be ordered, typically in the order they appear in the definition of the enum class. In practice, this would mean that SUIT and HONOUR inherit from COMPARABLE, and that the following statements are valid:

if honour < {HONOUR}.ace then ... end
 
inspect honour
when {HONOUR}.jack..{HONOUR}.king then
...
end

It should be possible to enumerate through values as well. For the purpose of displaying their names, or associated constants for instance. The code below shows how to achieve that:

across suit.items as value
loop
	print(value.item.out) -- Print the value name
end

Last but not least, an attribute of an enum type can only be assigned one of the values in the enum declaration, and at any time it cannot contain anything else than these values. This will be the default class invariant.

The question remains whether enums should have implicit numeric constants associated to each values. Such constants are needed when:

The program is connected to external components, like C code where enum values are fixed, known constants
out, print etc. feature are called for enum attributes, to obtain printable representations
Values are associated to specific constants for a purpose, in HONOUR for instance where constants represent a number of points to use during a bid.
Attributes of enum type are serialized

Perhaps the best approach is to leave the specification of the constants open, and just require that the internal representation of enum values be consistent with the cases listed above. At worst, it means that when interfacing with other languages, the compiler must require all values to have explicit associated constants. It would however be preferable to have a smarter compiler, capable of assigning the proper constants to enum values depending on the language it interfaces with.

In any case, if the value is associated to a numerical constant, this constant should be available to code through conversion.

Inheritance

Like any class in Eiffel, an enum can have descendants, and these should be able to redefine features, but also add, remove or rename values. The standard syntax can be used to rename or remove values, however the case of addition must be carefully considered, since it can break the order defined by the parent.

Descendants can also add attributes. What is the semantic, then, of an assignment like suit := {SUIT}.club, or the honour < {HONOUR}.ace expression? The simple answer is that {SUIT}.club and {HONOUR}.ace are objects of type SUIT and HONOUR, and these classes must have either default values, or redefine default_create such that {SUIT}.club and {HONOUR}.ace can be created by the compiler.

In the case of the honour < {HONOUR}.ace expression, if is_less is not redefined, then HONOUR is partially ordered around its enum values, and other attributes are ignored during expression evaluation.

The new syntax

It is now time to describe my new suggested syntax, and see how it fits into Eiffel.

First of all, all user-defined enums can inherit from the system ENUM class, inheriting itself from COMPARABLE and equipped with built-in features to ensure that values are kept ordered, to enforce the invariant, and provide representations for names and associated constants.

The ENUM class would have the following contract:

expanded class
	ENUM
 
inherit
	COMPARABLE
		redefine
			is_less
		end
 
	HASHABLE
		undefine
			is_equal
		redefine
			hash_code
		end
 
feature -- Implementation of deferred
 
	is_less alias "<" (other: like Current): BOOLEAN
	external
		"built_in"
	end
 
	hash_code: INTEGER
	external
		"built_in"
	end
 
feature -- Set
 
	items: LIST[like Current]
	external
		"built_in"
	end
 
invariant
	-- Consistency is enforced by the compiler
 
end

The ENUM class is simply an enum with no values, and each user-defined enum simply add new values thanks to an additional clause in the inheritance part:

class
	SUIT
 
inherit
	ENUM
		unique
			club, diamond, heart, spade
		end
end

And voilà!

Values order is the order of declaration in the unique clause. Everything else is provided by the ENUM class and fairly simple new rules for handling enum values in various part of the language: expressions, the inspect statement, conversions, assignment and so on.

Values can be given an associated numerical constant:

class
	HONOUR
 
inherit
	ENUM
		unique
			jack = 1, queen = 2, king = 3, ace = 4
		end
end

Descendants can add values to an existing set:

class
	POWER_CARD
 
inherit
	ENUM
		unique
			joker = 0
		end
	HONOUR
end

In this example, the value order in the POWER_CARD enum class is: joker, then all values from HONOUR. To make the new joker card the last value, change the order of inherited classes declaration:

class
	POWER_CARD
 
inherit
	HONOUR
	ENUM
		unique
			joker = 5
		end
end

Since HONOUR inherits from ENUM, the above declaration could be made even simpler:

inherit
	HONOUR
		unique
			joker = 5
		end

It is interesting to note that the compiler should make sure that the declaration order is compatible with the natural order of associated constants, and that numerical constants are preserved by inheritance. For instance, the following declaration should be prohibited:

inherit
	HONOUR
		unique
			joker = 0
		end

Other languages may allow enums to have unordered constants, but my personal feeling is that it's a recipe for disaster, and the symptom of a design error.

The unique clause can be used in conjunction with other clauses in the inheritance part of the class declaration:

class
	JOKE_CARD
 
inherit
	HONOUR
		rename
			jack as jack_the_mischevious,
			queen as queen_the_sad,
			king as king_the_deceived,
			ace as ace_for_nothing,
		unique
			joker_smiling_face
		redefine
			is_less
		end
 
feature
 
	is_less alias "<" (other: like Current): BOOLEAN
		-- Reverse the order and make the joker the less powerful card
	do
		Result := not Precursor(other)
	end
 
end

Creation

With this syntax, no creation procedure can be written that can initialize the value. Therefore, either enumeration types are initialized to a standardized default value, like the first value, or they are not initialized at all until client classes assign them a value. The later behavior is similar to references in a void-safe environment.

What if the enum class has other attributes? A default_create redefinition can handle this case, as the example below demonstrates:

class
	SUIT
 
inherit
	ENUM
		unique
			club, diamond, heart, spade
		redefine
			default_create
		end
 
create
	default_create
 
feature -- Initialization
 
	default_create
	do
		manufacturer := "none"
	end
 
feature -- Status
 
	manufacturer: STRING
 
end

Here, the assignment suit := {SUIT}.club still makes sense and will reset all additional attributes of 'suit' to their default value, i.e. manufacturer to "none".

Conclusion

I think enumeration types are a much needed feature in Eiffel. It allows simpler, easier to read code. I suggested a syntax that makes both the declaration and use of enums a simple task. While I haven't tested an actual implementation of the new unique clause, I hope something similar will make it in the language, eventually.

eMPC

saunders — Fri, 11 Jun 2010 22:48:07 +0000

Short Description:

Eiffel interface to the "C" MPC library

Eiffel interface to the "C" MPC library. This library requires you to build GMP(http://gmplib.org/), MPFR(http://www.mpfr.org/) and MPC(http://www.multiprecision.org/). It depends on eGMP and eMPFR.

To build on Windows I recommend MSYS. To build on 64-bit Windows I recommend MSYS and MinGW64. In the project settings dialog I needed to include the file "C:\MinGW_64\lib\gcc\x86_64-w64-mingw32\4.4.5\libgcc.a".

Dependencies:

eGMP

eMPFR

saunders — Fri, 11 Jun 2010 22:37:47 +0000

Short Description:

Eiffel interface to "C" MPFR

Eiffel interface to the "C" MPFR library. Contains a class MPFR_FUNCTIONS that gives a direct interface to the "C" functions. Class MPFR inherits from NUMERIC. To build this library you will need to build GMP(http://gmplib.org/) and MPFR(http://www.mpfr.org/) and this library depends on eGMP.

To build on Windows I recomend MSYS. For 64-bit I recomend MSYS and MinGW64. When I built this library on Windows 7 64-bit I had to include this in my project settings - C:\MinGW_64\lib\gcc\x86_64-w64-mingw32\4.4.5\libgcc.a under Advanced->Externals in the Project Settings dialog of EiffelStudio.

Dependencies:

eGMP

saunders — Fri, 04 Jun 2010 07:20:50 +0000

Short Description:

Eiffel interface to "C" GMP

This library is very similar to Multiple Precision also published here. The current version is based on GMP 5.0.1 and you will need to build this library for yourself in order to use this. You can acquire GMP from http://gmplib.org/. I have done little testing on this version yet but most of the classes are identical to the ones in Multiple Precision. If you have used Multiple Precision there is a small likelihood that any code based on that library will break on this one. Keep in mind that it might. Multiple Precision had classes MPFR and MPC which are not present in this one. In the future I intend to create eMPFR and eMPC as seperate libraries. MPFR is supposed to make a new release soon and I am waiting till that is available before I create those libraries. The Multiple Precision library was based on MPIR which is not strictly compatible with GMP and I desired that. This was my motivation for creating this library.

To build on Windows I recomend MSYS. For 64-bit I recomend MSYS and MinGW64.

Dependencies:

EiffelBase

Moving to a readable/writable model

dlebansais — Thu, 03 Jun 2010 22:04:13 +0000

Contents

1 Introduction
2 Starting with an example
3 Splitting the class
4 Refining the model
5 Inheritance
6 Deferred and once routines
7 Generics
8 Conclusion

Introduction

Work a long time on your code, and you will have countless opportunities to experiment with software design. Today, I'd like to describe how I moved some classes to a new model for separating queries and commands.

The need for this came to me because of complex assertions. It turns out that if the code called during assertions evaluation involves a large number of classes and features, it becomes difficult to ensure that it doesn't have side effects. My first approach was to verify the state of my objects dynamically and ensure it wasn't modified. Lately, I moved to a more static approach whereby classes involved during assertions evaluation only contain queries. It is this work I present here. The tradeoffs are mentioned in the conclusion section.

Starting with an example

I will begin with a SAMPLE class, containing some queries and commands.

class
	SAMPLE
 
create
	make
 
feature -- Initialization
 
	make
	do
		expanded_attribute := 0
		create reference_attribute.make_empty
	end
 
feature -- Queries
 
	expanded_value: INTEGER
	do
		result := expanded_attribute
	end
 
	reference_value: STRING
	do
		result := reference_attribute
	end
 
feature -- Commands
 
	change_expanded (new_value: INTEGER)
	do
		expanded_attribute := new_value
	end
 
	change_reference (new_value: STRING)
	do
		reference_attribute := new_value
	end
 
feature {NONE} -- Implementation
 
	expanded_attribute: INTEGER
	reference_attribute: STRING
 
end

This is close to the most basic example of a class with queries and commands. I separated expanded and reference types to demonstrate how a query can indirectly allow side effects to happen during execution. Here, a client class can call the reference_value feature to obtain access to reference_attribute and modify it. In the case of the expanded_value feature, the object is copied and can't produce side-effects.

The new model consists of splitting SAMPLE in two classes, SAMPLE and READABLE_SAMPLE.

Splitting the class

Let's see how we can do it on the sample code. All queries that can't produce side effects are moved to READABLE_SAMPLE, remaining features stay in SAMPLE. Finally SAMPLE inherits from READABLE_SAMPLE to produce a class that behaves identically to the old version. Creation functions can't be considered as producing side affects, but they can be called by clients if their export status is not {NONE}, and in that case are commands. This problem is easily fixed by setting the export status to {NONE} in READABLE_SAMPLE, and to the value it should have in the SAMPLE class.

Here is a first draft of the new code.

class
	READABLE_SAMPLE
 
create
	make
 
feature {NONE} -- Initialization
 
	make
	do
		expanded_attribute := 0
		create reference_attribute.make_empty
	end
 
feature -- Queries
 
	expanded_value: INTEGER
	do
		result := expanded_attribute
	end
 
	reference_value: STRING
	do
		result := reference_attribute
	end
 
feature {NONE} -- Implementation
 
	expanded_attribute: INTEGER
	reference_attribute: STRING
 
end

class
	SAMPLE
 
inherit
	READABLE_SAMPLE
		export {ANY}
			make
		end
 
create
	make
 
feature -- Commands
 
	change_expanded (new_value: INTEGER)
	do
		expanded_attribute := new_value
	end
 
	change_reference (new_value: STRING)
	do
		reference_attribute := new_value
	end
 
end

This first approach allows us to pass references to READABLE_SAMPLE objects when we don't want clients to be able to modify the object. It has some flaws, one of them already mentioned.

It does nothing about commands inherited from ANY, most notably copy.
The object can be modified if a client calls reference_value to get a reference to reference_attribute.

Before we refine the model, let's see an example of code that takes advantage of it.

class
	SOME_CLIENT
 
feature
 
	create_new_sample: SAMPLE
	do
		create result.make
 
		-- Do some stuff with the new object...
	ensure
		is_valid(result)
	end
 
	is_valid (a_sample: READABLE_SAMPLE): BOOLEAN
	do
		-- Perform queries on 'a_sample'
		-- Commands are statically rejected here
	end

In is_valid only queries can be called, and if a_sample is passed to other routines, they will also be unable to call commands. Actually, this is not entirely true. Since the object is in fact a SAMPLE object, a client routine could obtain a reference to the object as SAMPLE from the reference to READABLE_SAMPLE with a Certified Attachment Pattern (CAP). Consider the code below:

	is_valid (a_sample: READABLE_SAMPLE): BOOLEAN
	do
		if attached {SAMPLE} a_sample as a_writable_sample then
			-- Call commands on a_writable_sample here, and therefore modify the state of the object.
		end
	end

There is nothing we can do about this other than performing a copy of the object into a new READABLE_SAMPLE object. But this hurts performance, and the new model becomes useless since we could have kept the SAMPLE class as is, with all side-effects happening in the copy. We will assume that the writer of the code respects the intent of the new model and doesn't do such an horrible thing!

Refining the model

The case of the copy feature is typical and we will meet it again when we consider descendants of SAMPLE. Here is a feature that should not be in READABLE_SAMPLE and yet must be in SAMPLE. The solution to this problem is two-fold:

We change the export status of copy so that clients cannot call it. The export status to {ANY} will be reinstated in SAMPLE.
As an additional precaution, we rename copy into a new name intended to discourage descendants of READABLE_SAMPLE from using it.

Indeed, any class inheriting from READABLE_SAMPLE could call copy. By changing its name, we make sure that descendant classes know what they doing. The correct name can be reused in SAMPLE the same way it is exported.

class
	READABLE_SAMPLE
		rename
			copy as forbidden_copy
		export {NONE}
			forbidden_copy
		end
 
create
	make
 
feature {NONE} -- Initialization
 
	make
	do
		expanded_attribute := 0
		create reference_attribute.make_empty
	end
 
feature -- Queries
 
	expanded_value: INTEGER
	do
		result := expanded_attribute
	end
 
	reference_value: STRING
	do
		result := reference_attribute
	end
 
feature {NONE} -- Implementation
 
	expanded_attribute: INTEGER
	reference_attribute: STRING
 
end

class
	SAMPLE
 
inherit
	READABLE_SAMPLE
		rename
			forbidden_copy as copy
		export {ANY}
			make, copy
		end
 
create
	make
 
feature -- Commands
 
	change_expanded (new_value: INTEGER)
	do
		expanded_attribute := new_value
	end
 
	change_reference (new_value: STRING)
	do
		reference_attribute := new_value
	end
 
end

This is how we handle the first problem. But what about the second? We have two options:

Return a copy of reference_attribute instead of a direct reference to it. This is at the cost of performance and should be avoided when possible.
If reference_attribute is of a type that has a corresponding READABLE_ counterpart, return the read-only type in READABLE_SAMPLE, and the full type in a redefined version of the query in SAMPLE.

Fortunately for us, STRING is already implemented like that since it inherits (in its latest incarnation) from READABLE_STRING, or more accurately from the corresponding sized variant. The solution is therefore to have 2 versions of reference_value with different return type. We can take advantage of it to make both versions available in SAMPLE, since returning a read-only version makes sense even for the modifiable class. But in this case they must have different names. This is easily obtained with renaming, as the reader can see below:

class
	READABLE_SAMPLE
 
inherit
	ANY
		rename
			copy as forbidden_copy
		export {NONE}
			forbidden_copy
		end
 
create
	make
 
feature {NONE} -- Initialization
 
	make
	do
		expanded_attribute := 0
		create reference_attribute.make_empty
	end
 
feature -- Queries
 
	expanded_value: INTEGER
	do
		result := expanded_attribute
	end
 
	reference_value: READABLE_STRING
	do
		result := reference_attribute
	end
 
feature {NONE} -- Implementation
 
	expanded_attribute: INTEGER
	reference_attribute: STRING
 
end

class
	SAMPLE
 
inherit
	READABLE_SAMPLE
		rename
			forbidden_copy as copy,
			reference_value as readable_reference_value
		export {ANY}
			make, copy
		end
 
create
	make
 
feature -- Queries
 
	reference_value: STRING
	do
		result := reference_attribute
	end
 
feature -- Commands
 
	change_expanded (new_value: INTEGER)
	do
		expanded_attribute := new_value
	end
 
	change_reference (new_value: STRING)
	do
		reference_attribute := new_value
	end
 
end

Here, a client of SAMPLE can obtain either full access to reference_attribute by calling reference_value, or read-only access by calling readable_reference_value. A client of READABLE_SAMPLE could only get the read-only reference with a call to reference_value. Hence the semantic of this feature is preserved.

The sample class doesn't have an invariant, because they didn't create any problem for me. I just moved all invariants to the readable version of the splitted classes.

Inheritance

Single inheritance

Things can be formalized when a descendant inherits from a parent and both can be splitted. Let's call PARENT and READABLE_PARENT the classes to inherit from, CHILD and READABLE_CHILD the descendants. The inheritance scheme is CHILD -> READABLE_CHILD -> PARENT -> READABLE_PARENT. What we need is to make commands and queries that can lead to side-effects coming from PARENT unavailable to clients of READABLE_CHILD.

In READABLE_CHILD
- Commands are renamed as forbidden_<command name> and their export status changed to {NONE}.
- Queries allowing side effects have a readable_<query name> version. We rename <query name> to forbidden_<query name> and readable_<query name> to <query name>. Similarly to commands, we also change their export status.
In CHILD
- We reinstate commands with their original name and export status.
- We rename queries again (and change export) to the readable_<query name> and <query name> versions.

The resulting code, quite complicated, is listed below. SAMPLE and READABLE_SAMPLE are used to demonstrate queries that return a read-only version of an object to avoid side-effects.

class
	READABLE_PARENT
 
inherit
	ANY
		rename
			copy as forbidden_copy
		export {NONE}
			forbidden_copy
		end
 
create
	make
 
feature {NONE} -- Initialization
 
	make
	do
		-- Create the object
	end
 
feature
 
	query1: READABLE_SAMPLE
	do
		-- Create a read-only version of a SAMPLE object
	end
 
	query2: INTEGER
	do
		-- Return an expanded object. This query won't need any redefinition.
	end
 
end

class
	PARENT
 
inherit
	READABLE_PARENT
		rename
			forbidden_copy as copy,
			query1 as readable_query1
		export {ANY}
			copy
		end
 
create
	make
 
feature
 
	command
	do
		-- Perfoms some command
	end
 
feature
 
	query1: SAMPLE
	do
		-- Return a writable version of the sample object.
	end
 
end

class
	READABLE_CHILD
 
inherit
	PARENT
		rename
			copy as forbidden_copy,
			command as forbidden_command,
			query1 as forbidden_query1,
			readable_query1 as query1
		export {NONE}
			forbidden_copy, forbidden_command, forbidden_query1
		end
 
create
	make
 
end

class
	CHILD
 
inherit
	READABLE_CHILD
		rename
			forbidden_copy as copy,
			forbidden_command as command,
			query1 as readable_query1,
			forbidden_query1 as query1
		export{ANY}
			copy, command, query1
		end
 
create
	make
 
end

As long as all classes follow this model, assertions can be coded using only the READABLE_xxx version of classes as parameters.

In one occasion, almost the entire code of a class was dedicated to creating the object. This forced me to put all code in the readable version of the class. If no other class than SAMPLE inherits from READABLE_SAMPLE, then it's not much of a problem. Otherwise, the solution consists of implementing these features directly with the forbidden_ prefix and export to {NONE}.

Multiple inheritance

The case of multiple inheritance is slightly more complicated, but the rules are identical. In one case I had to merge different versions of copy. Taking the example of the PARENT and CHILD classes again, here is the corresponding code.

class
	READABLE_CHILD
 
inherit
	FIRST_PARENT
		rename
			copy as forbidden_copy
		export {NONE}
			forbidden_copy
		redefine
			forbidden_copy
		end
 
	SECOND_PARENT
		rename
			copy as forbidden_copy
		export {NONE}
			forbidden_copy
		redefine
			forbidden_copy
		end
 
feature {NONE}
 
	forbidden_copy (other: like current)
	do
		precursor{FIRST_PARENT}(other)
		precursor{SECOND_PARENT}(other)
	end
 
end

class
	CHILD
 
inherit
	READABLE_CHILD
		rename
			forbidden_copy as copy
		export{ANY}
			copy
		end
 
create
	make
 
end

Creation of readable objects

In my sample code, READABLE_SAMPLE is a class with a create clause. That is, READABLE_SAMPLE objects can be created, and for them no command can be called ever. They represent constant objects with a state fixed at creation. It turned out to be a problem in my code, because of anchor types and result types that are sometimes tied to the readable version of SAMPLE. For instance, if a query returns a READABLE_SAMPLE object destined to be stored and modified later, there will be no actually modification possible if the object was created with a code like create Result.make. To solve this issue, and make sure that all non-constant objects are properly created, I proceeded in three steps:

I made all readable versions of classes deferred and removed their create clause.
I recompiled and fixed all errors by changing code like create Result.make to result := create {SAMPLE}.make
I made all readable versions normal classes again (i.e. not deferred anymore) and reinstated the create clauses.

Deferred and once routines

Deferred routines can be a problem if they are commands. This is because they should be implemented in the writable version of the class, which means the readable version must be declared as deferred and therefore cannot have creation procedures. The solution I found was to declare the deferred command in the readable version of the class, but with an empty body and with export {NONE}. Then I redefine it with the appropriate implementation in the writable version.

Once routines are easier to manage. They create a problem because there must not be two versions of the once routine. For instance, if once_fcn is the routine name, we must not end up with readable_once_fcn too, otherwise it could be executed twice. This case happens only if the once routine is a function returning a reference to a writable object, and to a read-only object for the readable_once_fcn case. The solution consists of moving the code to a third implementation_once_fcn once function, belonging to the readable version of the class of course. once_fcn and readable_once_fcn can then be separate routines returning the appropriate object type, since they call a once function themselves.

Here is a more comprehensive example:

class
	READABLE_SAMPLE
		rename
			copy as forbidden_copy
		export {NONE}
			forbidden_copy
		end
 
create
	make
 
feature -- Initialization
 
	make
	do
		-- Some init
	end
 
feature -- Queries
 
	once_fcn: READABLE_CHILD
	once
		result := implementation_once_fcn
	end
 
feature {NONE} -- Implementation
 
	implementation_once_fcn: CHILD
	once
		create result.make
		-- Do stuff here
	end
 
end

class
	SAMPLE
 
inherit
	READABLE_SAMPLE
		rename
			forbidden_copy as copy,
			once_fcn as readable_once_fcn
		export {ANY}
			make, copy
		end
 
create
	make
 
feature -- Queries
 
	once_fcn: CHILD
	once
		result := implementation_once_fcn
	end
 
end

The idea of moving the code to a third function makes sense for all functions, and not only if they are "once", for the purpose of avoiding code replication. However, most of the time I didn't do it because the resulting code was more complicated and harder to understand.

Generics

When the sample class is parameterized with generic classes like in SAMPLE[G], I needed to access the readable version of G. There is unfortunaly no easy way to do that, so eventually I resorted to recode SAMPLE[G] as SAMPLE[READABLE_G, G->READABLE_G]. Here, the intended purpose is to have G being a direct descendant of READABLE_G but this is not something that can be enforced. For generic parameters that are not splitted, I could use the class twice like in SAMPLE[INTEGER, INTEGER], since a class always conforms to itself. This works with expanded classes, or classes that only have queries, but not with most classes coming from libraries.

Unfortunately, EiffelStudio doesn't fully implement the SAMPLE[READABLE_G, G->READABLE_G] syntax. G isn't considered conforming to READABLE_G when checking constraints. Let's make it more clear with an example:

class
	READABLE_SAMPLE[READABLE_G, G->READABLE_G]
 
inherit
	ANY
		rename
			copy as forbidden_copy
		export {NONE}
			forbidden_copy
		end
 
create
	make_from_other
 
feature {NONE} -- Initialization
 
	make_from_other (other: READABLE_G)
	do
		other_ref := other
	end
 
feature -- Queries
 
	object_ref: READABLE_G
	do
		Result := other_ref
	end
 
feature {NONE} -- Implementation
 
	other_ref: READABLE_G
 
end

class
	SAMPLE[READABLE_G, G->READABLE_G]
 
inherit
	READABLE_SAMPLE[READABLE_G, G]
		rename
			forbidden_copy as copy
		export {ANY}
			make_from_other, copy
		redefine
			object_ref
		end
 
create
	make_from_other
 
feature -- Queries
 
	object_ref: G
	do
		Result := other_ref
	end
 
feature -- Commands
 
	change_reference (new_value: G)
	do
		other_ref := new_value
	end
 
end

Here G is not recognized as a descendant of READABLE_G and this code won't compile.

I worked around this issue with a hack in the compiler, until better support for this kind of constraint is added to the language.

Conclusion

I demonstrated how I changed my code to move to a read/write, read-only class model. The change was necessary to write complex code to be used during assertions evaluation. Another, easier way to obtain the same result is to execute the assertion code on a copy of the program state, since it guarantees (within some limits) that there will be no side-effects on the core of the program. The tradeoff is to exchange simpler code for poor performance.

The new model forced me to duplicate almost all classes.
All class headers can easily be cluttered with a lot of rename and export clauses.
Class names are longer, and if they use generics, a lot longer.
Renaming a feature forbidden_<feature name> is not a proper protection against using the feature
This doesn't work well with libraries. I ended up rewriting several of the basic structure classes.

On this subject, things can be automated since I've been following a small set of rules. If the language had support for this model, the code would look a lot more simpler. For instance, introducing a new keyword 'readable', here is what the compiler could do:

Split all classes in two, 'readable SAMPLE' being an alias to READABLE_SAMPLE.
Move all queries to the readable version of the class. To indicate which feature is a query, just put 'readable' in front of the feature name.
For duplicated queries (<feature name> and readable_<feature name>) make the readable version available with 'readable <feature name>'
Hide commands instead of renaming them to forbidden_<command name>.
If G is a generic, Make 'readable G' an alias for READABLE_G and take SAMPLE[G] to mean SAMPLE[readable G, G->readable G].
Provide default yet unavailable versions of deferred features that are commands, so a readable class can be created. Code once functions to be called once even if they have two versions.

This would need to be better formalized of course. Perhaps I'll play with the compiler to try it one day. I'll live with the modified code for now.

How should we compute the result of DATE.is_leap_year?

manus_eiffel — Tue, 01 Jun 2010 19:30:11 +0000

Using Gregorian calendar even for date older than 1582

67% (4 votes)

Using Julian calendar for dates up to 1582, and then Gregorian calendar

17% (1 vote)

Remove `is_leap_year' from date and adds some calendar classes

17% (1 vote)

Total votes: 6

Recompiling EiffelStudio on Windows

dlebansais — Mon, 31 May 2010 20:13:11 +0000

Recently I found an issue with EiffelStudio and some .NET assemblies. I decided to rebuild my own version of the Eiffel compiler to implement a quick workaround. I succeeded but had to overcome some small issues, so in this post I will provide a detailed guide on how to proceed.

I won't cover the case of operating systems other than Windows, and will focus on Windows Vista, although almost everything applies to Windows XP as well.

There is a page at dev.eiffel.com [1] describing the procedure. If my way doesn't work for you, please follow instructions from that page, it should be up to date.

Contents

1 Importing the source code
2 Preparing the building process
3 Building the compiler
4 Staying up to date

Importing the source code

The source code of most of EiffelStudio is available as web pages at svn.origo.ethz.ch [2], and through CVS (Concurrent Versioning System) as well. Using a CVS client is the easy way if you have one installed. If not, I suggest to use TortoiseSVN, by doing the following:

Go to http://tortoisesvn.tigris.org/, click the Dowload button, then pick the version corresponding to your version of Windows. I chose the 32-bit version.

Install TortoiseSVN

Reboot Windows, if the installation program asks you to.

Once a CVS client is available, you will need to choose a folder where to download the source code. EiffelStudio developers recommend to choose a name of the form xxdev where xx is the major and minor version of EiffelStudio. For instance, 66dev for version 6.6. From experience, this is only good if you want to maintain several branches of the code simultaneously, but our case all we want is the latest version. Therefore, another name like 'EiffelStudioSource' is probably better suited. This is the name I will use throughout the rest of this guide.

Wherever you put the source file, make sure the full path to this folder doesn't contain any space. For instance, 'EiffelStudio Source' doesn't work.

Open the explorer, go to where this folder will be created, right-click the base folder and select 'SVN Checkouts...'

Fill the url line exactly as below, and the folder line as you want. You can use the default values for other options in the dialog box. Here is the base url that you can copy-paste: https://svn.eiffel.com/eiffelstudio/trunk (don't forget to add /Src).

If you run into the following error, it's up to you to accept or reject the invalid certificate.

There will be 4 checkouts to perform. Here is the mapping to use. Note that the /Src folder isn't mapped the same way as the other 3.

Url	Folder
https://svn.eiffel.com/eiffelstudio/trunk/Src	C:\Users\dlebansais\Documents\EiffelStudioSource
https://svn.eiffel.com/eiffelstudio/trunk/Delivery	C:\Users\dlebansais\Documents\EiffelStudioSource\Delivery
https://svn.eiffel.com/eiffelstudio/trunk/Documentation	C:\Users\dlebansais\Documents\EiffelStudioSource\Documentation
https://svn.eiffel.com/eiffelstudio/trunk/free_add_ons	C:\Users\dlebansais\Documents\EiffelStudioSource\free_add_ons

The entire download process takes about an hour.

Preparing the building process

Since I'm assuming you have EiffelStudio installed already, you must have a C compiler installed as well. However, as far as I know the Eiffel compiler source code is built with Visual Studio 2005. I used Visual Studio 2008, if you don't have one of them you will probably have to install Visual Studio. For this purpose, Microsoft offers a free version called Visual Studio Express, but I didn't try it.

To prepare the building process, you need to set two environment variables. This is done from the Control Panel, choose the System icon and on the left of the dialog box click Advanced system settings.

Click the Environment Variables button to pop the dialog used to manage environment variables.

In the section dedicated to user variables (the top section), click New... and enter the following:

Name: EIFFEL_SRC Value: The name of the folder where the source code was downloaded, in my case C:\Users\dlebansais\Documents\EiffelStudioSource.

Create another environment variable called ISE_LIBRARY and give it the same value. If you forget to do that, the building process can go pretty far but eventually will fail.

Building the compiler

Now, what the official instructions don't tell you, is that you need to launch a specific command prompt. To find it, click the start button and navigate through the 'All programs' menu to find the Visual Studio group. Under this menu is the Visual Studio Tools group, that countains the Visual Studio Command Prompt. Open it.

This will automatically setup the environment required to run the C compiler.

Now, type

cd %EIFFEL_SRC%
cd C
configure win32 m

This is assuming you want to build the 32-bit version of the compiler, of course. Otherwise, type 'configure win64 m'.

This command starts the build of all C files required by Eiffel source files. Once done, just close the command prompt. From now on, we will run tools coming from EiffelStudio, so launch the command prompt that the EiffelStudio installation provides, you can find it the same way you found the Visual Studio prompt.

If launching this prompt generate a few error messages, you will need to fix your EiffelStudio installation (I reported this bug and it should be fixed if you installed recently). You need to modify the following file: <EiifelStudio path in program Files>\studio\config\windows\esvars.bat

Change

set RegKeyPath=HKEY_LOCAL_MACHINE\SOFTWARE\ISE\Eiffel65

to become

set RegKeyPath=HKEY_LOCAL_MACHINE\SOFTWARE\ISE\Eiffel66

With this fix, the EiffelStudio command prompt should now start flawlessly. Type the following:

cd %EIFFEL_SRC%\library\net\Clib
finish_freezing -library
cd %EIFFEL_SRC%\library\vision2\Clib
finish_freezing -library
cd %EIFFEL_SRC%\library\wel\Clib
finish_freezing -library
cd %EIFFEL_SRC%\library\cURL\Clib
finish_freezing -library
cd %EIFFEL_SRC%/C_library/zlib
finish_freezing -library
cd %EIFFEL_SRC%/C_library/libpng
finish_freezing -library
cd %EIFFEL_SRC%/framework/cli_writer/Clib
finish_freezing -library
cd %EIFFEL_SRC%/framework/cli_debugger/Clib
finish_freezing -library

Until now, we have compiled C and C++ files. We are now ready build the compiler from Eiffel source files. Before this final step, you need to choose which version of the compiler you want, and if you want to finalize it. To choose the compiler version, you can pick one of these arguments for the -target option:

batch
bench_windows

This will compile either the command-line version or the studio version of the compiler. There are actually two possibilities for the studio version, either bench or bench_windows. I'm not sure what the difference is, and so far bench_windows has worked for me.

To build a finalized version, simply add -finalize to the command.

If like me you plan to rebuild the compiler regularly, when source files are updated, you can create your own batch file, with these lines:

@echo off
cd "%ISE_EIFFEL%\studio\config\windows"
call esvars.bat
cd %EIFFEL_SRC%\Eiffel\Ace
ec -config ec.ecf -target bench_windows -c_compile -finalize

The file you have built is %EIFFEL_SRC%\Eiffel\Ace\EIFGENs\bench_windows\F_code\ec.exe

Staying up to date

Every time a developer updates a source file, you can get the change with your SVN client. In the case of TortoiseSVN, simply open the explorer, find the 'EiffelStudioSource' folder, right-click and choose 'SVN Update'. This will automatically download all modified files.

EiffelStudio 6.6 released

manus_eiffel — Sat, 29 May 2010 16:44:35 +0000

We are pleased to announce the availability of EiffelStudio 6.6. It can be downloaded at http://www.eiffel.com/downloads.

The release notes are available at http://docs.eiffel.com/book/eiffelstudio/release-notes-eiffelstudio-66.

To me this release brings even more stability and some new language features which I'll highlight below:

Some incremental bugs that usually affects large and complex recompilation have been addressed.
Our multithreaded runtime has been rewritten to be even more portable and to guarantee the same behavior of mutexes across platforms (before mutexes were recursive on Windows but not on our other platforms, now it is always recursive).
We have introduced once per object and the new once syntax (once ("PROCESS") or once ("THREAD") or once ("OBJECT")).
We have introduced the new check instructions to simplify the writing of void-safe code:

check attached expression as e then
	e.do_something
end

when clearly something should be attached but the context is not strong enough for the compiler to guarantee it. If at runtime this was not true a check violation will be raised.

We have introduced this not yet adopted feature of the ECMA specification that has been requested by some Eiffel users for many years. The name is not yet decided, so far we have two attempted names: RAT (Remote Anchorted Types) or QAT (Qualified Anchored Types). It basically let you write a type declaration using like with not just a feature name but with an expression, that is to say like a.b.c. This is very practical to reduce the number of copy/paste in types and let you evolve your software easily by only changing a type at one place, instead of at many places (think of changing all your declarations of LINKED_LIST into ARRAYED_LIST in your code).

Tell me more about your experience using EiffelStudio 6.6 and what you are planning on doing with it. In the meantime, Happy Eiffeling!

Manu