Digest #13 2016-12-09
Contributions
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?
Shouldn't the synonym of a word inherit the restrictions of the parent word. For example
SYNONYM NEW-TO TO
' 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
SYNONYM TO TO
' TO
All that it needs is to add a sentence such as:
All ambiguous conditions applying to oldname, also apply to newname.
Replies
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 ;
To honor the "greater than zero"
: SPACES 0 MAX 0 ?DO SPACE LOOP ;
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" -- )
GET-CURRENT >R SET-CURRENT ' EXECUTE R> SET-CURRENT ;
Use it as follows
WORDLIST CONSTANT gui
IN gui : init-gl ( .. -- .. ) ... ;
IN gui VARIABLE foo
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.
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.
Stephen
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).
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.
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?
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>?