Digest #128 2020-12-08
Contributions
comment - THROW: text doesn't match implementation example
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"
Replies
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).
proposal - XML Forth Standard - migration from LaTeX to DocBook
I think the code below would be an equivalent. The blocks, the paragraphs and the inline markup are marked with roles. The --
markup delimits a generic "open" block, but other specific blocks exist.
[.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>
proposal - XML Forth Standard - migration from LaTeX to DocBook
Marcos, thank you for your example.
[.par]__colon-sys_1__
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 \<d\>c-addr_1 u_1</d>
.
One problem is how to render colon-sys_1
(or better colon-sys.1
) as 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 PICK
, ROLL
, CS-PICK
, 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.