Announce: Enki 1.0

[pragma]

In article <e64msu$19ck$1 at digitaldaemon.com>, Craig Black says...
>
>Very cool!

Thank you!


>Did you create this with a particular application in mind, or just as a 
>generic tool?

I dreamed this up as a generic tool since I always wanted something like this to
take a lot of the make-work out of things.  Plus, I found myself repeating
certain patterns and idioms *a lot* with only the grammar being the real
difference.  So there we have it.

I'm currently leveling my sights on a ddoc tool, and plan on using it for the
next iteration of DSP, once DDL is done.  

I *don't* plan on using it to parse binaries in DDL since I want to retain a
tighter control on the lower-level parsing behavior than Enki allows.  Plus Enki
doesn't quite have enough support for binary parsing, yet.

>
>I'm just curious, have you done any performance comparisons between the 
>hard-coded vs. self-hosting versions of Enki?

Its funny you say that: there never was a "hard-coded" version per-se.  I simply
started writing in bootstrap.d once I developed the baseline BNF for Enki's
grammar, and then refined it from there.  As bootstrap.d is just a parse-tree
(you could say that I played the role of parser), there's only the generated
frontend parser. So there's nothing to compare it against.

As with all machine-generated parsers, its not going to beat a hand-coded
implementation in terms of raw speed.  So because of that, I never really did
any side-by-side comparisons and just focused on making the codegen as efficent
as was practical.

>Do you think the D front end could benefit from using this technology?

Possibly, at least for the sake of having something easier to hack on for other
projects.  Not that Walter's C++ code is hard to follow, but I've seen so many
frontend projects crushed by grammar changes and bugfixes.  With a distinct
frontend, backed by an easy to change EBNF definition, at least the former won't
be a problem.



- EricAnderton at yahoo