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

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

[yoann padioleau]

> 
> > BTW, I dont know if your grammar talks about C, but in C you can even write
> >  "long const extern long a;"
> 
> The grammar in question is the Felix grammar, which is a kind
> of hybrid syntax between C++ and ML. It make no pretense
> of being an upgrade of C++ syntactically .. however I do
> try to keep enough familiar things in it that it won't
> be quite as scary as Ocaml or Haskell.

You should put a <shameless-advertising> around such statements :) 

Did you intentionnaly post your previous message to be able to get more attention on felix :) 


> 
> Felix uses "vlong" for C's "long long" .. not hard to 
> learn, but every new thing you have to learn is a barrier
> to acceptance.


> 
> -- 
> 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 Fri, 2005-11-18 at 17:34 +0100, yoann padioleau wrote:
> > 
> > > BTW, I dont know if your grammar talks about C, but in C you can even write
> > >  "long const extern long a;"
> > 
> > The grammar in question is the Felix grammar, which is a kind
> > of hybrid syntax between C++ and ML. It make no pretense
> > of being an upgrade of C++ syntactically .. however I do
> > try to keep enough familiar things in it that it won't
> > be quite as scary as Ocaml or Haskell.
> 
> You should put a <shameless-advertising> around such statements :) 
> 
> Did you intentionnaly post your previous message to be able to get 
> more attention on felix :) 

Nope. 

It is more by way of explanation. You said "I don't know if your
grammar talks about C ..", and I explained the context.

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

[yoann padioleau]

> 
> > 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 ;-).

except that sometimes there is some space, comments, between the 2 "long", so the regexp for "long long" would
be uselessly complicated. 

BTW, I dont know if your grammar talks about C, but in C you can even write
 "long const extern long a;"

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

[skaller]

On Fri, 2005-11-18 at 15:40 +0100, yoann padioleau wrote:

> except that sometimes there is some space, comments, between the 2 "long", 
> so the regexp for "long long" would
> be uselessly complicated. 

Yes, but I have a token filter sitting in between the lexer
and parser anyhow .. I just forgot about it. It already chucks
out comments and spaces. It's there for the reason you mention .. 
and also because it is cheaper (lexers get rather large if you 
give them too much work).

> BTW, I dont know if your grammar talks about C, but in C you can even write
>  "long const extern long a;"

The grammar in question is the Felix grammar, which is a kind
of hybrid syntax between C++ and ML. It make no pretense
of being an upgrade of C++ syntactically .. however I do
try to keep enough familiar things in it that it won't
be quite as scary as Ocaml or Haskell.

Felix uses "vlong" for C's "long long" .. not hard to 
learn, but every new thing you have to learn is a barrier
to acceptance.

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

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