- Pharo-users - lists.pharo.org

Re: [Pharo-users] Wiring objects, IoC and Service Locator

by Vitor Medina Cruz

Thanks for the detailed answer ben :) I will try to clarify a little: the question is how to loosely wire objects, such as MovieLister to MovieFinder, so that changes in the wiring can be made without effort. In Java, people use DI containers and xml files or annotations to provide the wiring configuration, which is easy to switch entirely. For example, I could have a xml file for production code and another for testing purposes. Also, another advantage is that the container takes care of ordering object creation for me. For example, if the object A, B and C needed to be injected on the object Y, I just have to declare each one of those objects on the configuration file, the container arranges the creation order for me. I started, however, to question DI as a valid mechanisms because of it's complexities and other problems. The article from Fowler provides the service locator as an alternative which seems to me much simpler and completely fine solution for the problem. So, to answer you question "Is it any more complicated than that?": In the DI approach, yes it can be, but I don't think so in the service locator approach. I am asking here because I wanted to know how people from Smalltalk deal with this problem. As it seems there is no standard approach, nor this is perceived as a problem... You think it is enough to do the wiring by hand? It is ok to use a service locator approach? Or wouldn't you care about that? but I'll add, it was so much simpler to understand without all that Java > typing boiler plate. Yeah, that's for sure! I am just used to read Java code. []s, Vitor On Mon, Jun 5, 2017 at 9:46 PM, Ben Coman <btc(a)openinworld.com> wrote: > > > On Tue, Jun 6, 2017 at 5:11 AM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > >> Tx ben. >> When I see all this complexity for something that looks not that complex: >> I prefer to pass the class and get done. >> May be I missed something obvious... but when I see something too complex >> I start to get worried. >> >> I think that thinking about the contract between classes at runtime is >> important and to me a MovieLister should be using at runtime and instance >> of the *Finder* >> Now needing an extra class just to set this should really be evaluated >> with the tradeoff: "flexibility win" (our simple solution is still really >> flexible - I decide when I want to pass the correct finder) vs. the code >> and conceptual bloat. >> >> >> I'm happy not to face the hyper super over engineering of Java >> "solutions". >> >> I like the "Of course this just shifts the burden a tad, we still have >> to get the locator into the lister" >> but the solution is super simple let us use another "Singleton and a >> Factory...." :) >> >> Stef >> >> On Mon, Jun 5, 2017 at 8:43 PM, Ben Coman <btc(a)openinworld.com> wrote: >> >>> >>> >>> On Tue, Jun 6, 2017 at 1:26 AM, Vitor Medina Cruz <vitormcruz(a)gmail.com> >>> wrote: >>> >>>> Thanks for the answer Ben and Stephane. >>>> >>>> I already read A Mentoring Course on Smalltalk, Valloud, there is >>>> nothing there I could use in this case :( . I will look after for The >>>> Design Patterns Smalltalk Companion. Most of the sources provided I already >>>> know of or went in the same lines lines of what I have already found. >>>> >>>> About TDD, I am experienced with the discipline and have tested it on >>>> Pharo living system already, but I could not understand how this is related >>>> with object wiring, DI and service locator. >>>> >>> >>> I guess I don't properly understand your need and those topics. That >>> was my quick pass. Now if I take the time to actually read Fowler's long >>> article >>> >>> "the inversion is about how they lookup a plugin implementation ... to >>> ensure that any user of a plugin follows some convention that allows a >>> separate assembler module to inject the implementation into the lister." >>> >>> "The basic idea of the Dependency Injection is to have a separate >>> object, an assembler, that populates a field in the lister class with an >>> appropriate implementation for the finder interface. There are three main >>> styles of dependency injection. The names I'm using for them are >>> Constructor Injection, Setter Injection, and Interface Injection." >>> >>> Now there was too much syntactical noise in those Java examples for me >>> to think clearly, so I converted them all to Smalltalk. >>> >>> >>> ##CONSTRUCTOR INJECTION >>> >>> Object subclass: MovieLister >>> instanceVariables: 'finder' >>> >>> >>> MovieLister class >> newWith: aFinder >>> ^ self basicNew initializeWith: aFinder >>> >>> MovieLister >> initializeWith: aFinder >>> finder := aFinder >>> >>> >>> ColonMovieFinder class >> newWith: aFilename >>> ^ self basicNew initializeWith: aFilename >>> >>> ColonMovieFinder >> initializeWith: aFilename >>> filename := aFilename. >>> >>> >>> ConstructorInjectionContainer >> new >>> container := DefaultContainer new. "the article doesn't specify >>> where this comes from" >>> finderParams := ConstantParameter newWith: 'movies1.txt'. >>> container registerComponentInterface: MovieFinderInterface >>> implementation: ColonMovieFinder >>> params: finderParams. >>> container registerComponentImplementation: MovieLister >>> ^container >>> >>> to be used like this... >>> ConstructorInjectionTest >> testWithContainer >>> container := ConstructorInjectionContainer new. >>> lister := container getComponentInstance( MovieLister ). >>> movies = lister moviesDirectedBy: 'Sergio Leone'. >>> self assert: (movies includes: 'Once Upon a Time in the West') >>> >>> The article poorly defines registerComponentXXX: or getComponentInstance: >>> methods, so I don't dwell on them. I presume its little relevant to the >>> main theme. >>> >>> >>> ##SETTER INJECTION >>> >>> MovieLister >> setFinder: aFinder >>> finder := aFinder. >>> >>> ColonMovieFinder >> setFilename: aFilename >>> filename := aFilename. >>> >>> SetterInjectionTest >> testWithConfigurationFile >>> ctx := SomeXmlApplicationConfiguration on: 'config.xml'. >>> lister := ctx getConfigOf: 'MovieLister'. >>> movies = lister moviesDirectedBy: 'Sergio Leone'. >>> self assert: (movies includes: 'Once Upon a Time in the West') >>> >>> >>> ##INTERFACE INJECTION >>> >>> MovieLister >> injectFinder: aFinder >>> finder := aFinder >>> >>> ColonMovieFinder >> injectFilename: aFilename >>> filename := aFilename >>> >>> InterfaceInjectionTest >> configureContainer >>> container := InterfaceInjectionContainer new. >>> self registerComponents. >>> self registerInjectors. >>> container start. >>> >>> InterfaceInjectionTest >> registerComponents >>> container registerComponent: 'MovieLister' with: MovieLister. >>> container registerComponent: 'MovieFinder' with: ColonMovieFinder. >>> >>> InterfaceInjectionTest >> registerInjectors >>> container registerInjector: Injector with: (container lookup: >>> 'MovieFinder'). >>> container registerInjector: InjectorFinderFilename with: >>> FinderFilenameInjector new. >>> >>> ColonMovieFinder >> inject: anObject >>> anObject injectFinder: self. >>> >>> FinderFilenameInjector >> inject: anObject >>> anObject injectFilename: 'movies1.txt'. >>> >>> InterfaceInjectionTester >> testInterface >>> self configureContainer. >>> lister := container lookup: 'MovieLister'. >>> movies = lister moviesDirectedBy: 'Sergio Leone'. >>> self assert: (movies includes: 'Once Upon a Time in the West') >>> >>> The article doesn't define InterfaceInjectionContainer, but I guess it >>> could look like this... >>> >>> InterfaceInjectionContainer >> registerComponent: componentName with: >>> aComponent >>> container ifNil: [ container := Dictionary new]. >>> container at: componentName put: aComponent >>> >>> InterfaceInjectionContainer >> lookup: componentName >>> ^ container at: componentName >>> >>> >>> ##SERVICE LOCATOR >>> >>> "The basic idea behind a service locator is to have an object that knows >>> how to get hold of all of the services that an application might need. So a >>> service locator for this application would have a method that returns a >>> movie finder when one is needed. Of course this just shifts the burden a >>> tad, we still have to get the locator into the lister" >>> >>> MovieLister >> initialize >>> finder := ServiceLocator movieFinder. >>> >>> >>> Object subclass: ServiceLocator >>> instanceVariable: 'movieFinder' >>> classVariable: 'SoleInstance' >>> >>> ServiceLocator class >> load: aServiceLocator >>> SoleInstance := aServiceLocator >>> >>> ServiceLocator class >> soleInstance >>> ^ SoleInstance >>> >>> ServiceLocator class >> movieFinder >>> ^ self soleInstance movieFinder >>> >>> ServiceLocator >> movieFinder >>> ^movieFinder >>> >>> >>> ServiceLocatorTest >> configure >>> ServiceLocator load: (ServiceLocator newWith: (ColonMovieFinder >>> newWith: 'movies1.txt')) >>> >>> >>> ServiceLocator class >> newWith: aMovieFinder >>> ^ self basicNew initializeWithFinder: aMovieFinder >>> >>> ServiceLocator >> initializeWithFinder: aMovieFinder >>> movieFinder := aMovieFinder >>> >>> >>> ServiceLocatorTest >> testSimple >>> self configure. >>> lister := MovieLister new. >>> movies = lister moviesDirectedBy: 'Sergio Leone'. >>> self assert: (movies includes: 'Once Upon a Time in the West') >>> >>> So it seems that a service locator is just a Singleton pattern having a >>> class variable for each service of interest ?? >>> >> > It was late and I mispoke here, of course this should have said... > * a Singleton pattern having an instance variable for each service of > interest > * a Singleton pattern having a getter method (with hidden implementation) for > each service of interest > > > >> So in good faith** I ask... "Is it any more complicated than that?" >>> >>> **Since its taken me a couple of hours to convert the Java to this point >>> so I stopped reading to seek your feedback. >>> >> > but I'll add, it was so much simpler to understand without all that Java > typing boiler plate. > > cheers -ben > > >> Is that enough insight to adapt to your needs, or is there something else >>> further down the article that invalidates my analysis? >>> >>> >>> >>> >>> >>>> >>>> From ben: >>>> >>>> "I'm not really familiar with IoC or DI patterns, so just taking your >>>>> example at face value, in Pharo I'd do... >>>>> >>>>> MovieLister>>moviesDirectedBy: director >>>>> allMovies := finder allMovies. >>>>> ^ allMovies select: [ :movie | movie getDirector = director ]. >>>>> "although typically #getDirector would be renamed #director" >>>>> >>>>> MovieLister>>finder: movieFinder >>>>> finder := movieFinder. >>>>> >>>>> to be used like this... >>>>> lister := MovieLister new finder: (ColonDelimitedMovieFinder on: >>>>> 'movies1.txt'). >>>>> movies := lister moviesDirectedBy: 'Tarantino'." >>>> >>>> >>> >>> So per Fowler, the above is equivalent to "Setter Injection with Spring" >>> >>> >>>> >>>> and Stephane: >>>> >>>> Why don't you simply pass the class and use that class in your >>>>> MovieLister? >>>>> >>>>> MovieLister new >>>>> finderClass: MySuperCoolFinderClass >>>>> >>>>> ... >>>>> MovieLister finder >>>>> finderClass new ..... >>>>> >>>>> What is wrong with that. >>>> >>>> >>>> That was what I meant when I said: "I know that in Smalltalk I can >>>> make MovieLister to receive, upon construction, a class representing >>>> MovieFinder and call it construction message.". The code I had in mind >>>> is a bit of mix from the one provided by you both: >>>> >>>> MovieLister>>moviesDirectedBy: director >>>> allMovies := finder allMovies. >>>> ^ allMovies select: [ :movie | movie getDirector = director ]. >>>> "although typically #getDirector would be renamed #director" >>>> >>>> MovieLister>>finder: aMovieFinderBuilder >>>> finder := aMovieFinderClass new. >>>> >>>> to be used like this... >>>> lister := MovieLister new finder: (ColonDelimitedMovieFinder >>>> builderOn: 'movies1.txt'). >>>> movies := lister moviesDirectedBy: 'Tarantino'." >>>> >>>> But that means I will have to wire dependencies by hand whenever I >>>> create a MovieLister and seek through code when and if those dependencies >>>> change. When there are lot's of dependencies it's is a considerable and >>>> tedious work. Let's see an image from Fowlers article: >>>> >>>> [image: Inline image 1] >>>> >>>> In this case, the service locator provides me with an instance and I >>>> configure the instance in the assembler, the scheme is alike for an IoC, >>>> and that would mean my implementation could be like this: >>>> >>>> >>>> MovieLister>>moviesDirectedBy: director >>>> allMovies := finder allMovies. >>>> ^ allMovies select: [ :movie | movie getDirector = director ]. >>>> "although typically #getDirector would be renamed #director" >>>> >>>> MovieLister>>initialize >>>> finder := ServiceLocator locate: FinderClass <--- This would >>>> bring the instance of finder class configured by the assembler >>>> >>> >>> No, like this... >>> finder := ServiceLocation movieFinder. >>> >>> Now if you want to store a class rather than an instance as I did higher >>> up, you just do this... >>> >>> Object subclass: ServiceLocator >>> instanceVariable: 'movieFinderClass' >>> classVariable: 'SoleInstance' >>> >>> ServiceLocator class >> movieFinder >>> ^ self soleInstance movieFinderClass new >>> >>> >>> >>>> >>>> >>>> to be used like this... >>>> lister := MovieLister new. >>>> movies := lister moviesDirectedBy: 'Tarantino'." >>>> >>>> and the assembler: >>>> >>>> Assember class>>configure: >>>> aMap put: (ColonDelimitedMovieFinder builderOn: 'movies1.txt') at: >>>> FinderClass >>>> >>> >>> Assembler class>>configure >>> ServiceLocator load: >>> (ServiceLocator new >>> movieFinder: (ColonMovieFinder newWith: 'movies1.txt') >>> otherService: MyCustomService new) >>> >>> >>>> >>>> My assembler and service locator could be even more elaborated, and >>>> provide a different MovieFinder in test scope, for different classes or >>>> wharever. >>>> >>> >>> Really, the test should not be updating the class variable global like >>> this... >>> ServiceLocatorTest >> configure >>> ServiceLocator load: (ServiceLocator newWith: (ColonMovieFinder >>> newWith: 'movies1.txt')) >>> >>> you probably want something like (its rough but shows the point...) >>> Object subclass: #MovieLister >>> instanceVariables: 'serviceLocator' >>> >>> MovieLister >> initialize >>> serviceLocator ifNil: [ serviceLocator := ServiceLocator >>> soleInstance ]. >>> finder := serviceLocator movieFinder. >>> >>> MovieLister class >> newWithServiceLocator: aServiceLocator >>> ^ (self basicNew initializeWithServiceLocator: aServiceLocator) >>> initialize. >>> >>> MovieLister >> initializeWithServiceLocator: aServiceLocator >>> serviceLocator := aServiceLocator >>> >>> ServiceLocatorTest >> testSimple2 >>> lister := MovieLister newWithServiceLocator: (ServiceLocator >>> newWith: (ColonMovieFinder newWith: 'movies1.txt')). >>> movies = lister moviesDirectedBy: 'Sergio Leone'. >>> self assert: (movies includes: 'Once Upon a Time in the West') >>> >>> >>> cheers -ben >>> >>> >>>> >>>> It is a little convenience for Smalltalk, I will give that, but I was >>>> wandering if there was something alike in Pharo, by your answers I assuming >>>> there is nothing like that. >>>> >>>> >>>> >>>> On Mon, Jun 5, 2017 at 6:41 AM, Stephane Ducasse < >>>> stepharo.self(a)gmail.com> wrote: >>>> >>>>> Why don't you simply pass the class and use that class in your >>>>> MovieLister? >>>>> >>>>> MovieLister new >>>>> finderClass: MySuperCoolFinderClass >>>>> >>>>> ... >>>>> MovieLister finder >>>>> finderClass new ..... >>>>> >>>>> What is wrong with that. >>>>> >>>>> If you do not want to have a reference at runtime to a Finder then you >>>>> need to use announcement and registration. >>>>> >>>>> Stef >>>>> >>>>> >>>>> >>>>> On Sun, Jun 4, 2017 at 11:17 PM, Vitor Medina Cruz < >>>>> vitormcruz(a)gmail.com> wrote: >>>>> > Hello, >>>>> > >>>>> > I would like to know how people in Pharo ecosystem do to deal with >>>>> object >>>>> > wiring, as described by Marting Fowler in >>>>> > https://martinfowler.com/articles/injection.html#FormsOfDepe >>>>> ndencyInjection: >>>>> > >>>>> > "A common issue to deal with is how to wire together different >>>>> elements: how >>>>> > do you fit together this web controller architecture with that >>>>> database >>>>> > interface backing when they were built by different teams with little >>>>> > knowledge of each other." >>>>> > >>>>> > He gives an example, I will leave it in java as it is simple enough >>>>> to >>>>> > understand: >>>>> > >>>>> > "class MovieLister... >>>>> > >>>>> > public Movie[] moviesDirectedBy(String arg) { >>>>> > List allMovies = finder.findAll(); >>>>> > for (Iterator it = allMovies.iterator(); it.hasNext();) { >>>>> > Movie movie = (Movie) it.next(); >>>>> > if (!movie.getDirector().equals(arg)) it.remove(); >>>>> > } >>>>> > return (Movie[]) allMovies.toArray(new >>>>> Movie[allMovies.size()]); >>>>> > >>>>> > }" >>>>> > >>>>> > The question is how to provide the finder object in a decoupled >>>>> matter, a >>>>> > naive approach would be: >>>>> > >>>>> > " private MovieFinder finder; >>>>> > >>>>> > public MovieLister() { >>>>> > finder = new ColonDelimitedMovieFinder("movies1.txt"); >>>>> > >>>>> > }" >>>>> > >>>>> > Which couples the MovieLister to the specific >>>>> ColonDelimitedMovieFinder >>>>> > class. >>>>> > >>>>> > Fowler explains how to decouple using an IoC framework or a Service >>>>> Locator. >>>>> > In Java and .Net IoC is used most of the time. I Googled how this >>>>> problem is >>>>> > approached in Smalltalk/Pharo, and I generally I found answers "that >>>>> is easy >>>>> > to do in Smalltalk, so there is no need of a framework", what I miss >>>>> is a >>>>> > description on *how* to do that: >>>>> > >>>>> > https://stackoverflow.com/questions/243905/smalltalk-and-ioc >>>>> > https://stackoverflow.com/questions/2684326/is-there-a-depen >>>>> dency-injection-framework-for-smalltalk >>>>> > https://stackoverflow.com/questions/243905/smalltalk-and-ioc >>>>> /347477#347477 >>>>> > >>>>> > I know that in Smalltalk I can make MovieLister to receive, upon >>>>> > construction, a class representing MovieFinder and call it >>>>> construction >>>>> > message. As long an object that responds to this message is >>>>> provided, I can >>>>> > create as many derivations I want and the MovieLister will be >>>>> decoupled from >>>>> > the MovieFinder. That way, however, I still have to wire things by >>>>> hand, and >>>>> > I am not sure if this is what I am supposed to do in order to solve >>>>> the >>>>> > decouple problem. >>>>> > >>>>> > Can you explain me how this is done in Pharo? It's is usually wiring >>>>> by >>>>> > hand? Is there a simple construction that deals with the wiring >>>>> problem that >>>>> > I cannot foresee? >>>>> > >>>>> > Thanks in advance, >>>>> > Vitor >>>>> > >>>>> > >>>>> > >>>>> >>>>> >>>> >>> >> >

June 6, 2017

Re: [Pharo-users] [Pharo-dev] [ANN] Pharo Consortium New Bronze Member: Palantir Solutions

by Tudor Girba

Excellent news! Doru > On Jun 6, 2017, at 2:53 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > The Pharo Consortium is very happy to announce that Palantir Solutions > has joined the Consortium as a Bronze Member. > > About > - Palantir Solutions: https://www.petrovr.com > - Pharo Consortium: http://consortium.pharo.org > > The goal of the Pharo Consortium is to allow companies and institutions to > support the ongoing development and future of Pharo. > > Individuals can support Pharo via the Pharo Association: > > - http://association.pharo.org > -- www.tudorgirba.com www.feenk.com "Every thing should have the right to be different."

June 6, 2017

[ANN] Pharo Consortium New Bronze Member: Palantir Solutions

by Marcus Denker

The Pharo Consortium is very happy to announce that Palantir Solutions has joined the Consortium as a Bronze Member. About - Palantir Solutions: https://www.petrovr.com - Pharo Consortium: http://consortium.pharo.org The goal of the Pharo Consortium is to allow companies and institutions to support the ongoing development and future of Pharo. Individuals can support Pharo via the Pharo Association: - http://association.pharo.org

June 6, 2017

Re: [Pharo-users] Porting Transducers to Pharo

by phil＠highoctane.be

Check https://medium.com/@i.oleks/interface-for-selecting-data-from-a-dataset-d7c… https://medium.com/@i.oleks/an-example-of-test-driven-development-c9ce033f0… Loading a dataframe from a dataset and then using transducers for a transformation pipeline would be great. DataFrame is part of Polymath. https://github.com/PolyMathOrg/PolyMath http://www.smalltalkhub.com/#!/~PolyMath/PolyMath Phil On Tue, Jun 6, 2017 at 1:09 PM, Steffen MÃ¤rcker <merkste(a)web.de> wrote: > Hi Phil, > > Coupling this with Olek's work on the DataFrame could really come handy. >> > > I am new to this list. Could you please elaborate? > > Cheers! > Steffen > > > > On Mon, Jun 5, 2017 at 9:14 AM, Stephane Ducasse <stepharo.self(a)gmail.com> >> wrote: >> >> Hi Steffen >>> >>> >>> > The short answer is that the compact notation turned out to work much >>> better >>> > for me in my code, especially, if multiple transducers are involved. >>> But >>> > that's my personal taste. You can choose which suits you better. In >>> fact, >>> > >>> > 1000 take. >>> > >>> > just sits on top and simply calls >>> > >>> > Take number: 1000. >>> >>> To me this is much much better. >>> >>> >>> > If the need arises, we could of course factor the compact notation out >>> into >>> > a separate package. >>> Good idea >>> >>> Btw, would you prefer (Take n: 1000) over (Take number: >>> > 1000)? >>> >>> I tend to prefer explicit selector :) >>> >>> >>> > Damien, you're right, I experimented with additional styles. Right now, >>> we >>> > already have in the basic Transducer package: >>> > >>> > (collection transduce: #squared map * 1000 take. "which is equal to" >>> > (collection transduce: #squared map) transduce: 1000 take. >>> > >>> > Basically, one can split #transduce:reduce:init: into single calls of >>> > #transduce:, #reduce:, and #init:, depending on the needs. >>> > I also have an (unfinished) extension, that allows to write: >>> > >>> > (collection transduce map: #squared) take: 1000. >>> >>> To me this is much mre readable. >>> I cannot and do not want to use the other forms. >>> >>> >>> > This feels familiar, but becomes a bit hard to read if more than two >>> steps >>> > are needed. >>> > >>> > collection transduce >>> > map: #squared; >>> > take: 1000. >>> >>> Why this is would hard to read. We do that all the time everywhere. >>> >>> >>> > I think, this alternative would reads nicely. But as the message chain >>> has >>> > to modify the underlying object (an eduction), very snaky side effects >>> may >>> > occur. E.g., consider >>> > >>> > eduction := collection transduce. >>> > squared := eduction map: #squared. >>> > take := squared take: 1000. >>> > >>> > Now, all three variables hold onto the same object, which first squares >>> all >>> > elements and than takes the first 1000. >>> >>> This is because the programmer did not understand what he did. No? >>> >>> >>> >>> Stef >>> >>> PS: I played with infinite stream and iteration back in 1993 in CLOS. >>> Now I do not like to mix things because it breaks my flow of thinking. >>> >>> >>> > >>> > Best, >>> > Steffen >>> > >>> > >>> > >>> > >>> > >>> > Am .06.2017, 21:28 Uhr, schrieb Damien Pollet >>> > <damien.pollet+pharo(a)gmail.com>: >>> > >>> >> If I recall correctly, there is an alternate protocol that looks more >>> like >>> >> xtreams or the traditional select/collect iterations. >>> >> >>> >> On 2 June 2017 at 21:12, Stephane Ducasse <stepharo.self(a)gmail.com> >>> wrote: >>> >> >>> >>> I have a design question >>> >>> >>> >>> why the library is implemented in functional style vs messages? >>> >>> I do not see why this is needed. To my eyes the compact notation >>> >>> goes against readibility of code and it feels ad-hoc in Smalltalk. >>> >>> >>> >>> >>> >>> I really prefer >>> >>> >>> >>> square := Map function: #squared. >>> >>> take := Take number: 1000. >>> >>> >>> >>> Because I know that I can read it and understand it. >>> >>> From that perspective I prefer Xtreams. >>> >>> >>> >>> Stef >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Wed, May 31, 2017 at 2:23 PM, Steffen MÃ¤rcker <merkste(a)web.de> >>> wrote: >>> >>> >>> >>>> Hi, >>> >>>> >>> >>>> I am the developer of the library 'Transducers' for VisualWorks. It >>> was >>> >>>> formerly known as 'Reducers', but this name was a poor choice. I'd >>> like >>> >>>> to >>> >>>> port it to Pharo, if there is any interest on your side. I hope to >>> learn >>> >>>> more about Pharo in this process, since I am mainly a VW guy. And >>> most >>> >>>> likely, I will come up with a bunch of questions. :-) >>> >>>> >>> >>>> Meanwhile, I'll cross-post the introduction from VWnc below. I'd be >>> very >>> >>>> happy to hear your optinions, questions and I hope we can start a >>> >>>> fruitful >>> >>>> discussion - even if there is not Pharo port yet. >>> >>>> >>> >>>> Best, Steffen >>> >>>> >>> >>>> >>> >>>> >>> >>>> Transducers are building blocks that encapsulate how to process >>> elements >>> >>>> of a data sequence independently of the underlying input and output >>> >>>> source. >>> >>>> >>> >>>> >>> >>>> >>> >>>> # Overview >>> >>>> >>> >>>> ## Encapsulate >>> >>>> Implementations of enumeration methods, such as #collect:, have the >>> >>>> logic >>> >>>> how to process a single element in common. >>> >>>> However, that logic is reimplemented each and every time. >>> Transducers >>> >>>> make >>> >>>> it explicit and facilitate re-use and coherent behavior. >>> >>>> For example: >>> >>>> - #collect: requires mapping: (aBlock1 map) >>> >>>> - #select: requires filtering: (aBlock2 filter) >>> >>>> >>> >>>> >>> >>>> ## Compose >>> >>>> In practice, algorithms often require multiple processing steps, >>> e.g., >>> >>>> mapping only a filtered set of elements. >>> >>>> Transducers are inherently composable, and hereby, allow to make the >>> >>>> combination of steps explicit. >>> >>>> Since transducers do not build intermediate collections, their >>> >>>> composition >>> >>>> is memory-efficient. >>> >>>> For example: >>> >>>> - (aBlock1 filter) * (aBlock2 map) "(1.) filter and (2.) map >>> elements" >>> >>>> >>> >>>> >>> >>>> ## Re-Use >>> >>>> Transducers are decoupled from the input and output sources, and >>> hence, >>> >>>> they can be reused in different contexts. >>> >>>> For example: >>> >>>> - enumeration of collections >>> >>>> - processing of streams >>> >>>> - communicating via channels >>> >>>> >>> >>>> >>> >>>> >>> >>>> # Usage by Example >>> >>>> >>> >>>> We build a coin flipping experiment and count the occurrence of >>> heads >>> >>>> and >>> >>>> tails. >>> >>>> >>> >>>> First, we associate random numbers with the sides of a coin. >>> >>>> >>> >>>> scale := [:x | (x * 2 + 1) floor] map. >>> >>>> sides := #(heads tails) replace. >>> >>>> >>> >>>> Scale is a transducer that maps numbers x between 0 and 1 to 1 and >>> 2. >>> >>>> Sides is a transducer that replaces the numbers with heads an tails >>> by >>> >>>> lookup in an array. >>> >>>> Next, we choose a number of samples. >>> >>>> >>> >>>> count := 1000 take. >>> >>>> >>> >>>> Count is a transducer that takes 1000 elements from a source. >>> >>>> We keep track of the occurrences of heads an tails using a bag. >>> >>>> >>> >>>> collect := [:bag :c | bag add: c; yourself]. >>> >>>> >>> >>>> Collect is binary block (reducing function) that collects events in >>> a >>> >>>> bag. >>> >>>> We assemble the experiment by transforming the block using the >>> >>>> transducers. >>> >>>> >>> >>>> experiment := (scale * sides * count) transform: collect. >>> >>>> >>> >>>> From left to right we see the steps involved: scale, sides, count >>> and >>> >>>> collect. >>> >>>> Transforming assembles these steps into a binary block (reducing >>> >>>> function) >>> >>>> we can use to run the experiment. >>> >>>> >>> >>>> samples := Random new >>> >>>> reduce: experiment >>> >>>> init: Bag new. >>> >>>> >>> >>>> Here, we use #reduce:init:, which is mostly similar to >>> #inject:into:. >>> >>>> To execute a transformation and a reduction together, we can use >>> >>>> #transduce:reduce:init:. >>> >>>> >>> >>>> samples := Random new >>> >>>> transduce: scale * sides * count >>> >>>> reduce: collect >>> >>>> init: Bag new. >>> >>>> >>> >>>> We can also express the experiment as data-flow using #<~. >>> >>>> This enables us to build objects that can be re-used in other >>> >>>> experiments. >>> >>>> >>> >>>> coin := sides <~ scale <~ Random new. >>> >>>> flip := Bag <~ count. >>> >>>> >>> >>>> Coin is an eduction, i.e., it binds transducers to a source and >>> >>>> understands #reduce:init: among others. >>> >>>> Flip is a transformed reduction, i.e., it binds transducers to a >>> >>>> reducing >>> >>>> function and an initial value. >>> >>>> By sending #<~, we draw further samples from flipping the coin. >>> >>>> >>> >>>> samples := flip <~ coin. >>> >>>> >>> >>>> This yields a new Bag with another 1000 samples. >>> >>>> >>> >>>> >>> >>>> >>> >>>> # Basic Concepts >>> >>>> >>> >>>> ## Reducing Functions >>> >>>> >>> >>>> A reducing function represents a single step in processing a data >>> >>>> sequence. >>> >>>> It takes an accumulated result and a value, and returns a new >>> >>>> accumulated >>> >>>> result. >>> >>>> For example: >>> >>>> >>> >>>> collect := [:col :e | col add: e; yourself]. >>> >>>> sum := #+. >>> >>>> >>> >>>> A reducing function can also be ternary, i.e., it takes an >>> accumulated >>> >>>> result, a key and a value. >>> >>>> For example: >>> >>>> >>> >>>> collect := [:dic :k :v | dict at: k put: v; yourself]. >>> >>>> >>> >>>> Reducing functions may be equipped with an optional completing >>> action. >>> >>>> After finishing processing, it is invoked exactly once, e.g., to >>> free >>> >>>> resources. >>> >>>> >>> >>>> stream := [:str :e | str nextPut: each; yourself] completing: >>> >>>> #close. >>> >>>> absSum := #+ completing: #abs >>> >>>> >>> >>>> A reducing function can end processing early by signaling Reduced >>> with a >>> >>>> result. >>> >>>> This mechanism also enables the treatment of infinite sources. >>> >>>> >>> >>>> nonNil := [:res :e | e ifNil: [Reduced signalWith: res] ifFalse: >>> >>>> [res]]. >>> >>>> >>> >>>> The primary approach to process a data sequence is the reducing >>> protocol >>> >>>> with the messages #reduce:init: and #transduce:reduce:init: if >>> >>>> transducers >>> >>>> are involved. >>> >>>> The behavior is similar to #inject:into: but in addition it takes >>> care >>> >>>> of: >>> >>>> - handling binary and ternary reducing functions, >>> >>>> - invoking the completing action after finishing, and >>> >>>> - stopping the reduction if Reduced is signaled. >>> >>>> The message #transduce:reduce:init: just combines the transformation >>> and >>> >>>> the reducing step. >>> >>>> >>> >>>> However, as reducing functions are step-wise in nature, an >>> application >>> >>>> may >>> >>>> choose other means to process its data. >>> >>>> >>> >>>> >>> >>>> ## Reducibles >>> >>>> >>> >>>> A data source is called reducible if it implements the reducing >>> >>>> protocol. >>> >>>> Default implementations are provided for collections and streams. >>> >>>> Additionally, blocks without an argument are reducible, too. >>> >>>> This allows to adapt to custom data sources without additional >>> effort. >>> >>>> For example: >>> >>>> >>> >>>> "XStreams adaptor" >>> >>>> xstream := filename reading. >>> >>>> reducible := [[xstream get] on: Incomplete do: [Reduced >>> signal]]. >>> >>>> >>> >>>> "natural numbers" >>> >>>> n := 0. >>> >>>> reducible := [n := n+1]. >>> >>>> >>> >>>> >>> >>>> ## Transducers >>> >>>> >>> >>>> A transducer is an object that transforms a reducing function into >>> >>>> another. >>> >>>> Transducers encapsulate common steps in processing data sequences, >>> such >>> >>>> as >>> >>>> map, filter, concatenate, and flatten. >>> >>>> A transducer transforms a reducing function into another via >>> #transform: >>> >>>> in order to add those steps. >>> >>>> They can be composed using #* which yields a new transducer that >>> does >>> >>>> both >>> >>>> transformations. >>> >>>> Most transducers require an argument, typically blocks, symbols or >>> >>>> numbers: >>> >>>> >>> >>>> square := Map function: #squared. >>> >>>> take := Take number: 1000. >>> >>>> >>> >>>> To facilitate compact notation, the argument types implement >>> >>>> corresponding >>> >>>> methods: >>> >>>> >>> >>>> squareAndTake := #squared map * 1000 take. >>> >>>> >>> >>>> Transducers requiring no argument are singletons and can be accessed >>> by >>> >>>> their class name. >>> >>>> >>> >>>> flattenAndDedupe := Flatten * Dedupe. >>> >>>> >>> >>>> >>> >>>> >>> >>>> # Advanced Concepts >>> >>>> >>> >>>> ## Data flows >>> >>>> >>> >>>> Processing a sequence of data can often be regarded as a data flow. >>> >>>> The operator #<~ allows define a flow from a data source through >>> >>>> processing steps to a drain. >>> >>>> For example: >>> >>>> >>> >>>> squares := Set <~ 1000 take <~ #squared map <~ (1 to: 1000). >>> >>>> fileOut writeStream <~ #isSeparator filter <~ fileIn readStream. >>> >>>> >>> >>>> In both examples #<~ is only used to set up the data flow using >>> reducing >>> >>>> functions and transducers. >>> >>>> In contrast to streams, transducers are completely independent from >>> >>>> input >>> >>>> and output sources. >>> >>>> Hence, we have a clear separation of reading data, writing data and >>> >>>> processing elements. >>> >>>> - Sources know how to iterate over data with a reducing function, >>> e.g., >>> >>>> via #reduce:init:. >>> >>>> - Drains know how to collect data using a reducing function. >>> >>>> - Transducers know how to process single elements. >>> >>>> >>> >>>> >>> >>>> ## Reductions >>> >>>> >>> >>>> A reduction binds an initial value or a block yielding an initial >>> value >>> >>>> to >>> >>>> a reducing function. >>> >>>> The idea is to define a ready-to-use process that can be applied in >>> >>>> different contexts. >>> >>>> Reducibles handle reductions via #reduce: and #transduce:reduce: >>> >>>> For example: >>> >>>> >>> >>>> sum := #+ init: 0. >>> >>>> sum1 := #(1 1 1) reduce: sum. >>> >>>> sum2 := (1 to: 1000) transduce: #odd filter reduce: sum. >>> >>>> >>> >>>> asSet := [:set :e | set add: e; yourself] initializer: [Set >>> new]. >>> >>>> set1 := #(1 1 1) reduce: asSet. >>> >>>> set2 := #(1 to: 1000) transduce: #odd filter reduce: asSet. >>> >>>> >>> >>>> By combining a transducer with a reduction, a process can be further >>> >>>> modified. >>> >>>> >>> >>>> sumOdds := sum <~ #odd filter >>> >>>> setOdds := asSet <~ #odd filter >>> >>>> >>> >>>> >>> >>>> ## Eductions >>> >>>> >>> >>>> An eduction combines a reducible data sources with a transducer. >>> >>>> The idea is to define a transformed (virtual) data source that needs >>> not >>> >>>> to be stored in memory. >>> >>>> >>> >>>> odds1 := #odd filter <~ #(1 2 3) readStream. >>> >>>> odds2 := #odd filter <~ (1 to 1000). >>> >>>> >>> >>>> Depending on the underlying source, eductions can be processed once >>> >>>> (streams, e.g., odds1) or multiple times (collections, e.g., odds2). >>> >>>> Since no intermediate data is stored, transducers actions are lazy, >>> >>>> i.e., >>> >>>> they are invoked each time the eduction is processed. >>> >>>> >>> >>>> >>> >>>> >>> >>>> # Origins >>> >>>> >>> >>>> Transducers is based on the same-named Clojure library and its >>> ideas. >>> >>>> Please see: >>> >>>> http://clojure.org/transducers >>> >>>> >>> >>>> >>> > >>> >>> >>> > >

June 6, 2017

Re: [Pharo-users] Porting Transducers to Pharo

by phil＠highoctane.be

Hi Steffen, I am willing to help you create the package in SmalltalkHub or Github based on your files/changeset. Do you have a github and/or SmalltalkHub account? Best, Phil On Tue, Jun 6, 2017 at 1:08 PM, Steffen MÃ¤rcker <merkste(a)web.de> wrote: > Hi! > > If the need arises, we could of course factor the compact notation out into >>> a separate package. >>> >> Good idea >> [...] I do not want to help promoting a syntax that alienates me (and >> others because other people reported the saem to me). >> > > I understand. Btw, I'd really, really appreciate if others post their > thoughts and feedback here as well. Discussion helps moving things forward. > =) > > > (collection transduce map: #squared) take: 1000. >>> >> >> To me this is much more readable. >> > > Well, I'll provide that extension once it is finished. > > I cannot and do not want to use the other forms. >> > > > collection transduce >>> map: #squared; >>> take: 1000. >>> >>> But as the message chain has to modify the underlying object >>> (an eduction), very snaky side effects my occur. E.g., consider >>> >>> eduction := collection transduce. >>> squared := eduction map: #squared. >>> take := squared take: 1000. >>> >>> Now, all three variables hold onto the same object, which first squares >>> all elements and than takes the first 1000. >>> >> >> This is because the programmer did not understand what he did. No? >> > > Sure. ;-) Nevertheless, it would be very hard to debug. All of which are > the reasons I wouldn't implement that variant. ;-) > > > PS: I played with infinite stream and iteration back in 1993 in CLOS. >> Now I do not like to mix things because it breaks my flow of thinking. >> > > > I am not sure whether I understand what your mean by mixing. Concerning > transducers, the ability to handle infinite sources in only a (natural) > side-effect of the ability to finish reductions before all elements are > processed, e.g., like #detect: and such. > > Best, Steffen > > > > > >

June 6, 2017

Re: [Pharo-users] Creating a BaselineOf from a ConfigurationOf>>#baselineXyz:

by Nicolai Hess

Hi Sean, 2017-06-04 5:48 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: > I'm trying to write a rewrite rule, but can't quite get it. > > I first want to remove `spec blessing: #baseline.` > > I tried the following with no effect: > > RBParseTreeRewriter new > replace: '`@expr blessing: `#lit' > with: ''; > executeTree: methodTree; > tree. > This works for me, but ... > > NB: If I try to edit the expression instead of remove, by passing something > like '`@expr assert: `#lit' for #with:, it works > > What am I missing here? > > Thanks! > > keep in mind some odds about the caching on ast nodes. Working with the tree rewriter directly on the method ast (MyClass>>#myMethod) ast - will modify the "cached" method ast, that means, on code browser, you do not see the change. - the #source method of the ast, again only shows a cached source (MyClass>>#myMethod) ast source -> "old source" - printing the formatted code will finally step into the (modified) method source nodes (MyClass>>#myMethod) ast formattedCode -> "new source code" > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/ > Creating-a-BaselineOf-from-a-ConfigurationOf-baselineXyz-tp4949192.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

June 6, 2017

Re: [Pharo-users] Analyzing Fuel Problem

by Mariano Martinez Peck

Hi Sean, Sorry for the delay on the answer. Yes, that's a good spot. Another thing I usually do is to put a halt in FLSerialization >> run. Just after #analysisStep for example, and then inspect the local variables. Also, if you want to understand WHY an object is getting in, then you can also halt in #trace and #privateTrace: from FLAnalysis. That way you monitor which objects gets pushed into the analysis stack. You can do something like self haltIf: [ anObject whateverConditionToHaltOnDesiredObject = true ]. Finally, there are more tools for debugging this kind of issue, but I don't know their state. You can read more about them here [1]. Best regards, [1] https://rmod.inria.fr/web/software/Fuel/Version1.9/Documentation/Debugging On Fri, Jun 2, 2017 at 10:26 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > I had an object graph that was pulling in all sorts of unrelated classes > when > serialized with Fuel. I was trying to find the offending object, and came > up > with the following: > ``` > (FLAnalyzer newDefault analysisFor: root) clusterization globalsBucket > ``` > > This worked, but I was wondering if that's "the right way" to do it... > > Thanks. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/ > Analyzing-Fuel-Problem-tp4949104.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > -- Mariano http://marianopeck.wordpress.com

June 6, 2017

Re: [Pharo-users] Porting Transducers to Pharo - Name Clash

by Steffen MÃ¤rcker

Hi, I found some name clash with the message #reduce: in Pharo. It is already declared in SequencableCollection. Additionally, Collection>>fold: just calls #reduce:, which makes the difference between folding and reducing a bit unclear. How should I handle this situation? I see the following options: - I could simply solve the situation at runtime depending on the argument (e.g., using double-dispatching). - I could check whether it might be possible to separate #fold: and #reduce: with the semantics: - reduce: starts with an initial value and the first collection item. - fold: uses no initial value and starts with the first two items. In the Transducers library, there are two variants of reduce: - #reduce:init: reduce using a block and an intial value - #reduce: reduce using a block that carries an intial value or an initializer block. Ciao, Steffen Am .05.2017, 14:23 Uhr, schrieb Steffen MÃ¤rcker <merkste(a)web.de>: > Hi, > > I am the developer of the library 'Transducers' for VisualWorks. It was > formerly known as 'Reducers', but this name was a poor choice. I'd like > to port it to Pharo, if there is any interest on your side. I hope to > learn more about Pharo in this process, since I am mainly a VW guy. And > most likely, I will come up with a bunch of questions. :-) > > Meanwhile, I'll cross-post the introduction from VWnc below. I'd be very > happy to hear your optinions, questions and I hope we can start a > fruitful discussion - even if there is not Pharo port yet. > > Best, Steffen > > > > Transducers are building blocks that encapsulate how to process elements > of a data sequence independently of the underlying input and output > source. > > > > # Overview > > ## Encapsulate > Implementations of enumeration methods, such as #collect:, have the logic > how to process a single element in common. > However, that logic is reimplemented each and every time. Transducers > make > it explicit and facilitate re-use and coherent behavior. > For example: > - #collect: requires mapping: (aBlock1 map) > - #select: requires filtering: (aBlock2 filter) > > > ## Compose > In practice, algorithms often require multiple processing steps, e.g., > mapping only a filtered set of elements. > Transducers are inherently composable, and hereby, allow to make the > combination of steps explicit. > Since transducers do not build intermediate collections, their > composition > is memory-efficient. > For example: > - (aBlock1 filter) * (aBlock2 map) "(1.) filter and (2.) map elements" > > > ## Re-Use > Transducers are decoupled from the input and output sources, and hence, > they can be reused in different contexts. > For example: > - enumeration of collections > - processing of streams > - communicating via channels > > > > # Usage by Example > > We build a coin flipping experiment and count the occurrence of heads and > tails. > > First, we associate random numbers with the sides of a coin. > > scale := [:x | (x * 2 + 1) floor] map. > sides := #(heads tails) replace. > > Scale is a transducer that maps numbers x between 0 and 1 to 1 and 2. > Sides is a transducer that replaces the numbers with heads an tails by > lookup in an array. > Next, we choose a number of samples. > > count := 1000 take. > > Count is a transducer that takes 1000 elements from a source. > We keep track of the occurrences of heads an tails using a bag. > > collect := [:bag :c | bag add: c; yourself]. > > Collect is binary block (reducing function) that collects events in a > bag. > We assemble the experiment by transforming the block using the > transducers. > > experiment := (scale * sides * count) transform: collect. > > From left to right we see the steps involved: scale, sides, count and > collect. > Transforming assembles these steps into a binary block (reducing > function) > we can use to run the experiment. > > samples := Random new > reduce: experiment > init: Bag new. > > Here, we use #reduce:init:, which is mostly similar to #inject:into:. > To execute a transformation and a reduction together, we can use > #transduce:reduce:init:. > > samples := Random new > transduce: scale * sides * count > reduce: collect > init: Bag new. > > We can also express the experiment as data-flow using #<~. > This enables us to build objects that can be re-used in other > experiments. > > coin := sides <~ scale <~ Random new. > flip := Bag <~ count. > > Coin is an eduction, i.e., it binds transducers to a source and > understands #reduce:init: among others. > Flip is a transformed reduction, i.e., it binds transducers to a reducing > function and an initial value. > By sending #<~, we draw further samples from flipping the coin. > > samples := flip <~ coin. > > This yields a new Bag with another 1000 samples. > > > > # Basic Concepts > > ## Reducing Functions > > A reducing function represents a single step in processing a data > sequence. > It takes an accumulated result and a value, and returns a new accumulated > result. > For example: > > collect := [:col :e | col add: e; yourself]. > sum := #+. > > A reducing function can also be ternary, i.e., it takes an accumulated > result, a key and a value. > For example: > > collect := [:dic :k :v | dict at: k put: v; yourself]. > > Reducing functions may be equipped with an optional completing action. > After finishing processing, it is invoked exactly once, e.g., to free > resources. > > stream := [:str :e | str nextPut: each; yourself] completing: > #close. > absSum := #+ completing: #abs > > A reducing function can end processing early by signaling Reduced with a > result. > This mechanism also enables the treatment of infinite sources. > > nonNil := [:res :e | e ifNil: [Reduced signalWith: res] ifFalse: > [res]]. > > The primary approach to process a data sequence is the reducing protocol > with the messages #reduce:init: and #transduce:reduce:init: if > transducers > are involved. > The behavior is similar to #inject:into: but in addition it takes care > of: > - handling binary and ternary reducing functions, > - invoking the completing action after finishing, and > - stopping the reduction if Reduced is signaled. > The message #transduce:reduce:init: just combines the transformation and > the reducing step. > > However, as reducing functions are step-wise in nature, an application > may > choose other means to process its data. > > > ## Reducibles > > A data source is called reducible if it implements the reducing protocol. > Default implementations are provided for collections and streams. > Additionally, blocks without an argument are reducible, too. > This allows to adapt to custom data sources without additional effort. > For example: > > "XStreams adaptor" > xstream := filename reading. > reducible := [[xstream get] on: Incomplete do: [Reduced signal]]. > > "natural numbers" > n := 0. > reducible := [n := n+1]. > > > ## Transducers > > A transducer is an object that transforms a reducing function into > another. > Transducers encapsulate common steps in processing data sequences, such > as > map, filter, concatenate, and flatten. > A transducer transforms a reducing function into another via #transform: > in order to add those steps. > They can be composed using #* which yields a new transducer that does > both > transformations. > Most transducers require an argument, typically blocks, symbols or > numbers: > > square := Map function: #squared. > take := Take number: 1000. > > To facilitate compact notation, the argument types implement > corresponding > methods: > > squareAndTake := #squared map * 1000 take. > > Transducers requiring no argument are singletons and can be accessed by > their class name. > > flattenAndDedupe := Flatten * Dedupe. > > > > # Advanced Concepts > > ## Data flows > > Processing a sequence of data can often be regarded as a data flow. > The operator #<~ allows define a flow from a data source through > processing steps to a drain. > For example: > > squares := Set <~ 1000 take <~ #squared map <~ (1 to: 1000). > fileOut writeStream <~ #isSeparator filter <~ fileIn readStream. > > In both examples #<~ is only used to set up the data flow using reducing > functions and transducers. > In contrast to streams, transducers are completely independent from input > and output sources. > Hence, we have a clear separation of reading data, writing data and > processing elements. > - Sources know how to iterate over data with a reducing function, e.g., > via #reduce:init:. > - Drains know how to collect data using a reducing function. > - Transducers know how to process single elements. > > > ## Reductions > > A reduction binds an initial value or a block yielding an initial value > to > a reducing function. > The idea is to define a ready-to-use process that can be applied in > different contexts. > Reducibles handle reductions via #reduce: and #transduce:reduce: > For example: > > sum := #+ init: 0. > sum1 := #(1 1 1) reduce: sum. > sum2 := (1 to: 1000) transduce: #odd filter reduce: sum. > > asSet := [:set :e | set add: e; yourself] initializer: [Set new]. > set1 := #(1 1 1) reduce: asSet. > set2 := #(1 to: 1000) transduce: #odd filter reduce: asSet. > > By combining a transducer with a reduction, a process can be further > modified. > > sumOdds := sum <~ #odd filter > setOdds := asSet <~ #odd filter > > > ## Eductions > > An eduction combines a reducible data sources with a transducer. > The idea is to define a transformed (virtual) data source that needs not > to be stored in memory. > > odds1 := #odd filter <~ #(1 2 3) readStream. > odds2 := #odd filter <~ (1 to 1000). > > Depending on the underlying source, eductions can be processed once > (streams, e.g., odds1) or multiple times (collections, e.g., odds2). > Since no intermediate data is stored, transducers actions are lazy, i.e., > they are invoked each time the eduction is processed. > > > > # Origins > > Transducers is based on the same-named Clojure library and its ideas. > Please see: > http://clojure.org/transducers

June 6, 2017

Re: [Pharo-users] Porting Transducers to Pharo

by Steffen MÃ¤rcker

Hi Phil, > Coupling this with Olek's work on the DataFrame could really come handy. I am new to this list. Could you please elaborate? Cheers! Steffen > On Mon, Jun 5, 2017 at 9:14 AM, Stephane Ducasse > <stepharo.self(a)gmail.com> > wrote: > >> Hi Steffen >> >> >> > The short answer is that the compact notation turned out to work much >> better >> > for me in my code, especially, if multiple transducers are involved. >> But >> > that's my personal taste. You can choose which suits you better. In >> fact, >> > >> > 1000 take. >> > >> > just sits on top and simply calls >> > >> > Take number: 1000. >> >> To me this is much much better. >> >> >> > If the need arises, we could of course factor the compact notation out >> into >> > a separate package. >> Good idea >> >> Btw, would you prefer (Take n: 1000) over (Take number: >> > 1000)? >> >> I tend to prefer explicit selector :) >> >> >> > Damien, you're right, I experimented with additional styles. Right >> now, >> we >> > already have in the basic Transducer package: >> > >> > (collection transduce: #squared map * 1000 take. "which is equal to" >> > (collection transduce: #squared map) transduce: 1000 take. >> > >> > Basically, one can split #transduce:reduce:init: into single calls of >> > #transduce:, #reduce:, and #init:, depending on the needs. >> > I also have an (unfinished) extension, that allows to write: >> > >> > (collection transduce map: #squared) take: 1000. >> >> To me this is much mre readable. >> I cannot and do not want to use the other forms. >> >> >> > This feels familiar, but becomes a bit hard to read if more than two >> steps >> > are needed. >> > >> > collection transduce >> > map: #squared; >> > take: 1000. >> >> Why this is would hard to read. We do that all the time everywhere. >> >> >> > I think, this alternative would reads nicely. But as the message chain >> has >> > to modify the underlying object (an eduction), very snaky side effects >> may >> > occur. E.g., consider >> > >> > eduction := collection transduce. >> > squared := eduction map: #squared. >> > take := squared take: 1000. >> > >> > Now, all three variables hold onto the same object, which first >> squares >> all >> > elements and than takes the first 1000. >> >> This is because the programmer did not understand what he did. No? >> >> >> >> Stef >> >> PS: I played with infinite stream and iteration back in 1993 in CLOS. >> Now I do not like to mix things because it breaks my flow of thinking. >> >> >> > >> > Best, >> > Steffen >> > >> > >> > >> > >> > >> > Am .06.2017, 21:28 Uhr, schrieb Damien Pollet >> > <damien.pollet+pharo(a)gmail.com>: >> > >> >> If I recall correctly, there is an alternate protocol that looks more >> like >> >> xtreams or the traditional select/collect iterations. >> >> >> >> On 2 June 2017 at 21:12, Stephane Ducasse <stepharo.self(a)gmail.com> >> wrote: >> >> >> >>> I have a design question >> >>> >> >>> why the library is implemented in functional style vs messages? >> >>> I do not see why this is needed. To my eyes the compact notation >> >>> goes against readibility of code and it feels ad-hoc in Smalltalk. >> >>> >> >>> >> >>> I really prefer >> >>> >> >>> square := Map function: #squared. >> >>> take := Take number: 1000. >> >>> >> >>> Because I know that I can read it and understand it. >> >>> From that perspective I prefer Xtreams. >> >>> >> >>> Stef >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> On Wed, May 31, 2017 at 2:23 PM, Steffen MÃ¤rcker <merkste(a)web.de> >> wrote: >> >>> >> >>>> Hi, >> >>>> >> >>>> I am the developer of the library 'Transducers' for VisualWorks. It >> was >> >>>> formerly known as 'Reducers', but this name was a poor choice. I'd >> like >> >>>> to >> >>>> port it to Pharo, if there is any interest on your side. I hope to >> learn >> >>>> more about Pharo in this process, since I am mainly a VW guy. And >> most >> >>>> likely, I will come up with a bunch of questions. :-) >> >>>> >> >>>> Meanwhile, I'll cross-post the introduction from VWnc below. I'd be >> very >> >>>> happy to hear your optinions, questions and I hope we can start a >> >>>> fruitful >> >>>> discussion - even if there is not Pharo port yet. >> >>>> >> >>>> Best, Steffen >> >>>> >> >>>> >> >>>> >> >>>> Transducers are building blocks that encapsulate how to process >> elements >> >>>> of a data sequence independently of the underlying input and output >> >>>> source. >> >>>> >> >>>> >> >>>> >> >>>> # Overview >> >>>> >> >>>> ## Encapsulate >> >>>> Implementations of enumeration methods, such as #collect:, have the >> >>>> logic >> >>>> how to process a single element in common. >> >>>> However, that logic is reimplemented each and every time. >> Transducers >> >>>> make >> >>>> it explicit and facilitate re-use and coherent behavior. >> >>>> For example: >> >>>> - #collect: requires mapping: (aBlock1 map) >> >>>> - #select: requires filtering: (aBlock2 filter) >> >>>> >> >>>> >> >>>> ## Compose >> >>>> In practice, algorithms often require multiple processing steps, >> e.g., >> >>>> mapping only a filtered set of elements. >> >>>> Transducers are inherently composable, and hereby, allow to make >> the >> >>>> combination of steps explicit. >> >>>> Since transducers do not build intermediate collections, their >> >>>> composition >> >>>> is memory-efficient. >> >>>> For example: >> >>>> - (aBlock1 filter) * (aBlock2 map) "(1.) filter and (2.) map >> elements" >> >>>> >> >>>> >> >>>> ## Re-Use >> >>>> Transducers are decoupled from the input and output sources, and >> hence, >> >>>> they can be reused in different contexts. >> >>>> For example: >> >>>> - enumeration of collections >> >>>> - processing of streams >> >>>> - communicating via channels >> >>>> >> >>>> >> >>>> >> >>>> # Usage by Example >> >>>> >> >>>> We build a coin flipping experiment and count the occurrence of >> heads >> >>>> and >> >>>> tails. >> >>>> >> >>>> First, we associate random numbers with the sides of a coin. >> >>>> >> >>>> scale := [:x | (x * 2 + 1) floor] map. >> >>>> sides := #(heads tails) replace. >> >>>> >> >>>> Scale is a transducer that maps numbers x between 0 and 1 to 1 and >> 2. >> >>>> Sides is a transducer that replaces the numbers with heads an >> tails by >> >>>> lookup in an array. >> >>>> Next, we choose a number of samples. >> >>>> >> >>>> count := 1000 take. >> >>>> >> >>>> Count is a transducer that takes 1000 elements from a source. >> >>>> We keep track of the occurrences of heads an tails using a bag. >> >>>> >> >>>> collect := [:bag :c | bag add: c; yourself]. >> >>>> >> >>>> Collect is binary block (reducing function) that collects events >> in a >> >>>> bag. >> >>>> We assemble the experiment by transforming the block using the >> >>>> transducers. >> >>>> >> >>>> experiment := (scale * sides * count) transform: collect. >> >>>> >> >>>> From left to right we see the steps involved: scale, sides, count >> and >> >>>> collect. >> >>>> Transforming assembles these steps into a binary block (reducing >> >>>> function) >> >>>> we can use to run the experiment. >> >>>> >> >>>> samples := Random new >> >>>> reduce: experiment >> >>>> init: Bag new. >> >>>> >> >>>> Here, we use #reduce:init:, which is mostly similar to >> #inject:into:. >> >>>> To execute a transformation and a reduction together, we can use >> >>>> #transduce:reduce:init:. >> >>>> >> >>>> samples := Random new >> >>>> transduce: scale * sides * count >> >>>> reduce: collect >> >>>> init: Bag new. >> >>>> >> >>>> We can also express the experiment as data-flow using #<~. >> >>>> This enables us to build objects that can be re-used in other >> >>>> experiments. >> >>>> >> >>>> coin := sides <~ scale <~ Random new. >> >>>> flip := Bag <~ count. >> >>>> >> >>>> Coin is an eduction, i.e., it binds transducers to a source and >> >>>> understands #reduce:init: among others. >> >>>> Flip is a transformed reduction, i.e., it binds transducers to a >> >>>> reducing >> >>>> function and an initial value. >> >>>> By sending #<~, we draw further samples from flipping the coin. >> >>>> >> >>>> samples := flip <~ coin. >> >>>> >> >>>> This yields a new Bag with another 1000 samples. >> >>>> >> >>>> >> >>>> >> >>>> # Basic Concepts >> >>>> >> >>>> ## Reducing Functions >> >>>> >> >>>> A reducing function represents a single step in processing a data >> >>>> sequence. >> >>>> It takes an accumulated result and a value, and returns a new >> >>>> accumulated >> >>>> result. >> >>>> For example: >> >>>> >> >>>> collect := [:col :e | col add: e; yourself]. >> >>>> sum := #+. >> >>>> >> >>>> A reducing function can also be ternary, i.e., it takes an >> accumulated >> >>>> result, a key and a value. >> >>>> For example: >> >>>> >> >>>> collect := [:dic :k :v | dict at: k put: v; yourself]. >> >>>> >> >>>> Reducing functions may be equipped with an optional completing >> action. >> >>>> After finishing processing, it is invoked exactly once, e.g., to >> free >> >>>> resources. >> >>>> >> >>>> stream := [:str :e | str nextPut: each; yourself] completing: >> >>>> #close. >> >>>> absSum := #+ completing: #abs >> >>>> >> >>>> A reducing function can end processing early by signaling Reduced >> with a >> >>>> result. >> >>>> This mechanism also enables the treatment of infinite sources. >> >>>> >> >>>> nonNil := [:res :e | e ifNil: [Reduced signalWith: res] >> ifFalse: >> >>>> [res]]. >> >>>> >> >>>> The primary approach to process a data sequence is the reducing >> protocol >> >>>> with the messages #reduce:init: and #transduce:reduce:init: if >> >>>> transducers >> >>>> are involved. >> >>>> The behavior is similar to #inject:into: but in addition it takes >> care >> >>>> of: >> >>>> - handling binary and ternary reducing functions, >> >>>> - invoking the completing action after finishing, and >> >>>> - stopping the reduction if Reduced is signaled. >> >>>> The message #transduce:reduce:init: just combines the >> transformation >> and >> >>>> the reducing step. >> >>>> >> >>>> However, as reducing functions are step-wise in nature, an >> application >> >>>> may >> >>>> choose other means to process its data. >> >>>> >> >>>> >> >>>> ## Reducibles >> >>>> >> >>>> A data source is called reducible if it implements the reducing >> >>>> protocol. >> >>>> Default implementations are provided for collections and streams. >> >>>> Additionally, blocks without an argument are reducible, too. >> >>>> This allows to adapt to custom data sources without additional >> effort. >> >>>> For example: >> >>>> >> >>>> "XStreams adaptor" >> >>>> xstream := filename reading. >> >>>> reducible := [[xstream get] on: Incomplete do: [Reduced >> signal]]. >> >>>> >> >>>> "natural numbers" >> >>>> n := 0. >> >>>> reducible := [n := n+1]. >> >>>> >> >>>> >> >>>> ## Transducers >> >>>> >> >>>> A transducer is an object that transforms a reducing function into >> >>>> another. >> >>>> Transducers encapsulate common steps in processing data sequences, >> such >> >>>> as >> >>>> map, filter, concatenate, and flatten. >> >>>> A transducer transforms a reducing function into another via >> #transform: >> >>>> in order to add those steps. >> >>>> They can be composed using #* which yields a new transducer that >> does >> >>>> both >> >>>> transformations. >> >>>> Most transducers require an argument, typically blocks, symbols or >> >>>> numbers: >> >>>> >> >>>> square := Map function: #squared. >> >>>> take := Take number: 1000. >> >>>> >> >>>> To facilitate compact notation, the argument types implement >> >>>> corresponding >> >>>> methods: >> >>>> >> >>>> squareAndTake := #squared map * 1000 take. >> >>>> >> >>>> Transducers requiring no argument are singletons and can be >> accessed >> by >> >>>> their class name. >> >>>> >> >>>> flattenAndDedupe := Flatten * Dedupe. >> >>>> >> >>>> >> >>>> >> >>>> # Advanced Concepts >> >>>> >> >>>> ## Data flows >> >>>> >> >>>> Processing a sequence of data can often be regarded as a data flow. >> >>>> The operator #<~ allows define a flow from a data source through >> >>>> processing steps to a drain. >> >>>> For example: >> >>>> >> >>>> squares := Set <~ 1000 take <~ #squared map <~ (1 to: 1000). >> >>>> fileOut writeStream <~ #isSeparator filter <~ fileIn >> readStream. >> >>>> >> >>>> In both examples #<~ is only used to set up the data flow using >> reducing >> >>>> functions and transducers. >> >>>> In contrast to streams, transducers are completely independent from >> >>>> input >> >>>> and output sources. >> >>>> Hence, we have a clear separation of reading data, writing data and >> >>>> processing elements. >> >>>> - Sources know how to iterate over data with a reducing function, >> e.g., >> >>>> via #reduce:init:. >> >>>> - Drains know how to collect data using a reducing function. >> >>>> - Transducers know how to process single elements. >> >>>> >> >>>> >> >>>> ## Reductions >> >>>> >> >>>> A reduction binds an initial value or a block yielding an initial >> value >> >>>> to >> >>>> a reducing function. >> >>>> The idea is to define a ready-to-use process that can be applied in >> >>>> different contexts. >> >>>> Reducibles handle reductions via #reduce: and #transduce:reduce: >> >>>> For example: >> >>>> >> >>>> sum := #+ init: 0. >> >>>> sum1 := #(1 1 1) reduce: sum. >> >>>> sum2 := (1 to: 1000) transduce: #odd filter reduce: sum. >> >>>> >> >>>> asSet := [:set :e | set add: e; yourself] initializer: [Set >> new]. >> >>>> set1 := #(1 1 1) reduce: asSet. >> >>>> set2 := #(1 to: 1000) transduce: #odd filter reduce: asSet. >> >>>> >> >>>> By combining a transducer with a reduction, a process can be >> further >> >>>> modified. >> >>>> >> >>>> sumOdds := sum <~ #odd filter >> >>>> setOdds := asSet <~ #odd filter >> >>>> >> >>>> >> >>>> ## Eductions >> >>>> >> >>>> An eduction combines a reducible data sources with a transducer. >> >>>> The idea is to define a transformed (virtual) data source that >> needs >> not >> >>>> to be stored in memory. >> >>>> >> >>>> odds1 := #odd filter <~ #(1 2 3) readStream. >> >>>> odds2 := #odd filter <~ (1 to 1000). >> >>>> >> >>>> Depending on the underlying source, eductions can be processed once >> >>>> (streams, e.g., odds1) or multiple times (collections, e.g., >> odds2). >> >>>> Since no intermediate data is stored, transducers actions are lazy, >> >>>> i.e., >> >>>> they are invoked each time the eduction is processed. >> >>>> >> >>>> >> >>>> >> >>>> # Origins >> >>>> >> >>>> Transducers is based on the same-named Clojure library and its >> ideas. >> >>>> Please see: >> >>>> http://clojure.org/transducers >> >>>> >> >>>> >> > >> >>

