From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id D8FF1BBC1 for ; Fri, 28 Mar 2008 12:57:52 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUCAGJ67EfAbSoIiGdsb2JhbACRMwEBAQ8mmT0 X-IronPort-AV: E=Sophos;i="4.25,569,1199660400"; d="scan'208";a="8905974" Received: from einhorn.in-berlin.de ([192.109.42.8]) by mail2-smtp-roc.national.inria.fr with ESMTP; 28 Mar 2008 12:57:52 +0100 X-Envelope-From: oliver@first.in-berlin.de X-Envelope-To: Received: from einhorn.in-berlin.de (localhost [127.0.0.1]) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id m2SBvqG9002506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 28 Mar 2008 12:57:52 +0100 Received: (from www-data@localhost) by einhorn.in-berlin.de (8.13.6/8.13.6/Submit) id m2SBvqhX002504 for caml-list@yquem.inria.fr; Fri, 28 Mar 2008 12:57:52 +0100 X-Authentication-Warning: einhorn.in-berlin.de: www-data set sender to oliver@first.in-berlin.de using -f Received: from dslb-088-073-089-114.pools.arcor-ip.net (dslb-088-073-089-114.pools.arcor-ip.net [88.73.89.114]) by webmail.in-berlin.de (IMP) with HTTP for ; Fri, 28 Mar 2008 12:57:52 +0100 Message-ID: <1206705472.47ecdd4031e56@webmail.in-berlin.de> Date: Fri, 28 Mar 2008 12:57:52 +0100 From: Oliver Bandel To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] The Bridge Pattern in OCaml References: <4a051d930803190929q60d31012kb6c9d2b03a2d2ca6@mail.gmail.com> <891bd3390803191907q5838ee66u83cb35e549805af0@mail.gmail.com> <200803281206.30620.micha-1@fantasymail.de> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 X-Spam: no; 0.00; bandel:01 in-berlin:01 ocaml:01 o'caml:01 ocaml:01 ocamllex:01 ocamlyacc:01 ocamlyacc:01 closures:01 closures:01 imho:01 imho:01 wrote:01 partial:01 partial:01 Hey Jim, Zitat von Jim Farrand : > On 28/03/2008, Michael Wohlwend wrote: > > > I would make my own format with a version number. > > Maybe: > > a complicated binary format, > > a more text like format like json or yaml or xml *schockhorror* > > or use a small db for storing, like sqlite. > > But how would you encode an O'Caml function/closure as, say, XML? As > far as I know this isn't possible. > > My point is, I want to find some compromise between: > - Representing behaviour as closures (very flexible, but not > serializable), and > - Representing behaviour without closures (serializable, but with > huge > loss of flexibility wrt. what the behaviour implementations can do - > ie, the framework would have to predict in advance what kind of > things > the implementations might want to do in order to provide an encoding > flexible enough). [...] If you create your closures not hard-coded, but instead create them by program (from a limited set of hardcoded closures), then you have the way you created it at hand. Call it an "AST" if you want, or give it a different name. What I mean is: you can call a closure a closure, or you can call it a partial applicated function. If you call it a partial applicated function, IMHO it's easier to understand, how to build up things from the bottom up to the top. If you create your functions from bottom to top, you also could create an AST (if you like this term) from it. Or possibly you already have such a datastructure at hand... ...then you can build up the conglomerated functions from it. The functionality that you have at hand then with your conglomerated funcions, will have a corrosponding linearization when writing things to the file ("will have", if you code it). I have no completely elaborated explanation of it. Possibly I should do this, when I have some time for it. (If I would be a computer-scientist, I may already would have been written a paper on it.) But I have done such composition of functionality in one of my tools. So I have some OCaml code. Here is, how I did it: I have an input language, use ocamllex and ocamlyacc to parse it, and in the ocamlyacc actions I used that partial application technique to build up functionality from bottom to top. I don't know if this way is one that the OCaml-Gurus or the Object.magicians would also recommend, ;-) but for my purposes it worked fine. I did not needed to write corresponding linearized things to a file (which seems to be your main problem here), so this was not implemented. But IMHO this should be possible also in the same manner as one creates the conglomerated functions. (Not prooved so far; it's an idea only.) If you don't understand, what I'm talking about, I could send you the link to the code. If you understand, what I mean: does this make sense to you, can you use that way for solving your problem? Ciao, Oliver