Re: [dev] nscript - a little stack-based scripting language interpretter I wrote

From: Kris Maglione <maglione.k_AT_gmail.com>
Date: Wed, 25 Aug 2010 20:09:00 -0400

On Thu, Aug 26, 2010 at 03:02:08AM +0300, Nikhilesh S wrote:
>The current way of doing it makes the implementation very
>simple - if it encounters a '$' it just reads the variable name
>and makes a new one. If it encounters an '&', it just sets
>'callFunc' to 0 and continues like a normal name-read except it
>won't execute it now - it'll just push the object onto the
>stack. Then 'callFunc' is set back to 1 (the default).

I don't see how this is any more complicated. When a $token is
encountered, the symbol should be pushed onto the stack. Then
when def is encountered, the top two items should be popped to
the stack, and the second should be assigned to the symbol that
is the first. It's deadly simple.

As for &, I haven't looked into the VM (I'm sorry to say that
the code does not match my esthetic), but I don't think that
this would be considerably more complicated. Instead of pushing
the object on the stack, you push the symbol onto the stack,
then dereference it when you need the object. Then again, I
can't really think of a use for &tokens, so I could be wrong
there.

>Actually I will probably rewrite the whole parser in a more
>proper way some time - right now it just runs through the
>characters with a primitive state system and some
>forward-peeking, and simply executes the code as it goes by
>(the whole thing is in 'ns_interpret' in nscript.c). Should I
>use 'bison' or something instead?

God no! The whole point of stack based language is that they
don't need anything nearly as complicated as a LALR grammar. Or,
as lispers are so fond of saying, they have no grammar. The most
complicated thing you have to do is parse {} blocks. The rest is
down to your lexer, which you'd have to write for yacc anyway.

-- 
Kris Maglione
Reason should be destroyed in all Christians.
	--Martin Luther
Received on Thu Aug 26 2010 - 02:09:00 CEST

This archive was generated by hypermail 2.2.0 : Thu Aug 26 2010 - 02:12:02 CEST