Closures, too much or too little?

[Reinier Zwitserloot]

That was not the right response. The right response was: That looks
ridiculous. But, I see I screwed up; that wasn't the right snippet. This is
closer to the mark:

@For(init=@Declare(type=@Primitive(type=INTEGER), name="x",
value=@IntConstant(10)),
    cond=@Lesser(left=@Local("x"), right=@Constant(20)),
    incr=@Increment(ref=@Local("x")),
    block=[
        @Call(ref=@Deref(ref=@Global("System"), id="out"), name="println",
values=[
            @StringConstant("Hello, world!")
        ])
])

vs:

for (int x = 10; x < 20; x++) System.out.println("Hello, world!");

No keywords, no symbols. Just meta-symbols. Symbols included as things that
need to be eliminated, because symbols and keywords really do the same thing
too, and according to your own logic, that means java is a badly designed
language and we should endeavour to make one of the two go away.

--Reinier Zwitserloot

NB: Shouldn't we be holding this discussion in closures-dev?


On Mon, Nov 23, 2009 at 4:03 PM, <tronicek at fit.cvut.cz> wrote:

>
> > @For
> >     @ForInit int x = 10;
> >     @ForCond x < 20;
> >     @ForIncr x++;
> > @ForBlock {
> > }
>
> This approach would have been ok, if Java was designed with annotations
> instead of keywords. But it was not. And so it is, in my opinion, against
> the spirit of the language.
>
> Z.
> --
> Zdenek Tronicek
> FIT CTU in Prague
> http://kenai.com/projects/refactoringng - refactoring tool for compiler
> guys
>
>
> Reinier Zwitserloot napsal(a):
> > Aside from your other arguments, why would a language have 2 separate
> > constructs for what boils down to doing mostly the same thing?
> >
> > Convenience of course. Annotations are parameterized, pluggable, and have
> > their own namespace, and even need to be imported. Keywords have none of
> > those things, but they are independent of libraries, appear in entirely
> > different places, and are easier to type. Unless you find:
> >
> > @For
> >     @ForInit int x = 10;
> >     @ForCond x < 20;
> >     @ForIncr x++;
> > @ForBlock {
> > }
> >
> > easier to read than for (int x = 10; x < 20; x++) {}, of course.
> >
> > --Reinier Zwitserloot
> >
> >
> >
> > On Mon, Nov 23, 2009 at 1:51 PM, <tronicek at fit.cvut.cz> wrote:
> >
> >> Hi Howard,
> >>
> >> I do not understand your arguments. Warning means "be cautious, there
> >> may
> >> be an error" and error means "there is an error".
> >> The @Shared annotation says "be cautious, the variable will be shared
> >> between threads". This warning makes sense because we (programmers) are
> >> not used to sharing the local variables.
> >> However, it does not mean anything on the bytecode level. That is, the
> >> program is compiled the same way regardless of the annotation. So what
> >> error you want to report?
> >>
> >> > I also find the advise that annotations don't change program behavior
> >> > a little silly. Half the time your program won't even run without the
> >> > correct annotations in many frameworks!
> >>
> >> There is a difference between the Java language and Java frameworks. If
> >> you let the annotations change the semantics of the Java language, what
> >> would be the difference between annotations and keywords? None, except
> >> the
> >> way how they are written. And does it make sense to have two language
> >> categories for the same?
> >> It may seem that annotations can help in adding new features. To some
> >> extent, it is true. But it violates the language consistency.
> >>
> >> Zdenek
> >> --
> >> Zdenek Tronicek
> >> FIT CTU in Prague
> >> http://kenai.com/projects/refactoringng - refactoring tool for compiler
> >> guys
> >>
> >>
> >> Howard Lovatt napsal(a):
> >> > Sure for BGGA it suppresses a warning, but there would be nothing to
> >> stop
> >> > inner classes been changed to the same mechanism (I think CISE
> >> proposed
> >> > something similar). For a library as opposed to a language feature you
> >> > could
> >> > change the @Shared to provide automatic wrapping in a holder. This is
> >> not
> >> > quite the same, in that you would get an error as opposed to a warning
> >> if
> >> > @Shared was absent.
> >> >
> >> > However, I prefer the error since I am not a fan of warning messages
> >> and
> >> > thought Java was better before warnings and I am therefore not fazed
> >> by
> >> > this. I also find the advise that annotations don't change program
> >> > behavior
> >> > a little silly. Half the time your program won't even run without the
> >> > correct annotations in many frameworks!
> >> >
> >> >  -- Howard.
> >> >
> >> > 2009/11/22 Neal Gafter <neal at gafter.com>
> >> >
> >> >> On Sun, Nov 22, 2009 at 12:20 PM, Howard Lovatt
> >> >> <howard.lovatt at iee.org>wrote:
> >> >>
> >> >>> I agree with your point that it really only captures finals (which
> >> as
> >> >>> you
> >> >>> say are simple values of an expression in the LamdaJ 'closure'), but
> >> to
> >> >>> me
> >> >>> this is a secondary issue. A @Shared annotation could be introduced
> >> >>> that
> >> >>> works with inner classes and with LamdaJ closures.
> >> >>>
> >> >>
> >> >> @Shared in BGGA just suppresses a warning; it has no effect on the
> >> >> semantics of the code.  I have no idea what specification for an
> >> >> annotation
> >> >> you have in mind that could affect the way lambdaj works.
> >> >>
> >> >>
> ______________________________________________________________________
> >> >> This email has been scanned by the MessageLabs Email Security System.
> >> >> For more information please visit http://www.messagelabs.com/email
> >> >>
> ______________________________________________________________________
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> >  -- Howard.
> >> >
> >> >
> >> >
> >> > --
> >> >  -- Howard.
> >> >
> >> >
> >>
> >>
> >>
> >
>
>