[Caml-list] a question about Ocaml toplevel behavior

[Caml-list] a question about Ocaml toplevel behavior

[Matej Košík]

Hi,

I've noticed that Ocaml (4.06.1) toplevel displays:

  <abstr>

instead of the actual term even if the value does not belong to an abstract data type.

Question #1: Is this the expected behavior?

My interaction with Ocaml toplevel was:

  # #load "misc_.cmo";;
  # #load "warnings_.cmo";;
  # #load "config_.cmo";;
  # #load "identifiable_.cmo";;
  # #load "numbers_.cmo";;
  # #load "arg_helper_.cmo";;
  # #load "clflags_.cmo";;
  # #load "location_.cmo";;
  # #load "docstrings_.cmo";;
  # #load "syntaxerr_.cmo";;
  # #load "ast_helper_.cmo";;
  # #load "longident_.cmo";;
  # #load "parser_.cmo";;
  # #load "lexer_.cmo";;
  # "foo" |> Lexing.from_string |> Parser_.implementation Lexer_.token_with_comments;;
    - : Parsetree_.structure =
  [{Parsetree_.pstr_desc =
     Parsetree_.Pstr_eval
      ({Parsetree_.pexp_desc = Parsetree_.Pexp_ident <abstr>;
        pexp_loc = <abstr>; pexp_attributes = []},
      []);
    pstr_loc = <abstr>}]

In the last response above, "<abstr>" appears twice.
In my opinion, in each case the actual term should have been printed.
The modules I have loaded where copied from Ocaml compiler with some α-conversions to avoid messages about duplicate interfaces.

What is strange is when I run a few other (dummy) commands:

  let Parsetree_.Pstr_eval (a,_) = ("foo" |> Lexing.from_string |> Parser_.implementation Lexer_.token_with_comments |> List.hd).pstr_desc;;
  let _ = Longident_.parse "foo.bar.baz";;
  Location_.none;;

then the original command:

  "foo" |> Lexing.from_string |> Parser_.implementation Lexer_.token_with_comments;;

is printed the expected way, i.e. without "<abstr>":

  [{Parsetree_.pstr_desc =
     Parsetree_.Pstr_eval
      ({Parsetree_.pexp_desc =
         Parsetree_.Pexp_ident
          {Parsetree_.Asttypes.txt = Parsetree_.Longident.Lident "foo";
           loc =
            {Parsetree_.Asttypes.Location.loc_start =
              {Lexing.pos_fname = ""; pos_lnum = 1; pos_bol = 0; pos_cnum = 0};
             loc_end =
              {Lexing.pos_fname = ""; pos_lnum = 1; pos_bol = 0; pos_cnum = 3};
             loc_ghost = false}};
        pexp_loc =
         {Parsetree_.Asttypes.Location.loc_start =
           {Lexing.pos_fname = ""; pos_lnum = 1; pos_bol = 0; pos_cnum = 0};
          loc_end =
           {Lexing.pos_fname = ""; pos_lnum = 1; pos_bol = 0; pos_cnum = 3};
          loc_ghost = false};
        pexp_attributes = []},
      []);
    pstr_loc =
     {Parsetree_.Asttypes.Location.loc_start =
       {Lexing.pos_fname = ""; pos_lnum = 1; pos_bol = 0; pos_cnum = 0};
      loc_end =
       {Lexing.pos_fname = ""; pos_lnum = 1; pos_bol = 0; pos_cnum = 3};
      loc_ghost = false}}]

Question 2: Does this make sense?
            Can the same value by printed by Ocaml toplevel sometimes as "<abstr>" and sometimes in the ordinary fashion?

Thanks in advance for the advice!

Matej

Re: [Caml-list] a question about Ocaml toplevel behavior

[Matej Košík]

Here is ta simplified version of the original question:

If I do:

  #use "topfind";;
  #require "compiler-libs.common";;
  Parse.implementation (Lexing.from_string "foo");;

