From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id D4DE3BB9A for ; Wed, 5 Oct 2005 13:56:00 +0200 (CEST) Received: from ptb-relay01.plus.net (ptb-relay01.plus.net [212.159.14.212]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j95Bu0kh019618 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 5 Oct 2005 13:56:00 +0200 Received: from [80.229.56.224] (helo=chetara) by ptb-relay01.plus.net with esmtp (Exim) id 1EN7sL-0001z5-Rk for caml-list@yquem.inria.fr; Wed, 05 Oct 2005 12:55:58 +0100 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: FP/IP and performance (in general) and Patterns... (Re: [Caml-list] Avoiding shared data) Date: Wed, 5 Oct 2005 01:31:59 +0100 User-Agent: KMail/1.7.2 References: <20051003200337.14092.qmail@web26809.mail.ukl.yahoo.com> <20051004164700.GA494@first.in-berlin.de> <200510050038.53080.micha-1@fantasymail.de> In-Reply-To: <200510050038.53080.micha-1@fantasymail.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510050132.00107.jon@ffconsultancy.com> X-Miltered: at concorde with ID 4343BF50.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 avoiding:01 ocaml:01 typer:01 trivial:01 fpls:01 hofs:01 recursive:01 afaik:01 ocaml's:01 checker:01 reusing:01 variants:01 ocaml:01 ...:98 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DATE_IN_PAST_06_12 autolearn=disabled version=3.0.3 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 variants. 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 http://www.ffconsultancy.com/products/ocaml_for_scientists