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

#59892

From	"HAA" <someone@microsoft.com>
Date	2017-05-27 15:04 +1000
Message-ID	<ogb1bi$11u5$1@gioia.aioe.org>
In reply to	#59856

Alex wrote:
> On 5/26/2017 12:56, HAA wrote:
>
> > My other point was efficiency.  I'd be horrified at the thought of
> > anyone attempting to use catch/throw in code such as this.
> >
>
> Why?

Forth is about using the right tool for the job?

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

#59928

From	Alex <alex@rivadpm.com>
Date	2017-05-27 17:33 +0100
Message-ID	<ogc9hu$mqk$1@dont-email.me>
In reply to	#59892

On 5/27/2017 06:04, HAA wrote:
> Alex wrote:
>> On 5/26/2017 12:56, HAA wrote:
>>
>>> My other point was efficiency.  I'd be horrified at the thought of
>>> anyone attempting to use catch/throw in code such as this.
>>>
>>
>> Why?
> 
> Forth is about using the right tool for the job?
> 
> 
> 

OK, so why is it the wrong tool for the job? Is it the names?

-- 
Alex

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

#59997

From	"HAA" <someone@microsoft.com>
Date	2017-05-29 12:17 +1000
Message-ID	<ogg0em$eco$1@gioia.aioe.org>
In reply to	#59928

Alex wrote:
> On 5/27/2017 06:04, HAA wrote:
> > Alex wrote:
> >> On 5/26/2017 12:56, HAA wrote:
> >>
> >>> My other point was efficiency.  I'd be horrified at the thought of
> >>> anyone attempting to use catch/throw in code such as this.
> >>>
> >>
> >> Why?
> >
> > Forth is about using the right tool for the job?
> >
> >
> >
>
> OK, so why is it the wrong tool for the job? Is it the names?

I've presented code using what I believe is the best tool for the job.
If you believe otherwise, provide an alternative explaining why that
is best.

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

#59910

From	hum9 <obi65537@gmail.com>
Date	2017-05-27 00:33 -0700
Message-ID	<38c7b678-85d5-4d09-a837-e4ae8378ac50@googlegroups.com>
In reply to	#59852

