While some of the tests in Annex G of the Forth200x draft may be new and
specifically written for the draft, I recognized that some of them come from
copyrighted Hayes core code.

The issue is that the Hayes' core tests which are part of the Forth200x
specification will not be protected by copyright, at least in the USA.

Under US Supreme Court rulings anything in a specification which is required
to comply with said specification is not protectable via copyright laws.

What that means anyone can copy tests in Annex G of the Forth200x drafts
into a file and use them, e.g., with another testing harness such as Josh
Grams' small tester.  In the process of using them, all copyrights on the
original test are lost or nullified, or were infringed by the Forth200x
committee by putting them into the specification in the first place.
I.e., Hayes' requirement of his copyright notice being kept gets
removed, legally.

I think that the Forth200x by using tests and the test harness from Hayes
core as part of a standard where the they are not protectable by under
copyright law in the US presents either one of two legal problems:

1) direct infringement of Hayes' copyrights by Forth200x
2) indirect nullification of Hayes' copyrights by making them
non-protectable by US copyright law

Personally, I think the committee should respect Haye's contribution and
copyright.  So, I think the specification should eliminate _any_ of Hayes'
core tests in Annex G by having completely new tests written for the
specification.  It might also be wise to eliminate his copyrighted harness.
That way only the tests are present in the specification and those tests
will not be copyrighted by John Hayes or infringed upon or nullified by the
specifications' use of them.  I.e., any copyright or infringement issues
with Hayes' core will be eliminated.


Rod Pemberton

Rod Pemberton wrote:
> Under US Supreme Court rulings anything in a specification which is
> required to comply with said specification is not protectable via
> copyright laws.

The test is not required to comply with the specification.  You may run 
the tests to feel good, but it is not an actual requirement.  Standard 
documents are protected by copyright (and standard bodies even require 
copyright transfer), it's just that you can't extend the copyright to 
the implemented system.  If you implement your Forth according to the 
Forth200x draft, it's your Forth.  But the testing does not become part 
of your Forth, as running our tests is not required to meet the 
specifications.  You can write your own tests.

The more troublesome is that standard bodies require copyright 
transfers.  So if we keep the Hayes Tester in, we need to ask John Hayes 
for allowance in case we submit the text to a standard body which 
requires copyright transfer.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

"Bernd Paysan" <bernd.paysan@gmx.de> wrote in message
news:2033927.jaK63IvyOB@sunwukong.fritz.box...
> Rod Pemberton wrote:
> > Under US Supreme Court rulings anything in a specification which is
> > required to comply with said specification is not protectable via
> > copyright laws.
>
> The test is not required to comply with the specification.  You may run
> the tests to feel good, but it is not an actual requirement.
> [... ]
> But the testing does not become part
> of your Forth, as running our tests is not required to meet the
> specifications.  You can write your own tests.

I'm not sure how you can _legitimately_ get away with saying that ...

Did you actually _read_ the Forth200x draft?

With the handful of errors I've posted recently, I'm getting the impression
no one has _read_ it.  People seem to be _writing_ it ... with errors ...


1) In a few places, the language of the Forth200x draft 11.1 specification
either requires, or strongly implies that passing of the tests in Annex G is
a requirement:

E.g.,

1a)
"1.3.2. Annexes"
"Annex G presents a test suite to test the operation of a system complies
with the definitions documented in this standard."

1b)
"G.3 Core Tests"
"... A standard system should pass all of the tests within this suite. ..."

How are either of those *NOT* a requirement to pass all the tests?


2) I have written some of my own tests.  But, my tests only confirm that
what I expect things to do is actually done.  I.e., my expectations of what
they should or should not do, may or may not match your reality or the
specification's intent.  They may not be testing what I think they do, or
the may pass on other Forths for reasons I've overlooked.  My personal tests
also don't test boundary conditions since my interpreter can't yet handle
some of them.

Testing of boundary conditions is a apparently requirement for all tests
submitted for proposals and should also be a requirement for Annex G.  So,
in order to confirm that Forth words are properly tested and comply with the
specification, the specification's tests must be used, i.e., they're
required.


