Walnut

Alan Knowles alan at akbkhome.com
Thu Jan 3 15:53:31 PST 2008


Just checking the code against this - Why are you not using Type|Token 
numbers for the Keywords
...
	case TEXT_case:
                   v.s = TEXT_case;
                   v.type = TYPE.KEYWORD;
                   return v;
...

would work alot better as:
	
	switch(word) {
		case "case" : v.type   = Token.CASE;  return v;
		case "if" :   v.type   = Token.IF;    return v;
		case "else" : v.type   = Token.ELSE;  return v;		
		....
Thinking about this - it may be a good idea to
alias TYPE Token;

It will give you quite a good readability gain.

Regards
Alan







Alan Knowles wrote:
> 
> That little snippet reminded me of another trick:
> 
> Dont create Tokens for single character Tokens - eg. -,=,",',..... etc.
> Start the Token Enum from 127.
> 
> In the case of your Value Type Enum, this should be ok. (may take a bit 
> of fudging with the Typedefs on Value.type / Enum creation.)
> 
> This enables you to do stuff like the example below:
> 
> switch(Value.type) {
>     case ':':
>     case Token.IF:
>     case '=':
> 
> Which makes the code considerably more readable. (no remembering what 
> Token.LT Token.GT where supposed to be...
> 
> Regards
> Alan
> 
> 
> 
> 
> Alan Knowles wrote:
>> 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


More information about the Digitalmars-d-learn mailing list