Enki 1.1 Released

[pragma]

In article <e6q2pu$2cqo$1 at digitaldaemon.com>, BCS says...
>
>pragma wrote:
>> In article <e6ptut$2c61$1 at digitaldaemon.com>, BCS says...
>> 
>>>>>.import("my.import.here");
>>>>
>>>Are these imports not always needed? Won't any parser use things from 
>>>these modules? I would think that the basic imports _should_ be hard 
>>>coded (or at least implicitly added to the imports list).
>>>
>>>On further thought only "enki.types" will _always_ be needed. 
>>>"enki.BaseParser" will only be used if the default base class is used. 
>>>But this is detectable, so again, it should be emitted unless the base 
>>>class is changed.
>> 
>> 
>> I'm inclined to agree, but its also at cross-purposes with the philosophy I had
>> in mind with the tool.  I really think that it should try to impose as little as
>> possible, wherever possible.  In this case, what happens if the user moves or
>> renames 'types.d' to something else, or merged the templates in with their base
>> parser?  I'd rather make imports explicit so the developer has this flexibility.
>> 
>> 
>
>OK I'll grant that things might move, however in the general case those 
>imports will be needed by most people. Good defaults make for good 
>programs. How about make those imports the default and put in some sort 
>of Override directive.

That's not a bad idea.  Something like a .supportlib() directive or something.
I'll consider it. :)

>
>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.  

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.

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;

>.parsetype(baz)

A wonderful idea.  This way Enki can use this as the default binding type when
it encounters expressions like the one above.


- EricAnderton at yahoo