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.