Re: [Caml-list] The verdict on "%identity"

[Gabriel Scherer <gabriel.scherer@gmail.com>]

On Mon, Nov 19, 2012 at 7:28 PM, David House <dhouse@janestreet.com> wrote:
> If you wanted to investigate this yourself, you could compile with -S
> and look at the generated assembly. For such short functions, this is
> generally not very hard.

Indeed:

cat test.ml
  module type SIG1 = sig type t val of_string: string -> t end
  module type SIG2 = sig type t external of_string: string -> t =
"%identity" end

  module Impl1 = struct type t = string let of_string x = x end
  module Impl2 = struct type t = string external of_string: string ->
t = "%identity" end

  module A: SIG1 = Impl1
  module B: SIG1 = Impl2
(*  module C: SIG2 = Impl1 *)
  module D: SIG2 = Impl2

  let testA = A.of_string "foo"
  let testB = B.of_string "bar"
  let testD = D.of_string "baz"

(I commented C out because it makes no sense to me, semantically, and
it's rejected by the compiler.)

ocamlopt -c -S test.ml
less test.s

The (relevant part of the) result on my machine, that correspond to
compilation of testA, testB, testD:
camlTest__entry:
  [...]
        movl    $camlTest__3, %eax
        movl    %eax, camlTest + 20
        movl    $camlTest__2, %eax
        movl    %eax, camlTest + 24
        movl    $camlTest__1, %eax
        movl    %eax, camlTest + 28
  [...]

All compiled in the same way.

There may be a difference for calls across compilation units: in
absence of the .cmx, no inlining would be performed. My guess would be
that in presence of the .cmx we should get the same final result, but
I must say I don't really care for performances on this front.

Note that there is however an important difference with private
definitions: with private, the cast from t to string is not only
erased by the compiler, it is a *coercion* that can be lifted to casts
to larger datatypes. You can coerce a (list t) into a (list string)
and this is also a no-op in the dynamic semantics. That's much
stronger than what you get from %identity.

(This suggest that, with the explicit subtyping we have in OCaml,
there would be a case for inter-coercible types: a way to define a t
such that for example (t :> string) and (string :> t), but not (t =
string). This doesn't increase the type safety of arbitrary programs
but allow programmers to force abstraction-breaking to be explicit,
with no performance cost in both directions.)

>
> On Mon, Nov 19, 2012 at 6:18 PM, Dario Teixeira <darioteixeira@yahoo.com> wrote:
>> Hi,
>>
>>> Wouldn't 'type t = private string' help the compiler optimize this?
>>
>>
>> Possibly, though the semantics would change: what before was
>> an abstract type is now translucent (ie, not quite transparent).
>>
>> Regards,
>> Dario
>>
>> --
>> 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