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

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

Ann: ANS/FORTH 2012 test suite update

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

Contents

  Ann: ANS/FORTH 2012 test suite update Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-27 20:06 +0000
    Re: Ann: ANS/FORTH 2012 test suite update Aliaksei Chapyzhenka <alex.drom@gmail.com> - 2015-11-27 22:19 -0800
    Re: Ann: ANS/FORTH 2012 test suite update peter.m.falth@gmail.com - 2015-11-28 10:07 -0800
      Re: Ann: ANS/FORTH 2012 test suite update Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-29 10:13 +0000
      Re: Ann: ANS/FORTH 2012 test suite update "steve@srpalmer.me.uk" <steverpalmer27@gmail.com> - 2015-11-29 03:47 -0800
        Re: Ann: ANS/FORTH 2012 test suite update Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-29 12:41 +0000
        Re: Ann: ANS/FORTH 2012 test suite update anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-29 12:41 +0000
        Re: Ann: ANS/FORTH 2012 test suite update peter.m.falth@gmail.com - 2015-11-29 08:41 -0800
          Re: Ann: ANS/FORTH 2012 test suite update peter.m.falth@gmail.com - 2015-11-29 10:47 -0800
            Re: Ann: ANS/FORTH 2012 test suite update Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-29 20:29 +0000
              Re: Ann: ANS/FORTH 2012 test suite update peter.m.falth@gmail.com - 2015-11-29 14:44 -0800
                Re: Ann: ANS/FORTH 2012 test suite update Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-30 01:24 +0100
                  Re: Ann: ANS/FORTH 2012 test suite update Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-30 09:35 +0000
                    Re: Ann: ANS/FORTH 2012 test suite update anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-30 18:04 +0000
                      Re: Ann: ANS/FORTH 2012 test suite update Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-30 21:28 +0000
                        Re: Ann: ANS/FORTH 2012 test suite update Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-30 22:59 +0100
                          Re: Ann: ANS/FORTH 2012 test suite update Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-12-01 12:29 +0000
                        Re: Ann: ANS/FORTH 2012 test suite update Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-12-02 10:08 +0000
                          Re: Ann: ANS/FORTH 2012 test suite update anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-12-05 15:57 +0000
                Re: Ann: ANS/FORTH 2012 test suite update Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-30 09:49 +0000
                  Re: Ann: ANS/FORTH 2012 test suite update anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-30 18:16 +0000
                    Re: Ann: ANS/FORTH 2012 test suite update Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-30 21:28 +0000
                Re: Ann: ANS/FORTH 2012 test suite update Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-30 10:25 +0000
            Re: Ann: ANS/FORTH 2012 test suite update "Elizabeth D. Rather" <erather@forth.com> - 2015-11-29 13:14 -1000
            Re: Ann: ANS/FORTH 2012 test suite update steverpalmer27@gmail.com - 2015-11-30 03:51 -0800
              Re: Ann: ANS/FORTH 2012 test suite update peter.m.falth@gmail.com - 2015-11-30 09:00 -0800
                Re: Ann: ANS/FORTH 2012 test suite update "Elizabeth D. Rather" <erather@forth.com> - 2015-11-30 07:54 -1000
                  Re: Ann: ANS/FORTH 2012 test suite update Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-30 18:25 +0000
                    Re: Ann: ANS/FORTH 2012 test suite update "Elizabeth D. Rather" <erather@forth.com> - 2015-11-30 11:06 -1000
        Re: Ann: ANS/FORTH 2012 test suite update "Elizabeth D. Rather" <erather@forth.com> - 2015-11-29 13:08 -1000

Page 1 of 2  [1] 2  Next page →

#43883 — Ann: ANS/FORTH 2012 test suite update

Updated to include a set of Block Word set tests (many thanks to Steve 
Palmer for the contribution) and various other improvements. See 
http://soton.mpeforth.com/flag/anstests/index.html

-- 
Gerry

[toc] | [next] | [standalone]

#43892

Hi Gerry,

I think it is a great idea creating standalone Forth Standard test suite.
I am using it to test my JavaScript Forth https://github.com/drom/forth

--Alexey

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

#43906

On Friday, 27 November 2015 21:06:04 UTC+1, Gerry  wrote:
> Updated to include a set of Block Word set tests (many thanks to Steve 
> Palmer for the contribution) and various other improvements. See 
> http://soton.mpeforth.com/flag/anstests/index.html
> 
> -- 
> Gerry

Gerry, first a great thanks for providing this test-suite.

I found a problem. 
You have changed COMPARE to STR= but you give a definition to S=
in the utilities file. STR= is used in 3 of the files so compilation stops

Then I found several problems in my Forth when running the Block tests.
This is due to the way I implement Blocks. I simply do a memory mapping
of the blockfile and have it all in memory. For this reason I can set 
: BUFFER  BLOCK ; and have no buffers at all. Any modification of a block
is handled by the operating system (Linux or Windows) and eventually
transferred to disk.

For this reason I fail your tests when you UPDATE and then run EMPTY-BUFFERS
as the contents has already been written.
I need to think if I want to introduce a buffer to transfer each block thru
to pass your tests. I like the simplicity of the mapped file and it has
worked well for me for 20 years.

BR
Peter

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

#43930

On 28/11/2015 18:07, peter.m.falth@gmail.com wrote:
> On Friday, 27 November 2015 21:06:04 UTC+1, Gerry  wrote:
>> Updated to include a set of Block Word set tests (many thanks to Steve
>> Palmer for the contribution) and various other improvements. See
>> http://soton.mpeforth.com/flag/anstests/index.html
>>
>> --
>> Gerry
>
> Gerry, first a great thanks for providing this test-suite.
>
> I found a problem.
> You have changed COMPARE to STR= but you give a definition to S=
> in the utilities file. STR= is used in 3 of the files so compilation stops
>

I don't quite know how this happened. It was a late change that didn't 
find its way into the GitHub master. I am a beginner with GitHub so I 
made a mistake somewhere. All occurrences of STR= have been changed to 
S= so the download is OK now. Sorry about that and many thanks for 
reporting it.

