June 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Pipe operator

by Denis Kudriashov

XStream I think is exactly about it 2014-06-08 22:46 GMT+04:00 Camille Teruel <camille.teruel(a)gmail.com>: > > On 8 juin 2014, at 19:20, Garth Holland <steve9571952(a)hotmail.com> wrote: > > > The pipe operator appears in many languages (F#, Haskell, Elixir, Clojure > > (threading macro)). It's an elegant way of chaining method/function > calls in > > the presence of additional parameters. The reddit example could be > written > > using a pipe operator |> > > > > #('apple' 'peach' 'banana') > > |> groupedBy: #size > > |> select: [:each | each size even] > > |> values > > |> collect: #asCommaString. > > The pipe operator is implemented as one of the examples of LanguageBox, a > tool that permits to scope language extensions (it's a part of Helvetia > made by Lucas Renggli). > > I once thought that the pipe operator could be useful. But now I notice > that the main (if not the only) recurrent use case I found is chaining > queries on collections. > If you have another recurrent use case (that is not purely idiomatic :) ) > please let me know. > > So yes, using the pipe operator make the snippet more readable but still > has much inefficient: at each step a new collection is created just to be > trashed afterward. > Here it's not a problem but not all collections only have 3 elements ;). > > For me it's a sign that the collection libraries lack a simple > abstraction: composable filters (that is, iterators) to make complex > queries. > We could have collections answering #query that would responds a > QueryBuilder object that would understand common enumeration methods, for > example: > > #('apple' 'peach' 'banana') query > groupedBy: #size; > select: [:each | each size even]; > values; > collect: #asCommaString. > > This would return a CollectFilter on a ValuesFilter on a SelectFilter on a > GroupedByFilter on the input collection. > The QueryBuilder could then answer a message like #endQuery to compute and > return the values obtained by the lastly created filter (embedded in a > collection that conforms to the input collection's #species). > Since it's just a composition of filter objects over the input collection, > no useless intermediate collection is created: better performances & less > stress on the GC. > > Of course this idea is acceptable only if they are no other use cases > where the pipe operator is a must. > > > > > /Garth > > > > > > > > > > -- > > View this message in context: > http://forum.world.st/Pipe-operator-tp4762106p4762182.html > > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > > > >

June 8, 2014

Re: [Pharo-dev] Bench comparing Pahro 1.4 and 3.0.

by ClÃ©ment Bera

Some collection protocols were optimized so your result makes sense. The current performance bottleneck for your application definitely comes from the use of isKindOf: based on your profiles. inheritsFrom: is called by isKindOf: I guess. Now be very careful the current GC has very strange side effect. Did you perform manually a full GC before each bench ? 2014-06-08 20:18 GMT+02:00 Hilaire Fernandes <hilaire.fernandes(a)gmail.com>: > I have run a Sketch script on DRGeo on Pharo 1.4 and 3.0 > The script involved a lot of collection operations and object comparison. > > > The leaves results are strange, because the script is the same: > > > On Pharo 1.4: > > **Leaves** > 14.2% {97ms} Array class(Behavior)>>inheritsFrom: > 11.4% {77ms} OrderedCollection(SequenceableCollection)>>hasEqualElements: > 9.7% {66ms} DrGPointIntersectionItem>>= > 9.6% {65ms} DrGPointIntersectionItem(DrGMathItem)>>parentsEqual: > 5.0% {34ms} OrderedCollection>>at: > 5.0% {34ms} Array(SequenceableCollection)>>first > 4.7% {32ms} DrGPointFreeItem(DrGMathItem)>>= > 3.5% {24ms} OrderedCollection(SequenceableCollection)>>= > 2.7% {18ms} Array(Object)>>isKindOf: > 2.4% {16ms} OrderedCollection>>do: > 2.4% {16ms} OrderedCollection>>size > 1.8% {12ms} > OrderedCollection(SequenceableCollection)>>indexOf:startingAt:ifAbsent: > 1.2% {8ms} OrderedCollection>>ensureBoundsFrom:to: > 1.2% {8ms} SmallInteger(Number)>>negative > > > > On Pharo3: > > **Leaves** > 15.8% {168ms} Array class(Behavior)>>inheritsFrom: > 11.4% {121ms} DrGCircle2ptsItem(DrGMathItem)>>= > 8.3% {88ms} OrderedCollection>>size > 8.3% {88ms} DrGCircle2ptsItem(DrGMathItem)>>parentsEqual: > 7.5% {80ms} OrderedCollection>>at: > 7.1% {76ms} OrderedCollection(SequenceableCollection)>>= > 6.6% {70ms} Array(SequenceableCollection)>>first > 6.0% {63ms} DrGPointIntersectionItem>>= > 5.6% {59ms} OrderedCollection(SequenceableCollection)>>hasEqualElements: > 1.9% {20ms} OrderedCollection>>do: > 1.9% {20ms} OrderedCollection>>ensureBoundsFrom:to: > 1.7% {18ms} OrderedCollection(Object)>>isKindOf: > 1.5% {16ms} > OrderedCollection(SequenceableCollection)>>indexOf:startingAt:ifAbsent: > 1.5% {16ms} SmallInteger(Number)>>negative > > > > > True in between DrGeo changes a bit but normally not in the part involved: > > > -- > Dr. Geo http://drgeo.eu > iStoa - https://launchpad.net/istoa > > >

June 8, 2014

Re: [Pharo-dev] Pipe operator

by stepharo

> > Norbert > > > I'm curious too :) > I recently proposed to enable caret as a binary selector, maybe > there's been a confusion... :) Yes my brain is overloaded in this moment. I'm doing far too many things at the same time. Not good. > I remember a discussion about using ;; as pipe "operator" (it's more > syntax sugar than operator), in august 2007 or so. > But it was not me. > > http://bugs.squeak.org/view.php?id=6649 > > > Am 08.06.2014 um 09:27 schrieb stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > >> if you are talking about the extension made by nicolas cellier: >> probably. >> >> Stef >> >> On 8/6/14 00:10, S. Garth Holland wrote: >>> Will Pharo ever get the pipe opeator? >>> >>> http://www.reddit.com/r/smalltalk/comments/27k27b/chaining_messages/ >>> >>> /Garth >>> >>> >> >

