[squeak-dev] Smalltalk and functional programming

Alejandro F. Reimondo aleReimondo at smalltalking.net
Tue Aug 24 14:28:20 UTC 2010


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



-- 
Best regards,
Igor Stasenko AKA sig.






More information about the Squeak-dev mailing list