Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #27720 > unrolled thread

Hayes tester fails

Back to article view | Back to comp.lang.forth

Contents

  Hayes tester fails "Ed" <invalid@invalid.com> - 2014-01-08 02:20 +1100
    Re: Hayes tester fails "Alex McDonald" <blog@rivadpm.com> - 2014-01-07 21:15 +0000
    Re: Hayes tester fails "Alex McDonald" <blog@rivadpm.com> - 2014-01-07 21:20 +0000
    Re: Hayes tester fails anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-08 14:58 +0000
      Re: Hayes tester fails "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-08 19:53 -0500
      Re: Hayes tester fails "Ed" <invalid@invalid.com> - 2014-01-09 21:49 +1100
        Re: Hayes tester fails anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-09 12:57 +0000
          Re: Hayes tester fails "Ed" <invalid@invalid.com> - 2014-01-11 16:06 +1100
            Re: Hayes tester fails "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-11 10:28 -0500
            Re: Hayes tester fails anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-13 16:18 +0000
              Re: Hayes tester fails "Ed" <invalid@invalid.com> - 2014-01-15 10:29 +1100
                Re: Hayes tester fails "Alex McDonald" <blog@rivadpm.com> - 2014-01-15 00:00 +0000
                  Re: Hayes tester fails AKK <akk@nospam.org> - 2014-01-15 02:06 +0100
                  Re: Hayes tester fails "Ed" <invalid@invalid.com> - 2014-01-19 01:33 +1100
                    Re: Hayes tester fails anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-18 16:58 +0000
                      Re: Hayes tester fails "Ed" <invalid@invalid.com> - 2014-01-21 00:09 +1100
                        Re: Hayes tester fails "Alex McDonald" <blog@rivadpm.com> - 2014-01-20 14:36 +0000
                          Re: Hayes tester fails "Ed" <invalid@invalid.com> - 2014-01-25 22:53 +1100
                            Re: Hayes tester fails "Alex McDonald" <blog@rivadpm.com> - 2014-01-25 23:21 +0000
                        Re: Hayes tester fails anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-21 14:50 +0000
                Re: Hayes tester fails "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-15 02:40 -0500
                  Re: Hayes tester fails "Elizabeth D. Rather" <erather@forth.com> - 2014-01-14 21:52 -1000
                  Re: Hayes tester fails "Ed" <invalid@invalid.com> - 2014-01-19 00:10 +1100
                Re: Hayes tester fails Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-15 03:28 -0600
        Re: Hayes tester fails "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-11 10:30 -0500
          Re: Hayes tester fails "Ed" <invalid@invalid.com> - 2014-01-13 10:45 +1100
    Re: Hayes tester fails Howerd <howerdo@yahoo.co.uk> - 2014-01-09 02:51 -0800
      Re: Hayes tester fails "Ed" <invalid@invalid.com> - 2014-01-09 22:12 +1100
        Re: Hayes tester fails Howerd <howerdo@yahoo.co.uk> - 2014-01-09 06:44 -0800
          Re: Hayes tester fails "Ed" <invalid@invalid.com> - 2014-01-11 16:14 +1100
            Re: Hayes tester fails Howerd <howerdo@yahoo.co.uk> - 2014-01-11 02:35 -0800
            Re: Hayes tester fails Coos Haak <chforth@hccnet.nl> - 2014-01-11 13:46 +0100
              Re: Hayes tester fails "Ed" <invalid@invalid.com> - 2014-01-13 11:16 +1100

Page 1 of 2  [1] 2  Next page →

#27720 — Hayes tester fails

-24. 33 FM/MOD . . -1 9  ok

Now try this buggy definition found in a Forth implementation:

: FM/MOD ( d1 n1 -- n2 n3 )
  DUP >R
  SM/REM
  OVER 0<> OVER 0< AND IF
    SWAP R> + SWAP
    1-
  ELSE R> DROP THEN ;

-24. 33 FM/MOD . . 0 -24  ok