June 8, 2014

Re: [Pharo-dev] Pipe operator

by Attila Magyar

Yes, AFIK, the Java 8 stream API works similarly. The query is called stream(), the endQuery is called collect(Collectors.toList()) -- View this message in context: http://forum.world.st/Pipe-operator-tp4762106p4762209.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 8, 2014

Re: [Pharo-dev] Pipe operator

by Camille Teruel

On 8 juin 2014, at 19:20, Garth Holland <steve9571952(a)hotmail.com> wrote: > The pipe operator appears in many languages (F#, Haskell, Elixir, Clojure > (threading macro)). It's an elegant way of chaining method/function calls in > the presence of additional parameters. The reddit example could be written > using a pipe operator |> > > #('apple' 'peach' 'banana') > |> groupedBy: #size > |> select: [:each | each size even] > |> values > |> collect: #asCommaString. The pipe operator is implemented as one of the examples of LanguageBox, a tool that permits to scope language extensions (it's a part of Helvetia made by Lucas Renggli). I once thought that the pipe operator could be useful. But now I notice that the main (if not the only) recurrent use case I found is chaining queries on collections. If you have another recurrent use case (that is not purely idiomatic :) ) please let me know. So yes, using the pipe operator make the snippet more readable but still has much inefficient: at each step a new collection is created just to be trashed afterward. Here it's not a problem but not all collections only have 3 elements ;). For me it's a sign that the collection libraries lack a simple abstraction: composable filters (that is, iterators) to make complex queries. We could have collections answering #query that would responds a QueryBuilder object that would understand common enumeration methods, for example: #('apple' 'peach' 'banana') query groupedBy: #size; select: [:each | each size even]; values; collect: #asCommaString. This would return a CollectFilter on a ValuesFilter on a SelectFilter on a GroupedByFilter on the input collection. The QueryBuilder could then answer a message like #endQuery to compute and return the values obtained by the lastly created filter (embedded in a collection that conforms to the input collection's #species). Since it's just a composition of filter objects over the input collection, no useless intermediate collection is created: better performances & less stress on the GC. Of course this idea is acceptable only if they are no other use cases where the pipe operator is a must. > > /Garth > > > > > -- > View this message in context: http://forum.world.st/Pipe-operator-tp4762106p4762182.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

June 8, 2014

Re: [Pharo-dev] Pipe operator

by Garth Holland

The pipe operator was discussed extensively on the Squeak list back in 2007. http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-August/thread.h… I count 161 pipe related messages. Judging from the bug report http://bugs.squeak.org/view.php?id=6649 , the Squeak team were reluctant to make changes to the language. OTOH, the pipe operator has become almost essential in languages such as F#, Clojure and Elixir. /Garth -- View this message in context: http://forum.world.st/Pipe-operator-tp4762106p4762202.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 8, 2014

Re: [Pharo-dev] Pipe operator

by Attila Magyar

Hi, I wrote that reddit post. I was curious if anyone came up with something to this. Since then I discovered that Bert Freudenberg created an asPipe method before, that works exactly the same way as mine. And probably asPipe is a better name than chain. The idea of the pipe operator is interesting as well, but I prefer library based solutions. Attila -- View this message in context: http://forum.world.st/Pipe-operator-tp4762106p4762201.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 8, 2014

Bench comparing Pahro 1.4 and 3.0.

by Hilaire Fernandes

I have run a Sketch script on DRGeo on Pharo 1.4 and 3.0 The script involved a lot of collection operations and object comparison. The leaves results are strange, because the script is the same: On Pharo 1.4: **Leaves** 14.2% {97ms} Array class(Behavior)>>inheritsFrom: 11.4% {77ms} OrderedCollection(SequenceableCollection)>>hasEqualElements: 9.7% {66ms} DrGPointIntersectionItem>>= 9.6% {65ms} DrGPointIntersectionItem(DrGMathItem)>>parentsEqual: 5.0% {34ms} OrderedCollection>>at: 5.0% {34ms} Array(SequenceableCollection)>>first 4.7% {32ms} DrGPointFreeItem(DrGMathItem)>>= 3.5% {24ms} OrderedCollection(SequenceableCollection)>>= 2.7% {18ms} Array(Object)>>isKindOf: 2.4% {16ms} OrderedCollection>>do: 2.4% {16ms} OrderedCollection>>size 1.8% {12ms} OrderedCollection(SequenceableCollection)>>indexOf:startingAt:ifAbsent: 1.2% {8ms} OrderedCollection>>ensureBoundsFrom:to: 1.2% {8ms} SmallInteger(Number)>>negative On Pharo3: **Leaves** 15.8% {168ms} Array class(Behavior)>>inheritsFrom: 11.4% {121ms} DrGCircle2ptsItem(DrGMathItem)>>= 8.3% {88ms} OrderedCollection>>size 8.3% {88ms} DrGCircle2ptsItem(DrGMathItem)>>parentsEqual: 7.5% {80ms} OrderedCollection>>at: 7.1% {76ms} OrderedCollection(SequenceableCollection)>>= 6.6% {70ms} Array(SequenceableCollection)>>first 6.0% {63ms} DrGPointIntersectionItem>>= 5.6% {59ms} OrderedCollection(SequenceableCollection)>>hasEqualElements: 1.9% {20ms} OrderedCollection>>do: 1.9% {20ms} OrderedCollection>>ensureBoundsFrom:to: 1.7% {18ms} OrderedCollection(Object)>>isKindOf: 1.5% {16ms} OrderedCollection(SequenceableCollection)>>indexOf:startingAt:ifAbsent: 1.5% {16ms} SmallInteger(Number)>>negative True in between DrGeo changes a bit but normally not in the part involved: -- Dr. Geo http://drgeo.eu iStoa - https://launchpad.net/istoa

June 8, 2014

Re: [Pharo-dev] Pipe operator

by Frank Shearar

Vassili Bykov wrote about the pipe operator in Smalltalk back in 2007: http://blog.3plus4.org/2007/08/30/message-chains/ frank On 8 June 2014 18:20, Garth Holland <steve9571952(a)hotmail.com> wrote: > The pipe operator appears in many languages (F#, Haskell, Elixir, Clojure > (threading macro)). It's an elegant way of chaining method/function calls in > the presence of additional parameters. The reddit example could be written > using a pipe operator |> > > #('apple' 'peach' 'banana') > |> groupedBy: #size > |> select: [:each | each size even] > |> values > |> collect: #asCommaString. > > /Garth > > > > > -- > View this message in context: http://forum.world.st/Pipe-operator-tp4762106p4762182.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

June 8, 2014

Re: [Pharo-dev] Pipe operator

by Ben Coman

Garth Holland wrote: > The pipe operator appears in many languages (F#, Haskell, Elixir, Clojure > (threading macro)). It's an elegant way of chaining method/function calls in > the presence of additional parameters. The reddit example could be written > using a pipe operator |> > > #('apple' 'peach' 'banana') > |> groupedBy: #size > |> select: [:each | each size even] > |> values > |> collect: #asCommaString. > > /Garth > > > Ah... so you mean instead of doing this? (((#('apple' 'peach' 'banana') groupedBy: #size ) select: [:each | each size even] ) values ) collect: #asCommaString. Yes. The former does look nice. cheers -ben

June 8, 2014