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

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

Boring for most of you, but I'm having fun ... :)

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

Contents

  Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2015-10-06 21:44 -0700
    Re: Boring for most of you, but I'm having fun ... :) Lars Brinkhoff <lars.spam@nocrew.org> - 2015-10-07 08:24 +0200
    Re: Boring for most of you, but I'm having fun ... :) Mark Wills <markwills1970@gmail.com> - 2015-10-07 00:48 -0700
      Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2015-10-07 05:41 -0700
    Re: Boring for most of you, but I'm having fun ... :) Jason Damisch <jasondamisch@yahoo.com> - 2015-10-07 12:05 -0700
    Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2015-12-27 18:04 -0800
      Re: Boring for most of you, but I'm having fun ... :) Paul Rubin <no.email@nospam.invalid> - 2015-12-27 18:12 -0800
        Re: Boring for most of you, but I'm having fun ... :) Coos Haak <chforth@hccnet.nl> - 2015-12-28 13:33 +0100
    Re: Boring for most of you, but I'm having fun ... :) humptydumpty <ouatubi@gmail.com> - 2015-12-28 00:54 -0800
    Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2015-12-28 12:32 -0800
      Re: Boring for most of you, but I'm having fun ... :) Paul Rubin <no.email@nospam.invalid> - 2015-12-28 12:43 -0800
        Re: Boring for most of you, but I'm having fun ... :) Coos Haak <chforth@hccnet.nl> - 2015-12-28 22:13 +0100
          Re: Boring for most of you, but I'm having fun ... :) Paul Rubin <no.email@nospam.invalid> - 2015-12-28 13:21 -0800
            Re: Boring for most of you, but I'm having fun ... :) Coos Haak <chforth@hccnet.nl> - 2015-12-28 23:47 +0100
        Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2015-12-28 13:13 -0800
          Re: Boring for most of you, but I'm having fun ... :) Coos Haak <chforth@hccnet.nl> - 2015-12-28 23:50 +0100
            Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2015-12-28 15:33 -0800
              Re: Boring for most of you, but I'm having fun ... :) "Elizabeth D. Rather" <erather@forth.com> - 2015-12-28 15:37 -1000
                Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2015-12-28 22:18 -0800
                  Re: Boring for most of you, but I'm having fun ... :) Paul Rubin <no.email@nospam.invalid> - 2015-12-28 22:31 -0800
                    Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2015-12-28 23:30 -0800
                      Re: Boring for most of you, but I'm having fun ... :) Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-12-29 02:47 -0800
                        Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2015-12-29 08:19 -0800
                          Re: Boring for most of you, but I'm having fun ... :) Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-12-29 08:26 -0800
                            Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2015-12-29 09:34 -0800
                              Re: Boring for most of you, but I'm having fun ... :) Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-12-29 10:22 -0800
                        Re: Boring for most of you, but I'm having fun ... :) Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-12-30 12:15 +0000
                          Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2015-12-30 08:26 -0800
                            Re: Boring for most of you, but I'm having fun ... :) Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-12-31 16:10 +0000
                          Re: Boring for most of you, but I'm having fun ... :) Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-12-30 08:35 -0800
                            Re: Boring for most of you, but I'm having fun ... :) Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-12-30 08:51 -0800
                              Re: Boring for most of you, but I'm having fun ... :) Paul Rubin <no.email@nospam.invalid> - 2015-12-30 12:21 -0800
                                Re: Boring for most of you, but I'm having fun ... :) "Elizabeth D. Rather" <erather@forth.com> - 2015-12-30 10:46 -1000
                                  Re: Boring for most of you, but I'm having fun ... :) Paul Rubin <no.email@nospam.invalid> - 2015-12-30 13:15 -0800
                                    Re: Boring for most of you, but I'm having fun ... :) "Elizabeth D. Rather" <erather@forth.com> - 2015-12-30 13:11 -1000
                                      Re: Boring for most of you, but I'm having fun ... :) Paul Rubin <no.email@nospam.invalid> - 2015-12-30 15:35 -0800
                                        Re: Boring for most of you, but I'm having fun ... :) "Elizabeth D. Rather" <erather@forth.com> - 2015-12-30 15:00 -1000
                                        Re: Boring for most of you, but I'm having fun ... :) Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-12-31 00:13 -0800
                                        Re: Boring for most of you, but I'm having fun ... :) Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-12-31 10:09 +0000
                                          Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-12-31 13:46 +0000
                                        Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-12-31 13:56 +0000
                                          Re: Boring for most of you, but I'm having fun ... :) Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-12-31 17:24 +0000
                                            Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-01 14:23 +0000
                                              Re: Boring for most of you, but I'm having fun ... :) Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-01-01 20:24 +0000
                                                Re: Boring for most of you, but I'm having fun ... :) Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-01 22:38 +0100
                                                  Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-02 13:24 +0000
                                                    Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-02 15:32 +0000
                                                    Re: Boring for most of you, but I'm having fun ... :) Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-01-02 16:41 +0000
                                                      Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-03 14:43 +0000
                                                Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-02 13:13 +0000
                                        Re: Boring for most of you, but I'm having fun ... :) Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-12-31 16:57 +0000
                                      Re: Boring for most of you, but I'm having fun ... :) Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-12-31 16:41 +0000
                                    Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-12-31 14:13 +0000
                                      Re: Boring for most of you, but I'm having fun ... :) Bernd Paysan <bernd.paysan@gmx.de> - 2015-12-31 22:27 +0100
                                        Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-01 13:38 +0000
                                          Re: Boring for most of you, but I'm having fun ... :) Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-01 18:46 +0100
                                            Re: Boring for most of you, but I'm having fun ... :) "Elizabeth D. Rather" <erather@forth.com> - 2016-01-01 09:01 -1000
                                              Re: Boring for most of you, but I'm having fun ... :) Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-01 22:35 +0100
                                          Re: Boring for most of you, but I'm having fun ... :) "Elizabeth D. Rather" <erather@forth.com> - 2016-01-01 08:39 -1000
                                            Re: Boring for most of you, but I'm having fun ... :) Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-01 21:01 +0100
                                          Re: Boring for most of you, but I'm having fun ... :) Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-01-01 20:18 +0000
                                Re: Boring for most of you, but I'm having fun ... :) Bernd Paysan <bernd.paysan@gmx.de> - 2015-12-31 22:19 +0100
                                  Re: Boring for most of you, but I'm having fun ... :) Paul Rubin <no.email@nospam.invalid> - 2016-01-01 21:43 -0800
                                    Re: Boring for most of you, but I'm having fun ... :) Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-01-01 23:36 -0800
                                    Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-02 15:36 +0000
                                      Re: Boring for most of you, but I'm having fun ... :) Paul Rubin <no.email@nospam.invalid> - 2016-01-02 12:18 -0800
                                        Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-03 14:34 +0000
                                      Re: Boring for most of you, but I'm having fun ... :) hughaguilar96@gmail.com - 2016-01-03 19:57 -0800
                                        Re: Boring for most of you, but I'm having fun ... :) Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-01-04 22:49 +0000
                                          Re: Boring for most of you, but I'm having fun ... :) Julian Fondren <julian.fondren@gmail.com> - 2016-01-04 15:05 -0800
                                            Re: Boring for most of you, but I'm having fun ... :) hughaguilar96@gmail.com - 2016-01-04 20:36 -0800
                                          Re: Boring for most of you, but I'm having fun ... :) hughaguilar96@gmail.com - 2016-01-05 13:03 -0800
                                            Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2016-01-05 14:30 -0800
                                              Re: Boring for most of you, but I'm having fun ... :) hughaguilar96@gmail.com - 2016-01-05 21:10 -0800
                                                Re: Boring for most of you, but I'm having fun ... :) hughaguilar96@gmail.com - 2016-01-05 21:26 -0800
                                                Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2016-01-06 05:01 -0800
                                            Re: Boring for most of you, but I'm having fun ... :) "WJ" <w_a_x_man@yahoo.com> - 2016-01-06 00:13 +0000
                                            Re: Boring for most of you, but I'm having fun ... :) Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-01-06 19:47 +0000
                                              Re: Boring for most of you, but I'm having fun ... :) hughaguilar96@gmail.com - 2016-01-07 21:43 -0800
                                                Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2016-01-08 05:54 -0800
                                                  Re: Boring for most of you, but I'm having fun ... :) Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-01-08 16:44 +0000
                                                  Re: Boring for most of you, but I'm having fun ... :) hughaguilar96@gmail.com - 2016-01-08 16:27 -0800
                                                Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-08 17:18 +0000
                                                Re: Boring for most of you, but I'm having fun ... :) Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-01-08 17:00 +0000
                                              Re: Boring for most of you, but I'm having fun ... :) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-01-08 04:52 -0600
                                                Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-08 11:27 +0000
                                                  Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-08 16:44 +0000
                                                    Re: Boring for most of you, but I'm having fun ... :) Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-08 21:17 +0100
                                                  Re: Boring for most of you, but I'm having fun ... :) Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-01-08 16:57 +0000
                                                    Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-08 17:06 +0000
                                                      Re: Boring for most of you, but I'm having fun ... :) Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-01-08 20:24 +0000
                                                        Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-09 17:05 +0000
                                                    Re: Boring for most of you, but I'm having fun ... :) stephen@mpeforth.com (Stephen Pelc) - 2016-01-08 20:02 +0000
                                                      Re: Boring for most of you, but I'm having fun ... :) Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-08 21:49 +0100
                                                    Re: Boring for most of you, but I'm having fun ... :) hughaguilar96@gmail.com - 2016-01-09 22:06 -0800
                                                  Re: Boring for most of you, but I'm having fun ... :) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-01-10 07:46 -0600
                                                    Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-10 14:35 +0000
                                                      Re: Boring for most of you, but I'm having fun ... :) hughaguilar96@gmail.com - 2016-01-10 11:55 -0800
                                                        Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-12 13:26 +0000
                                                          Re: Boring for most of you, but I'm having fun ... :) peter.m.falth@gmail.com - 2016-01-12 15:10 -0800
                                                            Re: Boring for most of you, but I'm having fun ... :) "Elizabeth D. Rather" <erather@forth.com> - 2016-01-12 13:23 -1000
                                                              Re: Boring for most of you, but I'm having fun ... :) hughaguilar96@gmail.com - 2016-01-12 20:42 -0800
                                                                Re: Boring for most of you, but I'm having fun ... :) hughaguilar96@gmail.com - 2016-01-12 21:08 -0800
                                                            Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-13 15:17 +0000
                                                              Re: Boring for most of you, but I'm having fun ... :) peter.m.falth@gmail.com - 2016-01-13 13:26 -0800
                                  Re: Boring for most of you, but I'm having fun ... :) hughaguilar96@gmail.com - 2016-01-04 14:19 -0800
                                    Re: Boring for most of you, but I'm having fun ... :) "WJ" <w_a_x_man@yahoo.com> - 2016-01-05 07:24 +0000
                              Re: Boring for most of you, but I'm having fun ... :) Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-12-31 16:24 +0000
                      Re: Boring for most of you, but I'm having fun ... :) "Elizabeth D. Rather" <erather@forth.com> - 2015-12-29 12:31 -1000
                        Re: Boring for most of you, but I'm having fun ... :) Paul Rubin <no.email@nospam.invalid> - 2015-12-29 14:52 -0800
                          Re: Boring for most of you, but I'm having fun ... :) Coos Haak <chforth@hccnet.nl> - 2015-12-30 02:11 +0100
                            Re: Boring for most of you, but I'm having fun ... :) "Elizabeth D. Rather" <erather@forth.com> - 2015-12-29 23:46 -1000
                              Re: Boring for most of you, but I'm having fun ... :) "HAA" <someone@microsoft.com> - 2015-12-30 21:25 +1100
                                Re: Boring for most of you, but I'm having fun ... :) "Elizabeth D. Rather" <erather@forth.com> - 2015-12-30 09:17 -1000
                                  Re: Boring for most of you, but I'm having fun ... :) "HAA" <someone@microsoft.com> - 2015-12-31 12:55 +1100
                                    Re: Boring for most of you, but I'm having fun ... :) "Elizabeth D. Rather" <erather@forth.com> - 2015-12-30 16:26 -1000
                                      Re: Boring for most of you, but I'm having fun ... :) "HAA" <someone@microsoft.com> - 2016-01-02 12:30 +1100
                                        Re: Boring for most of you, but I'm having fun ... :) "Elizabeth D. Rather" <erather@forth.com> - 2016-01-01 16:31 -1000
                                        Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2016-01-01 21:31 -0800
                                        Re: Boring for most of you, but I'm having fun ... :) stephen@mpeforth.com (Stephen Pelc) - 2016-01-02 12:04 +0000
                                  Re: Boring for most of you, but I'm having fun ... :) stephen@mpeforth.com (Stephen Pelc) - 2015-12-31 12:04 +0000
                                    Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-12-31 13:31 +0000
                                      Re: Boring for most of you, but I'm having fun ... :) "Elizabeth D. Rather" <erather@forth.com> - 2015-12-31 08:50 -1000
                                        Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-01 14:13 +0000
                                  Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-12-31 14:34 +0000
                                    Re: Boring for most of you, but I'm having fun ... :) Bernd Paysan <bernd.paysan@gmx.de> - 2015-12-31 22:39 +0100
                                      Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-01 10:05 +0000
                                        Re: Boring for most of you, but I'm having fun ... :) Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-01 18:16 +0100
                                          Re: Boring for most of you, but I'm having fun ... :) Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-01-01 17:49 +0000
                                            Re: Boring for most of you, but I'm having fun ... :) Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-01 19:23 +0100
                                      Re: Boring for most of you, but I'm having fun ... :) Paul Rubin <no.email@nospam.invalid> - 2016-01-01 15:53 -0800
                                        Re: Boring for most of you, but I'm having fun ... :) Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-02 14:20 +0100
                                          Re: Boring for most of you, but I'm having fun ... :) Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-01-02 16:34 +0000
                                          Re: Boring for most of you, but I'm having fun ... :) Mikael Nordman <oh2aun@gmail.com> - 2016-01-02 14:08 -0800
                                Re: Boring for most of you, but I'm having fun ... :) hughaguilar96@gmail.com - 2015-12-30 20:40 -0800
                              Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2015-12-30 08:28 -0800
                          Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-12-30 11:11 +0000
            Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2015-12-28 15:40 -0800
              Re: Boring for most of you, but I'm having fun ... :) "HAA" <someone@microsoft.com> - 2015-12-30 10:14 +1100
            Re: Boring for most of you, but I'm having fun ... :) "Elizabeth D. Rather" <erather@forth.com> - 2015-12-28 15:35 -1000
              Re: Boring for most of you, but I'm having fun ... :) hughaguilar96@gmail.com - 2015-12-30 20:58 -0800
    Re: Boring for most of you, but I'm having fun ... :) Julian Fondren <julian.fondren@gmail.com> - 2016-01-02 02:25 -0800

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

