Need guidance on what constructs to use when about ecmarkdown

[jmdyck]

For es-spec-emu, I assumed that the distinction between:

• "values" (*x* --> <emu-val>x</emu-val>) and
• "spec-level constants" (~x~ --> <emu-const>x</emu-const>)

was this: a "value" denotes a value in an 'ECMAScript language type', whereas a "spec-level constant" denotes a value in a 'specification type' (see http://www.ecma-international.org/ecma-262/6.0/#sec-ecmascript-data-types-and-values).

So:

   *undefined* *null* *true* *false* *NaN* *TypeError* etc
vs
   ~empty~ ~throw~ ~failure~ ~lexicalBinding~ etc

However, there's one exception, *this*, that doesn't really fit in either category, but is marked as if it's a "value".

[bterlson]

I like your distinction jmdyck. I'm going to codify that in the Emu readme.

[bterlson]

See here: http://bterlson.github.io/ecmarkup/#editorial-conventions. Thoughts?

[domenic]

Are we going to change strings from code to values?

An example for source code would be good. The spec uses it for talking about e.g. Function.prototype and so on.

"Structuring your Ecmarkup Document" should lowercase document

Maybe put the Ecmarkdown column before the Ecmarkup column and name the Ecmarkup column "Ecmarkup Output"

[bterlson]

I think strings and numbers should be treated identically. I think they are really values so I plan to use that convention going forward at least. Any concerns there?

Good call on the rest, will update it presently.

[domenic]

Not really, just will require some adjustment to existing specs and proposals. The line has always been fuzzy.

[bterlson]

Updated. I leave it up to you whether you want to duplicate the same sort of info in this repo or close this issue :)

[domenic]

Close for now, if people keep getting it wrong we can ask them directly and see if this might help...