On Friday, May 26, 2017 at 2:55:45 PM UTC+3, HAA wrote:
> humptydumpty wrote:
> > On Friday, May 26, 2017 at 8:03:30 AM UTC+3, obi6...@gmail.com wrote:
> > > On Wednesday, May 24, 2017 at 8:46:07 AM UTC+3, HAA wrote:
> > > >
> > > > : rdini  ( a u fid -- u a u | u ior )
> > > >   1 setfh ?dup if ( err) nip >ior unnest end  tuck ;
> > > >
> > > > : ranrw ( a' size mode -- a' size | a' u' )  \ read/write 128 byte disk file record
> > > >   33 + fcb swap bdos if  ( eof or disk full) drop  unnest  r>  then ;
> > > >
> > > > : fread ( a u1 -- a u2 )
> > > >   begin  dup while
> > > >     >r  \ u remaining
> > > >     setsiz r@ umin ( siz)
> > > >     dup recsiz = if  \ whole record
> > > >       over setdma  0 ranrw  \ direct to adr
> > > >     else \ partial record
> > > >       hbuf setdma  0 ranrw  \ to temp buffer
> > > >       2dup hbuf offs + -rot cmove \ copy partial to adr
> > > >     then
> > > >     dup >r +  rwp@  r@ m+  rwp!  2r> -  \ update file pos & u remaining
> > > >   repeat ;
> > > >
> > > > : read-file ( a u1 fid -- u2 ior )
> > > >   rdini ( u a u) fread ( u a' u') nip - 0 ;
> > >
> > >
> > > Just my taste of that code is:
> > > (I deleted my previous post because bad updating file pos & u remaining.)
> > >
> > > : rdini  ( a u fid -- a u | u ior )
> > >   1 setfh ?dup if ( err) nip >ior unnest then ;
> > >
> > > : rwrec  ( a size mode -- a size failure)  \ read/write 128 byte disk file record
> > >   33 + fcb swap bdos ;
> > >
> > > : +record   ( u a size mode -- u a size | u)
> > >   rwrec if 2drop unnest then ;
> > >
> > > : fread ( a u -- u')
> > >   begin dup while
> > >     tuck setsiz umin ( siz)
> > >     dup recsiz = if  \ whole record
> > >       over setdma  0 +record  \ direct to adr
> > >     else \ partial record
> > >       hbuf setdma  0 +record  \ to temp buffer
> > >       2dup hbuf offs + -rot cmove \ copy partial to adr
> > >     then
> > >     dup >r + rwp@  r@ m+  rwp!  swap r> - \ update file pos & u remaining
> > >   repeat nip ;
> > >
> > > : read-file ( a u1 fid -- u2 ior )
> > >   rdini ( a u) tuck fread ( u') nip - 0 ;
> > >
> > > Have a nice day,
> > > hum9
> >
> > Phew!
> >
> > : read-file ( a u1 fid -- u2 ior )
> >   rdini ( a u) tuck fread ( u') - 0 ;
> 
> Interesting to see you tackle that :)

It was a good exercise for me, a little bit of DOS nostalgia, 
and I think I learned something :)

>  The point of the example was to demonstrate
> the use of unnest to gain access to a value previously placed on the return stack.
> While you managed to avoid the need for it in this case, it remains a feature of
> unnest.  My other point was efficiency.  I'd be horrified at the thought of anyone
> attempting to use catch/throw in code such as this.

At first time when I understood 'ranrw' and its use on 'fread'
I recognized that will be very hard to write a more efficient forth code.

I've seen that most time 2 items are used data stack which is
a sign of good factoring and readability/understanding.  Also
recognized a tight cooperation data/return stack, more than
in usual factoring.

Thanks for pointing to that forth gem :)

Have a nice day,
hum9

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

#59890

From	"HAA" <someone@microsoft.com>
Date	2017-05-27 14:53 +1000
Message-ID	<ogb0o0$11al$1@gioia.aioe.org>
In reply to	#59844

