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

Would ?EXIT work in all ANS-Forth systems?

Started by	lehs <skydda.barnen@gmail.com>
First post	2017-05-10 08:21 -0700
Last post	2017-05-15 11:23 +0000
Articles	20 on this page of 135 — 21 participants

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

  Would ?EXIT work in all ANS-Forth systems? lehs <skydda.barnen@gmail.com> - 2017-05-10 08:21 -0700
    Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-10 16:39 +0100
      Re: Would ?EXIT work in all ANS-Forth systems? lehs <skydda.barnen@gmail.com> - 2017-05-10 08:46 -0700
      Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 16:04 +0000
      Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-11 04:22 -0500
        Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-11 10:35 +0100
          Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-11 05:08 -0500
            Re: Would ?EXIT work in all ANS-Forth systems? Julian Fondren <julian.fondren@gmail.com> - 2017-05-11 03:51 -0700
              Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-11 07:02 -0500
              Re: Would ?EXIT work in all ANS-Forth systems? rickman <gnuarm@gmail.com> - 2017-05-13 11:55 -0400
          Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 09:32 -0500
            Re: Would ?EXIT work in all ANS-Forth systems? Cecil Bayona <cbayona@cbayona.com> - 2017-05-15 11:56 -0500
              Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 12:20 -0500
                Re: Would ?EXIT work in all ANS-Forth systems? Cecil Bayona <cbayona@cbayona.com> - 2017-05-15 12:31 -0500
                  Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 15:50 -0500
    Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 16:49 +0000
      Re: Would ?EXIT work in all ANS-Forth systems? lehs <skydda.barnen@gmail.com> - 2017-05-10 12:04 -0700
    Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-11 01:08 -0700
      Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-11 09:13 +0100
        Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-11 01:48 -0700
          Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-11 09:59 +0100
    Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-12 14:20 +0000
      Re: Would ?EXIT work in all ANS-Forth systems? lehs <skydda.barnen@gmail.com> - 2017-05-12 17:01 -0700
        Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-12 22:18 -0700
          Re: Would ?EXIT work in all ANS-Forth systems? lehs <skydda.barnen@gmail.com> - 2017-05-13 03:09 -0700
          Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-13 21:07 +1000
          Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-13 14:20 +0000
            Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-14 11:59 +1000
              Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-14 09:21 -0500
                Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-14 10:43 -0700
                  Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-14 18:35 -0500
                    Re: Would ?EXIT work in all ANS-Forth systems? Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-15 07:11 +0200
                      Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 04:35 -0500
                        Re: Would ?EXIT work in all ANS-Forth systems? Julian Fondren <julian.fondren@gmail.com> - 2017-05-15 03:54 -0700
                          Re: Would ?EXIT work in all ANS-Forth systems? mhx@iae.nl - 2017-05-15 04:07 -0700
                          Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 06:23 -0500
                            Re: Would ?EXIT work in all ANS-Forth systems? Julian Fondren <julian.fondren@gmail.com> - 2017-05-15 06:53 -0700
                              Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 09:18 -0500
                    Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-14 22:44 -0700
                      Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 04:16 -0500
                        Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-16 02:00 -0700
                        Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-16 02:43 -0700
                          Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-16 05:08 -0500
                          Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-16 12:11 +0000
                            Re: Would ?EXIT work in all ANS-Forth systems? NN <november.nihal@gmail.com> - 2017-05-17 05:24 -0700
                              Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-17 07:35 -0500
                                Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-17 14:59 +0100
                              Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-17 13:30 +0000
                  Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-15 11:09 +1000
                    Re: Would ?EXIT work in all ANS-Forth systems? Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-14 21:17 -0700
                    Re: Would ?EXIT work in all ANS-Forth systems? Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-15 07:13 +0200
                      Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-16 10:24 +1000
                        Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-16 01:13 -0700
                          Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-16 12:26 +0000
                            Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-17 01:58 -0700
                              Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-17 16:45 +0000
                                Re: Would ?EXIT work in all ANS-Forth systems? obi65537@gmail.com - 2017-05-25 12:04 -0700
                                  Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-26 10:02 +0000
                                    Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-26 07:46 -0500
                                      Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-26 13:53 +0000
                                        Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-26 10:14 -0500
                                      Re: Would ?EXIT work in all ANS-Forth systems? Cecil Bayona <cbayona@cbayona.com> - 2017-05-26 10:16 -0500
                                        Re: Would ?EXIT work in all ANS-Forth systems? Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-26 08:59 -0700
                                          Re: Would ?EXIT work in all ANS-Forth systems? Cecil Bayona <cbayona@cbayona.com> - 2017-05-26 11:27 -0500
                                            Re: Would ?EXIT work in all ANS-Forth systems? Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-26 10:19 -0700
                                              Re: Would ?EXIT work in all ANS-Forth systems? Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-26 20:20 +0200
                                                Re: Would ?EXIT work in all ANS-Forth systems? Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-26 21:38 -0700
                                              Re: Would ?EXIT work in all ANS-Forth systems? Cecil Bayona <cbayona@cbayona.com> - 2017-05-26 14:06 -0500
                                                Re: Would ?EXIT work in all ANS-Forth systems? Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-26 22:00 -0700
                            Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-26 17:06 +0000
                              Re: Would ?EXIT work in all ANS-Forth systems? hum9 <obi65537@gmail.com> - 2017-05-27 01:15 -0700
                                Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-28 14:17 +0000
                              Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-27 17:40 +0000
                          Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-24 15:46 +1000
                            Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <obi65537@gmail.com> - 2017-05-25 11:51 -0700
                            Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <obi65537@gmail.com> - 2017-05-25 20:38 -0700
                            Re: Would ?EXIT work in all ANS-Forth systems? obi65537@gmail.com - 2017-05-25 22:03 -0700
                              Re: Would ?EXIT work in all ANS-Forth systems? obi65537@gmail.com - 2017-05-25 22:09 -0700
                                Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-26 21:56 +1000
                                  Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-26 13:30 +0100
                                    Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-27 15:04 +1000
                                      Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-27 17:33 +0100
                                        Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-29 12:17 +1000
                                  Re: Would ?EXIT work in all ANS-Forth systems? hum9 <obi65537@gmail.com> - 2017-05-27 00:33 -0700
                                Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-27 14:53 +1000
                                  READ-FILE over-specified? "HAA" <someone@microsoft.com> - 2017-05-27 21:28 +1000
                                    Re: READ-FILE over-specified? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-27 13:11 +0000
                                      Re: READ-FILE over-specified? "HAA" <someone@microsoft.com> - 2017-05-29 13:47 +1000
                                    Re: READ-FILE over-specified? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-28 09:44 +0200
                                      Re: READ-FILE over-specified? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-28 13:41 +0000
                                        Re: READ-FILE over-specified? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-28 19:59 +0200
                        Re: Would ?EXIT work in all ANS-Forth systems? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-05-16 09:42 +0100
                          Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-16 09:53 +0100
                            Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-16 04:53 -0500
                              Re: Would ?EXIT work in all ANS-Forth systems? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-16 12:32 +0200
                              Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-16 12:35 +0100
                                Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-16 10:48 -0500
                                  Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-16 18:23 +0100
                                    Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-17 04:33 -0500
                                      Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-17 12:29 +0100
                              Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-16 10:28 +0000
                                Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-16 10:43 -0500
                                  Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-16 16:34 +0000
                                    Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-16 12:41 -0500
                                      Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-17 16:14 +0000
                                        Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-18 03:05 -0500
                                          Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-18 16:33 +0000
                                            Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-18 12:43 -0500
                                        Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-18 04:01 -0500
                                          Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-18 15:41 +0000
                                            Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-18 11:58 -0500
                                            Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-18 22:57 +0100
                            Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-17 00:32 +1000
                              Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-16 15:53 +0100
                  Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-15 05:29 +0000
                    Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-14 23:00 -0700
                  Re: Would ?EXIT work in all ANS-Forth systems? rickman <gnuarm@gmail.com> - 2017-05-17 12:27 -0400
              Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-15 09:16 +0000
              Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-15 09:55 +0000
          Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-13 14:25 +0000
            Re: Would ?EXIT work in all ANS-Forth systems? Julian Fondren <julian.fondren@gmail.com> - 2017-05-13 07:49 -0700
              Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-15 09:59 +0000
              Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-15 12:22 +0000
        Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-13 14:19 +0000
    Re: Would ?EXIT work in all ANS-Forth systems? lehs <skydda.barnen@gmail.com> - 2017-05-14 23:23 -0700
      Re: Would ?EXIT work in all ANS-Forth systems? Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-15 00:10 -0700
        Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-15 09:35 +0000
      Re: Would ?EXIT work in all ANS-Forth systems? lehs <skydda.barnen@gmail.com> - 2017-05-15 00:54 -0700
        Return-address manipulation (was: Would ?EXIT ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-15 08:47 +0000
          Re: Return-address manipulation (was: Would ?EXIT ...) stephen@mpeforth.com (Stephen Pelc) - 2017-05-15 11:53 +0000
            Re: Return-address manipulation (was: Would ?EXIT ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-16 13:03 +0000
              Re: Return-address manipulation (was: Would ?EXIT ...) Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-16 07:06 -0700
                Re: Return-address manipulation (was: Would ?EXIT ...) Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-16 07:14 -0700
      Re: Would ?EXIT work in all ANS-Forth systems? "Elizabeth D. Rather" <erather@forth.com> - 2017-05-14 21:58 -1000
        Re: Would ?EXIT work in all ANS-Forth systems? stephen@mpeforth.com (Stephen Pelc) - 2017-05-15 11:23 +0000

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

#59366

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2017-05-16 10:28 +0000
Message-ID	<2017May16.122829@mips.complang.tuwien.ac.at>
In reply to	#59360

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Forth's CATCH/THROW is the lightest-weight exception-handling
>mechanism that I've seen, but it's still heavier than EXIT, which is
>(almost) the lightest-weight subroutine return mechanism I've ever
>seen.  Having siad that, it's difficult for an analytical Forth
>compiler to optimize CATCH and THROW: I don't know if any of them
>attempt it.

CATCH is easier for an analytical compiler (that analyses beyond basic
blocks) than R> DROP: you don't need to know where the THROW is coming
from to know the stack effect of the CATCH; you still need to know the
stack effect for the regular exit, but that's the same as for a
regular call.

For non-zero THROW, the way I use it would be relatively simple to
implement: only the TOS needs to be passed to the CATCH.  However, the
standard describes it in terms of adjusting the stack depth, so if any
value below the CATCH depth was changed in between, this value is
specified in that case, too.  Does anyone make use of this feature?

Concerning converting a statically predictable THROW into a
jump-with-extras, that's also possible, but requires similar effort to
optimizing a statically analyzable use of return-address manipulation.
The benefit of CATCH...THROW in that context is when we are not able
to statically analyze it: CATCH...THROW is relatively benign, whereas
with return-address manipulation every EXECUTE or deferred word can
result in arbitrary things happening to the return stack.

>Also, there is a philosophical objection to using THROW in anything
>other than exceptional circumstances.

If we can use return-address manipulation in non-exceptional
circumstances, why balk at THROW?

>In many languages this leads to
>throwing an exception being very slow.  (That's a property of the
>implementation, but it's also the product of an attitude.)

You have a feedback loop in such things.  But implementation comes
first: gcc now implements some cases of memcpy() in an efficient way,
and advocates its usage, so people start using it for these cases,
even those (like me) who think that this is the wrong way to solve the
problem.

>And
>exceptions can be very hard to debug.

Why do you think so?  I have not had problems with them yet.  On the
contrary, I have had problems with code where THROW may have been
appropriate, but was not used.

- 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 2017: http://www.euroforth.org/ef17/

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

#59377

From	Andrew Haley <andrew29@littlepinkcloud.invalid>
Date	2017-05-16 10:43 -0500
Message-ID	<W6mdnQe9aam6g4bEnZ2dnUU7-UnNnZ2d@supernews.com>
In reply to	#59366

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Forth's CATCH/THROW is the lightest-weight exception-handling
>>mechanism that I've seen, but it's still heavier than EXIT, which is
>>(almost) the lightest-weight subroutine return mechanism I've ever
>>seen.  Having siad that, it's difficult for an analytical Forth
>>compiler to optimize CATCH and THROW: I don't know if any of them
>>attempt it.
> 
> CATCH is easier for an analytical compiler (that analyses beyond basic
> blocks) than R> DROP:

Oh, for sure.

> you don't need to know where the THROW is coming from to know the
> stack effect of the CATCH; you still need to know the stack effect
> for the regular exit, but that's the same as for a regular call.

I get that, but you do have a merge point with two stack states.  The
easiest way to handle that is by spilling the stack state to memory.
I was wondering if anyone did anything other than that.

> For non-zero THROW, the way I use it would be relatively simple to
> implement: only the TOS needs to be passed to the CATCH.  However, the
> standard describes it in terms of adjusting the stack depth, so if any
> value below the CATCH depth was changed in between, this value is
> specified in that case, too.  Does anyone make use of this feature?

I've always assumed it was bad practice.  (i.e. Don't do that!)  On
the other hand, it's one of the ways you have of conveying more
information to the caller than a throw code.

> Concerning converting a statically predictable THROW into a
> jump-with-extras, that's also possible, but requires similar effort
> to optimizing a statically analyzable use of return-address
> manipulation.  The benefit of CATCH...THROW in that context is when
> we are not able to statically analyze it: CATCH...THROW is
> relatively benign, whereas with return-address manipulation every
> EXECUTE or deferred word can result in arbitrary things happening to
> the return stack.

Yes, I completely agree.  For comparison, we do optimize frequently-
taken exceptions in Java, but that's a very unusual case: frequent
throwning is often reckoned to be a sign of bad API design.

>>Also, there is a philosophical objection to using THROW in anything
>>other than exceptional circumstances.
> 
> If we can use return-address manipulation in non-exceptional
> circumstances, why balk at THROW?

We can't do that as standard.  I'm appalled at the very idea of using
return-address manipulation in non-exceptional circumstances!

>>In many languages this leads to throwing an exception being very
>>slow.  (That's a property of the implementation, but it's also the
>>product of an attitude.)
> 
> You have a feedback loop in such things.  But implementation comes
> first: gcc now implements some cases of memcpy() in an efficient way,
> and advocates its usage, so people start using it for these cases,
> even those (like me) who think that this is the wrong way to solve the
> problem.
>
> And exceptions can be very hard to debug.
> 
> Why do you think so?

I've had some bad experiences.  I once wrote a parser which handled
corner cases with THROW.  I (needless to say) got it wrong and found
that tracing the control flow was very difficult, and the usual
keyboard interaction was rather impractical.  In the end, I ripped out
the use of THROW for everything except an early end of stream.

It might be that really good tracing tools would have solved the
problem, but needing really good tracing tools is perhaps also a sign
of a bad design.

Andrew.

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

#59384

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2017-05-16 16:34 +0000
Message-ID	<2017May16.183409@mips.complang.tuwien.ac.at>
In reply to	#59377

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> you don't need to know where the THROW is coming from to know the
>> stack effect of the CATCH; you still need to know the stack effect
>> for the regular exit, but that's the same as for a regular call.
>
>I get that, but you do have a merge point with two stack states.  The
>easiest way to handle that is by spilling the stack state to memory.

Certainly, but that's not different than for any other control flow
join.

>I was wondering if anyone did anything other than that.

Maybe iForth.  But I hope to contribute to advances in this area in
the future.  

>> Concerning converting a statically predictable THROW into a
>> jump-with-extras, that's also possible, but requires similar effort
>> to optimizing a statically analyzable use of return-address
>> manipulation.  The benefit of CATCH...THROW in that context is when
>> we are not able to statically analyze it: CATCH...THROW is
>> relatively benign, whereas with return-address manipulation every
>> EXECUTE or deferred word can result in arbitrary things happening to
>> the return stack.
>
>Yes, I completely agree.  For comparison, we do optimize frequently-
>taken exceptions in Java, but that's a very unusual case: frequent
>throwning is often reckoned to be a sign of bad API design.

I would not draw any conclusions from Java style to Forth style.  In
Forth THROW is currently not usually used for non-exceptional exits,
but that would provide advantages (that are not relevant in Java) that
I discussed in <2017Feb13.175259@mips.complang.tuwien.ac.at>.

- 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 2017: http://www.euroforth.org/ef17/

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

#59386

From	Andrew Haley <andrew29@littlepinkcloud.invalid>
Date	2017-05-16 12:41 -0500
Message-ID	<V_SdnQBzw5l8pIbEnZ2dnUU7-dvNnZ2d@supernews.com>
In reply to	#59384

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:

>>we do optimize frequently-taken exceptions in Java, but that's a
>>very unusual case: frequent throwing is often reckoned to be a sign
>>of bad API design.
> 
> I would not draw any conclusions from Java style to Forth style.  In
> Forth THROW is currently not usually used for non-exceptional exits,
> but that would provide advantages (that are not relevant in Java) that
> I discussed in <2017Feb13.175259@mips.complang.tuwien.ac.at>.

Yes, I get that, and I can understand that the reasoning used there
make sense.

I don't think that there's anything Java-specific (or in any way
language-specific) about the idea that exceptions should be
exceptional.  It may well be that there is something special about
Forth (and there are many special things!) which means that CATCH and
THROW should be used for more for things than other languages do, but
right now I can't think of any reason why there might be.  (Well,
perhaps cost, but that strikes me as a fairly bad reason for such a
design decision.)

Having said that, I used CATCH and THROW to handle transaction aborts,
and they worked beautifully.

Andrew.

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

#59436

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2017-05-17 16:14 +0000
Message-ID	<2017May17.181425@mips.complang.tuwien.ac.at>
In reply to	#59386

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>I don't think that there's anything Java-specific (or in any way
>language-specific) about the idea that exceptions should be
>exceptional.

Sure, but does that mean that CATCH and THROW should be exceptional?
Why?  Just because they were originally intended for exceptions?  Not
a sufficient reason.

>  It may well be that there is something special about
>Forth (and there are many special things!) which means that CATCH and
>THROW should be used for more for things than other languages do, but
>right now I can't think of any reason why there might be.

Maybe you did not get <2017Feb13.175259@mips.complang.tuwien.ac.at>
after all.

The reason is that, in Forth, you frequently have to do some sequence
of 2DROP DROP FDROP 2r> 2DROP or somesuch in order to clean up
no-longer needed arguments on the stacks.  That's especially annoying
if you have to deal with a bunch of dependent conditions that you have
to check with ifs.  You get code like:

: foo
  2dup check-something if
    dup >r check-something-else if
      2dup fdup check-yet-another-thing if
         do the thing that depends on these conditions
         clean up the stacks exit then
      clean up the stacks for this branch exit then
    clean up the stacks for this branch exit then
  clean up the stacks for this branch ;

Or you can organize this with ELSEs; or with each IF in a separate
word, with local cleanups, but possibly long stack effects.  Or you
put the data in variables so that you don't have to worry about their
presence on the stacks; but wait, we are now in a multi-core world, so
we have to put it in user variables, and this local data will cost
space in every task.

Or, alternatively, you use THROW's ability to clean up all the stacks:

[: 2dup check-something ?lthrow
   dup >r check-something-else ?lthrow
   2dup fdup check-yet-another-thing ?throw
   do the thing that depends on these conditions 
   clean up the stacks
;] lexec

If the "do the thing" part leaves nothing on the stack, its cleanup
can be done by an LTHROW, too.

This style allows us to think about this code linearly instead of as a
complex IF cascade, and it frees us from having to adjust one or more
else branches whenever we change something in the checks.

- 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 2017: http://www.euroforth.org/ef17/

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

#59471

From	Andrew Haley <andrew29@littlepinkcloud.invalid>
Date	2017-05-18 03:05 -0500
Message-ID	<LfSdndoSbsJHyIDEnZ2dnUU7-VPNnZ2d@supernews.com>
In reply to	#59436

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>I don't think that there's anything Java-specific (or in any way
>>language-specific) about the idea that exceptions should be
>>exceptional.
> 
> Sure, but does that mean that CATCH and THROW should be exceptional?
> Why?  Just because they were originally intended for exceptions?  Not
> a sufficient reason.

Well, "exceptions should always be exceptional" is not a religious
doctrine for me, so to some extent I'm only repeating what has been
said by others.  It's a long discussion and I'm sure you've read the
points made.

But THROWing does effectively bypass actions at the end of a word, and
the maintenance programmer is going to have to be aware that if they
need some actions to happen they're going to have to change the way
they write.  So, in a program which uses exceptions heavily a common
pattern would change from

  open-action  stuff  close-action

to 

  open-action  [: stuff ;] catch >r  close-action  r> throw

which is more complicated.  (This is a standard pattern in Java, and
people sometimes forget to do it.)  I'm not sure it's an improvement.

>>It may well be that there is something special about Forth (and
>>there are many special things!) which means that CATCH and THROW
>>should be used for more for things than other languages do, but
>>right now I can't think of any reason why there might be.
> 
> Maybe you did not get <2017Feb13.175259@mips.complang.tuwien.ac.at>
> after all.
> 
> The reason is that, in Forth, you frequently have to do some sequence
> of 2DROP DROP FDROP 2r> 2DROP or somesuch in order to clean up
> no-longer needed arguments on the stacks.  That's especially annoying
> if you have to deal with a bunch of dependent conditions that you have
> to check with ifs.  You get code like:
> 
> : foo
>  2dup check-something if
>    dup >r check-something-else if
>      2dup fdup check-yet-another-thing if
>         do the thing that depends on these conditions
>         clean up the stacks exit then
>      clean up the stacks for this branch exit then
>    clean up the stacks for this branch exit then
>  clean up the stacks for this branch ;
> 
> Or you can organize this with ELSEs; or with each IF in a separate
> word, with local cleanups, but possibly long stack effects.  Or you
> put the data in variables so that you don't have to worry about their
> presence on the stacks; but wait, we are now in a multi-core world, so
> we have to put it in user variables, and this local data will cost
> space in every task.
> 
> Or, alternatively, you use THROW's ability to clean up all the stacks:
> 
> [: 2dup check-something ?lthrow
>   dup >r check-something-else ?lthrow
>   2dup fdup check-yet-another-thing ?throw
>   do the thing that depends on these conditions 
>   clean up the stacks
> ;] lexec

Mmm, and unconditional THROW which isn't checking anything, but merely
avoiding having to DROP stuff.

> If the "do the thing" part leaves nothing on the stack, its cleanup
> can be done by an LTHROW, too.
> 
> This style allows us to think about this code linearly instead of as a
> complex IF cascade, and it frees us from having to adjust one or more
> else branches whenever we change something in the checks.

I take your point, but it's not at all obvious to me that a well-
factored version of FOO, with stack changes and cleanups pushed down
into factors, wouldn't be better than THROWing.  It's really hard to
talk about something like this in the abstract.

In particular, it might make sense to keep the stack depth constant
across IFs so that the join at the end of FOO drops as many things as
needed.

I don't like ELSE DROP THEN very much any more than you do.  That's
why I like ?DUP, among other things.

Andrew.

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

#59512

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2017-05-18 16:33 +0000
Message-ID	<2017May18.183334@mips.complang.tuwien.ac.at>
In reply to	#59471

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
...
>But THROWing does effectively bypass actions at the end of a word, and
>the maintenance programmer is going to have to be aware that if they
>need some actions to happen they're going to have to change the way
>they write.  So, in a program which uses exceptions heavily a common
>pattern would change from
>
>  open-action  stuff  close-action
>
>to 
>
>  open-action  [: stuff ;] catch >r  close-action  r> throw
>
>which is more complicated.  (This is a standard pattern in Java, and
>people sometimes forget to do it.)  I'm not sure it's an improvement.

You need to do something like this anyway, even if THROW occurs just
in exceptional circumstances.  The typical way to make this nice and
simple is to factor it in a word that does the setup (open-action) and
cleanup (close-action) for all of the same kinds of things, and then
you just write

[: stuff ;] action

The only other alternative is to forget about cleanup, like Chuck
Moore is advocating (using BASE as example), but then you can forget
about composability and libraries.

I would say, that, contrary to your statement, unlike pre-Forth-94
(with its ABORT and ABORT" which bypassed everything without any
chance for the caller to effect a cleanup), CATCH almost offers a
guarantee that any exit will run through the post-CATCH code.  The
only standard exception to this is QUIT, but I hope nobody is using
this anymore in application code (it should actually be moved to TOOLS
EXT, or redefined in terms of THROW).

>I take your point, but it's not at all obvious to me that a well-
>factored version of FOO, with stack changes and cleanups pushed down
>into factors, wouldn't be better than THROWing.  It's really hard to
>talk about something like this in the abstract.

It's also hard to talk about this in the concrete, because for every
concrete example, the refactoring camp will provide some refactoring
and declare "mission accomplished", like George W. Bush did in Iraq,
ignoring the fact that the resulting factoring may not be the best for
further maintenance, and anyway, the code typically had a long and
tortuous past (with the cleanup code costing all the time) until it
became an example for the factoring capabilities of c.l.f
participants.

Anyway, I have had this problem and bugs from it a number of times,
and when I wrote about it in February, I looked through, IIRC
prims2x.fs, and found a number of nested IFs with stack cleanup (DROP
2DROP R> DROP and the like) before THEN.  I could search again and
post the code here, but I doubt that you would find it a useful
factoring exercise, because you don't know the context.

>In particular, it might make sense to keep the stack depth constant
>across IFs so that the join at the end of FOO drops as many things as
>needed.

Hmm, fill the stacks at the start, so that the stack depth is always
the same?  Unfortunately, often you can compute some items only after
you have checked a condition.  You could put a placeholder on the
stack until then, but I don't consider this better factoring.

>I don't like ELSE DROP THEN very much any more than you do.  That's
>why I like ?DUP, among other things.

Does not help for ELSE 2DROP THEN or ELSE R> DROP THEN.

- 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 2017: http://www.euroforth.org/ef17/

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

#59513

From	Andrew Haley <andrew29@littlepinkcloud.invalid>
Date	2017-05-18 12:43 -0500
Message-ID	<yZednUvhlPPXQIDEnZ2dnUU7-fvNnZ2d@supernews.com>
In reply to	#59512

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> ...
>>But THROWing does effectively bypass actions at the end of a word, and
>>the maintenance programmer is going to have to be aware that if they
>>need some actions to happen they're going to have to change the way
>>they write.  So, in a program which uses exceptions heavily a common
>>pattern would change from
>>
>>  open-action  stuff  close-action
>>
>>to 
>>
>>  open-action  [: stuff ;] catch >r  close-action  r> throw
>>
>>which is more complicated.  (This is a standard pattern in Java, and
>>people sometimes forget to do it.)  I'm not sure it's an improvement.
> 
> You need to do something like this anyway, even if THROW occurs just
> in exceptional circumstances. 

Not exactly.  Yes, if THROW can occur within the actions of stuff, but
that is not a given.  It's a matter of style: if stuff does not throw
or cleans up any exceptions for itself then you don't have to do that.

> The typical way to make this nice and simple is to factor it in a
> word that does the setup (open-action) and cleanup (close-action)
> for all of the same kinds of things, and then you just write
> 
> [: stuff ;] action
> 
> The only other alternative is to forget about cleanup, like Chuck
> Moore is advocating (using BASE as example), but then you can forget
> about composability and libraries.
> 
> I would say, that, contrary to your statement, unlike pre-Forth-94
> (with its ABORT and ABORT" which bypassed everything without any
> chance for the caller to effect a cleanup), CATCH almost offers a
> guarantee that any exit will run through the post-CATCH code.

CATCH does, yes, but THROW does not, and ABORT has even worse problems
than THROW.  (I can't think of a good reason why production code
should ever ABORT, but given time perhaps someone could think of one.)
So, no, the reality is not contrary to my statement.  The contrast is
between returning status information where a caller needs to know and
THROWing.  There's a choice here, but it's not clear to me which will
result in better programs.

>>I take your point, but it's not at all obvious to me that a well-
>>factored version of FOO, with stack changes and cleanups pushed down
>>into factors, wouldn't be better than THROWing.  It's really hard to
>>talk about something like this in the abstract.
> 
> It's also hard to talk about this in the concrete, because for every
> concrete example, the refactoring camp will provide some refactoring
> and declare "mission accomplished",

Perhaps so.  That doesn't make them wrong.  Not always, anyway.

>>In particular, it might make sense to keep the stack depth constant
>>across IFs so that the join at the end of FOO drops as many things as
>>needed.
> 
> Hmm, fill the stacks at the start, so that the stack depth is always
> the same?  Unfortunately, often you can compute some items only after
> you have checked a condition.  You could put a placeholder on the
> stack until then, but I don't consider this better factoring.

Probably not.  It depends on how complex the stack handing gets to be.

> 
>> I don't like ELSE DROP THEN very much any more than you do.  That's
>> why I like ?DUP, among other things.
> 
> Does not help for ELSE 2DROP THEN or ELSE R> DROP THEN.

No, but it's a big fat clue that there are sometimes better ways to do
it.

Andrew.

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

#59475

From	Andrew Haley <andrew29@littlepinkcloud.invalid>
Date	2017-05-18 04:01 -0500
Message-ID	<dLednZEUu6ub_oDEnZ2dnUU7-aPNnZ2d@supernews.com>
In reply to	#59436

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> 
> The reason is that, in Forth, you frequently have to do some sequence
> of 2DROP DROP FDROP 2r> 2DROP or somesuch in order to clean up
> no-longer needed arguments on the stacks.  That's especially annoying
> if you have to deal with a bunch of dependent conditions that you have
> to check with ifs.  You get code like:
> 
> : foo
>  2dup check-something if
>    dup >r check-something-else if
>      2dup fdup check-yet-another-thing if
>         do the thing that depends on these conditions
>         clean up the stacks exit then
>      clean up the stacks for this branch exit then
>    clean up the stacks for this branch exit then
>  clean up the stacks for this branch ;
> 
> Or you can organize this with ELSEs; or with each IF in a separate
> word, with local cleanups, but possibly long stack effects.  Or you
> put the data in variables so that you don't have to worry about their
> presence on the stacks; but wait, we are now in a multi-core world, so
> we have to put it in user variables, and this local data will cost
> space in every task.
> 
> Or, alternatively, you use THROW's ability to clean up all the stacks:
> 
> [: 2dup check-something ?lthrow
>   dup >r check-something-else ?lthrow
>   2dup fdup check-yet-another-thing ?throw
>   do the thing that depends on these conditions 
>   clean up the stacks
> ;] lexec

Thinking about this some more, something like

: foo
   sp@ >r
   2dup check-something if
     dup >r check-something-else if
       2dup fdup check-yet-another-thing if
         do the thing that depends on these conditions
   then then then
   r> sp! ;

looks much better to me.  There's no need for the EXECUTE and the
messing about with the return stack at all.  THROW is overkill for a
job like this, surely?  (OK, so there's the fp-stack to be DROPped as
well, but I'm you get the idea.  Maybe a pair of words <MARK MARK>
which mark and reset both stacks would be better.)

Andrew.

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

#59509

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2017-05-18 15:41 +0000
Message-ID	<2017May18.174156@mips.complang.tuwien.ac.at>
In reply to	#59475

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Or, alternatively, you use THROW's ability to clean up all the stacks:
>> 
>> [: 2dup check-something ?lthrow
>>   dup >r check-something-else ?lthrow
>>   2dup fdup check-yet-another-thing ?throw
>>   do the thing that depends on these conditions 
>>   clean up the stacks
>> ;] lexec
>
>Thinking about this some more, something like
>
>: foo
>   sp@ >r
>   2dup check-something if
>     dup >r check-something-else if
>       2dup fdup check-yet-another-thing if
>         do the thing that depends on these conditions
>   then then then
>   r> sp! ;
>
>looks much better to me.  There's no need for the EXECUTE and the
>messing about with the return stack at all.

Actually, in the example above you need to clean up the return stack
as well as the FP stack and the data stack; note the >R in the second
line of my code (fourth line of your code).  And therefore the "R>
SP!"  part will fail if the first condition is true.

>  THROW is overkill for a
>job like this, surely?

Let's see: THROW does three things:

1) clean up the stacks
2) determine the dynamically enclosing CATCH
3) jump there

