Re: Design Patterns and Functional programming

On Mon, 09 Jul 2007 21:53:26 +0100, Jon Harrop wrote:

Dmitry A. Kazakov wrote:
The above is not the Ada's grammar, which is far more complex.

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

The problem is in additional constraints, like a**-b (illegal).

Depending upon what exactly is illegal (is a** -b illegal?),

Brackets are required:

2.0**-1 -- This is illegal
2.0**(-1) -- This is OK

I would raise an exception in the lexer or parser.

How, non-functionally... (:-))

Further, diagnostics will be a mess...

Why do you believe that?

Because diagnostics is a side-effect, 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."

If we're talking about parsers then the handling of precedence levels
should be clear from the above example.

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.

I would still be interested to see an object oriented equivalent to the
term rewriter. :-)

Rewriter is defined as a function,

A pattern match.

No, a pattern match gives yes/no, rewriter translates from one
representation to another.

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.

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

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." You could also add "pattern recognition" as known in AI
to the list. These three are way different things, as I understand them.

Don't expect me reinventing wheels. (:-))

I would like the see the an OO equivalent.

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

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.

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.

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

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

Relevant Pages

  • Re: Design Patterns and Functional programming
    ... No, that is not Ada. ... your design or else face "states." ... a pattern match gives yes/no ... Integrating pattern matching into a statically typed language allows ...
    (comp.object)
  • Re: Questions about two sentences
    ... ploughed through one of the books which lists all the "grammar points" ... etc to plug into the grammar pattern with ones where you need to know ... the meaning of the pattern. ... It's worth making sure you have all the different ...
    (sci.lang.japan)
  • 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)
  • Re: issue with implementing a visitor design pattern
    ... Not quite sure how else you would achieve it in Ada. ... My objection to the "visitor" pattern is that it simulates case ... I suspect much of OO advocates' hatred of case statements comes from ... If Ada allowed case statements on the 'Tag field of class-wide ...
    (comp.lang.ada)
  • Re: Does ANSI Common Lisp have pattern matching?
    ... I think decent pattern matching would be a welcome addition to the next ... I feel that a pattern matcher needs to ... partially evaluating the pattern matcher at compile time ...
    (comp.lang.lisp)