obi65537@gmail.com wrote:
> On Friday, May 26, 2017 at 8:03:30 AM UTC+3, obi6...@gmail.com wrote:
> > ...
> > Just my taste of that code is:
> > (I deleted my previous post because bad updating file pos & u remaining.)
> >
> > : rdini  ( a u fid -- a u | u ior )
> >   1 setfh ?dup if ( err) nip >ior unnest then ;
> > ...
>
> Phew!
>
> : read-file ( a u1 fid -- u2 ior )
>   rdini ( a u) tuck fread ( u') - 0 ;

Like the move of tuck from rdini to just before fread.  It's logically better
and simplifies the code a little.

I discover u2 is supposed to be meaningful when ior <> 0, so

    : rdini  ( a u fid -- a u | 0 ior )
      1 setfh ?dup if ( err) 0 swap 2nip >ior unnest then ;

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

#59914 — READ-FILE over-specified?

From	"HAA" <someone@microsoft.com>
Date	2017-05-27 21:28 +1000
Subject	READ-FILE over-specified?
Message-ID	<ogbns8$1dm$1@gioia.aioe.org>
In reply to	#59890

HAA wrote:
> ...
> I discover u2 is supposed to be meaningful when ior <> 0, so
>
>     : rdini  ( a u fid -- a u | 0 ior )
>       1 setfh ?dup if ( err) 0 swap 2nip >ior unnest then ;

Perhaps I was too hasty in implementing that "fix".

The ANS stipulation in question is here:

    11.6.1.2080 READ-FILE
    ...
    If an exception occurs, ior is the implementation-defined I/O result code, and
    u2 is the number of characters transferred to c-addr without an exception.

In practice an implementer will have no control over this since it is the OS
that determines what is returned when an exception occurs.  The 'common
practice' for OS appears to be to return a flag or code in case of error.  As to
the validity of the accompanying count (assuming it is returned at all) they
are typically silent.

Given this, I can only wonder what prompted ANS to include a 'feature' few
systems could accommodate in practice.  The majority of implementers
will simply return u2=0 when ior <>0 because it's the best they can do.
I'll finish with these two questions for discussion:

1. What did ANS imagine 'standard programs' would do with u2 in case of error?
2. What other languages stipulate a valid count be returned when their 'read'
    function encounters an error?

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

#59919 — Re: READ-FILE over-specified?

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2017-05-27 13:11 +0000
Subject	Re: READ-FILE over-specified?
Message-ID	<2017May27.151106@mips.complang.tuwien.ac.at>
In reply to	#59914

"HAA" <someone@microsoft.com> writes:
>The ANS stipulation in question is here:
>
>    11.6.1.2080 READ-FILE
>    ...
>    If an exception occurs, ior is the implementation-defined I/O result code, and
>    u2 is the number of characters transferred to c-addr without an exception.
>
>In practice an implementer will have no control over this since it is the OS
>that determines what is returned when an exception occurs.  The 'common
>practice' for OS appears to be to return a flag or code in case of error.  As to
>the validity of the accompanying count (assuming it is returned at all) they
>are typically silent.

POSIX says
<http://pubs.opengroup.org/onlinepubs/009695399/functions/read.html>:

|If a read() is interrupted by a signal after it has successfully read
|some data, it shall return the number of bytes read.

However, in that case read() does not indicate an error (because it
indicates an error by returning -1).

And for the ANSI C fread()
<http://pubs.opengroup.org/onlinepubs/009695399/functions/fread.html>:

|Upon successful completion, fread() shall return the number of
|elements successfully read which is less than nitems only if a read
|error or end-of-file is encountered. If size or nitems is 0, fread()
|shall return 0 and the contents of the array and the state of the
|stream remain unchanged. Otherwise, if a read error occurs, the error
|indicator for the stream shall be set, [CX] [Option Start] and errno
|shall be set to indicate the error. [Option End]

>Given this, I can only wonder what prompted ANS to include a 'feature' few
>systems could accommodate in practice.  The majority of implementers
>will simply return u2=0 when ior <>0 because it's the best they can do.
>I'll finish with these two questions for discussion:
>
>1. What did ANS imagine 'standard programs' would do with u2 in case of error?

Process it?  That is, unless they just THROW the ior as most programs
do.  Given that widespread practice, it would probably be better to
report the error only on the next invocation of READ-FILE.  A
straightforward implementation based on ANSI C fread() or POSIX read()
will behave that way anyway.

If you think it's a problem, will you make a proposal for fixing 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 2017: http://www.euroforth.org/ef17/

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

#60000 — Re: READ-FILE over-specified?

From	"HAA" <someone@microsoft.com>
Date	2017-05-29 13:47 +1000
Subject	Re: READ-FILE over-specified?
Message-ID	<ogg5jp$juv$1@gioia.aioe.org>
In reply to	#59919

Anton Ertl wrote:
> ...
> If you think it's a problem, will you make a proposal for fixing it?
>
> - anton

It's not a problem in the sense every implementation could comply with ANS
by ensuring read-file <>0 returns u2=0.  If common practice however is to
just implement whatever the OS provides (Win32F and SwiftForth to name
just two) then perhaps that's what the standard ought to reflect e.g.

    If an exception occurs, ior is the implementation-defined I/O result code,
    and u2 is undefined.

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

#59963 — Re: READ-FILE over-specified?

From	albert@cherry.spenarnc.xs4all.nl (Albert van der Horst)
Date	2017-05-28 09:44 +0200
Subject	Re: READ-FILE over-specified?
Message-ID	<ogdv4h$lff$1@cherry.spenarnc.xs4all.nl>
In reply to	#59914

In article <ogbns8$1dm$1@gioia.aioe.org>, HAA <someone@microsoft.com> wrote:
>HAA wrote:
>> ...
>> I discover u2 is supposed to be meaningful when ior <> 0, so
>>
>>     : rdini  ( a u fid -- a u | 0 ior )
>>       1 setfh ?dup if ( err) 0 swap 2nip >ior unnest then ;
>
>Perhaps I was too hasty in implementing that "fix".
>
>The ANS stipulation in question is here:
>
>    11.6.1.2080 READ-FILE
>    ...
>    If an exception occurs, ior is the implementation-defined I/O result code, and
>    u2 is the number of characters transferred to c-addr without an exception.
>
>In practice an implementer will have no control over this since it is the OS
>that determines what is returned when an exception occurs.  The 'common
>practice' for OS appears to be to return a flag or code in case of error.  As to
>the validity of the accompanying count (assuming it is returned at all) they
>are typically silent.
>
>Given this, I can only wonder what prompted ANS to include a 'feature' few
>systems could accommodate in practice.  The majority of implementers
>will simply return u2=0 when ior <>0 because it's the best they can do.
>I'll finish with these two questions for discussion:
>
>1. What did ANS imagine 'standard programs' would do with u2 in case of error?
>2. What other languages stipulate a valid count be returned when their 'read'
>    function encounters an error?


It is not the task of read to specify what meaning can still be
attached to the number of bytes.
You got an exception. The exception must specify what happened.
E.g. in case of a memory fault you should run for your money.
In case of an interrupted system call, the number of bytes read
are valid.

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]

