From: "\"Mark\"" <mark@proof-technologies.com>
To: <caml-list@inria.fr>
Subject: Re: [Caml-list] Some questions about building OCaml programs
Date: Sun, 18 Nov 2012 14:43:22 +0000 [thread overview]
Message-ID: <1353249802877@names.co.uk> (raw)
on 18/11/12 9:33 AM, Gabriel Scherer <gabriel.scherer@gmail.com> 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" <mark@proof-technologies.com>
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> = sig <interface> end"
>> and each .ml file must have something like:
>> "module <Mod> : <Sig> = struct <body> 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:
>> "<interface>"
>> and similarly each .ml file to be of the form:
>> "<body>".
>>
>> 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
>
>
>
next reply other threads:[~2012-11-18 14:43 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-18 14:43 "Mark" [this message]
2012-11-18 15:40 ` Gabriel Scherer
-- strict thread matches above, loose matches on Subject: below --
2012-11-18 8:01 "Mark"
2012-11-18 9:32 ` Gabriel Scherer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1353249802877@names.co.uk \
--to=mark@proof-technologies.com \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).