Stephane Ducasse <ducasse at iam.unibe.ch> wrote:
> If you want by any chance that the blockclosure gets accepted in the 
> Squeak kernel as I would like. PLEASE do not mix research ideas with
> that. Fix all the problems you know or others know (decompiler....) first

Sorry for the confusion, I didn't mean the current VI4 would be changed,
I just meant subjectivity could be added on top of VI4, call it VI5.
Also, I do plan on fixing the rest of the decompiler.

> Still I think that all these subject-oriented programming papers that
> were at OOPSLA few years ago before AOP were cool but I would not
> like to program with that because it was complex.

You should read the Us paper.  Its at the site I gave, just click on PDF
in the upper right corner
(http://citeseer.nj.nec.com/smith96simple.html).  I agree AOP is
complex, but layers is implemented as just another lookup dimension. 
And from the programmer's/user's point of view it is just projects.  You
work in one project then maybe switch to another, any if there is
anything in common you want to share between the projects put
them in an inherited project.  The concept is the same as behavior
inheritance, but this is at a larger scale, call it image inheritance.

> > I really think layers will improve our package model in the
> > image, particularly with respect to dependencies, versions, and
> > unloading capabilities.
> 
> I think that we do not need that for that. Basic software engineering 
> principle and namespaces are enough for that. May be Layers could
> solve that but may be they are introducing another layer of complexity
> just at the cognitive level.

Layers (environments as I have described them on my website) are
dynamically bound namespaces and nothing more.  This allows you
to override them to change the behavior in different layers.  Thus
giving you multiple packages/projects that can be run and analyzed in
the same image.  Being able to work on different packages/projects in
the same image is important, and without something like layers it can't
be achieved.

> but may be they are introducing another layer of complexity just at the
> cognitive level. 
> (This what was worrying me the most with traits, the model is simple still
> you have one extra concept)

That's what also bothers me about traits.  I wish you would just use
straight multiple inheritance and eliminate the extra concept of traits
when there really isn't an extra concept.  Layers is different.  Its an
extra concept that adds another dimension of functionality, which is
needed in a multi view/version world.

> Sorry to be a little rude but I really appreciate your effort to add 
> block-closure to squeak don't mess it up. But still have fun so build
> your stuff on a separate VM.

Your not rude, and I hope you don't think I'm rude.  I really think
these discussions are valuable for advancing our understanding and
knowledge.  And don't worry, I put so much time into VI4, I am very keen
on getting it into the base image.  I'm just waiting for Ian to look at
it so we can decide how to merge it with a Jitter.

"Stephen Pair" <spair at acm.org> wrote:
> But even the stack optimizations that are in VI4
> concern me a bit.  It seems like that goes too far into the research
> realm and jeopardizes the acceptance of the work done on block closures.
> Everyone knows what block closures are and why they are needed; there is
> a much greater chance of them getting into the base VM if they don't
> come with extra stuff that's less well understood and proven.

The stack issue will be worked out when considering a Jitter.  But if we
keep on resisting changes because they are not proven, we'll never make
progress.  Squeak is primarily a research project.  We don't have any
customers funding or donating to us.  So lets take advantage of this
freedom and really advance Squeak.

Cheers,
Anthony