Version française
Home     About     Download     Resources     Contact us    
Browse thread
The Bridge Pattern in OCaml
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Oliver Bandel <oliver@f...>
Subject: Re: [Caml-list] The Bridge Pattern in OCaml
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