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

I've implemented a new feature 'namespaces'. The changes are on the 'namespace' branch on github. Now the old separation between 'functrie', 'operatortrie', 'variabletrie' has disappeared. All the builtin functions such as 'print', 'add' etc. have now gone into a 'builtins' namespace. A namespac

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

2010/8/26 Kris Maglione : >> Please, don't tell is the forth way when it is not. In forth, IF only >> takes one argument and is compiled to a conditional jump to THEN (or >> ELSE). > > How is that not a branch? Sorry, of course it is a branch. Yes, Forth has branches. I was thinking about quotatio

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

On Thu, Aug 26, 2010 at 09:51:10AM +0200, yy wrote: 2010/8/26 Kris Maglione : It does not work that way in postscript and, as I already said in another message, it does not work that way in forth, neither in toka or raven. Would you mind explainning why your way is more logical? I think it could

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

Floating point support has been added!

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

On Thu, Aug 26, 2010 at 01:11:00AM +0200, pancake wrote: > *) 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 app

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, descri

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

2010/8/26 Kris Maglione : > On Thu, Aug 26, 2010 at 12:19:33AM +0200, yy wrote: >> >> 2010/8/25 pancake : > > * I will probably swap the order of the conditional clauses: (what do > you > think about it) >   3 3 == { 'Is equal duppy\n' print } if >  --> >  { 'Is equal du

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

On Thu, Aug 26, 2010 at 12:19:33AM +0200, yy wrote: 2010/8/25 pancake : * I will probably swap the order of the conditional clauses: (what do you think about it)   3 3 == { 'Is equal duppy\n' print } if  -->  { 'Is equal duppy\n' print } 3 3 == if Hmm, personally I prefer the 'condition first'

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

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

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

On Thu, 26 Aug 2010, pancake wrote: with def you will be able to override any operator or function. nevertheless you can also doit with '$' and the parsing will go faster A quick way to allow that with '$' is move the 'findVariable' part before the 'findFunc' part in MD_READNAME in ns_interpre

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

On Thu, 26 Aug 2010 03:02:08 +0300 (AST) Nikhilesh S wrote: > The current way of doing it makes the implementation very simple - if it that's the point, but it makes no possible to override native functions. > encounters a '$' it just reads the variable name and makes a new one. If > it encoun

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 h

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

On Wed, 25 Aug 2010, anonymous wrote: You include files include include files. IMO one external include file (that is placed into /usr/include) should be enough. And internal include files can be placed into src/, one .h file for each c file. Then you can remove #ifdef guards. Read "Notes on

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

On Wed, 25 Aug 2010, Kris Maglione wrote: My personal preference is for single-quoted strings to ignore escape sequences, and to escape single quotes by doubling them, and for double-quoted strings to process escapes and possibly do simple interpolation. I think this is a good idea - I've impl

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

On Wed, 25 Aug 2010, Kris Maglione wrote: Personally, I don't think that a special syntax for variable definition fits well in a stack-based language. I prefer the PostScript syntax of quoting the word and using the def keyword, so: 2 $var def or { 'hi' print } $foo def or the revers

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

On Wed, 25 Aug 2010, pancake wrote: I vote for 1char string, no new type. And u can reuse the rest of operators Why not return an int with the enum value? Ok, I've added 'getline', 'getchar', 'type'. Also, ns now accepts more options to execute code from standard input, file or from a string

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

2010/8/25 pancake : >>> * I will probably swap the order of the conditional clauses: (what do you >>> think about it) >>>   3 3 == { 'Is equal duppy\n' print } if >>>  --> >>>  { 'Is equal duppy\n' print } 3 3 == if >> >> Hmm, personally I prefer the 'condition first' order... Why do you like >> th

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

Yo On Aug 26, 2010, at 12:08 AM, Nikhilesh S wrote: On Wed, 25 Aug 2010, pancake wrote: * Remove 'code' in nstest.c and put it as a testcase t/test nstest.c is gone, there's now ns.c, a standard-input-interpreter. The tests are now in the directory test/. You can now just run './ns < test/

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

On Wed, 25 Aug 2010, Moritz Wilhelmy wrote: Anyway, this is completely unrelated, I just wanted to suggest you to take a look at postscript. It is also well-documented, see [1], [2]. Yup, I've seen postscript before. I will go check it out again, maybe it has some good ideas. C bindings woul

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

On Wed, 25 Aug 2010, pancake wrote: * Remove 'code' in nstest.c and put it as a testcase t/test nstest.c is gone, there's now ns.c, a standard-input-interpreter. The tests are now in the directory test/. You can now just run './ns < test/fact.ns' for example. * floating point support (append

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

On Wed, Aug 25, 2010 at 10:02:56PM +0200, Moritz Wilhelmy wrote: The whole thing actually reminds me of postscript, which I consider a language with a nice syntax. The only thing that sucks about it, is that adobe buried it in favour of this PDF crap, which is really sad. PDF is, for all inte

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

Hi, The whole thing actually reminds me of postscript, which I consider a language with a nice syntax. The only thing that sucks about it, is that adobe buried it in favour of this PDF crap, which is really sad. I thought about implementing an alternative windowing system (possibly replacing X11)

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

2010/8/25 Kris Maglione : > On Wed, Aug 25, 2010 at 01:54:37PM +0200, pancake wrote: >> * I would probably prefer '"' quote char for strings. > > I think this is irrelevant. It's down to the preference of the language > designer. Most scripting languages support single quoted strings, some > (pytho

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

On Wed, Aug 25, 2010 at 03:24:03AM +0300, Nikhilesh S wrote: Preceding a name with '$' will create a variable with that name and pop and assign the last thing on the stack to it. Simply a name will push the value of the variable with that name onto the stack (if it's not executable, we're getting

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

On Wed, Aug 25, 2010 at 01:54:37PM +0200, pancake wrote: I encourage you to make the nstest program smarter by removing help messages, prompts and others and just keep the read-eval-print loop. I'd rather the script go in nstest.ns and either be sourced at runtime or processed by the makefile

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

On Wed, Aug 25, 2010 at 1:23 PM, Robert Ransom wrote: > On Wed, 25 Aug 2010 16:35:12 +0200 > pancake wrote: > >> why not 'ns'? is there any other program with this name? > > The Network Simulator also goes by 'ns' though I don't think it has an executable named

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

On Wed, 25 Aug 2010 16:35:12 +0200 pancake wrote: > why not 'ns'? is there any other program with this name? Robert Ransom signature.asc Description: PGP signature

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

On 08/25/10 17:29, Nikhilesh S wrote: On Wed, 25 Aug 2010, pancake wrote: Wow! pretty fun :) I encourage you to make the nstest program smarter by removing help messages, prompts and others and just keep the read-eval-print loop. I think I will make it build two programs - nsrepl and nstes

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

On Wed, 25 Aug 2010, pancake wrote: Wow! pretty fun :) I encourage you to make the nstest program smarter by removing help messages, prompts and others and just keep the read-eval-print loop. I think I will make it build two programs - nsrepl and nstest separately. About the language I find

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

