Something simpler?

[Reinier Zwitserloot]

First syntax proposal that is very different from the strawman that looks
workable and pretty.

In my experience, the vast majority of code is written and rendered in
monospace fonts. In such a font a colon is unlikely to be subtle.

Neal's block ambiguity comment is neither here nor there; just stripping
types out of source snippets turns loads of java code ambiguous. In case
you're worried, Neal, inference would most likely involve a symbol or
keyword. Scala seems to be doing pretty well with 'val' and 'var' at least
for local variable declarations.



--Reinier Zwitserloot



On Wed, Mar 17, 2010 at 1:13 AM, 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
>
>