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 nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 5000EBB81 for ; Thu, 29 Sep 2005 05:33:34 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j8T3XXOk020202 for ; Thu, 29 Sep 2005 05:33:33 +0200 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id FAA28641 for ; Thu, 29 Sep 2005 05:33:32 +0200 (MET DST) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j8T3XUof020193 for ; Thu, 29 Sep 2005 05:33:31 +0200 Received: from rosella (ppp16-174.lns2.syd7.internode.on.net [59.167.16.174]) by smtp1.adl2.internode.on.net (8.12.9/8.12.6) with ESMTP id j8T3XOlW054518; Thu, 29 Sep 2005 13:03:25 +0930 (CST) (envelope-from skaller@users.sourceforge.net) Subject: Re: [Caml-list] Looking for a configuration file library From: skaller To: brogoff Cc: caml-list , David MENTRE In-Reply-To: References: <3d13dcfc05092706091acdb72a@mail.gmail.com> <3d13dcfc050928000613f42ed@mail.gmail.com> <1127925464.7743.71.camel@rosella> Content-Type: text/plain Date: Thu, 29 Sep 2005 13:33:23 +1000 Message-Id: <1127964804.20162.36.camel@rosella> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 433B608D.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 433B608A.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 noweb:01 literate:01 ocamldoc:01 ocaml:01 noweb:01 ocaml:01 tarball:01 haskell:01 tarball:01 compiler:01 config:01 config:01 compilation:01 compiler:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 On Wed, 2005-09-28 at 09:55 -0700, brogoff wrote: > On Thu, 29 Sep 2005, skaller wrote: > > On Wed, 2005-09-28 at 08:15 -0700, brogoff wrote: > > > > > > [1] Even if, in the long term, I want to remove noweb in order to use > > > > a literate programing style relying on language source code, like > > > > ocamldoc. > > > > > > That is exactly what I wish they had done. > > > > Why? > > Getting off topic, but since you ask... Packaging is hardly off topic in any programming language list. Last Ocaml tool I tried to build, that nice re library .. failed on the first line. Gave up in disgust. First line started with 'findlib' ... its a third party tool. I also get annoyed when you need to have 'make' to build a package.. usually you need bash as well. Neither is standard on Windows. > Because, Borg like, I wish to integrate whatever source code I grab into my > own code base, perhaps modifying it, and I don't wish to add yet another layer > of perl scripts and extra weird tools into my flow. That I understand. Though note: noweb is written in Icon (under debian noweb package requires iconx package .. that's the end, two binaries). > I'd rather Lua-ML be just > like the libraries that are distributed with OCaml. > > Also, I don't believe programs are enough like books that LP is worth > adopting. In short I'm an LP unbeliever (behead me!). Using MY tool, interscript, I don't care about the 'literate' part much either. What I *do* care about is the code generation -- precisely because "I don't wish to add yet another layer of perl scripts and extra weird tools into my flow" Hard to describe, but if you look at Felix, you'll see the tarball contains a single directory of files ending in .ipk or .pak. These are the LP sources. Everything else: be it Ocaml, HTML, C++, Felix, test data, Python, build scripts, man pages .. for the language comparisons there is Ada, Haskell, Scheme, Java, and a few other languages in there too .. EVERYTHING is stored in a single format in just one directory. Furthermore, using tables I can keep all these codes synchronised, that is, remove redundant and error prone repetition -- all without any external tools, other than interscript, which is supplied in the tarball in machine independent form. Of course, you need Python .. and Ocaml (and for Felix a C++ compiler). But you don't need bash or make! (Felix now builds *from source* on raw Win32 using only major programming language tools). > > Is there problem with running noweb to extract the source? > > That's the first step, then you need to get the comments right. And there > was a problem with yacc stuff, but nothing beyond grunt work, like I said. Oh yes, you have a problem: if you manually run noweb and fiddle the result, then include that in your own product (which is what I do all the time with 3pl software) then you have two SERIOUS problems: (a) you can't easily synchronise with the upstream author (b) you have the usual Licence problem, you whole project is now probably a 'derived work' > Back to config files. Other languages like Python and Scheme could also be used > as configuration files, but Lua is especially suitable when "non programmers" > are writing the config scripts. I doubt that. I'm a programmer, and I spent some time with Lua. Simple assignments in Lua are the same as Python: x = 1 y = "Hello" Anything more complex is HARD, and much harder in Lua than Python -- I never really figured it out. And anything that simple can be parsed by a few lines of Ocaml.. I actually looked at Lua as a replacement for Python to control configuration but threw it out. I am very happy now, sticking with Python (the platform independent build would have been harder in Lua). However I don't need to embed reading of config scripts (Felix has it own mechanism for conditional compilation etc). In the end, I would have to recommend using a pure Ocaml solution.. because if your Ocaml code embeds native Lua, then you need your clients who are 'building from source' to have a C compiler to compile Lua.. and you need to provide build scripts to do it .. and .. its all a huge mess. Ocaml is much easier to build .. except that people insist on using 'findlib' and INRIA insists on NOT supplying it as part of Ocaml. It's an old problem. Sigh. GODI and Debian solve these problems entirely .. but they're very heavy weight. -- John Skaller Felix, successor to C++: http://felix.sf.net