[squeak-dev] Smalltalk and functional programming

Alejandro F. Reimondo aleReimondo at smalltalking.net
Tue Aug 24 13:31:57 UTC 2010


> 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" <reefedjib at gmail.com>
To: "The general-purpose Squeak developers list" 
<squeak-dev at lists.squeakfoundation.org>
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" <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