Notice the negative modulus.  That should never happen in floored
division when the divisor is positive.

Put the buggy routine through the Hayes tester and watch it pass.

[toc] | [next] | [standalone]

#27726

on 07/01/2014 15:20:44, "Ed" wrote:
> -24. 33 FM/MOD . . -1 9  ok
> 
> Now try this buggy definition found in a Forth implementation:
> 
>: FM/MOD ( d1 n1 -- n2 n3 )
> DUP >R
> SM/REM
> OVER 0<> OVER 0< AND IF
> SWAP R> + SWAP
> 1-
> ELSE R> DROP THEN ;
> 
> -24. 33 FM/MOD . . 0 -24  ok
> 
> Notice the negative modulus.  That should never happen in floored
> division when the divisor is positive.
> 
> Put the buggy routine through the Hayes tester and watch it pass.
> 
> 
> 
> 
> 

Can you provide (a) the Forth system and (b) the test you believe it
should have failed?

http://soton.mpeforth.com/flag/anstests/ says "25 April 2012. Some
provisional floating point wordset tests have been added.

Floating Point Tests

Some floating point test programs from various sources have been
collected together and made available in this download. These tests are
unproven and provided in the hope that implementers of ANS Forth/Forth
200X systems will try them and report back on any perceived deficiencies
which can then be resolved. When they are generally agreed to be correct
they can be incorporated into the above set of test programs. For more
details see the file readme.txt in the download."

The tests in the zip file are:

1. ak-fp-test.fth by A.K. (full name unknown) with some system
   dependent tests removed.
2. fatan2-test.fs by David N Williams
3. ieee-arith-test.fs by David N Williams
4. ieee-fprox-test.fs by David N Williams
5. fpzero-test.4th by Krishna Myneni
6. fpio-test.4th by Krishna Myneni
7. to-float-test.4th by Krishna Myneni
8. paranoia.4th converted by Krishna Myneni (see the file for
   the original source)

[toc] | [prev] | [next] | [standalone]

#27727

on 07/01/2014 15:20:44, "Ed" wrote:
> -24. 33 FM/MOD . . -1 9  ok
> 
> Now try this buggy definition found in a Forth implementation:
> 
>: FM/MOD ( d1 n1 -- n2 n3 )
> DUP >R
> SM/REM
> OVER 0<> OVER 0< AND IF
> SWAP R> + SWAP
> 1-
> ELSE R> DROP THEN ;
> 
> -24. 33 FM/MOD . . 0 -24  ok
> 
> Notice the negative modulus.  That should never happen in floored
> division when the divisor is positive.
> 
> Put the buggy routine through the Hayes tester and watch it pass.
> 
> 
> 
> 
> 

(correction if you see my previous post, which I've deleted from Google
Groups)

Can you provide (a) the Forth system and (b) the test you believe it
should have failed?

[toc] | [prev] | [next] | [standalone]

#27733

"Ed" <invalid@invalid.com> writes:
>Put the buggy routine through the Hayes tester and watch it pass.

Most people already know this, but just in case you don't:

"Program testing can be used to show the presence of bugs, but never
to show their absence!"

http://en.wikiquote.org/wiki/Edsger_W._Dijkstra

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

[toc] | [prev] | [next] | [standalone]

#27745

On Wed, 08 Jan 2014 09:58:03 -0500, Anton Ertl  
<anton@mips.complang.tuwien.ac.at> wrote:
> "Ed" <invalid@invalid.com> writes:

>> Put the buggy routine through the Hayes tester and watch it pass.
>
> Most people already know this, but just in case you don't:
>
> "Program testing can be used to show the presence of bugs, but never
> to show their absence!"
>
> http://en.wikiquote.org/wiki/Edsger_W._Dijkstra
>

I like that guy's theories.

Yes, if a bug is absent, it's clearly not present, so testing
for the presence of the bug won't find that the bug is present,
since it clearly hasn't arrived yet.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#27757

