Java 7 to get Closures!

General Discussions
#101

That was my point.

[quote]Usually people define * and / between vectors and numbers, but not between vectors themselves, when operator overloading.
[/quote]
Hmm. Definitely useful, but trickier to do in a generalisable way.
[/quote]
Matrices get * defined, but oftentimes not /, because the operation of inverting a matrix can fail sometimes and it’s usually best not to hide that by making it look like regular old division.
[/quote]
Division can fail in a field, although floating point in Java hides it by using infinities and NaNs. If integer division can get away with throwing ArithmeticException I don’t see why overloaded division couldn’t throw a SingularMatrixException.

[quote]Personally, I’d love to see Java get some built in primitives (preferably stack-allocated and immutable) for vectors, matrices, and complex numbers, with these overloadings baked in; if that happened, I wouldn’t care about operator overloading one bit, though I’d also like the big/arb. precision number classes to get the same treatment. I can’t come up with many other compelling or common use cases for operator overloading that make sense, but those ones cause a lot of pain if you work in areas that require them…
[/quote]
I’m trying to think about how it could be done while still being and feeling like Java and with a bit more flexibility for people who want to play around with surreal numbers, octonions, or an arbitrary field. (I’m assuming that quaternions would be added to your list of basics).

#102

[quote][quote]Quote from: DzzD on November 26, 2009, 07:23:48 pm
but the problem it introduce maybe is that type will be then checked at runtime and no more at compil time
[/quote]
The ahead-of-time compiler may not remove type assignment checks anyway
[/quote]
yes sure but it is better/easier to see it at compil time rather than later when running the programm

[quote]I agree, the now (not future) is parallel programming, but then why not think of a way to actually add it into the java realm instead of creating some kind of cyborg implant and hope the body does not reject it.
[/quote]
+1

a longer think about how to improve parallele programing in java (maybe with the help of an external library) rather then trying to add fastly every stuff that java dont have may be nice.

“Java have real lack in parralele programming ? yes ? no ? if yes let’s found a solution !” would be better than “Java have closure ? no, let’s add it ! … but what for ? hum… he… just to do like other languages, no ?”

what does closure will help us for ? any clear example ?

#103

http://gee.cs.oswego.edu/dl/jsr166/dist/extra166ydocs/

You see all those Opps in the right side there?
::slight_smile:

#104

Really as a java programmer, i’m surprised that you’re not sick to death of having to create Runnable inner classes.
(and no exposing the interface in the main class is not a solution).

#105

@i30817:
It is part of the language. Don’t like it? Find another language.
Ask a C developer if they like doing malloc.

You know, I get tired of remembering all the names of people so I will just call them Bob from now on.
Plus punctuation and grammatical tenses are also annoying so I’ll just leave those out as well.

Seriously, it is the spec and thats the way it is.
Changing the spec because I am to lazy to write stuff is the surest path to doom.

#106

What’s wrong with wanting to improve your tools?

Of course, one reason for using java is to code for the JVM which is very fast and quite cross platform. If that’s your major goal, one might look into alternative languages, like Scala.

#107

Programmers are lazy. Programming improves because they put a lot of work into facilitating this laziness.

#108

Yup, creating runnable inner classes is a pain. But what I want is readable syntax for making this easier, rather than co-opting random ascii symbols, or introducing annotations to work around quirks. Prize for the first person to come up with a shorthand syntax that looks and reads nicely.

And I really really would like type inference :slight_smile: I can’t think of any way to abuse it unless someone could enlighten me.

Cas :slight_smile:

#109

I love malloc. So much so, I write multiple flavors for different purposes.

Seriously, faking a good implemenation of closures is very difficult in Java. You would have to write something like what kilim does for continuations. You really want your enclosed expression to evalulate in a lightweight thread and have to access to its enclosing method’s local variables. However, were I to guess: the latest JDK7 milestone includes a new fork/join framework…the first pass is likely to be sugar on top of this. I just went back and reviewed Mark Reinhold’s blog entry, no local variable access…BOO!

Ah, but it’s like operator overloading. It might confuse people…we can’t have that.

As an aside: When does sugar become “evil”? Taken to the extreme, the only viable language is LISP (well, before they added ’ et al, of course!)

#110

I’m not worried about abusing it: I’m worried that it will make unintentional bugs harder to spot. There are some places where type inference could be improved (particularly looking at places where I still have to do Collections.emptySet() and at constructs like Foo<A, B> = new Foo<A, B>() which have no ?s), but making all casts implicit strikes me as a bad idea for maintainability of code. It’s like auto-unboxing, which is simple in concept but caused me much bewilderment the first few times I got a stack trace showing NPE and the corresponding line in my IDE was “a=b;” or “if §”.

#111

This is suppose to be part of the last milestone.

#112

Yep, that’s one of Project Coin’s offerings. So if they can do it there… why can’t we have it elsewhere :slight_smile: C’mon, let’s see an example where it could be confusing or have unintended results.

Cas :slight_smile:

#113

Your example from the previous page, expanded for clarity:

Object foo = foo();
// Insert various
// other lines
// here so that foo's
// type isn't
// obvious.
String bar = foo;

If it’s inside an instanceof check then, as I said earlier, that would be fine, but as is that’s an invitation to bugs. Explicit casts have the benefit of documenting that you know you’re doing something unsafe.

#114

Why’s a cast unsafe suddenly? By saying String bar = foo; I assert that foo is a String. Why do I need to type (String) to say that?

Cas :slight_smile:

#115

For argument sake, what should the front-end compiler do when a statically known invalid cast occurs? Or is your suggestion that if the cast is statically known to be correct, then it’s optional?

WRT: Being able to drop the cast inside of an instanceof. The trick here is your grammar becomes context dependent. I’m okay with that, but some folks aren’t.

#116

Because you previously asserted that you didn’t know it was a String and you haven’t given any reason for changing your mind.

#117

I don’t want to give a reason - that’s the work of machines to figure it out. If it’s impossible I’d like to be told, but as long as it’s legal to cast, I don’t see why I should have to go to the effort and clutter of stating it - it’s totally superfluous to the meaning of the code. String s = foo; means I think foo is a String and assign it to s; so does String s = (String) foo; - but one is shorter and clearer.

Cas :slight_smile:

#118

I don’t care what the compiler can figure out: I care what the maintainer can figure out.

#119

The less code there is for the maintainer to figure out the less chance he or she has of getting it wrong.

Cas :slight_smile:

#120

some more questions and answers on mark reinholds blog regarding closures in java 7

http://blogs.sun.com/mr/entry/closures_qa

and its really ‘MEH’ that Java 7 is being delay to September 2010.