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 mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by sympa.inria.fr (Postfix) with ESMTPS id 0EB337EE20 for ; Sun, 18 Nov 2012 16:41:27 +0100 (CET) Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of gabriel.scherer@gmail.com) identity=pra; client-ip=209.85.223.182; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail1-smtp-roc.national.inria.fr: domain of gabriel.scherer@gmail.com designates 209.85.223.182 as permitted sender) identity=mailfrom; client-ip=209.85.223.182; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ie0-f182.google.com) identity=helo; client-ip=209.85.223.182; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="postmaster@mail-ie0-f182.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsBABwBqVDRVd+2mGdsb2JhbABFsBuTDAgjAQEBAQEICQ0HFCeCHgEBBUABGxILAQMMBgULDQ0hIQEBEQEFAQoSBhMSh2gBAw8LoTqMM4J4g3gKGScDClmIdQEFDIs/aYUNA5QngVWBHIoWA4MtFimEEg X-IronPort-AV: E=Sophos;i="4.83,275,1352070000"; d="scan'208";a="182036654" Received: from mail-ie0-f182.google.com ([209.85.223.182]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 18 Nov 2012 16:41:25 +0100 Received: by mail-ie0-f182.google.com with SMTP id k10so10062209iea.27 for ; Sun, 18 Nov 2012 07:41:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=wyg/jwlkRDJXYLFTo/FveuGO2aPO4vYa1flpxPQxViM=; b=UFUg3cPMZJodKbqNQI0pvdC0811Un+VqJUjJQqyWheSPS8xpbOhqEx1H31nniaONzP KEnCpdMS57HqReLttlfXWvgDSemgjE7SSBzk+hgVWJsXWyO+ocTLRGnI0+MQpTSNBNhV wajSST1JspjZEOU6yKuJTWaT+abFCv7MEzch7FcRcaqdjz+AUJgBzMiruK+yO+nK9jyb Dj3CA5Hf1LV+nUYmAoBITb8tyIIIWSoeyUguqk24Tm/fV+RlD59mvjlVeB30Ia5Ot3E/ bVRdfxx0o0hF3exsZLQLQtSbSSXUoVrxFB5U/b0lt92bXcqEkXiyMwDczFyeLMxofSUT f2bg== Received: by 10.43.7.132 with SMTP id oo4mr8998312icb.6.1353253284961; Sun, 18 Nov 2012 07:41:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.184.199 with HTTP; Sun, 18 Nov 2012 07:40:44 -0800 (PST) In-Reply-To: <1353249802877@names.co.uk> References: <1353249802877@names.co.uk> From: Gabriel Scherer Date: Sun, 18 Nov 2012 16:40:44 +0100 Message-ID: To: "\"Mark\"" Cc: caml-list@inria.fr Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Caml-list] Some questions about building OCaml programs Sorry for not respecting the format of your questions. I don't think your perception of "A" being "sticking to the paradigm of the toplevel" is correct; #use is more like a hack that is very rarely used. I call #use "topfind";; routinely, to enable the ocamlfind goodness from the toplevel: #use seems fine for toplevel-specific scripting/configuration rather than actually being part of the semantics of an OCaml program. Besides that, I personally never use #use directives when using the toplevel, and I don't think they're any form of "paradigm". Question 1: This way of doing it (explicit "module ..." wrapping in files) is wrong. It's working around something else, and you shouldn't do that and expect the OCaml tools to support this use-case in any other way that the semantics given to such code by the language: a module (named after the name of the source file) containing a submodule. Question 2: I'm not sure I understand the question but I don't think failures are global. When #use-ing, the source file argument is first parsed as a series of toplevel sentences, then each sentence is executed, essentially as its own bare compilation unit. This creates a different between parsing errors and errors that happen later: parsing errors will make the whole #use fail, and later errors will only fail to execute the sentence but keep on executing the others, just as if you typed them one after the other in the toplevel. You may be asking for a different mode that parses sentences and execute them on the fly (to avoid global syntax failure). Feel free to open a feature request on the bugtracker ( http://caml.inria.fr/mantis/ ), knowing that working patches are better than simple request, but that maintainers are often (rightly) quite conservative about backward-compatibility and avoiding adding bug and increasing maintenance costs by changing code that maybe doesn't really need to be changed. Question 3: the semantics model of OCaml tools is that a file foo.ml is understood as a compilation unit who, from the point of view of the OCaml language, is a module named Foo. Tools manipulate "compilation units" and source code sees "modules". The reason for this choice is that "module" is a natural semantic concept for "bunches of structure items", which is what source files are. OCaml tools maintain this consistent view and I don't see any reason not to (if you want to "strip the module layer" out of a set of definitions, just use the "open M" construction to be able to access them without qualifying by the module name). I'm not sure what your use case is, and why it wouldn't be satisfied by explicit "open" (maybe scripted somewhere), but they would have to be very compelling to result in a language change that makes thing more complex by adding a choice between two different semantics for compilation units under certain circumstances. Question 4: "ocaml -init foo.ml" may be what you are after. The phrases in foo.ml will be executed from the toplevel, but silently (you don't get the usual textual feedback where declaration interfaces are printed). Tweaking toplevel setting from foo.ml may allow to change this if you want, I'm not familiar with these aspects. I think there are genuinely interesting programming language design questions raised by interactive use-cases, but I'm not sure OCaml is the best candidate for semantics changes aimed at interactive use. Regarding more down-to-earth interface questions, the HOL-light people have used the ocaml toplevel as their main user interface and they certainly have had some requests of this kind. On Sun, Nov 18, 2012 at 3:43 PM, "Mark" wrote: > 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 = sig end" >>> and each .ml file must have something like: >>> "module : = 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 >> >> >> > > -- > 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