Something simpler?

[Joshua Bloch]

I don't want to be the party pooper here, but this doesn't look at all like
Java. I'm afraid it violates the cardinal rule of language
extension:  primum nil nocere.

   Josh

On Tue, Mar 16, 2010 at 4: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
>
>