For this usage we need the cleanup, and we need a jump.  But yes,
point 2 above is overkill (but not particularly expensive).  We can
think about something that fits better, and I will do that below, but
THROW has the advantage that it is already standard and widely
available.

SP@ SP! are non-standard, but at least widely available.  Disadvantages:

- you also need RP@ RP! and FP@ FP! for the other stacks; and where do
  you store the original values then?

- For systems with simple compilers, SP@ SP! is cheap, but for systems
  with sophisticated compilers, it is expensive: it essentially dumbs
  down the sophisticated compiler to the level of the simple compiler
  for parts of the program, unless data-flow analysis can guarantee
  the data flow from SP@ to SP!.  CATCH and THROW are significantly
  easier to handle efficiently for a sophisticated compiler, because
  the THROW is guaranteed to clean up the stack, with no possibility
  of setting the stack pointer to an arbitrary value.

>Maybe a pair of words <MARK MARK>
>which mark and reset both stacks would be better.)

Or rather: all three stacks.  And then you do the jump part
separately, with IFs and a bunch of THENs.  Is there any circumstance
where we want to split the THENs from the MARK>?  I only can think of
a case where the THENs are not quite appropriate:

: foo
   <MARK
   2dup check-something if
     dup >r check-something-else if
       2dup fdup check-yet-another-thing if
         do the thing that depends on these conditions
         leave something on the stacks
   AHEAD THENs-for-the-IFs MARK>
     put something on the stacks to match up the success branch
   THEN ;

