3 ms·

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,

by aatd86 4y ago

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.

Timon3 4y ago
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.
- aatd86 4y ago
  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.
  - Timon3 4y ago
    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.
    - aatd86 4y ago
      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 :/
      - 4y ago

by aatd86 4y ago

Timon3 4y ago

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.

aatd86 4y ago
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.
- Timon3 4y ago
  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.
  - aatd86 4y ago
    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 :/
    - 4y ago