[squeak-dev] Smalltalk and functional programming
Rob Withers
reefedjib at gmail.com
Tue Aug 24 13:19:39 UTC 2010
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" <frank.shearar at angband.za.org>
Sent: Tuesday, August 24, 2010 8:58 AM
To: "The general-purpose Squeak developers list"
<squeak-dev at lists.squeakfoundation.org>
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 at 0 x) or, if they're state-mutating, return a new object
> with the required state (0 at 0 translateBy: 1 at 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
>
>
More information about the Squeak-dev
mailing list
|