I think you're mixing up the data with the statements. Yes, nodes in a subtree are ordered, but that doesn't mean you can't re-order the statements creating those nodes. For example you could insert the nodes in reverse order at the correct position. It wouldn't make any difference to the tree itself.

I must be a bit dense this morning :). I'm still not sure I understand.

Defining insertion would be in the imperative portion of the code right?

Since there, source order matters, you would have to change the subroutine that triggers insertion by changing the direction?

When describing the tree structure however, listing the nodes (html nodes for instance) has to be in order, no?

Creating those nodes can indeed be reordered provided there is no interdependence.

the same way

var a, b; c =a + b;

can be rewritten:

var b, a; c =a + b;

Asking because it seems to me that commutativity is a hard sell here. Might be mistaken about what you mean.

I think there might be a difference in what we see what the HTML tree exactly is in this example. For me, the HTML is a declaration of structure. This can be passed to imperative code to build the DOM, but the tree itself (the HTML code, if you will) is a declarative representation of what I want to have in the end.

It doesn't matter to me how this HTML is turned into a DOM. You could go through the HTML line by line and create the nodes. Or, if you'd think it could be faster, you might insert the children in reverse order at the correct position (e.g. start inserting the last element, then before that insert the second-to-last, and so on). All that matters is that the DOM in end behaves exactly like the one I specified.

In the end, it's the same as with SQL. It doesn't matter what exact approach you take to get me what I want, as long as the end result is what I specified.

Yes, it's an abstraction over the implementation details.

For html, the renderer still depends on the structure of the tree.

Whether it starts from the bottom of the top doesn't matter. Because the renderer is an imperative function.

But the declarative part is the tree itself and these declarative statements are not commutative is what I mean.

You cannot insert to a node that doesn't exist.

I don't think what you write actually touches what I wrote.

> For html, the renderer still depends on the structure of the tree.

Of course! But it's not important whether you first insert node A at place X and node B at place Y, or the other way around.

> Whether it starts from the bottom of the top doesn't matter. Because the renderer is an imperative function.

See, that's the thing. What renderer are you talking about? I'm talking about the process of turning the declarative HTML tree into a DOM tree.

> But the declarative part is the tree itself and these declarative statements are not commutative is what I mean.

Well, no. You can't change a declarative structure and expect it to be the same. But why does that have any bearing on whether HTML trees are declarative? The tree is a declaration, and it doesn't matter how you turn this declaration into a DOM tree.

It seems like you're expecting to be able to re-order the child nodes. That is not what declarativity is about. It means that it doesn't matter in which order you do the operations. The operation itself is defined by the node placed into the tree AND the resulting position of the node. You are right that you can't re-order the node declarations, but you can execute them in whatever order you want.

Just to be sure, what do you mean by executing node declarations?

Seems then to me that it is exactly the example of declaring variables. The order doesn't matter indeed.

But for operations on these variables, i.e. function calls, there needs to be an ordering between variable declarations and functions calls (source order) except in a few cases maybe where a language uses hoisting.

That's in the simple case where there are no side effects (but the parent comment takes this into account already).

Of course, when someone transforms an html element into its corresponding DOM node, because this does not depend on shared state, these operations can be commuted but that's not what declarativity is about.

Declarative is: cook me a chicken.

As opposed to imperative i.e.: turn the oven on, wash and season the chicken, put it on the oven, wait 1hour, get if off the oven and serve it.

You can buy the chicken or the oven whichever first. Still need to follow the steps in order.

I'm still not quite sure I understand what you meant exactly :/

I'm still a bit confused about the distinction. A HTML-page would be a declarative definition of a DOM-structure, right? It just declares what I want to see in the browser, it does not describe how the browser-engine shall render the HTML given to show it to my readers. Good so far, declarative.

But what if the web-page shows a cookbook recipe whose steps are elements in the DOM-structure of the page? Such a page then procedurally describes how to cook a cake, right? Is that recipe then declarative or procedural?

The html code is a declarative definition of a webpage. The internal representation as a DOM tree is just the imperative implementation on the backend.

A recipe is a description of the steps to the end result. So it's imperative.

Here instead of DOM nodes, you probably have utensils and ingredients on which you apply operations (grab, heat, pour oil etc...)

The end goal is not the description of the recipe itself. It's the meal that you get once you have followed the steps to completion.

But my end-goal could be finding the recipe, maybe I am a recipe collector.

> Alledgedly a HTML tree is declarative but sibling elemznts are ordered.

Yeah, so it does not matter in which order you render them, as long as they are inserted/shown in the right order in the end.

That works for a single function call.

You wouldn't be able to modify something that has not be rendered yet for instance.

Render itself is declarative perhaps, but that's the meta level.

Render is imperative in terms of rendering a declarative tree.

> You wouldn't be able to modify something that has not be rendered yet for instance.

What does rendered mean? In the browser window? Why not, you can certainly modify that. If you mean not rendered in the HTML then we are now talking about two different things, because my answer was meant for when there is an existing HTMl tree already.

Rendering meaning turning the html elements into dom nodes first before painting.

But that's a red herring.

The point in that the sequence, render-modify cannot be turned into modify-render. This is not commutative.

Now, render(a, b, c) where a, b, c are html nodes is a slightly different story because we consider only one function.

Here, your claim is that since it is basically equivalent to render(a) + render(b) + render(c) then it's commutable.

Well, it depends at which granularity one looks at it (subtrees...). And as the original comment mentions, in the general case, it's only true if there is no side-effects.

Well, now we are really down to semantics. I don't think there is any guarantees about rendering whatsoever, are there?

In other words, if you, currently, put some html elements (whatever that means, maybe using innerHTML or so) is there any guarantee how exactly they are rendered, meaning, how they are turned into dom nodes?

Because of not, then render(a, b, c) is in fact equivalent to render(a) + render(b) + render(c).

If this process can be controlled, then obviously "inserting" an html element (structure) must be able to describe that process to make it declarative.

The thing is, this is simplistic example. It's not just about pure semantics nitpicking.

That render decomposition works for sibling elements.

However, when there is a parent child relationship between html elements, the child can only be inserted on an existing parent.

Basically, render(a(b)) is not render(ab) where a(b) denotes that the html element a depends on the html element b for its definition.

> Basically, render(a(b)) is not render(ab) where a(b) denotes that the html element a depends on the html element b for its definition.

This is a new example. How does that contradict any of the previous points that I (and the OP) made? I fail to see that, can you explain?