On Sat, 24 Sep 2011 06:42:52 +0200, Andrei Alexandrescu
<[email protected]> wrote:
On 9/23/11 8:03 PM, Martin Nowak wrote:
On Thu, 22 Sep 2011 22:54:55 +0200, Andrei Alexandrescu
<[email protected]> wrote:
I want to add some points against introducing this particular syntax.
1. Foremost using '=>' is unfamiliar. Comming from C++ or Java you
really have to learn reading it.
If you weighted the lambda syntaxes with the tiobe factor, arrows would
be a minority.
Well the C++2011 lambda syntax is quite foreign for C++ users, too.
How often have you stopped reading about a language because the code
examples were unreadable?
Besides my liking for haskell, I don't want to see anything close to
this on the D site.
mergesortBy less [] = []
mergesortBy less xs = head $ until (null.tail) pairs [[x] | x <- xs]
where
pairs (x:y:t) = merge x y : pairs t
pairs xs = xs
merge (x:xs) (y:ys) | less y x = y : merge (x:xs) ys
| otherwise = x : merge xs (y:ys)
merge xs ys = xs ++ ys
I don't understand the point being made here.
2. D is not a functional language, using the implies arrow in 'a =>
write(1, a.ptr, a.length)' creates a horribly association.
Hackeyed as that sounds, D is a multi-paradigm language and includes a
lot of functional artifacts.
3. I don't see any of the proposed rewrites is working for nullary
delegates.
'=> foo()' ???
Or '_ => foo()' => 'Error can't deduce parameter'.
The comma-separated list may be empty.
4. The expression is badly delimited.
The first rewrite symbol => expression
is actually symbol => expression\{CommaExpression, CatExpression}.
E.g.:
dgs ~= (int a) => (a + 5) ~ (int a) => (a ^^ 2);
foo(a, b => (log(b), b), c)
And that with a pending tuple syntax reclaming even more parens, comma
overloads.
Not sure I understand this point either, sorry.
=> looks like an infix operator. It harder to distinguish in a parameter
list.
The trailing right curly OTOH always ends a function.
It makes it visually distinct and is highlighted/matchable in an ide.
It prevents interaction of operators with the inner expression.
sort!((a, b) => a <= b)(input)
vs.
sort!((a, b) { a <= b })(input)
static assert ((a, b) => a < b != (a, b) => a > b)
vs.
static assert ((a, b) {a < b} != (a, b) {a > b})
Another minor issue:
a =>
a + 3
Offers worse indentation for long expressions than
(a) {
a + 3
}
So D is a curly bracket language.
http://en.wikipedia.org/wiki/List_of_programming_languages_by_category#Curly-bracket_languages
What is wrong the, I think earlier proposed, very simple solution.
http://www.digitalmars.com/d/2.0/expression.html#FunctionLiteral
FunctionLiteral:
function Typeopt ParameterAttributes opt FunctionLiteralBody
delegate Typeopt ParameterAttributes opt FunctionLiteralBody
ParameterAttributes FunctionLiteralBody
FunctionLiteralBody
ParameterAttributes:
Parameters
Parameters FunctionAttributes
FunctionLiteralBody:
FunctionBody
'{' Expression '}'
(a, b) {a+b} // takes the same amount of characters
We've been discussing the issues of this form.
Andrei
I've only found one argument being made for this.
2. What if the lambda wants to actually evaluate the expression but
return void?
3. How is the semicolon relevant? (If its presence is used as a
disambiguator for (2), it's poor design to predicate a large semantic
difference on such a distinction.)
It will error when you want to use the return value of the delegate.
It will error when the expression has no side-effect.
It allows to easily create a void return delegate.
We already have implicit return for our second lambda syntax q{a+b}.
Having both (a, b) { foo(a, b); } and (a, b) => foo(a, b) for such similar
constructs is no good design either.
C#, Scala and apparently Java8 all allow curly embraced statement blocks
after the fat arrow.
Scala has an implicit return for this '() => { count += 1; count }'.
Will we allow statements () => { return 5; }?
We won't remove the existing function literal syntax due to code breakage.
We won't remove the string predicates because they are still shorter.
I am worried about having three subtly different language constructs for
the same concept.
(a, b) { return a < b; } | q{a < b} | (a, b) => a < b
| old delegate syntax | string predicates | fat arrow delegates
|--------------------------------------------------------------
scope | declaration | instantiation | declaration
return | explicit | implicit | implicit
body | statements | expression | expression
types | optional | no | optional
martin
