Walnut

[Alan Knowles]

Yes, sounds like a good approach.. -

Might be worth playing with naming the Parse methods around the Grammer 
as documented in the ECMAScript spec.

eg. something like:

// methods? returns 1 if statement found?? or should it just throw an 
exception???
bool Statement(bool execute=true)
{
	switch(tok) {
		case '{': // Block:
			while(Statement());
			if (tok != '}') throw Error....
		case TEXT.var: //   VariableStatement:
			while(VariableStatement());
			if (tok != ';') throw Error....			
		case ';': // EmtpyStatement:
			return 1;
		
ExpressionStatement:  -- this may be tricky.. (it uses lookahead?)
		case TEXT.if:
			if (tok != '(') throw Error....
			bool doif = Expression(); // return true|false?
			if (!Statement(doif)) throw Error...
			if tok == TEXT.else
				if (!Statement(!doif)) throw Error...	
			
  IterationStatement:
  ContinueStatement:
  BreakStatement:
  ReturnStatment:
  WithStatement:
  LabelledStatement:
  SwitchStatement:
  ThrowStatement:
  TryStatement:


Regards
Alan


Dan wrote:
> Alan Knowles Wrote:
> 
>>   .
>>> Yes, except the object isn't to copy DMDScript without the license,
>>> the objective is to create an engine that's significantly better.  At
>>> the moment, I would say roughly half the code is written and I'm
>>> using 108KB vs DMDScript's 513KB.  The parser is the only remaining
>>> component before it can (incorrectly) run javascript files.  The rest
>>> is debugging.
>>>
>> so is the idea to run the interpreter inside the parsing engine? or are 
>> you going to generate opcodes? - It wasn't quite clear?
>>
>> Regards
>> Alan
>>
> 
> Would you believe me if I said combinations of both?
> 
> For now I want to do this:
> 0) interpret top-level, and compile functions and loops to unoptimized native for execution (probably default behavior)
> 
> Later, I'd like it to be able to:
> 1) tokenize everything and serialize the output.
> 2) interpret everything on-the-fly, using bytecode for loops, functions
> 3) compile the whole program to unoptimized native and serialize the output.
> 4) run serialized token streams, and serialized compiled scripts.
> 
> I'm aware that's a tall order.  That's why I'm not scheduling all those for Walnut 2.0.  They'll come with following minor versions.
> 
> Regards,
> Dan