Preparing for the 0.2 draft

[Joshua Bloch]

John,

On Tue, Feb 2, 2010 at 5:53 PM, John Rose <John.Rose at sun.com> wrote:

> On Feb 2, 2010, at 5:42 PM, Joshua Bloch wrote:
>
> > I think it was with good reason that
> > Alex made the parens mandatory.
>
> Thanks; my bad.  I wasn't trying to subvert that part of the spec.
>
> > I believe it was a mistake to require (Integer)(128) to create a
> > new instance, and I don't think we should make that mistake twice.
>
> It doesn't!  The spec. requires caching in the range [-128,127], but does
> not disallow caching elsewhere.  That's the practical basis for proposing
> fixnums as a future JVM optimization.  (Or maybe I'm missing your point?)
>

No, my bad.  You're right, but still this piece of the spec sucks.  It
shouldn't have made any caching mandatory.  Any code that depends on the
caching of  [-128,127] is evil.  The spec should simply have said that it up
to the implementation to decide what to cache.

>
> > I'd like it if the syntax for creating an instance
> > of a Sam type was just as nice as for creating an instance of an ordinary
> > function type.
>
> The good old syntax dial has many gradations.  The dial setting I picked
> made sam instantiation "almost as nice but not quite, yet strangely
> familiar" (compared to a simple lambda) to take explicit control over
> constructor invocation and instance identity.
>
> The most implicit option (assignment conversion) has lots of corner cases
> with need sorting out.  That option should (as I think we agree) allow
> (though not require) implementations to hoist and/or cache, just as with
> Integer.


Agreed on both counts.  But my hope is that we'll figure out a way to do
this while retaining the same semantics for SAM types as functions. I
haven't figured out the details (or even the rough outlines).

            Josh