Re: Design Patterns and Functional programming

Dmitry A. Kazakov wrote:
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?

Elsewhere. :-)

OO and functional differ in their forms of abstraction: classes vs
functions/functors.

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.

If functions are first-class values then values can represent objects, thus
including class decomposition. So the two are equivalent. However, this
says nothing of how much you can check at compile time or how easy it is to
extend OO or functional decompositions, which are the interesting
questions.

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.

You just include a type equivalent to:

'a -> 'b

that represents function values. That's all you need: first-class functions.

Once you have types, operations automatically become just a part of.

There are many different type systems, ranging from completely dynamic in
Mathematica and Lisp to completely static in Standard ML.

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.

Provided you have laziness, purity only degrades the constant prefactor and
not the asymptotic complexity. Same for dynamic typing.

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.

Then compiler leaves it up to the programmer. Consider a trivial pattern
match that rotates addition nodes to be left-associative:

a+(b+c) -> (a+b)+c

I'd rather write the pattern match than a hierarchy of explicitly-specified
classes laid out in a design pattern representing a manually-compiled
pattern match.

Why should I care. Anyway I would prefer a language where aggregates and
literals where abstract operations to override.

They are with active patterns.

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.

The static type information is still available, you just don't have to write
it down yourself (repeatedly). Note that OCaml inferred the equivalent of
an entire class hierarchy in the example I gave.

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.

:-)

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.

Just infer the 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.

The type is denoted:

'a ref

the value is denoted:

ref x

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

Relevant Pages

  • Re: Design Patterns and Functional programming
    ... OCaml, Standard ML and Scala. ... Impurity is not required, as purely functional languages do exist, but it ... the model-view-controller design pattern. ... Then you can use pattern matching to manipulate ...
    (comp.object)
  • Re: OT: Performance of optimizing compilers.
    ... Johan> the compiler, unless you know what your criteria are. ... and here is some data compared with MLton ... the shootout also gives the impression that OCaml is also good at ... Some years ago, when I found my first way to functional languages, ...
    (comp.lang.functional)
  • Re: Suggestions on which language to "try" learning.
    ... choosing only based on the compiler, unless you know what your criteria are. ... know c and Haskell or Clean than to learn Haskell if you know c and SML, ... Also OCaml was easier to install. ... often used languages and the best - each in it's own way. ...
    (comp.lang.functional)
  • Re: Why Generics?
    ... Check out SML, OCaml ... It's still possible in these languages to explicitly declare the types of variables or functions to resolve ambiguity in certain cases, ... The compiler knows that pi is a float. ... int -> int ...
    (comp.lang.java.programmer)
  • Re: GoTo in Java
    ... but only to some extent - changing languages has to be ... MF has to support a lot of platforms, ... with, say, the free open-source OCaml compilers. ... Sometimes they're bugs in the *old* implementa- ...
    (comp.lang.cobol)