On Aug 28, 2007, at 11:22 AM, Cédrick Béler wrote:

first, what solution to choose...

• proxyobject (Bert's idea + Ramon optimization)

I like this solution but maybe not as efficient, thread safe (what peaople mean by that?)

Excellent hack. Not definitive for me because having to meanings for one token is not really nice.

• scanner modification (I think Vassili's contribution...)

in this case, I like ';;' too...

+1 on Vassili's. Not sure about the token. Don't like a lot the ';;'

It's a bit confusing with ';'.

What about this ?

class Monad m where (>>=) :: m a -> (a -> m b) -> m b return :: a -> m a

monad >>= doThis >>= doThat >>= doMoreSTuff

...

= might be allright ? Big and easy to spot !

The analogy is that... the function binded to the monad does this .. opens up the monad, then does something and then returns another 'closed' monad. Guess what encapsulation is on objects.

We allready got that !!!!!!!!

Example:

obj myMethodA:x | myMethodB:x

A closed object receives a message. The 'myMethodA' method opens up the object as all instance variables are accessible in the method (Just like the monad) and and returns another closed object

which again ...

... receives a message. Now the 'myMethodB' method opens up the object as all instance variables are accessible in the method (Just like the monad). and returns another closed object etc ...

With closed I mean: private instance variables encapsulated.

Well the analogies end there but I think it's still effective. Also trying to lure some Haskell hackers :-). There are quite some Phd powered hackers there, and I personally think that Smalltalk could win their love.

hope I didn"t miss another way...

You miss this (not related): Is it alright to Small-talkers with grey hair to push more on functional programming, where functional programming is intended as chains of functional applications (better if pure) ? Because if the change happens you WILL see more chained applications at least as much you see the cascade. Is this alright with the more experienced guys out there ? and maybe, is this alright at all ?

I'm +1 in reading more functional applications chains.

Cédrick

Fabio Filasieno

Hi!

Just noting that noone seems to mention the obvious problem:

Compatibility with other Smalltalks

I sure argued for my prefix-separator-::-thingy back in the namespace discussions - but I judged that as a very small modification that could *possibly* be worth it. Although we get along kinda fine without it, so today I might hesitate :)

Or have we (since Traits) thrown away the need for compatibility with other Smalltalks (and older Squeaks)? This is not sarcasm - it would be a reasonable choice to make.

regards, Göran

Cédrick Béler wrote:

I like this solution but maybe not as efficient, thread safe (what peaople mean by that?)

Without making the implementation of the proxy-based Pipe object radically more complicated and less efficient than it already is, it would not be thread-safe to share the same Pipe object among multiple threads.