Anton Ertl wrote:
> "Ed" <invalid@invalid.com> writes:
> >Put the buggy routine through the Hayes tester and watch it pass.
>
> Most people already know this, but just in case you don't:
>
> "Program testing can be used to show the presence of bugs, but never
> to show their absence!"

Yet 200x supports, if not requires, such testing and specifies the Hayes tester
be used to do it.

    Forth 2012 RC2:

    Proposals Process
    [..]
    Testing:
    This should test the feature/words you propose, in particular, it should test
    boundary conditions.  Where possible test cases should be written to conform
    with John Hayes tester.f test harness."

Clearly the 200x TC believes such testing is meaningful.

I recall reading suggestions the Hayes tester be included in the 200x document.
I spoke against it.

It is my observation Forthers place too much faith in the Hayes tester.  Vendors
include the Hayes tests in their distributions, presumably to support the claim
their system is Standard compliant.  As does Gforth.

It is a pity Hayes didn't include a big fat disclaimer.  None appear in any copy of
the tests I've seen.  Nor do I recall any system provider adding *their* disclaimer
to the Hayes tests.

I make no apology for posting cases wherein the Hayes tester fails.  If it discourages
reliance on the tester and its use as "proof" that systems are Standard compliant,
it can only be a good thing.

[toc] | [prev] | [next] | [standalone]

#27760

"Ed" <invalid@invalid.com> writes:
>Anton Ertl wrote:
>> "Ed" <invalid@invalid.com> writes:
>> >Put the buggy routine through the Hayes tester and watch it pass.
>>
>> Most people already know this, but just in case you don't:
>>
>> "Program testing can be used to show the presence of bugs, but never
>> to show their absence!"
>
>Yet 200x supports, if not requires, such testing and specifies the Hayes tester
>be used to do it.
>
>    Forth 2012 RC2:
>
>    Proposals Process
>    [..]
>    Testing:
>    This should test the feature/words you propose, in particular, it should test
>    boundary conditions.  Where possible test cases should be written to conform
>    with John Hayes tester.f test harness."
>
>Clearly the 200x TC believes such testing is meaningful.

Yes, testing is meaningful and useful, even if it does not prove the
absence of bugs.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

[toc] | [prev] | [next] | [standalone]

#27788

Anton Ertl wrote:
> "Ed" <invalid@invalid.com> writes:
> >Anton Ertl wrote:
> >> "Ed" <invalid@invalid.com> writes:
> >> >Put the buggy routine through the Hayes tester and watch it pass.
> >>
> >> Most people already know this, but just in case you don't:
> >>
> >> "Program testing can be used to show the presence of bugs, but never
> >> to show their absence!"
> >
> >Yet 200x supports, if not requires, such testing and specifies the Hayes tester
> >be used to do it.
> >
> >    Forth 2012 RC2:
> >
> >    Proposals Process
> >    [..]
> >    Testing:
> >    This should test the feature/words you propose, in particular, it should test
> >    boundary conditions.  Where possible test cases should be written to conform
> >    with John Hayes tester.f test harness."
> >
> >Clearly the 200x TC believes such testing is meaningful.
>
> Yes, testing is meaningful and useful, even if it does not prove the
> absence of bugs.

What does the 200x TC hope to derive from tests written in Hayes format
which will obviously show a positive outcome?  The only rationale I can
imagine is that it wants to add the tests to the Hayes suite.  What message
would that send?

[toc] | [prev] | [next] | [standalone]

#27811

On Sat, 11 Jan 2014 00:06:14 -0500, Ed <invalid@invalid.com> wrote:

> What does the 200x TC hope to derive from tests written in Hayes format
> [...]

Anyway, it would be useful to know which tests are in the Hayes suite and
which are only in 200x if some were added.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#27870

