,---------------. | Contributions | `---------------´ ,------------------------------------------ | 2018-11-03 13:15:53 ruv wrote: | proposal - Case sensitivity | see: https://forth-standard.org/proposals/case-sensitivity#contribution-73 `------------------------------------------ Citation from [meeting minutes 2016](http://www.forth200x.org/meetings/minutes2016.pdf) > **Case insensitivity** > This has always been left to system implementations, but does cause significant confusion to new users. Many new and many popular programming languages are case sensitive. It seems that the issue for new users is not case sensitivity itself, but that in this case the standard names should be spelled in upper-case. Personally, I would be against the requirement of case insensitivity in the standard. But it seems reasonable if the standard will require the capability of finding the standard words in lower-case as well as in upper-case. ## Suggested changes The changed fragments are emphasized with bold. ### 3.3.1.2. Definition names The phrase: > Programs that use **lower case** for standard definition names or depend on the case-sensitivity properties of a system have an environmental dependency. becomes: > Programs that use **mixed-case** for standard definition names or depend on the case-sensitivity properties of a system have an environmental dependency. Perhaps it is also needed to mention that **mixed-case** means that some letters in a name are in upper-case and some in lower-case. ### 3.4.2. Finding definition names The phrase: > A system shall be capable of finding the definition names defined by this standard when they are spelled with **upper-case** letters. becomes: > A system shall be capable of finding the definition names defined by this standard when they are spelled with **either upper-case or lower-case** letters. ,---------. | Replies | `---------´ ,------------------------------------------ | 2018-09-23 06:05:49 AntonErtl replies: | requestClarification - ALSO without VOCABULARY | see: https://forth-standard.org/standard/search/ALSO#reply-193 `------------------------------------------ Vocabularies are common practice, and have no technical problems. That's a good reason to keep them standardized. If you, like me, prefer to use wordlists, do it. Standardized vocabularies do not impede this. ,------------------------------------------ | 2018-09-23 06:23:10 AntonErtl replies: | requestClarification - Should TO be findable? | see: https://forth-standard.org/standard/core/TO#reply-194 `------------------------------------------ No ambiguous condition has been specified for [DEFINED] TO, and given that it does not return an xt, I don't see a reason for it. Yes, a system can get an xt for TO through SEARCH-WORDLIST or FIND. For FIND, the specification is quite fuzzy about the returned xt (and see the proposal on clarifying FIND for that), for SEARCH-WORDLIST it isn't. Gforth therefore returns the xt corresponding to interpretation semantics from SEARCH-WORDLIST (and nobody has complained about that). FORTH-WORDLIST is specified as containing all implemented standard words, and that includes TO. ,------------------------------------------ | 2018-09-24 09:28:53 AtH replies: | requestClarification - ALSO without VOCABULARY | see: https://forth-standard.org/standard/search/ALSO#reply-195 `------------------------------------------ Is it consensus, that status of **ALSO**, **VOCABULARY** and **FORTH** should be the same (all in the standard or all not in the standard)? **ALSO** without **VOCABULARY** makes little sense in the Standard Program. They all use the same undocumented construction (vocabulary). I suggest to legalize all three (and document vocabulary) or get rid of them. I’m now in the process of migration from old nested vocabulary system to **ALSO**/**ONLY** and context of several **WORDLIST**s. When I learned, that **VOCABULARY** is no longer in Standard, I tried to get rid of this word. My understanding now is that if I implement **ALSO**/**ONLY**, **VOCABULARY** should stay. Semantics will change a little, because **VOCABULARY** now aren’t based on each other. Also vocabulary execution affects now the search list in more predictable and standard way. If this change is important, a new word should be introduced. **VOC** or **DICTIONARY** could be used as the new name. ,------------------------------------------ | 2018-10-08 10:55:50 StephenPelc replies: | requestClarification - Should TO be findable? | see: https://forth-standard.org/standard/core/TO#reply-196 `------------------------------------------ POSTPONE [COMPILE] and so on are ambiguous with respect to TO because it is unspecified how TO is implemented and how it works, e.g. it probably parses, but doesn't have to. In other words, even if you got an XT back, you would not know what to do with it, hence the code is not portable. [DEFINED] just wants to know if the word exists in the dictionary, so it only needs to return a flag. Note that most systems permit ' ['] and so on to return an xt for any word in the system. At least one fails if the action of that xt is undefined by the standard. ,------------------------------------------ | 2018-10-11 18:41:22 ruv replies: | example - Need lock on already posted comments | see: https://forth-standard.org/meta-discussion#reply-197 `------------------------------------------ StephenPelc is right. The webpage with form to post a reply (e.g. https://forth-standard.org/profile/reply/57 ) is loaded via `GET` request (as it should be), and so, when you navigate from this page into another (regardless of the HTTP method), the browser's "Back" button works pretty well and you get the last view of this page including fields that are filled with your text. In general case, this issue can be solve via **nonce** hidden field, that allows to catch duplicate post. But it seems not so easy in implementation. I would suggest just to use the id of the last message (151 in this case) along with (or in place of) the id of a conversation as a *reference*: ``` # old https://forth-standard.org/profile/reply/57 # ^^ # new https://forth-standard.org/profile/reply/57/151/ ``` In the appropriate `POST` request handler it is need to check whether this user already answered with particular *reference*, and: - if not answered yet, — just save the message text as usual, and the *reference*; - otherwise either update the existing message text, or reject updating (response with "409 Conflict" HTTP status). The first reply can use 0 as a reference. Regarding contributions, and other matter — the approach is the same: ``` # old https://forth-standard.org/profile/contribute/meta-discussion # new https://forth-standard.org/profile/contribute/meta-discussion/59/ ``` ,------------------------------------------ | 2018-10-11 18:52:13 ruv replies: | example - Need lock on already posted comments | see: https://forth-standard.org/meta-discussion#reply-198 `------------------------------------------ Actually, this reference can play role of **nonce** and can be delivered via hidden field, in place of segment in URL. In such case it is need to ensure that ETag of the page with form is updated when a new answer was submitted. Or maybe better, just add something like "Cache-Control: max-age=30" into the response headers.