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