View mode: basic / threaded / horizontal-split · Log in · Help
June 15, 2006
Re: Enki 1.1 Released
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.
June 20, 2006
Re: Enki 1.1 Released
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
June 21, 2006
Re: Enki 1.1 Released
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
June 27, 2006
Re: Enki 1.1 Released
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
#
June 27, 2006
Re: Enki 1.1 Released
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.
June 27, 2006
Re: Enki 1.1 Released
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
July 18, 2006
Re: Enki 1.1 Released
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 ----
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home