caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Neil Inala <inalan@yahoo.com>
To: caml-list@inria.fr
Subject: [Caml-list] bytegen.comp_expr error when doing object copying
Date: Tue, 27 Nov 2001 09:03:52 -0800 (PST)	[thread overview]
Message-ID: <20011127170352.63710.qmail@web14609.mail.yahoo.com> (raw)
In-Reply-To: <20011127102130.A16765@pauillac.inria.fr>


Perhaps this should go to caml-bugs only, but I thought discussions
on the list might disambiguate some assumptions I'm making.  Also
I'm not sure it's a bug.  In the code below (section 1), everything
seems to work fine.  The code compiles with no problems.  In the
almost-identical code section 2, the compiler emits the following:

v/64
>> Fatal error: Bytegen.comp_expr: var v_64
Uncaught exception: Misc.Fatal_error

Now, I know why this happens; in code section 2, the val v is
declared only after the definition of make_altered_self.  So when
the compiler gets to the object copying expression {< v = 5 >},
it has no variable v available to it.  It seems to me, however,
that the compiler should either not give an error or emit a
different error.

Not giving an error would fit with my intuition that, in defining
the code for the object, I should be able to reference variables
defined anywhere in the same scope.  (note: I haven't experimented
here with modules or signatures, but I have the feeling that
if I were to declare signatures first the code in section 2
would compile fine).

As for giving a different error, some experimentation indicates
what might be a better way of reporting this.  If we replace the
{< v = 5 >} with {< v2 = 5 >}, for example, the compiler says
"Unbound instance variable v2".  If we replace the {< v = 5 >}
with {< v = 5.0 >}, the error is "This expression has type float
but is here used with type int".  These are both more informative,
and neither is of the same class of error as
"Fatal error: Bytegen.comp_expr".  This is because the compiler
does type checking before it does byte code generation, and does
so based on the entire section of code that it slurps in, as we
see in code section 3, excerpted from
ocaml-src-3.02/driver/compile.ml.  Yet byte generation can only
generate code based on what it has already seen added to its
available environment.  This is made clear when examining the
lambda and rawlambda dumps from the compiler.

It seems like the compiler type checks the source in section 2
just fine, so thinks it's ok to proceed to code generation.  Then,
when the variable isn't available, the compiler thinks something
has gone badly wrong and so emits a rather uninformative Fatal_error.

So lacking requisite knowledge of the object/type theory involved,
I must ask you all whether it makes sense to treat class definition
in the same way recursive definitions are treated (or maybe like
prototypes/forward declarations, ugh), and read in all defined
variables before code is emitted; or simply to modify the
code in section 4 (from ocaml-src/bytecomp/bytegen.ml) to say
something along the lines of "variable v not found" rather than
just Fatal_error.  The problem with the latter solution, while
it is more informative for the programmer, is that it seems like
the wrong kind of error (a fatal error rather than a typing or
'unbound' error).  Maybe I'm being too nitpicky?  Have I made
any wrong assumptions here?

Thanks for any feedback!                          -- Neil Inala


==== begin code section 1 =========
class virtual foo =
  object (_: 'a)
    method virtual make_altered_self : unit -> 'a
  end

class bar =
  object (self)
    inherit foo
    val v = 3
    method make_altered_self () = {< v = 5 >}
  end
==== end code =====================

==== begin code section 2 =========
class virtual foo =
  object (_: 'a)
    method virtual make_altered_self : unit -> 'a
  end

class bar =
  object (self)
    inherit foo
    method make_altered_self () = {< v = 5 >}
    val v = 3
  end

==== end code =====================

==== begin code section 3 =========
  try
    parse_file inputfile Parse.implementation ast_impl_magic_number
    ++ print_if ppf Clflags.dump_parsetree Printast.implementation
    ++ Typemod.type_implementation sourcefile prefixname modulename
env
    ++ Translmod.transl_implementation modulename
    ++ print_if ppf Clflags.dump_rawlambda Printlambda.lambda
    ++ Simplif.simplify_lambda
    ++ print_if ppf Clflags.dump_lambda Printlambda.lambda
    ++ Bytegen.compile_implementation modulename
    ++ print_if ppf Clflags.dump_instr Printinstr.instrlist
    ++ Emitcode.to_file oc modulename;
    Warnings.check_fatal ();
    remove_preprocessed inputfile;
    close_out oc;
  with x ->
    close_out oc;
    remove_file objfile;
    raise x

==== end code =====================

==== begin code section 4 =========
  match exp with
    Lvar id ->
      begin try
        let pos = Ident.find_same id env.ce_stack in
        Kacc(sz - pos) :: cont
      with Not_found ->
      try
        let pos = Ident.find_same id env.ce_heap in
        Kenvacc(pos) :: cont
      with Not_found ->
      try
        let ofs = Ident.find_same id env.ce_rec in
        Koffsetclosure(ofs) :: cont
      with Not_found ->
        Format.eprintf "%a@." Ident.print id;
        fatal_error ("Bytegen.comp_expr: var " ^ Ident.unique_name
id)
      end
==== end code =====================






__________________________________________________
Do You Yahoo!?
Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr


  parent reply	other threads:[~2001-11-27 17:03 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-02 17:53 [Caml-list] replay debugger Yoann Padioleau
2001-10-04 12:39 ` Xavier Leroy
2001-11-26 14:51   ` Fergus Henderson
2001-11-26 16:14     ` Xavier Leroy
2001-11-26 18:40     ` [Caml-list] Beware of compare (and Ocaml beaten by Java) Mattias Waldau
2001-11-27  9:21       ` Xavier Leroy
2001-11-27  9:41         ` Mattias Waldau
2001-11-30  9:12           ` Pierre Weis
2001-12-03 21:37             ` Chris Hecker
2001-11-27 17:03         ` Neil Inala [this message]
2001-11-28 20:15           ` [Caml-list] bytegen.comp_expr error when doing object copying Xavier Leroy

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=20011127170352.63710.qmail@web14609.mail.yahoo.com \
    --to=inalan@yahoo.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).