caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jeremy Yallop <yallop@gmail.com>
To: peterfrey <pjfrey@sympatico.ca>
Cc: "caml-list@inria.fr" <caml-list@inria.fr>
Subject: Re: [Caml-list] Repacking modules gives unexpected results
Date: Tue, 12 May 2015 23:36:24 +0100	[thread overview]
Message-ID: <CAAxsn=EgGBvO1=yrQ5jY-_jC6gsxCog9LnVqEbk6bpKtdhSARw@mail.gmail.com> (raw)
In-Reply-To: <BLU436-SMTP3178025F8A7ABA7A18CA4BA3DA0@phx.gbl>

On 12 May 2015 at 22:47, peterfrey <pjfrey@sympatico.ca> wrote:
> (* I am running into a very strange problem with re-packed modules:
>   re-packed instances of variables take on their new values, but internal
>   functions that depend on those values are still tied to the initial
> values.

I think you're thinking of modules as a way of defining something like
objects, where variables bound within the module behave like member
variables that can be overridden.  In fact, modules are not very much
like objects, and variables bound in modules have the same lexical
scope as most of the rest of the language.  In particular, in this
definition:

  struct
    let buf  = Data.initial
    let len  = (Bytes.length Data.initial)
    let show() = sprintf"len:%i\tbuf:%s" len buf
  end

the names 'len' and 'buf' in the definition of 'show' will always
refer to the nearest bindings for those names in the scope *in which
show was defined*, no matter what you do elsewhere in the program.
OCaml programmers tend to think of this kind of lexical scope as a
feature, since it makes it quite straightforward to understand and
refactor code.

A little further down you have

   include (val env:ELT) let buf = "aBar"
                                  let len = 4

which, when you substitute in the value of 'env', and expand the
'include', gives you something equivalent to this:

    let buf  = Data.initial
    let len  = (Bytes.length Data.initial)
    let show() = sprintf"len:%i\tbuf:%s" len buf
    let buf = "aBar"
    let len = 4

Although the names 'buf' and 'len' are rebound, the rebindings don't
have any effect on the uses of the previous bindings in the definition
of 'show'.  Again, there's nothing module-specific going on here;
you'll see the same behaviour if you enter the definitions at the
top-level.

OCaml does have a system of objects and classes which behaves in
something like the way that you're expecting.  For example, you can
write:

  class make ~initial =
    object
      val buf = initial
      val len = String.length initial
      method show = Printf.sprintf "len:%i\tbuf:%s" len buf
      method repack ~buf ~len = {< buf = buf; len = len >}
    end

and then

  # let s = new make ~initial:"foo";;
  val s : make = <obj>
  # s#show;;
  - : string = "len:3\tbuf:foo"
  # let s' = s#repack ~buf:"aBar" ~len:4;;
  val s' : make = <obj>
  # s'#show;;
  - : string = "len:4\tbuf:aBar"

Jeremy.

  reply	other threads:[~2015-05-12 22:36 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-12 21:47 peterfrey
2015-05-12 22:36 ` Jeremy Yallop [this message]
2015-05-15 22:28 ` peterfrey

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='CAAxsn=EgGBvO1=yrQ5jY-_jC6gsxCog9LnVqEbk6bpKtdhSARw@mail.gmail.com' \
    --to=yallop@gmail.com \
    --cc=caml-list@inria.fr \
    --cc=pjfrey@sympatico.ca \
    /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).