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

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

does VFX have the same bug as Gforth?

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

Contents

  does VFX have the same bug as Gforth? hughaguilar96@yahoo.com - 2014-08-17 21:09 -0700
    Re: does VFX have the same bug as Gforth? Bee <forth@calcentral.com> - 2014-08-17 23:06 -0700
      Re: does VFX have the same bug as Gforth? hughaguilar96@yahoo.com - 2014-08-18 17:03 -0700
        Re: does VFX have the same bug as Gforth? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-08-18 22:19 -0400
        Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-19 09:14 +0000
          Re: does VFX have the same bug as Gforth? Bernd Paysan <bernd.paysan@gmx.de> - 2014-08-19 15:23 +0200
            Re: does VFX have the same bug as Gforth? "Alex McDonald" <blog@rivadpm.com> - 2014-08-19 14:54 +0100
              Re: does VFX have the same bug as Gforth? Bernd Paysan <bernd.paysan@gmx.de> - 2014-08-19 16:09 +0200
                Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-19 15:39 +0000
                  Re: does VFX have the same bug as Gforth? Bernd Paysan <bernd.paysan@gmx.de> - 2014-08-19 22:34 +0200
                    Re: does VFX have the same bug as Gforth? "Alex McDonald" <blog@rivadpm.com> - 2014-08-19 23:29 +0100
                      Re: does VFX have the same bug as Gforth? Bernd Paysan <bernd.paysan@gmx.de> - 2014-08-20 23:06 +0200
                        Re: does VFX have the same bug as Gforth? "Alex McDonald" <blog@rivadpm.com> - 2014-08-20 22:21 +0100
                    Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-20 07:46 +0000
                      Re: does VFX have the same bug as Gforth? Bernd Paysan <bernd.paysan@gmx.de> - 2014-08-21 00:26 +0200
                        Re: does VFX have the same bug as Gforth? hughaguilar96@yahoo.com - 2014-08-20 22:42 -0700
                          Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-21 10:23 +0000
                            Re: does VFX have the same bug as Gforth? hughaguilar96@yahoo.com - 2014-08-21 23:29 -0700
                              Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-22 12:54 +0000
                                Re: does VFX have the same bug as Gforth? hughaguilar96@yahoo.com - 2014-08-22 17:54 -0700
                                  Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-23 10:46 +0000
                                    Re: does VFX have the same bug as Gforth? hughaguilar96@yahoo.com - 2014-08-23 11:15 -0700
                                      Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-24 13:32 +0000
                                        Re: does VFX have the same bug as Gforth? hughaguilar96@yahoo.com - 2014-08-24 10:40 -0700
                                          Re: does VFX have the same bug as Gforth? Bee <forth@calcentral.com> - 2014-08-24 22:03 -0700
                                          Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-25 08:31 +0000
                                            Re: does VFX have the same bug as Gforth? hughaguilar96@yahoo.com - 2014-08-25 22:55 -0700
                        Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-21 12:45 +0000
                        Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-22 15:13 +0000
                          Re: does VFX have the same bug as Gforth? Bernd Paysan <bernd.paysan@gmx.de> - 2014-08-22 18:47 +0200
                            Re: does VFX have the same bug as Gforth? hughaguilar96@yahoo.com - 2014-08-22 18:28 -0700
                              Re: does VFX have the same bug as Gforth? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-08-23 04:44 -0400
                              Re: does VFX have the same bug as Gforth? Coos Haak <chforth@hccnet.nl> - 2014-08-23 16:15 +0200
                              Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-23 11:50 -0500
                            Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-23 07:15 +0000
                              Re: does VFX have the same bug as Gforth? Bernd Paysan <bernd.paysan@gmx.de> - 2014-08-23 22:12 +0200
                                Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-24 03:51 -0500
                                  Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-24 13:36 +0000
                                    Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-25 04:16 -0500
                                      Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-25 09:44 +0000
                                        Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-25 11:53 -0500
                                          Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-26 06:34 +0000
                                            Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-26 03:55 -0500
                                              Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-26 12:37 +0000
                                                Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-26 08:24 -0500
                                                  Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-26 13:55 +0000
                                                    Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-26 10:42 -0500
                                                      Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-26 16:05 +0000
                                      Re: does VFX have the same bug as Gforth? Bernd Paysan <bernd.paysan@gmx.de> - 2014-09-23 17:20 +0200
                                        Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-23 11:29 -0500
                                          Re: does VFX have the same bug as Gforth? Bernd Paysan <bernd.paysan@gmx.de> - 2014-09-23 23:01 +0200
                                    Re: does VFX have the same bug as Gforth? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-08-25 15:59 +0000
                                      Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-26 06:23 +0000
                                        Re: does VFX have the same bug as Gforth? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-08-26 09:15 +0000
                                          Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-26 13:23 +0000
                                      Re: does VFX have the same bug as Gforth? Mark Wills <markwills1970@gmail.com> - 2014-08-26 01:41 -0700
                                        Re: does VFX have the same bug as Gforth? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-08-26 09:32 +0000
                                          Re: does VFX have the same bug as Gforth? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-08-26 09:43 +0000
                                          Re: does VFX have the same bug as Gforth? Mark Wills <markwills1970@gmail.com> - 2014-08-26 02:48 -0700
                                            Re: does VFX have the same bug as Gforth? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-08-26 11:58 +0000
                                              Re: does VFX have the same bug as Gforth? Mark Wills <markwills1970@gmail.com> - 2014-08-26 05:20 -0700
                                        Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-26 12:30 +0000
                                  Re: does VFX have the same bug as Gforth? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-08-25 14:15 +0000
                                    Re: does VFX have the same bug as Gforth? Mark Wills <markwills1970@gmail.com> - 2014-08-25 07:44 -0700
                                    Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-25 14:37 +0000
                                      Re: does VFX have the same bug as Gforth? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-08-25 15:14 +0000
                                        Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-25 15:33 +0000
                                      Re: does VFX have the same bug as Gforth? Mark Wills <markwills1970@gmail.com> - 2014-08-26 01:56 -0700
                                        Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-26 04:16 -0500
                                          Re: does VFX have the same bug as Gforth? Mark Wills <markwills1970@gmail.com> - 2014-08-26 02:24 -0700
                                          Re: does VFX have the same bug as Gforth? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-08-26 09:36 +0000
                                          Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-26 13:40 +0000
                                            Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-26 08:57 -0500
                                        Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-26 12:52 +0000
                                          Re: does VFX have the same bug as Gforth? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-08-26 14:14 +0000
                                            Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-26 14:36 +0000
                                              Re: does VFX have the same bug as Gforth? Bernd Paysan <bernd.paysan@gmx.de> - 2014-09-23 17:40 +0200
                                            Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-26 10:53 -0500
                                            Re: does VFX have the same bug as Gforth? Bernd Paysan <bernd.paysan@gmx.de> - 2014-09-23 17:36 +0200
                                    Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-25 12:02 -0500
                                      Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-26 06:42 +0000
                                        Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-26 04:08 -0500
                                          Re: does VFX have the same bug as Gforth? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-08-26 10:37 +0000
                                            Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-26 08:30 -0500
                                            Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-28 08:47 -0500
                                              Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-29 13:03 +0000
                                                Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-29 09:16 -0500
                                          Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-26 13:06 +0000
                                    Re: does VFX have the same bug as Gforth? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-08-26 07:36 -0400
                                    Re: does VFX have the same bug as Gforth? Bernd Paysan <bernd.paysan@gmx.de> - 2014-09-23 17:28 +0200
                                Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-24 09:48 +0000
                                Re: does VFX have the same bug as Gforth? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-08-24 15:55 -0400
                            Re: does VFX have the same bug as Gforth? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-08-24 15:55 -0400
                              Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-25 08:26 +0000
                                Re: does VFX have the same bug as Gforth? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-08-26 07:36 -0400
                                  Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-26 12:12 +0000
                                    Re: does VFX have the same bug as Gforth? Bernd Paysan <bernd.paysan@gmx.de> - 2014-09-23 17:45 +0200
                      Re: does VFX have the same bug as Gforth? Mark Wills <markwills1970@gmail.com> - 2014-08-21 03:25 -0700
                        Re: does VFX have the same bug as Gforth? hughaguilar96@yahoo.com - 2014-08-21 23:14 -0700
              Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-19 14:16 +0000
    Re: does VFX have the same bug as Gforth? Bee <forth@calcentral.com> - 2014-08-17 23:16 -0700
      Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-19 09:40 +0000
    Re: does VFX have the same bug as Gforth? Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-08-18 09:16 +0100
    Re: does VFX have the same bug as Gforth? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-08-18 09:32 +0100
      Re: does VFX have the same bug as Gforth? "Alex McDonald" <blog@rivadpm.com> - 2014-08-18 13:09 +0100
    Re: does VFX have the same bug as Gforth? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-08-18 12:29 +0000
      Re: does VFX have the same bug as Gforth? hughaguilar96@yahoo.com - 2014-08-18 17:10 -0700
        Re: does VFX have the same bug as Gforth? Bee <forth@calcentral.com> - 2014-08-18 17:48 -0700
          Re: does VFX have the same bug as Gforth? hughaguilar96@yahoo.com - 2014-08-18 18:23 -0700
        Re: does VFX have the same bug as Gforth? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-08-19 13:55 +0100

Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6  Next page →