"Ed" <invalid@invalid.com> writes:
>Anton Ertl wrote:
>> "Ed" <invalid@invalid.com> writes:
>> >    Forth 2012 RC2:
>> >
>> >    Proposals Process
>> >    [..]
>> >    Testing:
>> >    This should test the feature/words you propose, in particular, it should test
>> >    boundary conditions.  Where possible test cases should be written to conform
>> >    with John Hayes tester.f test harness."
>> >
>> >Clearly the 200x TC believes such testing is meaningful.
>>
>> Yes, testing is meaningful and useful, even if it does not prove the
>> absence of bugs.
>
>What does the 200x TC hope to derive from tests written in Hayes format

The Hayes tester is quite useful for writting tests of Forth words in
many cases.  The test cases are easier to read than tests written
without a framework (important for the intended purpose, see below),
and the framework gives useful output when a test fails.

The reason why I wanted test cases in proposals where possible is that
proposals written in natural language (as is done in the Forth200x
process) is not very precise.  So test cases in Forth are a way of
formally specifying a part of what is intended.  Coding test cases,
especially for boundary cases would help clarify the specification and
maybe also make the proponent write more precise text.

Tests may also help implementors to find bugs in their implementation
of the proposal.

Unfortunately, some proposals came without tests, which required extra
rounds in making the text more precise.  Maybe we should have insisted
on the tests.

>which will obviously show a positive outcome?

What do you mean by that?

>The only rationale I can
>imagine is that it wants to add the tests to the Hayes suite.  What message
>would that send?

Sounds like a rethorical question.  So what's your answer?

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

[toc] | [prev] | [next] | [standalone]

#27902

Anton Ertl wrote:
> "Ed" <invalid@invalid.com> writes:
> > ...
> >What does the 200x TC hope to derive from tests written in Hayes format
> ...
> The reason why I wanted test cases in proposals where possible is that
> proposals written in natural language (as is done in the Forth200x
> process) is not very precise.

Sometimes that's a good thing.  Faced with a poorly concieved and expressed
function it may be possible to re-interpret it in a more positive light.  Tests
kill off that option.

> ...
> >which will obviously show a positive outcome?
>
> What do you mean by that?

What is says.  You ask proposers to supply the tests and the cases to be tested
and you are expecting something other than a successful result?  This is no test
but a fait accompli.

> >The only rationale I can
> >imagine is that it wants to add the tests to the Hayes suite.  What message
> >would that send?
>
> Sounds like a rethorical question.  So what's your answer?

Based on what you have said the message from 200x is that tests are the way to
go and users can rely on them.  In supplying tests, 200x changes from a language
standard to an implementation standard.

[toc] | [prev] | [next] | [standalone]

#27903

on 14/01/2014 23:29:28, "Ed" wrote:
> Anton Ertl wrote:
>> "Ed" <invalid@invalid.com> writes:
>> > ...
>> >What does the 200x TC hope to derive from tests written in Hayes format
>> ...
>> The reason why I wanted test cases in proposals where possible is that
>> proposals written in natural language (as is done in the Forth200x
>> process) is not very precise.

Marker. See below...

> 
> Sometimes that's a good thing. Faced with a poorly concieved and
> expressed function it may be possible to re-interpret it in a more
> positive light. Tests kill off that option.
> 
>> ...
>> >which will obviously show a positive outcome?
>>
>> What do you mean by that?
> 
> What is says. You ask proposers to supply the tests and the cases to
> be tested and you are expecting something other than a successful
> result? This is no test but a fait accompli.
> 
>> >The only rationale I can
>> >imagine is that it wants to add the tests to the Hayes suite.  What message
>> >would that send?
>>
>> Sounds like a rethorical question.  So what's your answer?
> 
> Based on what you have said the message from 200x is that tests are
> the way to go and users can rely on them. In supplying tests, 200x
> changes from a language standard to an implementation standard.
> 
> 
> 

