> It is incongruous to see proposals for CONTINUE, CONTINUE2,
> CONTINUE3 coming from folks who campaign against LOCALS|
> for no other reason than the parameter order offends them, or
> who find floats on the data stack so appalling that they ensure
> no-one can use it despite such practice existing since early days.
> Even if one can't believe what one reads on c.l.f., it is entertaining.
So, significant programs have been written in Forth for, as I now count, >40 years with no need for CONTINUE, and now we have CONTINUE3? Ok, so some folks think it's fun to accept a challenge and invent something whether it's needed or not, but I find it hard to get excited about it.
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."
==================================================
> hughaguila...@yahoo.com wrote:
>> ...
>> Anton's CONTINUE2 is the most ridiculous thing I've ever heard of. The programmer is
>> supposed to count on his fingers how many IF or CASE statements are wrapped around his
>> CONTINUE so he knows if he should use CONTINUE, CONTINUE2, CONTINUE3, etc.? I don't know
>> what is going on with that guy --- his ideas these days are really weird, even by
>> comp.lang.forth standards which aren't high.
> It is incongruous to see proposals for CONTINUE, CONTINUE2,
> CONTINUE3 coming from folks who campaign against LOCALS|
> for no other reason than the parameter order offends them, or
> who find floats on the data stack so appalling that they ensure
> no-one can use it despite such practice existing since early days.
> Even if one can't believe what one reads on c.l.f., it is entertaining.
A silly extension might be
: ]CONTINUE ] CS-PICK POSTPONE AGAIN ; IMMEDIATE
Usage:
begin .. [ 0 ]continue ..
.. if [ 1 ]continue then ..
.. if if [ 2 ]continue then then ..
again
Finally, the computer uses the programmer to count on his fingers!
On Friday, August 24, 2012 1:47:04 PM UTC-7, Mark Wills wrote:
> CONTCASE
> ?
Wasn't that the heroine in The Hunger Games?
Seriously, abbreviating words is a bad idea, and pasting words together without benefit of a hyphen is another bad idea --- although that is done in the German language all the time, which is the PERL of human languages.
I don't like CASE at all. You tend to get gigantic functions that do several different things depending upon a code number that is passed into them that they check at run-time --- a complete violation of the Forth principle of having each function be short and do only one thing (remember the "universal processor" in the "Thinking Forth" book?). It is very difficult to test functions like that. Whenever I see programs featuring a big CASE, they are almost always C programs that have been ported to Forth and/or they were written by recalcitrant C programmers (which is pretty much what Anton Ertl is) --- the SWITCH statement is the foundation of C programming, where it is common to see a single SWITCH statement spanning hundreds of lines of source-code.
When I worked at Testra my boss liked to use CASE. He was a hardware designer and he tended to think in terms of state-machines, which is what hardware is all about. This doesn't work very well for software though.
P.S. --- Another thing that recalcitrant C programmers do is ignore compile-time altogether and just treat Forth like C with RPN syntax. Recently Anton Ertl argued against my suggestion that the control-flow stack be separate from the data stack. He said that it is "convenient" to use the data stack for control-flow stuff because nobody ever uses it for passing parameters into colon words at compile-time that will be picked up by LITERAL. It is obvious that he has never written colon words that execute at compile-time and generate other colon words --- but that is the essence of Forth programming! If you are not going to do that, then you might as well just program in C.
> [...] Whenever I see programs featuring a big CASE, they are
> almost always C programs that have been ported to Forth
> and/or they were written by recalcitrant C programmers [...]
> --- the SWITCH statement is the foundation of C programming,
> where it is common to see a single SWITCH statement spanning
> hundreds of lines of source-code.
Well, it's definately not "the foundation" of C programming. Switches are
not as common in C code as other control-flow. However, it's definately
true some C programmers seem to embrace C's switch() much more than they
ever should. I see excessively switched programs from time to time too.
I also see programmers embrace C's for() too much. etc.
FYI, ANSI C89/90 allows 257 and ISO C99 allows 1023 items in a switch.
So, switches were designed to allow easy selection of a relatively "large"
number of items (at the time).
Personally, I think it's far more common to see a switch() with just a
handful of items, followed by maybe 20 to 50 items. From what I've seen,
the truly large switches are used with a large input set of non-contiguous
integer values. If the set of input integer values is contiguous, you don't
need a switch. You can use an array.
The largest switch I have in C has 356 items. Why so many? Well, there are
356 different valid input text strings. The switch is given an integer from
a hash function on the input string. This produces 356 different 32-bit
integers. The integer values are not adjacent to each other. There are no
hash collisions on that set of strings. That makes the switch() ideal.
Otherwise, you're using many if's.
That large switch is relatively recent. Most of mine are much smaller.
What I think is my next largest switch has 100 items. That's still many.
It too is tasked with separating strings from each other. It uses a simple
hash function which has a few collisions that must be corrected.
Another option in C is similar, switch based on the first character of the
string which reduces you to 26 or 52 switch items, but then you need to do a
bunch of string compares using if's, e.g., if you switched on 'r', you still
need to separate "return" from "register". 356/26=14. So, if the strings
were evenly distributed, which they aren't, you'd need an average of 14 if's
per case. Obviously, that means you're likely to see one case with 28 or
similar larger set of strings ... That would encourage using a hash
function in the first place.
The "worst" option in C is to loop through a string array and compare every
string until the one you're looking for is found. I.e., like searching the
dictionary in a simple interpreted Forth. The loop is to equate the string
to a sequential integer index, i.e., one value from a contiguous set of
integer values.
The need to determine one string from another and take action for a specific
string is needed for parsers and interpreters.
How would you handle code selection for 356 different input strings in
Forth?
Elizabeth D. Rather wrote:
> On 8/24/12 7:50 PM, Ed wrote:
> > It is incongruous to see proposals for CONTINUE, CONTINUE2,
> > CONTINUE3 coming from folks who campaign against LOCALS|
> > for no other reason than the parameter order offends them, or
> > who find floats on the data stack so appalling that they ensure
> > no-one can use it despite such practice existing since early days.
> > Even if one can't believe what one reads on c.l.f., it is entertaining.
> So, significant programs have been written in Forth for, as I now count,
> >40 years with no need for CONTINUE, and now we have CONTINUE3? Ok, so
> some folks think it's fun to accept a challenge and invent something
> whether it's needed or not, but I find it hard to get excited about it.
That may be but ANS let the conditionals cat out of the bag long ago.
Had ANS *not* accepted Wil Baden's proposition that Forth needed
a GOTO there might be no CS-PICK CS-ROLL or separate CFS.
But it did. And far from discouraging users, ANS suggested several
new conditionals based on the new words!
ANS wasn't at all adverse to adding conditionals to Forth. It provided
the Eaker CASE despite the known limitations. Others augmented
it with BEGINCASE NEXTCASE ?OF etc. Nor will these be the last.
A better way is to provide the tools and let users define whatever
conditionals they believe they need.
hughaguila...@yahoo.com wrote:
> ...
> First Anton Ertl says that
> people don't put data on the stack during compilation
Classically the data stack has been used to pass conditionals
information.
Conditionals occur frequently during compilation and their number
is indeterminate. The data stack is ideal for that. For the few
occasions other data must be passed, variables have sufficed
e.g. RECURSE gets what it needs from variable LAST.
Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andre...@littlepinkcloud.invalid> writes:
>>Rod Pemberton <do_not_h...@notemailnot.cmm> wrote:
>>> How would you handle code selection for 356 different input strings in
>>> Forth?
>>If you want an exact string match followed by an action, FIND and
>>EXECUTE is probably a good choice.
> SEARCH-WORDLIST is a better choice than FIND: No need to worry about
> additional words in other wordlists.
True enough, but it makes no difference to the core point about Forth
design: use the tools that are already there. I've seen programs that
re-invent the dictionary, which shows this advice is not obvious!
> Gerry Jackson <ge...@jackson9000.fsnet.co.uk> writes:
>> On 22/08/2012 15:26, Anton Ertl wrote:
>>> BTW, the next version of Gforth will have a cute feature that's
>>> relevant in that context: It extends CASE to be a general control flow
>>> construct that can also loop in various ways:
>>> case
>>> ... ?of ... endof \ continues after ENDCASE/NEXTCASE
>>> ... ?of ... contof \ continues at CASE
>>> ... ?of ... endof \ continues after ENDCASE/NEXTCASE
>>> ...
>>> nextcase \ loop back to CASE
>> I like the idea, similar to an IT ... TI discussed in c.l.f archives but
>> merged into the existing CASE structure.
>> Will NEXTCASE have the run-time stack effect (x -- ) like ENDCASE and
>> VFX Forth's NEXTCASE
> Yes, it has ( x -- ) to be compatible with VFX. Probably not that
> sensible when used with ?OF (which will usually be the case when using
> NEXTCASE).
>> or will it be ( -- ) like VFX Forth's NEXT-CASE
> Maybe we should provide NEXT-CASE *instead of* NEXTCASE.
>> Presumably ?OF run-time will be ( f -- )
> Yes.
>> Isn't there a better name than CONTOF e.g. REPEATCASE or even CONTINUE
> As usual, everyone will have their own idea for a better name; If you
> reach consensus on a good name, I'll happily adopt it. The reason for
> CONTOF is: The OF part indicates that this ends an OF (like ENDOF).
> The CONT part indicates that we continue at the start (like C's
> continue).
To experiment with your extended CASE I have implemented it in ANS Forth, the code with tests is below. All CASE words have to be rewritten because the new CASE has to leave a dest on the control flow stack (CFS). It is a modified version of the code in section A.3.2.2.2 of the ANS Forth standard. It is quite straightforward, words have to deal with the extra dest on the CFS. The only messy bit is how ENDCASE handles that extra dest as ANS Forth doesn't have a CS-DROP. The only way I could think of was to compile a jump back to the dest but hide it by placing a forward jump in front of it to skip over it, which is inefficient. Perhaps optimising compilers will detect this dead code.
I've kept to the name CONTOF but still don't like it, I'm not very keen on NEXTCASE either. I've introduced ?BREAK to avoid the empty ?OF ENDOF which simply exits the CASE structure.
The tests work on GForth, VFX Forth, SwiftForth, Win32 Forth and BigForth but fails with a 'structure not balanced' error on iForth 4.0.380
-------------------------------------------------------
: case ( -- dest 0 ) postpone begin 0 ; immediate
\ ?break is equivalent to an empty ?OF ENDOF
: ?break ( dest #of -- orig dest #of+1 ) \ run-time ( f -- )
>r postpone 0= postpone if cs-swap r> 1+
; immediate
: contof ( orig dest #of -> dest #of-1 ) \ run-time ( -- )
>r
0 cs-pick postpone again cs-swap postpone then
r> 1-
; immediate
: resolve-origs ( orig1 ... orign n -- )
0 ?do postpone then loop
;
: endcase ( orig1 ... orign dest #of -- ) \ run-time ( x -- )
>r postpone drop postpone ahead cs-swap postpone again
r> 1+ resolve-origs
; immediate
: nextcase ( orig1 ... orign dest #of -- ) \ run-time ( x -- )
>r postpone drop postpone again r> resolve-origs
; immediate
\ Tests require the Hayes tester or derivatives of it
testing CASE OF ENDOF ENDCASE
t{ : cs1 case 1 of 111 endof
2 of 222 endof
3 of 333 endof
>r 999 r>
endcase
; -> }t
t{ : cs2 >r case -1 of case r@ 1 of 100 endof
2 of 200 endof
>r -300 r>
endcase
endof
-2 of case r@ 1 of -99 endof
>r -199 r>
endcase
endof
>r 299 r>
endcase r> drop
; -> }t
Gerry Jackson <ge...@jackson9000.fsnet.co.uk> writes Re: continue equivalent in Forth?
> On 24/08/2012 17:50, Anton Ertl wrote:
>> Gerry Jackson <ge...@jackson9000.fsnet.co.uk> writes:
>>> On 22/08/2012 15:26, Anton Ertl wrote:
[..]
> The tests work on GForth, VFX Forth, SwiftForth, Win32 Forth and > BigForth but fails with a 'structure not balanced' error on iForth 4.0.380
[..]
With the following extra lines at the top of gerry.frt:
-----
ANEW -gerry
NEEDS -ttester
SECURE OFF VERBOSE ON
----
... we can do
FORTH> in c:/idfwforth/examples/internet/idata/gerry
Creating --- John Hopkins TESTER Version 2.00 ---
Redefining case
Redefining of
Redefining endof
Redefining endcase testing CASE OF ENDOF ENDCASE
testing ?of
testing nextcase
testing contof
testing ?break
> Gerry Jackson <ge...@jackson9000.fsnet.co.uk> writes Re: continue equivalent in Forth?
>> On 24/08/2012 17:50, Anton Ertl wrote:
>>> Gerry Jackson <ge...@jackson9000.fsnet.co.uk> writes:
>>>> On 22/08/2012 15:26, Anton Ertl wrote:
> [..]
>> The tests work on GForth, VFX Forth, SwiftForth, Win32 Forth and
>> BigForth but fails with a 'structure not balanced' error on iForth 4.0.380
> [..]
> With the following extra lines at the top of gerry.frt:
> -----
> ANEW -gerry
> NEEDS -ttester
> SECURE OFF VERBOSE ON
> ----
> .... we can do
> FORTH> in c:/idfwforth/examples/internet/idata/gerry
> Creating --- John Hopkins TESTER Version 2.00 ---
> Redefining case
> Redefining of
> Redefining endof
> Redefining endcase
> testing CASE OF ENDOF ENDCASE
> testing ?of
> testing nextcase
> testing contof
> testing ?break
> I don't recommend turning of SECURE .
That's interesting, I now see that is mentioned in the manual. Why is this necessary for iForth but not for other ANS Forth systems? Only origs and a dest are on the CFS when CS-PICK and CS-ROLL are used so ISTM that SECURE on makes iForth non-compliant with ANS Forth when manipulating the control flow stack.
Gerry Jackson <ge...@jackson9000.fsnet.co.uk> writes Re: continue equivalent in Forth?
> On 27/08/2012 17:14, Marcel Hendrix wrote:
>> Gerry Jackson <ge...@jackson9000.fsnet.co.uk> writes Re: continue equivalent in Forth?
[..]
> I don't recommend turning off SECURE .
[..]
> That's interesting, I now see that is mentioned in the manual. Why is > this necessary for iForth but not for other ANS Forth systems? Only > origs and a dest are on the CFS when CS-PICK and CS-ROLL are used so > ISTM that SECURE on makes iForth non-compliant with ANS Forth when > manipulating the control flow stack.
[..]
Well, it is (obviously) not necessary for iForth to have SECURE on. The
reason SECURE is on is painful memories of trying to compile large NOVIX block files.
The SECURE feature can be permanently turned off by editing the
iforth.prf file.
Why don't other Forths have SECURE? They may have a fail-safe mechanism to catch silly errors that does not interfere with their CS-PICK etc.
But ...
-- -------------------------------
VFX Forth for Windows IA32
MicroProcessor Engineering Ltd, 1998-2012
Version: 4.50 [build 3327]
Build date: 17 April 2012
Free dictionary = 7561806 bytes [7384kb]
: test begin 1 2 + else 3 then ; ok
-- --------------------------------------
-- ----------------------------------------------------
SwiftForth i386-Win32 3.2.2 08-Jul-2010
base @ hex : testing again 10 20 + begin ; decimal ok
-- ----------------------------------------------------
... apparently passes unnoticed.
(gForth can't be caught that easily.)
Another reason for iForth's SECURE is that the compiler uses extra items on the CS stack to remember when registers should be spilled/loaded to/from the stacks for control flow nodes.
Yet another reason is the somewhat complicated parallel programming structures.
These extra CS items can be used to give better messages, but as that is not ANS compatible, there must be a way to turn them off.
I am not claiming that having extra items on the CS stack is the only
way to get the mentioned features.
> Gerry Jackson <ge...@jackson9000.fsnet.co.uk> writes Re: continue equivalent in Forth?
>> On 27/08/2012 17:14, Marcel Hendrix wrote:
>>> Gerry Jackson <ge...@jackson9000.fsnet.co.uk> writes Re: continue equivalent in Forth?
> [..]
>> I don't recommend turning off SECURE .
> [..]
>> That's interesting, I now see that is mentioned in the manual. Why is
>> this necessary for iForth but not for other ANS Forth systems? Only
>> origs and a dest are on the CFS when CS-PICK and CS-ROLL are used so
>> ISTM that SECURE on makes iForth non-compliant with ANS Forth when
>> manipulating the control flow stack.
> [..]
> Why don't other Forths have SECURE? They may have a fail-safe mechanism
> to catch silly errors that does not interfere with their CS-PICK etc.
> : test begin 1 2 + else 3 then ; ok
> -- --------------------------------------
> -- ----------------------------------------------------
> SwiftForth i386-Win32 3.2.2 08-Jul-2010
> base @ hex : testing again 10 20 + begin ; decimal ok
> -- ----------------------------------------------------
> .... apparently passes unnoticed.
> (gForth can't be caught that easily.)
Heh, even my system rejects rubbish like that, still I don't suppose those systems often encounter code like that.
> Another reason for iForth's SECURE is that the compiler uses
> extra items on the CS stack to remember when registers should
> be spilled/loaded to/from the stacks for control flow nodes.
> Yet another reason is the somewhat complicated parallel
> programming structures.
> These extra CS items can be used to give better messages, but as
> that is not ANS compatible, there must be a way to turn them off.
Thanks for that, I assumed there must be good reasons and I was interested to know what they were.
> : test begin 1 2 + else 3 then ; ok
> -- --------------------------------------
> -- ----------------------------------------------------
> SwiftForth i386-Win32 3.2.2 08-Jul-2010
> base @ hex : testing again 10 20 + begin ; decimal ok
> -- ----------------------------------------------------
> ... apparently passes unnoticed.
Hmmm:
SwiftForth i386-Mac OS X 3.4.2 11-Feb-2012
: test begin 1 2 + else 3 then ; Control structure mismatch
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."
==================================================
> Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> > Andrew Haley <andre...@littlepinkcloud.invalid> writes:
> >>Rod Pemberton <do_not_h...@notemailnot.cmm> wrote:
> >>> How would you handle code selection for 356 different input strings in
> >>> Forth?
> >>If you want an exact string match followed by an action, FIND and
> >>EXECUTE is probably a good choice.
> > SEARCH-WORDLIST is a better choice than FIND: No need to worry about
> > additional words in other wordlists.
> True enough, but it makes no difference to the core point about Forth
> design: use the tools that are already there. I've seen programs that
> re-invent the dictionary, which shows this advice is not obvious!
> Andrew.
My ASSOCIATION in the novice package does pretty much the same thing
that the dictionary does. The advantage is that allows you to do an in-
order traversal of the nodes within a particular region. If the
ordering of your data isn't important though, then you don't need this
feature so you might as well use the dictionary. Another advantage of
ASSOCIATION is that it can use key data other than strings, such as
floats for example --- once again, if you are just using strings, then
the dictionary should work. Another advantage of ASSOCIATION is that
it can be used in cross-compiled code in which the dictionary is not
available at run-time.
I've used the dictionary as an associative array myself in the past
--- in my 65c02 source-level debugger for example.
m...@iae.nl (Marcel Hendrix) writes:
>Why don't other Forths have SECURE?
What does SECURE do? Why should we have it?
>: test begin 1 2 + else 3 then ; ok
...
>(gForth can't be caught that easily.)
: test begin 1 2 + else 3 then ; :1: expected orig : test begin 1 2 + >>>else<<< 3 then ;
So Gforth usually notices when it does not get an orig, but something
else, and likewise it will complain if you pass it an orig while it
expects a dest. And every Forth-94 system is allowed to do this kind
of checking, as well as checking for unbalanced control flow stack,
e.g.:
: foo if ; :2: unstructured : foo if >>>;<<<
What does SECURE add? Is it worth the price of not being able to run
standard programs like Josh Grams implementation of CASE etc.?
>Another reason for iForth's SECURE is that the compiler uses >extra items on the CS stack to remember when registers should >be spilled/loaded to/from the stacks for control flow nodes.
Gforth uses larger CS items to remember which locals are alive at a
branch (orig) or branch target (dest); can be done nicely in a
Forth-94 compatible way, and I guess that's also true for your
register information. What do you do if SECURE is OFF?
>These extra CS items can be used to give better messages, but as >that is not ANS compatible, there must be a way to turn them off.
Yes the error messages of Gforth could be better, e.g., the first one
could be "control structure mismatch, expected orig".
an...@mips.complang.tuwien.ac.at (Anton Ertl) writes Re: continue equivalent in Forth?
> m...@iae.nl (Marcel Hendrix) writes:
>>Why don't other Forths have SECURE?
> What does SECURE do? Why should we have it?
[..]
> : foo if ; > :2: unstructured > : foo if >>>;<<<
[..]
Why is gForth complaining?
IF C CORE
Compilation: ( -- orig )
Put the location of a new unresolved forward reference orig onto the
control flow stack. Append the execution semantics given below to the
current definition. The semantics are incomplete until orig is resolved
(e.g., by THEN ).
Execution: ( x -- )
If all bits of x are zero, continue execution at the location specified
by the resolution of orig.
See also: ELSE THEN
I see nothing here that allows an error message.
iForth:
FORTH> secure off ok
FORTH> : test if ; ok
[3]FORTH>
