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 <merk...@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 > > > > > >
