From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 71CE9BBAF for ; Sat, 13 Mar 2010 14:21:38 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoCANAfm0vRVaC0kWdsb2JhbACQa4ISh20IFQEBAQEJCQwHESSpD4FhhF8uiEsBAQMFhHYE X-IronPort-AV: E=Sophos;i="4.49,632,1262559600"; d="scan'208";a="46619264" Received: from mail-gy0-f180.google.com ([209.85.160.180]) by mail2-smtp-roc.national.inria.fr with ESMTP; 13 Mar 2010 14:21:37 +0100 Received: by gyc15 with SMTP id 15so684464gyc.39 for ; Sat, 13 Mar 2010 05:21:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=5AaL6wJ7bosLZD30MIrOQ8sTKlUTmiGs5Oj5hdQxlkc=; b=iQs1iywHQhNprS2/IHMGZ7C0SyvICoqsbGqgQSe8bNo5BFKYy5VUFGqX4a6gDIBMm1 NVQjN/X8F3xqVn/o2sFAXT+MY+00BWZhzrbeRmkGlLkVh8T3O+SDOD28TgQ7bDIHHvT6 Gjsxw+ePb7WFqjfRUVNRaGEu96/S3va/uCMLI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=EFPs8GDaY5r92s8dm9ALk/1EJyT+5ZfbWtMOXUwMo8CV+9RjYD+Ia8iecXlql/CikZ rysmcyF+ZJ8ngHTjBLZ/bMZ83Bz8wrvQbo46gOYjXLn6qthE38MSFaFf2ZF/UG2EMz2p QftOgztPALITCfhU5arGMOxUu/FvfzfWZqnC8= MIME-Version: 1.0 Received: by 10.101.206.30 with SMTP id i30mr1103139anq.9.1268486494817; Sat, 13 Mar 2010 05:21:34 -0800 (PST) In-Reply-To: <320e992a1003130229v1f39f6aek752c32a677c3ac87@mail.gmail.com> References: <320e992a1003130229v1f39f6aek752c32a677c3ac87@mail.gmail.com> Date: Sat, 13 Mar 2010 14:21:34 +0100 Message-ID: <527cf6bc1003130521p203013bbo1c62ff66479cff6a@mail.gmail.com> Subject: Re: [Caml-list] AGI research using ocaml From: blue storm To: Eray Ozkural Cc: caml-list Content-Type: multipart/alternative; boundary=0016e68e8cb1ed0f9e0481ae8617 X-Spam: no; 0.00; ocaml:01 ocaml:01 subset:01 subset:01 interpretor:01 langauge:01 bytecode:01 bytecode:01 compiler:01 andrej:01 andrej:01 compiler:01 eijiro:01 sumii:01 interpretor:01 --0016e68e8cb1ed0f9e0481ae8617 Content-Type: text/plain; charset=ISO-8859-1 It is difficult to understand what you say with no previous knowledge of your field (wich is probably not a common knowledge among OCaml hackers). The fact that you paper is named "Stochastic Grammar Based Incremental Machine Learning Using Scheme" doesn't help. If I understand correctly (feel free to correct myself) : 1) your field of research is "automatic program generation to solve a set of given tasks" : you generate random programs in a given language, with a mathematic theory giving you probability distribution for various syntaxic elements, until you find one that achieve your goal. You have a "learning mechanism" that can reuse previous solution (such as declared functions) for helping further tasks 2) You generate Scheme program fragments 3) Your algorithm/generator is written in OCaml, using the ocs Ocaml Scheme interpreter to test your generated programs 4) You would like to generate OCaml program fragments instead of Scheme. Your idea is that the type system, imposing more constraints on the legal program, will reduce the search space and accelerate your generator. In the example you give (square root, nand), you use only a tiny subset of a general programming language features. Why did you choose to target the full Scheme, instead of a minimalistic Lisp/Scheme subset ? It seems to me that targeting a bigger language (wich additional feature your generator probably doesn't know about anyway) will mainly incur an overhead on program evaluation. It is reasonable if you can access an already existing interpretor/evaluator implementation that suit your need (reusing one of the available scheme interpreters makes more sense than reimplementing one for scratch, maybe even for a tiny subset of the langauge). However, I'm not sure you can have something similar for OCaml : the only used OCaml implementation is the INRIA implementation, wich has bytecode and native compilers, but are not specially easy to invoke programmatically with low startup times requirements. Perhaps the bytecode compiler would be quick enough for your need, you should try. I think the easiest way for you would be to implement a small language with a ML typing system, and a tiny (but not algorithmically inefficient) interpreter for it. On small program fragments, a small interpreter would probably be much more interesting that calling an external tool. Besides, you could design your small language accordingly to your generator abilities. You might also be interesting in minimal ML interpreters/compilers projects. The two that I know of are : - MiniML in Andrej Bauer "Programming language Zoo" : http://andrej.com/plzoo/html/miniml.html - MinCaml, a tiny ML compiler by Eijiro Sumii : http://min-caml.sourceforge.net/index-e.html --0016e68e8cb1ed0f9e0481ae8617 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It is difficult to understand what you say with no previous knowledge of yo= ur field (wich is probably not a common knowledge among OCaml hackers). The= fact that you paper is named "Stochastic Grammar Based Incremental Ma= chine Learning Using Scheme" doesn't help.

If I understand correctly (feel free to correct myself) :

1) you= r field of research is "automatic program generation to solve a set of= given tasks" : you generate random programs in a given language, with= a mathematic theory giving you probability distribution for various syntax= ic elements, until you find one that achieve your goal. You have a "le= arning mechanism" that can reuse previous solution (such as declared f= unctions) for helping further tasks

2) You generate Scheme program fragments

3) Your algorithm/gener= ator is written in OCaml, using the ocs Ocaml Scheme interpreter to test yo= ur generated programs

4) You would like to generate OCaml program fr= agments instead of Scheme. Your idea is that the type system, imposing more= constraints on the legal program, will reduce the search space and acceler= ate your generator.


In the example you give (square root, nand), you use only a tiny su= bset of a general programming language features. Why did you choose to targ= et the full Scheme, instead of a minimalistic Lisp/Scheme subset ? It seems= to me that targeting a bigger language (wich additional feature your gener= ator probably doesn't know about anyway) will mainly incur an overhead = on program evaluation.
It is reasonable if you can access an already existing interpretor/evaluato= r implementation that suit your need (reusing one of the available scheme i= nterpreters makes more sense than reimplementing one for scratch, maybe eve= n for a tiny subset of the langauge).
However, I'm not sure you can have something similar for OCaml : the on= ly used OCaml implementation is the INRIA implementation, wich has bytecode= and native compilers, but are not specially easy to invoke programmaticall= y with low startup times requirements. Perhaps the bytecode compiler would = be quick enough for your need, you should try.
I think the easiest way for you would be to implement a small language with= a ML typing system, and a tiny (but not algorithmically inefficient) inter= preter for it. On small program fragments, a small interpreter would probab= ly be much more interesting that calling an external tool. Besides, you cou= ld design your small language accordingly to your generator abilities.

You might also be interesting in minimal ML interpreters/compilers proj= ects. The two that I know of are :
- MiniML in Andrej Bauer "Progra= mming language Zoo" : http://andrej.com/plzoo/html/miniml.html
- MinCaml, a tiny ML compiler by Eijiro Sumii : http://min-caml.sourceforge.net/index-e.html<= /a>
--0016e68e8cb1ed0f9e0481ae8617--