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

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

Recognizers discussion

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

Contents

  Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 15:27 +0100
    Recognizers discussion lehs <skydda.barnen@gmail.com> - 2017-05-02 07:52 -0700
      Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-02 08:19 -0700
        Re: Recognizers discussion lehs <skydda.barnen@gmail.com> - 2017-05-02 08:27 -0700
      Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 19:55 +0100
        Re: Recognizers discussion lehs <skydda.barnen@gmail.com> - 2017-05-03 02:38 -0700
          Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 15:16 +0000
    Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 17:05 +0100
      Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 17:23 +0100
        Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 17:26 +0100
        Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-02 13:03 -0500
          Re: Recognizers discussion Matthias Trute <matthias.trute@gmail.com> - 2017-05-02 12:44 -0700
            Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 04:36 -0500
          Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 13:28 +0000
            Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 09:13 -0500
    Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-02 12:35 -0500
      Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 18:53 +0100
        Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-02 13:10 -0500
          Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 19:22 +0100
          Re: Recognizers discussion Bernd Paysan <bernd@net2o.de> - 2017-05-02 22:53 +0000
            Re: Recognizers discussion Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-05-03 07:39 +0100
              Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-03 10:58 +0100
              Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 13:53 +0000
              Re: Recognizers discussion Bernd Paysan <bernd@net2o.de> - 2017-05-06 01:21 +0000
              Re: Recognizers discussion pahihu <pahihu@gmail.com> - 2017-05-06 00:22 -0700
                Re: Recognizers discussion Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-05-06 23:05 +0100
                  Re: Recognizers discussion pahihu <pahihu@gmail.com> - 2017-05-06 22:36 -0700
            Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 04:38 -0500
              Re: Recognizers discussion minforth@arcor.de - 2017-05-03 04:49 -0700
                Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 05:03 -0700
                  Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 09:02 -0500
                    Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 07:45 -0700
                      Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 11:24 -0500
                        Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 09:45 -0700
                          Re: Recognizers discussion Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-03 10:08 -0700
                          Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-09 15:56 +0000
                        Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-03 18:37 +0100
                          Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 11:07 -0700
                            Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-03 20:55 +0100
                            Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 02:47 -0500
                              Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 13:07 +0100
                                Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 07:59 -0500
                                  Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 17:38 +0100
                                    Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 12:42 -0500
                          Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 02:43 -0500
                            Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 13:05 +0100
                              Re: Recognizers discussion Ron Aaron <rambamist@gmail.com> - 2017-05-04 15:10 +0300
                                Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 13:25 +0100
                                  Re: Recognizers discussion Ron Aaron <rambamist@gmail.com> - 2017-05-04 15:33 +0300
                              Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 08:05 -0500
                      Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-09 15:54 +0000
                        Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-09 11:10 -0500
                          Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-10 11:49 +0000
                    Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 16:14 +0000
                      Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 13:02 -0500
                        Re: Recognizers discussion Bernd Paysan <bernd@net2o.de> - 2017-05-05 23:29 +0000
                          Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-07 03:56 -0500
                            Re: Recognizers discussion Bernd Paysan <bernd@net2o.de> - 2017-05-07 22:42 +0000
                              Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-08 04:08 -0500
                  Re: Recognizers discussion Julian Fondren <julian.fondren@gmail.com> - 2017-05-03 08:51 -0700
                    Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 09:38 -0700
                      Re: Recognizers discussion Julian Fondren <julian.fondren@gmail.com> - 2017-05-03 09:59 -0700
                        Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 10:16 -0700
                      Re: Recognizers discussion albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-03 22:04 +0200
                        Re: Recognizers discussion minforth@arcor.de - 2017-05-03 22:09 -0700
                  Re: Recognizers discussion Joel Rees <joel.rees@gmail.com> - 2017-05-07 19:50 -0700
                    Re: Recognizers discussion "Elizabeth D. Rather" <erather@forth.com> - 2017-05-07 21:33 -1000
                    Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-08 04:12 -0500
                      Re: Recognizers discussion Joel Rees <joel.rees@gmail.com> - 2017-05-08 20:21 -0700
                    FP stack (was: Recognizers discussion) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-08 12:35 +0000
                      Re: FP stack (was: Recognizers discussion) Joel Rees <joel.rees@gmail.com> - 2017-05-08 20:50 -0700
                        Re: FP stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-09 03:39 -0500
                          Re: FP stack Joel Rees <joel.rees@gmail.com> - 2017-05-09 20:59 -0700
                            Re: FP stack Julian Fondren <julian.fondren@gmail.com> - 2017-05-10 00:03 -0700
                            Re: FP stack Alex <alex@rivadpm.com> - 2017-05-10 08:10 +0100
                              Re: FP stack "Elizabeth D. Rather" <erather@forth.com> - 2017-05-09 21:24 -1000
                                Re: FP stack Julian Fondren <julian.fondren@gmail.com> - 2017-05-10 00:37 -0700
                                  Re: FP stack "Elizabeth D. Rather" <erather@forth.com> - 2017-05-09 22:53 -1000
                                Re: FP stack Alex <alex@rivadpm.com> - 2017-05-10 08:53 +0100
                                  Re: FP stack Ron Aaron <rambamist@gmail.com> - 2017-05-10 11:00 +0300
                                    Re: FP stack Paul Rubin <no.email@nospam.invalid> - 2017-05-10 01:02 -0700
                                      Re: FP stack Ron Aaron <rambamist@gmail.com> - 2017-05-10 11:06 +0300
                                    Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 09:58 +0000
                                      Re: FP stack Ron Aaron <rambamist@gmail.com> - 2017-05-10 14:17 +0300
                                      Re: FP stack Alex <alex@rivadpm.com> - 2017-05-10 13:09 +0100
                                        Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 15:05 +0000
                                Re: FP stack albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-10 11:43 +0200
                            Re: FP stack "HAA" <someone@microsoft.com> - 2017-05-10 18:34 +1000
                              Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 09:45 +0000
                                Re: FP stack "HAA" <someone@microsoft.com> - 2017-05-11 19:13 +1000
                                  Re: FP stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-11 04:50 -0500
                                    Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-11 16:18 +0000
                                      Re: FP stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-11 12:12 -0500
                                  Re: FP stack stephen@mpeforth.com (Stephen Pelc) - 2017-05-11 13:53 +0000
                                    Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-11 15:43 +0000
                                      Re: FP stack Joel Rees <joel.rees@gmail.com> - 2017-05-12 08:48 -0700
                                  Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-11 16:31 +0000
                                  Re: FP stack "Elizabeth D. Rather" <erather@forth.com> - 2017-05-11 10:18 -1000
                                    Re: FP stack Cecil Bayona <cbayona@cbayona.com> - 2017-05-11 15:37 -0500
                                      Re: FP stack "Elizabeth D. Rather" <erather@forth.com> - 2017-05-11 17:25 -1000
                                        Re: FP stack Cecil Bayona <cbayona@cbayona.com> - 2017-05-11 22:55 -0500
                                          Re: FP stack "HAA" <someone@microsoft.com> - 2017-05-13 14:24 +1000
                                        Re: FP stack albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-13 13:44 +0200
                            Re: FP stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-10 05:58 -0500
                        Re: FP stack (was: Recognizers discussion) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-09 13:50 +0000
                          Re: FP stack (was: Recognizers discussion) Joel Rees <joel.rees@gmail.com> - 2017-05-10 00:25 -0700
                            Re: FP stack (was: Recognizers discussion) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 11:39 +0000
                              Re: FP stack (was: Recognizers discussion) Joel Rees <joel.rees@gmail.com> - 2017-05-10 11:49 -0700
                      Re: FP stack (was: Recognizers discussion) "HAA" <someone@microsoft.com> - 2017-05-09 21:15 +1000
                    Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-09 14:16 +1000
                Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 08:57 -0500
                  Re: Recognizers discussion minforth@arcor.de - 2017-05-03 07:54 -0700
                    Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 11:30 -0500
                      Re: Recognizers discussion Cecil Bayona <cbayona@cbayona.com> - 2017-05-03 14:05 -0500
                  Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-03 18:42 +0100
                    Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 02:51 -0500
                    Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-04 22:29 +1000
                      Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 13:41 +0100
                        Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 09:06 -0500
                          Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-15 12:22 +0000
                            Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 07:36 -0500
                              Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-18 21:21 +0000
                              Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-18 21:24 +0000
                        Re: Recognizers discussion albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-04 20:17 +0200
                        Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-05 11:03 +1000
                          Re: Recognizers discussion minforth@arcor.de - 2017-05-05 00:16 -0700
                            Re: Recognizers discussion JUERGEN <epldfpga@aol.com> - 2017-05-05 13:15 -0700
                            Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-06 16:49 +1000
                          Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-05 21:00 +0100
        Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-09 14:17 +0000
          Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-09 15:46 +0100
            Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-10 11:50 +0000
              Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-10 13:11 +0100
                Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-10 13:49 +0000
                  Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-10 15:57 +0100
                    Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-12 14:17 +0000
    Re: Recognizers discussion "Elizabeth D. Rather" <erather@forth.com> - 2017-05-02 09:25 -1000
      Re: Recognizers discussion albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-03 01:19 +0200
      Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-05 15:50 +0000
        Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-08 11:43 +1000
          Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-08 19:17 +0000
            Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-09 14:25 +0000
              Re: Recognizers discussion "Elizabeth D. Rather" <erather@forth.com> - 2017-05-09 21:22 -1000
                Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-13 13:33 +1000
                  Re: Recognizers discussion "Elizabeth D. Rather" <erather@forth.com> - 2017-05-12 21:32 -1000
                    Re: Recognizers discussion Howerd <howerdo@yahoo.co.uk> - 2017-05-13 07:12 -0700
                  Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-13 14:30 +0000
    Re: Recognizers discussion rickman <gnuarm@gmail.com> - 2017-05-04 11:37 -0400
      Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 17:51 +0100
        Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-05 07:31 +0000
          Re: Recognizers discussion Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-05 20:35 +0200
            Re: Recognizers discussion minforth@arcor.de - 2017-05-05 12:27 -0700
            Re: Recognizers discussion Cecil Bayona <cbayona@cbayona.com> - 2017-05-05 15:03 -0500
            Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-06 16:26 +0000
              Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-06 18:17 +0100
                Re: Recognizers discussion Brad Eckert <hwfwguy@gmail.com> - 2017-05-06 12:26 -0700
                  Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-06 21:39 +0100
              Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-07 03:58 -0500
                Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-07 10:39 +0100
                  Re: Recognizers discussion Bernd Paysan <bernd@net2o.de> - 2017-05-07 23:39 +0000
                    Re: Recognizers discussion Paul Rubin <no.email@nospam.invalid> - 2017-05-07 17:38 -0700
                      Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-08 13:40 +0000
                    Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-08 13:25 +0000
                      Re: Recognizers discussion Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-08 16:25 +0200
                Flash (was: Recognizers discussion) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-07 10:51 +0000
                  Re: Flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-07 08:06 -0500
                    Re: Flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-07 13:57 +0000
                      Re: Flash Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-07 16:46 +0200
                      Re: Flash Alex <alex@rivadpm.com> - 2017-05-07 16:31 +0100
                        Re: Flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-07 17:16 +0000
                          Re: Flash Alex <alex@rivadpm.com> - 2017-05-07 19:18 +0100
                          Re: Flash albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-07 21:45 +0200
                            Re: Flash Matthias Trute <matthias.trute@gmail.com> - 2017-05-07 12:54 -0700
                        Re: Flash Alex <alex@rivadpm.com> - 2017-05-07 19:33 +0100
                      Re: Flash Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-07 08:50 -0700
                        Re: Flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-07 17:21 +0000
      Re: Recognizers discussion Matthias Trute <matthias.trute@gmail.com> - 2017-05-04 10:07 -0700

