Forth-2012 and happier news
82 views
Skip to first unread message
The Beez
Jun 11, 2015, 9:14:57 AM6/11/15
to 4th-co...@googlegroups.com
Hi 4tH-ers!
Let's start with the sad news first. I've always tried to keep 4tH as aligned as possible with the current Forth-2012 (some call it Forth-200x) standard. Note this is NOT an ANS standard, but just a Forth standard that is based on it. Still, keeping aligned with the current trends in Forth seemed like something you would expect me to do. It's not that I did (or was even able to) fully comply with anything that was passed there, but.. close.
One of my major problems with ANS Forth has always been that it is a SYSTEMS standard, not a LANGUAGE standard. The consequence was that e.g. cross compilers (but also 4tH) could never be an "ANS system". The current trend is, that this is worsening.
One of the first things was that FP systems had to have a separate stack - which placed a cute thing like Zen float out of scope. I can see the reasoning, but I found that a mixed stack is not too much of a problem as long as you put "normal" values out of the way before doing FP operations.
The second was, making 2 complement compulsory. Not long after that, 1 char == 1 address unit came along.
The crazy thing is that most 4tH libraries that do low level math ARE 2 complement AND (due to its C roots) 1 char == 1 address unit. So, why object? Well, that is where portability comes in. I know those libraries won't work on systems that do signed magnitude or 1 complement. So, IMHO they have an (no matter how small or even existing) environmental dependency. Consequently, they should be labelled that way.
Yes, 4tH has (like most Forths) characters that equal one and exactly one address unit. I also know that when e.g. 1 char == 2 address units, several programs won't work anymore, because I have worked dirty (conceptually seen) and there is work to do. But I also know what came of Forth-83, who set cells to be 16-bit, divided into 2 8-bit bytes. Using "magic numbers" is never a smart idea. Especially in a standard.
So after a little soul searching I've done the following: I've reserved the right to deviate from Forth-2012 and do the ANS-Forth (Forth-94) thing. I've made changes in the manual accordingly.
What does it mean to you? At the moment, nothing at all. I won't remove ANY Forth-2012 words or wordsets - nor will I withdraw from the standardization process - nor will I boycott or discard any future proposals. If it fits, I'll add them in one form or another, just like I did before.
But the moment a problem arises which forces me to either deviate or conform to the Forth-2012 standard, I will stay with the ANS-interpretation of the standard and not the Forth-2012 interpretation.
The most tangible change you will see is that in the ANS Forth statement of the manual I will address the Forth 2012 and all Forth 2012 words in the glossary are marked as such.
Comments are, as always, welcome if you need to discuss this issue here any further.
Hans Bezemer
BTW, and what about the happy news?! Well, click this!
Let's start with the sad news first. I've always tried to keep 4tH as aligned as possible with the current Forth-2012 (some call it Forth-200x) standard. Note this is NOT an ANS standard, but just a Forth standard that is based on it. Still, keeping aligned with the current trends in Forth seemed like something you would expect me to do. It's not that I did (or was even able to) fully comply with anything that was passed there, but.. close.
One of my major problems with ANS Forth has always been that it is a SYSTEMS standard, not a LANGUAGE standard. The consequence was that e.g. cross compilers (but also 4tH) could never be an "ANS system". The current trend is, that this is worsening.
One of the first things was that FP systems had to have a separate stack - which placed a cute thing like Zen float out of scope. I can see the reasoning, but I found that a mixed stack is not too much of a problem as long as you put "normal" values out of the way before doing FP operations.
The second was, making 2 complement compulsory. Not long after that, 1 char == 1 address unit came along.
The crazy thing is that most 4tH libraries that do low level math ARE 2 complement AND (due to its C roots) 1 char == 1 address unit. So, why object? Well, that is where portability comes in. I know those libraries won't work on systems that do signed magnitude or 1 complement. So, IMHO they have an (no matter how small or even existing) environmental dependency. Consequently, they should be labelled that way.
Yes, 4tH has (like most Forths) characters that equal one and exactly one address unit. I also know that when e.g. 1 char == 2 address units, several programs won't work anymore, because I have worked dirty (conceptually seen) and there is work to do. But I also know what came of Forth-83, who set cells to be 16-bit, divided into 2 8-bit bytes. Using "magic numbers" is never a smart idea. Especially in a standard.
So after a little soul searching I've done the following: I've reserved the right to deviate from Forth-2012 and do the ANS-Forth (Forth-94) thing. I've made changes in the manual accordingly.
What does it mean to you? At the moment, nothing at all. I won't remove ANY Forth-2012 words or wordsets - nor will I withdraw from the standardization process - nor will I boycott or discard any future proposals. If it fits, I'll add them in one form or another, just like I did before.
But the moment a problem arises which forces me to either deviate or conform to the Forth-2012 standard, I will stay with the ANS-interpretation of the standard and not the Forth-2012 interpretation.
The most tangible change you will see is that in the ANS Forth statement of the manual I will address the Forth 2012 and all Forth 2012 words in the glossary are marked as such.
Comments are, as always, welcome if you need to discuss this issue here any further.
Hans Bezemer
BTW, and what about the happy news?! Well, click this!
Reply all
Reply to author
Forward
0 new messages