Minor wording change in assert() definition

[jimmonte]

What is the issue with the Console Standard?

In item 3 of the definition of assert() at https://console.spec.whatwg.org/,

If data is empty, append message to data.

would be more clearly expressed as

If data is empty, let data be message.

since it eliminates the dependency on an understanding of the definition of append and is a clearer and more direct action. (It would be possible to prepend with the same affect as append when the object being augmented is empty.) Also, the "let x be y" syntax is widely used in this definition and is slightly more concise.

[jimmonte]

Also,

Otherwise:

Let concat be the concatenation of message, U+003A (:), U+0020 SPACE, and first.

Set data[0] to concat.

could be streamlined to

Otherwise, let data[0] be the concatenation of message, U+003A (:), U+0020 SPACE, and first.

That change would eliminate a sublist.

[domfarolino]

If data is empty, append message to data.

would be more clearly expressed as

If data is empty, let data be message.

The variable data cannot be re-declared here via "let", since it already exists.

---

The second comment you make seems fine, though I'm not sure it is worth the change. If you want to upload a PR for it, feel free. But I don't think we need an issue to track this.

[jimmonte]

The variable data cannot be re-declared here via "let", since it already exists.

Ah, so that is the difference between Let... be... and Set... to...

If data is empty, set data to message.

It is still simpler than appending.

[domfarolino]

Eh, I don't think you can really set it to something else, if it is passed in. But you can mutate it like you would a JS value. Think of it as JS:

function LoggerPush(data) {
  data.push(10);
}

function LoggerAssign(data) {
  data = 10;
}

const data = [];
LoggerPush(data); // data is now `[10]`
LoggerAssign(data); // data is still `[10]`

[jimmonte]

@domfarolino

Eh, I don't think you can really set it to something else, if it is passed in.

In the definition of assert at https://console.spec.whatwg.org/#assert in step 2 (Set data[0] to concat.) of step 3 of step 4 (both Otherwise:) that is exactly what is currently being done. There data[0] is not the first element of an array named data, but the first argument in a list of arguments named data, as explained in the definition of lists at https://infra.spec.whatwg.org/#lists

const data = []; LoggerPush(data); // data is now [10] LoggerAssign(data); // data is still [10]

I think you meant "data is still []" in the second comment, and while that is true, it is because JS passes objects to functions by reference, allowing them to change the contents of the objects. Function LoggerAssign() changes what parameter data references during the life of the function when the primitive 10 is assigned to data. In assert() that is the desired behavior since the ultimate action if the condition being asserted is false is to call Logger() with data.

Having written all of that, in the definition of assert() the variable argument list of assert() is considered to be a list named data, and in the definition of "list" given earlier, there are only operations append, extend, prepend, and replace. There is no definition of let/be or set/to, and of the defined operations, only append and prepend are appropriate for the action of assert() in step 3, and of those two, append seems more natural. I had not seen the definition of list previously. So I agree that step 3 should stay as is. Different reasoning, but I guess all roads lead to Rome.

Consolidating the concatenation steps 4.3.1 and 4.3.2 still seems desirable since it reduces the size of the definition. eliminating an entire sublist, and all else being equal shorter is better for definitions.

[domfarolino]

I think you meant "data is still []" in the second comment, and while that is true

This is not what I meant, and that is false. I meant data is still [10], because that's what happens when you run the code I provided.

---

There data[0] is not the first element of an array named data, but the first argument in a list of arguments named data

I believe these are the same thing. See below.

Eh, I don't think you can really set it to something else, if it is passed in.

In the definition of assert at https://console.spec.whatwg.org/#assert in step 2 (Set data[0] to concat.) of step 3 of step 4 (both Otherwise:) that is exactly what is currently being done.

The list of variadic arguments gets converted to a list / array that the function has access to. You can assign/set anything to members of that list, just like you can assign/set anything to members of an array or object. But I see your point, yeah you could assign something to the whole variadic list of arguments called data. It won't mutate anything outside of the assert() call of course, but from an editorial view I think it is fine.

Like I've said, if you want to submit a PR, we can consider it.

[jimmonte]

Of course you are right regarding the code output. I was looking at executing the individual functions separately with an argument of the initial value of data ([]) rather than running the entire snippet of code.

The standard attempts to clearly define supported data structures and operations permitted on them, so a list and an array are not the same. In fact, arrays do not exist. Nor does an object exist, although there is a struct. See https://infra.spec.whatwg.org/#data-structures

There are definitions for the actions of let and set on variables, but not assign. See https://infra.spec.whatwg.org/#variables (as I read more). While you could set data to anything within assert(), data must be a list when step 6 is reached because the second argument to Logger() is specified to be a list.