Page 1 of 9  [1] 2 3 4 5 6 7 8 9  Next page →

#58497 — Recognizers discussion

On 5/2/2017 09:49, Andrew Haley wrote:

I've started a new thread for clarity. I'm answering one at a time as my 
time permits.

> The proposal allows recognizers to precede dictionary searches, so
> that even if a word would have been found it might not be executed
> because a recognizer got in there first.  This will not help
> debugging; it is not a good thing.


But Forth has never insisted on protecting the programmer from not good 
things; qv the "ain't Forth weird!" example of 1 CONSTANT 0 . And a 
system with recognizers should, since backward compatibility is 
essential, be able to act in entirely the same way as a classical 
interpreter. The only difference will be the inability to add 
recognizers, simple, literal or otherwise, in a standard way.

-- Alex

[toc] | [next] | [standalone]

#58499

In my biginteger I write 

b 12345

to put the number on the big number stack. SupposeI would like to write

12345^

and let recognizer put it on the big stack, how would I do that?

: v bl parse vpush ;  \ put ascii number on big stack
: b v v>b ;                   \ as above and convert ascii to "cellimal" number

https://github.com/Lehs/ANS-Forth-libraries 

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

#58503

On Tuesday, 2 May 2017 15:52:48 UTC+1, lehs  wrote:
> In my biginteger I write 
> 
> b 12345
> 
> to put the number on the big number stack. SupposeI would like to write

