Browse thread
ocamlyacc -- can i tell it to be quiet?
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2005-11-18 (15:59) |
From: | skaller <skaller@u...> |
Subject: | Re: [Caml-list] ocamlyacc -- can i tell it to be quiet? |
On Fri, 2005-11-18 at 15:16 +0100, Sebastian Egner wrote: > > > The following leads to shift reduce conflict: > > > > ctype_name: > > | LONG LONG > > | LONG > > > > Yacc is very weird -- I can parse a list of LONG without > > a conflict .. but not two of them?? > > > > Is there any way to tell it to shut up? > > Rather than trying to solve this in the LALR parser .. > the easiest way is to adapt the _lexer_ to produce two > different tokens for "long" and for "long long" Argg. I feel dumb! VERY dumb!! You are right! My lexer produces a list of tokens, which are then preprocessed to make them easier to parse: Felix only has one filter, to strip out whitespace and comments: (* 1: remove comments *) let filter_comments x = let rec filter x' result = match x' with | COMMENT_NEWLINE _ :: t | COMMENT _ :: t | NEWLINE :: t | WHITE _ :: t -> filter t result | h :: t -> filter t (h::result) | [] -> List.rev result in filter x [] let translate ts = let filters = [ (* 1 *) filter_comments ] and reverse_apply dat fn = fn dat in List.fold_left reverse_apply ts filters but it is trivial to add another one to compress multi-word C type names (such as long long). Originally, this code was used in Vyper to preprocess tokens: Vyper was an Ocaml based Python interpreter, and Python is a bit nasty to parse with an LALR1 parser -- it took 13 or so prepasses on the token stream to prepare it (indent/dedent processing, and the weird Pythonism allowing a trailing comma in tuples like (1,2,) being the hardest to manage). So actually .. I don't even have to modify the Ocamllex lexer at all, not even to make these names keywords, all the technology is in place already -- thanks for reminding why its there!! -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net