From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by sympa.inria.fr (Postfix) with ESMTPS id E8A027EE20 for ; Sun, 18 Nov 2012 15:43:31 +0100 (CET) Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of mark@proof-technologies.com) identity=pra; client-ip=85.233.160.25; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="mark@proof-technologies.com"; x-sender="mark@proof-technologies.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail4-smtp-sop.national.inria.fr: domain of mark@proof-technologies.com designates 85.233.160.25 as permitted sender) identity=mailfrom; client-ip=85.233.160.25; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="mark@proof-technologies.com"; x-sender="mark@proof-technologies.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@outgoing-smtp.namesco.net) identity=helo; client-ip=85.233.160.25; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="mark@proof-technologies.com"; x-sender="postmaster@outgoing-smtp.namesco.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAF3zqFBV6aAZZGdsb2JhbABFhiCFVKQnkxQWGgoLCBQDJIIeAQEEJEsQFhgCAgkdAiMbBAUYExKHaQMJCgeeS4ZYh3uICAMKiVSBIoopaYN6gRMDjg6GGYFVgRyET4VHiAA X-IronPort-AV: E=Sophos;i="4.83,275,1352070000"; d="scan'208";a="162896545" Received: from outgoing-smtp.namesco.net ([85.233.160.25]) by mail4-smtp-sop.national.inria.fr with ESMTP; 18 Nov 2012 15:43:27 +0100 Received: from [192.168.0.127] (helo=bigears.namesco.net) by outgoing-smtp.namesco.net with esmtp (Exim 4.67) (envelope-from ) id 1Ta65i-0006Kf-8m for caml-list@inria.fr; Sun, 18 Nov 2012 14:43:24 +0000 Received: from webmail by bigears.namesco.net with local (Exim 4.72) (envelope-from ) id 1Ta65i-000ECY-7k for caml-list@inria.fr; Sun, 18 Nov 2012 14:43:22 +0000 To: From: =?utf-8?q?=22Mark=22?= Reply-To: =?utf-8?q?=22Mark=22?= MIME-Version: 1.0 X-Mailer: Namesco Webmail v3.0 Message-ID: <1353249802877@names.co.uk> Date: Sun, 18 Nov 2012 14:43:22 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-namesco: 192.168.0.171 X-Spam-Score: -1.4 (-) Subject: Re: [Caml-list] Some questions about building OCaml programs on 18/11/12 9:33 AM, Gabriel Scherer wrote: > The long answer is part of this discussion of two weeks ago, started > by someone with essentially the same question: > https://sympa.inria.fr/sympa/arc/caml-list/2012-11/msg00024.html I didn't realise this. Thanks. Though that thread is only about my Question 1. > The short answer is that you should compile your files and use #load > "file.cmo";;, rather than directly #use "file.ml" which has a > different, less modular semantics. But what I want to do is A (i.e. stick completely within the paradigm of using the interpreter, without touching the 'ocamlc') and B (i.e. stick completely with the paradigm of the compiler, without touching the interpreter) with the same source code files. Using #load is a sort of messy compromise between the two. And so is a script to preprocess these files to chuck "outer syntax" around module bodies. I don't really see the problem with enhancing 'ocamlc' to have an option for dealing with outer syntax. The last part of my Question 1 asks whether it would be better to have an option to cater for what I want. Do you agree that it would be beter to have such an option, do you think it would make no difference, or do you think it would actually make things worse? Mark. > On Sun, Nov 18, 2012 at 9:01 AM, "Mark" wrote: >> Hi, >> >> I've got a series of interrelated questions about alternatives and >> what appear to be limitations in building OCaml programs. I hope you >> don't mind me packaging these together into one thread. >> >> I am writing a program that runs in the OCaml toplevel, implemented as >> a series of modules. Each module has a .mli source code file for its >> interface and a .ml source code file for its body. >> >> I would like to be able to do both of the following: >> A. Process the program interactively in the toplevel (using #use >> directives); >> B. Build the program into an extended toplevel (using 'ocamlc' to >> create .cmi and .cmo files, followed by 'ocamlmktop'). >> >> QUESTION 1 >> >> It seems that for A, each .mli file must have "outer module syntax", >> e.g. something like: >> "module type =3D sig end" >> and each .ml file must have something like: >> "module : =3D struct end". >> >> And it seems that for B, 'ocamlc' requires each .mli file not to have >> the outer syntax, i.e. to be of the form: >> "" >> and similarly each .ml file to be of the form: >> "". >> >> Am I correct? If so, why can't 'ocamlc' deal with the form for files >> acceptable for A? Wouldn't it be better to have the option of >> 'ocamlc' allowing the syntax required for A? >> >> QUESTION 2 >> >> This is just about A. I want to have a file "main.ml" which has #use >> directives for all the module files, and to call "main.ml" itself >> using a #use directive. It seems that a #use directive fails if there >> is an error in the given source code file, but not if the source code >> file itself contains #use directives (like my "main.ml") that fail. >> Why is this? Wouldn't it be better all failures bubbled to the top? >> >> QUESTION 3 >> >> This is just about B. It seems the 'ocamlmktop' command will only >> incorporate what are, ultimately, modules into the toplevel. Am I >> correct? Why can't it also incorporate directives and top level >> definitions? >> >> QUESTION 4 >> >> The 'ocaml' command can be called without a file argument, in which >> case a toplevel interactive session is started. It can also be called >> with a source code file argument, in which case the source code file >> is processed through the toplevel and then the session is terminated. >> Is there a way to process a file but then not terminate and instead >> enter an interactive toplevel session (with the source code file >> incorporated)? >> >> Mark. >> >> -- >> Caml-list mailing list. Subscription management and archives: >> https://sympa.inria.fr/sympa/arc/caml-list >> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners >> Bug reports: http://caml.inria.fr/bin/caml-bugs > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > > >