,---------------.
| Contributions |
`---------------´
,------------------------------------------
| 2020-12-06 08:05:30 MitraArdron wrote:
| comment - THROW: text doesn't match implementation example
| see: https://forth-standard.org/standard/exception/THROW#contribution-170
`------------------------------------------
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 |
`---------´
,------------------------------------------
| 2020-12-02 11:42:20 AntonErtl replies:
| comment - Cells numeration in a cell-pair
| see: https://forth-standard.org/standard/core/TwoStore#reply-580
`------------------------------------------
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).
,------------------------------------------
| 2020-12-02 15:05:55 MarcosCruz replies:
| proposal - XML Forth Standard - migration from LaTeX to DocBook
| see: https://forth-standard.org/proposals/xml-forth-standard-migration-from-latex-to-docbook#reply-581
`------------------------------------------
I think the code below would be an equivalent. The blocks, the paragraphs and the inline markup are marked with [roles](https://asciidoctor.org/docs/user-manual/#role). The `--` markup delimits a generic "open" block, but other specific [blocks](https://asciidoctor.org/docs/user-manual/#blocks) exist.
```Asciidoctor
[.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:
```DocBook
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 DOES> is implementation defined. Consume
colon-sys_1 and produce colon-sys_2. Append the initiation
semantics given below to the current definition.
```
,------------------------------------------
| 2020-12-05 09:31:00 ruv replies:
| proposal - XML Forth Standard - migration from LaTeX to DocBook
| see: https://forth-standard.org/proposals/xml-forth-standard-migration-from-latex-to-docbook#reply-582
`------------------------------------------
Marcos, thank you for your example.
> `[.par]__colon-sys_1__`
I can guess, in a case of several space separated lexemes like _( c-addr1 u1)_ they are written as `[.par]__c-addr_1 u_1__`, that in XML can be written as `c-addr_1 u_1`.
One problem is how to render `colon-sys_1` (or better `colon-sys.1`) as `colon-sys1` (that is shown as _colon-sys1_). 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).
,------------------------------------------
| 2020-12-05 10:01:24 ruv replies:
| comment - Cells numeration in a cell-pair
| see: https://forth-standard.org/standard/core/TwoStore#reply-583
`------------------------------------------
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`](/standard/string/SEARCH) word, it doesn't matter.