> On May 5, 10:25 am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
> wrote:
> > <BUILDS existed, because it allowed CREATE to be different
> > and consume less space.
> And in that *system* "CREATE ... DOES>" did not work, because "DOES>"
> assumed a preceding "<BUILD".
> Having a single defining word that works as CREATE and also works as
> <BUILDS is a different system than having one defining word that works
> as CREATE and a different word that is paired with DOES> ... call that
> different word paired with DOES> what you will, <CREATE if you wish.
> "CREATE ... DOES>" code from a system in which there is one such
> defining word and DOES> works on the most recently created word does
> not work on a system in which DOES> is paired with <BUILDS and CREATE
> is not.
> As was nearly hashed out recently, in some instances the
> implementation technique that allowed the more compact CREATE to also
> be paired with DOES> rendering the original implementation of <BUILDS
> incompatible with DOES> is not always feasible, in which case to it is
> necessary to use the original <BUILDS implementation technique. But it
> remains the single defining word system, not the system with two
> distinct defining words.
You must have read my RfD, or at least, were the only one to
understand it.
My point is that in ANS-Forth, CREATE is overloaded --- CREATE by
itself and CREATE with a DOES> are two entirely different concepts.
The Forth-way is that each word should do only one thing. It makes
sense to have CREATE and <BUILDS as distinct words, because they are
distinct concepts --- it is a philosophical issue.
If <BUILDS is used, and it does not get fixed-up with a DOES> prior to
the next definition, then that is an error. If CREATE is used, and it
does get a DOES> after it, then that is also an error. In either case,
compilation aborts with an error message.
If you assume that headers are not mixed in with data (and this is
assumed in Straight Forth), then CREATE can be defined like this:
: CREATE HERE CONSTANT ;
In most implementations, the value of the constant does not take up
memory on the target platform. There is no place that you can find it
in target memory. Constants just compile as literals wherever they are
referenced.
Defining <BUILDS is more complicated. I won't go into that here. I
will say however, that this is somewhat simplified by the fact that
you know ahead of time that there is going to be a DOES> --- you don't
have to allow for both possibilities, that there is a DOES>
(references will be a CALL to the DOES> code) or that there is no
DOES> (references will be a compilation of a literal).
Implementation is always simplified when each word does only one
thing. Remember the "universal processor" (word, data, food) in the
"Thinking Forth" book? We want to avoid that. Right now, CREATE is
used for both both simple variables that just return an address and
complex variables that execute the attached DOES> code. The situation
could be worse though! Imagine if CREATE were used instead of colon to
define functions, and the semi-colon had to fix-up the CREATE for this
case (similar to the way that DOES> fixes-up CREATE for its case).
That would be similar to what we already have with CREATE defining two
kinds of words, but worse, as CREATE would define three kinds of
words. That would be taking the current line of thinking to its
extreme!
Hugh Aguilar wrote:
> Implementation is always simplified when each word does only one
> thing. Remember the "universal processor" (word, data, food) in the
> "Thinking Forth" book? We want to avoid that.
To be honest, sometimes I even have to agree with you. I want my words uniform - see the header discussion - so it is not complicated to change a CREATE to a <BUILDS word (replace the COMPILE,-action, fill in the DODOES field), but the concept indeed feels like the word/data/food processor.
The rationale to throw out <BUILDS was that an implementation technique existed where CREATE and <BUILDS do the same thing. This would be the rationale to throw out COMPILE, - because there is an implementation technique where , does the same thing. The reason why Forth-83 felt inclined to do so is that Forth-83 actually mandated an implementation technique. That was its biggest mistake.
Forth-83 made a number of incompatible decisions, and though some decisions by themselves are good ideas (like -1 as TRUE or to have a one's complement called NOT), but they broke code. Maybe the idea was that Forth programs are not maintainable (or intented to be maintained), anyways, and will be quickly rewritten to the then-current standard.
Chuck Moore is even more radical with breaking code, when designing his next system.
-- Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
On May 8, 4:25 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> The rationale to throw out <BUILDS was that an implementation technique
> existed where CREATE and <BUILDS do the same thing. This would be the
> rationale to throw out COMPILE, - because there is an implementation
> technique where , does the same thing. The reason why Forth-83 felt
> inclined to do so is that Forth-83 actually mandated an implementation
> technique. That was its biggest mistake.
To a large extent, the purpose of a standard is to abstractify
implementation.
On the other hand, being wishy-washy isn't the same thing as
abstractification. For example, I've pointed out that the ANS-Forth
standard says that locals may or may not be held on the return stack.
This doesn't help! In a case like this, it really is necessary to
specify where the locals are, and to put them somewhere that makes
sense (not on the return stack!). When the standard is wishy-washy
like this, then the user has to assume the worst-case scenario (that
they are on the return stack) so that his code will work on any
standard-compliant system --- this is really no better than if the
standard specified the worst-case scenario --- he can't really use >R
R> R@ etc. in conjunction with locals, because this may not work on
some compliant compilers.
Abstractification is a good thing. For example, COMPILE, was a huge
step up from using comma, as this abstractified compilation and
allowed any kind of threading scheme to be used (including the
generation of machine code, which is what everybody wants to do with
the modern processors). Being wishy-washy is a bad thing. For example,
the standard should say that locals are on their own stack, as this
allows >R R> R@ etc. to be used in a function whether locals are being
used in that function or not.
Note that in Straight Forth I'm not going to support >R R> R@ etc. at
all (because they are ugly and error-prone), so it makes no difference
to me where the locals are.
Straight Forth will specify that the locals get destroyed when the
function exits. This means that they can be on the return stack (as
opposed to the heap), although they might have their own stack
(because some processors don't provided indexed addressing of the
return stack). This is abstractification --- so long as the locals
behave in the expected way, then they can be implemented in any way
that is convenient for the compiler-writer.
> Forth-83 made a number of incompatible decisions, and though some
> decisions by themselves are good ideas (like -1 as TRUE or to have a
> one's complement called NOT), but they broke code. Maybe the idea was
> that Forth programs are not maintainable (or intented to be maintained),
> anyways, and will be quickly rewritten to the then-current standard.
> Chuck Moore is even more radical with breaking code, when designing his
> next system.
The point of Straight Forth is that it makes sense. Breaking legacy
code is not a problem for me.
Some companies seem to have a high turnover in programmers (usually
because the boss is a non-programmer). These companies are the ones
that primarily care about not breaking legacy code. They often have a
lot of code that was written by a programmer who has since been fired.
They have no idea how that code works, but they want it to continue
working (because they don't have confidence that any of their current
programmers are capable of rewriting the program from scratch) --- so
they become highly focused on the idea that no new compiler should
ever break legacy code. Companies like this deserve to go out of
business --- I don't care about them --- the name "Straight" means,
among other things, that whiners are not tolerated.
On May 8, 11:25 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> Forth-83 made a number of incompatible decisions, and though some
> decisions by themselves are good ideas (like -1 as TRUE or to have a
> one's complement called NOT), but they broke code.
I don't really agree with this. Forth-83 is Forth-83, and Forth-79 is
Forth-79. Did all the Forth-79 code (and compilers) evaporate into
thin air when the Forth-83 standard was released? Of course not. Did
all the Forth-79 code suddenly cease to function? Of course not.
I just don't see the problem! With each new standard is the
opportunity to take the language in new directions, add new features,
and correct short-comings identified in the previous standard.
However, it doesn't have to be an incremental change. It's a new
standard!
We had ANS-94 and we're working towards 200x. Should we not simply
rename 200x as "ANS-94 Rev 1, 2012" - because *that's* what it really
is.
I think it would have been much more exciting, and more beneficial if
the 200x standard was a 'rip it up and start again' rather than an
update to the previous standard. A new standard doesn't invalidate a
previous standard. ANS-94 will still be there if people don't want to
move to the new standard. They run in parallel.
Mark Wills <markrobertwi...@yahoo.co.uk> wrote:
> We had ANS-94 and we're working towards 200x. Should we not simply
> rename 200x as "ANS-94 Rev 1, 2012" - because *that's* what it
> really is.
> I think it would have been much more exciting, and more beneficial
> if the 200x standard was a 'rip it up and start again' rather than
> an update to the previous standard.
It would certainly have been much more exciting.
There's a problem with this: languages designed by committees aren't
usually very good. So, it makes more sense for someone with a vision
to design their new language, campaign for its adoption, and get that
standardized when it's stable enough.
> On May 8, 11:25 pm, Bernd Paysan<bernd.pay...@gmx.de> wrote:
>> Forth-83 made a number of incompatible decisions, and though some
>> decisions by themselves are good ideas (like -1 as TRUE or to have a
>> one's complement called NOT), but they broke code.
> I don't really agree with this. Forth-83 is Forth-83, and Forth-79 is
> Forth-79. Did all the Forth-79 code (and compilers) evaporate into
> thin air when the Forth-83 standard was released? Of course not. Did
> all the Forth-79 code suddenly cease to function? Of course not.
> I just don't see the problem! With each new standard is the
> opportunity to take the language in new directions, add new features,
> and correct short-comings identified in the previous standard.
> However, it doesn't have to be an incremental change. It's a new
> standard!
> We had ANS-94 and we're working towards 200x. Should we not simply
> rename 200x as "ANS-94 Rev 1, 2012" - because *that's* what it really
> is.
> I think it would have been much more exciting, and more beneficial if
> the 200x standard was a 'rip it up and start again' rather than an
> update to the previous standard. A new standard doesn't invalidate a
> previous standard. ANS-94 will still be there if people don't want to
> move to the new standard. They run in parallel.
> But, what I do know?! Enough ranting!
With most standards bodies (ANSI, ISO, IEEE, etc.) the convention is that new standards *do* invalidate old ones, after a transition period. And the new standard seeks to minimize that transition period and minimize the cost of transitioning, by doing such things as respecting existing practice wherever practical. In the case of programming languages, including Forth, there are users maintaining programs with thousands of lines of code and thousands of systems in the field. They can (and will) be updated to some extent, but radical changes are out of the question.
It might be fun to 'rip it up and start again,' but the result should get a new name.
Cheers,
Elizabeth
-- ==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
> [..] but they broke code. Maybe the idea was > that Forth programs are not maintainable (or intented to be maintained), > anyways, and will be quickly rewritten to the then-current standard.
> Chuck Moore is even more radical with breaking code, when designing his > next system.
There's nothing wrong with dropping "backward compatibility", if this is
reasonable. For example: keeping the x86-line of processors still backward
compatible made their instructions list more than 1000 positions long:
It costs programming time. It costs efficiency. It costs energy.
Let's compare this to about 100 (or maybe less?) instructions of ARM...
Yes, Microsoft grew up exactly by assuring backward compatibility of their
software, but it was different situation "back in the day": when the computers
were expensive, of course everyone preferred to keep both the old and new
versions of software running on the same machine. Today the gear is so
cheap - and powerful at the same time - that it isn't a problem to keep old
machine for old programs (in fact, there could be a problem to sell such old
machine... nobody wants it), or - if anyone will see it as inconvenience - to
use software emulator, until new version of some software will be released.
My guess is, that it wasn't "Forth programs are not maintainable" approach -
but rather an expectation, that for that older programs the older version of
interpreters can be still used, and even the newer versions of such programs
can be still developed according to older standard (why not?), if someone is
afraid of messing the well-tested code. But quite new - "fresh" - programs
can use new standard.
-- Forth is a preserver of health (Hippocrates)
Zbiggy wrote:
> There's nothing wrong with dropping "backward compatibility", if this
> is reasonable.
This comment was clearly tongue-in-check ;-).
But I disagree that the x86 ISA is so long because of backward compatibility. Intel had a chance to demonstrate how a new ISA, developed from scratch, would look like, and they came up with IA64.
Intel instruction sets are so lengthy, because they are designed by committees. x86 is actually good look for all of us, because the main ISA design team at that time designed i432, and only a few people were left to create the x86 ISA (two, IIRC). Therefore, x86 is pretty clean and straight-forward, even considering the time it was designed (height of the CISC age), and that it came from Intel. And the two modes added later (386 mode and amd64 mode) are cleanups, which make the ISA more orthogonal and useful. Additions like MMX and 3DNow! are phased out and declared obsolesent (and AMD stopps to implement 3DNow!). It's not that awful. The worst things from Intel all died.
The ARM ISA is designed by one person, and even then it is one of the more byzantine RISC ISAs, with lots of things cobbled together in one instruction - shifts, conditional execution, normal operations.
-- Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
> [..] x86 is pretty clean and straight-forward, even considering the time
> it was designed (height of the CISC age), and that it came from Intel. > And the two modes added later (386 mode and amd64 mode) are cleanups,
> which make the ISA more orthogonal and useful. Additions like MMX and
> 3DNow! are phased out and declared obsolesent (and AMD stopps to implement
> 3DNow!). It's not that awful. The worst things from Intel all died.
But say: wouldn't it be even more "orthogonal and useful", if they dropped
16-bit legacy, and if the instruction set were restricted to - say - about
100 of carefully chosen commands?
> The ARM ISA is designed by one person, and even then it is one of the > more byzantine RISC ISAs, with lots of things cobbled together in one > instruction - shifts, conditional execution, normal operations.
Well, maybe; still it seems to be most successful RISC anyway, and I'm very
curious about "project Denver" gear, announced for this year by NVidia.
-- Forth is a preserver of health (Hippocrates)
Zbiggy wrote:
> But say: wouldn't it be even more "orthogonal and useful", if they
> dropped 16-bit legacy, and if the instruction set were restricted to -
> say - about 100 of carefully chosen commands?
Intel actually had a 386 version that did drop the 16-bit legacy and some other stuff:
It was a commercial failure. The 386EX, which did not drop 16-bit legacy, was much more successful. You can't say they haven't tried.
>> The ARM ISA is designed by one person, and even then it is one of the
>> more byzantine RISC ISAs, with lots of things cobbled together in one
>> instruction - shifts, conditional execution, normal operations.
> Well, maybe; still it seems to be most successful RISC anyway, and I'm
> very curious about "project Denver" gear, announced for this year by
> NVidia.
Well, they were the first to get the business model right: sell cores to everybody, while all the other RISC cores were only available as chips.
First movers have incredible advantages in these winner-takes-it-all markets.
-- Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
>> But say: wouldn't it be even more "orthogonal and useful", if they
>> dropped 16-bit legacy, and if the instruction set were restricted to -
>> say - about 100 of carefully chosen commands?
> Intel actually had a 386 version that did drop the 16-bit legacy and > some other stuff:
In article <joen7a$a3...@online.de>, Bernd Paysan <bernd.pay...@gmx.de> wrote:
>Zbiggy wrote:
>> There's nothing wrong with dropping "backward compatibility", if this
>> is reasonable.
>This comment was clearly tongue-in-check ;-).
>But I disagree that the x86 ISA is so long because of backward
>compatibility. Intel had a chance to demonstrate how a new ISA,
>developed from scratch, would look like, and they came up with IA64.
That is patently incorrect. Intel never wanted to move on from 32
to 64 bits in a compatible way. They had the Itanium. (Same situation
as the 432. )
Then AMD made them to, by inventing a devilishly clever and
obscure way to move to 64 bits. The best proof is that Intel had to
license the instruction set from AMD.
>Intel instruction sets are so lengthy, because they are designed by
>committees. x86 is actually good look for all of us, because the main
Again. The 8086 was designed by one man Stephen Morse. It was
a clever extension of the 8080 and a reasonable cisc processor,
but without a shred of thought about future enhancements.
(I have his book "8086 architecture". It is adamant about a few
errors and convincing regards design decisions.)
This processor had three characteristics that where in hindsight
responsible for the mess we're in. Too CISCy, segmentation, and
no regards for sufficiently address extensability.
The pressure to stay compatible was what did it.
The "real mode" (a real kludge) was absent in 80286 then reinstated
in the 80386, pressured by mostly Microsoft.
>ISA design team at that time designed i432, and only a few people were
>left to create the x86 ISA (two, IIRC). Therefore, x86 is pretty clean
>and straight-forward, even considering the time it was designed (height
>of the CISC age), and that it came from Intel. And the two modes added
>later (386 mode and amd64 mode) are cleanups, which make the ISA more
>orthogonal and useful. Additions like MMX and 3DNow! are phased out and
>declared obsolesent (and AMD stopps to implement 3DNow!). It's not that
>awful. The worst things from Intel all died.
>The ARM ISA is designed by one person, and even then it is one of the
>more byzantine RISC ISAs, with lots of things cobbled together in one
>instruction - shifts, conditional execution, normal operations.
Remember the Novix? It has also those bit-fields. They just go
directly to parts of the processor that do e.g. shifting.
That is RISC in my book, direct relation to the hardware without
much regard to the assembler programmer.
Conditional execution in one instruction is a very powerful speed
up mechanism. At the time Intel's alternative (complicated multiple
instruction analysis) was not viable.
>--
>Bernd Paysan
Groetjes Albert
(One of the rare occasions that I don't agree with you...)
--
-- Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
> Zbiggy wrote:
> > There's nothing wrong with dropping "backward compatibility", if this
> > is reasonable.
> This comment was clearly tongue-in-check ;-).
> But I disagree that the x86 ISA is so long because of backward
> compatibility. Intel had a chance to demonstrate how a new ISA,
> developed from scratch, would look like, and they came up with IA64.
> Intel instruction sets are so lengthy, because they are designed by
> committees. x86 is actually good look for all of us, because the main
> ISA design team at that time designed i432, and only a few people were
> left to create the x86 ISA (two, IIRC). Therefore, x86 is pretty clean
> and straight-forward, even considering the time it was designed (height
> of the CISC age), and that it came from Intel. And the two modes added
> later (386 mode and amd64 mode) are cleanups, which make the ISA more
> orthogonal and useful. Additions like MMX and 3DNow! are phased out and
> declared obsolesent (and AMD stopps to implement 3DNow!). It's not that
> awful. The worst things from Intel all died.
> The ARM ISA is designed by one person, and even then it is one of the
> more byzantine RISC ISAs, with lots of things cobbled together in one
> instruction - shifts, conditional execution, normal operations.
> --
> Bernd Paysan
> "If you want it done right, you have to do it yourself"http://bernd-paysan.de/
The point is, a *new* standard (as opposed to a revision of an
existing standard) affords opportunities to modernise, or even
revolutionise a language. Some could/would argue that there are some
historical legacies, inherited long ago, that are holding the language
back (that could apply to other languages too, not just Forth).
"Radical" changes, especially where it can break existing
functionality or code are resisted. That's okay. It's not an un-
reasonable desire to want to maintain compatibility where possible.
However, where a particular feature or quirk of a language is seen to
be a restriction (with the benefit of hindsight) I say go ahead and
change it! Don't be afraid! If it breaks functionality, well, that's a
shame, but, if the right decisions were made for the right reasons
then programmers will soon come to appreciate the "new way" once they
get comfortable with it. To me, the argument "No! We can't do that, it
will break all my code" is an invalid, and unreasonable argument. The
previous standard is still there. It hasn't gone away. The previous
standard compliant compilers are still there. If they decide to
upgrade software to be compatible with the new standard, great. If
not, no problem they can continue to use the previous standard. It's
not illegal!
Reading the ANS-94 standard, it seems that many concessions were made
to pre-exisiting compilers and/or vendors. One gets the feeling that
the standard was held back by politics. That's probably inevitable. It
probably isn't a very nice job sitting on a standards committee - it's
probably a rather thankless task. I believe the standard could be
improved just by removing references to 'ambiguous conditions' and
mandating that an error be produced. A valid argument in 1980 might
have been that it takes extra code (and cycles) to detect these
ambiguous conditions. It's not such a relevant argument any more
(that's just one example).
Another example: Improvements can also be made to the handling of
execution tokens. Specifically, a new standard could introduce the
concept of different *types* of execution tokens, to be used at
different times, and in different contexts. We've all seen and
participated in the discussions of obtaining XTs to compile only/
interpret only words etc. This is a good example of where current
Forth compiler technology has begun to out-grow the current standard.
A new standard could enshrine this new paradigm, and crucially,
*mandate* it. Don't make it optional. Remove the word "may". That just
gives implementors an easy way out. It is a political concession to
pre-existing systems. This should not be entertained. "May" just leads
to software that "may" work on a "compliant" system, or "may" not.
What's the point of that?
One area of focus (that would require the input of people far more
experienced than I) would be to look at the types of things that
cannot currently be implemented in a standard-compliant manner. To
revert to carnal knowledge in order to implement something in an
otherwise "compliant" system is to expose an area of the standard that
could be strengthened. Where these shortcomings are indentified, the
ratified solutions should be *mandated* in order to remove the
requirement for carnal knowledge, and improve the chances of user code
running correctly across a broad range of systems. One positive
example of this is the word CELL+ that was introduced in ANS94. It was
introduced as a core word too, which is very good.
I don't really have the "Forth stripes" to be saying all of this -
you'll appreciate that these comments are very much "shouted from the
touchlines", to use a footballing expression.
> That is patently incorrect. Intel never wanted to move on from 32
> to 64 bits in a compatible way. They had the Itanium. (Same situation
> as the 432. )
Yes, if they hadn't messed up Itanium so badly, AMD would never have succeeded.
> Again. The 8086 was designed by one man Stephen Morse. It was
> a clever extension of the 8080 and a reasonable cisc processor,
> but without a shred of thought about future enhancements.
> (I have his book "8086 architecture". It is adamant about a few
> errors and convincing regards design decisions.)
> This processor had three characteristics that where in hindsight
> responsible for the mess we're in. Too CISCy, segmentation, and
> no regards for sufficiently address extensability.
> The pressure to stay compatible was what did it.
> The "real mode" (a real kludge) was absent in 80286 then reinstated
> in the 80386, pressured by mostly Microsoft.
80286 had real mode and protected mode, but to go back from protected mode to real mode, you needed to reset the processor, either by telling the keyboard controller to do so or by causing a triple fault (which is faster, but Microsoft first used the keybord controller hack). 80386 had the VM mode, which is much more useful than going back to real mode.
>>The ARM ISA is designed by one person, and even then it is one of the
>>more byzantine RISC ISAs, with lots of things cobbled together in one
>>instruction - shifts, conditional execution, normal operations.
> Remember the Novix? It has also those bit-fields. They just go
> directly to parts of the processor that do e.g. shifting.
> That is RISC in my book, direct relation to the hardware without
> much regard to the assembler programmer.
I'm not convinced. ARM's critical path contains shifter+ALU, which means the achievable clock rate is significantly slower than competing RISC processors (of that time). The newer ARM cores get higher clock rates by dividing the execution stage into two stages, if necessary.
> Conditional execution in one instruction is a very powerful speed
> up mechanism. At the time Intel's alternative (complicated multiple
> instruction analysis) was not viable.
Conditional execution looks nice, but having every instruction conditional makes out-of-order execution difficult.
ARM64 drops both the integrated shift field and the omnipresent conditional execution - there is still conditional execution, but only for instructions where it makes sense (branch, select).
-- Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
> The point is, a *new* standard (as opposed to a revision of an
> existing standard) affords opportunities to modernise, or even
> revolutionise a language. Some could/would argue that there are some
> historical legacies, inherited long ago, that are holding the language
> back (that could apply to other languages too, not just Forth).
> "Radical" changes, especially where it can break existing
> functionality or code are resisted. That's okay. It's not an un-
> reasonable desire to want to maintain compatibility where possible.
> However, where a particular feature or quirk of a language is seen to
> be a restriction (with the benefit of hindsight) I say go ahead and
> change it! Don't be afraid! If it breaks functionality, well, that's a
> shame, but, if the right decisions were made for the right reasons
> then programmers will soon come to appreciate the "new way" once they
> get comfortable with it. To me, the argument "No! We can't do that, it
> will break all my code" is an invalid, and unreasonable argument. The
> previous standard is still there. It hasn't gone away. The previous
> standard compliant compilers are still there. If they decide to
> upgrade software to be compatible with the new standard, great. If
> not, no problem they can continue to use the previous standard. It's
> not illegal!
When I was arguing my <BUILDS RfD, I introduced what I call the "Asok
Principle." The idea is that if Asok the Intern (from the Dilbert
cartoon) is capable of upgrading an old-standard compliant program to
the new standard, then the changes that the new standard has
introduced are acceptable. In this case, even the dullest Forther
should be able to go through the source-code of any program and change
CREATE into <BUILDS for the cases when there is a DOES>, but leave
CREATE alone when it is used alone. Also, if any mistakes are made,
the compiler will catch the mistake during compilation (a DOES>
following a CREATE is a fatal error, as is a <BUILDS without a DOES>).
This kind of work is what interns are for! Of course, the Forth-200x
committee would have none of it; my RfD was described as a "non-
starter."
> Reading the ANS-94 standard, it seems that many concessions were made
> to pre-exisiting compilers and/or vendors. One gets the feeling that
> the standard was held back by politics. That's probably inevitable. It
> probably isn't a very nice job sitting on a standards committee - it's
> probably a rather thankless task. I believe the standard could be
> improved just by removing references to 'ambiguous conditions' and
> mandating that an error be produced. A valid argument in 1980 might
> have been that it takes extra code (and cycles) to detect these
> ambiguous conditions. It's not such a relevant argument any more
> (that's just one example).
> Another example: Improvements can also be made to the handling of
> execution tokens. Specifically, a new standard could introduce the
> concept of different *types* of execution tokens, to be used at
> different times, and in different contexts. We've all seen and
> participated in the discussions of obtaining XTs to compile only/
> interpret only words etc. This is a good example of where current
> Forth compiler technology has begun to out-grow the current standard.
> A new standard could enshrine this new paradigm, and crucially,
> *mandate* it. Don't make it optional. Remove the word "may". That just
> gives implementors an easy way out. It is a political concession to
> pre-existing systems. This should not be entertained. "May" just leads
> to software that "may" work on a "compliant" system, or "may" not.
> What's the point of that?
> One area of focus (that would require the input of people far more
> experienced than I) would be to look at the types of things that
> cannot currently be implemented in a standard-compliant manner. To
> revert to carnal knowledge in order to implement something in an
> otherwise "compliant" system is to expose an area of the standard that
> could be strengthened. Where these shortcomings are indentified, the
> ratified solutions should be *mandated* in order to remove the
> requirement for carnal knowledge, and improve the chances of user code
> running correctly across a broad range of systems. One positive
> example of this is the word CELL+ that was introduced in ANS94. It was
> introduced as a core word too, which is very good.
> I don't really have the "Forth stripes" to be saying all of this -
> you'll appreciate that these comments are very much "shouted from the
> touchlines", to use a footballing expression.
> Mark
Your TurboForth has more users than Gforth does --- that counts as
"Forth stripes" to me.
You're the only person on comp.lang.forth that ever makes any sense!
Everything that you said here is just common sense, but that is what
the Forth-200x committee fears the most!
