Re: Design Patterns and Functional programming

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?

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

Depending upon what exactly is illegal (is a** -b illegal?), I would raise
an exception in the lexer or parser.

Further, diagnostics will be a mess...

Why do you believe that?

You might want to do that. If you do, just sort by commuting and the
existing reduction rules will take care of constant folding. Something
like this:

| Add(Add(f, g), h) when g>h -> f +: h +: g
| Add(f, g) when f>g -> g +: f

What about 1+b+a+2?

Already handled => 3+a+b

What about 1-b+a-2?

Already handled => -1+a-b

The approach does not scale.

It seems to be scaling rather well but you need to make a comparison before
you can draw a justifiable conclusion.

Which is the point.

Yes.

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.

which is again the point.

Yes.

Does that design have any advantages over the functional solution above?

Yes, because of code reuse. It is modular, you don't need to rewrite (and
to test) all the code in order to parse, say C++.

Are they not both reusable and modular?

Other issues are
diagnostics, consider marking up the errors in the source. (BTW, what is a
functional equivalent to "marking in"? (:-)) Error recovery, what about
skipping to the end of the expression? You need two different grammars for
this and switching forth and back. To colorize the source there would be a
third grammar, and don't forget expansion of the methods when the cursor
hovers over... (Uhmm, "to hover" is it functional? (:-))

I don't follow. I am implementing all of these things for an IDE and memory
profiler at the moment and they seem trivial with the above approach. Code
position is carried in the AST automatically and I am using it to highlight
heavily-allocating code.

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

Rewriter is defined as a function,

A pattern match.

its OO equivalent would be again a function.

There is no OO equivalent to the pattern match. 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).

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

I would like the see the an OO equivalent.

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.

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

Apply the appropriate arguments.

2. How would you extend / modify a rewriter?

Using a continuation.

When you have it as a function, there is little you could do with it
beyond construction of a composition with some another function.

Yes.

If you wanted to "programmatically" look into a rewriter, then it would
become interesting. You could decompose it functional, you could do it as
a state machine, you could use a stack automat.

Sounds like a task for monads.

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.

Probably differently to some people here, I don't see any opposition
between FP and OO. You don't like stateful objects?

You are referring to a purely functional approach.

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

I agree. But why objects?

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