A functional way to do local recursion or tail recursion is

[ :recurse | recurse value:o1 value:o2 value:recurse ]
     value:[ :v1 :v2 :recurse |...( recurse value:o3 value:o4 value:recurse
)...]

Also Object>>recurse: allows you to do recursion on anObject as easy as
>>do: etc do iteration

( anObject recurse:[ :anObject1 :recurse |
     ...( anObject1 children do:[ :child | …( recurse value:child )… ] ] )

I can show Object>>recurse: it’s really short if anyone is interested

On Fri, May 3, 2019 at 19:31 Kjell Godo <squeaklist at gmail.com> wrote:

> Traits could be used to do functional programming unless i am wrong.
>
> Separate a program into Traits and Objects<—-[ with just accessors ].
>
> So now the Objects become like a database layer or IO layer in functional
> programming. Maybe then the Object accessors might be nearer to the place
> of the IO Monad in Haskell parlance. So now you put all your working code
> into Traits which are pure functions as far as i can tell.
>
> And then you get a kind of functional programming effect.
>
> Now the compiler should have an easier time reasoning about the pure
> functional Trait code especially if the imperative style is not used. One
> way to go functional is to make all your local variables be BlockClosure
> inputs in not persisting Blocks as such input variables are immutable.
> Having the compiler optimize these >>value: calls away should be child’s
> play to where even i could do it. I believe i have a .pdf that tells how to
> do it. Or a new standardized idiom like
>
> o asLocal:[ :v | ... ].
> ( o1 ,, o2 , o3 )asLocals:[ :v1 :v2 :v3 | ... ]
>
> [ :v1 :v2 :v3 | ... ]value:o1 value:o2 value:o3
> could easily be optimized away and give the compiler access to simpler
> functional optimizations.
>
> What if some or all of the actual data in these Objects was somewhere else
> like in Clojure via FFI or COM or DCOM or sockets or d-Bus or named shared
> queues etc. Then you could get immutable.
>
> I have been itching to experiment with this. I made a Class that was like
> a Trait once in Pharo before i knew about Traits. If i had known about
> Traits i would have made it a Trait instead. It was about editing children
> and could be used anywhere there are children. Which is anywhere there is a
> mutable SequenceableCollection like thing really. You could also make one
> that is for immutable Sequences. So you could easily add this capability to
> anything that has children. Which i thought was cool. But then i turned
> around and did it the usual Smalltalk way. Leaving the Trait for later.
>
> But i definitely do not want Traits to go away unless i can load them back
> in.
>
> On Fri, May 3, 2019 at 16:47 Jakob Reschke <forums.jakob at resfarm.de>
> wrote:
>
>> I have another one:
>>
>> For several test cases I have to suppress the display of progress
>> (otherwise the tests would run much slower). To do that, I override
>> performTest to catch the relevant exceptions/notifications and mute them. I
>> need that in multiple test case classes, but I do not want to provide the
>> progress suppressing with an abstract test superclass. So I created a trait
>> that contains this performTest override. Test cases that need the progress
>> muted can mix that in by using the trait.
>>
>> Why don't I want the abstract superclass? Because I have two more such
>> traits for test cases: one that provides additional assert methods for a
>> certain type of object, and one that provides a method for suppressing
>> change notifications so the changes file is not cluttered that much when
>> the tests run. As traits I can mix in and combine these into test case
>> classes when they are required.
>>
>> The latter mentioned trait would benefit from a traits implementation
>> with state, though.
>>
>> Am So., 31. März 2019 um 21:21 Uhr schrieb Levente Uzonyi <
>> leves at caesar.elte.hu>:
>>
>>> On Sat, 30 Mar 2019, David T. Lewis wrote:
>>>
>>> > Changing the subject line to focus on Levente's question.
>>> >
>>> > On Thu, Mar 28, 2019 at 06:43:11PM +0100, Levente Uzonyi wrote:
>>> >>
>>> >> What are the current use cases for traits?
>>> >
>>> > In order to experiment with Git based repositories, I have loaded the
>>> > Tonel package from the github repositories of Jakob Reschke.
>>> >
>>> >       Installer ensureRecentMetacello.
>>> >       (Smalltalk classNamed: #Metacello) new
>>> >          repository: 'github://j4yk/tonel:squeak';
>>> >          baseline: 'Tonel';
>>> >          load.
>>> >
>>> > This brings in the FS-AnsiStreams package, which uses traits.
>>> >
>>> > Having traits in Squeak allows me to load this package.
>>>
>>> I haven't tried your snippet and I don't know which version of FS
>>> depends
>>> on Traits, but the one on SqueakSource definitely does not.
>>> Btw, Traits can be flattened, so it's possible to make it loadable into
>>> images with no Trait support.
>>>
>>> So far all use cases of Traits in this thread (and its parent) were
>>> about
>>> interfaces. Squeak doesn't have a concept for that, and Traits are
>>> definitely more than just simple interfaces (as long as you don't want
>>> to
>>> interface state). Perhaps we need interfaces instead of traits.
>>>
>>> Levente
>>>
>>> >
>>> > Dave
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190503/f8862ec8/attachment-0001.html>