Re: Design Patterns and Functional programming

On Wed, 11 Jul 2007 23:24:33 +0100, Jon Harrop wrote:

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.

That depends on the settings.

0. It is untyped. There are some bracket constructs and rules to shuffle
brackets disregarding whatever might be within the brackets.

1. It is typed. Functions apply to typed arguments and yield typed results.
Already at this level the carrier of abstractions is type, neither function
nor value. Here the worn issue functional vs. data-oriented decomposition
ceases to exist.

2. The above was classical ADT. What OO adds is sets of types called
classes. Consequently it brings both polymorphic values and polymorphic
functions.

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,

Hmm, why should it? Value could be a natural number 1 from N. Object could
be a run-time thing used to express 1 in the program. Why would you like to
have it reverse and to invent some values for objects? [ That were trivial,
for any program runs on a finite machine and thus have a finite number of
states. ]

thus
including class decomposition. So the two are equivalent. However, this
says nothing of how much you can check at compile time

Yes, with types you can check far more. In fact you can check undecidable
things. Consider:

type Rational is ...;
type Transcendent is ...;

To check whether X is Transcendent, you should just match its type. The
trick is that the incomputable work is done outside the computer, by the
programmer who chooses the proper type.

or how easy it is to
extend OO or functional decompositions, which are the interesting
questions.

See above. OO can handle sets of types and use functional decomposition on
that level, in the form of polymorphic functions!

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.

So, you say it were rather an optimization issue? Then we have to conclude
that states should be scrapped down. Whatever performance loss might appear
it should be marginal, we could upgrade the computer and everything would
be OK... Either way, your position is inconsistent. [ Daniel already tried
to drive you this conclusion.]

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

Huh, that is a road to nowhere. What about this:

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

Or maybe

a + (b or not c) -> ?

The problem is complexity. Even if you solved all pattern matching problems
which are very hard if the pattern language is any more complex than
regular expressions. Even then, because of this complexity, the programmer
will be unable to understand the program it writes. Patterns are like
gotos. They are *too* powerful and lack any structure.

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.

How can I know what was inferred? Trivial inference is OK. Non-trivial is
not. The latter is when the programmer identifies types to solve the
problem. Nobody can do it for him.

[...]
Just infer the types. ;-)

You cannot infer transcendent numbers, it is a finite machine after all.

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

And these type and value are different from the type and the value the
reference points to. No ticks! (:-))

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

Relevant Pages

  • Re: Current JSON Proposal in ES4
    ... I don't really think JavaScript was well designed. ... that distinction comes from the programmer not the language. ... strange and confusing code. ... they could have realized that the module pattern was causing ...
    (comp.lang.javascript)
  • Re: Java is becoming the new Cobol
    ... Believe me, I don't have a problem with complexity, when it's warranted. ... Several years later, a programmer ... graphics data compression algorithms, including an assembly language ... Since the data backs up my impressions, ...
    (comp.lang.cobol)
  • Re: Java is becoming the new Cobol
    ... Believe me, I don't have a problem with complexity, when it's warranted. ... Several years later, a programmer ... graphics data compression algorithms, including an assembly language ... Since the data backs up my impressions, ...
    (comp.lang.cobol)
  • Re: Boxing and Unboxing ??
    ... It also increases language complexity, which can increase programmer ... adding one simple parameter qualifier and removing a complex qualifier. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: advice about `correct use of decorator
    ... I'm considering the software complexity AS ... program and a programmer who is working on some task; ... different from the complexity in implementing the decorator. ... care about the details. ...
    (comp.lang.python)