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 3 of 6 — ← Prev page 1 2 [3] 4 5 6  Next page →

#33046

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> 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.

So what are you arguing about?  Simply that it is possible to use
[COMPILE] , albeit grossly misleading?

Andrew.

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

#33055

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>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.
>
>So what are you arguing about?

I am pointing out the factual errors in your postings.  In this case:
It does not matter whether a system implements EXIT as immediate word
or not.

Yes, your next impulse is to point out that you did not claim it did.
Resist it!

- 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]

#33059

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>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.
>>
>>So what are you arguing about?
> 
> I am pointing out the factual errors in your postings.  In this case:
> It does not matter whether a system implements EXIT as immediate word
> or not.

Surely it does: if you want the effect of POSTPONE EXIT, but EXIT is
not immediate, then [COMPILE] EXIT isn't going to do what you want.
You need COMPILE EXIT .  That's why POSTPONE was invented: so you
didn't need to know if a word was immediate or not.

> Yes, your next impulse is to point out that you did not claim it did.
> Resist it!

Andrew.

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

#33076

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>>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.
>>>
>>>So what are you arguing about?
>> 
>> I am pointing out the factual errors in your postings.  In this case:
>> It does not matter whether a system implements EXIT as immediate word
>> or not.
>
>Surely it does: if you want the effect of POSTPONE EXIT, but EXIT is
>not immediate, then [COMPILE] EXIT isn't going to do what you want.

No, it does not matter.  On a standard system [COMPILE] EXIT is not
going to produce the same result as POSTPONE EXIT no matter how EXIT
is implemented.  For example, in Gforth the definition of EXIT is:

: EXIT ( compilation -- ; run-time nest-sys -- ) \ core
    exit-like
    POSTPONE ;s
    basic-block-end
    POSTPONE unreachable ; immediate restrict

When I do:

: foo [compile] exit ." bla" ; foo

it prints nothing, just like

: foo exit ." bla" ; foo

and unlike

: foo postpone exit ." bla" ; foo

The latter prints "bla".

>You need COMPILE EXIT .

COMPILE is not Forth-94 and is not present in, e.g., Gforth.

>That's why POSTPONE was invented: so you
>didn't need to know if a word was immediate or not.

With Forth-94 [COMPILE] you don't need to know whether a word is
immediate, either, but you need to know whether it's compilation
semantics are default or not (for user-defined words that's the same
as knowing whether a word is immediate, but for standard-defined words
it's not the same).  With POSTPONE you don't need to know that.

- 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]

#33079

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>>>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.
>>>>
>>>>So what are you arguing about?
>>> 
>>> I am pointing out the factual errors in your postings.  In this case:
>>> It does not matter whether a system implements EXIT as immediate word
>>> or not.
>>
>>Surely it does: if you want the effect of POSTPONE EXIT, but EXIT is
>>not immediate, then [COMPILE] EXIT isn't going to do what you want.
> 
> No, it does not matter.  On a standard system [COMPILE] EXIT is not
> going to produce the same result as POSTPONE EXIT no matter how EXIT
> is implemented.  For example, in Gforth the definition of EXIT is:
> 
> : EXIT ( compilation -- ; run-time nest-sys -- ) \ core
>    exit-like
>    POSTPONE ;s
>    basic-block-end
>    POSTPONE unreachable ; immediate restrict

I don't understand this at all.

> When I do:
> 
> : foo [compile] exit ." bla" ; foo
> 
> it prints nothing

Why does it do that?  Why does FOO not perform the compile time action
of EXIT and then print "bla" ?

>>You need COMPILE EXIT .
> 
> COMPILE is not Forth-94 and is not present in, e.g., Gforth.
> 

>>That's why POSTPONE was invented: so you didn't need to know if a
>>word was immediate or not.
> 
> With Forth-94 [COMPILE] you don't need to know whether a word is
> immediate, either, but you need to know whether it's compilation
> semantics are default or not

Well, yes, which at the time was almost always the same thing.

