Difference between revisions of "Eiffel Language Skins"

Latest revision as of 08:29, 21 April 2012

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, in this case the name of a Parisian quartier and an industrial strength cleaning agent once manufactured there).

Discussion

For the purposes of discussion, we will initially work off the 'Discussion' tab associated with this page. Discussions and comments can be posted there. Contributors should 'watch' this page for updates, to stay in the loop. In the interests of avoiding chaos, I suggest we try to reach agreements on the discussion loop before radically changing this page. However, for obvious additions, please edit directly here. (We could alternatively use a Google group or similar, but I am interested in actually seeing if wiki-based discussion actually works - retains the notification aspect of email but separates the content onto a shared page. If others don't like this, we can convert later. TB)

Timeline

Reality check: This is not a theoretical exercise, but a concrete proposal for making actual language skin additions to EiffelStudio and other Eiffel development tools and environments. It must therefore be practical, limited in time and implementable. Accordingly, we define the following timeline and milestones (to be refined as time goes on):

• end May 2012
  • v1.0 'paper' synthesis of Javel,
  • initial impact analysis on EiffelStudio and any other tools whose builders would like to implement Javel
• end Sep 2012
  • description of user interface / interaction model for at least one tool
  • proof of concept implementation of the bidirectional transform (e.g. as a text file converter)

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. [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;
• (other: please create a separate page on this wiki with a title like 'Javel proposal for Eiffel - Your Name', and link to it here)

Parser / Compiler design approach

TBD: describe general approach to implementation. Do we support:

• user-switchable elements (e.g. CamelCase)?
• a set of fixed core elements?
• some sort of profiles that create particular language skins from a 'bag' of possibilities?

Javel Syntax Definition

Strategy

A few strategies appear possible here:

• try to define a complete Eiffel / C-style language mapping and then implement it
• define an absolute minimum set (maybe only 2 or 3 things) and find a way to implement that, in order to get an implementation cycle established, then iteratively add new mappings

Syntax equivalence rules

TBD

Examples

TBD

Impact analysis for compilers / parsers

TBD