Wow! pretty fun :) I encourage you to make the nstest program smarter by removing help messages, prompts and others and just keep the read-eval-print loop. About the language I find it quite nice as in syntax. I wrote a similar virtual machine in 'sal' but it end up being a little messy and

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

On Wed, 25 Aug 2010 03:20:55 +0400 anonymous wrote: > In C variables can only be created in the start of block ({} > brackets). You sometimes declare new variables anywhere like in C++. C99 allows this. Robert Ransom signature.asc Description: PGP signature

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

On Wed, 25 Aug 2010, yy wrote: It is difficult to form an opinion about a language if there is no documentation or any examples, and it is difficult to form an opinion about the implementation without understanding the language. What features does it have? How does it look like? How does it com

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

In C variables can only be created in the start of block ({} brackets). You sometimes declare new variables anywhere like in C++. You include files include include files. IMO one external include file (that is placed into /usr/include) should be enough. And internal include files can be placed

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

Looks like Forth.

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

It is difficult to form an opinion about a language if there is no documentation or any examples, and it is difficult to form an opinion about the implementation without understanding the language. What features does it have? How does it look like? How does it compare to other stack-based language

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

I wrote a small interpretter for a stack-based scripting language I called 'nscript' a while back. I wasn't very well-versed at C (more of a C++ guy) so the code might suck a bit. You can find it here: http://github.com/nikki93/nscript It was born out of the one-file version here: http://codepad