Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #16855 > unrolled thread
| Started by | Mark Wills <forthfreak@gmail.com> |
|---|---|
| First post | 2012-10-31 04:58 -0700 |
| Last post | 2012-11-02 13:13 -0400 |
| Articles | 20 on this page of 169 — 25 participants |
Back to article view | Back to comp.lang.forth
Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-10-31 04:58 -0700
Re: Is there a better way? Paul Rubin <no.email@nospam.invalid> - 2012-10-31 05:22 -0700
Re: Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-10-31 05:44 -0700
Re: Is there a better way? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-31 11:29 -0400
Re: Is there a better way? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-31 11:40 -0400
Re: Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-10-31 08:45 -0700
Re: Is there a better way? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-02 04:48 -0400
Re: Is there a better way? rickman <gnuarm@gmail.com> - 2012-10-31 21:42 -0400
Re: Is there a better way? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-01 19:19 -0700
Re: Is there a better way? rickman <gnuarm@gmail.com> - 2012-11-02 13:06 -0400
Re: Is there a better way? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-02 12:18 -0500
Re: Is there a better way? rickman <gnuarm@gmail.com> - 2012-11-02 14:34 -0400
Re: Is there a better way? Paul Rubin <no.email@nospam.invalid> - 2012-11-02 11:39 -0700
Re: Is there a better way? rickman <gnuarm@gmail.com> - 2012-11-02 14:43 -0400
Re: Is there a better way? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-04 02:36 -0600
Re: Is there a better way? rickman <gnuarm@gmail.com> - 2012-11-04 14:18 -0500
Re: Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-11-02 14:38 -0700
Re: Is there a better way? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-04 03:01 -0600
Re: Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-11-04 03:54 -0800
Re: Is there a better way? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-04 07:59 -0600
Re: Is there a better way? Elizabeth D Rather <erather@forth.com> - 2012-11-04 08:34 -1000
Re: Is there a better way? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-04 15:22 -0800
Re: Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-11-05 02:39 -0800
Words consuming arguments, was [Re: Is there a better way?] "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-05 14:01 -0500
Re: Words consuming arguments, was [Re: Is there a better way?] "Elizabeth D. Rather" <erather@forth.com> - 2012-11-05 10:39 -1000
Re: Words consuming arguments, was [Re: Is there a better way?] Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-05 21:07 -0800
Re: Words consuming arguments, was [Re: Is there a better way?] "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-06 20:57 -0500
Re: Words consuming arguments, was [Re: Is there a better way?] Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-06 21:43 -0800
Re: Words consuming arguments, was [Re: Is there a better way?] Mark Wills <forthfreak@gmail.com> - 2012-11-07 03:52 -0800
Re: Words consuming arguments, was [Re: Is there a better way?] "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-07 19:55 -0500
Re: Words consuming arguments, was [Re: Is there a better way?] "Elizabeth D. Rather" <erather@forth.com> - 2012-11-07 20:46 -1000
Re: Words consuming arguments, was [Re: Is there a better way?] stephenXXX@mpeforth.com (Stephen Pelc) - 2012-11-08 10:39 +0000
Re: Words consuming arguments, was [Re: Is there a better way?] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-12 03:48 -0600
Re: Words consuming arguments, was [Re: Is there a better way?] "Elizabeth D. Rather" <erather@forth.com> - 2012-11-12 07:57 -1000
Re: Words consuming arguments, was [Re: Is there a better way?] "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-12 19:50 -0500
Re: Words consuming arguments, was [Re: Is there a better way?] "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-12 19:49 -0500
Re: Words consuming arguments, was [Re: Is there a better way?] "Elizabeth D. Rather" <erather@forth.com> - 2012-11-12 15:00 -1000
Re: Words consuming arguments, was [Re: Is there a better way?] Mark Wills <forthfreak@gmail.com> - 2012-11-13 00:50 -0800
Re: Words consuming arguments, was [Re: Is there a better way?] Mark Wills <forthfreak@gmail.com> - 2012-11-13 00:58 -0800
Re: Words consuming arguments, was [Re: Is there a better way?] "Elizabeth D. Rather" <erather@forth.com> - 2012-11-12 23:17 -1000
Re: Words consuming arguments, was [Re: Is there a better way?] albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-11-13 13:44 +0000
Re: Words consuming arguments, was [Re: Is there a better way?] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-13 13:53 +0000
Re: Words consuming arguments, was [Re: Is there a better way?] Alex McDonald <blog@rivadpm.com> - 2012-11-13 06:39 -0800
Re: Words consuming arguments, was [Re: Is there a better way?] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-13 18:02 +0000
Re: Words consuming arguments, was [Re: Is there a better way?] Alex McDonald <blog@rivadpm.com> - 2012-11-13 12:10 -0800
Re: Words consuming arguments, was [Re: Is there a better way?] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-15 16:59 +0000
Re: Words consuming arguments, was [Re: Is there a better way?] Mark Wills <forthfreak@gmail.com> - 2012-11-13 07:55 -0800
Re: Words consuming arguments, was [Re: Is there a better way?] "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-14 06:34 -0500
Re: Words consuming arguments, was [Re: Is there a better way?] Mark Wills <forthfreak@gmail.com> - 2012-11-14 05:01 -0800
Re: Words consuming arguments, was [Re: Is there a better way?] albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-11-14 16:11 +0000
Re: Words consuming arguments, was [Re: Is there a better way?] "Elizabeth D. Rather" <erather@forth.com> - 2012-11-14 09:36 -1000
Re: Words consuming arguments, was [Re: Is there a better way?] humptydumpty <ouatubi@gmail.com> - 2012-11-14 12:19 -0800
Re: Words consuming arguments, was [Re: Is there a better way?] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-13 10:20 -0600
Re: Words consuming arguments, was [Re: Is there a better way?] Brad Eckert <hwfwguy@gmail.com> - 2012-11-13 08:50 -0800
Re: Words consuming arguments, was [Re: Is there a better way?] "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-14 06:42 -0500
Re: Words consuming arguments, was [Re: Is there a better way?] stephenXXX@mpeforth.com (Stephen Pelc) - 2012-11-14 14:14 +0000
Re: Words consuming arguments, was [Re: Is there a better way?] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-14 15:28 +0000
Re: Words consuming arguments, was [Re: Is there a better way?] Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-14 17:54 +0100
Re: Words consuming arguments, was [Re: Is there a better way?] Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-14 15:01 -0800
Re: Words consuming arguments, was [Re: Is there a better way?] Mark Wills <forthfreak@gmail.com> - 2012-11-15 00:08 -0800
Strings (was: Words consuming arguments) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-15 15:18 +0000
Re: Strings (was: Words consuming arguments) albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-11-15 16:36 +0000
Re: Strings (was: Words consuming arguments) "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-15 18:35 -0500
Re: Strings (was: Words consuming arguments) stephenXXX@mpeforth.com (Stephen Pelc) - 2012-11-16 00:36 +0000
Re: Strings (was: Words consuming arguments) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-16 17:42 +0000
Re: Strings (was: Words consuming arguments) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-16 17:55 +0000
Re: Words consuming arguments, was [Re: Is there a better way?] Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-17 04:18 -0800
Re: Words consuming arguments, was [Re: Is there a better way?] Alex McDonald <blog@rivadpm.com> - 2012-11-17 04:56 -0800
Re: Words consuming arguments, was [Re: Is there a better way?] "Elizabeth D. Rather" <erather@forth.com> - 2012-11-17 07:24 -1000
Re: Words consuming arguments, was [Re: Is there a better way?] Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-19 15:58 -0800
Re: Words consuming arguments, was [Re: Is there a better way?] Brad Eckert <hwfwguy@gmail.com> - 2012-11-20 08:17 -0800
Re: Words consuming arguments, was [Re: Is there a better way?] "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-14 06:30 -0500
Re: Words consuming arguments, was [Re: Is there a better way?] "Elizabeth D. Rather" <erather@forth.com> - 2012-11-14 09:06 -1000
Re: Words consuming arguments, was [Re: Is there a better way?] "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-15 06:18 -0500
Re: Words consuming arguments, was [Re: Is there a better way?] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-13 04:26 -0600
Re: Words consuming arguments, was [Re: Is there a better way?] "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-14 06:29 -0500
Re: Words consuming arguments, was [Re: Is there a better way?] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-14 06:03 -0600
Re: Words consuming arguments, was [Re: Is there a better way?] "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-15 07:15 -0500
Re: Words consuming arguments, was [Re: Is there a better way?] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-15 11:51 -0600
Re: Words consuming arguments, was [Re: Is there a better way?] "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-15 18:44 -0500
Re: Words consuming arguments, was [Re: Is there a better way?] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-16 03:50 -0600
Re: Words consuming arguments, was [Re: Is there a better way?] "Elizabeth D. Rather" <erather@forth.com> - 2012-11-15 08:09 -1000
Re: Words consuming arguments, was [Re: Is there a better way?] "Elizabeth D. Rather" <erather@forth.com> - 2012-11-06 21:19 -1000
Re: Words consuming arguments, was [Re: Is there a better way?] "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-07 20:00 -0500
Re: Words consuming arguments, was [Re: Is there a better way?] stephenXXX@mpeforth.com (Stephen Pelc) - 2012-11-08 10:49 +0000
Re: Words consuming arguments, was [Re: Is there a better way?] albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-11-07 14:01 +0000
Re: Is there a better way? awegel@arcor.de (Alex Wegel) - 2012-11-04 11:07 +0100
Re: Is there a better way? awegel@arcor.de (Alex Wegel) - 2012-11-04 11:36 +0100
Re: Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-11-04 03:48 -0800
Re: Is there a better way? awegel@arcor.de (Alex Wegel) - 2012-11-04 13:31 +0100
Re: Is there a better way? Coos Haak <chforth@hccnet.nl> - 2012-11-04 13:29 +0100
Re: Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-11-04 04:42 -0800
Re: Is there a better way? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-04 02:38 -0600
Re: Is there a better way? Doug Hoffman <glidedog@gmail.com> - 2012-10-31 10:20 -0400
Re: Is there a better way? humptydumpty <ouatubi@gmail.com> - 2012-10-31 05:53 -0700
Re: Is there a better way? Doug Hoffman <glidedog@gmail.com> - 2012-10-31 09:23 -0400
Re: Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-10-31 06:41 -0700
Re: Is there a better way? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-31 11:46 -0500
Re: Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-10-31 14:27 -0700
Re: Is there a better way? Paul Rubin <no.email@nospam.invalid> - 2012-10-31 14:32 -0700
Re: Is there a better way? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-31 16:15 -0700
Re: Is there a better way? Coos Haak <chforth@hccnet.nl> - 2012-10-31 22:49 +0100
Re: Is there a better way? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-31 17:13 -0500
Re: Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-10-31 23:39 -0700
Re: Is there a better way? "Elizabeth D. Rather" <erather@forth.com> - 2012-10-31 20:58 -1000
Re: Is there a better way? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-01 02:04 -0700
Re: Is there a better way? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-31 19:13 -0400
Re: Is there a better way? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-02 17:31 +0000
Re: Is there a better way? Paul Rubin <no.email@nospam.invalid> - 2012-11-02 10:37 -0700
Re: Is there a better way? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-02 18:12 +0000
Re: Is there a better way? "Elizabeth D. Rather" <erather@forth.com> - 2012-11-02 08:29 -1000
Re: Is there a better way? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-05 14:53 +0000
Re: Is there a better way? Paul Rubin <no.email@nospam.invalid> - 2012-11-02 11:30 -0700
Re: Is there a better way? Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-03 00:15 +0100
Re: Is there a better way? rickman <gnuarm@gmail.com> - 2012-11-02 19:21 -0400
Re: Is there a better way? Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-03 00:42 +0100
Re: Is there a better way? rickman <gnuarm@gmail.com> - 2012-11-02 20:21 -0400
Re: Is there a better way? Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-03 01:44 +0100
Re: Is there a better way? rickman <gnuarm@gmail.com> - 2012-11-03 12:12 -0400
Re: Is there a better way? Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-03 18:24 +0100
Re: Is there a better way? rickman <gnuarm@gmail.com> - 2012-11-03 14:00 -0400
Re: Is there a better way? Paul Rubin <no.email@nospam.invalid> - 2012-11-03 10:29 -0700
Re: Is there a better way? Paul Rubin <no.email@nospam.invalid> - 2012-11-02 18:42 -0700
Re: Is there a better way? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-05 11:45 +0000
Re: Is there a better way? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-11-01 21:00 +0000
Re: Is there a better way? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-10-31 15:26 +0000
Re: Is there a better way? Doug Hoffman <glidedog@gmail.com> - 2012-10-31 12:22 -0400
Re: Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-10-31 15:07 -0700
Re: Is there a better way? Doug Hoffman <glidedog@gmail.com> - 2012-10-31 19:16 -0400
Re: Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-11-01 06:31 -0700
Re: Is there a better way? Doug Hoffman <glidedog@gmail.com> - 2012-11-01 10:34 -0400
Re: Is there a better way? Doug Hoffman <glidedog@gmail.com> - 2012-11-01 10:48 -0400
Re: Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-11-01 08:55 -0700
Re: Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-11-01 08:49 -0700
Re: Is there a better way? Doug Hoffman <glidedog@gmail.com> - 2012-11-01 12:46 -0400
Re: Is there a better way? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-01 09:37 -0500
Re: Is there a better way? Paul Rubin <no.email@nospam.invalid> - 2012-11-01 07:41 -0700
Re: Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-11-01 08:52 -0700
Re: Is there a better way? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-01 12:18 -0500
Re: Is there a better way? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-01 19:38 -0700
Re: Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-11-02 02:29 -0700
Re: Is there a better way? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-04 21:48 -0800
Re: Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-11-05 02:44 -0800
Re: Is there a better way? Graham NEWS <gray@forthman.plus.com> - 2012-11-01 15:52 +0000
Re: Is there a better way? Josh Grams <josh@qualdan.com> - 2012-11-03 16:38 +0000
Re: Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-10-31 14:26 -0700
Re: Is there a better way? rickman <gnuarm@gmail.com> - 2012-11-01 13:42 -0400
Re: Is there a better way? Graham <""gray\"@forthman@plus.com"> - 2012-10-31 17:05 +0000
Re: Is there a better way? Peter Fälth <peter.falth@tin.it> - 2012-10-31 12:07 -0700
Re: Is there a better way? Paul Rubin <no.email@nospam.invalid> - 2012-10-31 12:12 -0700
Re: Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-10-31 14:17 -0700
Re: Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-10-31 14:21 -0700
Re: Is there a better way? Pablo Hugo Reda <pabloreda@gmail.com> - 2012-10-31 14:50 -0700
Re: Is there a better way? Pablo Hugo Reda <pabloreda@gmail.com> - 2012-10-31 14:51 -0700
Re: Is there a better way? Paul Rubin <no.email@nospam.invalid> - 2012-10-31 14:57 -0700
Re: Is there a better way? Coos Haak <chforth@hccnet.nl> - 2012-10-31 23:47 +0100
Re: Is there a better way? mhx@iae.nl (Marcel Hendrix) - 2012-11-01 21:28 +0200
Re: Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-10-31 15:11 -0700
Re: Is there a better way? Pablo Hugo Reda <pabloreda@gmail.com> - 2012-10-31 15:44 -0700
Re: Is there a better way? rickman <gnuarm@gmail.com> - 2012-11-01 13:55 -0400
Re: Is there a better way? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-31 16:10 -0700
Re: Is there a better way? Charles Mélice <charles.melice@gmail.com> - 2012-11-02 01:10 -0700
Re: Is there a better way? Charles Mélice <charles.melice@gmail.com> - 2012-11-02 01:18 -0700
Re: Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-11-02 01:58 -0700
Re: Is there a better way? Charles Mélice <charles.melice@gmail.com> - 2012-11-02 02:14 -0700
Re: Is there a better way? Charles Mélice <charles.melice@gmail.com> - 2012-11-02 02:16 -0700
Re: Is there a better way? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-02 06:16 -0500
Re: Is there a better way? Charles Mélice <charles.melice@gmail.com> - 2012-11-02 06:04 -0700
Re: Is there a better way? rickman <gnuarm@gmail.com> - 2012-11-02 13:13 -0400
Page 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
| From | Elizabeth D Rather <erather@forth.com> |
|---|---|
| Date | 2012-11-04 08:34 -1000 |
| Message-ID | <Tq2dncwBFL7RKAvNnZ2dnUVZ_qGdnZ2d@supernews.com> |
| In reply to | #17032 |
On 11/4/2012 1:54 AM, Mark Wills wrote: ... > Well, a famous man once said: "Opinions are like ass-holes. Everyone > has one, and they're different". > > Is there any word naming convention that you (or anyone else) is aware > of that could indicate that a word does not consume its arguments? > Some opinions have more years of experience behind them than others. An example in a vacuum may look like one usage is prettier, but when you've been through the application development wars a bit you learn that certain useful habits will pay off for you. Such a naming convention doesn't exist because most programmers using Forth in "real world" applications, particularly large ones, learn the value of a word that is reusable, and also learn that something that appears to be an optimization in one place may make the word less usable in others. "A word should consume its arguments" is a rule that has been time-tested, independently, by many professionals. 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]
| From | Hugh Aguilar <hughaguilar96@yahoo.com> |
|---|---|
| Date | 2012-11-04 15:22 -0800 |
| Message-ID | <62cb4769-1a1e-4095-9474-edb37cb9053d@pb2g2000pbc.googlegroups.com> |
| In reply to | #17041 |
On Nov 4, 11:34 am, Elizabeth D Rather <erat...@forth.com> wrote: > On 11/4/2012 1:54 AM, Mark Wills wrote: > ... > > > Well, a famous man once said: "Opinions are like ass-holes. Everyone > > has one, and they're different". > > > Is there any word naming convention that you (or anyone else) is aware > > of that could indicate that a word does not consume its arguments? > > Some opinions have more years of experience behind them than others. An > example in a vacuum may look like one usage is prettier, but when you've > been through the application development wars a bit you learn that > certain useful habits will pay off for you. > > Such a naming convention doesn't exist because most programmers using > Forth in "real world" applications, particularly large ones, learn the > value of a word that is reusable, and also learn that something that > appears to be an optimization in one place may make the word less usable > in others. "A word should consume its arguments" is a rule that has been > time-tested, independently, by many professionals. > > 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 90045http://www.forth.com > > "Forth-based products and Services for real-time > applications since 1973." > ================================================== This is true, Mark --- it really does help to make words reusable if they consume their arguments --- this has been well-known for decades. As I suggested before: read "Thinking Forth." Look at the novice package. I do this consistently. There are a few exceptions (INIT-LIST comes to mind) that don't consume their arguments, and were done this way to boost the speed (all of them, like INIT-LIST, are used in a ritualistic manner) --- for the most part though, I always have functions consume their arguments, which is the Forth way.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <forthfreak@gmail.com> |
|---|---|
| Date | 2012-11-05 02:39 -0800 |
| Message-ID | <ccc298bd-9de6-4def-a4c6-4f31c17af369@ez26g2000vbb.googlegroups.com> |
| In reply to | #17046 |
On Nov 4, 11:22 pm, Hugh Aguilar <hughaguila...@yahoo.com> wrote: > On Nov 4, 11:34 am, Elizabeth D Rather <erat...@forth.com> wrote: > > > > > > > On 11/4/2012 1:54 AM, Mark Wills wrote: > > ... > > > > Well, a famous man once said: "Opinions are like ass-holes. Everyone > > > has one, and they're different". > > > > Is there any word naming convention that you (or anyone else) is aware > > > of that could indicate that a word does not consume its arguments? > > > Some opinions have more years of experience behind them than others. An > > example in a vacuum may look like one usage is prettier, but when you've > > been through the application development wars a bit you learn that > > certain useful habits will pay off for you. > > > Such a naming convention doesn't exist because most programmers using > > Forth in "real world" applications, particularly large ones, learn the > > value of a word that is reusable, and also learn that something that > > appears to be an optimization in one place may make the word less usable > > in others. "A word should consume its arguments" is a rule that has been > > time-tested, independently, by many professionals. > > > 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 90045http://www.forth.com > > > "Forth-based products and Services for real-time > > applications since 1973." > > ================================================== > > This is true, Mark --- it really does help to make words reusable if > they consume their arguments --- this has been well-known for decades. > As I suggested before: read "Thinking Forth." > > Look at the novice package. I do this consistently. There are a few > exceptions (INIT-LIST comes to mind) that don't consume their > arguments, and were done this way to boost the speed (all of them, > like INIT-LIST, are used in a ritualistic manner) --- for the most > part though, I always have functions consume their arguments, which is > the Forth way.- Hide quoted text - > > - Show quoted text - Okay okay! Hugh, Andrew and Elizabeth have beaten me into submission! ;-) I promise I'll write all words in the future to conume their arguments. I'm not brash enough to go against the grain of collective Forth programming experience. If you guys advise that it's the the best way, then perhaps I'll just accept it and save myself the pain of finding it out the hard way! I'll submit some further code in a few days (it will be a few days before I can get some time to properly concentrate on it) and you guys can pick it apart!
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailnotz.cnm> |
|---|---|
| Date | 2012-11-05 14:01 -0500 |
| Subject | Words consuming arguments, was [Re: Is there a better way?] |
| Message-ID | <k7926a$aob$1@speranza.aioe.org> |
| In reply to | #17057 |
"Mark Wills" <forthfreak@gmail.com> wrote in message news:ccc298bd-9de6-4def-a4c6-4f31c17af369@ez26g2000vbb.googlegroups.com... > On Nov 4, 11:22 pm, Hugh Aguilar <hughaguila...@yahoo.com> wrote: > > On Nov 4, 11:34 am, Elizabeth D Rather <erat...@forth.com> wrote: ... > > > Such a naming convention doesn't exist because most programmers using > > > Forth in "real world" applications, particularly large ones, learn the > > > value of a word that is reusable, and also learn that something that > > > appears to be an optimization in one place may make the word less > > > usable in others. "A word should consume its arguments" is a rule > > > that has been time-tested, independently, by many professionals. > > > This is true, Mark --- it really does help to make words reusable if > > they consume their arguments --- this has been well-known for decades. > > As I suggested before: read "Thinking Forth." > > Okay okay! Hugh, Andrew and Elizabeth have beaten me into > submission! ;-) I promise I'll write all words in the future to con[s]ume > their arguments. I'm not brash enough to go against the grain of > collective Forth programming experience. If you guys advise that it's > the the best way, then perhaps I'll just accept it and save myself the > pain of finding it out the hard way! > I take it this is to make sure extra arguments aren't left on the stack as a primitive form of "error checking". However, I really don't see the point of this. In certain situations, the style that breaks the "rule" may be create more effective coding. As I see it (AISI), the primary effect of this "rule" is to shift the location where parameters are duplicated or copied, and/or dropped. If a word preserves arguments, then the copying is internal. If it doesn't, then external. While the example below with the DROP has the disadvantage of using a DROP, it has the advantage that it can modify 'addr'. This seems to be very useful for parsing words and linked-lists. Isn't it? : OPR ( addr -- addr ) DUP ... ; ' addr' OPR OPR OPR OPR DROP : OPR ( addr -- ) ... ; 'addr' DUP OPR DUP OPR DUP OPR OPR Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2012-11-05 10:39 -1000 |
| Subject | Re: Words consuming arguments, was [Re: Is there a better way?] |
| Message-ID | <o6WdnVkWKcFjvgXNnZ2dnUVZ_sudnZ2d@supernews.com> |
| In reply to | #17071 |
On 11/5/12 9:01 AM, Rod Pemberton wrote: > "Mark Wills" <forthfreak@gmail.com> wrote in message > news:ccc298bd-9de6-4def-a4c6-4f31c17af369@ez26g2000vbb.googlegroups.com... >> On Nov 4, 11:22 pm, Hugh Aguilar <hughaguila...@yahoo.com> wrote: >>> On Nov 4, 11:34 am, Elizabeth D Rather <erat...@forth.com> wrote: > ... > >>>> Such a naming convention doesn't exist because most programmers using >>>> Forth in "real world" applications, particularly large ones, learn the >>>> value of a word that is reusable, and also learn that something that >>>> appears to be an optimization in one place may make the word less >>>> usable in others. "A word should consume its arguments" is a rule >>>> that has been time-tested, independently, by many professionals. >> >>> This is true, Mark --- it really does help to make words reusable if >>> they consume their arguments --- this has been well-known for decades. >>> As I suggested before: read "Thinking Forth." >> >> Okay okay! Hugh, Andrew and Elizabeth have beaten me into >> submission! ;-) I promise I'll write all words in the future to con[s]ume >> their arguments. I'm not brash enough to go against the grain of >> collective Forth programming experience. If you guys advise that it's >> the the best way, then perhaps I'll just accept it and save myself the >> pain of finding it out the hard way! >> > > I take it this is to make sure extra arguments aren't left on the stack as a > primitive form of "error checking". However, I really don't see the point > of this. In certain situations, the style that breaks the "rule" may be > create more effective coding. > > As I see it (AISI), the primary effect of this "rule" is to shift the > location where parameters are duplicated or copied, and/or dropped. If a > word preserves arguments, then the copying is internal. If it doesn't, then > external. While the example below with the DROP has the disadvantage > of using a DROP, it has the advantage that it can modify 'addr'. This > seems to be very useful for parsing words and linked-lists. Isn't it? > > : OPR ( addr -- addr ) DUP ... ; > ' addr' OPR OPR OPR OPR DROP > > : OPR ( addr -- ) ... ; > 'addr' DUP OPR DUP OPR DUP OPR OPR Sure, there are situations when you're coding part of a process that needs to pass things right through the process. The classic example would be the output number formatting words: <# starts the process, taking a double and initializing the string output area. Then words like # and #s do things to the double, affecting the string under construction and passing on the modified double, and the process is completed by #> . But note that # etc. are *useless* outside of this particular context. That is the tradeoff. Most of the time, it's better to code the word such that it isn't context-dependent, even though the first time you invent it it's within a specific context. 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]
| From | Hugh Aguilar <hughaguilar96@yahoo.com> |
|---|---|
| Date | 2012-11-05 21:07 -0800 |
| Subject | Re: Words consuming arguments, was [Re: Is there a better way?] |
| Message-ID | <aafcb3a4-dab1-4390-8e10-b894284686c2@6g2000pbh.googlegroups.com> |
| In reply to | #17077 |
On Nov 5, 1:39 pm, "Elizabeth D. Rather" <erat...@forth.com> wrote: > On 11/5/12 9:01 AM, Rod Pemberton wrote: > > I take it this is to make sure extra arguments aren't left on the stack as a > > primitive form of "error checking". However, I really don't see the point > > of this. In certain situations, the style that breaks the "rule" may be > > create more effective coding. > > > As I see it (AISI), the primary effect of this "rule" is to shift the > > location where parameters are duplicated or copied, and/or dropped. If a > > word preserves arguments, then the copying is internal. If it doesn't, then > > external. While the example below with the DROP has the disadvantage > > of using a DROP, it has the advantage that it can modify 'addr'. This > > seems to be very useful for parsing words and linked-lists. Isn't it? > > > : OPR ( addr -- addr ) DUP ... ; > > ' addr' OPR OPR OPR OPR DROP > > > : OPR ( addr -- ) ... ; > > 'addr' DUP OPR DUP OPR DUP OPR OPR > > Sure, there are situations when you're coding part of a process that > needs to pass things right through the process. The classic example > would be the output number formatting words: > > <# starts the process, taking a double and initializing the string > output area. > > Then words like # and #s do things to the double, affecting the string > under construction and passing on the modified double, and the process > is completed by #> . > > But note that # etc. are *useless* outside of this particular context. > That is the tradeoff. Most of the time, it's better to code the word > such that it isn't context-dependent, even though the first time you > invent it it's within a specific context. > > Cheers, > Elizabeth This is what I meant earlier by the word having a "ritualistic" use. My example was INIT-LIST. This is used in a very specific context and always in the same way. Whenever you create a node, the first thing that you do with the address is initialize it for whatever type it is going to be, and the datum (the node address) is being carried along. This is similar to how # is used only inside of <# and #>, and the datum (the double- precision integer) is being carried along. Putting the DUP (or 2DUP or whatever) inside the word helps with efficiency because the ritualistic word is typically so commonly used that you will likely write in in assembly-language. If the word isn't used in a ritualistic manner though, then you don't know if the datum is going to be needed afterward or not. You may either have a DUP before the word (if it consumes its argument) or a DROP after the word (if it doesn't). It is best to be consistent and have the words consume their arguments. This way there is no confusion about whether you need a DUP or a DROP. Also, it tends to be more efficient because the code inside of the word consumes the data and you don't have an explicit DROP. As an example, here are two ways to write the + word: : + ( a b -- a+b ) which is used like this: 5 7 + . 12 ok or : + ( a b -- a b a+b ) which is used like this: 5 7 + . 2drop 12 ok Pretty obvious which makes for the most readable code, don't you think?
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailnotz.cnm> |
|---|---|
| Date | 2012-11-06 20:57 -0500 |
| Subject | Re: Words consuming arguments, was [Re: Is there a better way?] |
| Message-ID | <k7ceuc$fb4$1@speranza.aioe.org> |
| In reply to | #17080 |
"Hugh Aguilar" <hughaguilar96@yahoo.com> wrote in message news:aafcb3a4-dab1-4390-8e10-b894284686c2@6g2000pbh.googlegroups.com... > On Nov 5, 1:39 pm, "Elizabeth D. Rather" <erat...@forth.com> wrote: > > On 11/5/12 9:01 AM, Rod Pemberton wrote: ... > > > I take it this is to make sure extra arguments aren't left on the > > > stack as a primitive form of "error checking". However, I really > > > don't see the point of this. In certain situations, the style that > > > breaks the "rule" may [...] create more effective coding. > > > > As I see it (AISI), the primary effect of this "rule" is to shift the > > > location where parameters are duplicated or copied, and/or dropped. If > > > a word preserves arguments, then the copying is internal. If it > > > doesn't, then external. While the example below with the DROP has the > > > disadvantage of using a DROP, it has the advantage that it can modify > > > 'addr'. This seems to be very useful for parsing words and > > > linked-lists. Isn't it? > > > > : OPR ( addr -- addr ) DUP ... ; > > > ' addr' OPR OPR OPR OPR DROP > > > > : OPR ( addr -- ) ... ; > > > 'addr' DUP OPR DUP OPR DUP OPR OPR > > > Sure, there are situations when you're coding part of a process that > > needs to pass things right through the process. The classic example > > would be the output number formatting words: > > > <# starts the process, taking a double and initializing the string > > output area. > > > Then words like # and #s do things to the double, affecting the string > > under construction and passing on the modified double, and the process > > is completed by #> . > > > But note that # etc. are *useless* outside of this particular context. > > That is the tradeoff. Most of the time, it's better to code the word > > such that it isn't context-dependent, even though the first time you > > invent it it's within a specific context. > > This is what I meant earlier by the word having a "ritualistic" use. > My example was INIT-LIST. This is used in a very specific context and > always in the same way. > > Whenever you create a node, the first thing that you do with the > address is initialize it for whatever type it is going to be, and the > datum (the node address) is being carried along. This is similar to > how # is used only inside of <# and #>, and the datum (the double- > precision integer) is being carried along. > > Putting the DUP (or 2DUP or whatever) inside the word helps with > efficiency because the ritualistic word is typically so commonly used > that you will likely write in in assembly-language. > > If the word isn't used in a ritualistic manner though, then you don't > know if the datum is going to be needed afterward or not. You may > either have a DUP before the word (if it consumes its argument) or a > DROP after the word (if it doesn't). It is best to be consistent and > have the words consume their arguments. This way there is no confusion > about whether you need a DUP or a DROP. Also, it tends to be more > efficient because the code inside of the word consumes the data and > you don't have an explicit DROP. > > As an example, here are two ways to write the + word: > > : + ( a b -- a+b ) > which is used like this: > 5 7 + . > 12 ok > > or > > : + ( a b -- a b a+b ) > which is used like this: > 5 7 + . 2drop > 12 ok > > Pretty obvious which makes for the most readable code, > don't you think? > No, I think it depends on what is needed the most. What about a word like COUNT ? COUNT ( addr -- addr len ) Would you rather use a DUP every time you needed to use COUNT at the prompt? E.g., DUP in front of a COUNT TYPE sequence? No, you're not going to do that ... You're going to forget to use the 'pesky' DUP just as easily as you'd forget a 'pesky' DROP. So, you're going to move the needed DUP into COUNT - as was done. Or, you're going to rework TYPE to have DUP COUNT in TYPE's definition so a COUNT isn't needed prior to TYPE. Of course, if you rework TYPE, then you're going to need to rework all the other words that COUNT is used with or within: TYPE SPAN >IN WORD S" .( EXPECT etc. One solution is less work. I.e., Forth words that use a string seem to require both an address and length and so "readability" and/or "ritualistic use" doesn't seem like sound reasons. COUNT returns an address because of Forth's historical use of counted strings with the length at the start, i.e., addr needs an adjustment because of counted strings. Fortunately, the fact that COUNT seems to be used as the primary mechanism in Forth to obtain an address and length pair for string related Forth words from just a string address, completely hides the fact that I'm using null-terminated C strings. If Forth used other methods, or multiple methods, or had ways other than just one word: COUNT, then I'd have some problems using C style strings. So far (it may reveal itself later on ...), there is only an issue if strings are constructed manually as counted strings, as is done in Hayes core for one of it's tests. I.e., Hayes core assumes counted strings are used in Forth. I've not checked to see if they're a requirement or not, but I'm having good luck so far without them. There is another situation where I had used pointers/addresses instead of offsets. This is faster. But, one of the new ANS words basically "forced" use of offsets. At the time, I didn't see anything *requiring* offsets. So, I may look at whether it is possible to convert back to pointers instead of offsets in the future. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Hugh Aguilar <hughaguilar96@yahoo.com> |
|---|---|
| Date | 2012-11-06 21:43 -0800 |
| Subject | Re: Words consuming arguments, was [Re: Is there a better way?] |
| Message-ID | <45d4f07b-8d85-43e7-acc9-614966bdae14@uk1g2000pbb.googlegroups.com> |
| In reply to | #17098 |
On Nov 6, 6:53 pm, "Rod Pemberton" <do_not_h...@notemailnotz.cnm> wrote: > "Hugh Aguilar" <hughaguila...@yahoo.com> wrote in message > > As an example, here are two ways to write the + word: > > > : + ( a b -- a+b ) > > which is used like this: > > 5 7 + . > > 12 ok > > > or > > > : + ( a b -- a b a+b ) > > which is used like this: > > 5 7 + . 2drop > > 12 ok > > > Pretty obvious which makes for the most readable code, > > don't you think? > > No, I think it depends on what is needed the most. > > What about a word like COUNT ? > > COUNT ( addr -- addr len ) This is the stack picture for COUNT : : count ( adr1 -- adr2 len ) COUNT does consume adr1 --- and then it gives you back some other data (adr2 is not the same datum as adr1). This is not conceptually different from + which also consumes the data that it is given and then gives you back some other data. The only difference is that + consumes more data (2 cells) than it returns (1 cell), whereas COUNT does the opposite --- the former is much more common, but there is no conceptual difference really.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <forthfreak@gmail.com> |
|---|---|
| Date | 2012-11-07 03:52 -0800 |
| Subject | Re: Words consuming arguments, was [Re: Is there a better way?] |
| Message-ID | <0d6eae9e-2a93-4a43-a201-ee605589dccf@s14g2000vba.googlegroups.com> |
| In reply to | #17100 |
On Nov 7, 5:43 am, Hugh Aguilar <hughaguila...@yahoo.com> wrote: > On Nov 6, 6:53 pm, "Rod Pemberton" <do_not_h...@notemailnotz.cnm> > wrote: > > > > > > > "Hugh Aguilar" <hughaguila...@yahoo.com> wrote in message > > > As an example, here are two ways to write the + word: > > > > : + ( a b -- a+b ) > > > which is used like this: > > > 5 7 + . > > > 12 ok > > > > or > > > > : + ( a b -- a b a+b ) > > > which is used like this: > > > 5 7 + . 2drop > > > 12 ok > > > > Pretty obvious which makes for the most readable code, > > > don't you think? > > > No, I think it depends on what is needed the most. > > > What about a word like COUNT ? > > > COUNT ( addr -- addr len ) > > This is the stack picture for COUNT : > > : count ( adr1 -- adr2 len ) > > COUNT does consume adr1 --- and then it gives you back some other data > (adr2 is not the same datum as adr1). This is not conceptually > different from + which also consumes the data that it is given and > then gives you back some other data. The only difference is that + > consumes more data (2 cells) than it returns (1 cell), whereas COUNT > does the opposite --- the former is much more common, but there is no > conceptual difference really.- Hide quoted text - > > - Show quoted text - Yes. Hugh and Elizabeth make very good points. The classical definition of COUNT may be: : COUNT ( addr1 -- addr2 len ) DUP C@ SWAP 1+ SWAP ; But note that the address that comes back is ADDR*2*, not ADDR1. It's a different address. Yes, classically, the length byte is just in front of the string, but it doesn't have to be. The length byte might not be there at all: : COUNT ( addr1 -- addr2 len ) @ 0 BEGIN 2DUP + C@ WHILE 1+ REPEAT ; The above being suitable for C based systems that store null- terminated strings in a string heap outside of the dictionary (for example).
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailnotz.cnm> |
|---|---|
| Date | 2012-11-07 19:55 -0500 |
| Subject | Re: Words consuming arguments, was [Re: Is there a better way?] |
| Message-ID | <k7evm0$kls$1@speranza.aioe.org> |
| In reply to | #17100 |
"Hugh Aguilar" <hughaguilar96@yahoo.com> wrote in message news:45d4f07b-8d85-43e7-acc9-614966bdae14@uk1g2000pbb.googlegroups.com... > On Nov 6, 6:53 pm, "Rod Pemberton" <do_not_h...@notemailnotz.cnm> > wrote: > > "Hugh Aguilar" <hughaguila...@yahoo.com> wrote in message ... > > > As an example, here are two ways to write the + word: > > > > : + ( a b -- a+b ) > > > which is used like this: > > > 5 7 + . > > > 12 ok > > > > or > > > > : + ( a b -- a b a+b ) > > > which is used like this: > > > 5 7 + . 2drop > > > 12 ok > > > > Pretty obvious which makes for the most readable code, > > > don't you think? > > > No, I think it depends on what is needed the most. > > > What about a word like COUNT ? > > > COUNT ( addr -- addr len ) > > This is the stack picture for COUNT : > > : count ( adr1 -- adr2 len ) > > COUNT does consume adr1 --- and then it gives you back > some other data That's a matter of interpretation. len is definately different. > (adr2 is not the same datum as adr1). False. "adr2 is" _typically_ "not the same datum as adr1", but can be. There is no requirement that adr2 be different from adr1. There is only a requirement that COUNT returns an address to the start of the string. Historically, since counted strings are used in Forth, where the count precedes the string, they are different. But, if no count precedes the string, they'll be the same. Either way (counted string or not), a DUP is still required to obtain the second address from the first for COUNT. So, the issue of needing DUP or DROP is still valid. It's just a matter of which do you want and where do you want to put it. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2012-11-07 20:46 -1000 |
| Subject | Re: Words consuming arguments, was [Re: Is there a better way?] |
| Message-ID | <U5-dnTj6PaeqyAbNnZ2dnUVZ_uidnZ2d@supernews.com> |
| In reply to | #17132 |
On 11/7/12 2:55 PM, Rod Pemberton wrote: ... >>> What about a word like COUNT ? >> >>> COUNT ( addr -- addr len ) >> >> This is the stack picture for COUNT : >> >> : count ( adr1 -- adr2 len ) >> >> COUNT does consume adr1 --- and then it gives you back >> some other data > > That's a matter of interpretation. len is definately different. > >> (adr2 is not the same datum as adr1). > > False. "adr2 is" _typically_ "not the same datum as adr1", but can be. > > There is no requirement that adr2 be different from adr1. There is only a > requirement that COUNT returns an address to the start of the string. > Historically, since counted strings are used in Forth, where the count > precedes the string, they are different. But, if no count precedes the > string, they'll be the same. > > Either way (counted string or not), a DUP is still required to obtain the > second address from the first for COUNT. So, the issue of needing DUP or > DROP is still valid. It's just a matter of which do you want and where do > you want to put it. The generally accepted understanding of stack notation means that: COUNT ( addr -- addr len ) ...*guarantees* that the two addresses are the same, and the len is added. However, : count ( adr1 -- adr2 len ) ...asserts that adr2 *may* be different from adr1, although that is not guaranteed. You are welcome to interpret these things differently in your Forth, but for communicating with other Forth programmers, this is how the stack comments are normally understood. 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]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2012-11-08 10:39 +0000 |
| Subject | Re: Words consuming arguments, was [Re: Is there a better way?] |
| Message-ID | <509b8a9e.437021403@192.168.0.50> |
| In reply to | #17140 |
On Wed, 07 Nov 2012 20:46:14 -1000, "Elizabeth D. Rather" <erather@forth.com> wrote: >The generally accepted understanding of stack notation means that: > > COUNT ( addr -- addr len ) > >...*guarantees* that the two addresses are the same, and the len is >added. However, > > : count ( adr1 -- adr2 len ) > >...asserts that adr2 *may* be different from adr1, although that is not >guaranteed. Cough, cough. In the instance of COUNT, the ANS standard says: ( c-addr1 -- c-addr2 u ) ... c-addr2 is the address of the first character after c-addr1. ... However, your view of stack comments are basically mine. However, the confusion in the discussion shows why comments are needed. Redefining CORE words is rarely a good idea. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-11-12 03:48 -0600 |
| Subject | Re: Words consuming arguments, was [Re: Is there a better way?] |
| Message-ID | <lo6dnQzHTZphWD3NnZ2dnUVZ8qqdnZ2d@supernews.com> |
| In reply to | #17132 |
Rod Pemberton <do_not_have@notemailnotz.cnm> wrote:
> "Hugh Aguilar" <hughaguilar96@yahoo.com> wrote in message
> news:45d4f07b-8d85-43e7-acc9-614966bdae14@uk1g2000pbb.googlegroups.com...
>> On Nov 6, 6:53 pm, "Rod Pemberton" <do_not_h...@notemailnotz.cnm>
>> wrote:
>>
>> > What about a word like COUNT ?
>>
>> > COUNT ( addr -- addr len )
>>
>> This is the stack picture for COUNT :
>>
>> : count ( adr1 -- adr2 len )
>>
>> COUNT does consume adr1 --- and then it gives you back
>> some other data
>
> That's a matter of interpretation. len is definately different.
>
>> (adr2 is not the same datum as adr1).
>
> False. "adr2 is" _typically_ "not the same datum as adr1", but can be.
>
> There is no requirement that adr2 be different from adr1.
Of course there is, because the count is at c-addr1, and c-addr2 is
the start of the string:
6.1.0980 COUNT
CORE
( c-addr1 -- c-addr2 u )
Return the character string specification for the counted string
stored at c-addr1. c-addr2 is the address of the first character after
c-addr1. u is the contents of the character at c-addr1, which is the
length in characters of the string at c-addr2.
> There is only a requirement that COUNT returns an address to the
> start of the string. Historically, since counted strings are used
> in Forth, where the count precedes the string, they are different.
> But, if no count precedes the string, they'll be the same.
The count precedes the string, as COUNT's glossary entry makes clear.
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2012-11-12 07:57 -1000 |
| Subject | Re: Words consuming arguments, was [Re: Is there a better way?] |
| Message-ID | <r6adneRRDaHgpTzNnZ2dnUVZ_s0AAAAA@supernews.com> |
| In reply to | #17233 |
On 11/11/12 11:48 PM, Andrew Haley wrote: > Rod Pemberton <do_not_have@notemailnotz.cnm> wrote: >> "Hugh Aguilar" <hughaguilar96@yahoo.com> wrote in message >> news:45d4f07b-8d85-43e7-acc9-614966bdae14@uk1g2000pbb.googlegroups.com... >>> On Nov 6, 6:53 pm, "Rod Pemberton" <do_not_h...@notemailnotz.cnm> >>> wrote: >>> >>>> What about a word like COUNT ? >>> >>>> COUNT ( addr -- addr len ) >>> >>> This is the stack picture for COUNT : >>> >>> : count ( adr1 -- adr2 len ) >>> >>> COUNT does consume adr1 --- and then it gives you back >>> some other data >> >> That's a matter of interpretation. len is definately different. >> >>> (adr2 is not the same datum as adr1). >> >> False. "adr2 is" _typically_ "not the same datum as adr1", but can be. >> >> There is no requirement that adr2 be different from adr1. > > Of course there is, because the count is at c-addr1, and c-addr2 is > the start of the string: > > 6.1.0980 COUNT > CORE > > ( c-addr1 -- c-addr2 u ) > > Return the character string specification for the counted string > stored at c-addr1. c-addr2 is the address of the first character after > c-addr1. u is the contents of the character at c-addr1, which is the > length in characters of the string at c-addr2. > >> There is only a requirement that COUNT returns an address to the >> start of the string. Historically, since counted strings are used >> in Forth, where the count precedes the string, they are different. >> But, if no count precedes the string, they'll be the same. > > The count precedes the string, as COUNT's glossary entry makes clear. > > Andrew. You are right, I wrote that late at night and in haste. 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]
| From | "Rod Pemberton" <do_not_have@notemailnotz.cnm> |
|---|---|
| Date | 2012-11-12 19:50 -0500 |
| Subject | Re: Words consuming arguments, was [Re: Is there a better way?] |
| Message-ID | <k7s581$lsi$1@speranza.aioe.org> |
| In reply to | #17239 |
"Elizabeth D. Rather" <erather@forth.com> wrote in message news:r6adneRRDaHgpTzNnZ2dnUVZ_s0AAAAA@supernews.com... > On 11/11/12 11:48 PM, Andrew Haley wrote: > > Rod Pemberton <do_not_have@notemailnotz.cnm> wrote: > >> "Hugh Aguilar" <hughaguilar96@yahoo.com> wrote in message > >> news:45d4f07b-8d85-43e7-acc9-614966bdae14@uk1g2000pbb.googlegroups.com... > >>> On Nov 6, 6:53 pm, "Rod Pemberton" <do_not_h...@notemailnotz.cnm> > >>> wrote: > >>> > >>>> What about a word like COUNT ? > >>> > >>>> COUNT ( addr -- addr len ) > >>> > >>> This is the stack picture for COUNT : > >>> > >>> : count ( adr1 -- adr2 len ) > >>> > >>> COUNT does consume adr1 --- and then it gives you back > >>> some other data > >> > >> That's a matter of interpretation. len is definately different. > >> > >>> (adr2 is not the same datum as adr1). > >> > >> False. "adr2 is" _typically_ "not the same datum as adr1", but can be. > >> > >> There is no requirement that adr2 be different from adr1. > > > > Of course there is, because the count is at c-addr1, and c-addr2 is > > the start of the string: > > > > 6.1.0980 COUNT > > CORE > > > > ( c-addr1 -- c-addr2 u ) > > > > Return the character string specification for the counted string > > stored at c-addr1. c-addr2 is the address of the first character after > > c-addr1. u is the contents of the character at c-addr1, which is the > > length in characters of the string at c-addr2. > > > >> There is only a requirement that COUNT returns an address to the > >> start of the string. Historically, since counted strings are used > >> in Forth, where the count precedes the string, they are different. > >> But, if no count precedes the string, they'll be the same. > > > > The count precedes the string, as COUNT's glossary entry makes clear. > > > You are right, I wrote that late at night and in haste. > You wrote what? Nothing in this part of the thread are your comments. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailnotz.cnm> |
|---|---|
| Date | 2012-11-12 19:49 -0500 |
| Subject | Re: Words consuming arguments, was [Re: Is there a better way?] |
| Message-ID | <k7s561$lku$1@speranza.aioe.org> |
| In reply to | #17233 |
"Andrew Haley" <andrew29@littlepinkcloud.invalid> wrote in message
news:lo6dnQzHTZphWD3NnZ2dnUVZ8qqdnZ2d@supernews.com...
> Rod Pemberton <do_not_have@notemailnotz.cnm> wrote:
> > "Hugh Aguilar" <hughaguilar96@yahoo.com> wrote in message
> >
news:45d4f07b-8d85-43e7-acc9-614966bdae14@uk1g2000pbb.googlegroups.com...
> >> On Nov 6, 6:53 pm, "Rod Pemberton" <do_not_h...@notemailnotz.cnm>
> >> wrote:
> >>
> >> > What about a word like COUNT ?
> >>
> >> > COUNT ( addr -- addr len )
> >>
> >> This is the stack picture for COUNT :
> >>
> >> : count ( adr1 -- adr2 len )
> >>
> >> COUNT does consume adr1 --- and then it gives you back
> >> some other data
> >
> > That's a matter of interpretation. len is definately different.
> >
> >> (adr2 is not the same datum as adr1).
> >
> > False. "adr2 is" _typically_ "not the same datum as adr1", but can be.
> >
> > There is no requirement that adr2 be different from adr1.
>
> Of course there is, because the count is at c-addr1, and c-addr2 is
> the start of the string:
>
> 6.1.0980 COUNT
> CORE
>
> ( c-addr1 -- c-addr2 u )
>
> Return the character string specification for the counted string
> stored at c-addr1. c-addr2 is the address of the first character after
> c-addr1. u is the contents of the character at c-addr1, which is the
> length in characters of the string at c-addr2.
>
> > There is only a requirement that COUNT returns an address to the
> > start of the string. Historically, since counted strings are used
> > in Forth, where the count precedes the string, they are different.
> > But, if no count precedes the string, they'll be the same.
>
> The count precedes the string, as COUNT's glossary entry makes clear.
>
Did you just pop in and ignore *EVERYTHING* that was said previously, i.e.,
including the now snipped context? You *keep* responding near the end of a
thread after relevant context for you reply has been snipped. Please, read
the entire thread first.
BTW, this is the original definition of COUNT:
" COUNT addr1 --- addr2 n L0
Leave the byte address addr2 and byte count n of a message
text beginning at addr1. It is presumed that the first
byte at addr1 contains the text byte count and the actual
text starts with the second byte. Typically COUNT is
followed by TYPE."
It's also more accurate. It doesn't assume counted strings.
Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2012-11-12 15:00 -1000 |
| Subject | Re: Words consuming arguments, was [Re: Is there a better way?] |
| Message-ID | <mdqdnYH8wqQ6BjzNnZ2dnUVZ_rWdnZ2d@supernews.com> |
| In reply to | #17241 |
On 11/12/12 2:49 PM, Rod Pemberton wrote: ... > BTW, this is the original definition of COUNT: > > " COUNT addr1 --- addr2 n L0 > Leave the byte address addr2 and byte count n of a message > text beginning at addr1. It is presumed that the first > byte at addr1 contains the text byte count and the actual > text starts with the second byte. Typically COUNT is > followed by TYPE." > > It's also more accurate. It doesn't assume counted strings. I'm not sure what "original" means in this context. COUNT has been around since 1971, which is 7 years before the first, very preliminary, attempt at standards. In any case, the sentence, "It is presumed that the first byte at addr1 contains the text byte count and the actual text starts with the second byte" is an accurate description of a counted string. 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]
| From | Mark Wills <forthfreak@gmail.com> |
|---|---|
| Date | 2012-11-13 00:50 -0800 |
| Subject | Re: Words consuming arguments, was [Re: Is there a better way?] |
| Message-ID | <6a42ffc1-3ac7-4099-905d-e5e89bccd13b@b12g2000vbg.googlegroups.com> |
| In reply to | #17243 |
On Nov 13, 1:00 am, "Elizabeth D. Rather" <erat...@forth.com> wrote:
> On 11/12/12 2:49 PM, Rod Pemberton wrote:
> ...
>
> > BTW, this is the original definition of COUNT:
>
> > " COUNT addr1 --- addr2 n L0
> > Leave the byte address addr2 and byte count n of a message
> > text beginning at addr1. It is presumed that the first
> > byte at addr1 contains the text byte count and the actual
> > text starts with the second byte. Typically COUNT is
> > followed by TYPE."
>
> > It's also more accurate. It doesn't assume counted strings.
>
> I'm not sure what "original" means in this context. COUNT has been
> around since 1971, which is 7 years before the first, very preliminary,
> attempt at standards. In any case, the sentence, "It is presumed that
> the first byte at addr1 contains the text byte count and the actual text
> starts with the second byte" is an accurate description of a counted string.
>
> 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 90045http://www.forth.com
>
> "Forth-based products and Services for real-time
> applications since 1973."
> ==================================================
The definition of COUNT is quite interesting. It actually indirectly,
and presumably un-intentionally mandates the format of a string in
Forth. Here's the ANS definition:
6.1.0980 COUNT
CORE
( c-addr1 -- c-addr2 u )
Return the character string specification for the counted string
stored at c-addr1. c-addr2 is the address of the first character after
c-addr1. u is the contents of the character at c-addr1, which is the
length in characters of the string at c-addr2.
Note the last line: u *is* the contents of the character at c-addr1...
So, there's no way around it in actual fact. If you wanted to
implement strings in a different way under the covers, you'd be
prevented from doing so. It's slightly off topic, but I thought it
interesting.
There is no clue to the format of a string in memory in the ANS
definition of S" :
6.1.2165 S"
s-quote CORE
Interpretation: Interpretation semantics for this word are undefined.
Compilation: ( "ccc<quote>" -- )
Parse ccc delimited by " (double-quote). Append the run-time semantics
given below to the current definition.
Run-time: ( -- c-addr u )
Return c-addr and u describing a string consisting of the characters
ccc. A program shall not alter the returned string.
That's disappointing. If the format of a string is mandatory, then the
appropriate place to describe it (or refer to it) is within the
definition of the word S" not COUNT.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <forthfreak@gmail.com> |
|---|---|
| Date | 2012-11-13 00:58 -0800 |
| Subject | Re: Words consuming arguments, was [Re: Is there a better way?] |
| Message-ID | <e9fcfc47-87e3-4bba-a62a-c53bb67bfc60@k20g2000vbj.googlegroups.com> |
| In reply to | #17245 |
On Nov 13, 8:50 am, Mark Wills <forthfr...@gmail.com> wrote: > On Nov 13, 1:00 am, "Elizabeth D. Rather" <erat...@forth.com> wrote: > > > > > > > On 11/12/12 2:49 PM, Rod Pemberton wrote: > > ... > > > > BTW, this is the original definition of COUNT: > > > > " COUNT addr1 --- addr2 n L0 > > > Leave the byte address addr2 and byte count n of a message > > > text beginning at addr1. It is presumed that the first > > > byte at addr1 contains the text byte count and the actual > > > text starts with the second byte. Typically COUNT is > > > followed by TYPE." > > > > It's also more accurate. It doesn't assume counted strings. > > > I'm not sure what "original" means in this context. COUNT has been > > around since 1971, which is 7 years before the first, very preliminary, > > attempt at standards. In any case, the sentence, "It is presumed that > > the first byte at addr1 contains the text byte count and the actual text > > starts with the second byte" is an accurate description of a counted string. > > > 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 90045http://www.forth.com > > > "Forth-based products and Services for real-time > > applications since 1973." > > ================================================== > > The definition of COUNT is quite interesting. It actually indirectly, > and presumably un-intentionally mandates the format of a string in > Forth. Here's the ANS definition: > > 6.1.0980 COUNT > CORE > > ( c-addr1 -- c-addr2 u ) > > Return the character string specification for the counted string > stored at c-addr1. c-addr2 is the address of the first character after > c-addr1. u is the contents of the character at c-addr1, which is the > length in characters of the string at c-addr2. > > Note the last line: u *is* the contents of the character at c-addr1... > > So, there's no way around it in actual fact. If you wanted to > implement strings in a different way under the covers, you'd be > prevented from doing so. It's slightly off topic, but I thought it > interesting. > > There is no clue to the format of a string in memory in the ANS > definition of S" : > > 6.1.2165 S" > s-quote CORE > > Interpretation: Interpretation semantics for this word are undefined. > > Compilation: ( "ccc<quote>" -- ) > > Parse ccc delimited by " (double-quote). Append the run-time semantics > given below to the current definition. > > Run-time: ( -- c-addr u ) > > Return c-addr and u describing a string consisting of the characters > ccc. A program shall not alter the returned string. > > That's disappointing. If the format of a string is mandatory, then the > appropriate place to describe it (or refer to it) is within the > definition of the word S" not COUNT.- Hide quoted text - > > - Show quoted text - On second thoughts, perhaps it's just me not reading the standard in enough detail. In fairness, the stack picture given in S" does clearly say: c-addr u That is *c-addr* - i.e. the address of a *character*. If I interpret that correctly, then S" *must* return the address of a *character*, not the address of a "thing" (for example, the address of entry into an array of string pointers). So, whilst the format of a Forth string isn't explicitly described in English in the standard in the description of S" it *is* there. It's in the stack sig. The devil is in the details, as they say.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2012-11-12 23:17 -1000 |
| Subject | Re: Words consuming arguments, was [Re: Is there a better way?] |
| Message-ID | <V6Wdnb6h5YekjT_NnZ2dnUVZ_tGdnZ2d@supernews.com> |
| In reply to | #17246 |
On 11/12/12 10:58 PM, Mark Wills wrote: > On Nov 13, 8:50 am, Mark Wills <forthfr...@gmail.com> wrote: >> On Nov 13, 1:00 am, "Elizabeth D. Rather" <erat...@forth.com> wrote: >> >>> On 11/12/12 2:49 PM, Rod Pemberton wrote: >>> ... >> >>>> BTW, this is the original definition of COUNT: >> >>>> " COUNT addr1 --- addr2 n L0 >>>> Leave the byte address addr2 and byte count n of a message >>>> text beginning at addr1. It is presumed that the first >>>> byte at addr1 contains the text byte count and the actual >>>> text starts with the second byte. Typically COUNT is >>>> followed by TYPE." >> >>>> It's also more accurate. It doesn't assume counted strings. >> >>> I'm not sure what "original" means in this context. COUNT has been >>> around since 1971, which is 7 years before the first, very preliminary, >>> attempt at standards. In any case, the sentence, "It is presumed that >>> the first byte at addr1 contains the text byte count and the actual text >>> starts with the second byte" is an accurate description of a counted string. >> >> The definition of COUNT is quite interesting. It actually indirectly, >> and presumably un-intentionally mandates the format of a string in >> Forth. Here's the ANS definition: >> >> 6.1.0980 COUNT >> CORE >> >> ( c-addr1 -- c-addr2 u ) >> >> Return the character string specification for the counted string >> stored at c-addr1. c-addr2 is the address of the first character after >> c-addr1. u is the contents of the character at c-addr1, which is the >> length in characters of the string at c-addr2. >> >> Note the last line: u *is* the contents of the character at c-addr1... >> >> So, there's no way around it in actual fact. If you wanted to >> implement strings in a different way under the covers, you'd be >> prevented from doing so. It's slightly off topic, but I thought it >> interesting. >> >> There is no clue to the format of a string in memory in the ANS >> definition of S" : >> >> 6.1.2165 S" >> s-quote CORE >> >> Interpretation: Interpretation semantics for this word are undefined. >> >> Compilation: ( "ccc<quote>" -- ) >> >> Parse ccc delimited by " (double-quote). Append the run-time semantics >> given below to the current definition. >> >> Run-time: ( -- c-addr u ) >> >> Return c-addr and u describing a string consisting of the characters >> ccc. A program shall not alter the returned string. >> >> That's disappointing. If the format of a string is mandatory, then the >> appropriate place to describe it (or refer to it) is within the >> definition of the word S" not COUNT.- Hide quoted text - >> >> - Show quoted text - > > On second thoughts, perhaps it's just me not reading the standard in > enough detail. In fairness, the stack picture given in S" does clearly > say: > > c-addr u > > That is *c-addr* - i.e. the address of a *character*. If I interpret > that correctly, then S" *must* return the address of a *character*, > not the address of a "thing" (for example, the address of entry into > an array of string pointers). > > So, whilst the format of a Forth string isn't explicitly described in > English in the standard in the description of S" it *is* there. It's > in the stack sig. The devil is in the details, as they say. > A couple of important points: The definition of 6.1.0980 COUNT that you cite explicitly states that it is for a "counted string" which is defined in 2.1 Definitions of Terms: "counted string: A data structure consisting of one character containing a length followed by zero or more contiguous data characters. Normally, counted strings contain text." The definition of S" however makes *no mention* of counted strings, and specifies absolutely nothing about its storage format. The similar word C" *does* return the address of a counted string; that is the difference between them. Counted strings have been around Forth for a long time (since 1970), because they're a very efficient format that's useful for a wide variety of things, and is still widely used internally. But this format is not *mandated* except in specific circumstances such as C" above. 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]
Page 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.forth
csiph-web