We will kick you out if you send crap to this list. One more mail like that and you are out.
> On 01 Aug 2015, at 15:41, Kjell Godo <squeakl...@gmail.com> wrote: > > is there anybody > > here > > who knows both > > Haskell and Smalltalk ? > > Can Smalltalk benefit from > > functional ideas > > and > > Haskell's ideas about > > Immutability > > Currying > > Function composition and > > the State and IO Monads ? > > I like the way Haskell is now based on > > Category Theory > > which is the mathematics of > > function composition . > > Haskell was not always thus > > it had a > > pre Category Theory > > epoch . > > which apparently > > was a UM or > > Ugly Mess . > > Can these ideas be applied to > > Smalltalk? > > And would it be good? > > Can Smalltalk have a way of making a > > framework > > that has an > > API > > and is statically typed inside > > using a Haskell like type system? > > On Saturday, August 1, 2015, Kjell Godo <squeakl...@gmail.com > <mailto:squeakl...@gmail.com>> wrote: > > > On Monday, July 6, 2015, Eliot Miranda <eliot.mira...@gmail.com > <javascript:_e(%7B%7D,'cvml','eliot.mira...@gmail.com');>> wrote: > Hi Kjell, > > On Jul 6, 2015, at 6:16 AM, Kjell Godo <squeakl...@gmail.com <>> wrote: > >> Thank you for the detailed reply Andreas >> >> >> >> Are there any Smalltalk packages implementing >> >> Category Theory based >> >> functional programming constructs >> >> for function composition like >> >> functors , applicatives , monads , arrows , etc ? >> >> >> >> Do people have opinions about whether or not >> >> these plus immutable data structures would be good for managing state >> >> in Smalltalk like they do it in Haskell etc? i know that monads are not >> built >> >> into Haskell but are implemented as addons via Haskell packages. >> >> My Haskell friend said all you need to do functional programming is >> >> first class functions >> >> which Smalltalk Block contexts almost are except they lack their own stack? >> >> if you wrap a Block in a Function Object do you then get the stack >> >> effect so you can essentially call the Block recursively? > > The Pharo & Squeak dialects, along with most others, now have closures, so > blocks are fully recursive. > >> >> i have been wondering about taking a crack at implementing these >> >> in Smalltalk and i wonder if it would be >> >> theoretically possible >> >> to speed them up by inlining them via the Smalltalk compiler > > The compiler already inlines closures in a few key control messages such as > ifTrue: whileTrue: and:. > > > I recommend spending some time reading the code for the core execution > classes and the compiler, and running examples interactively to learn how > the system works. It's a fun process and well supported by the tools. > Remember that the debugger includes a meta circular interpreter for executing > the system's bytecode, and that the compiler compiles source to bytecode in > the firm of CompiledMethod instances you can inspect, decompile and list > their bytecode. > > All the questions you have above you can answer for yourself by running > examples and using the tools to observe what happens. This is a route to > mastering the system; IMNERHO the best. > > > is there any tutorial? > > how do i do this? > > >> Thank you > > Eliot (phone) > > >> On Saturday, November 8, 2014, Andreas Wacknitz <a.wackn...@gmx.de <>> wrote: >> >>> Am 07.11.2014 um 16:51 schrieb Kjell Godo <squeakl...@gmail.com <>>: >>> >>> This is off topic. >>> >>> I tried to post it as a top level thread but I have become unknown. >> Why do you expect that? Many people here are using Smalltalk for years. >> Just because you have been silent for some time doesn’t mean everybody will >> forget about you :) >> >>> >>> I don't know if you want this crap in here but I have decided not to wait >>> for the >>> >>> postmaster to get back to me on the subject of becoming known. Feel free. >>> >>> >>> >>> >>> >>> ( Original-SUBJECT: "( picoVerse-:( what about state , is state really >>> evil? ) )" ) >>> >>> >>> >>> >>> >>> >>> I am a Smalltalker. >>> >>> But in the past few months i have been running with the Haskellers. >>> >>> The Haskellers hate state. >>> >>> This seemed strange at first because as a Smalltalker i love(d) state. >>> State iswas my friend. >>> >>> 90% of my life as a Smalltalker is state wrangling. I am a state herder. >>> >>> The debugger is my staff I use to whack the state. And TestCase is my >>> sheep dog. >>> >>> But to the Haskellers >>> >>> state is >>> >>> the evil trinity >>> >>> of >>> >>> satan the anti christ and the false prophet >>> >>> all rolled into one. >>> >>> State is the true dev incarnation of the total catastrophe of development >>> Armageddon. >>> >>> Blood up to the bridles for hundreds of miles. Dogs and cats living >>> together. Mass hysteria. >>> >>> They say. >>> >>> I'm not sure i quite get it yet but they keep preaching on this one point >>> most of all. >>> >>> State is evil. >>> >>> You must keep all state in a Monad. As many methods/functions m as possible >>> >>> must be 100% dependent on the input parameters ONLY. >>> >>> No hidden instance variables affecting the return value of m are allowed. >>> >>> The only effect m can have is to return a value. >>> >>> If all this is true then m is pure. >>> >>> And pure is good. Pure is very good. And the wind says >>> >>> very. >>> >>> So i wonder if any of you fellow >>> >>> Smalltalkers >>> >>> have thought about this at all. >> >> First, there are no good definitions of what is an object oriented language >> and what is a functional language. >> Thus, languages like C++, C#, Java are being considered object oriented. But >> their object orientation is not the same like Smalltalk’s. >> The same problem exists in the functional language world: Some consider LISP >> being functional, some deny that. >> >> Second, for some years I am constantly seeking for „the best“ language to >> solve my problems in. Alas I wasn’t successful yet and don’t expect >> to be successful in the future. Every programming paradigm has its strengths >> and weaknesses when it comes to real world problems. >> So in my eyes it is best to know the different programming paradigms and its >> representative languages in order to be able to choose the >> best fitting language for your problem at hand. >> >> Third, there have been many attempts to create multi-paradigm languages >> (like C++, C#, Java, Scala, …). The idea behind is simple: combine >> the best characteristics. In my eyes all of them failed because what always >> have been created is Frankenstein’s monster. When you combine >> paradigms you will may get some advantages of all but sure you will get a >> lot of additional complexity. >> >> Fourth, it has been said many times before: What makes Smalltalk so nice is >> not only the language. It’s the whole system: the language, duck typing, >> the image (object world), the tools, the VM, the simplicity, the elegance, … >> And last but not least the communities around. >> >> Regards >> Andreas >> >> PS: If you are interested in functional programming and don’t like static >> typing you should have a look at Clojure. It has some nice ideas about >> how to deal with state concurrently. >> >> >> >>> Thanks >>> >>> Kjell E Godø >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> (((((((((( Maybe Smalltalk should be called Statewalk >>> >>> as in yak it up fuzz ball. )))))))))) >>> >>