> Then I found several problems in my Forth when running the Block tests.
> This is due to the way I implement Blocks. I simply do a memory mapping
> of the blockfile and have it all in memory. For this reason I can set
> : BUFFER  BLOCK ; and have no buffers at all. Any modification of a block
> is handled by the operating system (Linux or Windows) and eventually
> transferred to disk.
>
> For this reason I fail your tests when you UPDATE and then run EMPTY-BUFFERS
> as the contents has already been written.
> I need to think if I want to introduce a buffer to transfer each block thru
> to pass your tests. I like the simplicity of the mapped file and it has
> worked well for me for 20 years.
>

I've forwarded this on to the author of the tests and await his reply. 
I'll look into it in the meantime - I've never used blocks so can't 
promise a quick solution.

Once again thanks.

-- 
Gerry

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

#43932

Hi Peter,

> I found a problem. 
> You have changed COMPARE to STR= but you give a definition to S=
> in the utilities file. STR= is used in 3 of the files so compilation stops

Gerry is on this.  Thanks for reporting it.

> Then I found several problems in my Forth when running the Block tests.
> This is due to the way I implement Blocks. I simply do a memory mapping
> of the blockfile and have it all in memory. For this reason I can set 
> : BUFFER  BLOCK ; and have no buffers at all. Any modification of a block
> is handled by the operating system (Linux or Windows) and eventually
> transferred to disk.
> 
> For this reason I fail your tests when you UPDATE and then run EMPTY-BUFFERS
> as the contents has already been written.
> I need to think if I want to introduce a buffer to transfer each block thru
> to pass your tests. I like the simplicity of the mapped file and it has
> worked well for me for 20 years.

Thanks for the feedback.  I checked the ANS standard regarding blocks and buffers and found the following relevant statements:

Section 7.2 gives a definition of "block buffer: A block-sized region of data space where a block is made temporarily available for use. The current block buffer is the block buffer most recently accessed by BLOCK, BUFFER, LOAD, LIST, or THRU."

Section 7.6.1.2400 gives the semantics of the word UPDATE, including the statement "Mark the current block buffer as modified. ... UPDATE does not immediately cause I/O."

Section 7.6.2.1330 gives the semantics of the extension word EMPTY-BUFFERS, saying "Do not transfer the contents of any UPDATEd block buffer to mass
storage."

I've checked the wording in Release Candidate 3 of Forth 2012 [RC3] and the latest version I can find on-line and they are all the same.

The Rationale section goes on to say and Blocks "Early Forth systems ran without a host OS; these are known as native systems. Such systems provide mass storage in blocks of 1024 bytes. The Block Word set includes the most common words for accessing program source and data on disk."  The Block word set operational model (as I interpret from the definitions above) is also trying to maintain consistency with native systems without advanced memory management hardware.  In particular, the forth system maintained a cache of buffers and the forth program had to indicate when a buffer had been changed (UPDATE) and when the changes where complete and so needed to be written back (FLUSH).