What does "hex b 12345" do?

Is it a case of "programmer beware"? :-)

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

#58504

Okay, my big integers is just for decimal. It ignores the content of BASE.

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

#58530

On 5/2/2017 15:52, lehs wrote:
> In my biginteger I write
> 
> b 12345
> 
> to put the number on the big number stack. SupposeI would like to write
> 
> 12345^
> 
> and let recognizer put it on the big stack, how would I do that?
> 
> : v bl parse vpush ;  \ put ascii number on big stack
> : b v v>b ;                   \ as above and convert ascii to "cellimal" number
> 
> https://github.com/Lehs/ANS-Forth-libraries
> 

Without knowing what your B does with the parsed string when 
interpreting & what it does when compiling, I'll have to leave bits 
unspecified. But basically, if I have VPUSH right;

   :noname ( biginteger -- ) when interpreting ;
   :noname ( biginteger -- ) when compiling ;
   :noanem ( biginteger -- ) when postponing ;
dt-token: DT:BIGNUM

rec:bigint ( addr len -- biginteger DT:BIGNUM | DT:NULL )
     2dup + c@ '^' = if
       1- vpush DT:BIGNUM
     else 2drop DT:NULL then ;

-- 
Alex

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

#58565

Okay, thanks! Must all three cases be stated? I've came to conclusion that
big integers are most interesting as interpretative inputs.

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