So the "AHEAD THENs-for-the-IFs" would be a kind of super-ELSE, but
the MARK> would still be right after these THENs.  So maybe "AHEAD
THENSs-for-the-ifs MARK>" should be combined into one word, say
CLEANUP>; then that example would become:

: foo
   <MARK
   2dup check-something if
     dup >r check-something-else if
       2dup fdup check-yet-another-thing if
         do the thing that depends on these conditions
         leave something on the stacks
   CLEANUP>
     put something on the stacks to match up the success branch
   THEN ;

A cosmetic issue: Using IF turns this conceptually (and optically, if
you use an editor with auto-indent) from a sequence (with exits) into
an if-cascade.  The reasoning for a sequence is simpler (especially if
the exits have guaranteed cleanup), but with the IFs, you have to look
at the whole thing to see that you can reason about it as a sequence.

- 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 2017: http://www.euroforth.org/ef17/

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

#59511

From	Andrew Haley <andrew29@littlepinkcloud.invalid>
Date	2017-05-18 11:58 -0500
Message-ID	<bvGdnXHcW-UgT4DEnZ2dnUU7-TXNnZ2d@supernews.com>
In reply to	#59509

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Or, alternatively, you use THROW's ability to clean up all the stacks:
>>> 
>>> [: 2dup check-something ?lthrow
>>>   dup >r check-something-else ?lthrow
>>>   2dup fdup check-yet-another-thing ?throw
>>>   do the thing that depends on these conditions 
>>>   clean up the stacks
>>> ;] lexec
>>
>>Thinking about this some more, something like
>>
>>: foo
>>   sp@ >r
>>   2dup check-something if
>>     dup >r check-something-else if
>>       2dup fdup check-yet-another-thing if
>>         do the thing that depends on these conditions
>>   then then then
>>   r> sp! ;
>>
>>looks much better to me.  There's no need for the EXECUTE and the
>>messing about with the return stack at all.
> 
> Actually, in the example above you need to clean up the return stack
> as well as the FP stack and the data stack; note the >R in the second
> line of my code (fourth line of your code).  And therefore the "R>
> SP!"  part will fail if the first condition is true.

