Related articles |
---|
[2 earlier articles] |
Re: Editing/storing syntax trees stefan.monnier@epfl.ch (Stefan Monnier) (1995-06-05) |
Re: Editing/storing syntax trees hbaker@netcom.com (1995-06-23) |
Re: Editing/storing syntax trees daniels@cse.ogi.edu (1995-06-23) |
Re: Editing/storing syntax trees bevan@cs.man.ac.uk (1995-06-23) |
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: | preston@tera.com (Preston Briggs) |
Keywords: | parse |
Organization: | Tera Computer Company, Seattle, WA |
References: | 95-04-013 95-06-022 |
Date: | Sat, 24 Jun 1995 12:14:31 GMT |
Status: | RO |
>] I disagree. ASCII source is actually a fine representation, small and
>] convenient. Syntax trees, on disk, are bulky and inconvenient.
>
>But "on disk" might be in the same address space if you have a SASOS coupled
>with a persistent object store, in which case you don't care that much about
>"bulkyness".
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 suppose you could argue that the time between when I say "compile"
and when it's done counts for quite a bit more. Perhaps. Probably
depends on how much spare disk space you've got lying around.
Preston Briggs
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.