#44468

Paul Rubin <no.email@nospam.invalid> writes:
> Or gforth's NEXTWORD which pushes the
>word back onto the input stream (or equivalent).

NEXTNAME stores the name somewhere and changes the header-creating
word to take that name for the next header it creates instead of using
the input stream; and after creating the header from the stored
string, the header-creating words resets itself to taking a name from
the input stream.  There is also NONAME, which works in a simular way;
i.e.,

noname : ... ; lastxt

is equivalent to

:noname ... ;

but you can also use NONAME with other defining words, e.g., with
CREATE or CONSTANT.

NEXTNAME is older than EXECUTE-PARSING, and would probably not have
come into existence if we had EXECUTE-PARSING first, but it can do one
thing that cannot be done with EXECUTE-PARSING: we can pass arbitrary
data to it, including bytes that look like white space when
interpreted as string.  That's useful when we want to use TABLEs (like
wordlists, but with literal comparison instead of case-insensitive
comparison on lookup) with binary data as lookup keys.

>IMO it's a useful word that I've wanted a few times.  Look at Chris
>Curl's example of creating an auxiliary T stack.  It would be nice to
>generalize that to something like
>
>   : NEWSTACK ( "name" size ) ... ;
>
>so that "20 NEWSTACK T" would allocate 20 cells for a new stack named T,
>and automatically create the words >T T> T@ and T.RESET that did the
>obvious things.