#59970 — Re: READ-FILE over-specified?

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2017-05-28 13:41 +0000
Subject	Re: READ-FILE over-specified?
Message-ID	<2017May28.154130@mips.complang.tuwien.ac.at>
In reply to	#59963

albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>In case of an interrupted system call, the number of bytes read
>are valid.

That's the Unix solution to the PC-lusering problem.  It's the main
example of the famous "worse-is-better" part in an essay by Richard
Gabriel.  Basically, Unix (i.e., Ken Thompson) took the easy way out
and just returned enough info to allow continuing the system call,
shifting the problem to user mode.

That is not necessarily a problem, but what happened then is a
problem: This behaviour of the system call was exported to many other
places.

Ideally, for a blocking read(), you would have a system-call wrapper
that performs the user-level part of this design, i.e., puts a loop
around the system call, and then every user of the wrapper will see a
decent interface; and given that Unix works with system call wrappers
anyway (because the system call interface does not follow the C
calling convention), that would have been the logical place to deal
with the issue.

Unfortunately, Unix also supports non-blocking reads, and uses the
same system call, and, alas, the same wrapper for it.  So you don't
want to loop in the wrapper.  A better design would have been to have
two wrappers: one for the blocking read, and one for the non-blocking
read.

But it does not stop there: Standard C does not support non-blocking
I/O in the fopen()/fread()/etc. family of functions, yet the glibc
implementation of fread() also exports this behaviour of the Unix
read() system call; it does not make any sense there.

Finally, Gforth up to 0.7 (but not the current development version)
exports this behaviour: When I do

pad 50 stdin read-file

type "ab" and then change the window size, the READ-FILE returns (with
2 -37 as result, so there actually are Forth systems that return an
error for non-zero length) instead of continuing to wait for more
input.  We fixed this in the current development version, and now
READ-FILE behaves as is appropriate for a blocking interface.

I would recommend the same to any Forth implementor.

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

#59981 — Re: READ-FILE over-specified?

From	albert@cherry.spenarnc.xs4all.nl (Albert van der Horst)
Date	2017-05-28 19:59 +0200
Subject	Re: READ-FILE over-specified?
Message-ID	<ogf364$q13$1@cherry.spenarnc.xs4all.nl>
In reply to	#59970