Ah, good point.  I missed that.

>>  THROW is overkill for a job like this, surely?
> 
> Let's see: THROW does three things:
> 
> 1) clean up the stacks
> 2) determine the dynamically enclosing CATCH
> 3) jump there
> 
> For this usage we need the cleanup, and we need a jump.  But yes,
> point 2 above is overkill (but not particularly expensive).  We can
> think about something that fits better, and I will do that below, but
> THROW has the advantage that it is already standard and widely
> available.
> 
> SP@ SP! are non-standard, but at least widely available.  Disadvantages:
> 
> - you also need RP@ RP! and FP@ FP! for the other stacks; and where do
>  you store the original values then?

I would have thought it advantageous to insist that the return stack
should not be unbalanced if people really are going to do stuff like
this, but even in discussing stuff like this we're halfway to
damnation already, so I suppose we might as well go the whole way.  I
accept that's a matter of a preferred style, and this is not mine: I
believe that people should tidy up their stacks just like they take
out their garbage.  Doubly so for their return stacks.

>>Maybe a pair of words <MARK MARK> which mark and reset both stacks
>>would be better.)
> 
> Or rather: all three stacks. 

Well, two would be better IMO: then it's just a matter of pushing FP
and SP.

> And then you do the jump part separately, with IFs and a bunch of
> THENs.  Is there any circumstance where we want to split the THENs
> from the MARK>?  I only can think of a case where the THENs are not
> quite appropriate:
> 
> : foo
>   <MARK
>   2dup check-something if
>     dup >r check-something-else if
>       2dup fdup check-yet-another-thing if
>         do the thing that depends on these conditions
>         leave something on the stacks
>   AHEAD THENs-for-the-IFs MARK>
>     put something on the stacks to match up the success branch
>   THEN ;

