I've been following Rebol since 1993-94, over 20 years, as dRebol,Inetw3, and I am still amazed. I may not be a good programmer but I do dream in Rebol.
I posted the %Rebol-dom.r script to rebol-org and it has some vague similarities to your TLS EMIT dialect. Especially the VAR LET variables that bind to functions. I've saw discussions on SO about it. I check it 2-3 times every day.
I thought I was crazy using a var function to turn set-word!s into a named variable functions bound to data. I don't know how to optimize the code but it must look like, say, javascript or lua as much as possible for my next two DSL's.
I think you given me hope to keep trying. Every new chosen path starts with a Pandora's Box.
(pardon my changes to your post; I moved it to "introductions" and did a little bit of formatting...if you want to know how to do things like bold and italics, or put links in posts...see the Markdown Documention)
Bendability is the name of the game in Ren-C. Have you seen SET-WORD!s on the left hand side?
default: enfixed func [ ; enfixed means "get first argument from left"
'left [set-word!]
right [block!]
][
either undefined? left [set left do right] [get left]
]
>> abcd: default [print "running", <first>]
running
== <first>
>> abcd
<first>
>> abcd: default [print "won't run", <second>]
== <first>
Crazy?
I think you given me hope to keep trying. Every new chosen path starts with a Pandora's Box.
Right now our primary target is the web. A DOM-based dialect that could run in the browser could be a good test...even if it wasn't necessarily "useful". (I don't know if your dialect is useful or not, I'm just saying it doesn't even really matter as long as it stretches and tests features...so there's no reason to worry either way.)
We might be able to get your DOM dialect running in "REDBOL" emulation on the web (Rebol2/Redlike), and then perhaps convert it to Ren-C. Do you have tests for it?
It seems like you have your example usages as part of that script. I think the good next step is to break those out into their own files, so that they can be run as tests.
So that would mean making a top-level "tests" directory, and then extracting each individual bit that represents a usage of rebol-dom into a file that includes the library (via do %../librarian/support/Rebol-Dom.r).
Then, make it so that running your tests will give you a "passing" or "failing" answer that you can detect from the command line. The exit status is one way to do that. You can return it explicitly with quit/return 0 if your test succeeds, and quit/return 1 if it fails...although I think if you just fail on an error you'll get 1.
Each feature in your project should ideally have a test file that focuses on it. And then you can make some %tests/examples/ files that are bigger and test many features.
Basically take all the testing out of Rebol-Dom.r and put them into individual files. Once you have that and then some answer to match the test to, you can tell if it's working or not. And if you can run it from the command-line, you can have GitHub run the tests for you on every commit you make to ensure it's all working.