%rebol-dom.r

Domains Dialects/DSLs
1

I been giving more thought to the DOM format in Rebol and I think it needs to present a clear, concise demonstration of how it would be used as an object model for DSL's.

While improving on or extending choices of formatting DSL data can be easy, feeding it a subset of a complete DSL may not. It takes a lot of thought in creating the DSL's and a subset of say HTML some would rightfully say isn't Good enough.

The html standard is huge. Even so i believe it really can be done all in Rebol. instead of html only you would have a dsl choice, say make doc, markdown, or defualt DOM code. So Rebol-DOM.r is very simple.

http://www.rebol.org/view-script.r?script=rebol-dom.r

But to make it better i would need others coding experience. You mentioned tests. Wich types of testing would be best for now.

2

Old post, but new-old thoughts.

For a name other than "Scrunch" I've decided in relationship to a Dialect Object Model it should simply be an element-node of type Sequence.

Used as a variable set-word, the array-obj!() uses the sequence as a set-builder notation.

Its base form is serialized data thats represented in Rebol as molded data.

Its grouping order is {[()]}, but not necessarily followed in dialects. And in Rebol there is no difference in using "{}" or "[]", unless your sending, receiving, or loading data. It must be serialized.

I chose the "{}" because it allows you to manipulate dialect data in block form while not allowed to be of type! block.

This i believe is some of the differences between a Rebol Series and a Sequence.

Rebol sequence type is its molded data form. But it should have been a native type from the beginning.

The %Rebol-Dom.r set-builder notation, the Var., like Uparse allows me to set, search, parse, save, serialize, and share data maybe slower than BLOCKS, but as it was intended to be used. Any way i like. I wish i had your know how Hostilefork to do this right but i just don't have the time. Oh well, Rebol-Dom. Sorry, bout that, i meant Rebol On.

3

I would like to start coding the Rebol-Dom.r script in Ren-C, but im not sure if it needs to be written as Rebdol compatible or R3 syntax. Any heads up would be nice.

I also would like to see its node sequence type coded as Red/sys or Ren-C if its possible.

I really like Uparse, but for me to focus on its intricacies would take up more free time that i really don't have right now.

Although i like Rebol, my coding style may not do it much justice, but that's ok. Rebol is still somewhat an unknown. So if anyone have any criticism, good or bad, i welcome it.

2 Likes
4

Hi Danny,

Last year, Ren-C underwent some necessary but painful transitions... as I try to reason about a working module system, and what the future of binding might look like. It means the already-not-well-documented variations from historical Rebol are even more of a minefield--I'll do what I can to improve it, but it will be slow.

But likely relevant to what you want is that I think it's going to be crucial that binding be able to let you access "binding environments" for strings. If you haven't got a chance to read this, I talk some about that:

Rebol and Scopes: Well, why Not?

So that's one heads-up I'd give you: that the best way to embed "JavaScript-like intents" inside of Ren-C may be something that is done with strings, vs. the kinds of syntax tricks you were trying.

This isn't to say that we couldn't use some experimentation in the area of Ren-C/web interoperability. @rgchris made "StyleTalk" which he explains in a video. I'd like to see us to see where things can go with that kind of thinking before bending ourselves too far into pretzels and asking if a[b]c should be its own lexical type.

Another heads up I'll give is that I've been traveling since December, and not programming much at all. Hence I'm a bit behind on the mountain of design (as well as my own pet projects...) I likely won't have the bandwidth to support anyone's new experiments that I'm not already supporting.

Though much of the current efforts are on things in the browser. If you are interested in HTML interoperability then I'd definitely encourage you to look at the ReplPad and where that is going. I'm effectively "doubling-down" on the approach of using the browser for GUI (vs. Red's strategy of writing their own code)

So if you want to be experimental in Ren-C land, the place where you'll be more likely to find support (though not promising...) is if you're trying things in the web build. It may lead you to different ideas about how to attack your problems, specifically as a mixture of JavaScript strings with Ren-C.

I'd suggest looking at JS-EVAL and JS-DO for instance, things like what @gchiu wrote just the other day:

add-content: func [
    txt [text!]
][
    txt: append copy txt newline
    js-do ["document.getElementById('script').innerHTML +=" spell @txt]
]

That's pretty smooth language interoperability... and I'm sure it can be better! (If you read the JS-EVAL post I explain why this winds up being smarter than gluing strings together, and avoids various escaping problems.)

1 Like
5

I notice you've been logging in regularly. Hopefully it's interesting reading. :slight_smile: Since you are paying attention, I'll follow up here...

I'm interested in making sure Ren-C can accomplish more than Rebol2 or Red could, so even if your example is a bit strange... if it can be shown as running in Rebol2 and doing something reproducible... it could be useful for the questions it brings up.

The ideal tests would be things that demonstrate whatever parts of the idea is most interesting to you. What makes you like it.

If something is worth doing it's worth doing right... so getting set up on GitHub with version control and having it test your code after every change you make is the way to go. For source control, I still suggest:

SmartGit – Git Client for Windows, macOS, Linux

I can help you with setting up a GitHub Actions script that runs the Rebol2 interpreter over your DOM and test, and reports success or error on changes.

We could then look at what sort of unique questions porting it to Ren-C might bring up, and if there's anything specific about it that a person should or shouldn't be doing with the tool.