I have thought about such things sometimes, too, but I have always
come to the conclusion that we can just as well do it as a sequence of
words, i.e., in this case T >S, T S>, T S@, T RESET or somesuch.

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#44475

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:

>Paul Rubin <no.email@nospam.invalid> writes:
>> Or gforth's NEXTWORD which pushes the
>>word back onto the input stream (or equivalent).

>NEXTNAME stores the name somewhere and changes the header-creating
>word to take that name for the next header it creates instead of using
>the input stream; and after creating the header from the stored
>string, the header-creating words resets itself to taking a name from
>the input stream.  There is also NONAME, which works in a simular way;
>i.e.,

That word is called POSTFIX in my book.
The implementation in an indirect threaded Forth is interesting,
instead of storing the string somewhere, the parsing action in
NAME is suppressed:

 \ Have the original behaviour of DEA restored.
: RESTORED   DUP >PHA SWAP >DFA ! ;
\ Do nothing for one call of ``NAME''
: NAME-NEW   'NAME RESTORED ;
\ Make the following defining word postfix for one execution.
\ The name must be a string constant on the stack
\ Use only while compiling, or you crash the system
: POSTFIX ( ?COMP ) 'NAME-NEW >DFA @ 'NAME >DFA ! ;

It is a loadable extension. Don't want it? Don't load it!
It works on all defining words that use NAME.

