From: "Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl>
To: dido@imperium.ph
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] handling forward references in a compiler
Date: Wed, 26 May 2004 13:31:42 +0200 [thread overview]
Message-ID: <1085571101.23506.15.camel@qrnik> (raw)
In-Reply-To: <20040525095213.GA2655@imperium.ph>
W liście z wto, 25-05-2004, godz. 17:52 +0800, dido@imperium.ph napisał:
> I'm writing a compiler for a language that allows undeclared forward
> references in OCaml, and I'm just wondering how one is supposed to
> handle these sorts of things without resorting to imperative features or
> multiple passes.
These are indeed two most obvious choices. I prefer the second one.
In the first pass we scan only "heads" of definitions, creating an
environment which maps strings to some unique ids. In the second pass
we know the meaning of each identifier, so we can process code normally
no matter which identifiers have their definitions before or after.
> Another option is to make a second pass through the
> generated intermediate representation, and fixing up the forward
> references after all of the declarations have been processed, but this
> seems like a second traversal that can be avoided.
There is no need to have a separate pass which only patches references.
You just lookup references in the previously constructed environment
as necessary, when processing the code tree in the next pass which also
does whatever it was supposed to do anyway.
In a compiler I implemented it was not that easy to scan heads of
definitions, because some syntactic sugar was not yet resolved, so it
would have to be resolved twice. To avoid this, the pass which gathers
defined names also produces a modified list of definitions, with
resolved toplevel syntactic sugar, with bound names represented by
unique ids, but with everything else - in particular all embedded
expressions - left unprocessed. They are processed in the next pass,
which resolves used identifiers and expression-level syntactic sugar,
and produces a new code representation for further processing.
--
__("< Marcin Kowalczyk
\__/ qrczak@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
prev parent reply other threads:[~2004-05-26 11:31 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-25 9:52 dido
2004-05-25 11:00 ` skaller
2004-05-25 19:59 ` Evan Martin
2004-05-26 11:31 ` Marcin 'Qrczak' Kowalczyk [this message]
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=1085571101.23506.15.camel@qrnik \
--to=qrczak@knm.org.pl \
--cc=caml-list@inria.fr \
--cc=dido@imperium.ph \
/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).