Hi Phil,
that's great. I do have a GitHub account (merkste) but none at
SmalltalkHub. Is there a recommendable doc on how to use Git from Pharo?
Best, Steffen
Am .06.2017, 14:09 Uhr, schrieb p...@highoctane.be <p...@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 <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
