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.