In article <2017May28.154130@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>>In case of an interrupted system call, the number of bytes read
>>are valid.
>
>That's the Unix solution to the PC-lusering problem.  It's the main
>example of the famous "worse-is-better" part in an essay by Richard
>Gabriel.  Basically, Unix (i.e., Ken Thompson) took the easy way out
>and just returned enough info to allow continuing the system call,
>shifting the problem to user mode.
>
>That is not necessarily a problem, but what happened then is a
>problem: This behaviour of the system call was exported to many other
>places.
>
>Ideally, for a blocking read(), you would have a system-call wrapper
>that performs the user-level part of this design, i.e., puts a loop
>around the system call, and then every user of the wrapper will see a
>decent interface; and given that Unix works with system call wrappers
>anyway (because the system call interface does not follow the C
>calling convention), that would have been the logical place to deal
>with the issue.
>
>Unfortunately, Unix also supports non-blocking reads, and uses the
>same system call, and, alas, the same wrapper for it.  So you don't
>want to loop in the wrapper.  A better design would have been to have
>two wrappers: one for the blocking read, and one for the non-blocking
>read.
>
>But it does not stop there: Standard C does not support non-blocking
>I/O in the fopen()/fread()/etc. family of functions, yet the glibc
>implementation of fread() also exports this behaviour of the Unix
>read() system call; it does not make any sense there.

Good to know, but it doesn't change the bottomline. If you
get an exception you got to inspect the system information about
what the exception means.

>
>Finally, Gforth up to 0.7 (but not the current development version)
>exports this behaviour: When I do
>
>pad 50 stdin read-file
>
>type "ab" and then change the window size, the READ-FILE returns (with
>2 -37 as result, so there actually are Forth systems that return an
>error for non-zero length) instead of continuing to wait for more
>input.  We fixed this in the current development version, and now
>READ-FILE behaves as is appropriate for a blocking interface.

Is that on Windows? gforth 0.7.0 on Debian Wheezy doesn't behave that
way.

>
>I would recommend the same to any Forth implementor.

Inspected this potential problem for ciforth (lina/Linux and wina/wine).
Nothing much interesting happened.

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

#59353

From	Gerry Jackson <gerry@jackson9000.fsnet.co.uk>
Date	2017-05-16 09:42 +0100
Message-ID	<ofedqi$a3s$1@dont-email.me>
In reply to	#59339

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.

-- 
Gerry

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

#59355

From	Alex <alex@rivadpm.com>
Date	2017-05-16 09:53 +0100
Message-ID	<ofeegl$c7g$1@dont-email.me>
In reply to	#59353

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.

-- 
Alex

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

#59360

From	Andrew Haley <andrew29@littlepinkcloud.invalid>
Date	2017-05-16 04:53 -0500
Message-ID	<d5GdnW8mjMeYUYfEnZ2dnUU7-c3NnZ2d@supernews.com>
In reply to	#59355

Alex <alex@rivadpm.com> wrote:
> On 5/16/2017 09:42, Gerry Jackson wrote:
>> 
>> So they didn't forget about [return stack trickery], 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.

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.

Also, there is a philosophical objection to using THROW in anything
other than 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.)  And
exceptions can be very hard to debug.

Andrew.

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

#59362

From	albert@cherry.spenarnc.xs4all.nl (Albert van der Horst)
Date	2017-05-16 12:32 +0200
Message-ID	<ofekfh$emr$1@cherry.spenarnc.xs4all.nl>
In reply to	#59360

In article <d5GdnW8mjMeYUYfEnZ2dnUU7-c3NnZ2d@supernews.com>,
Andrew Haley  <andrew29@littlepinkcloud.invalid> wrote:
<SNIP>
>
>Also, there is a philosophical objection to using THROW in anything
>other than 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.)  And
>exceptions can be very hard to debug.

Probably it is the other way around. In many languages an exception
is made too complicated and slow. Then a rationalisation is given
in order to make that less apparent. The usual way to abuse
political correctness.

