Related articles |
---|
[6 earlier articles] |
Re: Editing/storing syntax trees frode@news2.deltanet.com (Frode Odegard) (1995-06-24) |
Re: Editing/storing syntax trees hagerman@ece.cmu.edu (1995-06-24) |
Re: Editing/storing syntax trees preston@tera.com (1995-06-24) |
Re: Editing/storing syntax trees jhallen@world.std.com (1995-06-27) |
Re: Editing/storing syntax trees boggs@osage.csc.ti.com (1995-06-27) |
Re: Editing/storing syntax trees stefan.monnier@epfl.ch (Stefan Monnier) (1995-06-27) |
Re: Editing/storing syntax trees stefan.monnier@epfl.ch (Stefan Monnier) (1995-06-27) |
Newsgroups: | comp.compilers |
From: | Stefan Monnier <stefan.monnier@epfl.ch> |
Keywords: | parse, design |
Organization: | Ecole Polytechnique Federale de Lausanne |
References: | 95-04-013 95-06-057 |
Date: | Tue, 27 Jun 1995 17:01:17 GMT |
Preston Briggs <preston@tera.com> wrote:
] But you do (or anyway I do) care. Consider Time x Space. Most of the
] time, on my system, my programs lie about on disk in source form --
] perhaps even in compressed source form. Very occasionally, I compile
] one of them. The scanner and parser build the (larger) syntax tree
] form, very quickly, and the optimizer pores over it, and it's thrown
] away.
]
] In your approach, the big form exists all the time. Somebody pays for
] that Space x Time.
I don't see why the syntax tree should be that much bigger than ASCII. Noone
asked to store the syntax tree with all the data/control flow and whatnot
information. Just the bare syntax tree.
Stefan
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.