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

On Thu, 26 Aug 2010, pancake wrote:

> *) mv ReadMe README
> *) add install/uninstall/deinstall targets in makefile honoring PREFIX and DESTDIR vars
> *) CC, CFLAGS and others should be ?= and not =, this way make(1) honors the environment variables
> *) fix help message of ns to be in one line, description of what the program does must be in the manpage.
> *) 'ns' by default should read+eval one line of text. If first argument is a file, then open it, if it's '-' read from stdin.
> the current 'ns' only executes code when ^D is pressed..which is not really what read-eval-loop is..
> *) 'ns' must pop the last integer in stack and exit() with this value. or just add the 'exit' function

Done! :)

> *) follow dwm syntax (to keep same syntax in all projects)
> *) use tabs :)

Hmm... I'm really used to Allman already, but I guess I could try this.
Will 'indent -linux' work?

> *) I will prefer to have comments at the begiging of line or at least honour the 78 column rule in all files
> I understand that commenting every line in test programs is probably a good way to learn the language, but
> such verbose
> *) use oneline license comments in files and distribute a single LICENSE file in root

Ok, I will do this. How about MIT license?

> *) add manpage, and document the language there.

Good idea. I will have to learn some man syntax first though.

> most of those points are up to you.. I just like to have similar development rules in all
> the suckless projects :)

Nice to hear you consider nscript a suckless project now. :)

> So here'r more:
>
> *) add this script:
>
> $ cat nscc
> ...

I see you've made another thread about nscc, we will discuss there.

> For the code:
> *) i would do some optimizations in the stack implementation.
> - a fixed array for stack will be far more efficient and reserving a fixed amount of stack isn't
> that bad, you can add a config.def.h with STACKSIZE=4096 in it do define such size at compile time.

Hmm, this sounds like a nice idea if it leads to a good optimisation. It
also can make the code a little simpler. I think I could add this.

> *) do you think that running more than one 'nscript' vm in the same program takes sense?
> should it be good to have a NsVM *vm = ns_new(); ?
> this will make it fun to have multithreaded nscript apps, so you can import the stack
> state from another script for a while.
> I dont really know if all this stuff must go upstream.. it's just random buzzing :)
> - this change will make it slighly more complex..and i dont think in the benefits for it
> in short term, so will be better to think on it later.

I was thinking about it too - it would be a matter of moving most of the
currently global stuff into some 'nsvm' struct. It might become harder
to do later...

> *) "" must be for escapable strings and '' for unscaped ones. I think this will be saner, Other languages use @"" for
> literal strings, but ""/'' is simpler

This is already implemented - "" has C escapes, '' has only one escape -
double ' will escape the ' itself.

> *) about using 'def' instead of $ ..is probably more forthy, but reduces the performance of the VM.. having 'def' will enable
> to override 'def' definition..which is one of the most important features of lisp/fortran. the same applies to math
> operators like '+'.

This can also be done with '$'. I'm actually thinking of removing
'functrie' and putting everything into 'variabletrie' - even the
constants, operators. What do you think?

About 'def' - it could be easy to implement actually, after reading
Kris's latest email. We simply need to add a new 'symbol' type that
holds a string. Whenever the parser finds '$foo' it will push on a stack
a symbol with that name.

<obj> <symbol> def will make a new variable with the name being the
symbol and assign obj to it.

Then 'execute' will need one more addition - if it encounters a symbol
it looks for the variable of the same name and executes it.

I'm still thinking about what advantages this 'symbol' idea could
offer...

> *) We need a way to work with arrays and strings. those funcs would be good to have:
> - len/setch/getch/

Will be easy to implement, I will add them.

> *) Arrays would be interesting.. and same for data structures. clojure have a very nice syntax for structures in lisp syntax,
> this is very good if you want to do a program bigger than a hello world. Because you can solve any problem using lists
> or stacked.. which is imho not

Interesting. For arrays, shall we simply use a dynarray of ns_objs?
Structures could simply again themselves be tries of strings to ns_objs.

> *) You can have a look at java vm internals book, it's a stack based vm and you can get ideas by reading the list of opcodes.
> *) Real fortran compilers/emulators

I will check these out some time.

> *) What do you think about memory references as for '&' ?

You mean like pointers? This could be a good idea for allowing 'mutable
objects'.

Actually we have to think about memory management - right now there's a
lot of dynarray memory for example that's leaking. Should we add some
kin of reference counting mechanism for ns_objs?

> I think a good point for a language like nscript is that it must be consistent and simple. And this is something
> that many times collides with the ease of use or simplicity to do some stuff with it.

That was my main intent actually - to keep it as simple as possible. The
'stack' idea actually gives a very easy way of data passing. I think the
'executable' idea (blocks) and them being assigned to variables to
create functions makes things a little consistent too. The thing is,
there's no explicit argument passing - it's all on the stack - so every
'function' is inherently 'void func(void)' - you just need to execute
it, the data passing will handle itself.
Received on Thu Aug 26 2010 - 12:37:41 CEST