ocamlyacc -- can i tell it to be quiet?

ocamlyacc -- can i tell it to be quiet?

[skaller]

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?

[My script considers any conflict a fatal error]

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] ocamlyacc -- can i tell it to be quiet?

[Sebastian Egner]

[-- Attachment #1: Type: text/plain, Size: 575 bytes --]

> 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 (which
might involve a major rewrite of the grammer in this case),
the easiest way is to adapt the _lexer_ to produce two
different tokens for "long" and for "long long": The lexer
(ocamllex) always goes for the longest match, and in this
case this is what you want ;-).

Sebastian.

[-- Attachment #2: Type: text/html, Size: 944 bytes --]

Re: [Caml-list] ocamlyacc -- can i tell it to be quiet?

[skaller]

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

Re: [Caml-list] ocamlyacc -- can i tell it to be quiet?

[skaller]

On Sat, 2005-11-19 at 01:08 +1100, skaller 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?? 

Oopps, sorry, another case of find the bug immediately after
posting .. lol .. the conflict is not in the above productions, 
but only in combination with another production
which is effectively:

name: ctype_name

application:
  | name name
  | name

so of course there is a real conflict .. 

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] ocamlyacc -- can i tell it to be quiet?

[Jon Harrop]

On Friday 18 November 2005 14:08, skaller 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??

I'm not a yacc expert but there seem to be two possibilities:

1. The same action is repeated, in which case "LONG LONG" is superfluous and 
can be removed.

2. The two actions are different, in which case you need to tell yacc that 
LONG LONG has a higher precedence:

%nonassoc LONG
%prec long_long
...
ctype_name:
| LONG LONG %prec long_long { ... }
| LONG { ... };

I think this is equivalent to the dangling "else" problem. Anyway, you 
shouldn't be parsing C++, it is bad for your health. ;-)

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] ocamlyacc -- can i tell it to be quiet?

[Christian Lindig]

On Nov 18, 2005, at 3:08 PM, skaller wrote:
> Is there any way to tell it to shut up?

If you have a shift/reduce conflict the default action is to shift. To 
get rid of the warning declare a higher precedence for the symbol being 
shifted. Say, there is a conflict when parsing FOO BAR - FOO could be 
reduced or BAR being shifted; declare in your Yacc file:

%nonassoc FOO
%nonassoc BAR

Nor BAR has higher precedence and gets shifted without creating a 
conflict. Obviously, this kind of conflict resolution requires some 
care.

-- Christian