#33017

hughaguilar96@yahoo.com writes:
>On Friday, August 22, 2014 5:54:37 AM UTC-7, Anton Ertl wrote:
>> hughaguilar96@yahoo.com writes:
>> >On Thursday, August 21, 2014 3:23:42 AM UTC-7, Anton Ertl wrote:
>> >> hughaguilar96@yahoo.com writes:
>> >> You can check in Forth-94 with SEARCH-WORDLIST whether a word is in a
>> >> specific wordlist.
>>=20
>> >I already said that it is inefficient to search the entire dictionary to=
> fi=3D
>> >nd the xt (which is what SEARCH-WORDLIST does).
>>=20
>> SEARCH-WORDLIST searches one wordlist, not the entire dictionary, and
>>=20
>> I expect that search to be efficient (it certainly is in Gforth).
>
>If the point is to find out which word-list the xt was defined in, then how=
> do I know which word-list to search?

I don't, but that's not the problem you wanted to solve (check whether
the word is in a specific wordlist), unless I misunderstood your
problem description.

But if you want to find out which wordlist(s) an xt was defined in,
then yes, there is no more efficient way in Gforth than searching all
the wordlists.

>> Given that you first get the xt with FIND or ' (which searches the
>> whole search order), the check with SEARCH-WORDLIST will only add a
>> small constant factor to the overall cost.
>
>Assuming that the searches are done in the same way, which is likely, then =
>doing two searches rather than one will double the cost.

As I wrote: A small constant factor.  BTW, in Gforth FIND will usually
be more expensive, because it searches several wordlists.

>
>> If that's too inefficient for your taste, you have the option to stick
>> with UR/Forth.  If would be interesting to the overall speed
>> difference between UR/Forth (using the wid-in-header feature) and
>> Gforth (using SEARCH-WORDLIST) for the thing you want to do.
>
>For one thing, UR/Forth had >NAME and ANS-Forth doesn't, so how are you goi=
>ng to compare them? If you do get >NAME (VFX has it), then a comparison can=
> be made. I just extract the voc-no from the header directly, so this is a =
>matter of a few instructions. Any kind of search done on the entire diction=
>ary looking for a match of the xt, is going to be orders of magnitude slowe=
>r.=20
>
>If you want an overall comparison of speed of UR/Forth code to Gforth, I do=
>n't know how that would come out.

Gforth has >NAME, but no voc-no in headers.  And the question was
about the overall speed for the whole macro thing you are trying to
do.

>> Gforth has one hash table for all word lists, but it does not store
>> the wid for each word in that word's header.  Words with the same name
>> in different wordlists are guaranteed to be in different hash buckets
>> from the way we construct the hash value, so there is no need to
>> compare the wids; if we find the word in that bucket, it is guaranteed
>> to be in the wordlist we are searching.
>
>I don't understand this at all. UR/Forth just prepended the voc-no onto the=
> front of the name before doing the search of the hash-table.=20

And Gforth doesn't.  Instead it xors or adds the wordlist number to
the hash value.

- 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 2014: http://www.euroforth.org/ef14/

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

#33022

On Saturday, August 23, 2014 3:46:31 AM UTC-7, Anton Ertl wrote:
> hughaguilar96@yahoo.com writes:
> >If the point is to find out which word-list the xt was defined in, then how=
> > do I know which word-list to search?
> 
> I don't, but that's not the problem you wanted to solve (check whether
> the word is in a specific wordlist), unless I misunderstood your
> problem description.

I said that I want to take an xt, and find out what word-list it was defined in.

This is for error-checking in a cross-compiler. In my experience, when things go really haywire, it is because words from the wrong word-list are being used. Debugging this is a nightmare, because the behavior of the system becomes really bizarre and it is not clear when or where the problem began. This is why I put in the error-checking in MFX to check every word for being in the proper word-list --- after I did this, debugging became easy and progress on MFX was fast --- bugs that had previously taken days to figure out were found and fixed in minutes. You don't do this???

> Gforth has >NAME, but no voc-no in headers.  And the question was
> about the overall speed for the whole macro thing you are trying to
> do.

>NAME is not ANS-Forth. If we are going to abandon ANS-Forth portability to write a cross-compiler, why not go whole hog?

> >> Gforth has one hash table for all word lists, but it does not store
> >> the wid for each word in that word's header.  Words with the same name
> >> in different wordlists are guaranteed to be in different hash buckets
> >> from the way we construct the hash value, so there is no need to
> >> compare the wids; if we find the word in that bucket, it is guaranteed
> >> to be in the wordlist we are searching.
> 
> >I don't understand this at all. UR/Forth just prepended the voc-no onto the=
> > front of the name before doing the search of the hash-table.=20
> 
> And Gforth doesn't.  Instead it xors or adds the wordlist number to
> the hash value.

I still don't understand this at all!!! You have to have the wid (voc-no) available to XOR or ADD it to the hash value, so where are you getting it except from the word's header???

It is a trivial distinction whether you prepend the wid onto the name and then calculate your hash-value, or XOR the wid onto the hash-value after calculating it --- either way, you have to have the wid available, and it had to come from the word's header.

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

#33028

hughaguilar96@yahoo.com writes:
>On Saturday, August 23, 2014 3:46:31 AM UTC-7, Anton Ertl wrote:
>> And Gforth doesn't.  Instead it xors or adds the wordlist number to
>> the hash value.
>
>I still don't understand this at all!!! You have to have the wid (voc-no) a=
>vailable to XOR or ADD it to the hash value, so where are you getting it ex=
>cept from the word's header???

On insert, from the wordlist that we are inserting into (i.e., the
CURRENT wordlist).

On lookup, from the wordlist that we are searching (i.e., the wid
parameter of SEARCH-WORDLIST).

- 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 2014: http://www.euroforth.org/ef14/

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

#33030