#58667

lehs <skydda.barnen@gmail.com> writes:
>Okay, thanks! Must all three cases be stated? I've came to conclusion that
>big integers are most interesting as interpretative inputs.

If you really only want to support the interpretive inputs, you can
state, say, "' ABORT" for the other two cases, but my recommendation
is to deal with the other cases properly, too.  It's not that hard.

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

#58507

On 5/2/2017 15:27, Alex wrote:
> 
> Examples of the use of recognizers serve only to reinforce my
> disquiet.  For example, the "0x" example recognizer does this:
> 
> : plit postpone literal ;
> 
>    ' noop                           \ interpret: do nothing
>    ' plit                           \ compile as a literal
>    :noname plit postpone plit ;     \ postpone a literal
> dt-token: dt:0x ( n -- )
> 
> The multi-level POSTPONE took me a little while to understand.  

That's because POSTPONE parses.

> And
> it's totally unnecessary because no application will ever need to
> 
>    POSTPONE 0x25
> 
> The above could be rewritten as 
> 
>    ' noop                           \ interpret: do nothing
>    :noname   postpone literal ;     \ compile as a literal
>    ' abort                          \ WTF?
> dt-token: dt:0x ( n -- )
> 
> This is shorter, much easier to understand, and doesn't get carried
> away with pointless features.  And that's the examples of its use all
> over: pointless features.