3) The meaning of what is "required to comply with a specification" thereby
allowing use of material within a specification without copyright
infringement is entirely up to the reader.  Except for the quotes above
which support my perspective, I haven't located other statements within the
specification that would provide a clarification of what is required to
comply with a specification.  So, it'll be exceptionally difficult for
anyone to prove otherwise in a court of law.  I.e., where is the statement
to the effect of: "Passing of the tests in Annex G is *NOT* required for
compliance with this specification."  I think you would need that to prevent
use of the tests in the way I previously described, or the law language
equivalent.


Rod Pemberton

Rod Pemberton <do_not_have@notemailnot.cmm> wrote:
> "Bernd Paysan" <bernd.paysan@gmx.de> wrote in message
> news:2033927.jaK63IvyOB@sunwukong.fritz.box...
>> Rod Pemberton wrote:
>> > Under US Supreme Court rulings anything in a specification which is
>> > required to comply with said specification is not protectable via
>> > copyright laws.
>>
>> The test is not required to comply with the specification.  You may run
>> the tests to feel good, but it is not an actual requirement.
>> [... ]
>> But the testing does not become part
>> of your Forth, as running our tests is not required to meet the
>> specifications.  You can write your own tests.
> 
> I'm not sure how you can _legitimately_ get away with saying that ...
> 
> Did you actually _read_ the Forth200x draft?
> 
> With the handful of errors I've posted recently, I'm getting the impression
> no one has _read_ it.  People seem to be _writing_ it ... with errors ...
> 
> 
> 1) In a few places, the language of the Forth200x draft 11.1 specification
> either requires, or strongly implies that passing of the tests in Annex G is
> a requirement:

No it doesn't.

> E.g.,
> 
> 1a)
> "1.3.2. Annexes"
> "Annex G presents a test suite to test the operation of a system complies
> with the definitions documented in this standard."
> 
> 1b)
> "G.3 Core Tests"
> "... A standard system should pass all of the tests within this suite. ..."
> 
> How are either of those *NOT* a requirement to pass all the tests?

It says "should", not "shall".

Andrew.

On Aug 6, 10:11=A0am, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:
> Rod Pemberton <do_not_h...@notemailnot.cmm> wrote:
> > "Bernd Paysan" <bernd.pay...@gmx.de> wrote in message
> >news:2033927.jaK63IvyOB@sunwukong.fritz.box...
> >> Rod Pemberton wrote:
> >> > Under US Supreme Court rulings anything in a specification which is
> >> > required to comply with said specification is not protectable via
> >> > copyright laws.
>
> >> The test is not required to comply with the specification. =A0You may =
run
> >> the tests to feel good, but it is not an actual requirement.
> >> [... ]
> >> But the testing does not become part
> >> of your Forth, as running our tests is not required to meet the
> >> specifications. =A0You can write your own tests.
>
> > I'm not sure how you can _legitimately_ get away with saying that ...
>
> > Did you actually _read_ the Forth200x draft?
>
> > With the handful of errors I've posted recently, I'm getting the impres=
sion
> > no one has _read_ it. =A0People seem to be _writing_ it ... with errors=
 ...
>
> > 1) In a few places, the language of the Forth200x draft 11.1 specificat=
ion
> > either requires, or strongly implies that passing of the tests in Annex=
 G is
> > a requirement:
>
> No it doesn't.
>
> > E.g.,
>
> > 1a)
> > "1.3.2. Annexes"
> > "Annex G presents a test suite to test the operation of a system compli=
es
> > with the definitions documented in this standard."
>
> > 1b)
> > "G.3 Core Tests"
> > "... A standard system should pass all of the tests within this suite. =
...."
>
> > How are either of those *NOT* a requirement to pass all the tests?
>
> It says "should", not "shall".
>
> Andrew.- Hide quoted text -
>
> - Show quoted text -

Correct. That is my interpretation too. SHALL (it is often stated in
upper case in contract documents and technical specifications, just
like the specs from Total and Shell, which are open on my desk right
now) is a very important word. It means "what follows is mandadtory".

I haven't checked the 200x standard, but SHALL will be defined in
there somewhere near the beginning. "Should" also, probably. They are
in ANS94.

Rod Pemberton wrote:

> 1a)
> "1.3.2. Annexes"
> "Annex G presents a test suite to test the operation of a system complies
> with the definitions documented in this standard."