>noname : ... ; lastxt

>is equivalent to

>:noname ... ;

>but you can also use NONAME with other defining words, e.g., with
>CREATE or CONSTANT.

>NEXTNAME is older than EXECUTE-PARSING, and would probably not have
>come into existence if we had EXECUTE-PARSING first, but it can do one
>thing that cannot be done with EXECUTE-PARSING: we can pass arbitrary
>data to it, including bytes that look like white space when
>interpreted as string.  That's useful when we want to use TABLEs (like
>wordlists, but with literal comparison instead of case-insensitive
>comparison on lookup) with binary data as lookup keys.

So NEXTNAME is a gForth invention and has no older roots?

>>IMO it's a useful word that I've wanted a few times.  Look at Chris
>>Curl's example of creating an auxiliary T stack.  It would be nice to
>>generalize that to something like
>>
>>   : NEWSTACK ( "name" size ) ... ;
>>
>>so that "20 NEWSTACK T" would allocate 20 cells for a new stack named T,
>>and automatically create the words >T T> T@ and T.RESET that did the
>>obvious things.

>I have thought about such things sometimes, too, but I have always
>come to the conclusion that we can just as well do it as a sequence of
>words, i.e., in this case T >S, T S>, T S@, T RESET or somesuch.

Or even better, have a stack object, make it current and do
pop,push and get. TO-objects using TO and FROM would work also.

>- anton
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#44497

Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>So NEXTNAME is a gForth invention and has no older roots?

I was not aware of anything in that direction in other systems when I
added it to Gforth, but I would not be surprised if someone else had
implemented such a feature earlier.

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#44508

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:

>Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>>So NEXTNAME is a gForth invention and has no older roots?

>I was not aware of anything in that direction in other systems when I
>added it to Gforth, but I would not be surprised if someone else had
>implemented such a feature earlier.

While we're at it we could establish prioriy.
This is the first mention of POSTFIX in my logs.

"
2001 sep 26 we
...
Idea about POSTFIX replace (WORD) by a NOOP for one
call. Works.
"

>- anton
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#44511

Albert van der Horst wrote:

> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> 
>>Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>>>So NEXTNAME is a gForth invention and has no older roots?
> 
>>I was not aware of anything in that direction in other systems when I
>>added it to Gforth, but I would not be surprised if someone else had
>>implemented such a feature earlier.
> 
> While we're at it we could establish prioriy.
> This is the first mention of POSTFIX in my logs.
> 
> "
> 2001 sep 26 we
> ...
> Idea about POSTFIX replace (WORD) by a NOOP for one
> call. Works.
> "

According to git blame (with the CVS tree imported, where I am listed with 
the y/z swapped user name I had for historical reasons), nextname has been 
checked in by me in May 1998:

b727d802 (pazsan       1998-05-02 21:28:41 +0000 159) : nextname ( c-addr u 
-- ) \ gforth


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

#44530

Bernd Paysan <bernd.paysan@gmx.de> writes:
>According to git blame (with the CVS tree imported, where I am listed with 
>the y/z swapped user name I had for historical reasons), nextname has been 
>checked in by me in May 1998:
>
>b727d802 (pazsan       1998-05-02 21:28:41 +0000 159) : nextname ( c-addr u 
>-- ) \ gforth

That's the time kernel/comp.fs was checked in for the first time, but
unfortunately you don't see that with git blame (whereas a version 1.1
in cvs annotate is obvious); before that it was in kernel.fs, before
than in kernal.fs, and it was there in version 1.1, so it likely was
introduced even earlier, but I don't find the RCS repository at the
moment to determine the exact date.

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#44531

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>Bernd Paysan <bernd.paysan@gmx.de> writes:
>>According to git blame (with the CVS tree imported, where I am listed with 
>>the y/z swapped user name I had for historical reasons), nextname has been 
>>checked in by me in May 1998:
>>
>>b727d802 (pazsan       1998-05-02 21:28:41 +0000 159) : nextname ( c-addr u 
>>-- ) \ gforth
>
>That's the time kernel/comp.fs was checked in for the first time, but
>unfortunately you don't see that with git blame (whereas a version 1.1
>in cvs annotate is obvious); before that it was in kernel.fs, before
>than in kernal.fs, and it was there in version 1.1, so it likely was
>introduced even earlier, but I don't find the RCS repository at the
>moment to determine the exact date.

