HughAguilar писал(а):
1.) Straight Forth should support a cross-compiler. It needs LITERAL etc. vectored so we can have literal numbers in TARG words. It needs to support words to fetch and store the vocabulary-number given an xt, and also fetch and store the immediate-flag. There are some other features needed, but they are all trivial. I wrote MFX the cross-compiler for the MiniForth processor in UR/Forth and I had only one page of assembly-language code that was specific to UR/Forth. Everything else was Forth-83. Straight Forth needs to be only a slight upgrade from Forth-83.
Yes, indeed, interpreter engine should be carefully described and made extensible as much as possible. Words like vectored LITERAL are simple and gives a great flexibility. There are no reasons to limit usage of Forth by innatural rules.
HughAguilar писал(а):
2.) Straight Forth should support numerical programs. It needs one kind of number. Instead of having + D+ F+ etc. for adding different kinds of numbers, we have only + for our one kind of number. This design is not necessarily going to be the most efficient --- this design is intended to be convenient --- we could use double-precision IEEE-754 floating-point numbers for the greatest convenience (the Lua language does this). I have written code in ANS-Forth for ratios, but they are 32-bit integers --- they need to be 64-bit integers to be useful --- the math required is easy.
I'm agreed with this idea in general, but in practive I use separate F+ and other floaing-point words. An approach looks simple - if we have a hardware of certain type, Forth should support it as close to it's model as possible. So, since we have FPU it is good to support FPU formats and operations. Maybe with another higher level, but I feel programmers will dig into CPU/FPU sooner or later when limited by operations. Anyway, we must implement commands like + for different formats before adding higher-level words.
For + (and other words like this) we can have a slightly crazy thing like vectors
When base low-level words are explicitly defined by prefixes (D+ for 32-bits integer, F+ for double floating etc.), + may be vectorized and set to 'base format' by default.
HughAguilar писал(а):
3.) Straight Forth should support text-processing programs. A problem in ANS-Forth is that there is no where to put strings. <# #> WORD etc. all use the same memory, so they corrupt each other's data. The user needs a string-stack to hold strings temporarily. The user needs good pattern-matching capability. I have written STRING-STACK.4TH in ANS-Forth that does all of this --- this is some of the best Forth code that I have written in years!
Yes! Tex processing is very probably to use in scripting, where Forth is strong. I think words like <# # #> are just temporarily solution that accepts when no other adequate way was studied. It is not clear for me now how exactly this should be solved, by it definitely should be solved. At least, a set of string-supporting words must exist.
HughAguilar писал(а):
4.) Straight Forth should support quotations that can access the parent function's local variables despite the fact that the HOF (the function that the parent function calls, and which executes the quotation) has local variables of its own. I have written rquotation code in VFX and SwiftForth that does this --- I didn't invent rquotations --- I just improved the idea and implemented them using tricky non-standard assembly-language.
I have a rule for including such capabilities into the Forth engine. We must add a feature if it depended on the internal, hided algorithm inside Forth and cannot be added without deeply invasion to source code. Vectored LITERAL is an example of such thing - we must think about this, because cannot make LITERAL vectored after Forth is started.
I think quotations is a kind of this features. This should be described and changes to the engine must be stated clearly.
HughAguilar писал(а):
5.) Straight Forth should allow automatic smudging of words from the dictionary. In the definition of a class, we can have private words that can't be referenced outside of the class. Also, in a file, we can have private words that can't be referenced outside of the file. I have written an OOP (object-oriented-programming) system in ANS-Forth that can easily be upgraded to smudge private words as described here. In MFX I wrote code in UR/Forth to smudge private words in a file. This is easy.
6.) Straight Forth should support "chains" as the primary data-structure. The users will be encouraged to use chains for their data unless chains don't work and a more complicated data-structure is needed (rare). The chains internally are self-balancing binary-trees with uplinks. I have extensive code written in ANS-Forth to support self-balancing binary-trees, although I don't have the uplinks done yet, so I'm reasonably close to having chains.
Yes*2. See above - these features requires a certain changes in the engine, so must be described in the standard.
HughAguilar писал(а):
7.) Straight Forth should be simple and understandable. Fancy features will not be supported unless they are absolutely necessary. We are competing against C that was supposed to be simple and understandable but is actually complicated and confusing. To succeed, we need to focus on simplicity.
Oh, going a way of 'cool words' we will fall into another Forth-religion
Indeed, we need to focus on the necessary words and leave other at the libraries level.
HughAguilar писал(а):
Forth-200x was supposed to be completed in the 2000 decade, but it wasn't, so the name should have been changed to Forth-201x. Soon the year 2020 will pass, so the name should be changed to Forth-202x. The Forth-200x promoters are mired in tedious debates that go on for years, typically debating an idea that could be dismissed with two minutes of thought (Alex McDonald's "recognizer" idea, for example). It is unlikely that Forth-200x will ever be complete. Every year it gets bigger and more complicated, and it still lacks basic features needed to support cross-compilation. Eventually the year 2100 will pass and the Forth-200x committee (perhaps their grand-children's grand-children) will still be mired in tedious debates about idiotic ideas.
I wonder how stubborn they are standing at their swampy ground.
Btw, we meet Forth one more time in the product our customer wants to replace
The device originated from UK and use high-level scripting language transformed to the .FTH file, with Forth code inside, of course. It is too old and the device has very limited capabilities, so completely rewriting this part of the project is in progress. I just wonder, why nobody of ANS hear about such brilliant application?
Maybe nobody of practical programmers cares about that company of self-claimed experts?
HughAguilar писал(а):
I am hoping that Russians are smarter.
Hmm... a tons of flame took place here
Anyway, it is a challenge indeed.
HughAguilar писал(а):
I just had an idea: instead of calling it Straight Forth, it could be called Adequate Forth.
!