I read this as saying that the Test Suite in Annex G is an example set of 
code which demonstrates compliance but which is not required to be run to do 
so and you can write your own tests if you wish to.

> 1b)
> "G.3 Core Tests"
> "... A standard system should pass all of the tests within this suite.
> ..."
> 
> How are either of those *NOT* a requirement to pass all the tests?

Do you not get the difference between "should" and "shall"? The latter is 
the more imperative element.
 
[%X]

> 3) The meaning of what is "required to comply with a specification"
> thereby allowing use of material within a specification without copyright
> infringement is entirely up to the reader.  Except for the quotes above
> which support my perspective, I haven't located other statements within
> the specification that would provide a clarification of what is required
> to comply with a specification.  So, it'll be exceptionally difficult for
> anyone to prove otherwise in a court of law.  I.e., where is the statement
> to the effect of: "Passing of the tests in Annex G is *NOT* required for
> compliance with this specification."  I think you would need that to
> prevent use of the tests in the way I previously described, or the law
> language equivalent.

The standard authors should, I agree, be very clear of their intentions with 
respect to the requirements of the tests for proving compliance.

-- 
********************************************************************
Paul E. Bennett...............<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

[SNIPPED hand waving]

Has anyone consulted a legal expert?
Do any of the standards organizations have guidelines for 
writing standards?

On Aug 6, 9:16=A0pm, Richard Owlett <rowl...@pcnetinc.com> wrote:
> [SNIPPED hand waving]
>
> Has anyone consulted a legal expert?
> Do any of the standards organizations have guidelines for
> writing standards?

Yes, but what's the question? Is it copyright or the language as in
SHALL/SHOULD?

Paul E. Bennett wrote:
> Rod Pemberton wrote:
>
> > 1a)
> > "1.3.2. Annexes"
> > "Annex G presents a test suite to test the operation of a system complies
> > with the definitions documented in this standard."
>
> I read this as saying that the Test Suite in Annex G is an example set of
> code which demonstrates compliance but which is not required to be run to do
> so and you can write your own tests if you wish to.
>
> > 1b)
> > "G.3 Core Tests"
> > "... A standard system should pass all of the tests within this suite.
> > ..."
> >
> > How are either of those *NOT* a requirement to pass all the tests?
>
> Do you not get the difference between "should" and "shall"? The latter is
> the more imperative element.
>
> [%X]
>
> > 3) The meaning of what is "required to comply with a specification"
> > thereby allowing use of material within a specification without copyright
> > infringement is entirely up to the reader.  Except for the quotes above
> > which support my perspective, I haven't located other statements within
> > the specification that would provide a clarification of what is required
> > to comply with a specification.  So, it'll be exceptionally difficult for
> > anyone to prove otherwise in a court of law.  I.e., where is the statement
> > to the effect of: "Passing of the tests in Annex G is *NOT* required for
> > compliance with this specification."  I think you would need that to
> > prevent use of the tests in the way I previously described, or the law
> > language equivalent.
>
> The standard authors should, I agree, be very clear of their intentions with
> respect to the requirements of the tests for proving compliance.

I know of no language standard that includes a test suite.  Nor do
I see it as a good thing.

Test suites are someone's *interpretation* of the standard and
therefore subject to error and unintended consequences.  As useful
as the Hayes' suite has been for implementers, it cannot be an
authority.  The text of the standard is supposed be the authority.

As contradictory as it may sound, creatively interpreting standards
is a good thing.  It can lead to positive outcomes that no-one imagined
at the time and which 'authorized test suites' may unwittingly rule out.

It's always a mistake to over-legislate.

