Hi Phil,
thanks a lot for your effort and valuable input. I am having a look at
STIG for VW in the hope that I can set up a common repository for the VW
and Pharo version. Though, the next days I won't work on the port, because
I am quite busy at the moment.
Tell me how it goes for you.
I'll let you know soon.
I read your note about DoubleAgents for the tests, well, yeah this one we
do not have. I read about it on the blog of its maker and it looked
decent indeed.
I'll check whether a port is doable with reasonable effort and the
author's blessing. =)
Then look at the warnings. A bunch of them are non issues but there are
Undeclared things in need of a fix (e.g. IndexNotFoundError)
Luckily, most of them are straight forward to resolve. However, I'd really
like to hear your opinion on the name clash with #reduce: in the base (see
other thread). A solution could be to use double-dispatching (or similar)
to distinguish between the two cases
- reduce: aBlock, and
- reduce: aReduction
However, I have a slight preference to redefine #fold: and #reduce:, since
now (as far as I can see), they are redundant. E.g.,
- fold: aBlock "reduce as defined right now"
- reduce: aBlock init: "value "reduce starting with an initial value"
- reduce: aReduction "reduce with block and value from a reduction"
Kind regards,
Steffen
Best,
Phil
On Wed, Jun 7, 2017 at 11:29 AM, Steffen Märcker <merk...@web.de> wrote:
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
