Patterns and Compositionality

[btanksley@hifn.com]

> From: Francois-Rene Rideau [mailto:fare@tunes.org]

> > Lambda calculus is not even _close_ to powerful enough to 
> > handle design
> > patterns -- it's not even powerful enough to easily handle 
> > function calls
> > when the called function is permitted to modify variables 
> > (although it is
> > sufficiently powerful to model either one, given some more 
> > complexity).

> Of course it can! See the papers on Concurrent Haskell! Or 
> see Clean, etc.
> Just because you haven't seen it doesn't mean it's impossible.

I didn't say it was impossible -- I said that it's not easy.  In fact, it's
quite hard; proofs involving the resulting messes are a nightmare.

> And just because things have the same name "variable" doesn't mean
> they have a one-to-one correspondance in all settings.
> If variable modification is difficult to handle in lambda-calculi,
> it's because it's something _intrinsicly_ difficult to handle.

Nonsense!  Computers and even turing machines handle those _easily_.  You're
confusing one notation with absolute truth.

> Lambda-calculi are _simple_ _formal_ calculi. Try to account for the
> semantics of variable modification in _any_ calculus, you'll end up
> with something fairly complex. You end up with state being a monad,
> and variable accessors (and modifiers) being monadic combinators
> (and yes, the semantics of monads is intrinsicly coinductive).

> Friends have done proofs of imperative programs (heap 
> sorting, and more)
> in Coq (a logic system based on pure typed lambda-calculus); 
> it's possible,
> but it's certainly not straightforward.

Have you seen the proofs on similar systems written using abstract state
machines?  The proofs are readable by anyone with a reasonable amount of
perseverence.

> > So far, patterns have no been successfully formalized.  One 
> > reason for this
> > is that a true design pattern has to be commonly useful; if 
> > it's not, it may
> > be a clever design, but it's not suitable for a pattern.

> Another reason is that if they tried to formalize it, pattern 
> people would
> see that it's a combination of hype, the bloody obvious, and 
> long known in formal calculi.

Fare', you're too hung up on formality.  Not everything has a formal
definition!  "Design Patterns" are like "sewing patterns".  Opposing them is
like opposing sewing patterns because they're only shapes, and geometricians
have known about shapes all along.

A realistic definition of a "pattern" in that sense is "how it's been done
before".  Perhaps the words "role model" serve better.

Of course, some people give "patterns" a more rigorous definition.  I
haven't seen a single one which didn't make me think it was total and utter
hype; but that's probably because I'm prejudiced.  At the same time, it does
seem reasonable to me that because the general concept of "patterns" is so
solidly established and has been proven so useful, any specific definition
should politely use another name.

> > Fare senses most strongly other's crimes when he himself is 
> > guilty of the
> > same thing.  Hype is the entire basis of our devotion to 
> > Tunes, and Fare is
> > responsible for that.  So hype can be used for good as well 
> > as evil ;-).

> No comment.

It's one of the more important things I said.

Patterns are useful and expedient.  TUNES is also useful, but not always
expedient.  Hype claims to be useful, but is never expedient.  TUNES is
closer to hype than patterns are.

> [ François-René ÐVB Rideau | Reflection&Cybernethics | 

-Billy