,---------------. | Contributions | `---------------´ ,------------------------------------------ | 2024-06-28 23:47:44 ruv wrote: | requestClarification - Behavior of `represent` when buffer length is zero | see: https://forth-standard.org/standard/float/REPRESENT#contribution-347 `------------------------------------------ There was a recent discussion in comp.lang.forth about the behavior of `represent ( c-addr u -- n flag1 flag2 ) ( F: r -- )` when the parameter at position _u_ is zero (links: [1](https://www.novabbs.com/devel/article-flat.php?id=27288&group=comp.lang.forth#27285) , [2](https://www.novabbs.com/devel/article-flat.php?id=27288&group=comp.lang.forth#27288) ). There are two positions regarding this case (u=0): 1. the behavior is specified: - nothing is written into the buffer, - the significand (in the specified representation) is rounded to 0 digits after the decimal point — to an integer digit; _n_ is adjusted correspondingly. 2. the behavior is unclear/unspecified. Some systems writes to the buffer (despite _u_ is zero). Some throw an exception. Some behave according to (1). Should we clarify the text description, or specify some other particular behavior (e.g., throw a specific exception), or declare an ambiguous condition? If `represent` does not throw an exception, I would expect behavior as follows: ``` t{ 0.1e pad 1 represent -> 0 0 -1 }t t{ 0.1e pad 0 represent -> 1 0 -1 }t t{ 0.1e 0 0 represent -> 1 0 -1 }t \ to ensure that nothing is written ``` It can be useful if the field width for a significand is calculated and can be zero in a program, and then only the order of magnitude for the number is shown by the program. ,---------. | Replies | `---------´ ,------------------------------------------ | 2024-06-21 08:10:32 ruv replies: | requestClarification - shadowed names | see: https://forth-standard.org/standard/tools/TRAVERSE-WORDLIST#reply-1252 `------------------------------------------ > So the intention was to give no guarantees about that. Yes, but this intention (concerning "duplicated nodes") **is not reflected** in the normative parts. > Maybe we should put that intention explicitly in the standard text. I prefer to have access to shadowed definitions. And for introspection purposes, it's better if a Forth system does not skip shadowed words in `traverse-wordlist`. (From time to time people even ask how to access a shadowed word in Forth, see an [example](https://stackoverflow.com/questions/69312047/how-can-i-access-a-shadowed-definition-in-forth) on StackOverflow). > Alternatively, if you want a guarantee, investigate existing practice, and, if it agrees with your preference, make a proposal for standardizing that. From the formal point of view, we already have this guarantee: the text description says that _xt_ is executed once for **every word** in the word list. And nothing in the normative text says that `traverse-wordlist` can skip shadowed words in a word list. It means, it cannot skip the shadowed words. Thus, to allow `traverse-wordlist` to skip shadowed words, a proposal should be created to change the normative text description. ,------------------------------------------ | 2024-06-21 09:15:10 ruv replies: | requestClarification - shadowed names | see: https://forth-standard.org/standard/tools/TRAVERSE-WORDLIST#reply-1253 `------------------------------------------ > "Execute xt once for every word in the wordlist wid", but does not say whether "every word" includes shadowed words or not. I can't agree with this. "Every word in the word list" means every **word that was placed** in the word list **and was not subsequently removed** from the word list. That is, shadowing does not change anything in this regard. ,------------------------------------------ | 2024-06-21 11:03:38 UlrichHoffmann replies: | testcase - Possible Test Case | see: https://forth-standard.org/standard/block/LOAD#reply-1254 `------------------------------------------ Hello @JimPetersen the test passes on gforth. It should pass on an standard system given it provides the BLOCK word set. Suggestion for improving the test: - Please comment on what actually is checked by the test and why it is likely to fail? (What do we expect, what could go wrong). - As the loading of the blocks ist done interpretively and from within a definition it would be interesting what the idea behind distinguishing these cases is. - maybe more telling names could help to improve understanding the test cases ,------------------------------------------ | 2024-06-21 11:16:45 UlrichHoffmann replies: | referenceImplementation - Possible Reference Implementation | see: https://forth-standard.org/standard/block/THRU#reply-1255 `------------------------------------------ Hello @JimPetersen your contribution has been discussed in the the Forth Standards Committee interim Meeting von 2024-02-16. Thanks for the reference implementation of `thru` that seems to work fine given `u1` is less or equal to `u2`. if `u1` is greater than `u2` it will load blocks in a huge sequence... Your reference implementation might check that and load no block at all as is implied by the standard text `numbered u1 through u2 in sequence`. The sequence is empty if `u1` is greater than `u2`. Thanks also for the test case. The comments regarding the test case for [contribution #280](https://forth-standard.org/standard/block/LOAD#contribution-280) hold for this test case as well. ,------------------------------------------ | 2024-06-21 11:39:15 UlrichHoffmann replies: | proposal - Appendix F doesn't cater for strings. | see: https://forth-standard.org/proposals/appendix-f-doesn-t-cater-for-strings-#reply-1256 `------------------------------------------ Hello @albert, we discussed your contribution #314 in the Forth Standard's Committee interim meeting on 2024-02-16. The comittee considers your contribution more a comment to some other contribution, most likely to the [discussion of appendix F](https://forth-standard.org/standard/testsuite). The committee kindly asks to repeat your comment there. This contribution will be retired (but can be re-opened later at any time if requested). ,------------------------------------------ | 2024-06-21 11:41:42 UlrichHoffmann replies: | proposal - Appendix F doesn't cater for strings. | see: https://forth-standard.org/proposals/appendix-f-doesn-t-cater-for-strings-#reply-1257 `------------------------------------------ Hallo Albert, we also encourage you the provide appropriate string tests. The commitee will review and consider them. ,------------------------------------------ | 2024-06-21 11:48:01 UlrichHoffmann replies: | proposal - String store and fetch | see: https://forth-standard.org/proposals/string-store-and-fetch#reply-1258 `------------------------------------------ Hello @albert, we discussed your contribution in the Forth Standard's Committee interim meeting on 2024-02-16. Thanks for you contribution. The committee appreciates your effort on simplifying string handling. The committee kindly suggest, that you - elaborate on possible buffer overflow issues that can arise when using the string words you propose. - use terminology as close as possible to the current standard's terminology in order to allow to easier adoption. - create a string package with a reference implementation loadable on standard systems in order to establish common pratice for your string words. Thanks again for your effort. ,------------------------------------------ | 2024-06-21 12:24:06 AntonErtl replies: | proposal - Special memory access words | see: https://forth-standard.org/proposals/special-memory-access-words#reply-1259 `------------------------------------------ ## Address units I will extend the discussion of larger address units to suggest adding b-addr and related stuff, or alternatively specifying that systems that implement these words are required to have 8-bit address units. But in contrast to what you write, if we take the latter option, there is no need for b-addr. ## addr vs. c-addr Yes, as far as the standard is concerned, addr has the least alignment requirements. But it is also used in practice as a stand-in for any kind of address, including addresses with stricter alignment requirements (I am sure I am not alone in this usage of addr); so using c-addr makes the intent of not requiring alignment clearer to the reader. ## u vs. x Zero-extending is what you do with unsigned numbers, so if you use the result of `w@` as a number, the result of `w@` is an unsigned number. OTOH, if you apply `w>s` to the result of `w@`, the result is just treated as a funny representation of a signed number (not an n, but not a u either); if we don't know what it is, we use x, so using x would be ok here. Likewise, if we use, say, `lbe` on the result of `w@`, one can see the input of `lbe` as a funny representation of an unsigned or signed number, and the output as an unsigned number or a funny representation of a signed number. So yes, one can argue for using x everywhere except for the output of the sign-extending words. However, I don't see that it makes a difference in what kinds of programs are considered conforming to this specification or how systems are implemented, so we should use the type that makes it easiest to understand what is going on. And in this respect using u as output type for `w@` and `w@ lbe` makes it very obvious that the result is zero-extended, no need to consult the prose of these words for determining that. Another idea that I had some time ago was to have specialized types for the various intermediate results of the decomposition, e.g., bewn for a big-endian 16-bit signed number. This would allow specifying the proper sequences in the conversion through the type system, but would make the specification more complex. E.g., for the `w` words we would have: ```` w@ ( c-addr -- u|wn|bewn|lewn|bewu|lewu ) w! ( u|n|bewn|lewn|bewu|lewu c-addr -- ) wbe ( bewn -- wn | bewu -- u | n -- bewn | u -- bewu ) wle ( lewn -- wn | lewu -- u | n -- lewn | u -- lewu ) w>s ( wn -- n ) ```` I think that this amount of detail (including specifying all these types) makes the specification harder rather than easier to understand. Concerning the whether the things that are processed with these words are numbers: they certainly cannot be xts in a portable program, because an xt may consume a full cell, which may be larger than 16 bits, 32 bits, and in theory even larger than 64 bits. Also, the xt is specific to the process where it originates from, so it makes no sense to communicate it to elsewhere. The same goes for addresses. So that leaves us with integer numbers and bitmaps (including Forth flags). For bitmaps, x is more appropriate than u. Does this outweigh the benefit of making the zero extension obvious? If we add x to the variant with the specialized types above, things become even more complex. ## 2s-complement [2s-Complement Wrap-Around Integers](http://www.forth200x.org/twos-complement.html) have been standardized at the 2015 meeting. ,------------------------------------------ | 2024-06-23 17:28:45 ruv replies: | proposal - Special memory access words | see: https://forth-standard.org/proposals/special-memory-access-words#reply-1260 `------------------------------------------ > 2s-Complement Wrap-Around Integers have been standardized at the 2015 meeting. Yes. But it's for single-cell and double-cell singed integer numbers in the Forth system. If a binary interface uses another format for negative integers (for example, the least significant bit for sign), then the sequence: ``` w@ ( addr -- x ) wbe ( x -- x ) w>s ( x -- n ) ``` does not return an implied signed integer number. Why is this so from a formal point of view? Where are data types not matched? I think, the text description for `w>s ( x -- n )` should specify a format for the stack parameter in the position _x_. From this description it should be clear that the least significant 16 bits of _x_ must represent a signed integer **in two's complement format**, and the remaining bits of _x_ have no meaning. ,------------------------------------------ | 2024-06-26 17:38:13 ruv replies: | proposal - Special memory access words | see: https://forth-standard.org/proposals/special-memory-access-words#reply-1261 `------------------------------------------ > ### _u_ vs. _x_ > I don't see that it makes a difference in what kinds of programs are considered conforming to this specification or how systems are implemented, "_u_" is a symbol for the "unsigned number" [data type](https://forth-standard.org/standard/usage#table:datatypes); the set of values of this data type is the integers in the range { 0 ... _max-u_ } (_max-u_ is defined in [3.2.6 Environmental queries](https://forth-standard.org/standard/usage#subsection.3.2.6)). This data type defines not only a format (zero-extended), but also **the interpretation** for data objects as particular integer numbers. Namely, _u_ defines a **particular mapping from the set of data objects to the set of values**. If a mapping from the set of single-cell data objects to a set of values **is unknown** (or can vary) for a stack parameter, the standard can use the only _x_ data type for this parameter. For example, in the phrase `w@ ( x1 ) dup 1 rshift swap %1 and if negate then ( n )` the stack parameter in the position _x1_ is not a member of _u_, since the _u_ mapping from the data objects to the values does not hold for this parameter! In this example, if the parameter in the position _x1_ is `%11` (as a tuple of bits), it is not the number `3`, but the number `-1`, and it's defined by the application, not by the standard. > using _u_ as output type for `w@` and `w@ lbe` makes it very obvious that the result is zero-extended, no need to consult the prose of these words for determining that. The use of _u_ also implies the specific mapping from the set of data objects (bit tuples) to the set of values for the stack parameter. And this mapping does not hold. Therefore, this use is invalid. ,------------------------------------------ | 2024-06-29 00:00:46 ruv replies: | requestClarification - Behavior of `represent` when buffer length is zero | see: https://forth-standard.org/standard/float/REPRESENT#reply-1262 `------------------------------------------ Correction. If not exception, it should be: ``` t{ 0.1e pad 0 represent -> 0 0 -1 }t t{ 0.4e pad 0 represent -> 0 0 -1 }t t{ 0.6e pad 0 represent -> 1 0 -1 }t ``` Concerning 0.5e — it's unclear. Probably, it's system defined.