On Aug 8, 6:59=A0am, "Ed" <inva...@nospam.com> wrote:
> Paul E. Bennett wrote:
> > Rod Pemberton wrote:
>
> > > 1a)
> > > "1.3.2. Annexes"
> > > "Annex G presents a test suite to test the operation of a system comp=
lies
> > > with the definitions documented in this standard."
>
> > I read this as saying that the Test Suite in Annex G is an example set =
of
> > code which demonstrates compliance but which is not required to be run =
to do
> > so and you can write your own tests if you wish to.
>
> > > 1b)
> > > "G.3 Core Tests"
> > > "... A standard system should pass all of the tests within this suite=
..
> > > ..."
>
> > > How are either of those *NOT* a requirement to pass all the tests?
>
> > Do you not get the difference between "should" and "shall"? The latter =
is
> > the more imperative element.
>
> > [%X]
>
> > > 3) The meaning of what is "required to comply with a specification"
> > > thereby allowing use of material within a specification without copyr=
ight
> > > infringement is entirely up to the reader. =A0Except for the quotes a=
bove
> > > which support my perspective, I haven't located other statements with=
in
> > > the specification that would provide a clarification of what is requi=
red
> > > to comply with a specification. =A0So, it'll be exceptionally difficu=
lt for
> > > anyone to prove otherwise in a court of law. =A0I.e., where is the st=
atement
> > > to the effect of: "Passing of the tests in Annex G is *NOT* required =
for
> > > compliance with this specification." =A0I think you would need that t=
o
> > > prevent use of the tests in the way I previously described, or the la=
w
> > > language equivalent.
>
> > The standard authors should, I agree, be very clear of their intentions=
 with
> > respect to the requirements of the tests for proving compliance.
>
> I know of no language standard that includes a test suite. =A0Nor do
> I see it as a good thing.
>
> Test suites are someone's *interpretation* of the standard and
> therefore subject to error and unintended consequences.

True. However, a test suite authored by the TC would give implementors
an authritative target to aim their implementations at, and also serve
as guidance when the text of the standard is ambiguous.


> As useful
> as the Hayes' suite has been for implementers, it cannot be an
> authority. =A0The text of the standard is supposed be the authority.
>

Yet, as we have seen many times, the text of the standard is often
ambiguous, ergo it cannot be authorartitive!

> As contradictory as it may sound, creatively interpreting standards
> is a good thing. =A0It can lead to positive outcomes that no-one imagined
> at the time and which 'authorized test suites' may unwittingly rule out.
>
> It's always a mistake to over-legislate.- Hide quoted text -
>
> - Show quoted text -

I personally would welcome a test suite, either as an appendix to the
standard, or, a seperate document, vetted and passed by the 200x
committee. I genuinely believe it would make life easier for
implementors, and offer a big leap forward towards the eventual goal
of 200x - the Raison Detre: Portability.

Mark Wills <markrobertwills@yahoo.co.uk> wrote:
> On Aug 8, 6:59?am, "Ed" <inva...@nospam.com> wrote:
>> Paul E. Bennett wrote:
>> > Rod Pemberton wrote:
>>
>> > The standard authors should, I agree, be very clear of their
>> > intentions with respect to the requirements of the tests for
>> > proving compliance.
>>
>> I know of no language standard that includes a test suite. Nor do
>> I see it as a good thing.
>
>> Test suites are someone's *interpretation* of the standard and
>> therefore subject to error and unintended consequences.
> 
> True. However, a test suite authored by the TC would give implementors
> an authritative target to aim their implementations at, and also serve
> as guidance when the text of the standard is ambiguous.

I don't think it would: the standard itself is authoritative, the test
suite is not.  Where there's ambiguity, you can't rely on a test
suite, and certainly not for poorly-defined corner cases.  On the
contrary, a test suite often overspecifies things IME.

>> As useful as the Hayes' suite has been for implementers, it cannot
>> be an authority. The text of the standard is supposed be the
>> authority.

> Yet, as we have seen many times, the text of the standard is often
> ambiguous, ergo it cannot be authorartitive!

We haven't seen very much ambuguity, and not in any cases that a test
suite could sort out.  Or have we?  I can't remember any examples.

Andrew.

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>I don't think it would: the standard itself is authoritative, the test
>suite is not.  Where there's ambiguity, you can't rely on a test
>suite, and certainly not for poorly-defined corner cases.  On the
>contrary, a test suite often overspecifies things IME.

Often?  Can you even produce one example?  For Forth?

>We haven't seen very much ambuguity, and not in any cases that a test
>suite could sort out.  Or have we?  I can't remember any examples.

Just recently an issue came up again about whether EVALUATE is allowed
to copy the input string elsewhere and interpret it there.  The Hayes
test suite checks that the system does not do that and this
interpretation has been supported by the the TC in RFI 6
<http://www.complang.tuwien.ac.at/forth/dpans-html/a0006.htm>.  The
specification is not clear, as evidenced by the fact that it was
interpreted differently from the TC by at least two implementors.

