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