Enki 1.1 Released

[pragma]

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.

>
>And on another topic: another hack
>
>It fixes a default case bug. Without it any rule of the form
>
>rule ::= (foo bar)
>
>always matches even if both foo and bar don't match. The case where the 
>rule has annotations works as advertised.
>
><patch>
>*** old\enki\Rule.d	Wed Jun 14 13:50:06 2006
>--- new\enki\Rule.d	Wed Jun 14 13:50:59 2006
>***************
>*** 241,251 ****
>   	}
>   	
>   	public void renderPass(CodeGenerator generator){
>! 		generator.emit("return ResultT!(bool)(true);");
>   	}
>   	
>   	public void renderFail(CodeGenerator generator){
>! 		generator.emit("return ResultT!(bool)(false);");
>   	}
>   	
>   	public void semanticPass(Rule thisRule,BaseEnkiParser root){
>--- 242,252 ----
>   	}
>   	
>   	public void renderPass(CodeGenerator generator){
>! 		generator.emit("return ResultT!(bool)(true,true);");
>   	}
>   	
>   	public void renderFail(CodeGenerator generator){
>! 		generator.emit("return ResultT!(bool)(false,false);");
>   	}
>   	
>   	public void semanticPass(Rule thisRule,BaseEnkiParser root){
></patch>

Ah, now that's a serious bug.  Thanks for tracking it down.  I'm glad that
things are written such that you can find this stuff so easily.  Thanks for the
patch!

Another way to tackle this would be tochange the failure rule to this:

>   	public void renderFail(CodeGenerator generator){
>! 		generator.emit("return ResultT!(bool)();");
>   	}

Which is equivalent.  When I get around to expanding the docs to detail how to
write custom rules, this will make more sense.

- EricAnderton at yahoo