Smalltalk and functional programming

> Hi,
>
> I'm engaged in a discussion with someone
> (http://stackoverflow.com/questions/3527753) on whether Smalltalk is or is
> not a functional programming language.
>
> Now admittedly no one in the argument has defined what exactly checkboxes
> a language needs to tick to qualify as an FPL. (Also, "Foo is/is not a
> Bar" discussions tend to generate more heat than light.)
>
> So at any rate, my position is that because it's natural and idiomatic to
> program in Smalltalk in a functional way (see Point class and the
> Collection API - #collect:, #select:, #reduce: and friends), yes,
> Smalltalk is a FPL.
>
> I'm not quite sure what position igouy holds. Or, rather, I know that he
> (I'll just use the English male pronouns here for brevity) says that
> Smalltalk's not a FPL, but I'm not sure why. He talks of there being no
> way to define named functions outside of a class as being the reason, but
> I'm sure that can't be all of it. (You can - Smalltalk at : #square put:
> [:x| x * x] - but that's hardly idiomatic.)
>
> At any rate, I've spent a while thinking about the matter, so I'm happy
> either way.
>
> It seems to me that the _real_ reason one might label Smalltalk as not
> being a FPL is mutable state.
>
> You can, with a smidge of discipline, happily write a functional object.
> But it's just as easy to write a mutable object.
>
> Point is a good example of a Value Object (aka "immutable state") as is,
> if I recall correctly, Rectangle: methods either return part of the state
> of an object (0@0 x) or, if they're state-mutating, return a new object
> with the required state (0@0 translateBy: 1@1). There's a mild hiccup
> here, where your "return a new object with new state" must initialise the
> new object. Point does this by having #setX:setY: in the 'private'
> category.
>
> But this discipline isn't enforced by the language/environment, which for
> some might be a necessary condition for FPL-ness.
>
> Or have I missed the point of what makes a language an FPL?
>
> frank
>
>

> You can write a Y-combinator in Smalltalk.  As you point out you can write
> Function objects.  You can do currying.  You can do eval.
>
> Smalltalk is a dynamic fuctional object-oriented language.
>
> Rob
>
> --------------------------------------------------
> From: "Frank Shearar" <[hidden email]>
> Sent: Tuesday, August 24, 2010 8:58 AM
> To: "The general-purpose Squeak developers list"
> <[hidden email]>
> Subject: [squeak-dev] Smalltalk and functional programming
>
>> Hi,
>>
>> I'm engaged in a discussion with someone
>> (http://stackoverflow.com/questions/3527753) on whether Smalltalk is or
>> is not a functional programming language.
>>
>> Now admittedly no one in the argument has defined what exactly checkboxes
>> a language needs to tick to qualify as an FPL. (Also, "Foo is/is not a
>> Bar" discussions tend to generate more heat than light.)
>>
>> So at any rate, my position is that because it's natural and idiomatic to
>> program in Smalltalk in a functional way (see Point class and the
>> Collection API - #collect:, #select:, #reduce: and friends), yes,
>> Smalltalk is a FPL.
>>
>> I'm not quite sure what position igouy holds. Or, rather, I know that he
>> (I'll just use the English male pronouns here for brevity) says that
>> Smalltalk's not a FPL, but I'm not sure why. He talks of there being no
>> way to define named functions outside of a class as being the reason, but
>> I'm sure that can't be all of it. (You can - Smalltalk at : #square put:
>> [:x| x * x] - but that's hardly idiomatic.)
>>
>> At any rate, I've spent a while thinking about the matter, so I'm happy
>> either way.
>>
>> It seems to me that the _real_ reason one might label Smalltalk as not
>> being a FPL is mutable state.
>>
>> You can, with a smidge of discipline, happily write a functional object.
>> But it's just as easy to write a mutable object.
>>
>> Point is a good example of a Value Object (aka "immutable state") as is,
>> if I recall correctly, Rectangle: methods either return part of the state
>> of an object (0@0 x) or, if they're state-mutating, return a new object
>> with the required state (0@0 translateBy: 1@1). There's a mild hiccup
>> here, where your "return a new object with new state" must initialise the
>> new object. Point does this by having #setX:setY: in the 'private'
>> category.
>>
>> But this discipline isn't enforced by the language/environment, which for
>> some might be a necessary condition for FPL-ness.
>>
>> Or have I missed the point of what makes a language an FPL?
>>
>> frank
>>
>>
>
>

>
>> Smalltalk is a dynamic fuctional object-oriented language.
>
> Smalltalk is a trayectory in time; it what happens to a body
> in-formation when it change through time ... and survives
> that "unique" experience.
> It is not it's "definition" nor it contents; because it can
> change while you are still trying to constrain it to a
> description.
> Relax and use the part of your smalltalk in the computer;
> but don't forget that there are other parts of your smalltalk
> (some parts outside computer and otehr parts seen
> only in retrospective -sometimes described as
> software evolution- ).
>
> have a good smalltalking day,
> Ale.
>
>
>
>
>
>
> ----- Original Message ----- From: "Rob Withers" <[hidden email]>
> To: "The general-purpose Squeak developers list" <[hidden email]>
> Sent: Tuesday, August 24, 2010 10:19 AM
> Subject: Re: [squeak-dev] Smalltalk and functional programming
>
>
>> You can write a Y-combinator in Smalltalk.  As you point out you can write Function objects.  You can do currying.  You can do eval.
>>
>> Smalltalk is a dynamic fuctional object-oriented language.
>>
>> Rob
>>
>> --------------------------------------------------
>> From: "Frank Shearar" <[hidden email]>
>> Sent: Tuesday, August 24, 2010 8:58 AM
>> To: "The general-purpose Squeak developers list" <[hidden email]>
>> Subject: [squeak-dev] Smalltalk and functional programming
>>
>>> Hi,
>>>
>>> I'm engaged in a discussion with someone (http://stackoverflow.com/questions/3527753) on whether Smalltalk is or is not a functional programming language.
>>>
>>> Now admittedly no one in the argument has defined what exactly checkboxes a language needs to tick to qualify as an FPL. (Also, "Foo is/is not a Bar" discussions tend to generate more heat than light.)
>>>
>>> So at any rate, my position is that because it's natural and idiomatic to program in Smalltalk in a functional way (see Point class and the Collection API - #collect:, #select:, #reduce: and friends), yes, Smalltalk is a FPL.
>>>
>>> I'm not quite sure what position igouy holds. Or, rather, I know that he (I'll just use the English male pronouns here for brevity) says that Smalltalk's not a FPL, but I'm not sure why. He talks of there being no way to define named functions outside of a class as being the reason, but I'm sure that can't be all of it. (You can - Smalltalk at : #square put: [:x| x * x] - but that's hardly idiomatic.)
>>>
>>> At any rate, I've spent a while thinking about the matter, so I'm happy either way.
>>>
>>> It seems to me that the _real_ reason one might label Smalltalk as not being a FPL is mutable state.
>>>
>>> You can, with a smidge of discipline, happily write a functional object. But it's just as easy to write a mutable object.
>>>
>>> Point is a good example of a Value Object (aka "immutable state") as is, if I recall correctly, Rectangle: methods either return part of the state of an object (0@0 x) or, if they're state-mutating, return a new object with the required state (0@0 translateBy: 1@1). There's a mild hiccup here, where your "return a new object with new state" must initialise the new object. Point does this by having #setX:setY: in the 'private' category.
>>>
>>> But this discipline isn't enforced by the language/environment, which for some might be a necessary condition for FPL-ness.
>>>
>>> Or have I missed the point of what makes a language an FPL?
>>>
>>> frank
>>>
>>>
>>
>
>
>

> Relax and use the part of your smalltalk in the computer;
> but don't forget that there are other parts of your smalltalk
> (some parts outside computer and otehr parts seen
> only in retrospective -sometimes described as
> software evolution- ).
>
> have a good smalltalking day,
> Ale.
>
>
>
>
>
>
> ----- Original Message ----- From: "Rob Withers" <[hidden email]>
> To: "The general-purpose Squeak developers list"
> <[hidden email]>
> Sent: Tuesday, August 24, 2010 10:19 AM
> Subject: Re: [squeak-dev] Smalltalk and functional programming
>
>
>> You can write a Y-combinator in Smalltalk.  As you point out you can write
>> Function objects.  You can do currying.  You can do eval.
>>
>> Smalltalk is a dynamic fuctional object-oriented language.
>>
>> Rob
>>
>> --------------------------------------------------
>> From: "Frank Shearar" <[hidden email]>
>> Sent: Tuesday, August 24, 2010 8:58 AM
>> To: "The general-purpose Squeak developers list"
>> <[hidden email]>
>> Subject: [squeak-dev] Smalltalk and functional programming
>>
>>> Hi,
>>>
>>> I'm engaged in a discussion with someone
>>> (http://stackoverflow.com/questions/3527753) on whether Smalltalk is or is
>>> not a functional programming language.
>>>
>>> Now admittedly no one in the argument has defined what exactly checkboxes
>>> a language needs to tick to qualify as an FPL. (Also, "Foo is/is not a Bar"
>>> discussions tend to generate more heat than light.)
>>>
>>> So at any rate, my position is that because it's natural and idiomatic to
>>> program in Smalltalk in a functional way (see Point class and the Collection
>>> API - #collect:, #select:, #reduce: and friends), yes, Smalltalk is a FPL.
>>>
>>> I'm not quite sure what position igouy holds. Or, rather, I know that he
>>> (I'll just use the English male pronouns here for brevity) says that
>>> Smalltalk's not a FPL, but I'm not sure why. He talks of there being no way
>>> to define named functions outside of a class as being the reason, but I'm
>>> sure that can't be all of it. (You can - Smalltalk at : #square put: [:x| x
>>> * x] - but that's hardly idiomatic.)
>>>
>>> At any rate, I've spent a while thinking about the matter, so I'm happy
>>> either way.
>>>
>>> It seems to me that the _real_ reason one might label Smalltalk as not
>>> being a FPL is mutable state.
>>>
>>> You can, with a smidge of discipline, happily write a functional object.
>>> But it's just as easy to write a mutable object.
>>>
>>> Point is a good example of a Value Object (aka "immutable state") as is,
>>> if I recall correctly, Rectangle: methods either return part of the state of
>>> an object (0@0 x) or, if they're state-mutating, return a new object with
>>> the required state (0@0 translateBy: 1@1). There's a mild hiccup here, where
>>> your "return a new object with new state" must initialise the new object.
>>> Point does this by having #setX:setY: in the 'private' category.
>>>
>>> But this discipline isn't enforced by the language/environment, which for
>>> some might be a necessary condition for FPL-ness.
>>>
>>> Or have I missed the point of what makes a language an FPL?
>>>
>>> frank
>>>
>>>
>>
>>
>
>
>
>

> Relax and use the part of your smalltalk in the computer;
> but don't forget that there are other parts of your smalltalk
> (some parts outside computer and otehr parts seen
> only in retrospective -sometimes described as
> software evolution- ).
>
> have a good smalltalking day,
> Ale.
>
>
>
>
>
>
> ----- Original Message ----- From: "Rob Withers" <[hidden email]>
> To: "The general-purpose Squeak developers list"
> <[hidden email]>
> Sent: Tuesday, August 24, 2010 10:19 AM
> Subject: Re: [squeak-dev] Smalltalk and functional programming
>
>
>> You can write a Y-combinator in Smalltalk. As you point out you can write
>> Function objects. You can do currying. You can do eval.
>>
>> Smalltalk is a dynamic fuctional object-oriented language.
>>
>> Rob
>>
>> --------------------------------------------------
>> From: "Frank Shearar" <[hidden email]>
>> Sent: Tuesday, August 24, 2010 8:58 AM
>> To: "The general-purpose Squeak developers list"
>> <[hidden email]>
>> Subject: [squeak-dev] Smalltalk and functional programming
>>
>>> Hi,
>>>
>>> I'm engaged in a discussion with someone
>>> (http://stackoverflow.com/questions/3527753) on whether Smalltalk is or
>>> is
>>> not a functional programming language.
>>>
>>> Now admittedly no one in the argument has defined what exactly
>>> checkboxes
>>> a language needs to tick to qualify as an FPL. (Also, "Foo is/is not a
>>> Bar"
>>> discussions tend to generate more heat than light.)
>>>
>>> So at any rate, my position is that because it's natural and idiomatic
>>> to
>>> program in Smalltalk in a functional way (see Point class and the
>>> Collection
>>> API - #collect:, #select:, #reduce: and friends), yes, Smalltalk is a
>>> FPL.
>>>
>>> I'm not quite sure what position igouy holds. Or, rather, I know that he
>>> (I'll just use the English male pronouns here for brevity) says that
>>> Smalltalk's not a FPL, but I'm not sure why. He talks of there being no
>>> way
>>> to define named functions outside of a class as being the reason, but
>>> I'm
>>> sure that can't be all of it. (You can - Smalltalk at : #square put:
>>> [:x| x
>>> * x] - but that's hardly idiomatic.)
>>>
>>> At any rate, I've spent a while thinking about the matter, so I'm happy
>>> either way.
>>>
>>> It seems to me that the _real_ reason one might label Smalltalk as not
>>> being a FPL is mutable state.
>>>
>>> You can, with a smidge of discipline, happily write a functional object.
>>> But it's just as easy to write a mutable object.
>>>
>>> Point is a good example of a Value Object (aka "immutable state") as is,
>>> if I recall correctly, Rectangle: methods either return part of the
>>> state of
>>> an object (0@0 x) or, if they're state-mutating, return a new object
>>> with
>>> the required state (0@0 translateBy: 1@1). There's a mild hiccup here,
>>> where
>>> your "return a new object with new state" must initialise the new
>>> object.
>>> Point does this by having #setX:setY: in the 'private' category.
>>>
>>> But this discipline isn't enforced by the language/environment, which
>>> for
>>> some might be a necessary condition for FPL-ness.
>>>
>>> Or have I missed the point of what makes a language an FPL?
>>>
>>> frank
>>>
>>>
>>
>>
>
>
>
>

> Hi Igor,
>
>> Yup. What makes smalltalk to be smalltalk is
>> an evironment of live objects,
>
> [I have not made any relationship with life.
> I don´t know what "life of an object" is :-) ]
>
>> not its syntax or rules (because they can be easily
>> changed at run-time).
>
> The preservation of it identity.
> As a system it is defined as something that
> when ovserved through time preserves identity.
> (it is also the only caracteristic of anObject
> that distinguish as an object and not been
> only "something" )
>
> Ale.
>

>
>
>
> ----- Original Message ----- From: "Igor Stasenko" <[hidden email]>
> To: "The general-purpose Squeak developers list"
> <[hidden email]>
> Sent: Tuesday, August 24, 2010 10:47 AM
> Subject: Re: [squeak-dev] Smalltalk and functional programming
>
>
> On 24 August 2010 16:31, Alejandro F. Reimondo
> <[hidden email]> wrote:
>>
>>> Smalltalk is a dynamic fuctional object-oriented language.
>>
>> Smalltalk is a trayectory in time; it what happens to a body
>> in-formation when it change through time ... and survives
>> that "unique" experience.
>> It is not it's "definition" nor it contents; because it can
>> change while you are still trying to constrain it to a
>> description.
>
> Yup. What makes smalltalk to be smalltalk is an evironment of live objects,
> not its syntax or rules (because they can be easily changed at run-time).
>
>> Relax and use the part of your smalltalk in the computer;
>> but don't forget that there are other parts of your smalltalk
>> (some parts outside computer and otehr parts seen
>> only in retrospective -sometimes described as
>> software evolution- ).
>>
>> have a good smalltalking day,
>> Ale.
>>
>>
>>
>>
>>
>>
>> ----- Original Message ----- From: "Rob Withers" <[hidden email]>
>> To: "The general-purpose Squeak developers list"
>> <[hidden email]>
>> Sent: Tuesday, August 24, 2010 10:19 AM
>> Subject: Re: [squeak-dev] Smalltalk and functional programming
>>
>>
>>> You can write a Y-combinator in Smalltalk. As you point out you can write
>>> Function objects. You can do currying. You can do eval.
>>>
>>> Smalltalk is a dynamic fuctional object-oriented language.
>>>
>>> Rob
>>>
>>> --------------------------------------------------
>>> From: "Frank Shearar" <[hidden email]>
>>> Sent: Tuesday, August 24, 2010 8:58 AM
>>> To: "The general-purpose Squeak developers list"
>>> <[hidden email]>
>>> Subject: [squeak-dev] Smalltalk and functional programming
>>>
>>>> Hi,
>>>>
>>>> I'm engaged in a discussion with someone
>>>> (http://stackoverflow.com/questions/3527753) on whether Smalltalk is or
>>>> is
>>>> not a functional programming language.
>>>>
>>>> Now admittedly no one in the argument has defined what exactly
>>>> checkboxes
>>>> a language needs to tick to qualify as an FPL. (Also, "Foo is/is not a
>>>> Bar"
>>>> discussions tend to generate more heat than light.)
>>>>
>>>> So at any rate, my position is that because it's natural and idiomatic
>>>> to
>>>> program in Smalltalk in a functional way (see Point class and the
>>>> Collection
>>>> API - #collect:, #select:, #reduce: and friends), yes, Smalltalk is a
>>>> FPL.
>>>>
>>>> I'm not quite sure what position igouy holds. Or, rather, I know that he
>>>> (I'll just use the English male pronouns here for brevity) says that
>>>> Smalltalk's not a FPL, but I'm not sure why. He talks of there being no
>>>> way
>>>> to define named functions outside of a class as being the reason, but
>>>> I'm
>>>> sure that can't be all of it. (You can - Smalltalk at : #square put:
>>>> [:x| x
>>>> * x] - but that's hardly idiomatic.)
>>>>
>>>> At any rate, I've spent a while thinking about the matter, so I'm happy
>>>> either way.
>>>>
>>>> It seems to me that the _real_ reason one might label Smalltalk as not
>>>> being a FPL is mutable state.
>>>>
>>>> You can, with a smidge of discipline, happily write a functional object.
>>>> But it's just as easy to write a mutable object.
>>>>
>>>> Point is a good example of a Value Object (aka "immutable state") as is,
>>>> if I recall correctly, Rectangle: methods either return part of the
>>>> state of
>>>> an object (0@0 x) or, if they're state-mutating, return a new object
>>>> with
>>>> the required state (0@0 translateBy: 1@1). There's a mild hiccup here,
>>>> where
>>>> your "return a new object with new state" must initialise the new
>>>> object.
>>>> Point does this by having #setX:setY: in the 'private' category.
>>>>
>>>> But this discipline isn't enforced by the language/environment, which
>>>> for
>>>> some might be a necessary condition for FPL-ness.
>>>>
>>>> Or have I missed the point of what makes a language an FPL?
>>>>
>>>> frank
>>>>
>>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>
>
>
>

> Rob,
>
> On Tue, Aug 24, 2010 at 3:19 PM, Rob Withers<[hidden email]>  wrote:
>> Smalltalk is a dynamic fuctional object-oriented language.
>
> you forgot "imperative" and, hey, since you can implement Prolog in
> it, "logic". ;-) Sorry for the sarcasm, but Turing completeness just
> bites. (Yes, it's a bottom argument, but this kind of question just
> calls for it.)
>
> If someone'd ask me, I'd respond that Smalltalk is IMHO not a
> functional language. What is the primary means of abstraction at work
> in Smalltalk? Not functions, right?
>
> The other way around, would you agree that, uh, Haskell is an
> object-oriented language because you can somehow emulate objects and
> state using monads?

> Rob,
>
> On Tue, Aug 24, 2010 at 3:19 PM, Rob Withers <[hidden email]> wrote:
>> Smalltalk is a dynamic fuctional object-oriented language.
>
> you forgot "imperative" and, hey, since you can implement Prolog in
> it, "logic". ;-) Sorry for the sarcasm, but Turing completeness just
> bites. (Yes, it's a bottom argument, but this kind of question just
> calls for it.)
>
> If someone'd ask me, I'd respond that Smalltalk is IMHO not a
> functional language. What is the primary means of abstraction at work
> in Smalltalk? Not functions, right?
>
> The other way around, would you agree that, uh, Haskell is an
> object-oriented language because you can somehow emulate objects and
> state using monads?
>
> Best,
>
> Michael
>
>

> On 2010/08/24 15:27, Michael Haupt wrote:
>> Rob,
>>
>> On Tue, Aug 24, 2010 at 3:19 PM, Rob Withers<[hidden email]>  wrote:
>>> Smalltalk is a dynamic fuctional object-oriented language.
>>
>> you forgot "imperative" and, hey, since you can implement Prolog in
>> it, "logic". ;-) Sorry for the sarcasm, but Turing completeness just
>> bites. (Yes, it's a bottom argument, but this kind of question just
>> calls for it.)
>>
>> If someone'd ask me, I'd respond that Smalltalk is IMHO not a
>> functional language. What is the primary means of abstraction at work
>> in Smalltalk? Not functions, right?
>>
>> The other way around, would you agree that, uh, Haskell is an
>> object-oriented language because you can somehow emulate objects and
>> state using monads?
>
> Well, that's the thing. If you tried to write OO in Haskell, you'd fight
> the language, right? It's not natural to use Haskell to write OO.
> Similarly, you don't write OO in C because it _hurts_.
>
> On the other hand, while clearly not a pure functional language like
> Haskell, it's not hard - it's _easy_ - to write in a functional manner.
>
> Languages support certain ways of working better than others. Smalltalk
> seems to support working in a functional manner rather well. (In contrast,
> try doing so in Delphi. I don't recommend it.)
>
> (Everything in Common Lisp is an object, so is that not an FPL anymore?)
>
> So, in my book, if a tool's good for hitting things, it's a hammer.
> Whether that hammer has a metal end and a wooden handle, or a rock, I
> don't really care.
>
> Saying that Smalltalk isn't an FPL because its functions all happen to be
> associated with a class just seems foolish to me.
>
> At any rate, it seems I'm relatively alone in thinking this way, which is
> fine by me.
>
> frank
>
>

> Le 24/08/2010 20:07, Chris Cunnington a écrit :
>> Perhaps somebody would be willing to show a piece of code written in a
>> functional style?
>>
>> This was presented but then quickly dismissed: Smalltalk at: #square
>> put: [: x| x * x ]
>>
>>
>> Chris
>
> | f g h |
>
> f := Lambda m position: 100 @ 100.
> g := Lambda m color: Color red.
> h := Lambda m openInWorld.
>
> h <~ Morph new. "shows a Morph"
> h <= g <~ Morph new. "shows a red Morph".
> h <= g <= f <~ Morph new. "shows a red Morph at 100 @ 100".
>
>
> ... more about this at:
> http://www.zogotounga.net/comp/squeak/functionaltalk.htm
>
>
> Stef
>