Eiffel Language Skins

Introduction

This page documents the concept of 'language skins' for Eiffel, and in particular, a C-style language skin to enable developers used to C-based syntax of languages like C++, C#, Java, Scala etc to work in Eiffel. The basic concept is thus one or more semantically equivalent 'surface syntaxes' that convert to the underlying Eiffel language semantic model somewhere early in the parsing process. Initially the intention is to concentrate on a single C-style skin, which for the moment we will call 'Javel' (suggested by Bertrand Meyer: a nice pronounceable word that also happens, in his usual playful way to mean [other things|http://fr.wikipedia.org/wiki/Eau_de_Javel], in this case the name of a Parisian quartier and an industrial strength cleaning agent once manufactured there).

Discussion

For the moment there is no mailing list for this activity, and we will proceed using an email loop, which I (Thomas Beale) will facilitate.

Requirements

It is important to be clear about the principal requirement of the Javel exercise. It is as follows: to make the Eiffel language (understood as a semantic programming and tool framework) available to developers who normally work in C-like syntaxes of many of the mainstream languages of today. In other words, to remove the syntax barrier represented by the Algol-style syntax of Eiffel to developers who typically work in Java, C# and other similar languages.

It seems a reasonable assumption, given the existing variety of C-syntax languages that Javel will not need to be a slavish syntax copy of any particular one of these languages but rather an(other) 'acceptable' C-like language (see below for acceptability criteria).

Methodology

Our methodological approach here will be to capture ideas about the above concept from various people who have thought about it in the past and/or who have a proposal to make. Based on a set of criteria we develop, we will attempt to synthesise these into a coherent 'Javel' definition.

Criteria for any Eiffel language skin

There are some criteria that clearly apply to any language skin we might try to create. Suggestions so far for criteria that appear to be mandatory are as follows:

• full semantic equivalence - the full semantics of Eiffel is still available, simply under a different syntax. The underlying idea here is that the language skin works like a fully featured language, with the normal access to tools, libraries and software building capability. Further, it guarantees that there is a 100% bidirectional transform available between classic Eiffel syntax and each new language skin, for any given set of actual source texts.
• internal coherence of each language skin - the look & feel 'works' for developers.
• limited cost of implementation, i.e. parser complexity, compiler (re)design etc.

Other criteria which may apply:

• Minimality of changes - the difference between Eiffel and Javel is characterized by a few transformation rules, in this [style|http://bit.ly/IzAdCo]. [BM]
• The set of reserved words is the same in all versions. This is slightly less restrictive than "no new keywords" as originally stated. It makes it possible to add keywords, but they should become Eiffel keywords as well. Adding shortened keywords like `req' would only cause trouble. Obviously very few keywords if any will be added. [BM]
• developer access to the syntax mappings, e.g. by preferences dialogs and/or config files, enabling personalised language skin definition. [IJ]

Criteria for Javel, a C-like language skin

Following the assumption stated initially, and the 'coherence' criterion above, we assume that Javel will indeed be 'acceptable' to the typical C-based language user if it includes the following features, grouped into 'must-haves' and 'desirables'. The latter list might form the basis of personal switchable settings, or even more simply acceptable alternatives within Javel.

must-have features

• braces as block delimiters, i.e. {} - all C-languages have this, and it enables brace matching in editors, reduces visual keyword pollution etc;
• C-style type declarations, i.e. Type var, rather than var: Type as in Eiffel;
• C++/Java/UML style generic delimiters <> rather than [] as used in Eiffel;
• inherit keyword replaced by T1 : T2 as used in al C languages that support inheritance;
• comment delimiters /* */ and // supported in the way typical of C++, Java, C#;
• if/then/else style: if (expr) {} else if (expr) {} else {};
• (add more here)

desirable features

• Camel case;
• C-style 'for' loops. This arguably should be on the must-have list;
• (add more here)

Original Proposals

This section provides a place to list previous and/or individually separate proposals for C-like syntaxes for use with Eiffel.

• Bertrand Meyer / Manu Stapf [original discussion|http://bit.ly/IzAdCo];
• (other: please create a separate page on this wiki with a title like 'Javel proposal for Eiffel - Your Name', and link to it here)

Javel Synthesis

Syntax equivalence rules

TBD

Examples

TBD

Impact analysis for compilers / parsers

TBD