- 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 2012: http://www.euroforth.org/ef12/

On Aug 8, 11:47=A0am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
> Andrew Haley <andre...@littlepinkcloud.invalid> writes:
> >I don't think it would: the standard itself is authoritative, the test
> >suite is not. =A0Where there's ambiguity, you can't rely on a test
> >suite, and certainly not for poorly-defined corner cases. =A0On the
> >contrary, a test suite often overspecifies things IME.
>
> Often? =A0Can you even produce one example? =A0For Forth?
>
> >We haven't seen very much ambuguity, and not in any cases that a test
> >suite could sort out. =A0Or have we? =A0I can't remember any examples.
>
> Just recently an issue came up again about whether EVALUATE is allowed
> to copy the input string elsewhere and interpret it there. =A0The Hayes
> test suite checks that the system does not do that and this
> interpretation has been supported by the the TC in RFI 6
> <http://www.complang.tuwien.ac.at/forth/dpans-html/a0006.htm>. =A0The
> specification is not clear, as evidenced by the fact that it was
> interpreted differently from the TC by at least two implementors.
>
> - anton
> --
> M. Anton Ertl =A0http://www.complang.tuwien.ac.at/anton/home.html
> comp.lang.forth FAQs:http://www.complang.tuwien.ac.at/forth/faq/toc.html
> =A0 =A0 =A0New standard:http://www.forth200x.org/forth200x.html
> =A0 =A0EuroForth 2012:http://www.euroforth.org/ef12/

Exactly. Where the text of the specification is unclear, the source
code of a test should remove the abiguity. I concede that it may not
in all cases, but I still think it would be a step in the right
direction.

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>I don't think it would: the standard itself is authoritative, the test
>>suite is not.  Where there's ambiguity, you can't rely on a test
>>suite, and certainly not for poorly-defined corner cases.  On the
>>contrary, a test suite often overspecifies things IME.
> 
> Often?  Can you even produce one example?  For Forth?

For forth no, but I've seen a fair few cases with Java.

>>We haven't seen very much ambuguity, and not in any cases that a test
>>suite could sort out.  Or have we?  I can't remember any examples.
> 
> Just recently an issue came up again about whether EVALUATE is allowed
> to copy the input string elsewhere and interpret it there.  The Hayes
> test suite checks that the system does not do that and this
> interpretation has been supported by the the TC in RFI 6
> <http://www.complang.tuwien.ac.at/forth/dpans-html/a0006.htm>.

In which case the specification is now clear, isn't it?  I'm not
saying it is unambiguous.

Andrew.

Mark Wills <markrobertwills@yahoo.co.uk> wrote:
> Exactly. Where the text of the specification is unclear, the source
> code of a test should remove the abiguity.

No, that's wrong.  A test can't do that because a test is not
authoritative.  It is wrong for a test to insist on something that is
not specified; that's a bug in the test.

Andrew.

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>We haven't seen very much ambuguity, and not in any cases that a test
>>>suite could sort out.  Or have we?  I can't remember any examples.
>> 
>> Just recently an issue came up again about whether EVALUATE is allowed
>> to copy the input string elsewhere and interpret it there.  The Hayes
>> test suite checks that the system does not do that and this
>> interpretation has been supported by the the TC in RFI 6
>> <http://www.complang.tuwien.ac.at/forth/dpans-html/a0006.htm>.
>
>In which case the specification is now clear, isn't it?  I'm not
>saying it is unambiguous.

I don't understand what distinction you are trying to make here.  The
original specification is as it was, there is now an official
clarification/interpretation.  Together they clarify this particular
issue.

Anyway, it seems to me that this refutes your claim that "We haven't
seen very much ambuguity, and not in any cases that a test suite could
sort out".  Note that the clarification came about by an
implementation tripping over a Hayes test, and the implementor then
asked the TC about this issue.  If we did not have this Hayes test,
this clarification probably would not have happened, and maybe this
implementation would still copy the EVALUATEd string.

- 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 2012: http://www.euroforth.org/ef12/

On Aug 8, 3:10=A0pm, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:
> Mark Wills <markrobertwi...@yahoo.co.uk> wrote:
> > Exactly. Where the text of the specification is unclear, the source
> > code of a test should remove the abiguity.
>
> No, that's wrong. =A0A test can't do that because a test is not
> authoritative. =A0It is wrong for a test to insist on something that is
> not specified; that's a bug in the test.
>
> Andrew.

