Re: Design Patterns and Functional programming

On Wed, 11 Jul 2007 18:44:25 +0100, Jon Harrop wrote:

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

Exactly, yes.

Then where is any difference?

Note that if OO is understood as typed, as ADT, then that necessarily
includes functional decomposition, because one cannot define types without
operations on them.

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

This raises questions. What is left?

Impure functional programming languages like Mathematica, Lisp, Scheme,
OCaml, Standard ML and Scala.

These are languages. What is left of the model they allegedly embody? I
don't see any consistent way to keep it simultaneously "functional" and
typed. Once you have types, operations automatically become just a part of.

Why impurity is needed?

Impurity is not required, as purely functional languages do exist, but it
offers a different set of trade-offs that are preferable for certain
classes of user. In particular, impure functional languages are among the
fastest languages in existence whereas purely functional languages tend to
trail with dynamically typed languages as the purity requires laziness
(thunks) and graph traversal for evaluation.

It seems that you say here that most (how many?) of known algorithms cannot
be implemented in a functional way achieving their theoretical complexity.
E.g. instead of O(log N) you get O(N). If it is indeed so, then, sorry, you
have to scrap your paradigm completely.

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.

Ok. In languages like OCaml, patterns can match trees as well as sequences.

No it is still the same class. A tree is equivalent to a sequence with
balanced brackets.

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?

In these languages, sum types (known as "variant" types) are a core part of
the type system and complement product types. A sum type presents
alternatives (like a tagged union in C). For example, a binary tree:

[...]

This is very beneficial in practice as it catches a lot of errors. Moreover,
this form of static checking requires the pattern matcher to be integrated
with the type system.

I don't see why pattern matching is required here, whatever thing the
compiler use to parse literals of the type t, that is up to the compiler.
Why should I care. Anyway I would prefer a language where aggregates and
literals where abstract operations to override.

In the case of OCaml, you can even have the sum type inferred and statically
checked:

I don't like type inference and I don't count it for an advantage. The
language should clearly distinguish its static (types) and dynamic (values
of) parts.

I don't really see a better way around this. The conventional OO approach
used by the XML libraries of Java and .NET is certainly horrendous in
comparison.

There is a much simpler approach - just don't use XML.

For somebody who cannot refrain himself in his love to angular brackets.
The trick is - write them on the *** of paper, then write the data into
the file/wire etc. The paper can be then put on the wall for meditation
purposes and better digestion after lunch time. The file is used for work.

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 see. Yes. I've certainly hit that problem a few times with OO. I think
higher-order objects are the solution: you just pass an object to the
constructor of another object.

This breaks the abstraction, because you split one type into two. What is
worse you have to derive from both handling two hierarchies of types.

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.

This is just nomenclature. In OCaml, a mutable reference is a type of value:

Hmm, reference itself should have a type and a value.

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

Quantcast