I don't mind a database search that ends in FOUND exception.
Abandon it all ! I've found it !

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

#59365

From	Alex <alex@rivadpm.com>
Date	2017-05-16 12:35 +0100
Message-ID	<ofeo0k$c56$1@dont-email.me>
In reply to	#59360

On 5/16/2017 10:53, Andrew Haley wrote:
> Alex <alex@rivadpm.com> wrote:
>> On 5/16/2017 09:42, Gerry Jackson wrote:
>>>
>>> So they didn't forget about [return stack trickery], 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.
> 
> Forth's CATCH/THROW is the lightest-weight exception-handling
> mechanism that I've seen, but it's still heavier than EXIT, which is

The lightest weight AFAIK uses quite a different formulation to 
CATCH/THROW.

Saving the stack pointers with CATCH has an overhead, and it's a good 
bit slower than a straightforward EXECUTE. If you are continually 
CATCHing and not THROWing, then the overhead might get to be significant.

The alternative is to map out error handlers by address range and have a 
TRY section. There's no CATCH overhead, as the code covered by the TRY 
range is mapped at compile time. Just EXECUTE inside your CATCH range 
and be damned; and if you are damned and THROW, then have the THROW code 
take the hit searching through the call stack into the pre-built address 
range table to find the appropriate TRY handler. (That search presumes 
some sort of order to the stack; either all return addresses or stack 
frames, which is very un-Forthish. Good for C though. Windows 64 bit 
uses a variation of this technique.)

But as a dynamic mechanism. CATCH/THROW takes some beating. Here's an 
STC x86 based MARK and UNWIND, which is even lighter weight than CATCH 
and THROW. (EAX is top of stack, the data stack is EBP.) Setup & exit on 
CATCH is 3 extra instructions (PUSH MOV POP ) (even EXECUTE has to drop 
the XT) and a THROW is 2 (MOV POP).

variable handler

code mark ( xt -- )
       mov     ecx eax              ( save xt )
       mov     eax { ebp }          ( drop xt )
       add     ebp cell
       push    { handler }          \ handler @ >r
       mov     { handler } esp      \ rp @ handler !
       call    ecx                  \ execute
       pop     { handler }          \ r> handler !
       ret
end-code

code unwind ( -- )
       mov     esp { handler }      \ handler @ rp!
       pop     { handler }          \ r> handler !
       ret
end-code