On Sunday, August 24, 2014 6:32:44 AM UTC-7, Anton Ertl wrote:
> hughaguilar96@yahoo.com writes:
> >On Saturday, August 23, 2014 3:46:31 AM UTC-7, Anton Ertl wrote:
> >> And Gforth doesn't.  Instead it xors or adds the wordlist number to
> >> the hash value.
> 
> >I still don't understand this at all!!! You have to have the wid (voc-no) a=
> >vailable to XOR or ADD it to the hash value, so where are you getting it ex=
> >cept from the word's header???
 
> On insert, from the wordlist that we are inserting into (i.e., the
> CURRENT wordlist).

This is obvious.

> On lookup, from the wordlist that we are searching (i.e., the wid
> parameter of SEARCH-WORDLIST).

This is the problem area.

With your method, if there is a word with that name in the word-list being searched, then it will be found, but it may not be correct. I think that what you are getting at, is that after you find it, you compare its header with the header that you got earlier with >NAME and if they are the same then you are good. If not, then you have to search another word-list and do the same thing. You continue doing this until you succeed --- that is, find a header in the word-list with that name, and find that it is the same header that you obtained originally with >NAME.

My experience with ANS-Forth is that everything is overly complicated and grossly inefficient, and that Forth-200x is worse. The above is an obvious example. Why not just hold the wid in the header and have a word for extracting it? That would be so simple. It is just one byte. Also, why didn't >NAME make it into the standard? Both Gforth and VFX have it, so you must have known that it was needed.

ANS-Forth seems to lack support for cross-compiling. I get the impression that ANS-Forth was designed by people who had never written a cross-compiler, and just vaguely assumed that a cross-compiler doesn't need any special support, but that it is as easy as any application program. The result now, is that every cross-compiler written is vendor-specific (MFX is specific to UR/Forth) because the author had to use non-standard words like >NAME etc.. So, once again, what was the point of having a standard at all?

BTW: Who has ever used any of that word-list stuff anyway? Has anybody ever written a program that needed anything more than Forth-83's simple system with CONTEXT and CURRENT? This is all that I used in MFX, and MFX is the only program I ever wrote that used more than one vocabulary. Vocabularies were originally designed to allow assemblers (and the obsolete line-editor) that had name clashes with the main vocabulary (FORTH), and the Forth-83 system (which was the same as FIG and Forth-79) was adequate for this. Also, the term "vocabulary" is so much more descriptive than "word-list" --- why the terminology change? --- were you trying to sound computer-sciency?

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

#33033

On Sunday, August 24, 2014 10:40:27 AM UTC-7
hughaguilar96@yahoo.com wrote:

>BTW: Who has ever used any of that word-list stuff anyway?

I have many times.

>Has anybody ever written a program that needed anything
>more than Forth-83's simple system with CONTEXT and CURRENT?

Yes, I have many times.

One very interesting use of word-lists (aka vocabularies)
I extend them to select different banks of rom (or ram)
for VERY large applications on a small (circa z80) processor.

We ran out of program space for a piece of test equipment.
I extended the 'vocabulary' structure to not only select
a particular set of test words, but also to bank selected memory.
Word-lists were shorter, compilation was faster.

It worked a charm, saved the project, I got paid.

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

#33035

hughaguilar96@yahoo.com writes:
>With your method, if there is a word with that name in the word-list being =
>searched, then it will be found, but it may not be correct. I think that wh=
>at you are getting at, is that after you find it, you compare its header wi=
>th the header that you got earlier with >NAME and if they are the same then=
> you are good.

With the problem you sketched, I would just compare the xts.

> If not, then you have to search another word-list and do the=
> same thing. You continue doing this until you succeed --- that is, find a =
>header in the word-list with that name, and find that it is the same header=
> that you obtained originally with >NAME.

Why would I do that if I just want to check whether the xt is in a
specific wordlist (the sketched problem)?

> Also, t=
>he term "vocabulary" is so much more descriptive than "word-list" --- why t=
>he terminology change? --- were you trying to sound computer-sciency?

Aparently different Forth systems had different meanings for
VOCABULARY (and consequently for "vocabulary"), so like for NOT, this
word and the related term could not be standardized.  So another word
and its related term were introduced: WORDLIST.

- 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 2014: http://www.euroforth.org/ef14/

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

#33053

On Monday, August 25, 2014 1:31:21 AM UTC-7, Anton Ertl wrote:
> hughaguilar96@yahoo.com writes:
> >With your method, if there is a word with that name in the word-list being =
> >searched, then it will be found, but it may not be correct. I think that wh=
> >at you are getting at, is that after you find it, you compare its header wi=
> >th the header that you got earlier with >NAME and if they are the same then=
> > you are good.
> 
> With the problem you sketched, I would just compare the xts.
> 
> > If not, then you have to search another word-list and do the=
> > same thing. You continue doing this until you succeed --- that is, find a =
> >header in the word-list with that name, and find that it is the same header=
> > that you obtained originally with >NAME.
> 
> Why would I do that if I just want to check whether the xt is in a
> specific wordlist (the sketched problem)?

Why do you keep saying that I sketched a problem of checking whether an xt is in a specific word-list? I have repeatedly said that I want to find out which word-list the xt is in --- that is what my extension to UR/Forth did --- and that is what you would get if the wid was stored in the header and there was a word for extracting it (and >NAME was available to provide the header).

I suppose that the error-checking could get by with just checking if the xt is in a specific word-list, without finding out which word-list it is in, because there is a correct word-list for it to be in --- but this would make the error message less informative. I never gave this any thought, because in UR/Forth it was simple and easy to find out what voc-no was in the header --- I am very frustrated with ANS-Forth and Forth-200x, because nothing is ever simple and easy, but you seem to make an effort to do everything in the most complicated and inefficient way possible.

> > Also, t=
> >he term "vocabulary" is so much more descriptive than "word-list" --- why t=
> >he terminology change? --- were you trying to sound computer-sciency?
> 
> Aparently different Forth systems had different meanings for
> VOCABULARY (and consequently for "vocabulary"), so like for NOT, this
> word and the related term could not be standardized.  So another word
> and its related term were introduced: WORDLIST.

I recall vocabularies being pretty well standardized in Forth-83 --- but lets not debate Forth-83 --- debating ANS-Forth is already giving me a headache.

Ultimately, these debates go nowhere. You are not going to implement my suggestion for error-checking the wid on an xt in a cross-compiler --- you are not going to implement anything unless Leon Wagner tells you to --- and nobody at Forth Inc. is writing code like I write, so he isn't going to. The same thing was true in regard to what I said about using the data stack as the control stack --- unless somebody starts writing meta-compiling words, I will continue to be the only one who notices the problem. Same thing with ALLOCATION, etc..

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

