<div><div dir="auto">A functional way to do local recursion or tail recursion is</div></div><div dir="auto"><br></div><div dir="auto">[ :recurse | recurse value:o1 value:o2 value:recurse ]</div><div dir="auto"> value:[ :v1 :v2 :recurse |...( recurse value:o3 value:o4 value:recurse )...]</div><div dir="auto"><br></div><div dir="auto">Also Object>>recurse: allows you to do recursion on anObject as easy as >>do: etc do iteration</div><div dir="auto"><br></div><div dir="auto">( anObject recurse:[ :anObject1 :recurse |</div><div dir="auto"> ...( anObject1 children do:[ :child | …( recurse value:child )… ] ] )</div><div dir="auto"><br></div><div dir="auto">I can show Object>>recurse: it’s really short if anyone is interested</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 3, 2019 at 19:31 Kjell Godo <<a href="mailto:squeaklist@gmail.com">squeaklist@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div dir="auto">Traits could be used to do functional programming unless i am wrong. </div><div dir="auto"><br></div><div dir="auto">Separate a program into Traits and Objects<—-[ with just accessors ]. </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">And then you get a kind of functional programming effect. </div><div dir="auto"><br></div><div dir="auto">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 </div><div dir="auto"><br></div><div dir="auto">o asLocal:[ :v | ... ].</div><div dir="auto">( o1 ,, o2 , o3 )asLocals:[ :v1 :v2 :v3 | ... ] </div><div dir="auto"><br></div><div dir="auto">[ :v1 :v2 :v3 | ... ]value:o1 value:o2 value:o3</div><div dir="auto">could easily be optimized away and give the compiler access to simpler functional optimizations.</div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">But i definitely do not want Traits to go away unless i can load them back in.</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 3, 2019 at 16:47 Jakob Reschke <<a href="mailto:forums.jakob@resfarm.de" target="_blank">forums.jakob@resfarm.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I have another one:<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>The latter mentioned trait would benefit from a traits implementation with state, though.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am So., 31. März 2019 um 21:21 Uhr schrieb Levente Uzonyi <<a href="mailto:leves@caesar.elte.hu" target="_blank">leves@caesar.elte.hu</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sat, 30 Mar 2019, David T. Lewis wrote:<br>
<br>
> Changing the subject line to focus on Levente's question.<br>
><br>
> On Thu, Mar 28, 2019 at 06:43:11PM +0100, Levente Uzonyi wrote:<br>
>> <br>
>> What are the current use cases for traits?<br>
><br>
> In order to experiment with Git based repositories, I have loaded the<br>
> Tonel package from the github repositories of Jakob Reschke.<br>
><br>
> Installer ensureRecentMetacello.<br>
> (Smalltalk classNamed: #Metacello) new<br>
> repository: 'github://j4yk/tonel:squeak';<br>
> baseline: 'Tonel';<br>
> load.<br>
><br>
> This brings in the FS-AnsiStreams package, which uses traits.<br>
><br>
> Having traits in Squeak allows me to load this package.<br>
<br>
I haven't tried your snippet and I don't know which version of FS depends <br>
on Traits, but the one on SqueakSource definitely does not.<br>
Btw, Traits can be flattened, so it's possible to make it loadable into <br>
images with no Trait support.<br>
<br>
So far all use cases of Traits in this thread (and its parent) were about <br>
interfaces. Squeak doesn't have a concept for that, and Traits are <br>
definitely more than just simple interfaces (as long as you don't want to <br>
interface state). Perhaps we need interfaces instead of traits.<br>
<br>
Levente<br>
<br>
><br>
> Dave<br>
<br>
</blockquote></div>
<br>
</blockquote></div></div>
</blockquote></div></div>