June 6, 2017

Re: [Pharo-users] Porting Transducers to Pharo

by Steffen MÃ¤rcker

Hi! >> If the need arises, we could of course factor the compact notation out >> into >> a separate package. >Good idea >[...] I do not want to help promoting a syntax that alienates me (and > others because other people reported the saem to me). I understand. Btw, I'd really, really appreciate if others post their thoughts and feedback here as well. Discussion helps moving things forward. =) >> (collection transduce map: #squared) take: 1000. > > To me this is much more readable. Well, I'll provide that extension once it is finished. > I cannot and do not want to use the other forms. >> collection transduce >> map: #squared; >> take: 1000. >> >> But as the message chain has to modify the underlying object >> (an eduction), very snaky side effects my occur. E.g., consider >> >> eduction := collection transduce. >> squared := eduction map: #squared. >> take := squared take: 1000. >> >> Now, all three variables hold onto the same object, which first squares >> all elements and than takes the first 1000. > > This is because the programmer did not understand what he did. No? Sure. ;-) Nevertheless, it would be very hard to debug. All of which are the reasons I wouldn't implement that variant. ;-) > PS: I played with infinite stream and iteration back in 1993 in CLOS. > Now I do not like to mix things because it breaks my flow of thinking. I am not sure whether I understand what your mean by mixing. Concerning transducers, the ability to handle infinite sources in only a (natural) side-effect of the ability to finish reductions before all elements are processed, e.g., like #detect: and such. Best, Steffen

June 6, 2017