What I see is this:

  - : Parsetree.structure =
  [{Parsetree.pstr_desc =
     Parsetree.Pstr_eval
      ({Parsetree.pexp_desc = Parsetree.Pexp_ident <abstr>; pexp_loc = <abstr>;
        pexp_attributes = []},
      []);
    pstr_loc = <abstr>}]

What confuses me is the presence of "<abstr>" stuff.
Why are they there?
Why don't I see the actual Ocaml terms (which do not belong to abstract types)?

Re: [Caml-list] a question about Ocaml toplevel behavior

[Nicolás Ojeda Bär]

Hello Matej,

My understanding is that the compiler will delay opening a .cmi file
until absolutely necessary.
Since it does not need to look into Location in order to compile the
given phrase, the .cmi is not opened and the type Location.t remains
abstract. But if you give the compiler an excuse to open location.cmi
then the definition of the type Location.t will become known to the
compiler and the toplevel will be able to print the values concretely.

For example, evaluating Location.none as in you did in your previous
message in one thing that will cause the compiler to load the
corresponding .cmi file thereby making Location.t concrete.

Best wishes,
Nicolás


On Sun, Mar 11, 2018 at 2:30 PM, Matej Košík <mail@matej-kosik.net> wrote:
> Here is ta simplified version of the original question:
>
> If I do:
>
>   #use "topfind";;
>   #require "compiler-libs.common";;
>   Parse.implementation (Lexing.from_string "foo");;
>
> What I see is this:
>
>   - : Parsetree.structure =
>   [{Parsetree.pstr_desc =
>      Parsetree.Pstr_eval
>       ({Parsetree.pexp_desc = Parsetree.Pexp_ident <abstr>; pexp_loc = <abstr>;
>         pexp_attributes = []},
>       []);
>     pstr_loc = <abstr>}]
>
> What confuses me is the presence of "<abstr>" stuff.
> Why are they there?
> Why don't I see the actual Ocaml terms (which do not belong to abstract types)?
>
> --
> 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

Re: [Caml-list] a question about Ocaml toplevel behavior

[Matej Košík]

Hi Nicolás,

Thank you for the reply.

On 03/11/18 16:06, Nicolás Ojeda Bär wrote:
> Hello Matej,
> 
> My understanding is that the compiler will delay opening a .cmi file
> until absolutely necessary.> Since it does not need to look into Location in order to compile the
> given phrase, the .cmi is not opened and the type Location.t remains
> abstract. But if you give the compiler an excuse to open location.cmi
> then the definition of the type Location.t will become known to the
> compiler and the toplevel will be able to print the values concretely.
I see some of the disadvantages of this behavior:

  (0) I have lost time wondering why things are printed as "<abstr>" instead of the real thing.

  (1) "<abstr>" may (confusingly) mean something else than "a value of an abstract type".
      It may mean that "toplevel has find an excuse not to load a relevant *.cmi file some so it does not know (yet) how to print a given value.
      (this is very unintuitive)

  (2) #install_printer directive may have no effect if toplevel has find an excuse not to load relevant *.cmi file.
      (this is very unintuitive)

Was this done on purpose? What do we gain from this behavior?
(considering that computer time (as opposed to human time) has ~zero value).

Re: [Caml-list] a question about Ocaml toplevel behavior

[Nicolás Ojeda Bär]

Hello,

I don't know if there is any deep design reason for this behaviour,
but for one it enables a kind of information hiding: in order to hide
modules which are private to a library and should not be exposed to
the client code, simply do not install the corresponding .cmi files.

Best wishes,
Nicolás