If ever there were a good use for EXIT-in-the middle it's surely this.

Andrew.

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

#59521

From	Alex <alex@rivadpm.com>
Date	2017-05-18 22:57 +0100
Message-ID	<ofl56t$ia5$1@dont-email.me>
In reply to	#59509

On 5/18/2017 16:41, Anton Ertl wrote:
> Let's see: THROW does three things:
> 
> 1) clean up the stacks
> 2) determine the dynamically enclosing CATCH
> 3) jump there
> 
> For this usage we need the cleanup, and we need a jump.  But yes,
> point 2 above is overkill (but not particularly expensive). 

(2) comes pretty much for free; it's the RET to the address put there by 
CATCH's call, after THROW restores the saved rstack depth.

-- 
Alex

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

#59373

From	"HAA" <someone@microsoft.com>
Date	2017-05-17 00:32 +1000
Message-ID	<off2ib$hes$1@gioia.aioe.org>
In reply to	#59355

Alex wrote:
> On 5/16/2017 09:42, Gerry Jackson wrote:
> > On 16/05/2017 01:24, HAA wrote:
> >> Lars Brinkhoff wrote:
> >>> HAA wrote:
> >>>> It expresses a functionality which at the time was implemented through
> >>>> R> DROP.  For all I know ANS TC simply forgot to consider this use
> >>>> in its
> >>>> R> deliberations.
> >>>
> >>> Isn't it the case that the 1994 ANS explicitly spells out that return
> >>> addresses may not be accessible at all by R>?
> >>
> >> Exactly.
> >
> > So they didn't forget about it, they chose to make it non-standard.
> >
>
> And gave us CATCH and THROW, a much better & portable solution that
> allows you to mark a place and return to it without any return stack
> dependencies. Why more don't use it is a little mystifying.