With it we can POSTPONE literals; for instance, if I have ]] and [[ to 
enter and exit POSTPONE state

: foo ]] 5 dup 10 [[ ; immediate

Without it we have to write

: foo 5 postpone literal ]] dup [[ 10 postpone literal ; immediate

-- 
Alex

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

#58508

On 5/2/2017 09:49, Andrew Haley wrote:

> More broadly, much of the discussion of recognizers reflects an
> obsession with syntax which is not in keeping with the spirit of
> Forth.  Forth carefully eschews syntatctic minutiae and concentrates
> on semantics:
> 
>    THIS THAT OTHER
> 
> does this then that the the other, and we know that's what it does.
> There's no superfluous punctuation.  Literals are confined to simple
> numbers.  This simplicity is a feature, not a bug.  Where this general
> rule has been broken, for example as in TO, it has been a wart on the
> language.

You make it sound like a pachinko machine.

S" VARIABLE VALUE CREATE etc all parse; IFs need THENs and DOs need 
LOOPs and so on. Global variables, LOCALs with arcane parsing rules.

Even Forth Inc's washing machine program requires some syntax with its 
CONSTANTs and BEGIN UNTILs.

That argument is fine for programmer's 101 -- here's how the stack works 
and what words do, see how clean Forth is as it's all semantics -- but 
it really doesn't work as much more than a toy without syntax.

-- 
Alex

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

#58509

On 5/2/2017 09:49, Andrew Haley wrote:

> Getting changes into long-established languages is hard.  That is how
> it should be.  It is up to the proposers to present a convincing case
> that a change is really needed, and justify it with the needs of
> people writing applications.
> 
> Better to take a step back, take a hard look at what is really
> required, and come up with something that can be described more
> easily, managed more easily, and is a reasonable solution in
> proportion to the magnitude of the problem.

This I agree with. And, having one of very few Forth compilers that 
support the feature, I think it's important to test this, report on it 
and accept criticism of it.

-- 
Alex

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

#58516

Alex <alex@rivadpm.com> wrote:
> On 5/2/2017 09:49, Andrew Haley wrote:
> 
>> More broadly, much of the discussion of recognizers reflects an
>> obsession with syntax which is not in keeping with the spirit of
>> Forth.  Forth carefully eschews syntatctic minutiae and concentrates
>> on semantics:
>> 
>>    THIS THAT OTHER
>> 
>> does this then that the the other, and we know that's what it does.
>> There's no superfluous punctuation.  Literals are confined to simple
>> numbers.  This simplicity is a feature, not a bug.  Where this general
>> rule has been broken, for example as in TO, it has been a wart on the
>> language.
> 
> You make it sound like a pachinko machine.
> 
> S" VARIABLE VALUE CREATE etc all parse; IFs need THENs and DOs need 
> LOOPs and so on. Global variables, LOCALs with arcane parsing rules.

Indeed.  But please don't use abominations like S" to justify more
such things: there have been ill-thought-through decisions made in
previous Forth standards, and these are still causing people headaches
today.  The question in my mind is whether this proposal is another
such mistake.  I fear that it is.

> Even Forth Inc's washing machine program requires some syntax with its 
> CONSTANTs and BEGIN UNTILs.
> 
> That argument is fine for programmer's 101 -- here's how the stack
> works and what words do, see how clean Forth is as it's all
> semantics -- but it really doesn't work as much more than a toy
> without syntax.

I understand that, but it's really important in this discussion not to
consider this as a black-and white issue, but more of a matter of
degree.  THIS THAT OTHER is the normal flow of control, and everything
else (parsing words, immediates, etc.) is an exception.  If you're
reading a Forth program and you see ->X it's reasonable to think that
->X is a word, but in a system with these recognizers that no longer
holds. 

Of course, there are other ways (parsing words, etc.) in which a
simple-minded approach to reading Forth programs won't work, but that
really is beside the point.  The question in my mind is the extent to
which Forth programs will be made clearer (easier to read, debug,
etc.) by special-purpose recognizers, or more obscure.  And whether
the additional clarity provided by recognizers, if there is any,
justifies their inclusion in the language.

Andrew.

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

#58534

> Indeed.  But please don't use abominations like S" to justify more
> such things: there have been ill-thought-through decisions made in
> previous Forth standards, and these are still causing people headaches
> today.  The question in my mind is whether this proposal is another
> such mistake.  I fear that it is.

Is is plausible fear or a more abstract one? I see you as my
advocatus diaboli, so I'd like to know about your concerns. For
now they sound more of the "I fear the change but don't know
why" type.

Matthias

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

#58563

Matthias Trute <matthias.trute@gmail.com> wrote:
>> Indeed.  But please don't use abominations like S" to justify more
>> such things: there have been ill-thought-through decisions made in
>> previous Forth standards, and these are still causing people headaches
>> today.  The question in my mind is whether this proposal is another
>> such mistake.  I fear that it is.
> 
> Is is plausible fear or a more abstract one? I see you as my
> advocatus diaboli, so I'd like to know about your concerns. For
> now they sound more of the "I fear the change but don't know
> why" type.

I've just written a longish post which explains some of the problems.
I don't know what else I can reasonably do.

Andrew.

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

#58652

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> THIS THAT OTHER is the normal flow of control, and everything
>else (parsing words, immediates, etc.) is an exception.  If you're
>reading a Forth program and you see ->X it's reasonable to think that
>->X is a word, but in a system with these recognizers that no longer
>holds. 

That's nothing new.  When I wrote

1234. 2,

and the system did not complain, I expected "2," to be a word (along
the lines of 2@ and 2!), but it actually was recognized as a number.
And concerning LOCATE,

[~:95149] sf
SwiftForth i386-Linux 3.6.3 29-Jun-2016 
locate 2, 2, Can't be located

[~:95150] vfxlin
VFX Forth for Linux IA32 Version: 4.72 [build 0555]
locate 2, 
Err# -13 ERR: Undefined word.
 -> locate 2,
            ^

>Of course, there are other ways (parsing words, etc.) in which a
>simple-minded approach to reading Forth programs won't work, but that
>really is beside the point.  The question in my mind is the extent to
>which Forth programs will be made clearer (easier to read, debug,
>etc.) by special-purpose recognizers, or more obscure.

I think that, in practice, it will be made clearer.  We can let
'abominations like S"' fall into disuse and eventually destandardize
them, and, more importantly, have a good alternative to introducing
more such abominations.

Of course, you can dream up all kinds of abuses, and there will
certainly be people who will experiment with that (and we will come to
slightly different opinions of what constitutes abuse and what
constitutes desirable usage), but the abuses won't catch on, so no
need to worry about that.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2017: http://www.euroforth.org/ef17/

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

#58656

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> THIS THAT OTHER is the normal flow of control, and everything
>>else (parsing words, immediates, etc.) is an exception.  If you're
>>reading a Forth program and you see ->X it's reasonable to think that
>>->X is a word, but in a system with these recognizers that no longer
>>holds. 
> 
> That's nothing new.  When I wrote
> 
> 1234. 2,
> 
> and the system did not complain, I expected "2," to be a word (along
> the lines of 2@ and 2!), but it actually was recognized as a number.

Indeed.  There are exceptions, as I said in the very next paragraph:

>>Of course, there are other ways (parsing words, etc.) in which a
>>simple-minded approach to reading Forth programs won't work, but that
>>really is beside the point.  The question in my mind is the extent to
>>which Forth programs will be made clearer (easier to read, debug,
>>etc.) by special-purpose recognizers, or more obscure.
> 
> I think that, in practice, it will be made clearer.  We can let
> 'abominations like S"' fall into disuse and eventually destandardize
> them, and, more importantly, have a good alternative to introducing
> more such abominations.
> 
> Of course, you can dream up all kinds of abuses, and there will
> certainly be people who will experiment with that (and we will come to
> slightly different opinions of what constitutes abuse and what
> constitutes desirable usage), but the abuses won't catch on, so no
> need to worry about that.

Fair enough; I wish I had your faith!  :-)

If people start to use this stuff, we'll see.  It'll be interesting to
find out what it's really useful for, and if the programs in which
recognizers are used would be improved by removing them.

Andrew.

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

#58512

Alex <alex@rivadpm.com> wrote:
> On 5/2/2017 09:49, Andrew Haley wrote:
> 
> I've started a new thread for clarity. I'm answering one at a time as my 
> time permits.
> 
>> The proposal allows recognizers to precede dictionary searches, so
>> that even if a word would have been found it might not be executed
>> because a recognizer got in there first.  This will not help
>> debugging; it is not a good thing.
> 
> But Forth has never insisted on protecting the programmer from not good 
> things; qv the "ain't Forth weird!" example of 1 CONSTANT 0 . And a 
> system with recognizers should, since backward compatibility is 
> essential, be able to act in entirely the same way as a classical 
> interpreter.

Understood: there will still be a standard system if a recognizer
isn't added before the dictionary search.

> The only difference will be the inability to add recognizers,
> simple, literal or otherwise, in a standard way.

I don't understand this last sentence.

Andrew.

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

#58513

On 5/2/2017 18:35, Andrew Haley wrote:

> 
>> The only difference will be the inability to add recognizers,
>> simple, literal or otherwise, in a standard way.
> 
> I don't understand this last sentence.
> 
> Andrew.
> 

I mean that we will not be able, in a standard way, to extend number 
recognition. Matthias proposes recognizers, and having built a system 
that employs them, I can attest to their simplicity and universality.

All the recognizers I have posted so far are portable and produce 
correct results. I can't see any other solution providing that.

Albert proposes parsing prefix words, but I am utterly opposed to 
anything that requires parsing & statefulness in a single "blob", 
especially where (like TO) it's likely that the prefix, because it 
parses, can't be POSTPONEd. It's another candidate for "can't do this" 
note in the standard, and don't we have enough already?

-- 
Alex

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

#58518

Alex <alex@rivadpm.com> wrote:
> On 5/2/2017 18:35, Andrew Haley wrote:
> 
>> 
>>> The only difference will be the inability to add recognizers,
>>> simple, literal or otherwise, in a standard way.
>> 
>> I don't understand this last sentence.
> 
> I mean that we will not be able, in a standard way, to extend number 
> recognition. Matthias proposes recognizers, and having built a system 
> that employs them, I can attest to their simplicity and universality.

Yes, but you don't need recognizing numbers to come before the
dictionary search in order to do that.

> All the recognizers I have posted so far are portable and produce 
> correct results. I can't see any other solution providing that.
> 
> Albert proposes parsing prefix words, but I am utterly opposed to 
> anything that requires parsing & statefulness in a single "blob", 
> especially where (like TO) it's likely that the prefix, because it 
> parses, can't be POSTPONEd. It's another candidate for "can't do this" 
> note in the standard, and don't we have enough already?

We surely do.

Andrew.

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

#58521

On 5/2/2017 19:10, Andrew Haley wrote:
> Alex <alex@rivadpm.com> wrote:
>> On 5/2/2017 18:35, Andrew Haley wrote:
>>
>>>
>>>> The only difference will be the inability to add recognizers,
>>>> simple, literal or otherwise, in a standard way.
>>>
>>> I don't understand this last sentence.
>>
>> I mean that we will not be able, in a standard way, to extend number
>> recognition. Matthias proposes recognizers, and having built a system
>> that employs them, I can attest to their simplicity and universality.
> 
> Yes, but you don't need recognizing numbers to come before the
> dictionary search in order to do that.

Mine don't; they come in the usual place. (Read the search order as left 
to right.)