It also provided the option of throwing away the changes using EMPTY-BUFFERS.  (I'm not sure how a Forth Program that used more than one buffer could know what was being thrown away, but there you go.)  The semantics indicated in the language standard specifically state that even UPDATEd blocks do not get written back if EMPTY-BUFFERS is called.

Moving forwards to modern times with 32+ bit processors and hardware memory managers, I can quite understand the attraction of a memory mapped block file.  All changes are automatically captured and there is no need for UPDATE or FLUSH or others.  I suspect that it will make the life on real Forth Program using blocks to be much easier.  However, I don't think it is consistent with the language standard.

To test compliance with the standard, (at around line 555) I write a block (UPDATEd and FLUSHed) to one value, then change it, UPDATE it, but then discard the changes using EMPTY-BUFFERS.  The expectation is that the block contains the first value, not the second.  I guess that this is (at least one of) the place where an error is being reported.  If I've misunderstood the standard, then obviously the test should be changed, but I think that this test is a fair reflection of, in particular, section 7.6.2.1330.

You do ask a good question as to whether to change your current approach.  This will depend on your use cases.  I could easily be wrong, but I also get the impression that the Block word set is "falling out of fashion".  The ANS standard stated in section 3.2.5 that "A system need not provide any standard words for accessing mass storage. If a system provides any standard word for accessing mass storage, it shall also implement the Block word set."  RC3 has only the first statement and does not include the second statement, eliminating the need to provide at least the block word set.  I also struggle to see how the provided API could be used in a multitasking system, since the Forth Program can never now whether the address it has in the cache is still valid.  This problem disappears with a memory mapped block file.

So a long answer, but basically:
 1. I think that the tests are consistent with the language standard;
 2. I can see the advantages of the memory mapped block file and you may choose usability over compliance.

Thanks again,
Steve

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

#43933

"steve@srpalmer.me.uk" <steverpalmer27@gmail.com> writes:

<SNIP>
>To test compliance with the standard, (at around line 555) I write a block =
>(UPDATEd and FLUSHed) to one value, then change it, UPDATE it, but then dis=
>card the changes using EMPTY-BUFFERS.  The expectation is that the block co=
>ntains the first value, not the second.  I guess that this is (at least one=
> of) the place where an error is being reported.  If I've misunderstood the=
> standard, then obviously the test should be changed, but I think that this=
> test is a fair reflection of, in particular, section 7.6.2.1330.

Here you have it. Any of an assorted undefined action can write the
buffer to disk, in particular fetching some other block (as it may need the
buffer).
So if the above action works, you just got lucky. It shouldn't be relied
upon. In ciforth I always write to disk within the UPDATE action,
and specify that "EMPTY-BUFFERS as an undo is unfeasible."

>So a long answer, but basically:
> 1. I think that the tests are consistent with the language standard;
> 2. I can see the advantages of the memory mapped block file and you may ch=
>oose usability over compliance.

I think a test should only try to check whether EMPTY-BUFFERS results in
a clean intial state, not whether trying to come between the unspecified
times of an UPDATE and the actual writing to mass storage.
So the above shouldn't be in a test.

>Thanks again,
>Steve
-- 
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

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

#43934

"steve@srpalmer.me.uk" <steverpalmer27@gmail.com> writes:
>Moving forwards to modern times with 32+ bit processors and hardware memory=
> managers, I can quite understand the attraction of a memory mapped block f=
>ile.  All changes are automatically captured and there is no need for UPDAT=
>E or FLUSH or others.  I suspect that it will make the life on real Forth P=
>rogram using blocks to be much easier.  However, I don't think it is consis=
>tent with the language standard.

Instead of mmap()ing the blocks file with MAP_SHARED, one could also
use MAP_PRIVATE and then write out UPDATEd buffers explicitly with
write() on SAVE-BUFERS (replace the corresponding non-POSIX names on
non-POSIX OSs).  There would be no guarantee about consistency between
blocks files in two different processes, but the standard does not
give such a guarantee anyway.

>To test compliance with the standard, (at around line 555) I write a block =
>(UPDATEd and FLUSHed) to one value, then change it, UPDATE it, but then dis=
>card the changes using EMPTY-BUFFERS.  The expectation is that the block co=
>ntains the first value, not the second.  I guess that this is (at least one=
> of) the place where an error is being reported.  If I've misunderstood the=
> standard, then obviously the test should be changed, but I think that this=
> test is a fair reflection of, in particular, section 7.6.2.1330.

Yes.  However, Andrew Haley has pointed out how blocks are used on
multi-user systems.  Basically, you had to assume that, on every
potentially PAUSEing operation (all I/O), another task could do
anything with blocks.  In this setting, I expect that one would
UPDATE, then change and when you want to have everything on disk,
SAVE-BUFFERS.  EMPTY-BUFFERS does not make much sense in that kind of
setting (as an action that is used for a guaranteed outcome), but it
might have been used as an attempt at undoing the changes to the
buffer, without guarantee of success.

The standard does not cover such traditional cooperative
multi-tasking, and given that we are living in a world with
multi-cores, we probably should not limit ourselves to that model in
future standardization efforts.

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#43936

On Sunday, 29 November 2015 12:47:27 UTC+1, st...@srpalmer.me.uk  wrote:
> Hi Peter,
> 
> > I found a problem. 
> > You have changed COMPARE to STR= but you give a definition to S=
> > in the utilities file. STR= is used in 3 of the files so compilation stops
> 
> Gerry is on this.  Thanks for reporting it.
> 
> > Then I found several problems in my Forth when running the Block tests.
> > This is due to the way I implement Blocks. I simply do a memory mapping
> > of the blockfile and have it all in memory. For this reason I can set 
> > : BUFFER  BLOCK ; and have no buffers at all. Any modification of a block
> > is handled by the operating system (Linux or Windows) and eventually
> > transferred to disk.
> > 
> > For this reason I fail your tests when you UPDATE and then run EMPTY-BUFFERS
> > as the contents has already been written.
> > I need to think if I want to introduce a buffer to transfer each block thru
> > to pass your tests. I like the simplicity of the mapped file and it has
> > worked well for me for 20 years.
> 
> Thanks for the feedback.  I checked the ANS standard regarding blocks and buffers and found the following relevant statements:
> 
> Section 7.2 gives a definition of "block buffer: A block-sized region of data space where a block is made temporarily available for use. The current block buffer is the block buffer most recently accessed by BLOCK, BUFFER, LOAD, LIST, or THRU."
> 
> Section 7.6.1.2400 gives the semantics of the word UPDATE, including the statement "Mark the current block buffer as modified. ... UPDATE does not immediately cause I/O."
> 
> Section 7.6.2.1330 gives the semantics of the extension word EMPTY-BUFFERS, saying "Do not transfer the contents of any UPDATEd block buffer to mass
> storage."
> 
> I've checked the wording in Release Candidate 3 of Forth 2012 [RC3] and the latest version I can find on-line and they are all the same.
> 
> The Rationale section goes on to say and Blocks "Early Forth systems ran without a host OS; these are known as native systems. Such systems provide mass storage in blocks of 1024 bytes. The Block Word set includes the most common words for accessing program source and data on disk."  The Block word set operational model (as I interpret from the definitions above) is also trying to maintain consistency with native systems without advanced memory management hardware.  In particular, the forth system maintained a cache of buffers and the forth program had to indicate when a buffer had been changed (UPDATE) and when the changes where complete and so needed to be written back (FLUSH).
> 
> It also provided the option of throwing away the changes using EMPTY-BUFFERS.  (I'm not sure how a Forth Program that used more than one buffer could know what was being thrown away, but there you go.)  The semantics indicated in the language standard specifically state that even UPDATEd blocks do not get written back if EMPTY-BUFFERS is called.
> 
> Moving forwards to modern times with 32+ bit processors and hardware memory managers, I can quite understand the attraction of a memory mapped block file.  All changes are automatically captured and there is no need for UPDATE or FLUSH or others.  I suspect that it will make the life on real Forth Program using blocks to be much easier.  However, I don't think it is consistent with the language standard.
> 
> To test compliance with the standard, (at around line 555) I write a block (UPDATEd and FLUSHed) to one value, then change it, UPDATE it, but then discard the changes using EMPTY-BUFFERS.  The expectation is that the block contains the first value, not the second.  I guess that this is (at least one of) the place where an error is being reported.  If I've misunderstood the standard, then obviously the test should be changed, but I think that this test is a fair reflection of, in particular, section 7.6.2.1330.
> 
> You do ask a good question as to whether to change your current approach.  This will depend on your use cases.  I could easily be wrong, but I also get the impression that the Block word set is "falling out of fashion".  The ANS standard stated in section 3.2.5 that "A system need not provide any standard words for accessing mass storage. If a system provides any standard word for accessing mass storage, it shall also implement the Block word set."  RC3 has only the first statement and does not include the second statement, eliminating the need to provide at least the block word set.  I also struggle to see how the provided API could be used in a multitasking system, since the Forth Program can never now whether the address it has in the cache is still valid.  This problem disappears with a memory mapped block file.
> 
> So a long answer, but basically:
>  1. I think that the tests are consistent with the language standard;
>  2. I can see the advantages of the memory mapped block file and you may choose usability over compliance.
> 
> Thanks again,
> Steve

Hi Steve,

I share your analysis and think that my implementation failed when I updated
the block when modified but not marked updated.

I have now implemented 1 buffer and pass all of the tests except one.
This is a bug on my side in save-input that was there all the time
(or seen now with 1 buffer)

I found one problem that I think is an error in your test.
In TL7 (line 474) you test if there is only one buffer. if that is the case
you drop the parameters and push zeros and then exists. There is one drop
to much.

I can see that you and Gerry have put in a lot of work on these tests.
They have really helped me create a better forth. A big thanks for your efforts

BR
Peter

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

#43939

On Sunday, 29 November 2015 17:41:19 UTC+1, peter....@gmail.com  wrote:
> On Sunday, 29 November 2015 12:47:27 UTC+1, st...@srpalmer.me.uk  wrote:
> > Hi Peter,
> > 
> > > I found a problem. 
> > > You have changed COMPARE to STR= but you give a definition to S=
> > > in the utilities file. STR= is used in 3 of the files so compilation stops
> > 
> > Gerry is on this.  Thanks for reporting it.
> > 
> > > Then I found several problems in my Forth when running the Block tests.
> > > This is due to the way I implement Blocks. I simply do a memory mapping
> > > of the blockfile and have it all in memory. For this reason I can set 
> > > : BUFFER  BLOCK ; and have no buffers at all. Any modification of a block
> > > is handled by the operating system (Linux or Windows) and eventually
> > > transferred to disk.
> > > 
> > > For this reason I fail your tests when you UPDATE and then run EMPTY-BUFFERS
> > > as the contents has already been written.
> > > I need to think if I want to introduce a buffer to transfer each block thru
> > > to pass your tests. I like the simplicity of the mapped file and it has
> > > worked well for me for 20 years.
> > 
> > Thanks for the feedback.  I checked the ANS standard regarding blocks and buffers and found the following relevant statements:
> > 
> > Section 7.2 gives a definition of "block buffer: A block-sized region of data space where a block is made temporarily available for use. The current block buffer is the block buffer most recently accessed by BLOCK, BUFFER, LOAD, LIST, or THRU."
> > 
> > Section 7.6.1.2400 gives the semantics of the word UPDATE, including the statement "Mark the current block buffer as modified. ... UPDATE does not immediately cause I/O."
> > 
> > Section 7.6.2.1330 gives the semantics of the extension word EMPTY-BUFFERS, saying "Do not transfer the contents of any UPDATEd block buffer to mass
> > storage."
> > 
> > I've checked the wording in Release Candidate 3 of Forth 2012 [RC3] and the latest version I can find on-line and they are all the same.
> > 
> > The Rationale section goes on to say and Blocks "Early Forth systems ran without a host OS; these are known as native systems. Such systems provide mass storage in blocks of 1024 bytes. The Block Word set includes the most common words for accessing program source and data on disk."  The Block word set operational model (as I interpret from the definitions above) is also trying to maintain consistency with native systems without advanced memory management hardware.  In particular, the forth system maintained a cache of buffers and the forth program had to indicate when a buffer had been changed (UPDATE) and when the changes where complete and so needed to be written back (FLUSH).
> > 
> > It also provided the option of throwing away the changes using EMPTY-BUFFERS.  (I'm not sure how a Forth Program that used more than one buffer could know what was being thrown away, but there you go.)  The semantics indicated in the language standard specifically state that even UPDATEd blocks do not get written back if EMPTY-BUFFERS is called.
> > 
> > Moving forwards to modern times with 32+ bit processors and hardware memory managers, I can quite understand the attraction of a memory mapped block file.  All changes are automatically captured and there is no need for UPDATE or FLUSH or others.  I suspect that it will make the life on real Forth Program using blocks to be much easier.  However, I don't think it is consistent with the language standard.
> > 
> > To test compliance with the standard, (at around line 555) I write a block (UPDATEd and FLUSHed) to one value, then change it, UPDATE it, but then discard the changes using EMPTY-BUFFERS.  The expectation is that the block contains the first value, not the second.  I guess that this is (at least one of) the place where an error is being reported.  If I've misunderstood the standard, then obviously the test should be changed, but I think that this test is a fair reflection of, in particular, section 7.6.2.1330.
> > 
> > You do ask a good question as to whether to change your current approach.  This will depend on your use cases.  I could easily be wrong, but I also get the impression that the Block word set is "falling out of fashion".  The ANS standard stated in section 3.2.5 that "A system need not provide any standard words for accessing mass storage. If a system provides any standard word for accessing mass storage, it shall also implement the Block word set."  RC3 has only the first statement and does not include the second statement, eliminating the need to provide at least the block word set.  I also struggle to see how the provided API could be used in a multitasking system, since the Forth Program can never now whether the address it has in the cache is still valid.  This problem disappears with a memory mapped block file.
> > 
> > So a long answer, but basically:
> >  1. I think that the tests are consistent with the language standard;
> >  2. I can see the advantages of the memory mapped block file and you may choose usability over compliance.
> > 
> > Thanks again,
> > Steve
> 
> Hi Steve,
> 
> I share your analysis and think that my implementation failed when I updated
> the block when modified but not marked updated.
> 
> I have now implemented 1 buffer and pass all of the tests except one.
> This is a bug on my side in save-input that was there all the time
> (or seen now with 1 buffer)
> 
> I found one problem that I think is an error in your test.
> In TL7 (line 474) you test if there is only one buffer. if that is the case
> you drop the parameters and push zeros and then exists. There is one drop
> to much.
> 
> I can see that you and Gerry have put in a lot of work on these tests.
> They have really helped me create a better forth. A big thanks for your efforts
> 
> BR
> Peter

Hi again Steve,

I fixed my problem but did still not pass the test!
Instead I found a problem in your test.
In TCSIRIR4 at line 653 you shift to the next block to start writing to it
but the old buffer is not updated so it will be overwritten and not committed
to the disk. Inserting an UPDATE SAVE-BUFFERS solved this.

I now pass all the tests in the test suite except one.

INCORRECT RESULT: \? T{ $" [']" FORTH-WORDLIST GET-NAME-TOKEN NAME>INTERPRET -> 0 }T

But this I do not really consider a problem. Maybe this test should be deleted

I also get 2 errors on the FP tests, but also these I think is OK.
I allow an FP number to have leading or trailing blank chars where your
tests does not.

Again thanks to both Steve and Gerry for a very good work put into this test suite

BR
Peter

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

#43943

On 29/11/2015 18:47, peter.m.falth@gmail.com wrote:
>> Hi Steve,
>> >
>> >I share your analysis and think that my implementation failed when I updated
>> >the block when modified but not marked updated.
>> >
>> >I have now implemented 1 buffer and pass all of the tests except one.
>> >This is a bug on my side in save-input that was there all the time
>> >(or seen now with 1 buffer)
>> >
>> >I found one problem that I think is an error in your test.
>> >In TL7 (line 474) you test if there is only one buffer. if that is the case
>> >you drop the parameters and push zeros and then exists. There is one drop
>> >to much.
>> >
>> >I can see that you and Gerry have put in a lot of work on these tests.
>> >They have really helped me create a better forth. A big thanks for your efforts
>> >
>> >BR
>> >Peter
> Hi again Steve,
>
> I fixed my problem but did still not pass the test!
> Instead I found a problem in your test.
> In TCSIRIR4 at line 653 you shift to the next block to start writing to it
> but the old buffer is not updated so it will be overwritten and not committed
> to the disk. Inserting an UPDATE SAVE-BUFFERS solved this.
>
> I now pass all the tests in the test suite except one.
>
> INCORRECT RESULT: \? T{ $" [']" FORTH-WORDLIST GET-NAME-TOKEN NAME>INTERPRET -> 0 }T
>
> But this I do not really consider a problem. Maybe this test should be deleted
>

This test in file toolstest.fth is a new one as NAME>INTERPRET is a new 
word in Forth 2012. The specification says:
------
15.6.2.1909.20 NAME>INTERPRET “name-to-interpret” TOOLS EXT
    ( nt – – xt | 0 )
    xt represents the interpretation semantics of the word nt. If nt has
    no interpretation semantics, NAME>INTERPRET returns 0.

    Note: This standard does not define the interpretation semantics of
    some words, but systems are allowed to do so.
------
The test is on a word that has no interpretation semantics. As the 
comments before the test indicate, this could be difficult due to the 
note in the specification. ['] was chosen because it has an 
interpretation equivalent ' in the hope that systems wouldn't have 
interpretation semantics for ['].
  Assuming the test is correct, the fact it fails implies one of two things:

1. that your system has interpretation semantics for ['] or
2. your implementation of NAME>INTERPRET is incorrect.

As the comments in the test program indicate, if 1. is the case then you 
could select another word that has no interpretation semantics to 
replace ['] in the test, if you have such a word. ; EXIT [CHAR] RECURSE 
are suggested as alternatives. If all your words have defined 
interpretation semantics then that test cannot be used in your system so 
it can be deleted.

I am reluctant to delete the test unless most systems cannot pass it. 
One option for the test suite we have briefly discussed is to have a 
test configuration file, this is something that could be put into such a 
file so that, if the test is inapplicable, it is skipped.

> I also get 2 errors on the FP tests, but also these I think is OK.
> I allow an FP number to have leading or trailing blank chars where your
> tests does not.

That's interesting - can you let me know which particular tests give the 
errors. The FP tests are experimental and simply a collection of 
contributions from other people. I included those in early 2012 in the 
hope that people would run the tests and provide feedback and further 
develop the tests. Yours is only the second comment I have received - 
and thanks for that. We really need a comprehensive set of FP tests and 
I don't really have the time (or expertise as I hardly ever use floating 
point) to develop such a set. A volunteer is needed.

>
> Again thanks to both Steve and Gerry for a very good work put into this test suite

You're welcome, I am pleased they are being used.

-- 
Gerry

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

#43947

On Sunday, 29 November 2015 21:29:27 UTC+1, Gerry  wrote:
> On 29/11/2015 18:47, peter.m.falth@gmail.com wrote:
> >> Hi Steve,
> >> >
> >> >I share your analysis and think that my implementation failed when I updated
> >> >the block when modified but not marked updated.
> >> >
> >> >I have now implemented 1 buffer and pass all of the tests except one.
> >> >This is a bug on my side in save-input that was there all the time
> >> >(or seen now with 1 buffer)
> >> >
> >> >I found one problem that I think is an error in your test.
> >> >In TL7 (line 474) you test if there is only one buffer. if that is the case
> >> >you drop the parameters and push zeros and then exists. There is one drop
> >> >to much.
> >> >
> >> >I can see that you and Gerry have put in a lot of work on these tests.
> >> >They have really helped me create a better forth. A big thanks for your efforts
> >> >
> >> >BR
> >> >Peter
> > Hi again Steve,
> >
> > I fixed my problem but did still not pass the test!
> > Instead I found a problem in your test.
> > In TCSIRIR4 at line 653 you shift to the next block to start writing to it
> > but the old buffer is not updated so it will be overwritten and not committed
> > to the disk. Inserting an UPDATE SAVE-BUFFERS solved this.
> >
> > I now pass all the tests in the test suite except one.
> >
> > INCORRECT RESULT: \? T{ $" [']" FORTH-WORDLIST GET-NAME-TOKEN NAME>INTERPRET -> 0 }T
> >
> > But this I do not really consider a problem. Maybe this test should be deleted
> >
> 
> This test in file toolstest.fth is a new one as NAME>INTERPRET is a new 
> word in Forth 2012. The specification says:
> ------
> 15.6.2.1909.20 NAME>INTERPRET "name-to-interpret" TOOLS EXT
>     ( nt - - xt | 0 )
>     xt represents the interpretation semantics of the word nt. If nt has
>     no interpretation semantics, NAME>INTERPRET returns 0.
> 
>     Note: This standard does not define the interpretation semantics of
>     some words, but systems are allowed to do so.
> ------
> The test is on a word that has no interpretation semantics. As the 
> comments before the test indicate, this could be difficult due to the 
> note in the specification. ['] was chosen because it has an 
> interpretation equivalent ' in the hope that systems wouldn't have 
> interpretation semantics for ['].
>   Assuming the test is correct, the fact it fails implies one of two things:
> 
> 1. that your system has interpretation semantics for ['] or
> 2. your implementation of NAME>INTERPRET is incorrect.
> 
> As the comments in the test program indicate, if 1. is the case then you 
> could select another word that has no interpretation semantics to 
> replace ['] in the test, if you have such a word. ; EXIT [CHAR] RECURSE 
> are suggested as alternatives. If all your words have defined 
> interpretation semantics then that test cannot be used in your system so 
> it can be deleted.
> 

Both of my systems define interpretation semantics to all compile-only words
in my 32 bit system all compile-only words return an interpretation xt that 
when executed prints an error message.

In my new 64 bit system they simply return the compilation semantics also if
executed while interpreting.

I think definitely that this is allowed by the standard.

I could of course special-case NAME>INTERPRET to detect these and return 0
for them. But what would this add other then complication


> I am reluctant to delete the test unless most systems cannot pass it. 
> One option for the test suite we have briefly discussed is to have a 
> test configuration file, this is something that could be put into such a 
> file so that, if the test is inapplicable, it is skipped.
> 
> > I also get 2 errors on the FP tests, but also these I think is OK.
> > I allow an FP number to have leading or trailing blank chars where your
> > tests does not.
> 
> That's interesting - can you let me know which particular tests give the 
> errors. The FP tests are experimental and simply a collection of 
> contributions from other people. I included those in early 2012 in the 
> hope that people would run the tests and provide feedback and further 
> develop the tests. Yours is only the second comment I have received - 
> and thanks for that. We really need a comprehensive set of FP tests and 
> I don't really have the time (or expertise as I hardly ever use floating 
> point) to develop such a set. A volunteer is needed.
> 

The file I get the errors in is to-float-test.4th

Here they are

INCORRECT RESULT: t{  S"  9"   >FLOAT  ->   FALSE     }t    \ Leading space
WRONG NUMBER OF FP RESULTS: t{  S"  9"   >FLOAT  ->   FALSE     }t    \ Leading space
INCORRECT RESULT: t{  S" 9 "   >FLOAT  ->   FALSE     }t    \ Trailing space
WRONG NUMBER OF FP RESULTS: t{  S" 9 "   >FLOAT  ->   FALSE     }t    \ Trailing space

>FLOAT is a way to read in FP numbers from different sources and is specified
to allow different FP representations. It even allows a string of blanks to be
interpreted as zero. A leading or trailing space should not disqualify it.

In my opinion the standard here describe the minimum that a system must 
deliver to be compliant. It can choose to do more. I allow also binary hex 
input like

S" 0x1.1234ABCDp64" >FLOAT

BR
Peter


> >
> > Again thanks to both Steve and Gerry for a very good work put into this test suite
> 
> You're welcome, I am pleased they are being used.
> 
> -- 
> Gerry

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

#43951

peter.m.falth@gmail.com wrote:
> Both of my systems define interpretation semantics to all compile-only
> words in my 32 bit system all compile-only words return an interpretation
> xt that when executed prints an error message.

The 0 return value is only a permission.  A system may return 0 for compile-
only words, but it can either define an interpretation semantics for 
compile-only words, or return the compilation semantics xt.

We recently changed Gforth so that it only warns when compile-only words are 
encountered with ' or the interpreter, and as part of that, NAME>INTERPRET 
has been changed not to return 0.  You still can query the flags with 
COMPILE-ONLY? ( nt -- flag ), so we could implement a NAME>INTERPRET which 
returns 0 in that case.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

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

#43961

On 30/11/2015 00:24, Bernd Paysan wrote:
> peter.m.falth@gmail.com wrote:
>> Both of my systems define interpretation semantics to all compile-only
>> words in my 32 bit system all compile-only words return an interpretation
>> xt that when executed prints an error message.
>
> The 0 return value is only a permission.  A system may return 0 for compile-
> only words, but it can either define an interpretation semantics for
> compile-only words, or return the compilation semantics xt.

I think we'll have to amend the test in a future version.

>
> We recently changed Gforth so that it only warns when compile-only words are
> encountered with ' or the interpreter, and as part of that, NAME>INTERPRET
> has been changed not to return 0.

You still can query the flags with
> COMPILE-ONLY? ( nt -- flag ), so we could implement a NAME>INTERPRET which
> returns 0 in that case.
>

So does NAME>INTERPRET return an xt that can be executed to do something 
useful i.e. do something other than output a warning or throwing an 
error. If not then surely returning a 0 is better for a user.

-- 
Gerry

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

#43977

Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>On 30/11/2015 00:24, Bernd Paysan wrote:
>> We recently changed Gforth so that it only warns when compile-only words are
>> encountered with ' or the interpreter, and as part of that, NAME>INTERPRET
>> has been changed not to return 0.
>
>You still can query the flags with
>> COMPILE-ONLY? ( nt -- flag ), so we could implement a NAME>INTERPRET which
>> returns 0 in that case.

I think the current approach (return the same value as ' does) is
better, for the same reasons that it is better to make these words
tickable and interpretable: It's more uniform, it's more traditional,
and it's easier to program for (no special-casing for 0 is necessary).

>So does NAME>INTERPRET return an xt that can be executed to do something 
>useful i.e. do something other than output a warning or throwing an 
>error.

If you NAME>INTERPRET or ' IF, you get the xt for the compilation
semantics of IF, and I think that's also the case for all the other
remaining compile-only words.  Likewise, if you text-interpret IF (in
either state), the text interpreter will perform the compilation
semantics (so they have all become immediate in every sense, not just
"immediate-but-...").  Example:

: foo [ if ] ." foo" then ; 
:1: warning: IF is compile-only ok
0 foo  ok
1 foo foo ok
: bar [ ' if execute ] ." bar" then ; 
:4: warning: IF is compile-only ok
0 bar  ok
1 bar bar ok

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#43983

On 30/11/2015 18:04, Anton Ertl wrote:
> Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>> On 30/11/2015 00:24, Bernd Paysan wrote:
>>> We recently changed Gforth so that it only warns when compile-only words are
>>> encountered with ' or the interpreter, and as part of that, NAME>INTERPRET
>>> has been changed not to return 0.
>>
>> You still can query the flags with
>>> COMPILE-ONLY? ( nt -- flag ), so we could implement a NAME>INTERPRET which
>>> returns 0 in that case.
>
> I think the current approach (return the same value as ' does) is
> better, for the same reasons that it is better to make these words
> tickable and interpretable: It's more uniform, it's more traditional,
> and it's easier to program for (no special-casing for 0 is necessary).
>
>> So does NAME>INTERPRET return an xt that can be executed to do something
>> useful i.e. do something other than output a warning or throwing an
>> error.
>
> If you NAME>INTERPRET or ' IF, you get the xt for the compilation
> semantics of IF, and I think that's also the case for all the other
> remaining compile-only words.  Likewise, if you text-interpret IF (in
> either state), the text interpreter will perform the compilation
> semantics (so they have all become immediate in every sense, not just
> "immediate-but-...").  Example:
>
> : foo [ if ] ." foo" then ;
> :1: warning: IF is compile-only ok
> 0 foo  ok
> 1 foo foo ok
> : bar [ ' if execute ] ." bar" then ;
> :4: warning: IF is compile-only ok
> 0 bar  ok
> 1 bar bar ok

Why would anyone want to do that when it is easier to write e.g.
: foo if ." foo" then ;

What happens then if someone types e.g.
if           \ or
' if execute
Does Gforth just issue a warning and then compile some code that is 
inaccesible and therefore useless? Also leaving control-flow information 
on the stack?

Is there a useful use case for interpreting a compile-only word which 
then executes its compilation semantics? These examples above just look 
silly.

So you make NAME>INTERPRET meaningful for words like IF by giving them 
some interpretation semantics that are in fact its compilation 
semantics, that aren't a lot of use in interpreter mode.

Personally I prefer IF to throw a -14 exception in interpreter mode. e.g.

' IF EXECUTE
            ^
Interpreting a compile-only word


-- 
Gerry

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

#43986

Gerry Jackson wrote:

>> : foo [ if ] ." foo" then ;
>> :1: warning: IF is compile-only ok
>> 0 foo  ok
>> 1 foo foo ok
>> : bar [ ' if execute ] ." bar" then ;
>> :4: warning: IF is compile-only ok
>> 0 bar  ok
>> 1 bar bar ok
> 
> Why would anyone want to do that when it is easier to write e.g.
> : foo if ." foo" then ;

Oh, just think a bit further.  Maybe you have a deferred word

defer ?debug immediate

: debug-on ['] if is ?debug ;

: skip-if  postpone drop postpone ahead ; immediate

: debug-off ['] skip-if is ?debug ;

And then you write something like

: bla ... ( flag ) ?debug ." Condition xxx happened" then ... ;

Of course, this will only work when IF is tickable and immediate.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

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

#44007

On 30/11/2015 21:59, Bernd Paysan wrote:
> Gerry Jackson wrote:
>
>>> : foo [ if ] ." foo" then ;
>>> :1: warning: IF is compile-only ok
>>> 0 foo  ok
>>> 1 foo foo ok
>>> : bar [ ' if execute ] ." bar" then ;
>>> :4: warning: IF is compile-only ok
>>> 0 bar  ok
>>> 1 bar bar ok
>>
>> Why would anyone want to do that when it is easier to write e.g.
>> : foo if ." foo" then ;
>
> Oh, just think a bit further.  Maybe you have a deferred word
>
> defer ?debug immediate
>
> : debug-on ['] if is ?debug ;
>
> : skip-if  postpone drop postpone ahead ; immediate
>
> : debug-off ['] skip-if is ?debug ;
>
> And then you write something like
>
> : bla ... ( flag ) ?debug ." Condition xxx happened" then ... ;
>
> Of course, this will only work when IF is tickable and immediate.
>

OK that's a use case and works in the recent Thanksgiving snapshot, but 
does IF have to be immediate there or skip-if?

It is not much more trouble to define:

: do-if postpone if ;
: debug-on ['] do-if is ?debug ;

which works in Gforth 0.7.9_20150825 on Windows 32 bit.

I wanted to try your original code in the latest GForth snapshot but it 
wouldn't install. (see reply to your announcement).

Anyway I'd rather do:

defer ?debug immediate
: debug-on  [: postpone if ;] is ?debug ;
: debug-off [: postpone drop postpone ahead ;] is ?debug ;
: bla ... ( flag ) ?debug ." Condition xxx happened" then ... ;

Which works in the previous snapshot which didn't permit ['] IF

Your (faked :-) quotations aren't yet in Forth 20XX though :-(

-- 
Gerry

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

#44038

On 30/11/2015 21:28, Gerry Jackson wrote:
> On 30/11/2015 18:04, Anton Ertl wrote:
>> Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>>> On 30/11/2015 00:24, Bernd Paysan wrote:
>>>> We recently changed Gforth so that it only warns when compile-only
>>>> words are
>>>> encountered with ' or the interpreter, and as part of that,
>>>> NAME>INTERPRET
>>>> has been changed not to return 0.
>>>
>>> You still can query the flags with
>>>> COMPILE-ONLY? ( nt -- flag ), so we could implement a NAME>INTERPRET
>>>> which
>>>> returns 0 in that case.
>>
>> I think the current approach (return the same value as ' does) is
>> better, for the same reasons that it is better to make these words
>> tickable and interpretable: It's more uniform, it's more traditional,
>> and it's easier to program for (no special-casing for 0 is necessary).
>>
>>> So does NAME>INTERPRET return an xt that can be executed to do something
>>> useful i.e. do something other than output a warning or throwing an
>>> error.
>>
>> If you NAME>INTERPRET or ' IF, you get the xt for the compilation
>> semantics of IF, and I think that's also the case for all the other
>> remaining compile-only words.  Likewise, if you text-interpret IF (in
>> either state), the text interpreter will perform the compilation
>> semantics (so they have all become immediate in every sense, not just
>> "immediate-but-...").  Example:
>>
>> : foo [ if ] ." foo" then ;
>> :1: warning: IF is compile-only ok
>> 0 foo  ok
>> 1 foo foo ok
>> : bar [ ' if execute ] ." bar" then ;
>> :4: warning: IF is compile-only ok
>> 0 bar  ok
>> 1 bar bar ok
>
> Why would anyone want to do that when it is easier to write e.g.
> : foo if ." foo" then ;
>
> What happens then if someone types e.g.
> if           \ or
> ' if execute
> Does Gforth just issue a warning and then compile some code that is
> inaccesible and therefore useless? Also leaving control-flow information
> on the stack?
>

Yes, I tried it since you didn't answer:

-------------
Gforth 0.7.9_20151126, Copyright (C) 1995-2015 Free Software Foundation, 
Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
' if execute .s
:1: warning: IF is compile-only<3> 0 2143238672 2  ok
drop 2drop  ok
here . 2143238676  ok
if ." inaccessible code" then .s
:4: warning: IF is compile-onlyinaccessible code
:4: warning: THEN is compile-only<0>  ok
here . 2143238684  ok
-------------

I see it displayed the message after the warning so I tried:

-------------
-1 if cr ." Should display" cr then .s
:16: warning: IF is compile-only
Should display

:16: warning: THEN is compile-only<1> -1  ok
drop  ok
   ok
0 if cr ." Should not display" cr then .s
:19: warning: IF is compile-only
Should not display

:19: warning: THEN is compile-only<1> 0  ok
-------------

So GForth interprets the line, compiling stuff because of the IF ... 
THEN, but the IF ... THEN are otherwise noops as far as the interpreting 
is concerned.

I realise that this is misusing IF and THEN and, from your previous 
description, I can understand the logic behind GForth doing this. But I 
think I'll stick with being able to tick IF and throwing an exception if 
IF's xt is executed, particularly as no convincing use case has been 
suggested as yet.
-- 
Gerry

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

#44088

Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>On 30/11/2015 21:28, Gerry Jackson wrote:
>> On 30/11/2015 18:04, Anton Ertl wrote:
>>> If you NAME>INTERPRET or ' IF, you get the xt for the compilation
>>> semantics of IF, and I think that's also the case for all the other
>>> remaining compile-only words.  Likewise, if you text-interpret IF (in
>>> either state), the text interpreter will perform the compilation
>>> semantics (so they have all become immediate in every sense, not just
>>> "immediate-but-...").  Example:
>>>
>>> : foo [ if ] ." foo" then ;
>>> :1: warning: IF is compile-only ok
>>> 0 foo  ok
>>> 1 foo foo ok
>>> : bar [ ' if execute ] ." bar" then ;
>>> :4: warning: IF is compile-only ok
>>> 0 bar  ok
>>> 1 bar bar ok
>>
>> Why would anyone want to do that when it is easier to write e.g.
>> : foo if ." foo" then ;

I did it to demonstrate what happens.

Other people want to ' IF and expect EXECUTEing that to perform the
compilation semantics of IF, because that's what they are used to from
classical implementations.  Sure, as you point out, one can define

: comp-if postpone if ; \ maybe immediate

and then ' COMP-IF to get the same effect in Forth-94/2012, but why
make them jump through hoops?  There have been several complaints
about Gforth's behaviour on ' IF etc. over the years, and that's one
factor in the decision.

More importantly, the deviation from the conventional
single-xt-with-immediate-flag model in the standard is spawning
abominations like VFX's "COMPILE," (which is not (but it should be)
equivalent to ": compile, postpone literal postpone execute ;") and
after two decades we are diverging rather than converging in that
area, so my thinking is that maybe we should converge on that old
model and replace everything that does not fit it (i.e., what people
try to do with STATE-smart words in that model) with better
alternatives.

>> What happens then if someone types e.g.
>> if           \ or
>> ' if execute
>> Does Gforth just issue a warning and then compile some code that is
>> inaccesible and therefore useless? Also leaving control-flow information
>> on the stack?

Yes and yes.

>So GForth interprets the line, compiling stuff because of the IF ... 
>THEN, but the IF ... THEN are otherwise noops as far as the interpreting 
>is concerned.

Yes.

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#43963

On 29/11/2015 22:44, peter.m.falth@gmail.com wrote:
>>> I now pass all the tests in the test suite except one.
>>> > >
>>> > >INCORRECT RESULT: \? T{ $" [']" FORTH-WORDLIST GET-NAME-TOKEN NAME>INTERPRET -> 0 }T
>>> > >
>>> > >But this I do not really consider a problem. Maybe this test should be deleted
>>> > >
>> >
>> >This test in file toolstest.fth is a new one as NAME>INTERPRET is a new
>> >word in Forth 2012. The specification says:
>> >------
>> >15.6.2.1909.20 NAME>INTERPRET "name-to-interpret" TOOLS EXT
>> >     ( nt - - xt | 0 )
>> >     xt represents the interpretation semantics of the word nt. If nt has
>> >     no interpretation semantics, NAME>INTERPRET returns 0.
>> >
>> >     Note: This standard does not define the interpretation semantics of
>> >     some words, but systems are allowed to do so.
>> >------
>> >The test is on a word that has no interpretation semantics. As the
>> >comments before the test indicate, this could be difficult due to the
>> >note in the specification. ['] was chosen because it has an
>> >interpretation equivalent ' in the hope that systems wouldn't have
>> >interpretation semantics for ['].
>> >   Assuming the test is correct, the fact it fails implies one of two things:
>> >
>> >1. that your system has interpretation semantics for ['] or
>> >2. your implementation of NAME>INTERPRET is incorrect.
>> >
>> >As the comments in the test program indicate, if 1. is the case then you
>> >could select another word that has no interpretation semantics to
>> >replace ['] in the test, if you have such a word. ; EXIT [CHAR] RECURSE
>> >are suggested as alternatives. If all your words have defined
>> >interpretation semantics then that test cannot be used in your system so
>> >it can be deleted.
>> >
> Both of my systems define interpretation semantics to all compile-only words
> in my 32 bit system all compile-only words return an interpretation xt that
> when executed prints an error message.

In that case the test is not applicable for your system so either 
comment it out or ignore the error message. I'll try to improve the test 
or delete it in the next release.

>
> In my new 64 bit system they simply return the compilation semantics also if
> executed while interpreting.
>
> I think definitely that this is allowed by the standard.

Yes the note in the specification for NAME>INTERPRET permits an xt to be 
returned. Does the xt do anything useful if EXECUTEd? If not then surely 
returning a 0 is better for a user.

>
> I could of course special-case NAME>INTERPRET to detect these and return 0
> for them. But what would this add other then complication
>

For the implementer, not the user. Of course if you are the only user it 
doesn't matter if you leave things as they are.


-- 
Gerry

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web