Digest #47 2018-11-04
Contributions
Citation from meeting minutes 2016
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
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.
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.
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 WORDLISTs.
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.
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.
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/
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.