The Bridge Pattern in OCaml

The Bridge Pattern in OCaml

[Christopher L Conway]

It is often said that almost any programming problem can be solved
without touching the OO part of OCaml. I have found this to be largely
true and try to avoid using objects whenever possible. One design
pattern that comes up frequently that I have never found a suitable
non-OO solution for is the Bridge Pattern.

In short, the Bridge Pattern is applicable when a client needs access
to operations F, G which can be provided by a variety of underlying
implementations X, Y, or Z. If the specific implementation isn't
important, you create an interface B (a "bridge") with operations F
and G, and write both the client and the implementations to the
interface B. The client should then be able to access X, Y, or Z
interchangeably, e.g., by taking the implementation as an argument at
initialization.

This is trivial in any OO language (including OCaml using objects) and
will typically appear in the first or second chapter of any tutorial
on OO programming. This is more or less *the* problem that subtyping
polymorphism was designed to solve. My question: is there a non-OO way
of achieving the same result in OCaml?

The naive approach is to substitute module and module types for
objects and interfaces in the OO solution. I'm sure everybody who's
come to OCaml from an OO background has tried this approach and found
it wanting. The problem is you can't "pass around" a module as if it
were an object. You have to do an explicit branch to choose between X,
Y, and Z anytime you access F or G. (Even if you functorize the client
C, you end up having to explicitly branch to choose between C(X),
C(Y), C(Z).)

Another solution is to define a structure type including F and G, then
pass the structure around as a "dictionary." I.e., to code up a
fragment of the object type system by hand in order to avoid dealing
with objects in their fully generality. This doesn't work if the
interface needs to include types as well as functions.

At this point, I typically give up and go with the OO solution. Has
anyone come up with an elegant solution that does not require objects
and object subtyping?

Regards,
Chris

Re: [Caml-list] The Bridge Pattern in OCaml

[Bünzli Daniel]

Le 19 mars 08 à 17:29, Christopher L Conway a écrit :

> In short, the Bridge Pattern is applicable when a client needs access
> to operations F, G which can be provided by a variety of underlying
> implementations X, Y, or Z. If the specific implementation isn't
> important, you create an interface B (a "bridge") with operations F
> and G, and write both the client and the implementations to the
> interface B. The client should then be able to access X, Y, or Z
> interchangeably, e.g., by taking the implementation as an argument at
> initialization.

You need existential types. They can be encoded in ocaml, see here [1]  
the abstract counter datatype that does just what you describe above.

Best,

Daniel

[1] http://caml.inria.fr/pub/ml-archives/caml-list/2004/01/52732867110697f55650778d883ae5e9.en.html

Re: [Caml-list] The Bridge Pattern in OCaml

[Christopher L Conway]

Daniel,

This is very clever! But I might do better to just use objects...

