pipe

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

pipe

Jerome Peace
Hi all,

Well, now that the issue has gotten a well and noisy
airing on the mailing list. Who wants to start the
mantis issue so the good work here can get harvested?

Yours in curiosity and service, --Jerome Peace

P.S. I'm +1 on the ';;' syntax.


       
____________________________________________________________________________________
Choose the right car based on your needs.  Check out Yahoo! Autos new Car Finder tool.
http://autos.yahoo.com/carfinder/

Reply | Threaded
Open this post in threaded view
|

pipe harvesting

cbeler
Jerome Peace a écrit :

> Hi all,
>
> Well, now that the issue has gotten a well and noisy
> airing on the mailing list. Who wants to start the
> mantis issue so the good work here can get harvested?
>
> Yours in curiosity and service, --Jerome Peace
>
> P.S. I'm +1 on the ';;' syntax.
>
>  
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?)

- scanner modification (I think Vassili's contribution...)
in this case, I like ';;' too...

hope I didn"t miss another way...

Cédrick



Reply | Threaded
Open this post in threaded view
|

Re: pipe harvesting

Fabio Filasieno

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







Reply | Threaded
Open this post in threaded view
|

Re: pipe harvesting

Göran Krampe
In reply to this post by cbeler
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


Reply | Threaded
Open this post in threaded view
|

Re: pipe harvesting

Alan L. Lovejoy
In reply to this post by cbeler
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.

Reply | Threaded
Open this post in threaded view
|

RE: pipe harvesting

Ron Teitelbaum
In reply to this post by Göran Krampe
This is a good question.  What is the process of managing compatibility
between Smalltalk implementations?    How much compatibility is there today?
(GUI frameworks excluded) Do we just assume that good changes will get
adopted or should we actively try to stay in sync?

Ron Teitelbaum

> -----Original Message-----
> From: Göran Krampe

> 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
>



Reply | Threaded
Open this post in threaded view
|

Re: pipe harvesting

Jason Johnson-5
In reply to this post by Fabio Filasieno
On 8/28/07, Fabio Filasieno <[hidden email]> wrote:
>
> There are quite some Phd powered hackers there, and I personally think that
> Smalltalk could win their love.

I seriously doubt it.  Haskell programming is as much about
programming to the typing system as it is functional programming [1]
(possibly more).  So switching to a dynamically typed system is highly
unlikely.  It's pretty unlikely that many of them would even accept
such a system as viable at all.

Functional programmers typically think they don't need OO as well [2].

So if you truly believe that changing expressions that look like:

(((someObject message: 1) message: 2) message: 3)

to:

someObject message: 1 >>= message: 2 >>= message: 3

is going to overcome all those issues, and bring in all those
PhD's.... well, it calls in your previous claim that your arguments
are logical, etc. :)

[1] http://cgi.cse.unsw.edu.au/~dons/blog/2007/05/17#xmonad_part1b_zipper
[1] http://www.paulgraham.com/noop.html