diff --git a/documentation/current/papers/eiffel-expression-language.wiki b/documentation/current/papers/eiffel-expression-language.wiki
index 6e3281eb..f8cf8bfe 100644
--- a/documentation/current/papers/eiffel-expression-language.wiki
+++ b/documentation/current/papers/eiffel-expression-language.wiki
@@ -3,5 +3,13 @@
 [[Property:uuid|61e93102-c558-42e7-7784-0b60b9257b5d]]
 A functional-programming style, or more generally a style involving more expressions and fewer instructions, is possible in Eiffel. In particular, the agent mechanism embeds a full functional-programming mechanism in the object-oriented framework of the language.
 
-To make the notations simpler, a number of extensions have been proposed. They involve no fundamental new language mechanisms, but provide new, more concise notations for existing mechanisms. Examples are 
+To make the notations simpler, a number of extensions have been proposed. They involve no fundamental new language mechanisms, but provide new, more concise notations for existing mechanisms. Examples are:
+*Conditional expressions
+*Implicit tuple, a rule allowing the omission of brackets for an actual argument when it is a tuple and the last argument, e.g. f (a, b, c) as an abbreviation for f ([a, b, c]) (an example involving just one argument). Tuples already provided the equivalent of a variable-argument ("varargs") facility, but it is made simpler to use with this convention.
+*Parenthesis alias, making it possible to write just f (x, y) when f is an agent (closure, lambda expression, delegate etc. in other terminologies), i.e. treating f as if it were a function; the notation is simply an abbreviation for f.item ([x, y]) (this example also takes advantage of implicit tuples). It has many other applications since a "parenthesis alias" can be defined for a feature of any class.
+*Avoiding explicit assignments to '''Result'''.
+*Type inference (to avoid explicitly specifying the type when it can be deduced from the context). This is a facility for the programmer, useful in particular for local variables, but does not affect the type system: Eiffel remains strongly typed, it is just that you can be lazy about writing the type when there is no ambiguity.
+*In the same vein, omitting the entire list of generic parameters when it can be inferred.
+
+The description of the mechanism (see the link below) is in the form of a set of slides explaining the concepts and presenting example. This is a working document and feedback is welcome.