Eiffel Language Skins - Revision history

Thomas.beale: /* Javel Synthesis */

2012-04-21T17:29:44Z

‎Javel Synthesis

Thomas.beale: /* Javel Synthesis */

2012-04-21T17:26:24Z

‎Javel Synthesis

Thomas.beale at 11:24, 19 April 2012

2012-04-19T11:24:18Z

Thomas.beale at 11:16, 19 April 2012

2012-04-19T11:16:22Z

Thomas.beale at 11:14, 19 April 2012

2012-04-19T11:14:38Z

Thomas.beale at 11:09, 19 April 2012

2012-04-19T11:09:56Z

Thomas.beale at 11:01, 19 April 2012

2012-04-19T11:01:53Z

Thomas.beale: New page: == 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 ...

2012-04-19T10:58:03Z

New page: == 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 ...

New page

== 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).

== 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

@@ Line 56: / Line 56: @@
 * (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 ==
+== Parser / Compiler design approach ==
 === Strategy ===
 A few strategies appear possible here:

@@ Line 5: / Line 5: @@
 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)
 == Requirements ==

@@ Line 3: / Line 3: @@
 === 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. (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)
+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.
 == Requirements ==

@@ Line 3: / Line 3: @@
 === 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.
+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. (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)
 == Requirements ==

@@ Line 57: / Line 57: @@
 == Javel Synthesis ==
 === Syntax equivalence rules ===
 TBD

@@ Line 1: / Line 1: @@
 == 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).
+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 [http://fr.wikipedia.org/wiki/Eau_de_Javel other things], in this case the name of a Parisian quartier and an industrial strength cleaning agent once manufactured there).
 === Discussion ===
@@ Line 20: / Line 20: @@
 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]
+* Minimality of changes - the difference between Eiffel and Javel is characterized by a few transformation rules, in this [http://bit.ly/IzAdCo 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]
@@ Line 43: / Line 43: @@
 == 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];
+* Bertrand Meyer / Manu Stapf [http://bit.ly/IzAdCo 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)