Something simpler?

[Neal Gafter]

Peter-

This isn't bad, but I think the colon is far too subtle.  It also
fails to naturally support a possible future extension of further type
inference, because

{name:statement}

could either be a lambda expression with one parameter whose type is
inferred, or a block containing a labeled statement.

Cheers,
Neal

On Tue, Mar 16, 2010 at 5:13 PM, Peter Levart <peter.levart at gmail.com> wrote:
> In light of recent Remi Forax's plea for simpler syntax, in light of of '#' and '.(' considered
> harmful, in light of Neal Gafter's blog about desirable orthogonality of language features:
>
> http://gafter.blogspot.com/2006/09/failure-of-imagination-in-language_17.html
>
> and above all in light of Lawrence Kesteloot's writing:
>
> http://www.teamten.com/lawrence/writings/the_language_squint_test.html
>
> which extends "orthogonality" to syntax as well, here's my 3rd attempt at a simpler syntax:
>
>
> FunctionType:
>    '[' ParameterTypes_opt ':' ResultType Throws_opt ']'
>
> ExpressionLambda:
>    '(' ParameterList_opt ':' Expression ')'
>
> StatementLambda:
>    '{' ParameterList_opt ':' Statements '}'
>
> FunctionInvocationExpression:
>    FunctionTypedExpression '[' ExpressionList_opt ']'
>
>
> examples:
>
>
> [:int] two = (:2);
>
> assert two[] == 2;
>
>
> [File:String throws IOException] readFile = {
>  File f:
>    Reader in = new FileReader(f);
>    try {
>      char[] buf = new char[8192];
>      StringBuilder sb = new StringBuilder();
>      int nread;
>      while ((nread = in.read(buf)) >= 0)
>        sb.append(buf, 0, nread);
>      return sb.toString();
>    }
>    finally {
>      try { in.close(); } catch (IOException e) { // ignore }
>    }
> };
>
> String text = readFile[new File("/etc/passwd")];
>
>
> [[A:R throws E], A : [:R throws E]] curry = ([A:R throws E] lambda, A arg : (:lambda[arg]));
>
> [[A:R throws E], A : [:R throws E]] curry2 = {
>  [A:R throws E] lambda, A arg :
>    return (:lambda[arg]);
> };
>
> [A:R throws E] lambda = {
>  A a:
>    if (a == null)
>      throw new E();
>    return new R(a);
> };
>
> [:R throws E] curried = curry[lambda, new A()];
>
> R r = curried[];
>
>
> discussion:
>
>
> I know, I know, '[]' are reserved for arrays. But so are '()'  - for expressions,
> method/constructor params and casts. The point is that '()' are very much abused in current 0.15
> lambda proposal for function types as well as lambdas (just look at expression lambda
> potentially containing 3 pairs of '()' in single construct). Lambda and function-typed heavy
> code is starting to look like Lisp - not very Java like. The point that Lawrance Kesteloot
> beautifully explains in his writing is that different things combined together should visually
> fall-apart - they should be easily decomposable into components.
>
> Since function type / array type combinations are deprecated anyway, this proposal steps right
> onto the syntax tokens that are traditionally reserved for arrays. It does not prevent
> combinations of function types and array types but it makes the less used combination more
> awkward-looking to benefit other more useful combinations (like casting to function types,
> specifying function-typed parameters in methods, chaining method and function calls).
>
> The syntax of expression lambda is similar to parenthesized expression. It just adds optional
> formal parameters and a mandatory delimiter immediately after opening '('. Likewise the syntax
> of statement lambda is similar to block statement. It just adds optional formal parameters and a
> mandatory delimiter immediately after opening '{':
>
> (12) vs. (:12)
>
> { System.out.println(); } vs . {: System.out.println(); }
>
>
> Regards, Peter
>
>