From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id B1CEDBC6B for ; Wed, 31 Oct 2007 08:16:12 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAABfIJ0eAKs4Fnmdsb2JhbACOZAIBAQcEBhEY X-IronPort-AV: E=Sophos;i="4.21,350,1188770400"; d="scan'208";a="3864941" Received: from netscaler2.rice.edu (HELO mh1.mail.rice.edu) ([128.42.206.5]) by mail1-smtp-roc.national.inria.fr with ESMTP; 31 Oct 2007 08:16:11 +0100 Received: from mh1.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh1.mail.rice.edu (Postfix) with ESMTP id E8C37385350; Wed, 31 Oct 2007 02:16:09 -0500 (CDT) X-Virus-Scanned: by amavis-2.4.4 at mh1.mail.rice.edu Received: from mh1.mail.rice.edu ([127.0.0.1]) by mh1.mail.rice.edu (mh1.mail.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMINBN1DiEiK; Wed, 31 Oct 2007 02:16:09 -0500 (CDT) Received: from [192.168.1.102] (c-98-195-25-217.hsd1.tx.comcast.net [98.195.25.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mh1.mail.rice.edu (Postfix) with ESMTP id A7CC238532D; Wed, 31 Oct 2007 02:16:09 -0500 (CDT) In-Reply-To: <1193814307.8355.68.camel@rosella.wigram> References: <6C4DFFEF-0A5E-496F-9468-56693FFA4DC2@cs.rice.edu> <1193753915.47273d3bb15f2@webmail.in-berlin.de> <23EC0ABA-12EE-49DE-B76A-1D91BCCAE1BA@cs.rice.edu> <1193809920.8355.41.camel@rosella.wigram> <1193814307.8355.68.camel@rosella.wigram> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <117B8C1B-3586-4A77-B3B6-5FF881BE8B62@cs.rice.edu> Cc: caml-list@yquem.inria.fr Content-Transfer-Encoding: 7bit From: Angela Zhu Subject: Re: Re: Re: [Caml-list] Problem with precedence declaration in .mly file Date: Wed, 31 Oct 2007 02:16:07 -0500 To: skaller X-Mailer: Apple Mail (2.752.3) X-Spam: no; 0.00; ocaml:01 expr:01 expr:01 syntax:01 syntax:01 parser:01 angela:98 angela:98 2007,:98 .....:98 wrote:01 wrote:01 precedence:01 integer:01 integer:01 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 > Felix, successor to C++: http://felix.sf.net >