Re: Design Patterns and Functional programming

On Tue, 10 Jul 2007 18:17:01 +0100, Jon Harrop wrote:

Dmitry A. Kazakov wrote:

Because diagnostics is a side-effect,

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

? If side effect is functional, then I don't what to say. At least it
implies that assignment is functional too.

Absolutely. This never had anything to do with a purely functional model.

This raises questions. What is left? How much functional is impurely
functional? Why impurity is needed? How much of impurity one would require
in an average project?

Rewriter is defined as a function,

A pattern match.

No, a pattern match gives yes/no

What do you mean by this?

Pattern is a function which takes a chain of letters from some alphabet and
yields true or false. When the result is true, it is said that the pattern
matches the chain.

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.

Why? What is the subject of matching. Some strings (the program processes),
or the program's source code? In either case I see no relation to static
typing. Maybe you mean types matching?

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.

Looks like fighting some architectural problems to me...

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.

It is a too wide stretch, and I think it is wrong. The whole idea of
pattern matching is to ignore the semantics of the thing being analysed. In
some cases it gives you an advantage of doing the job quickly without much
clutter. When we talk about design patterns, the idea is quite opposite.
Design patterns heavily rely on the semantics while trying to ignore any
syntactical differences.

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.

I.e. by screwing the paradigm.

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?

The problem is, to dispatch to some virtual method from the constructor. In
terms of functional decomposition you need to inject some code into the
body of another function, here a constructor. The problem is that at this
point the object is still under construction, so you cannot pass to object
to the target. It can only be solved by proper typing.

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.

You need somebody to pay for such study. A typical software maintenance
period is 20+ years. Then you will know the answer, which probably nobody
will hear anyway.

Actually it is much simpler. Ask you senator to pass a law making
no-warranty licenses illegal. You will be amazed how quickly the number of
languages will reduce.

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.

Oh, that is OK. Surely subroutines have to be ADTs. Why do you think that
this would be anti-OO?

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.

No, there is no such thing as a mutable value. Mutable can be a variable,
parameter, object. They are functions mapping execution states onto values.
Switching states just selects another value without changing them.

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

Relevant Pages

  • Re: Win App Development Program Structure
    ... But I would stress more about the TDD. ... Also look into a particular design pattern called "Model View Presenter ... I would suggest reading a couple of books on design patterns. ... I have been developing custom apps ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Expert of Design Patterns
    ... You need to READ the pattern specified by another and interpret it. ... rather context evaluation. ... design patterns can be expected, by definition, to make good choices about ...
    (comp.object)
  • Re: MooTools: An Objective Look
    ... What design patterns in Mootools were criticized? ... host objects were the design patterns I have been commenting on in this ... A design pattern is a reusable solution to a problem in a context. ... So if this is a pattern, we could look at the goals, usage, and constraints in Mootools. ...
    (comp.lang.javascript)
  • Re: Why i dont switch to Lisp
    ... I would argue that a design pattern which is invisible actually /isn't/ ... there, and as evidence, I would cite its very invisibility. ... them to the restrictions of the language. ... the way design patterns are presented reinforces the ...
    (comp.lang.lisp)
  • Re: Regular Expression AND mach
    ... There are, of course, many exceptions, but the pattern is ... "Length-Frequency Statistics for Written English." ... Sun Wu and Udi Manber: AGREP - A Fast Approximate Pattern-matching ... Approximate Pattern Matching. ...
    (comp.lang.python)