.recognizers
recognizers: rec:name rec:num rec:quot rec:wincon rec:tick rec:string

REC:NAME is the dictionary search.


-- 
Alex

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

#58541

Am Tue, 02 May 2017 13:10:07 -0500 schrieb Andrew Haley:

> Alex <alex@rivadpm.com> wrote:
>> On 5/2/2017 18:35, Andrew Haley wrote:
>> 
>> 
>>>> The only difference will be the inability to add recognizers,
>>>> simple, literal or otherwise, in a standard way.
>>> 
>>> I don't understand this last sentence.
>> 
>> I mean that we will not be able, in a standard way, to extend number
>> recognition. Matthias proposes recognizers, and having built a system
>> that employs them, I can attest to their simplicity and universality.
> 
> Yes, but you don't need recognizing numbers to come before the
> dictionary search in order to do that.

You are still locked into thinking that the recognizer is for numbers 
only.  It isn't.  Get out of your box.  Recognizers can be dot parsers, 
can be scope parsers (scope:word), and where they sit in the recognizer 
order depends on the job.

Literal recognizers will certainly be added after the dictionary search.  
Unless you want to parse a ton of literals quickly, then you reverse that 
temporarily.

And one important factor for a clean design is that you have rules, but 
no exceptions.  The dictionary search is just one recognizer, nothing 
special (people suggested that it's actually a stack of recognizers, with 
each vocabulary in the search order being one recognizer).

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

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

Page 1 of 9  [1] 2 3 4 5 6 7 8 9  Next page →

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

csiph-web