I'm happy to give credit to ANS when they get something right.
But misapplying what they've provided is something only a fan will do.

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

#59374

From	Alex <alex@rivadpm.com>
Date	2017-05-16 15:53 +0100
Message-ID	<off3iv$koq$1@dont-email.me>
In reply to	#59373

On 5/16/2017 15:32, HAA wrote:
> Alex wrote:
>> On 5/16/2017 09:42, Gerry Jackson wrote:
>>> On 16/05/2017 01:24, HAA wrote:
>>>> Lars Brinkhoff wrote:
>>>>> HAA wrote:
>>>>>> It expresses a functionality which at the time was implemented through
>>>>>> R> DROP.  For all I know ANS TC simply forgot to consider this use
>>>>>> in its
>>>>>> R> deliberations.
>>>>>
>>>>> Isn't it the case that the 1994 ANS explicitly spells out that return
>>>>> addresses may not be accessible at all by R>?
>>>>
>>>> Exactly.
>>>
>>> So they didn't forget about it, they chose to make it non-standard.
>>>
>>
>> And gave us CATCH and THROW, a much better & portable solution that
>> allows you to mark a place and return to it without any return stack
>> dependencies. Why more don't use it is a little mystifying.
> 
> I'm happy to give credit to ANS when they get something right.
> But misapplying what they've provided is something only a fan will do.
> 