There are non normative parts to many (I'd reckon on most) standards, and
language standards are not excluded from having them; nor do such non
normative statements make them implementation standards. In fact, ANS
Forth and the Forth200x update have many ambiguous conditions for
implementors to implement as they see fit, from cell size to error
handling and more.

As to tests, having them doesn't imply that "tests kills off that option
[of imprecision]". Normative statements are rarely 100% precise, so it's
helpful if non normative statements illustrate intent. (And precision is
to be welcomed in a standard; why you might want an imprecise
specification is a bit mystifying.)

I would agree however that contrary to Anton's statement above that I've
marked, making (or assuming that) these tests are normative runs contrary
to what most people would expect. 

[toc] | [prev] | [next] | [standalone]

#27905

Am 15.01.2014 01:00, schrieb Alex McDonald:
> There are non normative parts to many (I'd reckon on most) standards, and
> language standards are not excluded from having them; nor do such non
> normative statements make them implementation standards. In fact, ANS
> Forth and the Forth200x update have many ambiguous conditions for
> implementors to implement as they see fit, from cell size to error
> handling and more.
>
> As to tests, having them doesn't imply that "tests kills off that option
> [of imprecision]". Normative statements are rarely 100% precise, so it's
> helpful if non normative statements illustrate intent. (And precision is
> to be welcomed in a standard; why you might want an imprecise
> specification is a bit mystifying.)
>
> I would agree however that contrary to Anton's statement above that I've
> marked, making (or assuming that) these tests are normative runs contrary
> to what most people would expect.
>


FWIW the Scheme "standard" (RxRS) is full of code snippets and expected 
results from given inputs. So it more or less includes a test suite, 
albeit without calling it so.

[toc] | [prev] | [next] | [standalone]

#27932

Alex McDonald wrote:
> ...
> There are non normative parts to many (I'd reckon on most) standards, and
> language standards are not excluded from having them; nor do such non
> normative statements make them implementation standards. In fact, ANS
> Forth and the Forth200x update have many ambiguous conditions for
> implementors to implement as they see fit, from cell size to error
> handling and more.

Those things are fully specified in the text, including the 'ambiguous conditions'.
No problem there.  Problems arise when one adds a second authority which
competes with the text e.g. sample code or tests.  When the sample code
differs from the text, which has precedence?  The same issue with tests.

ANS was careful to include its sample code in the Rationale - an informal
non-binding section containing information supplied in good faith but without
guarantee.  If anyone were to find a bug or feature in one of the ANS code
samples they would not be able to claim it was 'standard'.

[toc] | [prev] | [next] | [standalone]

#27934

"Ed" <invalid@invalid.com> writes:
>Problems arise when one adds a second authority which
>competes with the text e.g. sample code or tests.  When the sample code
>differs from the text, which has precedence?  The same issue with tests.

For Forth200x we discussed the question and decided that the text has
precedence.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

[toc] | [prev] | [next] | [standalone]

#27975

Anton Ertl wrote:
> "Ed" <invalid@invalid.com> writes:
> >Problems arise when one adds a second authority which
> >competes with the text e.g. sample code or tests.  When the sample code
> >differs from the text, which has precedence?  The same issue with tests.
>
> For Forth200x we discussed the question and decided that the text has
> precedence.

So it is possible to get the text right without resorting to tests which
might prove a liability.  That was the view of '94 and the standards that
preceded it.

[toc] | [prev] | [next] | [standalone]

#27976

on 20/01/2014 13:09:24, "Ed" wrote:
> Anton Ertl wrote:
>> "Ed" <invalid@invalid.com> writes:
>> >Problems arise when one adds a second authority which
>> >competes with the text e.g. sample code or tests.  When the sample code
>> >differs from the text, which has precedence?  The same issue with tests.
>>
>> For Forth200x we discussed the question and decided that the text has
>> precedence.
> 
> So it is possible to get the text right without resorting to tests
> which might prove a liability. That was the view of '94 and the
> standards that preceded it.
> 

As you so admirably demonstrate, interpreting what can appear to be a
clear and unambiguous statement is fraught with difficulty.

Anton says; if there is text (what other standards call normative text)
and tests (or non-normative text) and the two disagree, then the
normative text takes precedence.

Your interpretation -- that its is possible to get the text right all the
time and every time, as in '94 and preceding standards -- is much like a
non-normative statement that disagrees with its normative. We can safely
ignore it.

[toc] | [prev] | [next] | [standalone]

#28087

Alex McDonald wrote:
> ...
> Anton says; if there is text (what other standards call normative text)
> and tests (or non-normative text) and the two disagree, then the
> normative text takes precedence.

    Anton Ertl wrote:
    > ...
    > The reason why I wanted test cases in proposals where possible is that
    > proposals written in natural language (as is done in the Forth200x
    > process) is not very precise.  So test cases in Forth are a way of
    > formally specifying a part of what is intended.

It states tests in 200x are formally part of the specification because natural
language is inadequate.  We are informed it has to do with infinite monkey
theorem.

Never mind that a test can never be a specification (a test is a tool created from
an existing well-defined specification).

What it's really about, is a guy who got caught out using tests in a Standard while
attempting to ridicule others' use of tests - and getting himself deeper in shit.
I wouldn't be caught dead defending him, but if that suits your agenda, feel free
to bury yourself in the same hole.

[toc] | [prev] | [next] | [standalone]

#28097

on 25/01/2014 11:53:31, "Ed" wrote:
> Alex McDonald wrote:
>> ...
>> Anton says; if there is text (what other standards call normative text)
>> and tests (or non-normative text) and the two disagree, then the
>> normative text takes precedence.
> 
> Anton Ertl wrote:
> > ...
> > The reason why I wanted test cases in proposals where possible is
> that > proposals written in natural language (as is done in the
> Forth200x > process) is not very precise. So test cases in Forth are a
> way of > formally specifying a part of what is intended.
> 
> It states tests in 200x are formally part of the specification because
> natural language is inadequate. We are informed it has to do with
> infinite monkey theorem.

I don't follow you here, since you have provided quotes snipped from
other posts.

I would state quite clearly; tests may or may not be normative. The
latest version of the standard states;

1.3.2 Annexes
The annexes do not contain any required material.
..
Annex F presents a test suite to test the operation of a system complies
with the definitions documented in this standard.

This places the tests in Annex F in the category of non-normative.

> 
> Never mind that a test can never be a specification (a test is a tool
> created from an existing well-defined specification).

Here you're just flat out wrong. I'm on several standards bodies, and
none of them hobbles themselves in that way. For instance, see Scheme
(http://www.r6rs.org/) or CDMI
(http://snia.org/sites/default/files/CDMI%20v1.0.2.pdf) where examples
are normative parts of the specification.

> 
> What it's really about, is a guy who got caught out using tests in a
> Standard while attempting to ridicule others' use of tests - and
> getting himself deeper in shit. I wouldn't be caught dead defending
> him, but if that suits your agenda, feel free to bury yourself in the
> same hole.

It could be a reasoned discussion, but you have to make an effort.

What it's really about is that the tests haven't AFAIK been proposed and
agreed as normative. There will be compliant systems that won't be able
to run them at all, since (a) the standard doesn't require it and (b) the
tester requires optional parts of the specification such as [IF] et al
from the TOOLS EXT wordset.

[toc] | [prev] | [next] | [standalone]

#27988

"Ed" <invalid@invalid.com> writes:
>Anton Ertl wrote:
>> "Ed" <invalid@invalid.com> writes:
>> >Problems arise when one adds a second authority which
>> >competes with the text e.g. sample code or tests.  When the sample code
>> >differs from the text, which has precedence?  The same issue with tests.
>>
>> For Forth200x we discussed the question and decided that the text has
>> precedence.
>
>So it is possible to get the text right without resorting to tests which
>might prove a liability.

"Possible": That it's possible does not prove much, cf. the infinite
monkey theorem.

"So": Your statement does not follow from mine.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.forth

csiph-web