English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
Avoiding shared data
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2005-10-05 (11:56)
From: Jon Harrop <jon@f...>
Subject: Re: FP/IP and performance (in general) and Patterns... (Re: [Caml-list] Avoiding shared data)
On Tuesday 04 October 2005 23:38, Michael Wohlwend wrote:
> there is a paper "Design Patterns in OCaml"  which describes various
> patterns:
> http://people.csail.mit.edu/dnj/teaching/6898/projects/vicente-wagner.pdf

I think I read this paper some time ago but it was interesting to read it 
again. Firstly, it gives only 3 references, doesn't appear to be complete, I 
think it is out of date and it appears to be written from the point of view 
of a dynamic typer. Secondly, I was never a fan of "design patterns".

As they say, several "design patterns" have trivial counterparts in FPLs, 
roughly: Singleton = module structure, Facade = module signature, Command = 
currying, Memento = dynamic type checking, and Strategy = HOFs.

The paper repeatedly states that modules cannot be mutually recursive. AFAIK, 
this has not been true for some time.

In the section about the "Observer" pattern, they state "a meaningless method 
call must be inserted into the code because OCaml's static checker cannot 
infer the type of the ...". Can the meaningless method not be replaced with a 
type declaration?

Perhaps the "State" pattern can be better represented by reusing polymorphic 

Overall, I'd say that the idea of design patterns is reasonable but the GOFs 
work is not relevant to OCaml - the study will need to be redone from 
scratch. I am much more interested in the automation of the factoring of code 
patterns, although I've yet to actually study it...

Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists