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/ |
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. > > - 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 |
On Aug 28, 2007, at 11:22 AM, Cédrick Béler wrote:
Excellent hack. Not definitive for me because having to meanings for one token is not really nice.
+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.
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.
Fabio Filasieno |
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 |
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. |
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 > |
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 |
Free forum by Nabble | Edit this page |