Version française
Home     About     Download     Resources     Contact us    
Browse thread
Problem with precedence declaration in .mly file
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Angela Zhu <angela.zhu@c...>
Subject: Re: Re: Re: [Caml-list] Problem with precedence declaration in .mly file
Thanks a lot for your detailed explanation.
The problem is that now the AST for my language is getting really big.
I am not sure how much work it will take.

Best regards,
Angela
------------------------------------------
Dept. of CS, Rice Unitersity
http://www.cs.rice.edu/~yz2/
------------------------------------------



On Oct 31, 2007, at 2:05 AM, skaller wrote:

>
> On Wed, 2007-10-31 at 01:02 -0500, Angela Zhu wrote:
>>>
>>>
>>> DO NOT USE THEM. The rules are hard to explain and very badly
>>> designed, in other words, they're a hack. Ocaml provides
>>> them for compatibility with older yacc like tools.
>>>
>>> Write your grammar properly instead, in pseudo code:
>>>
>>> 	term = factor | term + factor
>>> 	factor = atom | factor * atom
>>> 	atom = INTEGER | ( term )
>>
>> ... Then I need to change my whole AST.....
>> :(
>
> Yes, that's possible. The 'simple' AST isn't efficient,
> that is, where you have a variant
>
> 	type term = Term_Factor of factor | Term_plus of term * factor
>
> because of the first case. However this isn't necessary if you just
> use something like
>
> 	type expr = Integer of int | Apply of string * expr list
>
> then you can just do:
>
> 	term:
> 	| factor { $1 }
> 	| term + factor { Apply  ("+",[$1;$3]) }
>
> and similarly for the other productions. The typing here
> is weaker than you may want, for example you can get
> nonsense like
>
> 	Apply ["*",Integer 1]
>
> so you might try a safer encoding, eg using
>
> 	| Integer of int
> 	| Unary of string * expr
> 	| Binary of string * expr * expr
> 	
>
> The point is, this AST is still less structured than one
> which exactly reflects the syntax tree -- but that is the
> point of an 'Abstract' syntax tree (AST).
>
> Exactly how much work you do in the parser is a difficult
> design choice.
>
>
> -- 
> John Skaller <skaller at users dot sf dot net>
> Felix, successor to C++: http://felix.sf.net
>