Digest #128 2020-12-08
I think the text needs updating - it is not clear what happens when the value is zero, though the implementation example is.
I think this is particularly imporant as this differs from other implementations of THROW, for example in eForth where it is always triggered , i.e. there is no "?DUP IF"
It is probably less work and especially more compatible with usage outside the standard to remove or swap the reference to "first" and "second" in 3.1.4, and in every other place where it occurs (I don't remember any other).
[.compile] -- [.stack] colon-sys_1 -- colon-sys_2 Append the run-time semantics below to the current definition. Whether or not the current definition is rendered findable in the dictionary by the compilation of [.word]`DOES>` is implementation defined. Consume [.par]__colon-sys_1__ and produce [.par]__colon-sys_2__. Append the initiation semantics given below to the current definition. --
The resulting DocBook is the following:
<para role="compile"> <simpara role="stack">colon-sys_1 — colon-sys_2</simpara> \<simpara\>Append the run-time semantics below to the current definition. Whether or not the current definition is rendered findable in the dictionary by the compilation of <literal role="word">DOES></literal> is implementation defined. Consume \<emphasis\><phrase role="par">colon-sys_1</phrase></emphasis> and produce \<emphasis\><phrase role="par">colon-sys_2</phrase></emphasis>. Append the initiation semantics given below to the current definition.</simpara> </para>
Marcos, thank you for your example.
I can guess, in a case of several space separated lexemes like ( c-addr<sup>1 u<sup>1) they are written as
[.par]__c-addr_1 u_1__, that in XML can be written as
One problem is how to render
colon-sys_1 (or better
colon-sys\<sup\>1</sup> (that is shown as colon-sys<sup>1). In the case of XML it is easily solved in the XSLT step that transforms the sources. In the case of AsciiDoc I can guess a post-processing XSLT step on the generated DocBook can be used.
Other questions are: nesting of different blocks, using indentation in the sources, support of folding in text editors. It seems, some of these features are supported with AsciiDoc, but with XML they seem to be supported better.
To me, XML for this purpose looks better than AsciiDoc. But my view perhaps is biased, since I use XML a lot, and never AsciiDoc (except sometimes Markdown that is similar to AsciiDoc).
Perhaps you are right. But numbering of stack items in such words like
CS-ROLL is also from top to bottom (and the corresponding indexing is used in the stack notations).
So, I still think that numbering items in a cell pair (and in a tuple in the general case) from the top to the bottom would be more consistent.
Usage outside the standard (and also in the standard), when indexes are going from bottom to top, is just a result of practices from other languages, and common left-to-right writing, I think. Actually, it does matter only when the items are referred by their indexes (i.e., in the case of tuples). In such cases as the
SEARCH word, it doesn't matter.