How is the proposed use (avoiding non-portable rstack fiddling) 
"misapplying" CATCH/THROW?

-- 
Alex

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

#59256

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2017-05-15 05:29 +0000
Message-ID	<2017May15.072905@mips.complang.tuwien.ac.at>
In reply to	#59223

humptydumpty <ouatubi@gmail.com> writes:
>On Sunday, May 14, 2017 at 5:21:50 PM UTC+3, Andrew Haley wrote:
>> No.  That is not how it happened.  ANS did not preclude return stack
>> hackery because it wasn't portable anyway.  Before the ANS process
>> began, the number of return stack items pushed by a colon definition
>> wasn't always 1.  And maybe you'd even be using a different stack for
>> return addresses.
>
>This is mind boggling! Was that Forth? What is the percentage
>of such implementations from all Forth implementations?

F-PC, possibly the most popular Forth system at the time of Forth-94
standardization, had two cells per return address.  There are reports
of popular microcontrollers (IIRC 8051) that have an on-chip
return-address stack without connection to the data part of the chip,
i.e., the stack for >R R> has to be implemented elsewhere.

- 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 2017: http://www.euroforth.org/ef17/

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

#59259

From	humptydumpty <ouatubi@gmail.com>
Date	2017-05-14 23:00 -0700
Message-ID	<ad5c86a1-bd1f-49e5-a7c5-d328aa2e8dc9@googlegroups.com>
In reply to	#59256

On Monday, May 15, 2017 at 8:40:08 AM UTC+3, Anton Ertl wrote:
> humptydumpty writes:
> >On Sunday, May 14, 2017 at 5:21:50 PM UTC+3, Andrew Haley wrote:
> >> No.  That is not how it happened.  ANS did not preclude return stack
> >> hackery because it wasn't portable anyway.  Before the ANS process
> >> began, the number of return stack items pushed by a colon definition
> >> wasn't always 1.  And maybe you'd even be using a different stack for
> >> return addresses.
> >
> >This is mind boggling! Was that Forth? What is the percentage
> >of such implementations from all Forth implementations?
> 
> F-PC, possibly the most popular Forth system at the time of Forth-94
> standardization, had two cells per return address.  There are reports
> of popular microcontrollers (IIRC 8051) that have an on-chip
> return-address stack without connection to the data part of the chip,
> i.e., the stack for >R R> has to be implemented elsewhere.

That return address is a segment:offset pair on F-PC does not change
the logical way to manipulate partial continuations.

I'll take a look onto 8051 CamelFORTH of Brad Rodriguez. Thank you.
 
> 
> - 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 2017: http://www.euroforth.org/ef17/

--
Have a nice day,
hum9

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

#59433

From	rickman <gnuarm@gmail.com>
Date	2017-05-17 12:27 -0400
Message-ID	<ofhtft$jd$1@dont-email.me>
In reply to	#59223

On 5/14/2017 1:43 PM, humptydumpty wrote:
> On Sunday, May 14, 2017 at 5:21:50 PM UTC+3, Andrew Haley wrote:
>> HAA wrote:
>>
>>> In the days when "return stack" meant return stack and threaded code
>>> was the norm R> DROP is what you would use.  ANS precludes this,
>>> forcing programmers to adopt inefficient solutions.
>>
>> No.  That is not how it happened.  ANS did not preclude return stack
>> hackery because it wasn't portable anyway.  Before the ANS process
>> began, the number of return stack items pushed by a colon definition
>> wasn't always 1.  And maybe you'd even be using a different stack for
>> return addresses.
>
> This is mind boggling! Was that Forth? What is the percentage
> of such implementations from all Forth implementations?
>
>>  So maybe the R> DROP trick would work, maybe not.
>
> But this is not a trick. Is applying knowledge that on return-stack
> is the address of continuation(partial) of current definition caller.
>
>>
>> In that sense, the situation is not any different post-ANS: if you
>> want to depend on a colon definition pushing one item onto the return
>> stack you can still assume that.  ANS did not cause this trick to stop
>> working: it was descriptive rather than prescriptive.
>>
>>> Here's an example of a routine that deserves to be as efficient as
>>> it looks.
>>>
>>> : ?# ( ud -- ud )  #  2dup d0= if  r> drop  then ;
>>>
>>> : #,S ( ud -- 0 0 )  begin ?#  ?#  ?#  [char] , hold  again ;
>>
>> I hope that wouldn't pass review.
>
> This is a very nice factored code!
>
> What matter is idea behind code. User will modify  '?#'  definition
> accordingly with used Forth implementation, if necessary, or choose
> another Forth implementation.