> (for user-defined words that's the same as knowing whether a word is
> immediate, but for standard-defined words it's not the same).  With
> POSTPONE you don't need to know that.

Andrew.

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

#33084

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> : EXIT ( compilation -- ; run-time nest-sys -- ) \ core
>>    exit-like
>>    POSTPONE ;s
>>    basic-block-end
>>    POSTPONE unreachable ; immediate restrict
>
>I don't understand this at all.
>
>> When I do:
>> 
>> : foo [compile] exit ." bla" ; foo
>> 
>> it prints nothing
>
>Why does it do that?  Why does FOO not perform the compile time action
>of EXIT and then print "bla" ?

Because the standard says that [COMPILE] EXIT is equivalent to EXIT,
and I implemented [COMPILE] accordingly.

>> With Forth-94 [COMPILE] you don't need to know whether a word is
>> immediate, either, but you need to know whether it's compilation
>> semantics are default or not
>
>Well, yes, which at the time was almost always the same thing.

For a traditional implementation, it is the same thing.  But for
Gforth, it is not.  In any case, the user does not need to know
whether EXIT is implemented as an immediate word, and can still use
[COMPILE] EXIT in a standard program with predictable results.

- 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]

#33087

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> : EXIT ( compilation -- ; run-time nest-sys -- ) \ core
>>>    exit-like
>>>    POSTPONE ;s
>>>    basic-block-end
>>>    POSTPONE unreachable ; immediate restrict
>>
>>I don't understand this at all.
>>
>>> When I do:
>>> 
>>> : foo [compile] exit ." bla" ; foo
>>> 
>>> it prints nothing
>>
>>Why does it do that?  Why does FOO not perform the compile time action
>>of EXIT and then print "bla" ?
> 
> Because the standard says that [COMPILE] EXIT is equivalent to EXIT,
> and I implemented [COMPILE] accordingly.

Oh, so [COMPILE] special-cases EXIT ?  Or is there some other magic?

>>> With Forth-94 [COMPILE] you don't need to know whether a word is
>>> immediate, either, but you need to know whether it's compilation
>>> semantics are default or not
>>
>>Well, yes, which at the time was almost always the same thing.
> 
> For a traditional implementation, it is the same thing.  But for
> Gforth, it is not.  In any case, the user does not need to know
> whether EXIT is implemented as an immediate word, and can still use
> [COMPILE] EXIT in a standard program with predictable results.

That may well be so, but it is rather to skirt around the actual
point.  I wrote:

> That's why POSTPONE was invented: so you didn't need to know if a
> word was immediate or not.

Andrew.

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

#33089

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>> : EXIT ( compilation -- ; run-time nest-sys -- ) \ core
>>>>    exit-like
>>>>    POSTPONE ;s
>>>>    basic-block-end
>>>>    POSTPONE unreachable ; immediate restrict
>>>
>>>I don't understand this at all.
>>>
>>>> When I do:
>>>> 
>>>> : foo [compile] exit ." bla" ; foo
>>>> 
>>>> it prints nothing
>>>
>>>Why does it do that?  Why does FOO not perform the compile time action
>>>of EXIT and then print "bla" ?
>> 
>> Because the standard says that [COMPILE] EXIT is equivalent to EXIT,
>> and I implemented [COMPILE] accordingly.
>
>Oh, so [COMPILE] special-cases EXIT ?

Yes, as I have posted several times in the last few days.

> Or is there some other magic?

No, special-casing EXIT and LEAVE is sufficient for Gforth, and the
needs of [COMPILE] are not more generally useful, so no need for
something more general.

- 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]

#33525

Andrew Haley wrote:

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

Actually, the way the standard specifies [COMPILE] is quite different.  The 
problem here IMHO is the standard.  We should take a closer look at 
[COMPILE] in the next two days, it is certainly specified in a way which 
nobody implements.  We all implement the [COMPILE] which makes immediate 
words non-immediate.  The implication of the standard text is that the 
semantics maps 1:1 to immediacy and compile-only flags in Forth-83, and this 
can't be what has been intended.

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

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

#33531

Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Andrew Haley wrote:
> 
>> I stand by my claim.  [COMPILE] is intended for immediate words, and
>> using it on non-immediate words is useless or worse.  Usually worse.
> 
> Actually, the way the standard specifies [COMPILE] is quite different.  The 
> problem here IMHO is the standard.  We should take a closer look at 
> [COMPILE] in the next two days, it is certainly specified in a way which 
> nobody implements.  We all implement the [COMPILE] which makes immediate 
> words non-immediate.  The implication of the standard text is that the 
> semantics maps 1:1 to immediacy and compile-only flags in Forth-83, and this 
> can't be what has been intended.

