Re: Design Patterns and Functional programming

Dmitry A. Kazakov wrote:
On Mon, 09 Jul 2007 21:53:26 +0100, Jon Harrop wrote:
Did your calculator example implement Ada's grammar?

No, that is not Ada. The sample of Ada 95 expression is at the end of the
chapter 8:

http://www.dmitry-kazakov.de/ada/components.htm#8.9

Ok, I hadn't read the whole page. :-)

Further, diagnostics will be a mess...

Why do you believe that?

Because diagnostics is a side-effect,

You need to shed the idea that functional programming prohibits
side-effects. It does not.

while the result is a compiled
program. It does not fit into a purely functional model. You have to bend
your design or else face "states."

Absolutely. This never had anything to do with a purely functional model.
All of the code I posted was written in an impure functional language that
allows side effects.

Yep, you can trash them into the grammar, and in fact, people are doing
this all the time. But the result will most likely be an unreadable
mess,

You need to make a comparison before you can draw a justifiable
conclusion.

Look at the grammar of Ada 95, I gave you the link. It does that thing and
also handles many constraints at the grammar level. If you consider it
readable, then well, I take my hat off to you.

True.

Rewriter is defined as a function,

A pattern match.

No, a pattern match gives yes/no

What do you mean by this?

its OO equivalent would be again a function.

There is no OO equivalent to the pattern match.

I am not sure what you mean. In the solution space, an OO equivalent is:

Source'Class -- The class of sources
Pattern'Class -- The class of patterns

function Match (X : in out Source; Y : Pattern) return Boolean;

If you mean pattern matching as a language feature, then you should
elaborate why do you believe it essential.

Integrating pattern matching into a statically typed language allows
programs to be statically checked more thoroughly and greatly improves
performance by allowing pattern matches to be compiled and optimized
statically.

(I have some personal interest in pattern matching. There was a time I
worked much on it. If you are interested, see:

http://www.dmitry-kazakov.de/match/match.htm

At some point I came to conclusion that pattern matching is not an answer.
IMO it brings more problems than solves.)

Have you studied Wadler's views? These are implemented as "active patterns"
in F# and are very useful under certain circumstances. For example, you can
write active patterns that deconstruct XML documents directly from the .NET
representation. Then you can use pattern matching to manipulate XML
documents quickly and easily from F# code.

You could reach for a design
pattern but it will not provide the same static checking or performance
without an enormous amount of effort (essentially writing a pattern
matcher).

Hmm, I don't see an obvious connection between "pattern matching" and
"design patterns."

I'm assuming there are design patterns representing special cases of pattern
matching, just as there are design patterns representing special cases of
first-class functions.

I would like the see the an OO equivalent.

Functional decomposition is an integral part of OOP. [Many here would
probably disagree.]

Interesting.

But, what about sets of rewriters?

1. How would you describe a class of, with certain properties?

A higher-order function parameterized over the properties.

That means you need the properties being evaluated to certain values. This
looks very constraining. Consider a property of being non-zero everywhere
except at a finite number of points.

How a user of the class could design a program in terms of these
properties?

Apply the appropriate arguments.

That's too late. The whole idea is to know properties in advance during
design.

Both of these are addressed by parameterizing via a functor (a higher-order
module) rather than a higher-order function. A monadic style is another
alternative.

2. How would you extend / modify a rewriter?

Using a continuation.

That is same as composition. BTW, this is a great problem of many OO
languages too. They also use extension = composition with some epilogue
and prologues, or overriding. That is too limiting in many cases. A
typical example is dispatching constructors / destructors.

I don't really understand this. Can you give an example?

OO does not limit you here in any way.

With enough work you can solve the same problems with an OO design but
requiring 10x as much code to do the same thing is severely limiting in
practice.

I doubt it is a relation. It is rather a+b/x+b/x*x+... I would expect
that in a large project you will eventually have much *less* code in an
OOP variant than in a pure FP.

I think the only way we can justify a conclusion is by looking at some real
examples. Can you think of any equivalent compilers written in both
functional and OO styles? Prolog implementations, maybe.

If you give something away from FP and
OO-preachers do the same, then you will probably meet somewhere at the
optimum. Stateless design is a great advantage *when* appropriate.

I'm not advocating statelessness though, only first-class functions.

I don't either. But I see reasons when an object should better have a
state.

I agree. But why objects?

Because a value cannot have state. It is a state of something else.

Well, an immutable value cannot have state. Mutable values do, of course.

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

Relevant Pages

  • Re: Evolution is not random?
    ... Below is the definition that best meets my "intent". ... "intent" than the third or later definitions of a guiding agent. ... "optimize" is used in the pattern sense and not design sense right? ... pattern, not something that is different from "pattern". ...
    (talk.origins)
  • Re: Eleven questions Pitman refuses to answer. was Non-beneficial
    ... necessity of deliberate design behind most of the key differences. ... deliberate design without the need for common descent. ... The problem with that is that any pattern at all, or no pattern at all, ... If on the other hand we allow that anything can actually be rules, out, we can certainly rule out the idea that only design could result in a nested hierarchy, right? ...
    (talk.origins)
  • Re: Eleven questions Pitman refuses to answer. was Non-beneficial
    ... I've already discussed your ideas on the nested pattern with you ... to have the one that mimics exactly what we would see from common descent. ... But in fact you couldn't falsify design that way either. ... > combined with mindless natural selection can produce the vast variety ...
    (talk.origins)
  • Re: Pitmans Miller Time
    ... this evidence could equally be explained by common ... design and common descent. ... The real absence in the pattern is more than ... You have presented no metric of "level of functional complexity". ...
    (talk.origins)
  • Re: If SETI researchers were to take Noctilucas advise, they would pack up and go home
    ... For a pattern to count as a specification, ... recognized from our background knowledge of number theory---prime ... First because ID theory doesn't yield an inference of Intelligent ... Design all that easily contrary to the straw man erected by atheists ...
    (talk.origins)