Digest #13 2016-12-09


[21] 2016-07-03 16:20:50 JennyBrien wrote:

example - Mistake in the specification of significand?

Convertible string := <significand><exponent> <significand> := [<sign>]<digits>[.<digits0>] <exponent> := E[<sign>]<digits0> <sign> := { + | - } <digits> := <digit><digits0> <digits0> := <digit>* <digit> := { 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 }

Surely it should be [<sign>]<digit>[.<digits0>] ? Only one digit allowed before the decimal point?

[24] 2016-11-22 10:02:04 GerryJackson wrote:

comment - Incomplete specification of SYNONYM

Shouldn't the synonym of a word inherit the restrictions of the parent word. For example


' NEW-TO \ Is apparently valid because it isn't forbidden whereas

' TO \ Is an ambiguous condition

Also this is not forbidden and would be rather confusing


' TO

All that it needs is to add a sentence such as:

All ambiguous conditions applying to oldname, also apply to newname.


[r33] 2016-09-11 17:04:33 mtrute replies:

proposal - WLSCOPE -- wordlists switching made easier

Why did you choose vocabularies? The Forth Standard does not contain them, it specified wordlists instead. A better interface and more standard like would be

IN ( wid "action" -- )

with wid beeing a wordlist identifier as returned by WORDLIST.

: IN get-current >r set-current ' execute r> set-current ;

[r36] 2016-09-24 17:34:30 mtrute replies:

example - Obvious implementation

To honor the "greater than zero"


[r37] 2016-09-24 17:44:05 mtrute replies:

proposal - WLSCOPE -- wordlists switching made easier

Why do you use vocabularies? They are not part of the standard and they can do harmful things to the environment. I'd suggest using word lists instead. They are standard and they are much simpler to use (and define).

  : IN ( wid "action" -- ) 

Use it as follows

IN gui : init-gl ( .. -- .. ) ... ;
IN gui DEFER bar

The constant for the word list can be wrapped as a vocabulary easily. Many Forth's have tools to show the content of a wordlist by it's id already (in amforth it's called show-wordlist) so there is no need for vocabularies, at least not at the standard level.

[r39] 2016-10-31 10:45:37 StephenPelc replies:

requestClarification - Source of a string

Forth does not know about STDIN. Many Forths, both desktop and embedded, allow I/O through KEY and EMIT and friends to be vectored. This could be through a console, a serial line, a TCP/IP connection. How the vectoring occurs is not (yet) standardised. ACCEPT works with KEY and EMIT and friends and so inherits whatever vectoring the Forth system provides. Note that the current input and output device should be vectored separately.


[r40] 2016-11-22 10:29:50 GerryJackson replies:

comment - TRAVERSE-WORDLIST is in the wrong word set

Ok but I don't see why the NAME>... words shouldn't also go in the Search-Order word set. They and TRAVERSE-WORDLIST are a family of words that belong together and wouldn't be much use without wordlists. Your argument could be used to exclude WORDLIST from the Search-Order wordset as it's only creating a wordlist not affecting the search order (I'm not seriously suggesting that).

[r41] 2016-12-08 09:38:00 AntonErtl replies:

comment - TRAVERSE-WORDLIST is in the wrong word set

Once we have FIND-NAME, NAME>... makes perfect sense without search order words.

As for the programming tools, it contains two sets of words: words like SEE that are normally used just for debugging and not used inside colon definitions (except for debugging purposes); and words like AHEAD that some in the Forth community consider unnecessary for application programming; NAME>... is in the latter category.

[r42] 2016-12-08 09:43:19 AntonErtl replies:

comment - Incomplete specification of SYNONYM

Good point.

Other, less urgent issues are inheritance of TO <name> semantics, and inheritance of the property of being a child of a CREATEd word. Any other issues?

[r43] 2016-12-08 14:33:37 AntonErtl replies:

comment - Incomplete specification of SYNONYM

Once the "child-of-CREATE" property can be inherited (for >BODY), we need to specify if the following is standard and what it does:

: foo does> drop ." foo" ; : bar does> drop ." bar" ; create a foo synonym b a bar a

We did not standardize using IMMEDIATE on a synonym, should we allow using DOES>?