Isn't [COMPILE] obsolescent anyway?  Can't it now be deleted?

Andrew.

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

#33535

Andrew Haley wrote:

> Bernd Paysan <bernd.paysan@gmx.de> wrote:
>> Andrew Haley wrote:
>> 
>>> I stand by my claim.  [COMPILE] is intended for immediate words, and
>>> using it on non-immediate words is useless or worse.  Usually worse.
>> 
>> Actually, the way the standard specifies [COMPILE] is quite different. 
>> The
>> problem here IMHO is the standard.  We should take a closer look at
>> [COMPILE] in the next two days, it is certainly specified in a way which
>> nobody implements.  We all implement the [COMPILE] which makes immediate
>> words non-immediate.  The implication of the standard text is that the
>> semantics maps 1:1 to immediacy and compile-only flags in Forth-83, and
>> this can't be what has been intended.
> 
> Isn't [COMPILE] obsolescent anyway?  Can't it now be deleted?

No, it's not.  There's no mentioning of obsolescence anywhere.  It just has 
no interpretation semantics, and the compilation semantics is defined as:

Compilation: Skip leading space delimiters. Parse name delimited by a space. 
Find name. If name has other than default compilation semantics, append them 
to the current definition; otherwise append the execution semantics of name. 
An ambiguous condition exists if name is not found.

IMHO the action described in sentence 4 is wrong in all possible ways.  In a 
traditional system, "append the execution semantics of name" would be right, 
the other part is not necessary (traditionally, non-default compilation 
semantics is achieved by being immediate, which means that it's the 
execution semantics).

Note that there has been a paragraph about [COMPILE] in the compatibility 
section of Forth 94:

"Impact: [COMPILE] remains in ANS Forth, since its proper use does not 
depend on knowledge of whether or not a word is immediate (Use of [COMPILE] 
with a non-immediate word is and has always been a no-op). Whether or not 
you need to use [COMPILE] requires knowledge of whether or not its target 
word is immediate, but it is always safe to use [COMPILE]. [COMPILE] is no 
longer in the (required) core word set, having been moved to the Core 
Extensions word set, but the committee anticipates that most vendors will 
supply it anyway."

This is 50% bullshit, and the other 50% assumes that [COMPILE] simply 
ignores the immediacy flag.  It's not "always safe to use [COMPILE]", since 
it either alters the behavior to non-immediacy, or it does nothing, 
depending on the immediacy of the word it is applied to.

In effect, we should change the spec of [COMPILE] to that, i.e. that it 
simply is an one-shot interpreter that ignores the immediacy flag, and that 
you can only apply [COMPILE] savely on your own words (where you know if 
they are immediate or not), and mark it as obsolescent.  Reference 
implementation:

: [compile] ( "name" -- ) ' compile, ; immediate

For systems like Gforth, where we make the promise that traditional stuff 
will quite often work, it means that EXIT and LEAVE will have to be non-
immediate; that's something we can do in Gforth git.

I'd actually put it a bit stronger: The expectation for a system that allows 
traditional stuff is that this reference implementation just works.  But a 
standard program should not expect that every system works like this.

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

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

#33045

In article <2014Aug24.153654@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
<SNIP>
>
>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.

I gravitate towards
    "APE"
instead of
   S" APE"
and
    "APE" TYPE
instead of
   ." APE"
and
 .( APE)

Numbers ("denotations") are state smart but that is the only
state smartness we need.

colorforth takes it one step further:
Chuck Moore has taken the state-smartness out of numbers.
The programmer has to paint numbers green or yellow as desired.

>
>- anton

Groetjes Albert
-- 
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]

#33054

albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>I gravitate towards
>    "APE"
>instead of
>   S" APE"
>and
>    "APE" TYPE
>instead of
>   ." APE"
>and
> .( APE)

Yes.

>Numbers ("denotations") are state smart but that is the only
>state smartness we need.

If you consider a number a word with the execution semantics to push a
cell on the stack, then a number has default compilation semantics and
is not state-smart.  In any case, there is no way to observe
state-smartness, because numbers cannot be ticked or postponed.

- 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]

#33062