I understand that the test is not authoritative and I am not saying
that it should be. Apologies if that's how it came across. I'm simply
saying there where there is some abmiguity in the specification text
in the mind of the implementor (what is/isn't ambiguous will be
different for different people) then a test suite for that particular
word may serve to explicitly state the intention of the text, and
remove the ambiguity in the mind of the implementor.

The specification would remain authoritative, with recourse to the TC
as normal if the implementor still isn't satisfied.

I'm just going through life experience. In fact, just today I had this
experience. I had to implement a MODBUS CRC-16 algorithm (in Forth, as
it happens) so I went to the MODBUS.ORG website to view the spec. The
spec contains both a textual description of how to generate the CRC,
and a flow chart.

Implementing the code they way I thought the spec read resulted in the
wrong CRCs being generated. I had to resort to some VB code I had
written years earlier (which took some searching for, it's not on my
office machine). That totally clarified where I was going wrong.

Now, *I* would say the spec was ambiguous. However, it might be
perfectly clear to you. However, having access to physical, tested,
working code (with example input and output) made it clear. I didn't
need to ask for clarification and wait days/weeks for an authortitive
answer. It was done. Settled.

Mark

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>We haven't seen very much ambuguity, and not in any cases that a test
>>>>suite could sort out.  Or have we?  I can't remember any examples.
>>> 
>>> Just recently an issue came up again about whether EVALUATE is allowed
>>> to copy the input string elsewhere and interpret it there.  The Hayes
>>> test suite checks that the system does not do that and this
>>> interpretation has been supported by the the TC in RFI 6
>>> <http://www.complang.tuwien.ac.at/forth/dpans-html/a0006.htm>.
>>
>>In which case the specification is now clear, isn't it?  I'm not
>>saying it is unambiguous.
> 
> I don't understand what distinction you are trying to make here.  The
> original specification is as it was, there is now an official
> clarification/interpretation.  Together they clarify this particular
> issue.

Yes.

I did not say that the specification was unambiguous, so pointing out
an ambiguity does not counter what I said.  I did say that we haven't
seen very much ambiguity.

> Anyway, it seems to me that this refutes your claim that "We haven't
> seen very much ambiguity, and not in any cases that a test suite could
> sort out".

I see your point, but the test suite didn't sort out the problem: that
required a real human being to provide an interpretation.

> Note that the clarification came about by an implementation tripping
> over a Hayes test, and the implementor then asked the TC about this
> issue.  If we did not have this Hayes test, this clarification
> probably would not have happened, and maybe this implementation
> would still copy the EVALUATEd string.

Indeed.  Probably no-one would ever have noticed, and the time spent
clarifying this ambiguity would not have been wasted.

Andrew.

Mark Wills <markrobertwills@yahoo.co.uk> wrote:
> On Aug 8, 3:10?pm, Andrew Haley <andre...@littlepinkcloud.invalid>
> wrote:
>> Mark Wills <markrobertwi...@yahoo.co.uk> wrote:
>> > Exactly. Where the text of the specification is unclear, the source
>> > code of a test should remove the abiguity.
>>
>> No, that's wrong. A test can't do that because a test is not
>> authoritative. It is wrong for a test to insist on something that is
>> not specified; that's a bug in the test.
> 
> I understand that the test is not authoritative and I am not saying
> that it should be. Apologies if that's how it came across. I'm simply
> saying there where there is some abmiguity in the specification text
> in the mind of the implementor (what is/isn't ambiguous will be
> different for different people) then a test suite for that particular
> word may serve to explicitly state the intention of the text, and
> remove the ambiguity in the mind of the implementor.

Indeed it may, and that may do more harm than good because it may lead
the implementor to believe that something has to be done in a
particular way.  Test suites can only really provide an indication of
what's required.

There used to be Forths available that everyone would use as a
reference, in particular fig-FORTH, which wasn't very good, but it was
there.  Nowadays, for some reason, we have a bunch of people with
little Forth experience who want to write one from scratch.  This has
never been a good idea: implementing Forth well isn't as easy as
people sometimes think.  Such people have problems interpreting the
standard, because they don't have the background knowledge.

