Enki 1.1 Released

[BCS]

pragma wrote:
> In article <e6q2pu$2cqo$1 at digitaldaemon.com>, BCS says...
> 
>>Another thought; as it is written, Enki is purely an ASCII text program. 
>>  It would be nice if the parsed data had its own type that, is only 
>>used for the input data. This would allow for the parsing of an array on 
>>any type (enums or structs come to mind). Of course this would requirer 
>>the introduction of a new terminal matching syntax.
> 
> 
> I'm well ahead of you on this front.  I'm presently composing a lexer for D,
> which will then support a secondary parser for the lexed tokens.  Both of these
> will be Enki based.  

I'm already working on a lexer that so far does just about everything 
but numeric literals, lexing it down to an array of structs. It is 
totally native D and is done from the start with the intention that it 
be easy to change. Adding a static token type (say "~~") involves about 
three lines of code in the lexer. Adding something like a new type of 
string only involves adding two of those lines and a function to find 
the rest.

Its still a bit buggy but it works for the most part.

> 
> So far I'm starting to see the limitations of the String/char[] setup, and yearn
> for multi-byte char support.  So I'll be working on a way to provide this.  As
> far as non-ascii parsing is concerned, Enki can already support this to an
> extent.
> 

What I did for mine is make a wrapper Stream struct that presents the 
whole stream as dchars. For convenience it also catches look-ahead and such.

I'm not sure what goals your project is perusing, mine is easy 
modification targeted at alpha testing of features. However I intend to 
drop my code into the wild at some point so...

> code{{{
> enum MyType: uint{
> Foo, Bar, Baz
> }
> }}}
> 
> MyRule ::= &Foo:x &Bar:y &Baz:z;
> 
> Under the hood, Enki will generate terminal expressions for each & term, which
> are then generated as "terminal(Foo)".  As long as your base parser has a
> terminal(MyType) declared, you can handle these expressions.  It then becomes
> the responsility of that terminal to determine if the token matches or not.
> 
> As far as the internal stream of data is concerned, the IParser position() and
> sliceData() methods abstract the data away to the same extent.  When working
> with a non-text input, sliceData() can be redefined as returning something other
> than string.  The only caveat here is that you must be careful to avoid
> expressions cases where Enki will evaluate the default type of a binding to
> String:
> 
> # Enki has no clue what 'x' should be so it becomes a String
> Foobar ::= ("hello world"):x;
> 

I'll check that out.