In article <2014Aug26.082356@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>>I gravitate towards
>>    "APE"
>>instead of
>>   S" APE"
>>and
>>    "APE" TYPE
>>instead of
>>   ." APE"
>>and
>> .( APE)
>
>Yes.
>
>>Numbers ("denotations") are state smart but that is the only
>>state smartness we need.
>
>If you consider a number a word with the execution semantics to push a
>cell on the stack, then a number has default compilation semantics and
>is not state-smart.  In any case, there is no way to observe
>state-smartness, because numbers cannot be ticked or postponed.

You never put it that clearly. So basically, the difference between
compilation and interpretation is being in a state, which is not
the same as being state smart.
You're convincing me.

' 12
makes no sense and luckily
' "aape"
doesn't either.

>
>- anton
-- 
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]

#33081

albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>You never put it that clearly. So basically, the difference between
>compilation and interpretation is being in a state, which is not
>the same as being state smart.

I would not put it that way.  STATE is something for the text
interpreter.  When it is in interpret state, it performs the
interpretation semantics of words; when it is in compile state, the
compilation semantics of words.

>' 12
>makes no sense and luckily
>' "aape"
>doesn't either.

One could assign sense to them.  Consider the definitions

12 constant 12
: "aape" "aape" ;

Now you can ' 12 and ' "aape", and it makes sense (and you also see
that they are not state-smart).  The reason why we don't support it is
not because it would make no sense, but because we don't know a good
implemenation.  The xt is just a single cell, but it would have to
contain the knowledge about what kind of xt it is an what value it
should push; this needs extra storage, and that would require managing
this storage.

- 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]

#33058

On Monday, 25 August 2014 16:59:21 UTC+1, Albert van der Horst  wrote:
> I gravitate towards
>     "APE"
> instead of
>    S" APE"

Interested in your opinion on how you would implement that
inside the compiler.

I presume that after determining that "APE" is not a dictionary
entry, and not a valid number, a third check is made to see if it
it's a valid string (i.e. begins and ends with a " character)?

The only potential issue that I see is that it's no longer
possible to have words in the dictionary that are surrounded by
quotation marks, surely a very very rare occurrence.

E.g. it would (presumably) be possible to *define* "APE":

: "APE" ... ... ... ;

But you could not refer to it, as you'd get a string instead.

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

#33065

In article <edf13df6-b3ec-4fca-9410-95b1f63a4dc2@googlegroups.com>,
Mark Wills  <markwills1970@gmail.com> wrote:
>On Monday, 25 August 2014 16:59:21 UTC+1, Albert van der Horst  wrote:
>> I gravitate towards
>>     "APE"
>> instead of
>>    S" APE"
>
>Interested in your opinion on how you would implement that
>inside the compiler.
>
>I presume that after determining that "APE" is not a dictionary
>entry, and not a valid number, a third check is made to see if it
>it's a valid string (i.e. begins and ends with a " character)?

No it isn't. There is a word " that is present in the minimum
search order wordlist (called ONLY). It is executed because
it has the PREFIX flag (similar to IMMEDIATE). Prefix words
are recognized irrespective whether followed by a space. 1]

: test ONLY WORDS FORTH ;
 OK
test
& ^ 0 1 2 3 4 5 6 7 8 9 A B C D E F - + " FORTH OK


 " is a just a word:

"APE" TYPE
APE OK
' " HIDDEN
OK
"APE" TYPE

As you see numbers are done using this mechanism.
There is no third check. There is not even a second check.

>
>The only potential issue that I see is that it's no longer
>possible to have words in the dictionary that are surrounded by
>quotation marks, surely a very very rare occurrence.
>
>E.g. it would (presumably) be possible to *define* "APE":
>
>: "APE" ... ... ... ;
>
>But you could not refer to it, as you'd get a string instead.

Let me see

   : "APE" "This must be my lucky day!" TYPE CR ;
   OK
   "APE"
   This must be my lucky day!
   OK

You overlooked the search order.
The situation is really no different than redefining
0 as a constant.

If it were any different I couldn't use this mechanism in
an ISO-compliant system (ciforth).

Groetjes Albert

1] You can imagine how minimal a difference this is for a
Forth. In my first promotion of this mechanism it amounted
to one line.
-- 
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]

#33067