> I'm just going through life experience. In fact, just today I had this
> experience. I had to implement a MODBUS CRC-16 algorithm (in Forth, as
> it happens) so I went to the MODBUS.ORG website to view the spec. The
> spec contains both a textual description of how to generate the CRC,
> and a flow chart.
> 
> Implementing the code they way I thought the spec read resulted in the
> wrong CRCs being generated. I had to resort to some VB code I had
> written years earlier (which took some searching for, it's not on my
> office machine). That totally clarified where I was going wrong.
> 
> Now, *I* would say the spec was ambiguous. However, it might be
> perfectly clear to you. However, having access to physical, tested,
> working code (with example input and output) made it clear. I didn't
> need to ask for clarification and wait days/weeks for an authortitive
> answer. It was done. Settled.

It's much the same with the specification of the DES, which talked
about input and output blocks without ever actually saying how 8 input
bytes were to be mapped onto the 64-bit block to be encrypted.  That
was established by common practice, AFAIK.  And indeed, the Internet
protocols succeeded not because there was a good set of specs but
because there were free implementations.

All this brings back some memories.  MODBUS, as specified, was
particularly tragic because of the 3.5 character timeout with no
tolerance.  It's impossible to implement as specified in a reliable
way; a classic example of how not to write a specification.  In
practice MODBUS only works because people tolerate gaps of much more
than 3.5 characters and make sure they send data with gaps much less.

Andrew.

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Anyway, it seems to me that this refutes your claim that "We haven't
>> seen very much ambiguity, and not in any cases that a test suite could
>> sort out".
>
>I see your point, but the test suite didn't sort out the problem: that
>required a real human being to provide an interpretation.

An interpretation that agreed with the test suite.  If the implementor
had accepted that the test case was correct (which it was), the real
human being would not have been required.

>> Note that the clarification came about by an implementation tripping
>> over a Hayes test, and the implementor then asked the TC about this
>> issue.  If we did not have this Hayes test, this clarification
>> probably would not have happened, and maybe this implementation
>> would still copy the EVALUATEd string.
>
>Indeed.  Probably no-one would ever have noticed,

That is easily refuted, because someone else noticed, and that led to
the recent thread about the topic.

> and the time spent
>clarifying this ambiguity would not have been wasted.

It seems you disagree with the TC about this issue and think that it
should have been left unspecified (an ambiguous condition, in Forth-94
terms).

By contrast, the TC obviously thought that this was not a waste of
time; they could easily have avoided taking a position, because there
was no RFI on this; instead they decided to clarify it and tacked it
onto an answer to an official RFI.

- 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 2012: http://www.euroforth.org/ef12/

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Anyway, it seems to me that this refutes your claim that "We haven't
>>> seen very much ambiguity, and not in any cases that a test suite could
>>> sort out".
>>
>>I see your point, but the test suite didn't sort out the problem: that
>>required a real human being to provide an interpretation.
> 
> An interpretation that agreed with the test suite.  If the implementor
> had accepted that the test case was correct (which it was), the real
> human being would not have been required.

Well yes, I suppose so, in the sense that the test would have pushed
the implementor in a direction that the specification didn't require.

>>> Note that the clarification came about by an implementation tripping
>>> over a Hayes test, and the implementor then asked the TC about this
>>> issue.  If we did not have this Hayes test, this clarification
>>> probably would not have happened, and maybe this implementation
>>> would still copy the EVALUATEd string.
>>
>>Indeed.  Probably no-one would ever have noticed,
> 
> That is easily refuted, because someone else noticed, and that led to
> the recent thread about the topic.

Indeed, but that's not my point: would the difference ever have
affected any actual Forth programs that weren't test suites?

>> and the time spent clarifying this ambiguity would not have been
>> wasted.
> 
> It seems you disagree with the TC about this issue and think that it
> should have been left unspecified (an ambiguous condition, in Forth-94
> terms).

No, I don't, because it would have taken time to decide to leave it
unspecified.  Once the issue had arisen, it made sense to clarify it
the way it was.  Once ambiguities in a spec arise, it makes sense to
clarify things.  However, I doubt that any real program would ever
have been affected, which is why I call the whole drawn-out saga a
waste of time.  We're wasting time talking about it now!

Andrew.