Found the RCS repository:

revision 1.7
date: 1993/11/21 21:23:44;  author: anton;  state: Exp;  lines: +76 -13
added: nextname noname inputstream lastxt ENDIF S+LOOP 2, 2VARIABLE 2CONSTANT
cleaned up a few things

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#44536

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:

>Bernd Paysan <bernd.paysan@gmx.de> writes:
>>According to git blame (with the CVS tree imported, where I am listed with
>>the y/z swapped user name I had for historical reasons), nextname has been
>>checked in by me in May 1998:
>>
>>b727d802 (pazsan       1998-05-02 21:28:41 +0000 159) : nextname ( c-addr u
>>-- ) \ gforth

>That's the time kernel/comp.fs was checked in for the first time, but
>unfortunately you don't see that with git blame (whereas a version 1.1
>in cvs annotate is obvious); before that it was in kernel.fs, before
>than in kernal.fs, and it was there in version 1.1, so it likely was
>introduced even earlier, but I don't find the RCS repository at the
>moment to determine the exact date.

Maybe I should change the name POSTFIX to NEXTNAME? (Though I like 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 2015: http://www.rigwit.co.uk/EuroForth2015/
-- 
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]

#44550

Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>
>>Bernd Paysan <bernd.paysan@gmx.de> writes:
>>>According to git blame (with the CVS tree imported, where I am listed with
>>>the y/z swapped user name I had for historical reasons), nextname has been
>>>checked in by me in May 1998:
>>>
>>>b727d802 (pazsan       1998-05-02 21:28:41 +0000 159) : nextname ( c-addr u
>>>-- ) \ gforth
>
>>That's the time kernel/comp.fs was checked in for the first time, but
>>unfortunately you don't see that with git blame (whereas a version 1.1
>>in cvs annotate is obvious); before that it was in kernel.fs, before
>>than in kernal.fs, and it was there in version 1.1, so it likely was
>>introduced even earlier, but I don't find the RCS repository at the
>>moment to determine the exact date.
>
>Maybe I should change the name POSTFIX to NEXTNAME? (Though I like it.)

They do different things.  POSTFIX changes what WORD does (according
to what you wrote), while NEXTNAME changes what HEADER (the
header-creating word) does.

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#44528

Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>
>>Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>>>So NEXTNAME is a gForth invention and has no older roots?
>
>>I was not aware of anything in that direction in other systems when I
>>added it to Gforth, but I would not be surprised if someone else had
>>implemented such a feature earlier.
>
>While we're at it we could establish prioriy.
>This is the first mention of POSTFIX in my logs.
>
>"
>2001 sep 26 we
>...
>Idea about POSTFIX replace (WORD) by a NOOP for one
>call. Works.
>"

NEXTNAME was already in the sources when we switched from RCS to CVS
on 1994-02-11:

http://www.complang.tuwien.ac.at/cvsweb/cgi-bin/cvsweb/gforth/Attic/kernal.fs?rev=1.1;content-type=text%2Fx-cvsweb-markup

I mentioned it at the latest in clf on Mon Nov 25 18:58:57 1996.

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#44474

Paul Rubin <no.email@nospam.invalid> writes:

>"Elizabeth D. Rather" <erather@forth.com> writes:
>> as you start talking about a "standard way to make an arbitrary
>> dictionary entry" you open a huge can of worms about exactly what
>> needs to be incorporated in that dictionary entry, where it is, etc.

>I don't see how that can be, since otherwise CREATE would open the
>exact same can of worms.  The idea is to just have a word like

> : $DATA ( addr u -- )  ... ;

>which takes a string as arg, and does the same thing as CREATE would
>do in parsing that string.  Or gforth's NEXTWORD which pushes the
>word back onto the input stream (or equivalent).

>> None of these issues are really germane to using Forth to write
>> applications, which its purpose.

>IMO it's a useful word that I've wanted a few times.  Look at Chris
>Curl's example of creating an auxiliary T stack.  It would be nice to
>generalize that to something like

>   : NEWSTACK ( "name" size ) ... ;

>so that "20 NEWSTACK T" would allocate 20 cells for a new stack named T,
>and automatically create the words >T T> T@ and T.RESET that did the
>obvious things.  I don't see any standard way to do that.

A standard way is to build up standard code in a text buffer.
Then use EVALUATE on the buffer.
Totally standard.

I use it myself in my mini-OO.
If I have declared a class APE in my OO package words like ^APE and
BUILD-APE are present.

You are aware that you cannot use a word like >T in an application
at run time, unless you've defined your stack at compile time?
So there is nothing actually dynamic  about >T T> ..

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]

#44473

"Elizabeth D. Rather" <erather@forth.com> writes:


>AFAIK there has never been an intent to make it possible to write an
>implementation in Standard Forth. The objective has always been to
>standardize the interface between a system and an application. As soon
>as you start talking about a "standard way to make an arbitrary
>dictionary entry" you open a huge can of worms about exactly what needs
>to be incorporated in that dictionary entry, where it is, etc. None of
>these issues are really germane to using Forth to write applications,
>which its purpose.