Huh?  I didn't realize the idea of sharing code was so it could be 
modified to work.  I thought the idea of writing standard conforming 
code was to share without modification.  Heck, this is the sort of code 
that gives a language a bad name.

Another problem with it is compatibility with debuggers.  I don't 
normally use them, but setting a breakpoint anywhere after the first use 
of ?# would give confusing results when the code executes right past the 
breakpoint without stopping.  You would only figure out why if you dig 
into the underlying code.

The same thing would happen if you insert debugging statements.  I often 
do that and work from the top down to isolate the problem.  It is very 
distracting when you insert debugging statements and they aren't executed.

There is a reason why the idea of structured code was invented.

-- 

Rick C

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

#59275

From	"Rudy Velthuis" <newsgroups@rvelthuis.de>
Date	2017-05-15 09:16 +0000
Message-ID	<xn0kq09hi6okud006@nntp.aioe.org>
In reply to	#59199

HAA wrote:

> Rudy Velthuis wrote:
> > humptydumpty wrote:
> > 
> > > > Yes you are right. Anton Ertls suggestion is perfect:
> > > > 
> > > > : ?exit postpone if postpone exit postpone then ; immediate
> > > > 
> > > > Nowadays I focus on calculations and I've stopped thinking
> > > > outside the box... :)
> > > 
> > > LOL!
> > > 
> > > Then what "return stack" means? :)
> > 
> > Different things in different systems. And, as I said, there will be
> > many systems that only put one cell on the return stack if they
> > enter a definition, so 2R> and 2DROP would be wrong already.
> 
> But it does raise the issue of wanting to drop a level. 

Well, how do you define "returning" from a definition to the "calling"
definition? That is returning to a previous level, in a way.

-- 
Rudy Velthuis        http://www.rvelthuis.de

"I don't approve of political jokes... I've seen too many of them
 get elected." -- unknown

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

#59284

From	"Rudy Velthuis" <newsgroups@rvelthuis.de>
Date	2017-05-15 09:55 +0000
Message-ID	<xn0kq0agd5wcdzr002@nntp.aioe.org>
In reply to	#59199

HAA wrote:

> Rudy Velthuis wrote:
> > humptydumpty wrote:
> > 
> > > > Yes you are right. Anton Ertls suggestion is perfect:
> > > > 
> > > > : ?exit postpone if postpone exit postpone then ; immediate
> > > > 
> > > > Nowadays I focus on calculations and I've stopped thinking
> > > > outside the box... :)
> > > 
> > > LOL!
> > > 
> > > Then what "return stack" means? :)
> > 
> > Different things in different systems. And, as I said, there will be
> > many systems that only put one cell on the return stack if they
> > enter a definition, so 2R> and 2DROP would be wrong already.
> 
> But it does raise the issue of wanting to drop a level.

Depends on how you define "level". I think that if you call a
definition, you go one level deeper and if you return (exit) from that
definition, you go back (up) one level again. That is what I would call
"dropping a level".

-- 
Rudy Velthuis        http://www.rvelthuis.de

"I can envision a small cottage somewhere, with a lot of
 writing paper, and a dog, and a fireplace and maybe enough
 money to give myself some Irish coffee now and then and
 entertain my two friends."
 -- Richard Van de Geer, letter, 1975, last American to die in
 Vietnam War, Time, 1985

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

#59172

From	"Rudy Velthuis" <newsgroups@rvelthuis.de>
Date	2017-05-13 14:25 +0000
Message-ID	<xn0kpxogz4ib1hw00f@nntp.aioe.org>
In reply to	#59148

humptydumpty wrote:

> On Saturday, May 13, 2017 at 3:01:03 AM UTC+3, lehs wrote:
> > Den fredag 12 maj 2017 kl. 16:20:24 UTC+2 skrev Rudy Velthuis:
> > > lehs wrote:
> > > 
> > > > : ?exit ( flag -- )  if 2r> 2drop then ;
> > > > 
> > > > I'm doing a kind of filtering word and want to replace  IF EXIT
> > > > THEN with  ?EXIT if this works.
> > > 
> > > Probably only on indirectly threaded systems, and even there,
> > > there may be more or fewer items on the return stack.
> > > 
> > > -- 
> > > Rudy Velthuis        http://www.rvelthuis.de
> > > 
> > > "In the 1980s capitalism triumphed over communism. In the 1990s
> > >  it triumphed over democracy."
> > >  -- David Korten
> > 
> > Yes you are right. Anton Ertls suggestion is perfect:
> > 
> > : ?exit postpone if postpone exit postpone then ; immediate 
> > 
> > Nowadays I focus on calculations and I've stopped thinking outside
> > the box... :)
> 
> LOL!
> 
> Then what "return stack" means? :)
> 
> Please, review what "return stack" stands for every kind of
>  threading. Also what "subroutine" means for in generic
>  programming.
> 
> Return stack manipulations  does *not work* for inlined
>  or tail-recursion optimized words.

Indeed. Now I am wondering what the fun is about. Why the LOL! and whom
are you telling this? I already said it won't work in general, but it
may work on *some* indirect threading systems (obviously the ones that
do not do inlining or tail-recursion optimization and that push two
cells when entering a definition).

<shrug>

-- 
Rudy Velthuis        http://www.rvelthuis.de

"I think Microsoft named .Net so it wouldn’t show up in a
 Unix directory listing.” -- Oktal

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

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

csiph-web

Would ?EXIT work in all ANS-Forth systems?

Contents

#59366

#59377

#59384

#59386

#59436

#59471

#59512

#59513

#59475

#59509

#59511

#59521

#59373

#59374

#59256

#59259

#59433

#59275

#59284

#59172