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
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
>> 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
> 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
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
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)
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
>>>> 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
>> 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! (:-))
Dmitry A. Kazakov