Talking about ai where you may want the program to write a new program,
it is clear that a couple of $ words don't do the job anyway.
There is EVALUATE to the rescue with no restrictions whatsoever.

"CREATE " PAD $! get-some-string PAD $+!
PAD $@ EVALUATE
\ Now we have a word with a name resulting from `` get-some-string ''
\ in the dictionary.

So I'd agree that we shouldn't add $-words to the standard. Let us not
clutter up the standard with words with limited usage. We have
an extensible language at our hands, but not all extensions belong in
the standard.

>Cheers,
>Elizabeth

Groetjes Albert

>--
>==================================================
>Elizabeth D. Rather   (US & Canada)   800-55-FORTH
>FORTH Inc.                         +1 310.999.6784
>5959 West Century Blvd. Suite 700
>Los Angeles, CA 90045
>http://www.forth.com

>"Forth-based products and Services for real-time
>applications since 1973."
>==================================================
-- 
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]

#44469

Paul Rubin <no.email@nospam.invalid> writes:
> But it doesn't specify any
>way to make an arbitrary dictionary entry.  That seems like a bug.  I
>vaguely remember reading there was some discussion in the Forth-2012
>group about how to do it, but it got mired in bikeshedding.  Maybe one
>of the participants could say more.

Not sure what you are referring to, but I suggested EXECUTE-PARSING at
a meeting a number of years ago.  Stephen Pelc claimed that this is
not general enough and that one would also introduce
EXECUTE-PARSING-FILE, EXECUTE-PARSING-BLOCK, EXECUTE-PARSING-FLASH and
millions of other words if we introduced EXECUTE-PARSING.  In actual
usage, Gforth has EXECUTE-PARSING-FILE, but I have never used it.  It
does not have EXECUTE-PARSING-BLOCK nor EXECUTE-PARSING-FLASH, and I
have not missed them at all.

But I do use EXECUTE-PARSING regularly.  Everytime some idiot writes a
parsing word, EXECUTE-PARSING is to the rescue.  In the meantime I
have come to the conclusion that it's actually not so dumb to write
parsing words, but one of the ways to reduce the stack load in Forth;
but it needs to be combined with a way to get back to a general
stack-based interface, and that way is EXECUTE-PARSING.

Anyway, back to the discussion at the standards meeting.  There was a
suggestion from Stephen Pelc that we should generalize the text
interpreter such that we could arbitrarily plug together various input
stream sources, and various ways to process the input stream, as a
very generalized variant of the EXECUTE-PARSING idea.  I worked out a
sketch of how that might look (I can dig it out if there is interest).
My own feelings about this were mixed, and the reaction of the
participants was negative or neutral (anyway, not supportive), so I
did not pursue it further.  But I also did not pursue EXECUTE-PARSING
in the committee further.

Looking back, the general solution may inspire some new style or
something, but is certainly not something that comes out of existing
practice, and it might just end up as overgeneralization.  In
contrast, EXECUTE-PARSING has quite a bit of existing practice (of
course not if you define "existing practice" as "what MPE and (to the
knowledge of Stephen Pelc) its customers do") and is just the right
level of generality.  Maybe someone should make an RfD on 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#44484

Anton Ertl wrote:
> Not sure what you are referring to, but I suggested EXECUTE-PARSING at
> a meeting a number of years ago.  Stephen Pelc claimed that this is
> not general enough and that one would also introduce
> EXECUTE-PARSING-FILE, EXECUTE-PARSING-BLOCK, EXECUTE-PARSING-FLASH and
> millions of other words if we introduced EXECUTE-PARSING.  In actual
> usage, Gforth has EXECUTE-PARSING-FILE, but I have never used it.  It
> does not have EXECUTE-PARSING-BLOCK nor EXECUTE-PARSING-FLASH, and I
> have not missed them at all.

It's probably easier to use recognizers for parsing more than one word.

The key thing for EXECUTE-PARSING is that it transforms
s" <something>" ['] <parsing-word> execute-parsing
into the equivalent of
<parsing-word> <something>

I've a use of execute-parsing-named-file in net2o-tools.fs (net2o sources in 
https://fossil.net2o.de/net2o), to implement the help system; and I plan to 
push that back to Gforth itself, as using your own help system for any kind 
of Forth program can be a good idea.  Given that it contains a filter + an 
action if the filter matches, I should reimplement that as recognizer.

The recognizer proposal needs a number of example cases to convince 
especially Stephen, anyways ;-).

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

#44495

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> Not sure what you are referring to, but I suggested EXECUTE-PARSING at
>> a meeting a number of years ago.  Stephen Pelc claimed that this is
>> not general enough and that one would also introduce
>> EXECUTE-PARSING-FILE, EXECUTE-PARSING-BLOCK, EXECUTE-PARSING-FLASH and
>> millions of other words if we introduced EXECUTE-PARSING.  In actual
>> usage, Gforth has EXECUTE-PARSING-FILE, but I have never used it.  It
>> does not have EXECUTE-PARSING-BLOCK nor EXECUTE-PARSING-FLASH, and I
>> have not missed them at all.
>
>It's probably easier to use recognizers for parsing more than one word.

Easier than what?  EXECUTE-PARSING and recognizers do not solve the
same problems, so your sentence does not make sense in this context.

