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 mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 810F0BBC1 for ; Fri, 28 Mar 2008 20:04:57 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUCAP/d7EfAbSoIiGdsb2JhbACRMwEBAQ8mmVs X-IronPort-AV: E=Sophos;i="4.25,572,1199660400"; d="scan'208";a="10115642" Received: from einhorn.in-berlin.de ([192.109.42.8]) by mail1-smtp-roc.national.inria.fr with ESMTP; 28 Mar 2008 20:04:57 +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 m2SJ4u3d015519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 28 Mar 2008 20:04:56 +0100 Received: (from www-data@localhost) by einhorn.in-berlin.de (8.13.6/8.13.6/Submit) id m2SJ4utI015514 for caml-list@yquem.inria.fr; Fri, 28 Mar 2008 20:04:56 +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 20:04:56 +0100 Message-ID: <1206731096.47ed415833e07@webmail.in-berlin.de> Date: Fri, 28 Mar 2008 20:04:56 +0100 From: Oliver Bandel To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] The Bridge Pattern in OCaml References: <4a051d930803190929q60d31012kb6c9d2b03a2d2ca6@mail.gmail.com> <1206703811.47ecd6c379853@webmail.in-berlin.de> <200803281252.41824.micha-1@fantasymail.de> <1206706146.47ecdfe275806@webmail.in-berlin.de> <91a2ba3e0803281123o68e86a1ej1d91f838c753232d@mail.gmail.com> In-Reply-To: <91a2ba3e0803281123o68e86a1ej1d91f838c753232d@mail.gmail.com> 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 serialize:01 ocaml's:01 ocaml:01 parses:01 syntax:01 syntax:01 parser:01 inserting:01 oliver:01 oliver:01 caml-list:01 functions:01 Hello, Zitat von Raoul Duke : > 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