Considering how stylized the declarations are in your example (i.e.,
type 'a t, type 'a t_scope = { bind_t : 'b . 'a t -> 'b }, etc.), I
wonder if one couldn't devise some syntactic sugar?

Chris

On Wed, Mar 19, 2008 at 12:51 PM, Bünzli Daniel
<daniel.buenzli@erratique.ch> wrote:
>
>  Le 19 mars 08 à 17:29, Christopher L Conway a écrit :
>
>
>  > In short, the Bridge Pattern is applicable when a client needs access
>  > to operations F, G which can be provided by a variety of underlying
>  > implementations X, Y, or Z. If the specific implementation isn't
>  > important, you create an interface B (a "bridge") with operations F
>  > and G, and write both the client and the implementations to the
>  > interface B. The client should then be able to access X, Y, or Z
>  > interchangeably, e.g., by taking the implementation as an argument at
>  > initialization.
>
>  You need existential types. They can be encoded in ocaml, see here [1]
>  the abstract counter datatype that does just what you describe above.
>
>  Best,
>
>  Daniel
>
>  [1] http://caml.inria.fr/pub/ml-archives/caml-list/2004/01/52732867110697f55650778d883ae5e9.en.html
>
>  _______________________________________________
>  Caml-list mailing list. Subscription management:
>  http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
>  Archives: http://caml.inria.fr
>  Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>  Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>

Re: [Caml-list] The Bridge Pattern in OCaml

[Christopher L Conway]

I'll also note that this is the second time a question I posted to the
list has been answered with "use existential types" [1] (aside: to my
eternal shame, these two questions are basically the same and I should
have seen the connection...) but there is no accessible reference I
can find via Google that explains what OCaml's "existential types"
are, what they do, and how a non-type-theorist would go about using
them. I would write this myself, but I'm clearly not qualified. (This
is no knock on your contribution Daniel. It's just that scratching
one's head over clever code is no substitute for a tutorial.)

Are people here using this language feature in the real world? If so, how?

Regards,
Chris

[1] http://caml.inria.fr/pub/ml-archives/caml-list/2007/05/1f28b525af6b5cd446b5ccecf8ae5685.en.html

On Wed, Mar 19, 2008 at 1:44 PM, Christopher L Conway
<cconway@cs.nyu.edu> wrote:
> Daniel,
>
>  This is very clever! But I might do better to just use objects...
>
>  Considering how stylized the declarations are in your example (i.e.,
>  type 'a t, type 'a t_scope = { bind_t : 'b . 'a t -> 'b }, etc.), I
>  wonder if one couldn't devise some syntactic sugar?
>
>  Chris
>
>
>
>  On Wed, Mar 19, 2008 at 12:51 PM, Bünzli Daniel
>  <daniel.buenzli@erratique.ch> wrote:
>  >
>  >  Le 19 mars 08 à 17:29, Christopher L Conway a écrit :
>  >
>  >
>  >  > In short, the Bridge Pattern is applicable when a client needs access
>  >  > to operations F, G which can be provided by a variety of underlying
>  >  > implementations X, Y, or Z. If the specific implementation isn't
>  >  > important, you create an interface B (a "bridge") with operations F
>  >  > and G, and write both the client and the implementations to the
>  >  > interface B. The client should then be able to access X, Y, or Z
>  >  > interchangeably, e.g., by taking the implementation as an argument at
>  >  > initialization.
>  >
>  >  You need existential types. They can be encoded in ocaml, see here [1]
>  >  the abstract counter datatype that does just what you describe above.
>  >
>  >  Best,
>  >
>  >  Daniel
>  >
>  >  [1] http://caml.inria.fr/pub/ml-archives/caml-list/2004/01/52732867110697f55650778d883ae5e9.en.html
>  >
>  >  _______________________________________________
>  >  Caml-list mailing list. Subscription management:
>  >  http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
>  >  Archives: http://caml.inria.fr
>  >  Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>  >  Bug reports: http://caml.inria.fr/bin/caml-bugs
>  >
>  >
>

Re: [Caml-list] The Bridge Pattern in OCaml

[Yaron Minsky]

[-- Attachment #1: Type: text/plain, Size: 845 bytes --]

On Wed, Mar 19, 2008 at 2:06 PM, Christopher L Conway <cconway@cs.nyu.edu>
wrote:

>
> Are people here using this language feature in the real world? If so, how?


For what it's worth, not at Jane Street.  We've looked at using existential
types once or twice, but have yet to find a really compelling application.
We don't really use objects much either.

I'm actually a bit puzzled by your original post, in that I don't have a
clear sense of what kind of situations you've run up against where using
poor-man's objects (e.g., collections of closures wrapped up in a bundle)
doesn't do the job.  On the whole, I've found that collections of closures
are easier to think about than objects precisely because you don't have to
worry about subtyping.  I'd be quite curious to hear about concrete examples
where that approach doesn't fit well.

y

[-- Attachment #2: Type: text/html, Size: 1190 bytes --]

Re: [Caml-list] The Bridge Pattern in OCaml

[Martin Jambon]

On Wed, 19 Mar 2008, Yaron Minsky wrote:

> On Wed, Mar 19, 2008 at 2:06 PM, Christopher L Conway <cconway@cs.nyu.edu>
> wrote:
>
>>
>> Are people here using this language feature in the real world? If so, how?
>
>
> For what it's worth, not at Jane Street.  We've looked at using existential
> types once or twice, but have yet to find a really compelling application.
> We don't really use objects much either.
>
> I'm actually a bit puzzled by your original post, in that I don't have a
> clear sense of what kind of situations you've run up against where using
> poor-man's objects (e.g., collections of closures wrapped up in a bundle)
> doesn't do the job.  On the whole, I've found that collections of closures
> are easier to think about than objects precisely because you don't have to
> worry about subtyping.  I'd be quite curious to hear about concrete examples
> where that approach doesn't fit well.

I find the biggest advantage of objects over records to be the same as 
polymorphic variants over classic variants:

- reusability of method names or variant names
- the same interface can be defined independently by 2 libraries without
   creating a dependency between them; later, objects (resp. poly.
   variants) coming from one library or another can be used
   interchangeably.


Martin

--
http://wink.com/profile/mjambon
http://martin.jambon.free.fr

Re: [Caml-list] The Bridge Pattern in OCaml

[Christophe Raffalli]

[-- Attachment #1.1: Type: text/plain, Size: 1437 bytes --]


> I find the biggest advantage of objects over records to be the same as 
> polymorphic variants over classic variants:
No surprise, the duality between sum types (normal variant) and record 
types (duality mean that they can encode
one another through a functional encoding) can be lifted to objects for 
records ans polymorphic variants for sum ...

In Ocaml, the polymorphic variant sare a bit too limited to have the 
full duality. To do it one would need the
type system to know that in (match t with `A -> ... | x -> ...) x can 
not use `A. Nervertheless, J. Garrigue modular evaluator
is a bery nice illustration of this (look at his web page for the paper).

The problem is to have tuples, records, objects and modules to be only 
one thing (and by the way require that variant always have exactly one 
argument),
so that you do not have to choose which approach you prefer ...


Cheers,

-- 
Christophe Raffalli
Universite de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tel: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
---------------------------------------------
IMPORTANT: this mail is signed using PGP/MIME
At least Enigmail/Mozilla, mutt or evolution 
can check this signature. The public key is
stored on www.keyserver.net
---------------------------------------------


[-- Attachment #1.2: Christophe_Raffalli.vcf --]
[-- Type: text/x-vcard, Size: 310 bytes --]

begin:vcard
fn:Christophe Raffalli
n:Raffalli;Christophe
org:LAMA (UMR 5127)
email;internet:christophe.raffalli@univ-savoie.fr
title;quoted-printable:Ma=C3=AEtre de conf=C3=A9rences
tel;work:+33 4 79 75 81 03
note:http://www.lama.univ-savoie.fr/~raffalli
x-mozilla-html:TRUE
version:2.1
end:vcard


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

Re: [Caml-list] The Bridge Pattern in OCaml

[Jim Farrand]

On 20/03/2008, Yaron Minsky <yminsky@gmail.com> wrote:

> For what it's worth, not at Jane Street.  We've looked at using existential
> types once or twice, but have yet to find a really compelling application.
> We don't really use objects much either.
>
> I'm actually a bit puzzled by your original post, in that I don't have a
> clear sense of what kind of situations you've run up against where using
> poor-man's objects (e.g., collections of closures wrapped up in a bundle)
> doesn't do the job.  On the whole, I've found that collections of closures
> are easier to think about than objects precisely because you don't have to
> worry about subtyping.  I'd be quite curious to hear about concrete examples
> where that approach doesn't fit well.

Hi,

Apologies for chipping in so late.

I've used the "poor man's objects" approach quite often.  It's very
powerful and nicely modular - especially when creating frameworks
intended to be used by other programmers.  You can provide a module
which dictates an interface, while allowing clients of the module to
provide the precise implementation.

However, I always find it unravels quite quickly when a requirement is
added to store state on disk or send it over the network.  Records
containing closures aren't suitable for this.  I can use the O'Caml
marshalling system, but I don't really understand how this is useful
in practice, because data isn't portable between different
compilations of the program

To give a concrete, but slightly simple example (which I've hit in the
real world): you are writing a game writing framework.  You want to
allow client code to implement different kinds of Monster behaviour by
providing a function (game_state -> monster_state -> action).  The
complete game and monster state needs to be saved and reloaded,
possibly between different versions of the program.

Do any O'Caml design gurus have opinions on how best to do this?  I've
never been satisfied with any of the solutions I've come up with.

Regards,
Jim

Re: [Caml-list] The Bridge Pattern in OCaml

[Michael Wohlwend]

Am Freitag, 28. März 2008 11:44:41 schrieb Jim Farrand:

> ...  The
> complete game and monster state needs to be saved and reloaded,
> possibly between different versions of the program.

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.

you can also zip it for saving space...

 Michael

Re: [Caml-list] The Bridge Pattern in OCaml

[Jim Farrand]

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).

Regards,
Jim

Re: [Caml-list] The Bridge Pattern in OCaml

[Oliver Bandel]

Zitat von Michael Wohlwend <micha-1@fantasymail.de>:

> Am Freitag, 28. März 2008 11:44:41 schrieb Jim Farrand:
>
> > ...  The
> > complete game and monster state needs to be saved and reloaded,
> > possibly between different versions of the program.
>
> 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.
[...]


For special purposes and requirements, I would recommend
to develop a special file format.

Or, if other game engines' formats could be re-used
without legal problems, and no re-engeneering from the
source is necessary, one could re-use those formats.

For example, if your code is GPLed, I would have some
Python-stuff in mind...

But possibly you have to code you another "Bridge" ;-)
between this stuff and your Ocaml-program.


To re-use in some cases needs more time than to re-invent. :-)

It seems that you already know, what things you
want to write to the files, so then the fileformat it's
specification is at hand.


Ciao,
   Oliver

P.S.: ==>:1,$ s/you/the original author/g

Re: [Caml-list] The Bridge Pattern in OCaml

[Jim Farrand]

On 28/03/2008, Oliver Bandel <oliver@first.in-berlin.de> wrote:
>  It seems that you already know, what things you
>  want to write to the files

No.

The opposite in fact.  I want to be able to serialize things I (the
framework designer) never even thought of.  I want the users of my
framework to have maximum flexibility to implement whatever behaviour
they like, without restricted them to the things I thought of putting
into the file format.

O'Caml marshalling is in the right direction (take any closure and
serialize it, this is very flexible in this respect), but it is far to
restricted in other ways to be of use (file format tied to particular
executable).

Regards,
Jim

Re: [Caml-list] The Bridge Pattern in OCaml

[Michael Wohlwend]

Am Freitag, 28. März 2008 12:45:26 schrieb Jim Farrand:
>
> The opposite in fact.  I want to be able to serialize things I (the
> framework designer) never even thought of.  I want the users of my
> framework to have maximum flexibility to implement whatever behaviour
> they like, without restricted them to the things I thought of putting
> into the file format.

couldn't the user implement and somehow register functions for serializing his 
own data structures?

Re: [Caml-list] The Bridge Pattern in OCaml

[Oliver Bandel]

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

Re: [Caml-list] The Bridge Pattern in OCaml

[Oliver Bandel]

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

> On 28/03/2008, Oliver Bandel <oliver@first.in-berlin.de> wrote:
> >  It seems that you already know, what things you
> >  want to write to the files
>
> No.
>
> The opposite in fact.  I want to be able to serialize things I (the
> framework designer) never even thought of.  I want the users of my
> framework to have maximum flexibility to implement whatever behaviour
> they like, without restricted them to the things I thought of putting
> into the file format.
[...]

OK, so I misunderstood your needs.
sorry, I didn't read the thread completely and just jumped in.

>
> O'Caml marshalling is in the right direction (take any closure and
> serialize it, this is very flexible in this respect), but it is far
> to
> restricted in other ways to be of use (file format tied to particular
> executable).


OK. Marhsal-module is nice, but there are disadvantages:
if the marshalled data is loaded but was corrupted, this
can crash your program!
So I would never recommend to use it.
It also possibly could be a security hole, when using that module.
Another reason why I would never recommend it's usage.

Beter write your own implementation of the serialization
on top of OCaml, without of Marhsalling-module (which
is too deep inside the internals of Ocaml, and therefore make things
possibly unreliable!).


Ciao,
   Oliver

Re: [Caml-list] The Bridge Pattern in OCaml

[Oliver Bandel]

Zitat von Michael Wohlwend <micha-1@fantasymail.de>:

> Am Freitag, 28. März 2008 12:45:26 schrieb Jim Farrand:
> >
> > The opposite in fact.  I want to be able to serialize things I (the
> > framework designer) never even thought of.  I want the users of my
> > framework to have maximum flexibility to implement whatever
> behaviour
> > they like, without restricted them to the things I thought of
> putting
> > into the file format.
>
> couldn't the user implement and somehow register functions for
> serializing his
> own data structures?
[...]

When I hear "serialization", the term "AST" pop ups for me also.

Possibly I'm too biased here ;-)
but maybe that's the way to go?

Creating a datastrzucture, while creatzing the functionality.
And later, when you want to serialize what you have build up,
write that datastructure, you build by your own, to a file.
and when rereading it, this means: re-create the functionality from the
datastructure.

Isn't this, what is looked for, here?

This is in a way langauge implementation.
Isn't it?

Ciao,
   Oliver

Re: [Caml-list] The Bridge Pattern in OCaml

[Jim Farrand]

On 28/03/2008, Oliver Bandel <oliver@first.in-berlin.de> wrote:
> Zitat von Michael Wohlwend <micha-1@fantasymail.de>:

>  Creating a datastrzucture, while creatzing the functionality.
>  And later, when you want to serialize what you have build up,
>  write that datastructure, you build by your own, to a file.
>  and when rereading it, this means: re-create the functionality from the
>  datastructure.
>
>  Isn't this, what is looked for, here?

Yes, this definitely solves the problem and meets the requirements I specified.

In Haskell, it would be very neat - define a Monad for composing the
ASTs and then code just like you would any other Haskell program,
you're just using a different Monad from normal.

In O'Caml, a lot less neat because the user providing the behaviour
suddenly isn't really coding the algorithm in O'Caml, but creating a
data-structure that represents the computation.

But still, it definitely gets the job done.

>  This is in a way langauge implementation.
>  Isn't it?

Yes, indeed.  I guess that's what makes me hesitate.  When a fairly
simple problem like "allow calling modules to provide custom behaviour
with serialisation" is answered with "implement a sub-language", it
makes me worry that either the language or my design is inappropriate
for the job, especially when other languages solve the same problem
with relative ease.

So I guess, I'm hoping for something more.  :)  (I'm very demanding I
know, but this list regularly puts forward answer of such pure genius
that I figure it's worth asking[1])

Thanks for your thoughts on the issue,
Jim

[1] http://ocaml.janestcapital.com/?q=node/18

Re: [Caml-list] The Bridge Pattern in OCaml

[Raoul Duke]

clueless question: are there languages which really can de/serialize
arbitrary functions? Lisp?

Re: [Caml-list] The Bridge Pattern in OCaml

[Robert Fischer]

Factor brags about being able to do that.

~~ Robert.

On Mar 28, 2008, at 1:23 PM, Raoul Duke wrote:

> clueless question: are there languages which really can de/serialize
> arbitrary functions? Lisp?
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] The Bridge Pattern in OCaml

[David Thomas]

I know that CL-STORE, specifically, does not.


--- Raoul Duke <raould@gmail.com> wrote:

> clueless question: are there languages which really
> can de/serialize
> arbitrary functions? Lisp?
> 
> _______________________________________________
> Caml-list mailing list. Subscription management:
>
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list:
> http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
> 



      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

Re: [Caml-list] The Bridge Pattern in OCaml

[Oliver Bandel]

Hello,


Zitat von Raoul Duke <raould@gmail.com>:

> clueless question: are there languages which really can de/serialize
> arbitrary functions? Lisp?
[...]


Well, if one thinks about using a different language,
one possibly can find a lot of languages that support that feature,
but they do not have the advantage of OCaml's rigid type system.

One could use Perl with datadumper-moule, one can use
eval in perl and slurp in Code... I think this feature
was first invented in Lisp. I think this is powerful,
but also very easily exploitable.

Objective-C is not functional, but OO.
With the Cocoa-framwework one can write all
objects with their internal state to disk,
or send them vie network to another application.

But Apple decided to use Java instead of Objective-C.

Again thinking about the "implementing a language inside
a language possibly means to have to switch to a language that
provides the needed features of serialization, instead of
reimplementing it" does forget one argument: the type-sytem
of OCaml. Do the other languages provide such a system as
OCaml does? Swithcing to a less-rigid language could be
the easier task in the begining, but not in the long run.

This somehow is similar to things like code-injecting by eval()
in functions that provide this. For example, if you unchecked use
data from the outside (e.g. webpage) and eval(9 it directly,
this would be very problematic. better one should implement a
mini-language that parses it's arguments, and when the syntax (and
syntax also means the accepted keywords... for example a
system()-command that is not defined in the minilanguage would
let the parser fail, instead of inserting the code and executing it.

It's much harder to have a secure way of "accept all and then throw
away, what makes problem", instead of making "accept nothing, but allow
these keywords" secure. And this problem is somehow related to the
problem of "taking a language that offers the functionality already",
when this means that you then also have a lot of holes slurped in
(typesystem is too weak).

It's also possible to reinvent the weak wheel, when
one reimplements such weak languages on top of OCaml.
But if one insists on rigid checks, one could invent something new.
Something that works AND is easy to use.

BTW: Is there something like a LISP with type-checking like OCaml?
     Did someone have programmed something like that?


Ciao,
   Oliver

Re: [Caml-list] The Bridge Pattern in OCaml

[Mathias Kende]

I believe that C# is able to do that. But although I have used this capability 
in a grid project (http://sourceforge.net/projects/ngrid/) I don't know how this 
part of the work was performed.
Also, I don't know what do you mean by arbitrary. C# is able to serialize 
functions that are unknown to the software that will receive them, but there is 
maybe some limitation.

Maybe this is also possible to other .NET language.

Mathias


Raoul Duke a écrit :
> clueless question: are there languages which really can de/serialize
> arbitrary functions? Lisp?
> 
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] The Bridge Pattern in OCaml

[blue storm]

> In Haskell, it would be very neat - define a Monad for composing the
> ASTs and then code just like you would any other Haskell program,
> you're just using a different Monad from normal.

>  In O'Caml, a lot less neat because the user providing the behaviour
> suddenly isn't really coding the algorithm in O'Caml, but creating a
> data-structure that represents the computation.

Could you elaborate a bit on this ?
It seems me that monads only provide (in this particular case) a
limited syntaxic sugar. Are they really an improvement ? If you've got
some example of monadic AST-building, i'd be interested.

Couldn't the pa_monad extension achieve the same job ? The more
general (and heavyweight) solution would be to build a full DSL using
camlp4, but i'm not sure of what you can win with a dedicated syntax.

Re: [Caml-list] The Bridge Pattern in OCaml

[Jon Harrop]

On Friday 28 March 2008 18:23:56 Raoul Duke wrote:
> clueless question: are there languages which really can de/serialize
> arbitrary functions?

Rewrite languages can do that easily because code really is data.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

Re: [Caml-list] The Bridge Pattern in OCaml

[Oliver Bandel]

Zitat von Jon Harrop <jon@ffconsultancy.com>:

> On Friday 28 March 2008 18:23:56 Raoul Duke wrote:
> > clueless question: are there languages which really can
> de/serialize
> > arbitrary functions?
>
> Rewrite languages can do that easily because code really is data.
[...]

In dynamic languages: yes.


Ciao,
   Oliever

Re: [Caml-list] The Bridge Pattern in OCaml

[Peng Zang]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 28 March 2008 08:43:42 am Jim Farrand wrote:
> On 28/03/2008, Oliver Bandel <oliver@first.in-berlin.de> wrote:
> > Zitat von Michael Wohlwend <micha-1@fantasymail.de>:
> >
> >  Creating a datastrzucture, while creatzing the functionality.
> >  And later, when you want to serialize what you have build up,
> >  write that datastructure, you build by your own, to a file.
> >  and when rereading it, this means: re-create the functionality from the
> >  datastructure.
> >
> >  Isn't this, what is looked for, here?
>
> Yes, this definitely solves the problem and meets the requirements I
> specified.
>
> In Haskell, it would be very neat - define a Monad for composing the
> ASTs and then code just like you would any other Haskell program,
> you're just using a different Monad from normal.
>
> In O'Caml, a lot less neat because the user providing the behaviour
> suddenly isn't really coding the algorithm in O'Caml, but creating a
> data-structure that represents the computation.
>
> But still, it definitely gets the job done.
>


Forgive me if I'm missing something here, but couldn't you just use OCaml 
bytecode?

It appears to me that OCaml bytecode is perfect for your purposes.  It is, 
exactly, a serialized format for code.  So if your client wants to send you 
some arbitrary piece of code to run, tell them to compile it down to 
bytecode, send it over the wire, and then on your end, simply interpret the 
bytecode.  In fact you might be able to get away with just calling the 
current OCaml bytecode interpreter.

Or better yet, your client can just send you the plain ascii of the code and 
you can use the OCaml toplevel to interpret it.

(you may have to send the environment of the piece of code as well, but the 
environment is simply a big hashtable of (symbol, value) pairs.  Well, I 
say "value" but it may be a pointer to another piece of code or a pointer to 
a file with some raw data in it.)

If you are concerned with speed, you can do JIT compilation of 
bytecode/source.

Peng
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)

iD8DBQFH7kwmfIRcEFL/JewRAiGiAJ9gDrg09aZNvT8dqfHdOjRqmt++awCfYmQ7
nSniH6930lJytpD6BTcgYyU=
=1Oaa
-----END PGP SIGNATURE-----

Re: [Caml-list] The Bridge Pattern in OCaml

[Berke Durak]

Raoul Duke a écrit :
> clueless question: are there languages which really can de/serialize
> arbitrary functions? Lisp?

AliceML does :

http://www.ps.uni-sb.de/alice/manual/pickling.html

-- 
Berke DURAK