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