Re: Design Patterns and Functional programming
- From: "Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx>
- Date: Mon, 16 Jul 2007 09:55:21 +0200
On Mon, 16 Jul 2007 00:57:50 +0100, Jon Harrop wrote:
Like pattern matching and garbage collection, the benefits of
closures are now widely exploited.
LOL. In other subthreads you were pressing on checks. Neither from above is
statically checkable. Consider a trivial pattern "A"|"AA". What is wrong
with it? Now observe that for two patterns P1 and P2 it is at least halting
problem to determine whether the sets of strings matched by them intersect.
As for GC, everything is clear, right? Upward closures require GC and see
below.
As you just said, OOP does not provide the core concept of FP: closures.
Where I did that?
Your examples with using impure methods and mutable variables perfectly
*confirm* this point.
You are failing to distinguish between "purity" and "functional" again.
I am not. It wasn't my objective to define "functional." My expectation was
that you would. What I can summarize from the rant:
1. Purity is not characteristic
2. Downward closures aren't either, as they are supported
3. Upward closures?
So the paradigm you propose is to consequently pass local functions up
messing the contexts? Not that this were impossible to have in an OOPL. The
question is why. Further, how are you going to reconcile this mess with
static typing. Consider this:
function Mess return ??? is
type Foo is ...;
Object : Foo; -- Local object of the type Foo
function Upward_Closure return Foo is
begin
Object := Object + 1;
return Object;
end Upward_Closure;
begin
return Upward_Closure;
end Mess;
Observe that Object and its type outlive the scope of the context of Mess.
What is the type of result of Mess? You need first-class objects of types
and types of types to handle this. Then what about closures bearing objects
of types of types with them? And so on. This is fundamentally inconsistent
with a sane types system.
What does a mutation make with "ref x"?
I do not understand your sentence.
You don't know what a mutation of a value is supposed to mean? I guess "to
mutate" = "to undergo or cause to undergo mutation." Or there is a
different Pickwickian sense you are using?
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.
- Follow-Ups:
- Re: Design Patterns and Functional programming
- From: Jon Harrop
- Re: Design Patterns and Functional programming
- References:
- Design Patterns and Functional programming
- From: Jon Harrop
- Re: Design Patterns and Functional programming
- From: Dmitry A. Kazakov
- Re: Design Patterns and Functional programming
- From: Jon Harrop
- Re: Design Patterns and Functional programming
- From: Dmitry A. Kazakov
- Re: Design Patterns and Functional programming
- From: Jon Harrop
- Re: Design Patterns and Functional programming
- From: Dmitry A. Kazakov
- Re: Design Patterns and Functional programming
- From: Jon Harrop
- Re: Design Patterns and Functional programming
- From: Dmitry A. Kazakov
- Re: Design Patterns and Functional programming
- From: Jon Harrop
- Re: Design Patterns and Functional programming
- From: Dmitry A. Kazakov
- Re: Design Patterns and Functional programming
- From: Jon Harrop
- Re: Design Patterns and Functional programming
- From: Dmitry A. Kazakov
- Re: Design Patterns and Functional programming
- From: Jon Harrop
- Re: Design Patterns and Functional programming
- From: Dmitry A. Kazakov
- Re: Design Patterns and Functional programming
- From: Jon Harrop
- Re: Design Patterns and Functional programming
- From: Dmitry A. Kazakov
- Re: Design Patterns and Functional programming
- From: Dmitry A. Kazakov
- Re: Design Patterns and Functional programming
- From: Jon Harrop
- Design Patterns and Functional programming
- Prev by Date: re: Design Patterns and Functional programming
- Next by Date: Re: Design Patterns and Functional programming
- Previous by thread: Re: Design Patterns and Functional programming
- Next by thread: Re: Design Patterns and Functional programming
- Index(es):
Relevant Pages
|