Function types syntax

Zdenek Tronicek tronicek at fit.cvut.cz
Tue Jan 26 05:52:55 PST 2010


Peter Levart napsal(a):
> On Tuesday 26 January 2010 11:15:48 Zdenek Tronicek wrote:
>> I think that more important than different syntax are parens in your
syntax:
>> #(#int(String)(throws IOException)) (String)(throws SQLException) vs.
>> #String: #String: int throws IOException throws SQLException
> 1. '(' Type ')' in current Java syntax can not be interpreted as Type
(it's a cast), so optionally enclosing a Type in parens to visibly
disambiguate is not valid syntax (currently). Even if it was, yet
another
> pair of parens (10 totally for above example vs. 4 for my proposed
syntax)
> is not a big plus.
> 2. If a syntax specifies a mandatory character, it can not be taken
away,
> so removing parens from my proposed syntax is not a fair way to compare
it's readability to another syntax - it's not the same syntax.
> But yes, I agree that parens placement is crucial for readability. If
the
> whole construct is effectively "enclosed" between '#(' and ')' then
nesting is explicitly visible.

I only try to show that better readability of your proposed syntax does
not come from the changed order of return type and argument types, but is
a consequence of parens added. And this is, hopefully, something, we
agreed on.

As for the following syntax:

> #(String: int) stringLength = #(String s: int length) label:{
>   if (s == null) { length =-1; break label; }
>   length = s.length();
> };

I do not understand where your enthusiasm comes from. I do not claim it
cannot be used nor it is incorrect in some sense, but:

1) it uses a principle which is not common in Java (return value is in a
variable),
2) it uses the break statement in a novel way,
3) it is not transparent (a consequence of 1) and 2)).

Z.
-- 
Zdenek Tronicek
FIT CTU in Prague





More information about the lambda-dev mailing list