In article <53fc541b$0$15832$e4fe514c@dreader35.news.xs4all.nl>,
Albert van der Horst <albert@spenarnc.xs4all.nl> wrote:
>In article <edf13df6-b3ec-4fca-9410-95b1f63a4dc2@googlegroups.com>,
>Mark Wills  <markwills1970@gmail.com> wrote:
>>On Monday, 25 August 2014 16:59:21 UTC+1, Albert van der Horst  wrote:
>>> I gravitate towards
>>>     "APE"
>>> instead of
>>>    S" APE"
>>
>>Interested in your opinion on how you would implement that
>>inside the compiler.
>>
>>I presume that after determining that "APE" is not a dictionary
>>entry, and not a valid number, a third check is made to see if it
>>it's a valid string (i.e. begins and ends with a " character)?
>
>No it isn't. There is a word " that is present in the minimum
>search order wordlist (called ONLY). It is executed because
>it has the PREFIX flag (similar to IMMEDIATE). Prefix words
>are recognized irrespective whether followed by a space. 1]
>
>: test ONLY WORDS FORTH ;
> OK
>test
>& ^ 0 1 2 3 4 5 6 7 8 9 A B C D E F - + " FORTH OK
>
>
> " is a just a word:
>
>"APE" TYPE
>APE OK
>' " HIDDEN
>OK
>"APE" TYPE

Sorry the punch line was not copied:
    "APE" ? ciforth ERROR # 12 : NOT RECOGNIZED

>
>As you see numbers are done using this mechanism.
>There is no third check. There is not even a second check.
>
>>
>>The only potential issue that I see is that it's no longer
>>possible to have words in the dictionary that are surrounded by
>>quotation marks, surely a very very rare occurrence.
>>
>>E.g. it would (presumably) be possible to *define* "APE":
>>
>>: "APE" ... ... ... ;
>>
>>But you could not refer to it, as you'd get a string instead.
>
>Let me see
>
>   : "APE" "This must be my lucky day!" TYPE CR ;
>   OK
>   "APE"
>   This must be my lucky day!
>   OK
>
>You overlooked the search order.
>The situation is really no different than redefining
>0 as a constant.
>
>If it were any different I couldn't use this mechanism in
>an ISO-compliant system (ciforth).
>
>Groetjes Albert
>
>1] You can imagine how minimal a difference this is for a
>Forth. In my first promotion of this mechanism it amounted
>to one line.
>--
>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
>
-- 
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]

#33068

On Tuesday, 26 August 2014 10:32:11 UTC+1, Albert van der Horst  wrote:
> No it isn't. There is a word " that is present in the minimum
> search order wordlist (called ONLY). It is executed because
> it has the PREFIX flag (similar to IMMEDIATE). Prefix words
> are recognized irrespective whether followed by a space. 1]

Ah, okay. So it looks like you have a special-case FIND for words
in the ONLY wordlist, or, at least, a FIND that can deal with words
that are not followed by a space. Neat implementation.

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

#33072

In article <c656ab64-9206-4d9c-91c6-4758ffe45605@googlegroups.com>,
Mark Wills  <markwills1970@gmail.com> wrote:
>On Tuesday, 26 August 2014 10:32:11 UTC+1, Albert van der Horst  wrote:
>> No it isn't. There is a word " that is present in the minimum
>> search order wordlist (called ONLY). It is executed because
>> it has the PREFIX flag (similar to IMMEDIATE). Prefix words
>> are recognized irrespective whether followed by a space. 1]
>
>Ah, okay. So it looks like you have a special-case FIND for words
>in the ONLY wordlist, or, at least, a FIND that can deal with words
>that are not followed by a space. Neat implementation.

You're right that my underlying (FIND) is special in that it observes
the PREFIX flag, but indeed it does so always, not only for the ONLY wordlist.

So a user can define his own prefixes, e.g. using 0x to recognize
hex numbers like 0x1AC0 only in a context of his choosing.

Assuming $ and ALIAS have been loaded:

   NAMESPACE AAP AAP DEFINITIONS    \ AAP is a pushing wordlist with a name
   ' $ ALIAS 0x
   OK
   0xAA .
   170 OK
   WORDS
   0x OK
   PREVIOUS DEFINITIONS
   0xAA
   0xAA ? ciforth ERROR # 10 : NOT A WORD, NOR A NUMBER OR OTHER DENOTATION

Groetjes Albert
-- 
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]

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

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

csiph-web