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

More on nscript..

*) 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
*) 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
*) follow dwm syntax (to keep same syntax in all projects)
*) use tabs :)
*) fix help message of ns to be in one line, description of what the program does must be in the manpage.
*) add manpage, and document the language there.

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

So here'r more:

*) '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
*) add this script:

$ cat nscc
#!/bin/sh
# compile nscript files with a C compiler
# --pancake

if [ -z "$1" ]; then
        echo "Usage: nscc [-o a.out] [file.ns] [...]"
        exit 1
fi
[ -z "${CC}" ] && CC=gcc

OUT=a.out
if [ "$1" = "-o" ]; then
        shift
        OUT=$1
        shift
fi

cat >.tmp.c <<EOF
#include <nscript.h>
static const char *code = \\
EOF
cat $@ | sed -e 's,",\",g' -e 's,^,",' -e 's,$,\\n",' >> .tmp.c
cat >>.tmp.c <<EOF
;
int main() {
        ns_init();
        ns_interpret(code);
        return 0;
}
EOF
${CC} ${CFLAGS} ${LDFLAGS} -Iinclude -o ${OUT} .tmp.c libnscript.a
rm -f .tmp.c

With it you can compile nscript binaries with a C compiler

  $ ./nscc hello.ns
  $ ./a.out
  Hello World!

  The next cool thing would be to be able to call C functions from nscript, so nscc would
  generate the trampoline automatically. This way you will be able to use the full libc,
  X11, swk and others without having to write bindings in C, because they will be definible
  in nscript. Just defining a signature of the function in string format, nscc can parse it
  and generate the stub to add this 'instruction' into the vm.

  Im thinking in something like this:

   *) We need a syntax to describe function signatures
      - parsed by nscc
      - generate C stub to add functions to the compiled binary
      - function signatures must should have a name:

file can look like this:
# format is:
# [ret values] [arg values] [C function name] [optional nscript func name]
i s strlen len
i ss strcmp cmp
i ssi setenv
...

I dont know if it will be simpler to describe this in C, and rewrite nscc in C, so you can
describe those signatures in a .h file and include it with 'nscc -i libc.h'.

The problem here is that we should add a step in the compilation to not load functions
not used in the source file. this would require a bit of parsing, so maybe is task for
libnscript.

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.
*) 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.

And for the language:

*) "" must be for escapable strings and '' for unscaped ones. I think this will be saner, Other languages use @"" for
   literal strings, but ""/'' is simpler
*) 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 '+'.
*) We need a way to work with arrays and strings. those funcs would be good to have:
   - len/setch/getch/
*) 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
*) Having few basic
*) 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.
*) What do you think about memory references as for '&' ?
*) Real fortran compilers/emulators

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.

One of the reasons why fortran failed is because many people extend it without control, adding incompatible extensions,
which resulted in many interpreters with different syntax and features. This is no good if you want to keep using
your software more than 5 years. Real CPUs does not change ABI that much, so they keep more backwards compatiblity than
software... same comparision can be done with network standards (tcp,vlan,eth,...) and data formats.. replacing
hardware is not critical and it's easy to change, but software is essentially evolving much faster and making
compatibility of file formats or databases get deprecated or incompatible in about months.

Sorry for this uberlong mail :)

--pancake
Received on Thu Aug 26 2010 - 01:11:00 CEST