Closures, too much or too little?

Reinier Zwitserloot reinier at zwitserloot.com
Mon Nov 23 09:34:26 PST 2009


I just explained at length why stating that 'annotations and keywords SHOULD
do different things' cannot be applied to just the things you want. They are
different in keywords being global and non-parameterized, and annotations
being things you import, which can have parameters.

In that they are different. That's as far as the difference needs to go. Any
further semantic arguments that they should be MORE different somehow, are
not valid unless you explain why this would be a good or bad thing. Hint:
"because they should be different" is not a good argument. Strawman
comparisons aren't a good argument. Stop making them.


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

> Not at all. Both, keywords and annotations, are useful in Java. But for
> different purposes. Keywords define what the program should do (the
> semantics) and annotations add some extra information which serve, for
> example, for static analysis.
>
> What would you think about the language where the while loop is written by
> the "while" keyword and the for loop is expressed by the annotation?
> Although I do not have any strong argument against such approach, it is
> very unnatural and illogical for me.
>
> Z.
> --
> Zdenek Tronicek
> FIT CTU in Prague
> http://kenai.com/projects/refactoringng - refactoring tool for compiler
> guys
>
>
> Reinier Zwitserloot napsal(a):
> > 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.
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >
> >>
> >>
> >
>
>



More information about the coin-dev mailing list