Stationary fields...
Ian Rogers
I was interested to read about noop and liked what I read. I wanted to
throw some of my own thoughts into the pot under fear of ridicule..
and I hope any of this doesn't come across as self promotion, just
interest in moving the state-of-the-art forward :-)
I think making fields immutable by default is great. In many
situations this isn't possible, why would the scope of mutability of a
field be related to the scope of a constructor (or before the
constructor in C++). I did a hack [1] with an annotation in Java
called @FinalWhen, that would assert that a field was final when it
hit a certain value and cause runtime exceptions if its value changed.
I used this mechanism to the specialize the Java class loader so that
when a java.lang.Class became fully resolved it was immutable. The
ultimate aim of this, and work on stationary fields, is that it
becomes far easier to reason about what parts of a system are
misbehaving when you can say a certain percentage of the objects can't
be changing. With final fields on existing code bases, something like
15% of fields may be classifiable as final. Stationary fields may get
this percentage up to 50%, but there is strong cause for hope that a
language like noop could push this figure way higher. Having a dynamic
immutability property I think is interesting and something equally
well achieve by a freeze method (as in Ruby, although I'd leave out
unfreeze).
I like making methods pure from a runtime optimization point-of-view.
Making methods pure also means at compile time you can verify its
accesses to mutable state. If purity were expressed in libraries then
presumably it would make it easier for user's code to be compile time
verified that it was pure, making it easier to reason where bugs may
be. How you express purity and whether it is the default, I think are
things open for debate.
Anyway, I'm sorry I didn't go to the JVM language summit (I'm based in
Mountain View working for Azul Systems - in the Google campus). If
people want to talk more then let me know.
Regards,
Ian Rogers
[1] http://doi.acm.org/10.1145/1411732.1411746
--
Metacircular VM effort - http://mrp.codehaus.org/
Alex Eagle
Ian Rogers
2009/9/25 Alex Eagle <alex...@google.com>:
> I'm not sure why you say in many situations it's not possible to have the
> immutable field set by the constructor. That's our approach right now. I
> very rarely need to use "setter injection" (the dependency injection term
> for providing a value after construction).
I need to read more about noop and play with the language, I've just
been reading the wiki for now. I guess the simplest example of what I
mean in Java would be lazy initialization of fields:
Object getX() {
if ( x == null ) {
x = makeX();
}
return x;
}
> I'll read the paper this weekend. I'm guessing it's still hard to reason
> about whether the field has been initialized or not?
So what I did was propose a constraint on a field that could be used
to reason that it was final. In the example above the constraint would
be that if the field x were non-null then it was final. There are
weaknesses to this approach, but I did use it for a case study and a
compiler optimization (value specialization). Rather than using a
constraint to express finality (or the more general term that it has
become stationary) you could have a method that would make the entire
object immutable, such as freeze in Ruby. My interest stemmed from
seeing what could be done to reduce the set of operations a
transactional memory system needed to consider. But as it is stated in
Java Concurrency in Practice, what makes concurrent programmable
difficult is shared mutable state. Other than stationary fields,
JavaRI provides a means to specify that objects passed to methods
shouldn't be mutated.
In a different situation we were thinking about functional and OO
languages, there was a project called UFO (unified functions and
objects). This has become something of a trend with languages like F#
and OCaml. But once mutability is out of the basket then the question
is how to give tools so the programmers don't keep losing their thumbs
to it.
> Thanks for being involved, we could certainly use help from some academic
> language experts!
s/expert/engineer/ :-)
Regards,
Ian
David Bernard
>
> Thanks for your follow up Alex.
>
> 2009/9/25 Alex Eagle <alex...@google.com>:
>> I'm not sure why you say in many situations it's not possible to have the
>> immutable field set by the constructor. That's our approach right now. I
>> very rarely need to use "setter injection" (the dependency injection term
>> for providing a value after construction).
>
> I need to read more about noop and play with the language, I've just
> been reading the wiki for now. I guess the simplest example of what I
> mean in Java would be lazy initialization of fields:
>
> Object getX() {
> if ( x == null ) {
> x = makeX();
> }
> return x;
> }
>
>
same as in Scala :
lazy val x = makeX();
As a scala user, there is a place where "lazy val" is not enought :
how to release/free x only if instantiated ?
It's very similar to the use of "lazy singleton service" in Spring or any DI ;)
>> I'll read the paper this weekend. I'm guessing it's still hard to reason
>> about whether the field has been initialized or not?
>
> So what I did was propose a constraint on a field that could be used
> to reason that it was final. In the example above the constraint would
> be that if the field x were non-null then it was final. There are
> weaknesses to this approach, but I did use it for a case study and a
> compiler optimization (value specialization). Rather than using a
> constraint to express finality (or the more general term that it has
> become stationary) you could have a method that would make the entire
> object immutable, such as freeze in Ruby. My interest stemmed from
> seeing what could be done to reduce the set of operations a
> transactional memory system needed to consider. But as it is stated in
> Java Concurrency in Practice, what makes concurrent programmable
> difficult is shared mutable state. Other than stationary fields,
> JavaRI provides a means to specify that objects passed to methods
> shouldn't be mutated.
>
> In a different situation we were thinking about functional and OO
> languages, there was a project called UFO (unified functions and
> objects). This has become something of a trend with languages like F#
> and OCaml. But once mutability is out of the basket then the question
> is how to give tools so the programmers don't keep losing their thumbs
> to it.
Same goal as Scala (Functional/OO)
/davidB
Ian Rogers
>
> On Sat, Sep 26, 2009 at 03:04, Ian Rogers <ian.r...@manchester.ac.uk> wrote:
>>
>> Thanks for your follow up Alex.
>>
>> 2009/9/25 Alex Eagle <alex...@google.com>:
>>> I'm not sure why you say in many situations it's not possible to have the
>>> immutable field set by the constructor. That's our approach right now. I
>>> very rarely need to use "setter injection" (the dependency injection term
>>> for providing a value after construction).
>>
>> I need to read more about noop and play with the language, I've just
>> been reading the wiki for now. I guess the simplest example of what I
>> mean in Java would be lazy initialization of fields:
>>
>> Object getX() {
>> if ( x == null ) {
>> x = makeX();
>> }
>> return x;
>> }
>>
>>
>
> same as in Scala :
> lazy val x = makeX();
>
> As a scala user, there is a place where "lazy val" is not enought :
> how to release/free x only if instantiated ?
> It's very similar to the use of "lazy singleton service" in Spring or any DI ;)
Agreed, although I won't pretend to be an expert, I also think
singletons are a special, common instance of this. Unfortunately lazy
doesn't capture all of the semantic meaning, for example could makeX
return null? I'm not saying constraints on final fields are a good
idea, they are an idea, from the compilers point of view they give
something that you can use to solve problems which its not clear to me
lazy provides. In the case of something that goes from uninitialized,
to resolving, to loaded (a Java class) could lazy be used to capture
this behaviour? What I'd like to see in a language is something that
can give me compile time (best imo) or runtime guarantees as to what
can be changing under my feet, the shared mutable state that is
supposed to be making concurrent programming difficult. I think extra
immutability and side effect free (purity) mark up are the way to go
about this, I'd then want to make it the default that these things
were on. I find the idea of runtime exceptions when immutability
guarantees break some what appealing, the compiler can then warn when
these exceptions are possible.
Regards,
Ian
Christian Edward Gruber
Safety" in Eiffel, and I think there are concepts there that are
nicely supported by stationary attributes (fields). I think this is
one to definitely play with.
cheers,
Christian.
t0rx
around concurrency, you want something to say at compile time that an
object (or a known portion of it) is totally immutable without (the
run-time) having to check that every time you want to access it.
Concurrency support within the language is something that needs to be
thought about seriously as the trend continues for many-core CPUs, so
the easier we make it for the compiler to optimise for this and for
the programmer to easily get those optimisations, the better in my
book.
Yan
On Sep 26, 10:59 pm, Ian Rogers <ian.rog...@manchester.ac.uk> wrote:
> 2009/9/26 David Bernard <david.bernard...@gmail.com>:
>
>
>
>
>
>
> > On Sat, Sep 26, 2009 at 03:04, Ian Rogers <ian.rog...@manchester.ac.uk> wrote:
>
> >> Thanks for your follow up Alex.
>
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
Christian Edward Gruber
concurrency. I think it'll probably include a few key elements:
1. First-class concurrency support in the stdlib, in the form of
clean locking and immutable collections, etc.
2. We were noodling about the idea of something similar to
GrandCentral where one doesn't create threads, but rather asks some
thing central to execute a worker. I'm not sure exactly how we want
to do this, but having centrally managed threading with configurable
and manageable pools where the end-developer doesn't ever directly
create a thread would probably be best. This way, the back-end
runtime could manage such things according to available resources.
christian.
t0rx
discussed for noop but they would help make the syntax cleaner than in
C/C++/Objective-C. JVM-based implementations of Noop might not be
able to take advantage of GCD in the OS in the short term, but
supporting these kinds of constructs either in the language itself or
in the stdlib sounds like a smart move.
On Oct 4, 5:37 pm, Christian Edward Gruber