caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Oliver Bandel <oliver@first.in-berlin.de>
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] The Bridge Pattern in OCaml
Date: Fri, 28 Mar 2008 12:57:52 +0100	[thread overview]
Message-ID: <1206705472.47ecdd4031e56@webmail.in-berlin.de> (raw)
In-Reply-To: <e16c7bcd0803280429j6c8c7aecl5154b8c227d8020@mail.gmail.com>

Hey Jim,

Zitat von Jim Farrand <jim.farrand@gmail.com>:

> On 28/03/2008, Michael Wohlwend <micha-1@fantasymail.de> 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


  reply	other threads:[~2008-03-28 11:57 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-19 16:29 Christopher L Conway
2008-03-19 16:51 ` [Caml-list] " Bünzli Daniel
2008-03-19 17:44   ` Christopher L Conway
2008-03-19 18:06     ` Christopher L Conway
2008-03-20  2:07       ` Yaron Minsky
2008-03-20 13:27         ` Martin Jambon
2008-03-20 20:10           ` Christophe Raffalli
2008-03-28 10:44         ` Jim Farrand
2008-03-28 11:06           ` Michael Wohlwend
2008-03-28 11:29             ` Jim Farrand
2008-03-28 11:57               ` Oliver Bandel [this message]
2008-03-28 11:30             ` Oliver Bandel
2008-03-28 11:45               ` Jim Farrand
2008-03-28 11:52                 ` Michael Wohlwend
2008-03-28 12:09                   ` Oliver Bandel
2008-03-28 12:43                     ` Jim Farrand
2008-03-28 18:23                       ` Raoul Duke
2008-03-28 18:29                         ` Robert Fischer
2008-03-28 18:34                         ` David Thomas
2008-03-28 19:14                           ` blue storm
2008-03-28 19:04                         ` Oliver Bandel
2008-03-28 19:05                         ` Mathias Kende
2008-03-28 19:47                         ` Jon Harrop
2008-03-28 23:24                           ` Oliver Bandel
2008-03-31  8:31                         ` Berke Durak
2008-03-29 14:03                       ` Peng Zang
2008-03-28 12:03                 ` Oliver Bandel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1206705472.47ecdd4031e56@webmail.in-berlin.de \
    --to=oliver@first.in-berlin.de \
    --cc=caml-list@yquem.inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).