Yes, although it may sound like splitting hairs. You could say that
myCollection reduce: aBlock == myCollection allButFirst inject:
myCollection first into: aBlock.

So if you don't know whether your collection's empty, use
#inject:into:. But if you know for certain it's not empty, #reduce:
spares you a few key presses.

(Haskellers would call #reduce: foldl1, and they'd call #inject:into: foldl.)

frank

On 28 April 2013 18:20, Chris Muller <asqueaker at gmail.com> wrote:
> Is there any practical difference between #reduce: and #inject:into:?
>
> On Sun, Apr 28, 2013 at 4:35 AM, Frank Shearar <frank.shearar at gmail.com> wrote:
>> I don't really have the energy for re-arguing that point. In summary,
>> the primary argument against Smalltalk being an FPL is that the
>> community doesn't write functional code. Inefficient? Only because
>> noone's bothered making it efficient.
>>
>> So I'm not going to argue any further, and instead continue pushing
>> Squeak in the direction of writing code functionally.
>>
>> (Note that nothing in that SO argument even vaguely touches the actual
>> serious stuff, like "classes confound several issues that should be
>> orthogonal".)
>>
>> frank
>>
>> On 28 April 2013 01:13, Nicolas Cellier
>> <nicolas.cellier.aka.nice at gmail.com> wrote:
>>> Ah, yes, in a FPL it's another story...
>>> By the way Frank, sorry for
>>> http://stackoverflow.com/questions/3527753/why-is-smalltalk-not-a-functional-programming-language,
>>> Smalltalk if ever considered as a FPL, would not only be an impure FPL but
>>> also an inefficient one :(
>>>
>>>
>>> 2013/4/27 Levente Uzonyi <leves at elte.hu>
>>>>
>>>> On Sat, 27 Apr 2013, Frank Shearar wrote:
>>>>
>>>>> In Schlemiel's algorithm you have to traverse your string from the
>>>>> beginning. Here, the problem is that at every step you're making
>>>>> String after String after String that you just throw away.
>>>>>
>>>>> Unless perhaps you're suggesting that the Schlemielness comes from not
>>>>> doing things the way our particular garbage collector like to do
>>>>> things?
>>>>
>>>>
>>>> Your code looks right, and works well in a functional programming language
>>>> which has the required optimizations to run such code efficiently. But in
>>>> Smalltalk it creates 2n-1 intermediate strings, where the previous is the
>>>> prefix of the current one, so each one is longer than the previous, which
>>>> means that O(n^2) bytes are allocated, filled, read once, and then garbage
>>>> collected. This means that the runtime cost is also O(n^2).
>>>>
>>>>
>>>> Levente
>>>>
>>>>
>>>>>
>>>>> frank
>>>>>
>>>>> On 27 April 2013 22:08, Nicolas Cellier
>>>>> <nicolas.cellier.aka.nice at gmail.com> wrote:
>>>>>>
>>>>>> http://en.wikipedia.org/wiki/Schlemiel_the_Painter%27s_algorithm
>>>>>>
>>>>>>
>>>>>> 2013/4/27 <commits at source.squeak.org>
>>>>>>
>>>>>>> Levente Uzonyi uploaded a new version of Tests to project The Trunk:
>>>>>>> http://source.squeak.org/trunk/Tests-ul.200.mcz
>>>>>>>
>>>>>>> ==================== Summary ====================
>>>>>>>
>>>>>>> Name: Tests-ul.200
>>>>>>> Author: ul
>>>>>>> Time: 27 April 2013, 10:08:43.206 pm
>>>>>>> UUID: dfe70287-0768-42f9-97b7-d7ba6fbd6bb6
>>>>>>> Ancestors: Tests-fbs.199
>>>>>>>
>>>>>>> - avoid suboptimal string concatentation in ReleaseTest >>
>>>>>>> #testMethodsWithUnboundGlobals
>>>>>>>
>>>>>>> =============== Diff against Tests-fbs.199 ===============
>>>>>>>
>>>>>>> Item was changed:
>>>>>>>   ----- Method: ReleaseTest>>testMethodsWithUnboundGlobals (in category
>>>>>>> 'testing') -----
>>>>>>>   testMethodsWithUnboundGlobals
>>>>>>>         | unbound |
>>>>>>>         unbound := SystemNavigation default methodsWithUnboundGlobals.
>>>>>>>         Smalltalk cleanOutUndeclared.
>>>>>>> +       self assert: unbound isEmpty description: 'Unbound: ', unbound
>>>>>>> asCommaString!
>>>>>>> -       self assert: unbound isEmpty description: ('Unbound: ',
>>>>>>> (unbound
>>>>>>> reduce: [:acc :each | acc, ', ', each]))!
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>