Why is smalltalk not a functional programming language?

Question

With the renewed interest in functional programming languages, I\'ve seen some similitudes between Smalltalk and FPL, namely closures ( BlockClosures in Smalltalk ) Yet, Sm

Answer 1

Purely functional languages usually have immutable variables, making them more like the variables in a mathematical sense.

Answer 2

What would be needed to consider it as such?

• a way to declare functions rather than a way to declare methods in a class

• a way to structure a program around functions rather than around objects

@Missing Faktor - but isn't func in this example a named function?

|func v|
func := [:x | x + 1].
v := func value: 5.

No func is a local variable. You've bound an anonymous function to the local variable func.

|func v|
func := [:x | x + 1].
func := 2.
v := func value: 5.

To see the difference, look at this Erlang example which shows both an anonymous function and a named function.

Answer 3

Smalltalk might not be a "pure functional language" (whatever that might be). However, natural use of Smalltalk often results in functional code. (What I guess the Scala people would call "object-functional".)

For example, Squeak's Point class has a functional API: methods like 1@1 translateBy: 1@1 return new Points with the new state, instead of mutating internal state. (This makes Point practically immutable, since the only way to change the internal state of the object is through reflection mechanisms like #instVarAt:.)

It's quite normal to use higher order functions in Smalltalk like maps, filters, folds, and the like. Given that these are baked into the Collections API, it's often easier to write code that uses Collections in a functional way than not.

So many people have so many definitions of "functional programming language" that the question "is Foo a FPL" is as useless a question to ask as "is Foo an object oriented language".

Having said that, here's my two cents: a functional programming language is a language in which it is natural and idiomatic to employ functional techniques: first-class functions, avoidance of mutable state, side-effect free functions, higher-order functions.

By that description, Smalltalk is a functional programming language. It calls first-order functions "methods" or "blocks" depending on whether or they're named or anonymous. Objects store state in instance variables. Higher order functions are simply methods that take blocks as parameters.

Having said that, yes, you can write Smalltalk in a non-functional manner. It does allow for mutable state. Does that stop Smalltalk from being called a functional language? If so, neither are these languages functional: Common Lisp, Erlang (shared state through the process dictionary, ets/dets).

So, in brief, Smalltalk is an FPL because:

• Functions are first-class entities (objects, in Smalltalk - CompiledMethods or BlockClosures, to be precise).
• Smalltalk supports closures (it calls them blocks).
• Smalltalk allows one to write functionally in a natural, idiomatic manner.

and Smalltalk is not an FPL because:

• You as programmer must ensure that your data structures (objects) are immutable (by having setters/mutators return copies of the object with the mutated state).
• You as programmer must ensure that your methods (functions) are side-effect free.

(Some Smalltalks do apparently support immutable objects. My experience is limited to Squeak, which does not support VM-level immutability.)

Edit: I don't understand igouy's need for named function definitions other than through defining methods on an object. But anyway, here we go:

Smalltalk at: #func put: [:x | x + 1].
func value: 1.

Answer 4

A language does not become a functional language by having named functions - by that definition, C would be functional ! More important is the functional semantics in the mathematical sense, that the result depends on the arguments alone (in particular: no side effects). By this definition, objects which can be modified by setters are contrary to a functional programming style. However, as already pointed out, even objects can be used in a functional style (Rectangle example) if you forbid side effects. And, btw. there is a duality between objects with methods and a set of functions which are defined in a closure over a private state (see SICP for details). They can simulate each other mutually:

(def (make_foo initVal1 ... initValN)
   (let ((instVar1 initVal1) ... (instVarN initValN))
      (define (method1 args) ...)
      ...
      (define (methodN args) ...)
      (define (lookup selector)
          (cond ((eq? selector 'method1) method1)
             ...
             ((eq? selector 'methodN) methodN)
             (true doesNotUnderstandCode)))
      lookup)) ; returns the lookup function (provides "access into the closure") !

(defMacro (method1 receiver.args)
    ((receiver selector) args))

(define foo (make_foo 1 2 ...))
(method1 foo ...)

the above is a simulation of "pure" functional objects, and semantically the same as a lot of Smalltalk code! However, to implement a setter-method, you have to add a method which does a (set! instVar newValue). And, because set! is non-functional, breaks the "functionality" of the scheme.

Summary: look at the semantics, not the source, luke !

Answer 5

I've seen some similitudes between Smalltalk and FPL, namely closures

There's a more basic similarity - every Smalltalk message always returns a value.

But now look at the Design Principles Behind Smalltalk

[Smalltalk] sends the name of the desired operation, along with any arguments, as a message to the number, with the understanding that the receiver knows best how to carry out the desired operation.

Does that describe what you think of as Functional Programming?

@Frank Shearar - That describes Erlang too. Is Erlang now non-functional?

Erlang is something of a chimera - sequential programming is based on functions, but concurrent programming is based on message passing between processes. So Erlang is not multi paradigm or hybrid in the way that other languages allow different styles to be used to achieve the same purpose - it uses different styles for different purposes.

Answer 6

Programming with the Object Oriented paradigm is creating a program by identifying and modeling the Problem Domain Entities as objects, and then make them collaborate between themselves to solve each problem instance. Programming with the Functional paradigm is modeling the problem as a mathematical problem, and creating a mathematical function (by composing other functions) that for each problem instance, computes the problem solution.

In my opinion, a functional programming language is a language that given a solution for a problem solved using the functional programming paradigm, the language can express that solution exactly as it was thought. If you need to "transform" some part of your solution so it fits in what the language can express, then it doesn't fully support the paradigm you used to think the solution.

Smalltalk can express in most cases all the solutions created using the Object Oriented Programming paradigm, but it cannot expresss primitively a lot of solutions created using the Functional Programming paradigm. That's why I don't consider it a FPL. Despite not primitively be able to express every solution that a FPL can, Smalltalk is extremelly extensible, and you can extend it to be able to express all the solutions a FPL can.