Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #60222 > unrolled thread
| Started by | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| First post | 2017-06-03 09:09 +0000 |
| Last post | 2017-06-13 10:52 -0500 |
| Articles | 20 on this page of 125 — 21 participants |
Back to article view | Back to comp.lang.forth
Astronomy and programming languages anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-03 09:09 +0000
Re: Astronomy and programming languages krishna.myneni@ccreweb.org - 2017-06-03 04:38 -0700
Re: Astronomy and programming languages anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-03 13:45 +0000
Re: Astronomy and programming languages krishna.myneni@ccreweb.org - 2017-06-03 08:46 -0700
Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-03 18:49 +0000
Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-03 18:48 +0000
Re: Astronomy and programming languages krishna.myneni@ccreweb.org - 2017-06-03 13:33 -0700
Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-03 22:34 +0000
Re: Astronomy and programming languages Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-04 03:05 -0500
Re: Astronomy and programming languages krishna.myneni@ccreweb.org - 2017-06-03 05:58 -0700
Re: Astronomy and programming languages krishna.myneni@ccreweb.org - 2017-06-03 06:01 -0700
Re: Astronomy and programming languages anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-03 13:37 +0000
Re: Astronomy and programming languages foxaudioresearch@gmail.com - 2017-06-03 07:28 -0700
Re: Astronomy and programming languages anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-10 17:31 +0000
Re: Astronomy and programming languages mhx@iae.nl - 2017-06-03 08:21 -0700
Re: Astronomy and programming languages Julian Fondren <julian.fondren@gmail.com> - 2017-06-03 12:01 -0700
Re: Astronomy and programming languages mhx@iae.nl - 2017-06-03 13:09 -0700
Re: Astronomy and programming languages mhx@iae.nl - 2017-06-03 13:20 -0700
Re: Astronomy and programming languages Brad Eckert <hwfwguy@gmail.com> - 2017-06-03 18:30 -0700
Re: Astronomy and programming languages Brad Eckert <hwfwguy@gmail.com> - 2017-06-03 18:43 -0700
Re: Astronomy and programming languages anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-10 17:52 +0000
Re: Astronomy and programming languages Julian Fondren <julian.fondren@gmail.com> - 2017-06-03 19:15 -0700
Re: Astronomy and programming languages mhx@iae.nl - 2017-06-04 00:19 -0700
Re: Astronomy and programming languages anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-10 17:39 +0000
Re: Astronomy and programming languages NN <november.nihal@gmail.com> - 2017-06-03 06:57 -0700
Re: Astronomy and programming languages anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-03 14:48 +0000
Re: Astronomy and programming languages NN <november.nihal@gmail.com> - 2017-06-03 11:12 -0700
Re: Astronomy and programming languages Mark Wills <markwills1970@gmail.com> - 2017-06-06 06:28 -0700
Re: Astronomy and programming languages minforth@arcor.de - 2017-06-06 06:56 -0700
Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-07 19:40 +0000
Re: Astronomy and programming languages Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-08 05:10 -0500
Re: Astronomy and programming languages Mark Wills <markwills1970@gmail.com> - 2017-06-08 04:28 -0700
Re: Astronomy and programming languages Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-08 07:20 -0500
Re: Astronomy and programming languages Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-09 04:08 -0500
Re: Astronomy and programming languages Mark Wills <markwills1970@gmail.com> - 2017-06-09 02:31 -0700
Re: Astronomy and programming languages Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-06-09 03:54 -0700
Re: Astronomy and programming languages Mark Wills <markwills1970@gmail.com> - 2017-06-09 05:00 -0700
Re: Astronomy and programming languages Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-06-09 04:03 -0700
Re: Astronomy and programming languages Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-09 08:37 -0500
Re: Astronomy and programming languages hughaguilar96@gmail.com - 2017-06-09 09:27 -0700
Re: Astronomy and programming languages Cecil Bayona <cbayona@cbayona.com> - 2017-06-03 13:49 -0500
Re: Astronomy and programming languages Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-04 03:11 -0500
Re: Astronomy and programming languages Paul Rubin <no.email@nospam.invalid> - 2017-06-04 17:20 -0700
Re: Astronomy and programming languages Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-07 03:10 -0500
Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-07 19:41 +0000
Re: Astronomy and programming languages anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-08 11:48 +0000
Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-09 17:25 +0000
Re: Astronomy and programming languages Paul Rubin <no.email@nospam.invalid> - 2017-06-10 00:31 -0700
Re: Astronomy and programming languages Melzzzzz <Melzzzzz@zzzzz.com> - 2017-06-10 08:18 +0000
Re: Astronomy and programming languages Paul Rubin <no.email@nospam.invalid> - 2017-06-16 00:23 -0700
Re: Astronomy and programming languages Melzzzzz <Melzzzzz@zzzzz.com> - 2017-06-16 07:40 +0000
Re: Astronomy and programming languages Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-11 02:21 -0500
Re: Astronomy and programming languages Brad Eckert <hwfwguy@gmail.com> - 2017-06-14 23:36 -0700
Re: Astronomy and programming languages Cecil Bayona <cbayona@cbayona.com> - 2017-06-03 13:53 -0500
Re: Astronomy and programming languages mhx@iae.nl - 2017-06-03 08:04 -0700
Re: Astronomy and programming languages rickman <gnuarm@gmail.com> - 2017-06-03 11:29 -0400
Re: Astronomy and programming languages krishna.myneni@ccreweb.org - 2017-06-03 08:55 -0700
Re: Astronomy and programming languages Brad Eckert <hwfwguy@gmail.com> - 2017-06-03 09:57 -0700
Re: Astronomy and programming languages Paul Rubin <no.email@nospam.invalid> - 2017-06-03 10:35 -0700
Re: Astronomy and programming languages Lars Brinkhoff <lars.spam@nocrew.org> - 2017-06-03 19:44 +0200
Re: Astronomy and programming languages Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-06-03 10:15 -0700
Re: Astronomy and programming languages Mark Wills <markwills1970@gmail.com> - 2017-06-06 06:20 -0700
Re: Astronomy and programming languages Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-06-06 07:13 -0700
Re: Astronomy and programming languages minforth@arcor.de - 2017-06-06 08:21 -0700
Re: Astronomy and programming languages Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-06-06 09:05 -0700
Re: Astronomy and programming languages Paul Rubin <no.email@nospam.invalid> - 2017-06-06 23:49 -0700
Re: Astronomy and programming languages Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-06-07 00:58 -0700
Re: Astronomy and programming languages Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-06-07 16:05 -0400
Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-07 20:26 +0000
Re: Astronomy and programming languages Mark Wills <markwills1970@gmail.com> - 2017-06-07 14:00 -0700
Re: Astronomy and programming languages hughaguilar96@gmail.com - 2017-06-07 15:46 -0700
Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-07 23:06 +0000
Re: Astronomy and programming languages Mark Wills <markwills1970@gmail.com> - 2017-06-08 01:24 -0700
Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-09 17:27 +0000
Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-07 23:08 +0000
Re: Astronomy and programming languages Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-06-07 22:26 -0700
Re: Astronomy and programming languages Mark Wills <markwills1970@gmail.com> - 2017-06-08 01:29 -0700
Re: Astronomy and programming languages Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-06-08 08:28 -0400
Re: Astronomy and programming languages Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-06-08 08:02 -0700
Re: Astronomy and programming languages Mark Wills <markwills1970@gmail.com> - 2017-06-08 01:26 -0700
Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-09 17:30 +0000
Re: Astronomy and programming languages Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-08 05:17 -0500
Re: Astronomy and programming languages Mark Wills <markwills1970@gmail.com> - 2017-06-08 04:37 -0700
Re: Astronomy and programming languages Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-08 07:28 -0500
Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-09 17:33 +0000
Re: Astronomy and programming languages anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-08 11:46 +0000
Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-09 17:35 +0000
Re: Astronomy and programming languages Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-10 02:18 -0500
Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-10 07:54 +0000
Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-10 08:00 +0000
Re: Astronomy and programming languages Melzzzzz <Melzzzzz@zzzzz.com> - 2017-06-10 08:38 +0000
Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-11 17:53 +0000
Re: Astronomy and programming languages Melzzzzz <Melzzzzz@zzzzz.com> - 2017-06-11 18:03 +0000
Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-11 18:17 +0000
Re: Astronomy and programming languages Melzzzzz <Melzzzzz@zzzzz.com> - 2017-06-11 18:23 +0000
Re: Astronomy and programming languages Alex <alex@rivadpm.com> - 2017-06-11 19:21 +0100
Re: Astronomy and programming languages Melzzzzz <Melzzzzz@zzzzz.com> - 2017-06-11 18:24 +0000
Re: Astronomy and programming languages Alex <alex@rivadpm.com> - 2017-06-11 19:28 +0100
Re: Astronomy and programming languages Melzzzzz <Melzzzzz@zzzzz.com> - 2017-06-11 19:04 +0000
Re: Astronomy and programming languages Alex <alex@rivadpm.com> - 2017-06-11 21:13 +0100
Re: Astronomy and programming languages Alex <alex@rivadpm.com> - 2017-06-11 21:22 +0100
Re: Astronomy and programming languages Melzzzzz <Melzzzzz@zzzzz.com> - 2017-06-12 03:11 +0000
Re: Astronomy and programming languages anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-12 07:38 +0000
Re: Astronomy and programming languages Melzzzzz <Melzzzzz@zzzzz.com> - 2017-06-12 08:13 +0000
Re: Astronomy and programming languages Alex <alex@rivadpm.com> - 2017-06-12 11:22 +0100
Re: Astronomy and programming languages Alex <alex@rivadpm.com> - 2017-06-12 11:48 +0100
Re: Astronomy and programming languages anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-12 13:58 +0000
Re: Astronomy and programming languages Melzzzzz <Melzzzzz@zzzzz.com> - 2017-06-13 02:19 +0000
Re: Astronomy and programming languages anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-10 13:16 +0000
Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-11 17:53 +0000
Re: Astronomy and programming languages Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-06-08 08:28 -0400
Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-09 17:38 +0000
Re: Astronomy and programming languages Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-03 12:23 -0500
Re: Astronomy and programming languages Paul Rubin <no.email@nospam.invalid> - 2017-06-03 10:27 -0700
Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-03 18:46 +0000
Re: Astronomy and programming languages Julian Fondren <julian.fondren@gmail.com> - 2017-06-03 12:42 -0700
Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-03 22:24 +0000
Re: Astronomy and programming languages Julian Fondren <julian.fondren@gmail.com> - 2017-06-03 15:34 -0700
Re: Astronomy and programming languages "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-03 22:55 +0000
Re: Astronomy and programming languages Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-06-10 10:27 -0700
A Small Challenge (Re: Astronomy and programming languages) Joel Rees <joel.rees@gmail.com> - 2017-06-12 22:20 -0700
Re: A Small Challenge (Re: Astronomy and programming languages) Paul Rubin <no.email@nospam.invalid> - 2017-06-12 22:52 -0700
Re: A Small Challenge (Re: Astronomy and programming languages) Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-06-13 10:04 -0400
Re: A Small Challenge (Re: Astronomy and programming languages) minforth@arcor.de - 2017-06-13 07:30 -0700
Re: A Small Challenge (Re: Astronomy and programming languages) Cecil Bayona <cbayona@cbayona.com> - 2017-06-13 10:52 -0500
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-06-10 17:52 +0000 |
| Message-ID | <2017Jun10.195251@mips.complang.tuwien.ac.at> |
| In reply to | #60263 |
Brad Eckert <hwfwguy@gmail.com> writes:
>On Saturday, June 3, 2017 at 1:20:06 PM UTC-7, m...@iae.nl wrote:
>>=20
>> There is that, but we also can't reliably specify a pathname=20
>
>There's also the question of who "We" is/are. The established Forth vendors=
> are obligated to not break code.
That was not the issue, neither for pathnames nor for include-relative
file names. In the latter case my proposal
<http://www.forth200x.org/directories.html> tried hard not to tread on
anyone's toes. The reason for the resistance was more along the lines
of "You are not a real programmer; real programmers just change a few
lines in the source code when installing code in a directory and
therefore don't need a standard way to refer to a file in the same
directory as the currently-included file."
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2017-06-03 19:15 -0700 |
| Message-ID | <220d2d77-4111-402c-9ab5-03507286fd34@googlegroups.com> |
| In reply to | #60256 |
On Saturday, June 3, 2017 at 3:20:06 PM UTC-5, m...@iae.nl wrote: > On Saturday, June 3, 2017 at 9:01:10 PM UTC+2, Julian Fondren wrote: > [..] > > > We can't even open a arbitrary text file in a > > > standard way. > > > > On POSIX if OPEN-FILE is a thin wrapper over open() or fopen(), then > > you're at the standard met by most other languages. Do you mean that > > there isn't a 'search order' for files, that OPEN-FILE doesn't look > > for a file several locations before giving up? > > There is that, but we also can't reliably specify a pathname (which > characters, which slashes or other separators (:, ~), relative or > absolute, case-sensitive or not ...). > An included file does not know how to get its support files, even > if they are in the same directory. > > File names and paths, plus the FFI, and we would be all set to go. > > -marcel Common Lisp has really advanced pathname support like this, and it's completely useless there. It is a thing you learn only in order to get it out of your way. No other language that comes to mind has much more than Forth does. Ultimately any serious application written is going to be written for a particular environment, "cPanel on CentOS6 on x86_64 with Linux of at least >3.0", and your OS paths come from convention, configuration, or calling context. A library wordset would be nice, but 'nice' is as much weight as I'd put on it. A library wordset is also something, like a common FFI, that you can brute force: any individual Forth programmer, without help from a vendor, can start making it work by tying together what's available and building on it. Even if the result is ".. before anything works you need to recompile your Forth kernel or insert this block of code into include/forth.prf or--", that's how everything works in the beginning. Take a look at perlbrew or npm or rvm. theforth.net is pretty close. Small hanging fruit would be: - (a password reset mechanism) - some user configuration, so that you can tell the 'f' script what Forths you have and where you want their stuff installed. - some package configuration, so that 'f' can know what files are for what Forth. And then you no longer need "Forth" to have Common Lisp-tier filesystem support. You just package stuff up for theforth.net and in your packaged code use phrases like s" bob.wav" THEFORTH-ASSET to get a path to wherever that was installed.
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2017-06-04 00:19 -0700 |
| Message-ID | <fd6772f9-265f-472a-956f-c15fca8b85f4@googlegroups.com> |
| In reply to | #60265 |
On Sunday, June 4, 2017 at 4:15:57 AM UTC+2, Julian Fondren wrote: > On Saturday, June 3, 2017 at 3:20:06 PM UTC-5, m...@iae.nl wrote: > > On Saturday, June 3, 2017 at 9:01:10 PM UTC+2, Julian Fondren wrote: > > [..] > > > > We can't even open a arbitrary text file in a > > > > standard way. [..] > Common Lisp has really advanced pathname support like this, and it's > completely useless there. It is a thing you learn only in order to get > it out of your way. No other language that comes to mind has much more > than Forth does. Ultimately any serious application written is going > to be written for a particular environment, "cPanel on CentOS6 on > x86_64 with Linux of at least >3.0", and your OS paths come from > convention, configuration, or calling context. You may be right, it was too much fun for me to rant a bit. What I see in Python is that it accesses files on the host with host conventions (even using "\\dir\\name" where "/dir/name" is supported), and nobody squawks about it. Before loading a library all kind of magic configurations have to be performed, but they seem to be all (or can be) in the load file. To me the way SF, VFX and iForth do this is already far simpler than that. One important difference is that Pythonists are very phlegm-atic about Python variations: they have only one "vendor" and code for one language version doesn't work on the other ones anyway. They are so focused on the immediate results that they don't care :-) Maybe we should just steal a big Python app (one that relies mainly on libraries), rewrite it in (a) Forth, and then make it parallel or something ... -marcel
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-06-10 17:39 +0000 |
| Message-ID | <2017Jun10.193927@mips.complang.tuwien.ac.at> |
| In reply to | #60256 |
mhx@iae.nl writes:
>There is that, but we also can't reliably specify a pathname (which
>characters, which slashes or other separators (:, ~), relative or
>absolute, case-sensitive or not ...).
There is <http://www.forth200x.org/directories1.html> (withdrawn due
to lack of support), which is based on POSIX 2004: filename characters
are letters, digits, and . _ -. The directory separator is "/". Case
must match, but no file names that differ only in case must occur in
the same directory. Etc.
That works pretty universally on all platforms that want to be
relavant. My guess is that the lack of support for this proposal came
from it being so mundane.
>An included file does not know how to get its support files, even
>if they are in the same directory.
That's <http://www.forth200x.org/directories.html> (withdrawn due to
vigorous resistance; there is a new team that has taken up this task,
and I wish them good luck).
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | NN <november.nihal@gmail.com> |
|---|---|
| Date | 2017-06-03 06:57 -0700 |
| Message-ID | <0d8d485a-0917-4211-815c-043bb970db4a@googlegroups.com> |
| In reply to | #60222 |
[...] > The interesting thing for Forthers context is that Forth used to be > very strong in astronomy. There is a section in the article titled > "Why Python?" Some of the reasons mentioned there are an antithesis > to the positions many present as Forth philosophy: It is used > because: > - anton > -- [...] > M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html > comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html > New standard: http://www.forth200x.org/forth200x.html > EuroForth 2017: http://www.euroforth.org/ef17/ Can you elaborate on what you meant when you refer to positions many present as forth philosopy ? What are these positions and who is presenting these ?
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-06-03 14:48 +0000 |
| Message-ID | <2017Jun3.164811@mips.complang.tuwien.ac.at> |
| In reply to | #60229 |
NN <november.nihal@gmail.com> writes:
>Can you elaborate on what you meant when you refer to positions many present as forth philosopy ? What are these positions and who is presenting these ?
Apparently the positions are not clear enough from the way I
contrasted them with the reasons for using Python, so I'll make them
more explicit here:
1) C and other languages are evil or at least there is nothing of
value there, so we don't need to interface with them (except for
dealing with the OS). We certainly don't need to interface with C
or Fortran libraries, see also 3). (There is even a meme here that
rejects a feature with the (usually incorrect) argument that it
would make Forth more like C; e.g., some argued against number
prefixes such as $10 and #10 with that argument, even though $10
and #10 are not part of C).
2) We must minimize everything at all costs. Consuming a KB or an MB
for a convenience feature is against the Forth philosophy; whether
we have GBs of RAM to spare does not matter.
3) Libraries are "full of inefficient code to take care of
all possible cases, etc."
4) There is no need to standardize a feature if you can already do it
on some systems using carnal knowledge. The value of the standard
is in programmer portability. Loading programs unchanged is not
relevant to real programmers, and requiring to change some lines of
code in various places is the proper way to deal with moving code
between directories or computers.
As for who, I'll not put names here to protect the guilty. Also,
these positions are often held by multiple people, so picking out
one would not be fair.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | NN <november.nihal@gmail.com> |
|---|---|
| Date | 2017-06-03 11:12 -0700 |
| Message-ID | <776e148c-eb85-489b-82fb-96a35ce5e1d5@googlegroups.com> |
| In reply to | #60234 |
On Saturday, 3 June 2017 16:12:03 UTC+1, Anton Ertl wrote: > NN writes: > >Can you elaborate on what you meant when you refer to positions many present as forth philosopy ? What are these positions and who is presenting these ? > > Apparently the positions are not clear enough from the way I > contrasted them with the reasons for using Python, so I'll make them > more explicit here: > > 1) C and other languages are evil or at least there is nothing of > value there, so we don't need to interface with them (except for > dealing with the OS). We certainly don't need to interface with C > or Fortran libraries, see also 3). (There is even a meme here that > rejects a feature with the (usually incorrect) argument that it > would make Forth more like C; e.g., some argued against number > prefixes such as $10 and #10 with that argument, even though $10 > and #10 are not part of C). > > 2) We must minimize everything at all costs. Consuming a KB or an MB > for a convenience feature is against the Forth philosophy; whether > we have GBs of RAM to spare does not matter. > > 3) Libraries are "full of inefficient code to take care of > all possible cases, etc." > > 4) There is no need to standardize a feature if you can already do it > on some systems using carnal knowledge. The value of the standard > is in programmer portability. Loading programs unchanged is not > relevant to real programmers, and requiring to change some lines of > code in various places is the proper way to deal with moving code > between directories or computers. > > As for who, I'll not put names here to protect the guilty. Also, > these positions are often held by multiple people, so picking out > one would not be fair. > > - anton > -- > M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html > comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html > New standard: http://www.forth200x.org/forth200x.html > EuroForth 2017: http://www.euroforth.org/ef17/ If people choose to believe in assumptions that are wrong, its sad, and I doubt there is anything I could write that will change their stance. Going back to your original post. I dont think forth's demise is due to lack of marketing or libraries or inefficiency. I would suggest that the simplest explanation might be that forth is hard/difficult/...
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2017-06-06 06:28 -0700 |
| Message-ID | <53be8600-e061-415c-a708-fc87fd36f78e@googlegroups.com> |
| In reply to | #60245 |
On Saturday, 3 June 2017 19:12:13 UTC+1, NN wrote: > On Saturday, 3 June 2017 16:12:03 UTC+1, Anton Ertl wrote: > > NN writes: > > >Can you elaborate on what you meant when you refer to positions many present as forth philosopy ? What are these positions and who is presenting these ? > > > > Apparently the positions are not clear enough from the way I > > contrasted them with the reasons for using Python, so I'll make them > > more explicit here: > > > > 1) C and other languages are evil or at least there is nothing of > > value there, so we don't need to interface with them (except for > > dealing with the OS). We certainly don't need to interface with C > > or Fortran libraries, see also 3). (There is even a meme here that > > rejects a feature with the (usually incorrect) argument that it > > would make Forth more like C; e.g., some argued against number > > prefixes such as $10 and #10 with that argument, even though $10 > > and #10 are not part of C). > > > > 2) We must minimize everything at all costs. Consuming a KB or an MB > > for a convenience feature is against the Forth philosophy; whether > > we have GBs of RAM to spare does not matter. > > > > 3) Libraries are "full of inefficient code to take care of > > all possible cases, etc." > > > > 4) There is no need to standardize a feature if you can already do it > > on some systems using carnal knowledge. The value of the standard > > is in programmer portability. Loading programs unchanged is not > > relevant to real programmers, and requiring to change some lines of > > code in various places is the proper way to deal with moving code > > between directories or computers. > > > > As for who, I'll not put names here to protect the guilty. Also, > > these positions are often held by multiple people, so picking out > > one would not be fair. > > > > - anton > > -- > > M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html > > comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html > > New standard: http://www.forth200x.org/forth200x.html > > EuroForth 2017: http://www.euroforth.org/ef17/ > > > If people choose to believe in assumptions that are wrong, its sad, and I doubt there is anything I could write that will change their stance. > > Going back to your original post. I dont think forth's demise is due to lack of marketing or libraries or inefficiency. I would suggest that the simplest explanation might be that forth is hard/difficult/... The Forth *language* itself is terribly simple, and beautiful in some respects. What makes Forth "hard" is that in Forth *you* are responsible for *data* flow (making sure the stack is the way you want it at the right time) in *addition* to *program* flow. In other languages, you're only concerned about program flow. You can access any data item in any order you want. That's what makes Forth hard. The stack management words. It leads to the dreaded "write-only" highly ugly source code and it puts people off. That said, some are better at it than others have a real knack for it. I still struggle with it, but I'm getting better at it and enjoy the challenge of it.
[toc] | [prev] | [next] | [standalone]
| From | minforth@arcor.de |
|---|---|
| Date | 2017-06-06 06:56 -0700 |
| Message-ID | <72392537-130d-4cfd-9bde-6ddcdfbb0bf6@googlegroups.com> |
| In reply to | #60388 |
Am Dienstag, 6. Juni 2017 15:28:31 UTC+2 schrieb Mark Wills: > On Saturday, 3 June 2017 19:12:13 UTC+1, NN wrote: > > On Saturday, 3 June 2017 16:12:03 UTC+1, Anton Ertl wrote: > > > NN writes: > > > >Can you elaborate on what you meant when you refer to positions many present as forth philosopy ? What are these positions and who is presenting these ? > > > > > > Apparently the positions are not clear enough from the way I > > > contrasted them with the reasons for using Python, so I'll make them > > > more explicit here: > > > > > > 1) C and other languages are evil or at least there is nothing of > > > value there, so we don't need to interface with them (except for > > > dealing with the OS). We certainly don't need to interface with C > > > or Fortran libraries, see also 3). (There is even a meme here that > > > rejects a feature with the (usually incorrect) argument that it > > > would make Forth more like C; e.g., some argued against number > > > prefixes such as $10 and #10 with that argument, even though $10 > > > and #10 are not part of C). > > > > > > 2) We must minimize everything at all costs. Consuming a KB or an MB > > > for a convenience feature is against the Forth philosophy; whether > > > we have GBs of RAM to spare does not matter. > > > > > > 3) Libraries are "full of inefficient code to take care of > > > all possible cases, etc." > > > > > > 4) There is no need to standardize a feature if you can already do it > > > on some systems using carnal knowledge. The value of the standard > > > is in programmer portability. Loading programs unchanged is not > > > relevant to real programmers, and requiring to change some lines of > > > code in various places is the proper way to deal with moving code > > > between directories or computers. > > > > > > As for who, I'll not put names here to protect the guilty. Also, > > > these positions are often held by multiple people, so picking out > > > one would not be fair. > > > > > > - anton > > > -- > > > M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html > > > comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html > > > New standard: http://www.forth200x.org/forth200x.html > > > EuroForth 2017: http://www.euroforth.org/ef17/ > > > > > > If people choose to believe in assumptions that are wrong, its sad, and I doubt there is anything I could write that will change their stance. > > > > Going back to your original post. I dont think forth's demise is due to lack of marketing or libraries or inefficiency. I would suggest that the simplest explanation might be that forth is hard/difficult/... > > The Forth *language* itself is terribly simple, and beautiful in some > respects. What makes Forth "hard" is that in Forth *you* are responsible > for *data* flow (making sure the stack is the way you want it at the right > time) in *addition* to *program* flow. In other languages, you're only > concerned about program flow. You can access any data item in any order > you want. > > That's what makes Forth hard. The stack management words. It leads to the > dreaded "write-only" highly ugly source code and it puts people off. > > That said, some are better at it than others have a real knack for it. > I still struggle with it, but I'm getting better at it and enjoy the > challenge of it. With Forth you can have more than one return values. In C you have only one. Forth syntax with locals looks barely different from "normal" functions in other languages. Write Forth functions with one return value and use Forth xt's as function pointer replacement, and you have a C-ish Forth. But you won't feel any better and your code gets longer.. ;-)
[toc] | [prev] | [next] | [standalone]
| From | "Rudy Velthuis" <newsgroups@rvelthuis.de> |
|---|---|
| Date | 2017-06-07 19:40 +0000 |
| Message-ID | <xn0kqyfioaxc1xt00c@nntp.aioe.org> |
| In reply to | #60388 |
Mark Wills wrote: > The Forth language itself is terribly simple, and beautiful in some > respects. What makes Forth "hard" is that in Forth you are responsible > for data flow (making sure the stack is the way you want it at the > right time) in addition to program flow. Fully agreed, to all of the above. Add to that that, unless you implement locals, you don't have any random access to the data passed in. -- Rudy Velthuis http://www.rvelthuis.de "Radioactive cats have 18 half-lives."
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-06-08 05:10 -0500 |
| Message-ID | <pfydnQ8Sn-A7v6TEnZ2dnUU7-KXNnZ2d@supernews.com> |
| In reply to | #60388 |
Mark Wills <markwills1970@gmail.com> wrote:
>
> The Forth *language* itself is terribly simple, and beautiful in
> some respects. What makes Forth "hard" is that in Forth *you* are
> responsible for *data* flow (making sure the stack is the way you
> want it at the right time) in *addition* to *program* flow. In other
> languages, you're only concerned about program flow. You can access
> any data item in any order you want.
>
> That's what makes Forth hard. The stack management words. It leads
> to the dreaded "write-only" highly ugly source code and it puts
> people off.
I disagree somewhat. Really good Forth code isn't hard to read
"because of stack management": it flows from left to right like a
pipeline. And the fact that you're not having to mention variable
names all the time can be nice. This is related to point-free style
in functional programming languages, where, for example, you can
define a function which doubles a number in different ways:
double x = 2*x
or
double = (2*)
Writing good Forth code can be tricky, but reading it shouldn't be.
IMO, if you end up with more than four things on the stack and need to
grope down there to get one of them, it's time to refactor: introduce
a struct, use a variable, or even a local. But I admit that mine is
probably a minority opinion: I always was rather more allergic to
stack juggling than many Forthers.
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2017-06-08 04:28 -0700 |
| Message-ID | <919ff31b-d498-436c-ac88-5625559bc2d6@googlegroups.com> |
| In reply to | #60459 |
On Thursday, 8 June 2017 11:10:52 UTC+1, Andrew Haley wrote: > Mark Wills <markwills1970@gmail.com> wrote: > > > > The Forth *language* itself is terribly simple, and beautiful in > > some respects. What makes Forth "hard" is that in Forth *you* are > > responsible for *data* flow (making sure the stack is the way you > > want it at the right time) in *addition* to *program* flow. In other > > languages, you're only concerned about program flow. You can access > > any data item in any order you want. > > > > That's what makes Forth hard. The stack management words. It leads > > to the dreaded "write-only" highly ugly source code and it puts > > people off. > > I disagree somewhat. Really good Forth code isn't hard to read > "because of stack management": it flows from left to right like a > pipeline. And the fact that you're not having to mention variable > names all the time can be nice. This is related to point-free style > in functional programming languages, where, for example, you can > define a function which doubles a number in different ways: > > double x = 2*x > > or > double = (2*) > > Writing good Forth code can be tricky, but reading it shouldn't be. > IMO, if you end up with more than four things on the stack and need to > grope down there to get one of them, it's time to refactor: introduce > a struct, use a variable, or even a local. But I admit that mine is > probably a minority opinion: I always was rather more allergic to > stack juggling than many Forthers. > > Andrew. Indeed. It's just something that takes time. Writing good Forth is a... Craft. That's the best word I can conjure right now. I remember corresponding privately with Jeff Fox about some code I was writing, and I sent him the code. He sent me back a "why don't you do it like this" email, and the code he sent me caused me to face-palm hard. His code "smelled" of experience. You could feel it. And it did flow nicely, and there was less of it. It was an important moment. I'm at the stage where (I think) my high-level Forth code is quite good, but as you go lower, it can get ugly. Of course, in any Forth application, the "real work" happens at the lower layers, so that's inevitable to a certain degree. I think you're right that reaching for a variable or a local now and again is a much better solution than "forcing" your code to not use them. I find that I *can* solve problems without resorting to variables or locals, but the code is always uglier and harder to read, and may actually be slower to execute (at least on non-optimising/simple optimiser) systems due to the stack traffic. I need to get over the in-built snobbery that I have against "giving in" and using locals or variables more. Snobbery leads to read-only code.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-06-08 07:20 -0500 |
| Message-ID | <L9SdnbPCuey13KTEnZ2dnUU7-UGdnZ2d@supernews.com> |
| In reply to | #60461 |
Mark Wills <markwills1970@gmail.com> wrote: > I need to get over the in-built snobbery that I have against "giving > in" and using locals or variables more. Snobbery leads to read-only > code. Indeed, and don't forget that structs are tremendously useful too: if you pass a pointer to a struct instead of a bunch of items on the stack you have named access to everything. It's not unlikely that those items go together naturally, and might even be stored together in memory. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-06-09 04:08 -0500 |
| Message-ID | <uZGdnUfh8PMZ-KfEnZ2dnUU7-WfNnZ2d@supernews.com> |
| In reply to | #60461 |
Mark Wills <markwills1970@gmail.com> wrote: > I need to get over the in-built snobbery that I have against "giving in" > and using locals or variables more. Snobbery leads to read-only code. But refactoring should be the first thing to reach for. Sometimes you come across something this is so "just right" that it must be the right answer. I was thinking about a nice way to represent Pythagoras' theorem using purely integer arithmetic , and kicked around a few ideas, but it's always going to be tricky because of the need to keep everything in range without overflow. N squared is twice as long as N, so there are a lot of things on the stack. Then I came up with this: \ Add the square of n to d : +square ( n d - d) rot square d+ ; \ Pythagoras' theorem in two dimensions : hypotenuse ( n1 n2 - n) square +square sqrt ; Which generalizes trivially to three: : hypotenuse ( n1 n2 n3 - n) square +square +square sqrt ; And, fairly simply, to vectors in Euclidean n-space. Not everything falls nicely like this, of course, but as you mentioned (of Jeff Fox's solution to your problem) it's something to reach for. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2017-06-09 02:31 -0700 |
| Message-ID | <3578945f-258e-428c-a21b-013cd0f2deeb@googlegroups.com> |
| In reply to | #60480 |
On Friday, 9 June 2017 10:08:25 UTC+1, Andrew Haley wrote: > Mark Wills <markwills1970@gmail.com> wrote: > > I need to get over the in-built snobbery that I have against "giving in" > > and using locals or variables more. Snobbery leads to read-only code. > > But refactoring should be the first thing to reach for. > > Sometimes you come across something this is so "just right" that it > must be the right answer. I was thinking about a nice way to > represent Pythagoras' theorem using purely integer arithmetic , and > kicked around a few ideas, but it's always going to be tricky because > of the need to keep everything in range without overflow. N squared > is twice as long as N, so there are a lot of things on the stack. > Then I came up with this: > > \ Add the square of n to d > : +square ( n d - d) rot square d+ ; > > \ Pythagoras' theorem in two dimensions > : hypotenuse ( n1 n2 - n) square +square sqrt ; > > Which generalizes trivially to three: > : hypotenuse ( n1 n2 n3 - n) square +square +square sqrt ; > > And, fairly simply, to vectors in Euclidean n-space. Not everything > falls nicely like this, of course, but as you mentioned (of Jeff Fox's > solution to your problem) it's something to reach for. > > Andrew. Yes, that's very nice indeed. However, is there an error in the stack sig for +square? You're using ROT which implies three inputs on the stack, but the stack sig only refers to two :-)
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2017-06-09 03:54 -0700 |
| Message-ID | <ca794cbf-bb60-470a-a7d1-f273f08b429c@googlegroups.com> |
| In reply to | #60482 |
vineri, 9 iunie 2017, 12:31:59 UTC+3, Mark Wills a scris: > On Friday, 9 June 2017 10:08:25 UTC+1, Andrew Haley wrote: > > Mark Wills <markwills1970@gmail.com> wrote: > > > I need to get over the in-built snobbery that I have against "giving in" > > > and using locals or variables more. Snobbery leads to read-only code. > > > > But refactoring should be the first thing to reach for. > > > > Sometimes you come across something this is so "just right" that it > > must be the right answer. I was thinking about a nice way to > > represent Pythagoras' theorem using purely integer arithmetic , and > > kicked around a few ideas, but it's always going to be tricky because > > of the need to keep everything in range without overflow. N squared > > is twice as long as N, so there are a lot of things on the stack. > > Then I came up with this: > > > > \ Add the square of n to d > > : +square ( n d - d) rot square d+ ; > > > > \ Pythagoras' theorem in two dimensions > > : hypotenuse ( n1 n2 - n) square +square sqrt ; > > > > Which generalizes trivially to three: > > : hypotenuse ( n1 n2 n3 - n) square +square +square sqrt ; > > > > And, fairly simply, to vectors in Euclidean n-space. Not everything > > falls nicely like this, of course, but as you mentioned (of Jeff Fox's > > solution to your problem) it's something to reach for. > > > > Andrew. > > Yes, that's very nice indeed. However, is there an error in the stack > sig for +square? You're using ROT which implies three inputs on the stack, > but the stack sig only refers to two :-) You aren't right, 'd' is usually a double item. I'm against this usage because it can be confusing, but I can 'read' such a stack comment w/o problem.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2017-06-09 05:00 -0700 |
| Message-ID | <000c94ea-24bb-4146-a8d7-4f167269ee8f@googlegroups.com> |
| In reply to | #60489 |
On Friday, 9 June 2017 11:54:26 UTC+1, Raimond Dragomir wrote: > vineri, 9 iunie 2017, 12:31:59 UTC+3, Mark Wills a scris: > > On Friday, 9 June 2017 10:08:25 UTC+1, Andrew Haley wrote: > > > Mark Wills <markwills1970@gmail.com> wrote: > > > > I need to get over the in-built snobbery that I have against "giving in" > > > > and using locals or variables more. Snobbery leads to read-only code. > > > > > > But refactoring should be the first thing to reach for. > > > > > > Sometimes you come across something this is so "just right" that it > > > must be the right answer. I was thinking about a nice way to > > > represent Pythagoras' theorem using purely integer arithmetic , and > > > kicked around a few ideas, but it's always going to be tricky because > > > of the need to keep everything in range without overflow. N squared > > > is twice as long as N, so there are a lot of things on the stack. > > > Then I came up with this: > > > > > > \ Add the square of n to d > > > : +square ( n d - d) rot square d+ ; > > > > > > \ Pythagoras' theorem in two dimensions > > > : hypotenuse ( n1 n2 - n) square +square sqrt ; > > > > > > Which generalizes trivially to three: > > > : hypotenuse ( n1 n2 n3 - n) square +square +square sqrt ; > > > > > > And, fairly simply, to vectors in Euclidean n-space. Not everything > > > falls nicely like this, of course, but as you mentioned (of Jeff Fox's > > > solution to your problem) it's something to reach for. > > > > > > Andrew. > > > > Yes, that's very nice indeed. However, is there an error in the stack > > sig for +square? You're using ROT which implies three inputs on the stack, > > but the stack sig only refers to two :-) > > You aren't right, 'd' is usually a double item. I'm against this > usage because it can be confusing, but I can 'read' such a stack > comment w/o problem. Ah yes of course. Well spotted.
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2017-06-09 04:03 -0700 |
| Message-ID | <0265f36c-a2ca-4584-bcde-7bbc5f90599a@googlegroups.com> |
| In reply to | #60480 |
vineri, 9 iunie 2017, 12:08:25 UTC+3, Andrew Haley a scris: > Mark Wills <markwills1970@gmail.com> wrote: > > I need to get over the in-built snobbery that I have against "giving in" > > and using locals or variables more. Snobbery leads to read-only code. > > But refactoring should be the first thing to reach for. > I'm a bit reserved. Sometimes a factor is obvious and easy. Sometimes it's just a desperate mean to keep things under control. And there is a problem of naming too. You hardly get a good name for a factor, not to say that some people seem to use all kind of @#$%^&[] for these factors because probably they mean something to them but usually don't mean something (or anything or the same thing) to the reader. The naming is not a forth problem, is a problem in general. In forth it is only more visible because this is the forth paradigm of many short definitions. And using all kind of symbols because "you can" doesn't help much.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-06-09 08:37 -0500 |
| Message-ID | <zNedna5Kc78ROafEnZ2dnUU7-cmdnZ2d@supernews.com> |
| In reply to | #60490 |
Raimond Dragomir <raimond.dragomir@gmail.com> wrote: > vineri, 9 iunie 2017, 12:08:25 UTC+3, Andrew Haley a scris: >> Mark Wills <markwills1970@gmail.com> wrote: >> > I need to get over the in-built snobbery that I have against "giving in" >> > and using locals or variables more. Snobbery leads to read-only code. >> >> But refactoring should be the first thing to reach for. > > I'm a bit reserved. Sometimes a factor is obvious and > easy. Sometimes it's just a desperate mean to keep things under > control. But ... that's a bad thing? > And there is a problem of naming too. You hardly get a good name for > a factor, not to say that some people seem to use all kind of > @#$%^&[] for these factors because probably they mean something to > them but usually don't mean something (or anything or the same > thing) to the reader. It depends on the reader. I'm not sure I agree that naming is such a big pain, expecially if you don't insist on all names of factors being globally unique. Of course, a reader has to understand the naming conventions being used, and it's these naming conventions, used with good taste, which help readability no end. IMO. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-06-09 09:27 -0700 |
| Message-ID | <beec601b-1f01-4e22-8825-4124ee45221a@googlegroups.com> |
| In reply to | #60490 |
On Friday, June 9, 2017 at 4:03:11 AM UTC-7, Raimond Dragomir wrote: > vineri, 9 iunie 2017, 12:08:25 UTC+3, Andrew Haley a scris: > > Mark Wills <markwills1970@gmail.com> wrote: > > > I need to get over the in-built snobbery that I have against "giving in" > > > and using locals or variables more. Snobbery leads to read-only code. > > > > But refactoring should be the first thing to reach for. > > > I'm a bit reserved. Sometimes a factor is obvious and easy. Sometimes > it's just a desperate mean to keep things under control. And there is a > problem of naming too. You hardly get a good name for a factor, not to > say that some people seem to use all kind of @#$%^&[] for these > factors because probably they mean something to them but usually > don't mean something (or anything or the same thing) to the reader. > > The naming is not a forth problem, is a problem in general. In forth > it is only more visible because this is the forth paradigm of many > short definitions. And using all kind of symbols because "you can" > doesn't help much. In MFX I had these words: LOCAL \ used after a definition to mark the word as smudge-ready END-MODULE \ used at the end of a file to smudge all of the smudge-ready words This helps the code to be self-documenting. When somebody reads the source-code, then can ignore the LOCAL words and focus on learning the words that will be exposed to the user (the API). Also, there is no clash for the LOCAL words if the same name is used later in the program (this happens a lot with common names such as PTR or CNT etc.). Doing this involves carnal knowledge --- I found an unused bit in the header flag byte that I used to mean smudge-ready. END-MODULE would traverse the entire dictionary and, if it found a word the smudge-ready flag set, it would clear the smudge-ready flag and set the smudge flag. Because this involves carnal knowledge it has to be part of the standard --- it will be part of Straight Forth --- Forth-200x won't allow it, of course (because I thought of the idea). IIRC, C uses STATIC for the words that won't be exported from the file, and Pascal uses EXPORT for the words that will be exported from the file.
[toc] | [prev] | [next] | [standalone]
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.forth
csiph-web