> (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.

For a handful of instructions, the considerable compile-time effort 
isn't probably worth it. Just don't do it inside a loop.

-- 
Alex

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

#59378

From	Andrew Haley <andrew29@littlepinkcloud.invalid>
Date	2017-05-16 10:48 -0500
Message-ID	<W6mdnQa9aanTgobEnZ2dnUU7-UmdnZ2d@supernews.com>
In reply to	#59365

Alex <alex@rivadpm.com> wrote:
> On 5/16/2017 10:53, Andrew Haley wrote:
>> Alex <alex@rivadpm.com> wrote:
>>> On 5/16/2017 09:42, Gerry Jackson wrote:
>>>>
>>>> So they didn't forget about [return stack trickery], 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.
>> 
>> Forth's CATCH/THROW is the lightest-weight exception-handling
>> mechanism that I've seen, but it's still heavier than EXIT, which is
> 
> The lightest weight AFAIK uses quite a different formulation to 
> CATCH/THROW.
> 
> Saving the stack pointers with CATCH has an overhead, and it's a
> good bit slower than a straightforward EXECUTE. If you are
> continually CATCHing and not THROWing, then the overhead might get
> to be significant.
> 
> The alternative is to map out error handlers by address range and
> have a TRY section. There's no CATCH overhead, as the code covered
> by the TRY range is mapped at compile time. Just EXECUTE inside your
> CATCH range and be damned; and if you are damned and THROW, then
> have the THROW code take the hit searching through the call stack
> into the pre-built address range table to find the appropriate TRY
> handler.

Yeah, exactly.  That's the heavyweight approaqch generally used by
GCC, Java, etc.  It highly opitimizes the CATCH at the cost of a much
more expensive THROW.

> But as a dynamic mechanism. CATCH/THROW takes some beating. Here's an 
> STC x86 based MARK and UNWIND, which is even lighter weight than CATCH 
> and THROW. (EAX is top of stack, the data stack is EBP.) Setup & exit on 
> CATCH is 3 extra instructions (PUSH MOV POP ) (even EXECUTE has to drop 
> the XT) and a THROW is 2 (MOV POP).

It's much the same, except that it doesn't return a code and restore
SP, I guess?

Andrew.

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

#59385

From	Alex <alex@rivadpm.com>
Date	2017-05-16 18:23 +0100
Message-ID	<offcc9$mfu$1@dont-email.me>
In reply to	#59378

On 5/16/2017 16:48, Andrew Haley wrote:

> 
> It's much the same, except that it doesn't return a code and restore
> SP, I guess?
> 

Yes, the data stack pointer is simply returned asis. You have to be 
absolutely certain as to what stack depth you expect on an UNWINDing 
super-return, so it's of limited use for deep unwinds.

-- 
Alex

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

#59421

From	Andrew Haley <andrew29@littlepinkcloud.invalid>
Date	2017-05-17 04:33 -0500
Message-ID	<AMGdncGpbuJphYHEnZ2dnUU7-cudnZ2d@supernews.com>
In reply to	#59385

Alex <alex@rivadpm.com> wrote:
> On 5/16/2017 16:48, Andrew Haley wrote:
> 
>> It's much the same, except that it doesn't return a code and restore
>> SP, I guess?
> 
> Yes, the data stack pointer is simply returned asis. You have to be 
> absolutely certain as to what stack depth you expect on an UNWINDing 
> super-return, so it's of limited use for deep unwinds.

I'm not sure what to think, really.  In a way I like it, but I'm not
quite sure.  It's certianly an interesting idea.  AFAICS it does
everything that fiddling with the return stack can usefully do, but in
a structured way.

Andrew.

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

#59425

From	Alex <alex@rivadpm.com>
Date	2017-05-17 12:29 +0100
Message-ID	<ofhc0v$vcv$1@dont-email.me>
In reply to	#59421

On 5/17/2017 10:33, Andrew Haley wrote:
> Alex <alex@rivadpm.com> wrote:
>> On 5/16/2017 16:48, Andrew Haley wrote:
>>
>>> It's much the same, except that it doesn't return a code and restore
>>> SP, I guess?
>>
>> Yes, the data stack pointer is simply returned asis. You have to be
>> absolutely certain as to what stack depth you expect on an UNWINDing
>> super-return, so it's of limited use for deep unwinds.
> 
> I'm not sure what to think, really.  In a way I like it, but I'm not
> quite sure.  It's certianly an interesting idea.  AFAICS it does
> everything that fiddling with the return stack can usefully do, but in
> a structured way.
> 
> Andrew.
> 

It's much like INTERCAL's COMEFROM; it might* be useful in implementing 
continuations. But I suspect it will only encourage a style sometimes 
called "wherethefuckarewe" programming by those tasked with maintenance.

The advantage of CATCH/THROW is that at least we know where we are in 
terms of both stacks rather than one. And we know how we got to the 
statement after the CATCH; either a THROW or the normal return mechanism.

*probably won't

-- 
Alex

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

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

csiph-web

Would ?EXIT work in all ANS-Forth systems?

Contents

#59892

#59928

#59997

#59910

#59890

#59914 — READ-FILE over-specified?

#59919 — Re: READ-FILE over-specified?

#60000 — Re: READ-FILE over-specified?

#59963 — Re: READ-FILE over-specified?

#59970 — Re: READ-FILE over-specified?

#59981 — Re: READ-FILE over-specified?

#59353

#59355

#59360

#59362

#59365

#59378

#59385

#59421

#59425