Re: Design Patterns and Functional programming

On Sun, 15 Jul 2007 00:24:14 +0100, in comp.object you wrote:

Dmitry A. Kazakov wrote:
On Sat, 14 Jul 2007 03:25:12 +0100, Jon Harrop wrote:

However, it says nothing of the differences between paradigms, which is
important if you give yourself that choice.

Because there is no any difference.

Closures.

1. Closures, especially downward ones are supported in OOPLs with local
functions. Upward ones should never be used anyway.

2. If you mean a programming style heavily relying on closures, then yes,
it is depreciated because often it assumes references to non-contracted
contextual things. Non-contracted = neither an argument, nor a result. In
this narrow sense closures were opposite to DbC. But I fail to see a
paradigm here. Sloppiness is not a paradigm.

With regard to "OOP allowing functional decomposition", OOP adds nothing
to ordinary procedural programming with function pointers. In particular,
neither provide first-class lexical closures.

There is nothing in OOP which should preclude typed functions and the
constant values of. One could even allow functional variables if one
wished.

Yes. This is why OOP can be integrated into functional languages. OCaml and
OOHaskell did this.

If OOP and FP were different paradigms, one would be unable to mix them.
The point is that OOP simply includes FP as an integral part. Your examples
with using impure methods and mutable variables perfectly *confirm* this
point.

So the important question is "what does OO provide that other paradigms
do not?". I can think of only one thing: covariance and contravariance.

It provides (requires) a consistent type system.

Smalltalk and C++ have wildly different type systems, for example.

Yet a consistent type system would be able to describe either. Note that

1. any dynamic types system is a case of some more general static types
system with single class.

2. no fully dynamic types system is consistent - there always exist some
objects of statically known types.

Same as with OOP vs FP, dynamic vs. static is not a paradigm choice.

Given enough effort, the performance may be recoverable, yes.

Huh, more efforts? What a perfect paradigm!

I wouldn't refer to the use of "const" in C as a "paradigm".

It is not. It is a design fault. "const" [subtype mark] should have been
the default. While to get anything mutable one should be forced to use
"var" [subtype mark].

My point was not about popularity ... pattern decomposition is hard

The popularity of pattern matching shows that many people do not find
it "hard".

Alas. People don't find C++ hard, then they start projects like an
automated baggage-handling system for Denver airport. Perhaps, if they also
used pattern matching, the project would collapse a bit sooner, saving some
money...

The type is denoted:

'a ref

the value is denoted:

ref x

And these type and value are different from the type and the value the
reference points to. No ticks! (:-))

Yes. The type and value referred to are "'a" and "x", respectively.

So, returning to "mutable values," neither "x" nor "ref x" are mutable.

"ref x" is mutable.

What does a mutation make with "ref x"? I presume x there is a value. Let's
take a more obvious value 123 instead. So mutating "ref 123", what is this?

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.

Relevant Pages

  • Re: Function minimization and random numbers
    ... Well, .NET's type system makes the distinction, allowing conversions ... Groovy supports overloaded method groups as closures, ... Consider a language that support integers but imposes a compile time ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Function minimization and random numbers
    ... minor point, but surely the CLR spec defines the type system, not the ... it doesn't actually impose anything on your type system. ... You look at a member invocation: ... be second-class closures because you cannot manipulate all functions in the ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Function minimization and random numbers
    ... Well, .NET's type system makes the distinction, allowing conversions ... lacks closures. ... design but it culminated in F# rather than delegates. ... Are you claiming that the C# support for closures is useless? ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Design Patterns and Functional programming
    ... closures are now widely exploited. ... If OOP and FP were different paradigms, one would be unable to mix them. ... Yet a consistent type system would be able to describe either. ... also used pattern matching, the project would collapse a bit sooner, ...
    (comp.object)