It's not related to newLISP in any way, even core language is significantly different. dfsch has only lexical scoping (I'm not entirely convinced of which way to add dynamic scoping to scheme is best) while IIRC newLISP has only dynamic.
And as for documentation: writing documentation sucks :) Originally I thought that doc-strings and automatic generation will take care of most work, but it simply isn't so.
HTML generation (and XML parsing, I tried to use NetSurf's HTML5 parser too, but then gave up) is inspired by S-XML ( http://okmij.org/ftp/Scheme/SXML.html) but with the grammar of structure modified to reflect that dfsch has packages (node names are strings instead of symbols) and for convenience (node names can be keywords, attributes can be specified without '(@ ...)'). My long-term idea is to write set of DOM-like generic functions to manipulate this structure but I haven't yet got to do it.
> I'm not entirely convinced of which way to add dynamic scoping to scheme is best
I believe the way Kernel[1,2,3] handle this is really great. A `vau` expression is like a `lambda` expression (it's a lexically scoped fexpr actually) except that its operands (~ arguments) are passed in call-by-text and there is an extra argument which is the dynamic environment of the call site. This way you can `eval` the operands in the dynamic environment if you want to, but you can also `eval` quoted symbols or expressions in this same environment, thus achieving dynamic scoping.
This is very powerful, `vau` expressions can replace functions and macros altogether (and you have first class macros "for free" for instance). The counterpart is that I don't know if this kind of code can be compiled down to efficient code.
this is mostly orthogonal to issue I have. Syntax-wise I want either Common Lisp or IsLisp style special variables, with selection of syntax being predicated on other concerns like performance, interaction with multiple threads (dfsch was originally fully multithreaded, current implementation uses global interpreter lock only for few rare operations, which is faster than fine-grained locking) and isolation between multiple lexical environments (so dynamic variables have to be partially lexicaly scoped)
6 comments
[ 4.5 ms ] story [ 46.9 ms ] threadI like the html generation in Your "http-server-demo". That's looking pretty simple.
And as for documentation: writing documentation sucks :) Originally I thought that doc-strings and automatic generation will take care of most work, but it simply isn't so.
HTML generation (and XML parsing, I tried to use NetSurf's HTML5 parser too, but then gave up) is inspired by S-XML ( http://okmij.org/ftp/Scheme/SXML.html) but with the grammar of structure modified to reflect that dfsch has packages (node names are strings instead of symbols) and for convenience (node names can be keywords, attributes can be specified without '(@ ...)'). My long-term idea is to write set of DOM-like generic functions to manipulate this structure but I haven't yet got to do it.
I believe the way Kernel[1,2,3] handle this is really great. A `vau` expression is like a `lambda` expression (it's a lexically scoped fexpr actually) except that its operands (~ arguments) are passed in call-by-text and there is an extra argument which is the dynamic environment of the call site. This way you can `eval` the operands in the dynamic environment if you want to, but you can also `eval` quoted symbols or expressions in this same environment, thus achieving dynamic scoping.
This is very powerful, `vau` expressions can replace functions and macros altogether (and you have first class macros "for free" for instance). The counterpart is that I don't know if this kind of code can be compiled down to efficient code.
[1] http://web.cs.wpi.edu/~jshutt/kernel.html - John N. Shutt's Kernel page.
[2] http://klisp.org/ - An implementation of Kernel.
[3] http://axisofeval.blogspot.fr/ - a blog which talks a lot about Kernel.