pragma wrote:
> In article <e6q2pu$2cqo$1@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.

A few patches to make it compile under 0.161

--two do nothing function now cause errors, so I put assert(0)s in them.
--the variable "start" is used in nested scopes a lot, so now it is suffixed with its indent level.

e.g.
{
	uint start;
	{
		uint start;
	}
}

becomes

{
	uint start1;
	{
		uint start2;
	}
}



www.uidaho.edu/~shro8822/enki_patch_161.zip

In article <e79r5q$1ds7$9@digitaldaemon.com>, BCS says...
>
>A few patches to make it compile under 0.161
>
>--two do nothing function now cause errors, so I put assert(0)s in them. --the variable "start" is used in nested scopes a lot, so now it is suffixed with its indent level.
>
>e.g.
>{
>	uint start;
>	{
>		uint start;
>	}
>}
>
>becomes
>
>{
>	uint start1;
>	{
>		uint start2;
>	}
>}
>
>
>
>www.uidaho.edu/~shro8822/enki_patch_161.zip

Thanks!  I was just going to get a patch underway for that - I'll take a look at your submission.


- EricAnderton at yahoo

In article <e6ntg4$270o$1@digitaldaemon.com>, pragma says...
>
>Enki 1.1 is now available.
>
>Documentation (still in progress)
>http://www.dsource.org/projects/ddl/wiki/Enki
>
[...]

Yet another patch!!!!!

This time to the grammar. Enki won't allow a rule of the form

#            v-- note second []
Rule = char[][] var ::= ["foo":var  Rule:~var]

This would logically generate an array of arrays of char. Adding it doesn't seem to brake anything.

*** enki.bnf	Mon Jun 26 21:24:51 2006
--- enki.bnf	Mon Jun 26 18:56:07 2006
***************
*** 94,100 ****

ExplicitParam
= new Param(bool isArray,String type,String name)
! 	::=  Identifier:type  ws [ "[]":isArray ws]  Identifier:name ;
#
#  Expressions
#
--- 94,103 ----

ExplicitParam
= new Param(bool isArray,String type,String name)
! 	::=  Identifier:type  ws [ "[]":isArray Brackets ws]  Identifier:name ;
!
! Brackets ::= ["[]" Brackets];
!
#
#  Expressions
#

In article <e7qdln$juq$1@digitaldaemon.com>, BCS says...
>
>In article <e6ntg4$270o$1@digitaldaemon.com>, pragma says... [...]
>
>Yet another patch!!!!!
[...]
>Adding it doesn't seem to brake anything.
>

How to change a program:
1: think
2: try
3: TEST
4: tell

I forgot #3, sure, the patched version parses the BNF and even generates code, but the generated code doesn't compile . :op It's making some assumptions that I voided, I'll try to get a working version sooner or later.

In article <e7qngu$10lt$1@digitaldaemon.com>, BCS says...
>
>In article <e7qdln$juq$1@digitaldaemon.com>, BCS says...
>>
>>In article <e6ntg4$270o$1@digitaldaemon.com>, pragma says... [...]
>>
>>Yet another patch!!!!!
>[...]
>>Adding it doesn't seem to brake anything.
>>
>
>How to change a program:
>1: think
>2: try
>3: TEST
>4: tell

Exactly!

>
>I forgot #3, sure, the patched version parses the BNF and even generates code, but the generated code doesn't compile . :op It's making some assumptions that I voided, I'll try to get a working version sooner or later.
>

No worries.  I'm *way* behind schedule on everything these days (being off your ass with a bad cold will do that).  I'll get to folding your contributions in as soon as I can get to it. :)

Thank you for helping out !

- EricAnderton at yahoo

pragma wrote:
[...]

> No worries.  I'm *way* behind schedule on everything these days (being off your
> ass with a bad cold will do that).  I'll get to folding your contributions in as
> soon as I can get to it. :)
> 
> Thank you for helping out !
> 
> - EricAnderton at yahoo

Some cases of negation will result in illegal code

{
	...
	mismatch53:
		// nothing to label
}

this patch should fix the problem. (don't count on it to apply, I had to hand edit it to remove my other changes.) Another solution would be to make an emptyExpression render to "{}" rather than nothing.

*** enki/Expression.d	Mon Jul 17 18:15:04 2006
--- enki/Expression.d	Mon Jul 17 22:55:01 2006
***************
*** 776,792 ****
  			emit("{//Negate");
  			indent();
  				render(expr,gotoMatch,gotoMismatch);
  								
  				render(matchLabel);
  				render(fail);
  				
  				render(mismatchLabel);
+ 				if(pass.isEmpty) emit("{}");
  				render(pass);
  			unindent();
  			emit("}");
  		}		
  	}
  	
  	public String toBNF(){
  		 return "!" ~ expr.toBNF();
--- 776,791 ----