#32992

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> Given that there is no consent between implementors on what ['] EXIT
>> should mean, it's unlikely to get in, and there is no proposal for
>> including ['] EXIT in a future standard, either.
>
>Hm, if I understand the test correctly, 4 out of 5 systems had a consent on 
>what ['] EXIT COMPILE, means, and the only dissenting oppinion is Anton 
>Ertl's.  Which does not really break consent.

I don't think there is consensus among the maintainers of the 4
systems, they just happen to work that way.  Maybe if they talked
about it, they would find consensus among them.  But the last time
this was discussed, the outcome was that ['] EXIT is non-standard.

>> Anyway, to make your code above work, you would also need to change
>> COMPILE, in an incompatible way, and we have learned from bad
>> experiences in the past (e.g., NOT) that this is a very bad idea.
>
>It has already been changed in several Forth systems, and apparently not 
>caused user complaints.  While not being able to ' EXIT has caused people to 
>complain, several times.  This is just one case.  Do you take bug reports 
>like that serious or do you close them with Ulrich Drepper "invalid, as the 
>standard allows me to be a dick, and break your program" reason?

I don't remember seeing a bug report on this.

If we had chosen to produce an xt for immediate compile-only words, it
would have been the same xt as if the word was not compile-only; this
is closest to the traditional behaviour (for, say, words like IF).
For ['] EXIT COMPILE, in Gforth, the second test would have produced
"a", not "b" like the other systems.

>That's the way we want it from the GCC team.  We should live by our 
>standards.

No, I don't want gcc to silently produce a possible unexpected answer.
If there is something possibly unexpected (such as an immediate
compile-only EXIT), I want the compiler to make me aware of that.  And
Gforth does so, by reporting an error when you tick EXIT.

xts are also to be EXECUTEable, and there are big differences between
the systems when EXECUTEing the xt of EXIT.

>> In
>> no existing Forth system COMPILE, works the way you want it to;
>
>It works that way in three Forth systems.

You wanted

: exit postpone exit ; immediate

to behave the same way as the builtin EXIT with ['] EXIT COMPILE,.
None of the five systems I tested do this.  Which three Forth systems
are you talking about?

>> In contrast, ['] EXIT does not work on all Forth systems, and behaves
>> differently in different Forth systems where it does not produce an
>> error.
>
>Well, let's see:
>
>> As your example shows, what makes sense (if you can tick EXIT) depends
>> on the way that EXIT is implemented.  If it is implemented as
>> IMMEDIATE word, then it makes sense to EXECUTE the xt in COND,.
>> 
>> I tried the following code on iforth-2.1, vfxlin 4.60,
>> SwiftForth 3.4.4, Gforth 0.7.0, and bigFORTH 2.3.1:
>> 
>> : bla ['] exit execute ." x" ; bla
>> 
>> iForth outputs nothing.
>> vfxlin produces an error -14 when BLA executes.
>> sf outputs "x".
>> gforth produces an error -14 when ['] executes.
>> bigforth outputs "x".
>> 
>> Not very much portability here.
>
>As EXIT has no interpretation semantics, it is quite easy to see why 
>executing the returning xt does not lead to something useful.
>
>> Next test:
>> : x ['] exit compile, ; immediate : a x ." a" ; immediate : b a ." b" ; b
>> 
>> iforth outputs "b".
>> sf outputs "b".
>> vfxlin outputs "b".
>> gforth produces an error -14 when ['] executes.
>> bigforth outputs "b".
>> 
>> Four of these systems make "['] exit compile," behave like POSTPONE
>> EXIT (e.g., by implementing EXIT as a word with default compilation
>> semantics (something like +)).
>
>Yes, that's what a user would expect from EXIT - it has no interpretation 
>semantics, so it can't be EXECUTEd, but it has compilation semantics, so 
>COMPILE, maybe can do something with it.

That may be what you expect from it.  It's completely at odds with
what I expect from it.  More importantly, it's also at odds with the
specification of EXECUTE and COMPILE,; no "interpretation semantics"
or "compilation semantics" occurs in these specifications.

>It still might be immediate, but 
>apparently, 4 out of 5 Forth systems found a way to have a non-immediate 
>EXIT.

Sure, the traditional implementation of EXIT is the same as the Gforth
primitive ";s", and ";s" behaves that way on words without locals.
And there's a way to keep that implementation in the presence of
locals, it just makes locals less efficient.

>In Gforth git head, you can define it easily:
>
>:noname drop postpone exit ;
>: exit  -14 throw ; set-compiler
>
>And then suddenly, gforth also outputs "b".

Yes, we have agreed that you can do all sorts of things with the new
headers, including things that we both agree are bad ideas.  So
showing that you can make Gforth behave like VFX does not prove
anything.

>> Now a way to get a guaranteed tickable EXIT is to redefine it (all
>> words defined by the user in standard Forth have interpretation
>> semantics and are therefore tickable):
>> 
>> : exit postpone exit ; immediate
>> 
>> But as you point out, this changes what "['] exit compile," does:
>> 
>> : exit postpone exit ; immediate : x ['] exit compile, ; immediate : a x
>> : ." a" ; immediate : b a ." b" ; b
>> 
>> iforth outputs "a".
>> sf outputs "a".
>> vfxlin outputs "a".
>> gforth outputs "a".
>> bigforth outputs "a".
...
>Yes, this means that the standard does not allow the user to define a 
>reasonably derived version of EXIT.  That's because the standard has poor 
>tools for defining such words.  IMMEDIATE is a pretty crappy solution.

I find it good enough for words like EXIT, but then I don't tick EXIT.
It's not good enough for words like S", but these words are not such a
good idea anyway.

>> Maybe your
>> next argument is that this redefinition of EXIT is wrong, and we
>> should either not use it (but what else?) or change it's meaning along
>> with the meaning of "COMPILE,", but my conclusion is that ['] EXIT is
>> just a bad idea.  As for "the only thing that makes sense", thinging
>> about these examples I did not get the feeling that COMPILE, makes
>> more or less sense than EXECUTE for ['] EXIT.
>
>But COMPILE, did work 4 out of 5 cases, and the case it didn't work is the 
>one which is implemented following your oppinion, and it can easily be 
>fixed.  So if you exclude the one dissenting voice, there's a consent.

I think that just happens to be a coincidence of the way that EXIT is
implemented in these systems (i.e., many implement it as ;s).  If we
try the same for, say, IF, another standard word without
interpretation semantics, my guess is that the results will be
different.  Let's try it: According to you ['] IF COMPILE, should
perform the compilation semantics of IF, right?  So let's see if this
works:

: f ['] if compile, ; immediate : g f ." a" else ." b" then ; 0 g

iforth gives an error -22 "Structure not balanced ?"
sf gives an error "Control structure mismatch"
vfxlin outputs "b" (the result you expect)
gforth gives an error "Cannot tick compile-only word [...]"
bigforth gives an error "unstructured else"

So, no, there is no common practice that ['] <word> COMPILE, performs
the compilation semantics of <word>, even if you exclude Gforth.  And
there certainly is no consensus.

>>>The way a standard process works means that we probably need to change the
>>>definition of COMPILE, because it no longer reflects a consent within the
>>>Forth community.
>> 
>> The definition of "consent" is not "Bernd Paysan's opinion".  Also, a
>> single dissenting opinion does not dissolve consent.
>
>That's certainly a nonsense argument, because the dissenting COMPILE, is 
>already in VFX, in Gforth git head, and in Win32Forth (in the STC version).

If Gforth's COMPILE, is buggy, it will be fixed.  I cannot speak for
the other systems.

>And the straw mens you are errecting to prove 
>that this COMPILE, is going to cause problems are not conclusive.  Your 
>point is that this COMPILE, is going to break code like Mini-OOF if you 
>define a new word with special compilation semantics (with SET-COMPILER), 
>and assign it to a method.  Yes, this is going to break Mini-OOF.  However, 
>as SET-COMPILER is new, it's not going to break legacy Mini-OOF programs, 
>because they simply can't do that (there wasn't a SET-COMPILER when they had 
>been written, and words like EXIT weren't tickable).  And the old words with 
>special compilation semantics like S" still use the dual-xt approach (in the 
>git head Gforth, not in VFX), which doesn't cause this problem.

When considering new features, you need to make sure that they fit
with the existing features.  You want to be able to combine libraries
using the new features with libraries using the old features (such as
mini-OOF).  If a proposed feature like SET-COMPILER breaks an existing
feature like the EXECUTE/COMPILE, relation, that's a strong reason for
rejecting the proposal.  And I don't see an equally strong reason for
SET-COMPILER, not by far.

>To illustrate what kind of problem we are talking about, I've done this in 
>VFX:
>
>variable foo  ok
>: [foo] foo @ execute ;  ok
>: foo, foo @ compile, ;  ok
>' s" foo !  ok
>[foo] bla" type bla ok
>: test [ foo, bla" ] type ;  ok
>test bla ok
>
>And that's how you are supposed to use this in Gforth:
>
>variable foo  ok
>: [foo] foo @ execute ;  ok
>: foo, foo @ compile, ;  ok
>' s" foo !  ok
>[foo] bla" type bla ok
>: test [ foo, ] type ;  ok  
>test bla" bla ok
>
>Certainly, this is not portable *now*.  I can't imagine that Stephen will 
>change VFX, this COMPILE, is a central feature, and convincing him to use 
>the ugly FIND will be difficult.

Gforth works according to the specification.  If Stephen wants to keep
this bug in VFX, that's his decision.  As long as this only concerns
S" and a few similar words, this bug is of little practical
consequence.

Of course, if we don't want to add more such words, we don't need
SET-COMPILER.  If we want to add more such words, this bug may become
practically relevant.

>> I don't see enough value in standardizing this "feature" to sacrifice
>> the COMPILE,-EXECUTE relation for it.  Also, even if I was not in
>> play, I have my doubts that you will get consent among implementors.
>> After all, this requires standardizing things about the implementation
>> that they have been very reluctant to standardize.
>
>Yes.  But Stephen actually started convincing others to do so, and he 
>succeeded.  The idea that it's my proposal is silly; I jumped late on this 
>smart COMPILE, bandwagon.  Win32Forth STC already had it, you made a posting 
>proposing that, and Stephen gave a talk at a EuroForth, and then I was 
>convinced.

I wrote about intelligent COMPILE,, and we have had an intelligent
COMPILE, in Gforth since about 2001 (although the implementation is
not elegant).  The point is that the intelligent COMPILE, allows a
more efficient implementation of the semantics represented by the xt,
not a different semantics.

In my "header structure ideas" posting
<http://www.complang.tuwien.ac.at/forth/header-ideas.html>, there is
the comp field for that purpose.  The compilation semantics is a
different thing from what an intelligent COMPILE, does, and in my
header ideas the xt2 field is there for providing (the rest of) the
compilation semantics.  There are two fields for these two purposes in
these header structure ideas for a reason, not because I thought it
would be cool to waste cell per word.  VFX does not make the
difference, resulting in the bug you demonstrate above.

>This is nothing new, this has been in VFX for ages (and with 
>"ages" I mean really right from start).  This is known to work with the 1 
>million lines of CCS, and it also works with the 500 lines of guru code in 
>BerndOOF.  There's very little which survives both tests

Well, by that criterion, STATE-smartness has no problems.  It worked
for the CCS code, and also for the code you wrote.  No, that does not
convince me in the least.

>> My other idea is to get rid of words that have both interpretation
>> semantics and non-default non-immediate compilation semantics (S", TO,
>> IS ...).  Then we really just have one xt per word,
>
>That has been implemented with recognizers in Gforth git head.  This however 
>means that you have to remove several words from the standard... that's not 
>going to happen too quickly.  We might get an RFD for recognizes soon, 
>though.

Right, that's a long process.

>>>But that approach breaks the "user-implemented text
>>>interpreter", which was the motivation of Mitch Bradley to introduce
>>>COMPILE, at all.
>> 
>> It does not.  The user-defined text interpreter works fine with the
>> currently-standard COMPILE,.  Ok, it needs an ugly FIND, but that
>> uglyness is a bastard of words like S" and FIND; trying to make FIND
>> less ugly by breaking COMPILE, is a bad idea.
>
>Yes, but the ugly FIND is an "Anton Ertl's oppinion", nobody else in the set 
>of the 5 Forths you tested has implemented the ugly FIND.  They all have a 
>FIND which doesn't depend on STATE.  It's still ugly, because it takes a 
>counted string, but that can be fixed easily.

3 of these systems shift the uglyness to words like S" by implementing
them in a STATE-smart way.  And VFX avoids the ugly FIND by breaking
COMPILE,.

>> No from me for the change to COMPILE,.
>
>The change already happened in several popular Forth systems.  I'm just 
>describing reality.  You can continue to ignore reality (apparently you are 
>doing that, because you say that this new COMPILE, is my oppinion only, 
>instead of researching how many systems actually do it that way).  But a 
>standard usually codifies existing practice, and this practice already 
>exists.  If your system doesn't have a SET-COMPILER, the COMPILE, behaves as 
>it used to be.  If it has, it behaves differently - on words where SET-
>COMPILER has been used.

Ok, then no to SET-COMPILER, too.

In my reposting of the posting you replied to (somehow I did not see
it getting posted), I added the following, less-time-pressed response
to your proposal:

|Then what COMPILE, does for the xts of these words (if the system
|produces such xts) depends on the system, so for the example you gave,
|nothing is won.
|
|Overall, I don't like this proposal: If SET-COMPILER and words defined
|with SET-COMPILER are used frequently enough to merit their inclusion
|in the standard, the damage your proposed change to COMPILE, does to
|the COMPILE,/EXECUTE relation is not just a contrived corner case, but
|becomes practically relevant.
|
|I also doubt that you will find consensus among other Forth system
|implementors to standardize SET-COMPILER; it requires changes deep in
|the system, and system implementors are often quite reluctant about
|such features.

>This change on the other hand fixes something in Forth, which is really 
>ugly: state smart words.  It doesn't fix them in the way you want to, but 
>your solution just moves the uglyness to FIND, and therefore, none of the 
>other impementers of popular systems wants to follow you.  And the new 
>COMPILE, solution doesn't have the drawbacks.

If does not fix the problem.  Instead, it moves it from a little-used
words (I hardly ever use FIND) to much more frequently-used words (I
use EXECUTE and COMPILE, frequently).  It's a very bad idea.

- 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 2014: http://www.euroforth.org/ef14/

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

#33008

Bernd Paysan <bernd.paysan@gmx.de> writes:
>The idea that it's my proposal is silly; I jumped late on this 
>smart COMPILE, bandwagon.  Win32Forth STC already had it, you made a posting 
>proposing that, and Stephen gave a talk at a EuroForth, and then I was 
>convinced.  This is nothing new, this has been in VFX for ages (and with 
>"ages" I mean really right from start).  This is known to work with the 1 
>million lines of CCS, and it also works with the 500 lines of guru code in 
>BerndOOF.  There's very little which survives both tests, and BerndOOF is 
>actually of the class *you* think would fail.
...
> We can ask Stephen, how much code breakage he 
>has observed.

As it turns out, no need to ask around, just in the thread next door
<lt79f6$b0o$1@dont-email.me> we get to see breakage from VFX's
"COMPILE,", and in the core of VFX as well:

: [cif] [COMPILE] IF ; IMMEDIATE 
Err# -22 ERR: Control structure mismatch.
 -> : [cif] [COMPILE] IF ; IMMEDIATE

How does COMPILE, come into play?  Look here:

see [compile] 
[COMPILE] (is IMMEDIATE) 
( 08058398    E897FFFFFF )            CALL      08058334        '
( 0805839D    E8EEE7FFFF )            CALL      08056B90        COMPILE,
( 080583A2    C3 )                    NEXT,
( 11 bytes, 3 instructions )

- 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 2014: http://www.euroforth.org/ef14/

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

#33010

Anton Ertl wrote:

> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>The idea that it's my proposal is silly; I jumped late on this
>>smart COMPILE, bandwagon.  Win32Forth STC already had it, you made a
>>posting proposing that, and Stephen gave a talk at a EuroForth, and then I
>>was
>>convinced.  This is nothing new, this has been in VFX for ages (and with
>>"ages" I mean really right from start).  This is known to work with the 1
>>million lines of CCS, and it also works with the 500 lines of guru code in
>>BerndOOF.  There's very little which survives both tests, and BerndOOF is
>>actually of the class *you* think would fail.
> ...
>> We can ask Stephen, how much code breakage he
>>has observed.
> 
> As it turns out, no need to ask around, just in the thread next door
> <lt79f6$b0o$1@dont-email.me> we get to see breakage from VFX's
> "COMPILE,", and in the core of VFX as well:
> 
> : [cif] [COMPILE] IF ; IMMEDIATE
> Err# -22 ERR: Control structure mismatch.
>  -> : [cif] [COMPILE] IF ; IMMEDIATE
> 
> How does COMPILE, come into play?  Look here:
> 
> see [compile]
> [COMPILE] (is IMMEDIATE)
> ( 08058398    E897FFFFFF )            CALL      08058334        '
> ( 0805839D    E8EEE7FFFF )            CALL      08056B90        COMPILE,
> ( 080583A2    C3 )                    NEXT,
> ( 11 bytes, 3 instructions )

Yes, taking away immediacy of words you expect to be immediate is bound to 
cause problems with words like [COMPILE], which assume that the user knows 
whether the word is immediate or not (which is a bad idea).

That's why POSTPONE was invented.  I don't quite understand why [COMPILE] 
was left in the standard, it's impossible to use correctly given that the 
standard doesn't tell which words are immediate and which aren't (with a few 
exceptions).

If you look at the definition of [COMPILE] in Gforth, you see that there's 
an obvious way to fix [COMPILE] in VFX:

: [compile] ( compilation "name" -- ; run-time ? -- ? ) \ core-ext bracket-
compile
    comp' drop
    dup [ comp' exit drop ] literal = if
	execute \ EXIT has default compilation semantics, perform them
    else
	compile,
    then ; immediate

Yeah, there's a special casing for EXIT, because people using [COMPILE] will 
assume EXIT to be non-immediate, so we "cheat".  VFX should cheat the same 
way, and have a small case statement with all the words users expect to be 
immediate.  As [COMPILE] is there for legacy code, with a very well-defined 
expectation of what it should do (just look at the Forth-83 standard which 
words are marked immediate), it's doable.

So the assumption that [COMPILE] is something simple doesn't hold if you 
deviate from the Forth-83 or Forth-79 standard with respect to immediacy of 
certain words.

In effect, the way [COMPILE] is written renders the entire semantics stuff 
null and void: It means that there is a direct relation from the immediate 
and compile-only flag to the way the word's description is structured: no 
interpretation semantics: compile-only.  Non-default compilation semantics: 
immediate.  Default compilation semantics: non-immediate.  As Gforth mostly 
follows the fig-Forth model, this is true for Gforth (with the excepton of 
EXIT).

BTW: There's no use of [compile] as a standard word in the entire Gforth 
source code (the cross compiler's [compile] doesn't count, because it does 
something different: It works for forward references, while postpone doesn't 
and can't), which makes the word of dubious quality.

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

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

#33014

On Friday, August 22, 2014 9:47:39 AM UTC-7, Bernd Paysan wrote:
> Anton Ertl wrote:
> Yes, taking away immediacy of words you expect to be immediate is bound to 
> cause problems with words like [COMPILE], which assume that the user knows 
> whether the word is immediate or not (which is a bad idea).
> 
> That's why POSTPONE was invented.  I don't quite understand why [COMPILE] 
> was left in the standard, it's impossible to use correctly given that the 
> standard doesn't tell which words are immediate and which aren't (with a few 
> exceptions).

SwiftForth doesn't support [COMPILE] so it is not fully ANS-Forth compliant.

This doesn't bother me. I don't know why [COMPILE] is in the standard either. I have never used it in ANS-Forth. I don't know why it would be used instead of POSTPONE. I assumed that you would know. If you don't know, and Elizabeth Rather doesn't know, then who would know?

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

#33016

On Fri, 22 Aug 2014 21:28:39 -0400, <hughaguilar96@yahoo.com> wrote:
> On Friday, August 22, 2014 9:47:39 AM UTC-7, Bernd Paysan wrote:
>> Anton Ertl wrote:

>> Yes, taking away immediacy of words you expect to be immediate is
>> bound to cause problems with words like [COMPILE], which assume
>> that the user knows whether the word is immediate or not (which
>> is a bad idea).
>>
>> That's why POSTPONE was invented.  I don't quite understand why
>> [COMPILE] was left in the standard, it's impossible to use
>> correctly given that the standard doesn't tell which words are
>> immediate and which aren't (with a few exceptions).

Bernd, you're thinking as a user of Forth, not as the creator
of the Forth dictionary who can see and knows which words are
and aren't immediate.

> SwiftForth doesn't support [COMPILE] so it is not fully
> ANS-Forth compliant.
>

Hugh, these are John Hayes' ANS compliant COMPILE, and
[COMPILE] definitions (c.l.f. 1990):

  : COMPILE, POSTPONE LITERAL POSTPONE EXECUTE ;
  : [COMPILE] ' COMPILE, ; IMMEDIATE

> This doesn't bother me. I don't know why [COMPILE] is in the
> standard either. I have never used it in ANS-Forth. I don't
> know why it would be used instead of POSTPONE. I assumed that
> you would know. If you don't know, and Elizabeth Rather doesn't
> know, then who would know?

Could it be for ['] ?

['] seems to typically be coded in terms or COMPILE
or [COMPILE] such as in these (not by me):

  : ['] ' COMPILE LIT , ; IMMEDIATE
  : ['] ' [COMPILE] LITERAL ; IMMEDIATE

Where LITERAL is typically:
  : LITERAL COMPILE LIT , ; IMMEDIATE

POSTPONE seems to be most commonly coded using
COMPILE COMPILE as part of the sequence.

So, if you have COMPILE then you have POSTPONE then COMPILE,
and [COMPILE] from John Hayes' definitions and so too ['].
ISTM, you need ' COMPILE EXECUTE LITERAL to construct them.

In 1990 on c.l.f, John Hayes said POSTPONE was the key word,
while Mitch Bradley said only COMPILE, was needed.


Rod Pemberton

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

#33020

Op Fri, 22 Aug 2014 18:28:39 -0700 (PDT) schreef hughaguilar96@yahoo.com:

> On Friday, August 22, 2014 9:47:39 AM UTC-7, Bernd Paysan wrote:
>> Anton Ertl wrote:
>> Yes, taking away immediacy of words you expect to be immediate is bound to 
>> cause problems with words like [COMPILE], which assume that the user knows 
>> whether the word is immediate or not (which is a bad idea).
>> 
>> That's why POSTPONE was invented.  I don't quite understand why [COMPILE] 
>> was left in the standard, it's impossible to use correctly given that the 
>> standard doesn't tell which words are immediate and which aren't (with a few 
>> exceptions).
> 
> SwiftForth doesn't support [COMPILE] so it is not fully ANS-Forth compliant.
> 
> This doesn't bother me. I don't know why [COMPILE] is in the standard either. I have never used it in ANS-Forth. I don't know why it would be used instead of POSTPONE. I assumed that you would know. If you don't know, and Elizabeth Rather doesn't know, then who would know?

As usual, you're spouting gibberish.
SwiftForth has [COMPILE].
Get a newer version. Oi, you are not allowed, bummer!

-- 
Coos

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

#33021

hughaguilar96@yahoo.com wrote:
> On Friday, August 22, 2014 9:47:39 AM UTC-7, Bernd Paysan wrote:
>> Anton Ertl wrote:
>> Yes, taking away immediacy of words you expect to be immediate is bound to 
>> cause problems with words like [COMPILE], which assume that the user knows 
>> whether the word is immediate or not (which is a bad idea).
>> 
>> That's why POSTPONE was invented.  I don't quite understand why [COMPILE] 
>> was left in the standard, it's impossible to use correctly given that the 
>> standard doesn't tell which words are immediate and which aren't (with a few 
>> exceptions).
> 
> SwiftForth doesn't support [COMPILE] so it is not fully ANS-Forth compliant.

zebedee:jcstress $ ~/SwiftForth/bin/linux/sf
SwiftForth i386-Linux 3.5.3 05-Feb-2014 
locate [compile]                                                               
/home/aph/SwiftForth/src/kernel/interp.f
   40: : [COMPILE] ( "name" -- ) 

Andrew.

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

#33015

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>
>> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>>The idea that it's my proposal is silly; I jumped late on this
>>>smart COMPILE, bandwagon.  Win32Forth STC already had it, you made a
>>>posting proposing that, and Stephen gave a talk at a EuroForth, and then I
>>>was
>>>convinced.  This is nothing new, this has been in VFX for ages (and with
>>>"ages" I mean really right from start).  This is known to work with the 1
>>>million lines of CCS, and it also works with the 500 lines of guru code in
>>>BerndOOF.  There's very little which survives both tests, and BerndOOF is
>>>actually of the class *you* think would fail.
>> ...
>>> We can ask Stephen, how much code breakage he
>>>has observed.
>> 
>> As it turns out, no need to ask around, just in the thread next door
>> <lt79f6$b0o$1@dont-email.me> we get to see breakage from VFX's
>> "COMPILE,", and in the core of VFX as well:
>> 
>> : [cif] [COMPILE] IF ; IMMEDIATE
>> Err# -22 ERR: Control structure mismatch.
>>  -> : [cif] [COMPILE] IF ; IMMEDIATE
>> 
>> How does COMPILE, come into play?  Look here:
>> 
>> see [compile]
>> [COMPILE] (is IMMEDIATE)
>> ( 08058398    E897FFFFFF )            CALL      08058334        '
>> ( 0805839D    E8EEE7FFFF )            CALL      08056B90        COMPILE,
>> ( 080583A2    C3 )                    NEXT,
>> ( 11 bytes, 3 instructions )
>
>Yes, taking away immediacy of words you expect to be immediate is bound to 
>cause problems with words like [COMPILE], which assume that the user knows 
>whether the word is immediate or not (which is a bad idea).
>
>That's why POSTPONE was invented.  I don't quite understand why [COMPILE] 
>was left in the standard, it's impossible to use correctly given that the 
>standard doesn't tell which words are immediate and which aren't (with a few 
>exceptions).

It's definitely possible to use correctly.  [COMPILE] does not ask
whether a word is immediate, so there is no need for the standard to
tell.  The specification talks about whether a word has default
compilation semantics, and the standard tells whether a word has
default compilation semantics (a word without a "Compilation:"
section has default compilation semantics).

>If you look at the definition of [COMPILE] in Gforth, you see that there's 
>an obvious way to fix [COMPILE] in VFX:
>
>: [compile] ( compilation "name" -- ; run-time ? -- ? ) \ core-ext bracket-
>compile
>    comp' drop
>    dup [ comp' exit drop ] literal = if
>	execute \ EXIT has default compilation semantics, perform them
>    else
>	compile,
>    then ; immediate
>
>Yeah, there's a special casing for EXIT, because people using [COMPILE] will 
>assume EXIT to be non-immediate, so we "cheat". 

No, there is a special casing for EXIT, because EXIT has default
compilation semantics, but (unlike for other words in Gforth with
default compilation semantics) COMP' EXIT DROP produces an xt for the
compilation semantics, not the execution semantics.  No cheat
involved.

>VFX should cheat the same 
>way, and have a small case statement with all the words users expect to be 
>immediate.

VFX also should take into account whether a word has default or
non-default compilation semantics.

But that's not the point I wanted to make.  In a traditional
implementation, VFX's implementation of [COMPILE]

: [compile] ' compile, ; immediate

is correct.  VFX's change to COMPILE, broke it.  You asked for
breakage? Here's one example.  And I did not even need to search for
it.

>In effect, the way [COMPILE] is written renders the entire semantics stuff 
>null and void: It means that there is a direct relation from the immediate 
>and compile-only flag to the way the word's description is structured: no 
>interpretation semantics: compile-only.  Non-default compilation semantics: 
>immediate.  Default compilation semantics: non-immediate.

That is certainly the relation between the semantics stuff and
traditional implementations (plus COMPILE-ONLY), but that's
independent of [COMPILE].

>BTW: There's no use of [compile] as a standard word in the entire Gforth 
>source code (the cross compiler's [compile] doesn't count, because it does 
>something different: It works for forward references, while postpone doesn't 
>and can't), which makes the word of dubious quality.

It's of dubious utility, but that says little about quality.  My guess
is that, since POSTPONE was new and people did not trust it yet, they
wanted to keep [COMPILE] for the traditionalists.  Even twenty years
later we see at least one thread every year where some people express
their dislike of POSTPONE and advocate to use [COMPILE] and COMPILE
instead.

- 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 2014: http://www.euroforth.org/ef14/

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

#33023

Anton Ertl wrote:

> But that's not the point I wanted to make.  In a traditional
> implementation, VFX's implementation of [COMPILE]
> 
> : [compile] ' compile, ; immediate
> 
> is correct.

No. Gforth shows that this assertion is not correct.  If you change a single 
thing, e.g. make one of those compile-only words which have "execution 
semantics" in the standard immediate, you break [compile].  If you make IF 
non-immediate, you break [compile].  Note that you can implement IF in a way 
that e.g. scans for ELSE and THEN in the threaded code (at run-time), and 
therefore just has default compilation semantics, without any fancy smart 
COMPILE, and you still break [compile].

All [compile] does is to undo the immediate flag.  It's not specified that 
way, but people implement it that way.  And because it's not specified that 
way, you either have to honor the traditional immediate flag stuff in your 
implementation (like we do in Gforth with the excepton of EXIT, and there, 
we can now change it thanks to COMPILE,), or you have to special-case all 
standard words where you changed that flag.

> VFX's change to COMPILE, broke it.  You asked for
> breakage? Here's one example.  And I did not even need to search for
> it.

Let's try something different: change Gforth's EXIT to be non-immediate 
through the new use of compile,.  Our test candidate is foo:

: foo ." a" [compile] exit ." b" ;  ok
foo a ok

So [compile] exit (the immediate, non-tickable Gforth exit which is special-
cased in [compile]) works as intented: It's just equal to EXIT alone.  Fine.  
Now, our EXIT handles stuff like cleaning up locals, so we had to make it 
immediate.  Try SET-COMPILER:

:noname drop postpone exit ; : exit -14 throw ; set-compiler  
:1: warning: redefined EXIT with exit ok
: foo ." a" [compile] exit ." b" ;  ok                       
foo a ok

Works.  This now is the new EXIT, which is not special-cased by [compile].  
It is non-immediate, as the Forth-83 standard has meant EXIT to be.  It does 
SET-COMPILER magic, because that is how you can implement stuff like 
cleaning up local stacks in EXIT.  The new magic doesn't change anything, 
because EXIT has default compilation semantics, and the compilation 
semantics is specified with SET-COMPILER.

So: It's not the new COMPILE, which breaks [COMPILE], it is the choice of 
making IF and friends non-immediate.  Or, as in Gforth, making EXIT 
immediate (but we did add the workaround into [COMPILE]).

So that's my conclusion: The standard had tried to make the question, 
whether a word is immediate or not a choice of the implementer, but failed.  
It also had tried to make dual-xt/single-xt a choice of the implementer, but 
failed (your logic that S" has to be dual-xt is true if you strictly use 
only the text of the standard as reference).  The result is that it mandates 
a pretty traditional implementation, where IF is immediate and EXIT is not.

There's one question, whether we leave this traditional stuff in Gforth, and 
my answer is pretty much: yes.  That's due to the goals of Gforth.  We 
should make EXIT non-immediate, and allow to tick all those compile-only 
words, because you still can COMPILE, them (or EXECUTE them if you think 
they are immediate, and in Gforth, the assumption will be correct).

The other question is whether we want the standard to mandate this 
traditional flags, or if we rather leave it up to the implementer, and drop 
[COMPILE].

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

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

#33026

Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Anton Ertl wrote:
> 
>> But that's not the point I wanted to make.  In a traditional
>> implementation, VFX's implementation of [COMPILE]
>> 
>> : [compile] ' compile, ; immediate
>> 
>> is correct.
> 
> No. Gforth shows that this assertion is not correct.  If you change
> a single thing, e.g. make one of those compile-only words which have
> "execution semantics" in the standard immediate, you break
> [compile].  If you make IF non-immediate, you break [compile].

Eh?  [COMPILE] is to be applied to immediate words; don't apply it to
non-immediate words.

> So that's my conclusion: The standard had tried to make the
> question, whether a word is immediate or not a choice of the
> implementer, but failed.

If I want to use [COMPILE] I need to know if a word is immediate.  So,
it's impossible to use [COMPILE] on system-supplied words in a
portable program.  I must use POSTPONE for that.  I may use [COMPILE]
on my own words, though.

One thing that baffles me about this kind of discussion is that there
is an obvious way of doing all the optimization anyone could want
while still keeping compatibility with "traditional" systems.  Compile
source code into tokens, using IMMEDIATE in the traditional way (none
of this dual-XT stuff) with a non-immediate EXIT, etc.  Then optimize
the hell out of the tokenized code.  All of the interminable
discussions about non-default compilation semantics would just go
away, and words would be IMMEDIATE or not: nothing else.

Andrew.

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

#33029

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Bernd Paysan <bernd.paysan@gmx.de> wrote:
>> Anton Ertl wrote:
>> 
>>> But that's not the point I wanted to make.  In a traditional
>>> implementation, VFX's implementation of [COMPILE]
>>> 
>>> : [compile] ' compile, ; immediate
>>> 
>>> is correct.
>> 
>> No. Gforth shows that this assertion is not correct.  If you change
>> a single thing, e.g. make one of those compile-only words which have
>> "execution semantics" in the standard immediate, you break
>> [compile].  If you make IF non-immediate, you break [compile].
>
>Eh?  [COMPILE] is to be applied to immediate words; don't apply it to
>non-immediate words.

You can apply it to any word.  It just is redundant for words with
default compilation semantics.

>> So that's my conclusion: The standard had tried to make the
>> question, whether a word is immediate or not a choice of the
>> implementer, but failed.
>
>If I want to use [COMPILE] I need to know if a word is immediate.  So,
>it's impossible to use [COMPILE] on system-supplied words in a
>portable program.

That's so factually wrong that it makes me wonder if someone else is
impersonating Andrew Haley.  Andrew may sometimes be wrong in his
opinions, but he usually gets the facts right.

You don't need to know if a word is immediate to use [COMPILE], and it
is possible to use [COMPILE] on system-supplied standard words.

>One thing that baffles me about this kind of discussion is that there
>is an obvious way of doing all the optimization anyone could want
>while still keeping compatibility with "traditional" systems.  Compile
>source code into tokens, using IMMEDIATE in the traditional way (none
>of this dual-XT stuff) with a non-immediate EXIT, etc.  Then optimize
>the hell out of the tokenized code.  All of the interminable
>discussions about non-default compilation semantics would just go
>away, and words would be IMMEDIATE or not: nothing else.

That way to compilation is certainly the way to go.  The idea of doing
good compilation by misusing the dual-xt stuff is wrong-headed; and
it's even worse to then propose to change COMPILE, in a way that
breaks an established, useful, and practically used equivalence, in
order to accomodate that idea.

As for dual-xt itself, that's just a relatively clean way to do words
like S".  Given all the nonsense that's coming out of it, we should
probably get rid of these words, though.

- 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 2014: http://www.euroforth.org/ef14/

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

#33036

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Bernd Paysan <bernd.paysan@gmx.de> wrote:
>>> Anton Ertl wrote:
>>> 
>>>> But that's not the point I wanted to make.  In a traditional
>>>> implementation, VFX's implementation of [COMPILE]
>>>> 
>>>> : [compile] ' compile, ; immediate
>>>> 
>>>> is correct.
>>> 
>>> No. Gforth shows that this assertion is not correct.  If you change
>>> a single thing, e.g. make one of those compile-only words which have
>>> "execution semantics" in the standard immediate, you break
>>> [compile].  If you make IF non-immediate, you break [compile].
>>
>>Eh?  [COMPILE] is to be applied to immediate words; don't apply it to
>>non-immediate words.
> 
> You can apply it to any word.  It just is redundant for words with
> default compilation semantics.

It's grossly misleading to the reader.  Don't do it.

>>> So that's my conclusion: The standard had tried to make the
>>> question, whether a word is immediate or not a choice of the
>>> implementer, but failed.
>>
>>If I want to use [COMPILE] I need to know if a word is immediate.  So,
>>it's impossible to use [COMPILE] on system-supplied words in a
>>portable program.
> 
> That's so factually wrong that it makes me wonder if someone else is
> impersonating Andrew Haley.  Andrew may sometimes be wrong in his
> opinions,

How is it possible to have a wrong opinion?  :-)

> but he usually gets the facts right.

I stand by my claim.  [COMPILE] is intended for immediate words, and
using it on non-immediate words is useless or worse.  Usually worse.

> You don't need to know if a word is immediate to use [COMPILE], and it
> is possible to use [COMPILE] on system-supplied standard words.

Not really, no.  If you have, say, a word EXIT which is not immediate,
and you want the effect of POSTPONE, then [COMPILE] isn't going to do
it, and will exit from the calling word.  It will have just the same
effect as EXIT on its own.

Andrew.

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

#33037

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> That's so factually wrong that it makes me wonder if someone else is
>> impersonating Andrew Haley.  Andrew may sometimes be wrong in his
>> opinions,
>
>How is it possible to have a wrong opinion?  :-)

Ok, a better word may be "judgement".

>> You don't need to know if a word is immediate to use [COMPILE], and it
>> is possible to use [COMPILE] on system-supplied standard words.
>
>Not really, no.  If you have, say, a word EXIT which is not immediate,
>and you want the effect of POSTPONE, then [COMPILE] isn't going to do
>it, and will exit from the calling word.  It will have just the same
>effect as EXIT on its own.

[COMPILE] EXIT has the same effect as EXIT on its own (not POSTPONE
EXIT) in a standard system, no matter how EXIT is implemented.

- 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 2014: http://www.euroforth.org/ef14/

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

Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6  Next page →

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

csiph-web