[Caml-list] A question about custom toplevels

[Caml-list] A question about custom toplevels

[Jocelyn Sérot]

[-- Attachment #1: Type: text/plain, Size: 1336 bytes --]

Hello,

I recently stumbled on a problem and am wondering whether it comes from a misunderstanding or a bad usage.

When a custom toplevel is built using the [ocamlmktop] program, it seems that the modules which are « included » must be present in the path when the so-built toplevel is executed afterwards. 

For example, suppose that directory « bar » contains  a file foo.ml, with, let say the definition « let v=100 ».
Then, making 

ocamlfind ocamlc -c -o foo.cmo foo.ml
ocamlfind ocamlc -a -o foo.cma foo.cmo
ocamlfind ocamlmktop -o foo.top foo.cma

creates foo.top, which, when executed, behaves has expected.

$ ./foo.top 
        OCaml version 4.06.0

# Foo.v;;
- : int = 100

But, when trying to execute foo.top from another directory, for ex from ../bar, i get the following error :

$ ./bar/foo.top 
        OCaml version 4.06.0

# Foo.v;;
Error: Unbound module Foo

The error disappears if i add option « -I ./bar » when lauching foo.top (or, equivently execute the directive « #directory ./bar »).

Is there a way to build a « self-contained » custom toplevel which could be executed without any explicit reference to the modules it included at creation ? 

Jocelyn

ps : i tried the -custom option but, not surprisingly, it does not solve the pb since it only refers to external C code.

[-- Attachment #2: Type: text/html, Size: 3017 bytes --]

Re: [Caml-list] A question about custom toplevels

[Nicolás Ojeda Bär]

Dear Jocely,

I do not think this is currently possible.

When you enter a phrase into the toplevel (custom or otherwise), it is
compiled much the same way as if it had been written in a file and
passed to ocamlc.
To do so the compiler needs access to the signature information stored
in the .cmi files of all referenced modules. This is completely
independent of whether the code of those modules is linked into the
toplevel or loaded separately which is what ocamlmktop is about.

Note that it works the same way even for modules of the stdlib. The
reason "it just works" in that case is because a flag "-I <stdlibdir>"
is added implicitly. But if you pass the -nostdlib flag to the
toplevel, this implicit flag is not added, and the toplevel will not
be able to find the .cmi files of the stdlib in much the same way in
cannot find foo.cmi.

Best wishes,
Nicolás

On Thu, Mar 8, 2018 at 9:19 AM, Jocelyn Sérot
<Jocelyn.Serot@univ-bpclermont.fr> wrote:
> Hello,
>
> I recently stumbled on a problem and am wondering whether it comes from a
> misunderstanding or a bad usage.
>
> When a custom toplevel is built using the [ocamlmktop] program, it seems
> that the modules which are « included » must be present in the path when the
> so-built toplevel is executed afterwards.
>
> For example, suppose that directory « bar » contains  a file foo.ml, with,
> let say the definition « let v=100 ».
> Then, making
>
> ocamlfind ocamlc -c -o foo.cmo foo.ml
> ocamlfind ocamlc -a -o foo.cma foo.cmo
> ocamlfind ocamlmktop -o foo.top foo.cma
>
> creates foo.top, which, when executed, behaves has expected.
>
> $ ./foo.top
>         OCaml version 4.06.0
>
> # Foo.v;;
> - : int = 100
>
> But, when trying to execute foo.top from another directory, for ex from
> ../bar, i get the following error :
>
> $ ./bar/foo.top
>         OCaml version 4.06.0
>
> # Foo.v;;
> Error: Unbound module Foo
>
> The error disappears if i add option « -I ./bar » when lauching foo.top (or,
> equivently execute the directive « #directory ./bar »).
>
> Is there a way to build a « self-contained » custom toplevel which could be
> executed without any explicit reference to the modules it included at
> creation ?
>
> Jocelyn
>
> ps : i tried the -custom option but, not surprisingly, it does not solve the
> pb since it only refers to external C code.

Re: [Caml-list] A question about custom toplevels

[Jocelyn Sérot]

Dear Nicolàs,

Thank for your very clear answer. 
I should have guessed this from the fact that the .cmi files were not available indeed ..

Best wishes

Jocelyn

Le 8 mars 2018 à 15:18, Nicolás Ojeda Bär <nicolas.ojeda.bar@lexifi.com> a écrit :

> Dear Jocely,
> 
> I do not think this is currently possible.
> 
> When you enter a phrase into the toplevel (custom or otherwise), it is
> compiled much the same way as if it had been written in a file and
> passed to ocamlc.
> To do so the compiler needs access to the signature information stored
> in the .cmi files of all referenced modules. This is completely
> independent of whether the code of those modules is linked into the
> toplevel or loaded separately which is what ocamlmktop is about.
> 
> Note that it works the same way even for modules of the stdlib. The
> reason "it just works" in that case is because a flag "-I <stdlibdir>"
> is added implicitly. But if you pass the -nostdlib flag to the
> toplevel, this implicit flag is not added, and the toplevel will not
> be able to find the .cmi files of the stdlib in much the same way in
> cannot find foo.cmi.
> 
> Best wishes,
> Nicolás
> 
> On Thu, Mar 8, 2018 at 9:19 AM, Jocelyn Sérot
> <Jocelyn.Serot@univ-bpclermont.fr> wrote:
>> Hello,
>> 
>> I recently stumbled on a problem and am wondering whether it comes from a
>> misunderstanding or a bad usage.
>> 
>> When a custom toplevel is built using the [ocamlmktop] program, it seems
>> that the modules which are « included » must be present in the path when the
>> so-built toplevel is executed afterwards.
>> 
>> For example, suppose that directory « bar » contains  a file foo.ml, with,
>> let say the definition « let v=100 ».
>> Then, making
>> 
>> ocamlfind ocamlc -c -o foo.cmo foo.ml
>> ocamlfind ocamlc -a -o foo.cma foo.cmo
>> ocamlfind ocamlmktop -o foo.top foo.cma
>> 
>> creates foo.top, which, when executed, behaves has expected.
>> 
>> $ ./foo.top
>>        OCaml version 4.06.0
>> 
>> # Foo.v;;
>> - : int = 100
>> 
>> But, when trying to execute foo.top from another directory, for ex from
>> ../bar, i get the following error :
>> 
>> $ ./bar/foo.top
>>        OCaml version 4.06.0
>> 
>> # Foo.v;;
>> Error: Unbound module Foo
>> 
>> The error disappears if i add option « -I ./bar » when lauching foo.top (or,
>> equivently execute the directive « #directory ./bar »).
>> 
>> Is there a way to build a « self-contained » custom toplevel which could be
>> executed without any explicit reference to the modules it included at
>> creation ?
>> 
>> Jocelyn
>> 
>> ps : i tried the -custom option but, not surprisingly, it does not solve the
>> pb since it only refers to external C code.

Re: [Caml-list] A question about custom toplevels

[Alain Frisch]

On 08/03/2018 15:18, Nicolás Ojeda Bär wrote:
> I do not think this is currently possible.
> 
> When you enter a phrase into the toplevel (custom or otherwise), it is
> compiled much the same way as if it had been written in a file and
> passed to ocamlc.
> To do so the compiler needs access to the signature information stored
> in the .cmi files of all referenced modules. This is completely
> independent of whether the code of those modules is linked into the
> toplevel or loaded separately which is what ocamlmktop is about.


The Env module has the following:

=======================================================
module Persistent_signature : sig
   type t =
     { filename : string; (** Name of the file containing the signature. *)
       cmi : Cmi_format.cmi_infos }

   (** Function used to load a persistent signature. The default is to 
look for
       the .cmi file in the load path. This function can be overridden 
to load
       it from memory, for instance to build a self-contained toplevel. *)
   val load : (unit_name:string -> t option) ref
end
=======================================================

This makes it possible to create a custom toplevel with some "embedded" 
.cmi files.

-- Alain

Re: [Caml-list] A question about custom toplevels

[Oleg]

Alain Frisch mentioned:

> The Env module has the following:

> =======================================================
> module Persistent_signature : sig
>    type t =
>      { filename : string; (** Name of the file containing the signature. *)
>        cmi : Cmi_format.cmi_infos }

>    (** Function used to load a persistent signature. The default is to 
> look for
>        the .cmi file in the load path. This function can be overridden 
> to load
>        it from memory, for instance to build a self-contained toplevel. *)
>    val load : (unit_name:string -> t option) ref
> end
> =======================================================

This facility has made me think (some four years ago, in fact) that
OCaml may very well support type providers like those in F# (which
seem to be very popular, in this age of Big Data). This load function
can as well go on the web and load .cmi from there (or synthesize one
from the information found in the online schema). It might be a fun
project.