However, while we are at it, how do we solve the problem that
EXECUTE-PARSING solves for parsing words for recognizers?

Say, we have a recognizer for environment variables (for the pattern
"$<var>), but the programmer of the recognizer did not provide the
environment lookup as a factor, and now we want to look up an
environmental variable whose name we get from, say, a file.  How do we
make use of the environment lookup buried in the recognizer?

One way would be to build a string "$<var>" and EVALUATE it, hoping
that the recognizer we are interested in is active and first among
those that might recognize the string (but the hex number recognizer
might be earlier).

Alternatively, we could pass some recognizer token to an
EXECUTE-RECOGNIZER ( c-addr u rt -- ... flag ) word that is the
recognizer equivalent of EXECUTE-PARSING, but if the programmer failed
to give us the environment lookup as a factor, he probably did not
export the recognizer token, either; sure, one could look it up in the
source code of the library, but that might change in the next version
of the library.

Any further ideas?

>The key thing for EXECUTE-PARSING is that it transforms
>s" <something>" ['] <parsing-word> execute-parsing
>into the equivalent of
><parsing-word> <something>

I put it the other word around: Given a <parsing-word> that is written
to be used as

<parsing-word> <something>

EXECUTE-PARSING allows you to pass the <something> as string on the
stack.

>The recognizer proposal needs a number of example cases to convince 
>especially Stephen, anyways ;-).

Do you think that anything that is not in one of his paying client's
code bases is not dismissed by him as irrelevant because application
programmers don't need this.

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#44499

Anton Ertl wrote:
>>It's probably easier to use recognizers for parsing more than one word.
> 
> Easier than what?  EXECUTE-PARSING and recognizers do not solve the
> same problems, so your sentence does not make sense in this context.

For EXECUTE-PARSING-FILE ("more than one word").  The current method is that 
you need to provide your own version of READ-LOOP, so you do everything 
including the REFILL.  In most cases, the REFILL-style approach is perfectly 
fine, you only want to replace the actual interpreter.

And that's what the recognizer stack can do.

> However, while we are at it, how do we solve the problem that
> EXECUTE-PARSING solves for parsing words for recognizers?
> 
> Say, we have a recognizer for environment variables (for the pattern
> "$<var>), but the programmer of the recognizer did not provide the
> environment lookup as a factor, and now we want to look up an
> environmental variable whose name we get from, say, a file.  How do we
> make use of the environment lookup buried in the recognizer?

Pass $<var> as string to that recognizer.  It will return either a R:FAIL 
(i.e. "no such variable exists") or something else, in which case you can 
either interpret or compile the result, as you want it.  Interpreting it 
will end up with the content on the stack.

I.e.

s" $HOME" rec:env r>int execute type

should print "/home/anton" or whatever your $HOME is (and potentially fail).  
You might want to use this when it conflicts with a hex number.

> Alternatively, we could pass some recognizer token to an
> EXECUTE-RECOGNIZER ( c-addr u rt -- ... flag ) word that is the
> recognizer equivalent of EXECUTE-PARSING, but if the programmer failed
> to give us the environment lookup as a factor, he probably did not
> export the recognizer token, either; sure, one could look it up in the
> source code of the library, but that might change in the next version
> of the library.

The recognizer lookup word needs to be exported as a factor; in theory you 
could add just a :noname xt into the lookup stack, but that makes it 
difficult to re-arrange that lookup stack later.

>>The recognizer proposal needs a number of example cases to convince
>>especially Stephen, anyways ;-).
> 
> Do you think that anything that is not in one of his paying client's
> code bases is not dismissed by him as irrelevant because application
> programmers don't need this.

Given the huge amount of hooks in his outer interpreter, he's the one who 
needs the recognizers most badly, but he doesn't yet know it.  Each of the 
hook went there due to a specific customer feature request.  If he accepts 
the recognizer proposal, all future feature requests in this area have been 
handled.

Ok, thinking twice about this shows where my mistake is:  I'm a free 
software developer.  Feature requests therefore are my costs, and not a 
source of income for me.  That means I want to handle feature requests in a 
way that minimizes my workload.  For a "pay per feature request" business 
model, this is the wrong approach.  You want to solve exactly the requested 
feature request, but absolutely no other feature request, because that other 
feature request will be another source of income.

The result is a mess of hooks in INTERPRET, which can't be left out, even 
when a clean solution is available, because the customers don't want to 
change their sources.  The per-feature-request payment incentive 
automatically generates maintenance nightmares.

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

#44504

On 1/1/16 7:46 AM, Bernd Paysan wrote:
...
> Ok, thinking twice about this shows where my mistake is:  I'm a free
> software developer.  Feature requests therefore are my costs, and not a
> source of income for me.  That means I want to handle feature requests in a
> way that minimizes my workload.  For a "pay per feature request" business
> model, this is the wrong approach.  You want to solve exactly the requested
> feature request, but absolutely no other feature request, because that other
> feature request will be another source of income.
>
> The result is a mess of hooks in INTERPRET, which can't be left out, even
> when a clean solution is available, because the customers don't want to
> change their sources.  The per-feature-request payment incentive
> automatically generates maintenance nightmares.

That's a serious misunderstanding of how professional (i.e., for pay) 
software development works. Our clients are not paying for "features", 
they are paying to have problems solved, marketable products released 
for sale, and projects completed on time and on budget. "Features" are 
side effects, developed only in aid of achieving these goals. Companies 
such as MPE and FORTH, Inc. thrive on long-term relationships with our 
customers. This is only possible if we consistently meet their 
expectations for on-time, cost-effective delivery of reliable, working 
programs. That is the opposite of being in a "pay-per-feature" business!

Speaking for FORTH, Inc., for the most part our customers maintain their 
programs, not us. Indeed, a typical relationship is that we provide 
various system-level functionality (drivers, communication protocols, 
etc.) and they write most of the higher layers of the application. They 
are the ones who will have to live with their systems year after year. 
We help them understand how to develop maintainable applications.

Our customers consistently tell us that our products and services help 
them achieve their goals at a fraction of the cost of their colleagues 
and competitors using C and other languages. Forth enables them to do 
that because it makes the most efficient use of programmer's time and 
intelligence, making the development, testing, and long-term maintenance 
of their programs economical, so that they can maintain a profitable 
business. If our customers win, we win.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#44510

Elizabeth D. Rather wrote:
> That's a serious misunderstanding of how professional (i.e., for pay)
> software development works.

I've done that.  There's a serious misunderstanding on your side how 
incentives works: They just work.  Whatever global minimum is there in the 
incentive space will be reached.  It you have the incentive to get money for 
maintenance, those companies will survive who makes money by maintenance, 
and those who don't, because their product just works, will go out of 
business.  The larger the scale, the more likely the global minimum will be 
reached by all players, which is why companies like Microsoft are the way 
they are.  At no point in time there needs to be a conscious decision to do 
it that way, this is just a matter of evolution.

Changing the incentive changes the outcome.  Add free software to that: I, 
as developer, want to minimize my costs; some free software is financed by 
maintenance (e.g. GCC), most isn't.  The projects which are financed by 
maintenance are maintenance nightmares, and they did become that during the 
time they were financed by maintenance.  If they hadn't, the business model 
wouldn't have worked, and the pay-for-maintenance company would have been 
out of business.  They didn't, they are the biggest company making 
exclusively money from free software now.

On the other extreme of Linux distributions there is Debian, which is full 
of really ancient packages, because the package maintainer's incentive 
directs him towards doing absolutely nothing.  There is not even a way to 
take over when the maintainer sits on ancient packages and doesn't release 
them.  That's not good, either.  So incentives matter.

> Our clients are not paying for "features",
> they are paying to have problems solved, marketable products released
> for sale, and projects completed on time and on budget. "Features" are
> side effects, developed only in aid of achieving these goals.

Yes, and the other requirements you have listed probably press for a quick 
patch instead for a solution that's good in the long run, but requires more 
time to think about it and to get it right.

> Companies
> such as MPE and FORTH, Inc. thrive on long-term relationships with our
> customers. This is only possible if we consistently meet their
> expectations for on-time, cost-effective delivery of reliable, working
> programs. That is the opposite of being in a "pay-per-feature" business!

I'm sure, in the long run you want to follow the same approach of good 
engineering as I want.  Actually, the magic of incentives take over, and 
when we have different incentives, we will optimize our strategies 
differently.

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

#44503

On 1/1/16 3:38 AM, Anton Ertl wrote:
> Bernd Paysan <bernd.paysan@gmx.de> writes:
...
>> The recognizer proposal needs a number of example cases to convince
>> especially Stephen, anyways ;-).
>
> Do you think that anything that is not in one of his paying client's
> code bases is not dismissed by him as irrelevant because application
> programmers don't need this.

