Author:bmeyer

Date:2014-01-28T17:15:30.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@1249 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
bmeyer
2014-01-28 17:15:30 +00:00
parent 6ee13fcfb0
commit 4fd910bd04

View File

@@ -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.