caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Vesa Karvonen" <vesa.karvonen@housemarque.fi>
To: <caml-list@inria.fr>
Subject: Re: [Caml-list] On ocamlyacc and ocamllex
Date: Sun, 23 Sep 2001 19:27:36 +0300	[thread overview]
Message-ID: <001501c1444c$a7b0a720$422aa8c0@housemarque.fi> (raw)
In-Reply-To: <20010922211013.A580@eecs.harvard.edu>

From: "Christian Lindig" <lindig@eecs.harvard.edu>
> On Sun, Sep 23, 2001 at 12:09:14AM +0300, Vesa Karvonen wrote:
> > I would like to make it so that the lexer would record the positions
> > of line breaks so that I could directly give line number and column
> > information in error messages.
[snip snip]
> The particular problem can be solved outside of Lex and Yacc: in the
> Quick C-- compiler we have a mutable Sourcemap.map data type that
> records the connection between character positions and
> (file,line,column) triples.

This is basically the same technique that I have been using. The problem is
that the map has to be global, because the only context passed to the lexer
actions is the lexbuf. Furthermore, the records need to be manually removed
(in order to save memory) after a file has been processed completely and the
recorded connections for the file are no longer needed.

An extendable lexer makes it possible to extend the context passed to the
lexer actions so that globals can be avoided.

> I agree that more flexible lexer and parser generators would be nice and
> have myself lobbied for them in the past. On the other hand I have
> always found my way with the existing ones which probably is the reason
> that we still use them.

Replacing the Lex and Yacc modules turned out to be simpler than I thought.
I'm almost done with writing replacements for the Lexing and Parsing modules.
I have written replacement modules called Lex and Yacc. The Lex module defines
an abstract parameterized type lexbuf like this:

    type 't lexbuf
    val access : 't lexbuf -> 't
    val from_channel : in_channel -> 't -> 't lexbuf
    ...

It is now possible to make a simple module for tracking line numbers:

    type t
    val make : unit -> t
    val new_line_at_pos : t -> int -> unit
    val line_and_col_of_pos : t -> int -> int * int

And then extend the lexbuf with the line map:

    val from_channel : in_channel -> Line_map.t Lex.lexbuf
    val new_line : Line_map.t Lex.lexbuf -> unit
    ...

and use those functions in the lexer actions:

    '\n' { new_line lexbuf; token lexbuf; }
    ...

I have made it so that the ocamlyacc and ocalmlex generated files go through
sed commands which change the generated files to work with the Lex and Yacc
modules instead of the Lexing and Parsing modules.

> > Another issue with ocamllex and ocamlyacc (and lex/flex and
> > yacc/bison) is that the dependencies between the generated lexer and
> > parser are not quite optimal. Currently the generated lexer is
> > dependent on the parser, because the parser generates the token type.
> > This means that each time the grammar is modified, but not the token
> > definitions, the lexer is recompiled. This could be avoided by making
> > it so that the token type is defined in a separate module.
>
> This is a general problem with make: when you edit a comment, a file is
> touched and all dependent files must be recompiled.
[...]

I think that you slightly misunderstood.

The basic idea was to put the token type definition into a separate module.
Instead of two source files, you would have three source files:

    lexer.mll
    token.ml
    parser.mly

The token definition is now effectively demoted into its own module which is
now dependent upon by the lexer and parser modules.

In parser.mly there would be code that would tell ocamlyacc to look at
token.ml for the token type.


-------------------
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


  reply	other threads:[~2001-09-23 16:24 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-22 21:09 Vesa Karvonen
2001-09-23  1:10 ` Christian Lindig
2001-09-23 16:27   ` Vesa Karvonen [this message]
2001-09-23 17:44     ` Christian Lindig
2001-09-23 19:32       ` Vesa Karvonen
2001-09-23 20:09         ` Christian Lindig
2001-09-23 20:51           ` Vesa Karvonen
2001-10-22 17:09           ` John Max Skaller
2001-10-22 16:47       ` John Max Skaller
2001-09-24  1:05 ` Christian RINDERKNECHT
2001-09-24 11:17   ` Vesa Karvonen
2001-10-22 17:24     ` John Max Skaller

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='001501c1444c$a7b0a720$422aa8c0@housemarque.fi' \
    --to=vesa.karvonen@housemarque.fi \
    --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).