Right now, what's the most important for the success and adoption of D?
Jascha Wetzel
firstname at mainia.de
Sat Sep 29 09:05:43 PDT 2007
Jari-Matti Mäkelä wrote:
> Your web page says "It provides access to an AST and an ASG of a D source
> file". So does the ASG part mean that it creates pointers from identifiers
> to declarations using the D scope rules?
It creates a separate graph that interconnects Declaration objects
(among others) that in turn point to the identifiers and line/column
numbers in the source file. Search and enumeration of this graph is done
by applying the D scope rules.
> Is it possible to modify that data
> structure later or should one just clone the AST if further processing is
> needed?
It will be the preferred way to modify the ASG with simply operations
and generate a new (full or partial) AST from the modified ASG when
required. As of now (v0.01.2 alpha) no modification is supported, though.
> Comparing LOC is a bit pointless since the SEATD parser is machine
> generated - dil could be made shorter too with e.g. the coming macros
> without losing much readability.
I don't think it's pointless. We're talking about 6 times the size.
Maintaining that much code is considerably more work. SEATD's ~2000 LOC
already include some semantic analysis. Plus, the grammar definition has
significantly less technical detail to deal with and is therefore less
error prone.
> You mentioned compact editors in the other
> thread. One downside of SEATD is that the resulting binary is about twice
> as large as my vim binary. Doesn't sound very compact to me, but maybe that
> wasn't the point.
With "compact" i was referring to the editors, to set them apart from a
feature rich IDE.
You still have a point there, though. SEATD's binary is indeed pretty
big (190kb with UPX, 905kb without). That is partially because it's a D
binary and therefore carries around the Tango runtime and a lot of
TypeInfos. But the generated parser still has potential to improve in
size, too. Until now i was concerned with performance optimization only.
The binary size is a minor issue, though.
More information about the Digitalmars-d
mailing list