Re: Design Patterns and Functional programming

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

Interestingly, that was a theoretical objection put forward when Lisp
adopted first-class closures several decades ago and has long been put to
rest. Like pattern matching and garbage collection, the benefits of
closures are now widely exploited.

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.

Free variables.

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.

Look up "paradigm" in a dictionary.

The point is that OOP simply includes FP as an integral part.

As you just said, OOP does not provide the core concept of FP: closures. So
there is clearly no merit in trying to claim that it "includes FP".

Your examples with using impure methods and mutable variables perfectly
*confirm* this point.

You are failing to distinguish between "purity" and "functional" again.

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

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

Does this imaginary type system have any bearing on reality?

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

I would say that dynamic and static typing are paradigms.

Huh, more efforts? What a perfect paradigm!

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

It is not.

Then why did you just refer to it as a "paradigm" in the previous sentence?

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...

Google for "pattern matching software".

What does a mutation make with "ref x"?

I do not understand your sentence.

--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?usenet
.

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: Design Patterns and Functional programming
    ... If you mean a programming style heavily relying on closures, then yes, ... This is why OOP can be integrated into functional languages. ... Yet a consistent type system would be able to describe either. ...
    (comp.object)
  • 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)