It's not so much an issue of whether "paying clients" use something, 
although that's certainly an important consideration, but more 
importantly I think before standardizing something there should be a 
consideration of whether it's really needed in application programming. 
Too many things get proposed here because they're "cool" or "language X 
does it".

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#44506

Elizabeth D. Rather wrote:

> On 1/1/16 3:38 AM, Anton Ertl wrote:
>> Bernd Paysan <bernd.paysan@gmx.de> writes:
> ...
>>> The recognizer proposal needs a number of example cases to convince
>>> especially Stephen, anyways ;-).
>>
>> Do you think that anything that is not in one of his paying client's
>> code bases is not dismissed by him as irrelevant because application
>> programmers don't need this.
> 
> It's not so much an issue of whether "paying clients" use something,
> although that's certainly an important consideration, but more
> importantly I think before standardizing something there should be a
> consideration of whether it's really needed in application programming.
> Too many things get proposed here because they're "cool" or "language X
> does it".

Recognizers haven't been done by any other language, at least I don't know 
of it.  Other languages usually have a much more fixed syntax and semantics, 
and are way less flexible than Forth, so adding more flexibility with 
recognizers is something unthinkable for them.

One particular motivation for recognizer is that some Forth systems already 
provide an ample amount of special-purpose hooks (MPE's VFX as example), 
which apparently have been added one-by-one each for one particular feature, 
instead of looking for the more general picture how to make the interpreter 
flexible enough so that there's one hook to rule them all (all extensions).  
Years ago, we had some discussion about "let's standardize on interpreter 
hooks", and then we found out that there are about ten different interpreter 
hooks, most of them in one particular interpreter.  There is no way to 
standardize on this mess, because the only general-purpose hook in the hook 
mess is the "replace the entire interpeter"-hook.

On the other hand, the recognizer proposal got the most opposition from 
exactly these people who added hook after hook to their own outer 
interpreter.  With the most funny "solution" to add a few more hooks 
instead...

Maybe they are simply locked into their way of thinking about hooks in the 
interpreter.

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

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

csiph-web