Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] On ocamlyacc and ocamllex
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Vesa Karvonen <vesa.karvonen@h...>
Subject: Re: [Caml-list] On ocamlyacc and ocamllex
From: "Christian Lindig" <lindig@eecs.harvard.edu>
> On Sun, Sep 23, 2001 at 10:32:23PM +0300, Vesa Karvonen wrote:

> I lobbied for this three years ago and had a patch for ocamllex:
>
>     http://www.eecs.harvard.edu/~lindig/software/lex-patch.html

Yes. I just visited your homepage. I find it odd that it has not yet been
adopted. Looking back at Ocaml mailing list archives, I think that this
extension should perhaps be proposed again. Perhaps it was caused by my search
paratemeters, but I found no responses from Ocaml team members to this
proposal. Perhaps they missed it or just forgot about it.

> > Can this technique be used for adding context to parsers generated
> > using ocamlyacc, too?
>
> I'm not sure what you mean here. A Yacc parser works bottom up - do you
> want to inject "context" into the tokens that are received from the
> lexer?

I want good error messages from the parser. I want the parser to have access
to the line number information generated by the lexer. A simple way to let the
parser have access to the information would be to pass it as a parameter to
the parsing action code.

So, is there a simple way to have a reentrant lexer and parser generated by
ocamllex and ocamlyacc that would have line number information?

I don't want to annotate all tokens by a line number. Furthermore, the Parsing
module needs to be replaced at any rate because it has global state.

The compiler we are implementing may be used by rather novice programmers (or
actually non-programmers), so I'm willing to spend extra time polishing just
the error messages, so that I don't have to spend the same amount of time (or
possibly a lot more) explaining the errors to the users.

> I agree that this alternative avoids the dependency of the type
> definition on the grammar. But I am not sure that manually keeping the
> type definition and the %token declarations in the parser in sync is
> better than automatic recompiles or a little Make hack.

The idea is that the .mly file would no longer have %token definitions.
Instead it would have a definition such as follows:

    %token_type My_token_module.my_token_type

This would cause ocamlyacc to read the my_token_type constructor names from
the My_token_type module.

Alternatively, the technique could be more low level. For instance:

    %token_type my_token_module.mli

Which would simply read the first type definition from the my_token.mli file.


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