On Sun, Mar 11, 2018 at 4:51 PM, Matej Košík <mail@matej-kosik.net> wrote:
> Hi Nicolás,
>
> Thank you for the reply.
>
> On 03/11/18 16:06, Nicolás Ojeda Bär wrote:
>> Hello Matej,
>>
>> My understanding is that the compiler will delay opening a .cmi file
>> until absolutely necessary.> Since it does not need to look into Location in order to compile the
>> given phrase, the .cmi is not opened and the type Location.t remains
>> abstract. But if you give the compiler an excuse to open location.cmi
>> then the definition of the type Location.t will become known to the
>> compiler and the toplevel will be able to print the values concretely.
> I see some of the disadvantages of this behavior:
>
>   (0) I have lost time wondering why things are printed as "<abstr>" instead of the real thing.
>
>   (1) "<abstr>" may (confusingly) mean something else than "a value of an abstract type".
>       It may mean that "toplevel has find an excuse not to load a relevant *.cmi file some so it does not know (yet) how to print a given value.
>       (this is very unintuitive)
>
>   (2) #install_printer directive may have no effect if toplevel has find an excuse not to load relevant *.cmi file.
>       (this is very unintuitive)
>
> Was this done on purpose? What do we gain from this behavior?
> (considering that computer time (as opposed to human time) has ~zero value).

Re: [Caml-list] a question about Ocaml toplevel behavior

[Matej Košík]

Hi,

On 03/11/18 20:17, Nicolás Ojeda Bär wrote:
> Hello,
> 
> I don't know if there is any deep design reason for this behaviour,
> but for one it enables a kind of information hiding: in order to hide
> modules which are private to a library and should not be exposed to
> the client code, simply do not install the corresponding .cmi files.

I am not sure if this is the right mechanism (not providing *.cmi files)
for information hiding (which is a valid goal) but that is a separate topic.

What I do not understand is the default behavior of coqtop if *.cmi files are present.

Why coqtop does not load them all eagerly?

Why does coqtop delays loading of them us much as possible?

What is here to be gained by this behavior?

Is this done on purpose or was it a random decision?

Does anybody have an idea?

Why isn't this documented?

Why are (non abstract) types printed (in case *.cmi files were temporarily ignored) printed as "<abstr>" instead of "<something-else>"?

Re: [Caml-list] a question about Ocaml toplevel behavior

[Jacques Garrigue]

This actually looks like a bug.
Printing a value falls in the category where type information is
"asbolutely necessary”, so it should open the cmi.
Looking at the code, I do not see any immediate reason it wouldn’t work.
Well, it could happen if location.cmi is not available, but then I don’t
see how doing so extra stuff would help.
Can somebody open a PR on Mantis?

Jacques Garrigue

On 2018/03/12 00:06, Nicolás Ojeda Bär wrote:
> 
> Hello Matej,
> 
> My understanding is that the compiler will delay opening a .cmi file
> until absolutely necessary.
> Since it does not need to look into Location in order to compile the
> given phrase, the .cmi is not opened and the type Location.t remains
> abstract. But if you give the compiler an excuse to open location.cmi
> then the definition of the type Location.t will become known to the
> compiler and the toplevel will be able to print the values concretely.
> 
> For example, evaluating Location.none as in you did in your previous
> message in one thing that will cause the compiler to load the
> corresponding .cmi file thereby making Location.t concrete.
> 
> Best wishes,
> Nicolás
> 
> 
> On Sun, Mar 11, 2018 at 2:30 PM, Matej Košík <mail@matej-kosik.net> wrote:
>> Here is ta simplified version of the original question:
>> 
>> If I do:
>> 
>>  #use "topfind";;
>>  #require "compiler-libs.common";;
>>  Parse.implementation (Lexing.from_string "foo");;
>> 
>> What I see is this:
>> 
>>  - : Parsetree.structure =
>>  [{Parsetree.pstr_desc =
>>     Parsetree.Pstr_eval
>>      ({Parsetree.pexp_desc = Parsetree.Pexp_ident <abstr>; pexp_loc = <abstr>;
>>        pexp_attributes = []},
>>      []);
>>    pstr_loc = <abstr>}]
>> 
>> What confuses me is the presence of "<abstr>" stuff.
>> Why are they there?
>> Why don't I see the actual Ocaml terms (which do not belong to abstract types)?
>> 
>> --
>> 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

Re: [Caml-list] a question about Ocaml toplevel behavior

[Matej Košík]

On 03/12/18 09:50, Jacques Garrigue wrote:

> Can somebody open a PR on Mantis?

Done:

  https://caml.inria.fr/mantis/view.php?id=7751