Browse thread
Problem with precedence declaration in .mly file
[
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: | -- (:) |
| 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
>