Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #58497 > unrolled thread
| Started by | Alex <alex@rivadpm.com> |
|---|---|
| First post | 2017-05-02 15:27 +0100 |
| Last post | 2017-05-04 10:07 -0700 |
| Articles | 20 on this page of 177 — 26 participants |
Back to article view | Back to comp.lang.forth
Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 15:27 +0100
Recognizers discussion lehs <skydda.barnen@gmail.com> - 2017-05-02 07:52 -0700
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-02 08:19 -0700
Re: Recognizers discussion lehs <skydda.barnen@gmail.com> - 2017-05-02 08:27 -0700
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 19:55 +0100
Re: Recognizers discussion lehs <skydda.barnen@gmail.com> - 2017-05-03 02:38 -0700
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 15:16 +0000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 17:05 +0100
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 17:23 +0100
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 17:26 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-02 13:03 -0500
Re: Recognizers discussion Matthias Trute <matthias.trute@gmail.com> - 2017-05-02 12:44 -0700
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 04:36 -0500
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 13:28 +0000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 09:13 -0500
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-02 12:35 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 18:53 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-02 13:10 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 19:22 +0100
Re: Recognizers discussion Bernd Paysan <bernd@net2o.de> - 2017-05-02 22:53 +0000
Re: Recognizers discussion Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-05-03 07:39 +0100
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-03 10:58 +0100
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 13:53 +0000
Re: Recognizers discussion Bernd Paysan <bernd@net2o.de> - 2017-05-06 01:21 +0000
Re: Recognizers discussion pahihu <pahihu@gmail.com> - 2017-05-06 00:22 -0700
Re: Recognizers discussion Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-05-06 23:05 +0100
Re: Recognizers discussion pahihu <pahihu@gmail.com> - 2017-05-06 22:36 -0700
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 04:38 -0500
Re: Recognizers discussion minforth@arcor.de - 2017-05-03 04:49 -0700
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 05:03 -0700
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 09:02 -0500
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 07:45 -0700
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 11:24 -0500
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 09:45 -0700
Re: Recognizers discussion Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-03 10:08 -0700
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-09 15:56 +0000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-03 18:37 +0100
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 11:07 -0700
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-03 20:55 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 02:47 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 13:07 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 07:59 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 17:38 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 12:42 -0500
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 02:43 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 13:05 +0100
Re: Recognizers discussion Ron Aaron <rambamist@gmail.com> - 2017-05-04 15:10 +0300
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 13:25 +0100
Re: Recognizers discussion Ron Aaron <rambamist@gmail.com> - 2017-05-04 15:33 +0300
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 08:05 -0500
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-09 15:54 +0000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-09 11:10 -0500
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-10 11:49 +0000
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 16:14 +0000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 13:02 -0500
Re: Recognizers discussion Bernd Paysan <bernd@net2o.de> - 2017-05-05 23:29 +0000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-07 03:56 -0500
Re: Recognizers discussion Bernd Paysan <bernd@net2o.de> - 2017-05-07 22:42 +0000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-08 04:08 -0500
Re: Recognizers discussion Julian Fondren <julian.fondren@gmail.com> - 2017-05-03 08:51 -0700
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 09:38 -0700
Re: Recognizers discussion Julian Fondren <julian.fondren@gmail.com> - 2017-05-03 09:59 -0700
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 10:16 -0700
Re: Recognizers discussion albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-03 22:04 +0200
Re: Recognizers discussion minforth@arcor.de - 2017-05-03 22:09 -0700
Re: Recognizers discussion Joel Rees <joel.rees@gmail.com> - 2017-05-07 19:50 -0700
Re: Recognizers discussion "Elizabeth D. Rather" <erather@forth.com> - 2017-05-07 21:33 -1000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-08 04:12 -0500
Re: Recognizers discussion Joel Rees <joel.rees@gmail.com> - 2017-05-08 20:21 -0700
FP stack (was: Recognizers discussion) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-08 12:35 +0000
Re: FP stack (was: Recognizers discussion) Joel Rees <joel.rees@gmail.com> - 2017-05-08 20:50 -0700
Re: FP stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-09 03:39 -0500
Re: FP stack Joel Rees <joel.rees@gmail.com> - 2017-05-09 20:59 -0700
Re: FP stack Julian Fondren <julian.fondren@gmail.com> - 2017-05-10 00:03 -0700
Re: FP stack Alex <alex@rivadpm.com> - 2017-05-10 08:10 +0100
Re: FP stack "Elizabeth D. Rather" <erather@forth.com> - 2017-05-09 21:24 -1000
Re: FP stack Julian Fondren <julian.fondren@gmail.com> - 2017-05-10 00:37 -0700
Re: FP stack "Elizabeth D. Rather" <erather@forth.com> - 2017-05-09 22:53 -1000
Re: FP stack Alex <alex@rivadpm.com> - 2017-05-10 08:53 +0100
Re: FP stack Ron Aaron <rambamist@gmail.com> - 2017-05-10 11:00 +0300
Re: FP stack Paul Rubin <no.email@nospam.invalid> - 2017-05-10 01:02 -0700
Re: FP stack Ron Aaron <rambamist@gmail.com> - 2017-05-10 11:06 +0300
Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 09:58 +0000
Re: FP stack Ron Aaron <rambamist@gmail.com> - 2017-05-10 14:17 +0300
Re: FP stack Alex <alex@rivadpm.com> - 2017-05-10 13:09 +0100
Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 15:05 +0000
Re: FP stack albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-10 11:43 +0200
Re: FP stack "HAA" <someone@microsoft.com> - 2017-05-10 18:34 +1000
Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 09:45 +0000
Re: FP stack "HAA" <someone@microsoft.com> - 2017-05-11 19:13 +1000
Re: FP stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-11 04:50 -0500
Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-11 16:18 +0000
Re: FP stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-11 12:12 -0500
Re: FP stack stephen@mpeforth.com (Stephen Pelc) - 2017-05-11 13:53 +0000
Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-11 15:43 +0000
Re: FP stack Joel Rees <joel.rees@gmail.com> - 2017-05-12 08:48 -0700
Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-11 16:31 +0000
Re: FP stack "Elizabeth D. Rather" <erather@forth.com> - 2017-05-11 10:18 -1000
Re: FP stack Cecil Bayona <cbayona@cbayona.com> - 2017-05-11 15:37 -0500
Re: FP stack "Elizabeth D. Rather" <erather@forth.com> - 2017-05-11 17:25 -1000
Re: FP stack Cecil Bayona <cbayona@cbayona.com> - 2017-05-11 22:55 -0500
Re: FP stack "HAA" <someone@microsoft.com> - 2017-05-13 14:24 +1000
Re: FP stack albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-13 13:44 +0200
Re: FP stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-10 05:58 -0500
Re: FP stack (was: Recognizers discussion) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-09 13:50 +0000
Re: FP stack (was: Recognizers discussion) Joel Rees <joel.rees@gmail.com> - 2017-05-10 00:25 -0700
Re: FP stack (was: Recognizers discussion) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 11:39 +0000
Re: FP stack (was: Recognizers discussion) Joel Rees <joel.rees@gmail.com> - 2017-05-10 11:49 -0700
Re: FP stack (was: Recognizers discussion) "HAA" <someone@microsoft.com> - 2017-05-09 21:15 +1000
Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-09 14:16 +1000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 08:57 -0500
Re: Recognizers discussion minforth@arcor.de - 2017-05-03 07:54 -0700
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 11:30 -0500
Re: Recognizers discussion Cecil Bayona <cbayona@cbayona.com> - 2017-05-03 14:05 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-03 18:42 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 02:51 -0500
Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-04 22:29 +1000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 13:41 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 09:06 -0500
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-15 12:22 +0000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 07:36 -0500
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-18 21:21 +0000
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-18 21:24 +0000
Re: Recognizers discussion albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-04 20:17 +0200
Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-05 11:03 +1000
Re: Recognizers discussion minforth@arcor.de - 2017-05-05 00:16 -0700
Re: Recognizers discussion JUERGEN <epldfpga@aol.com> - 2017-05-05 13:15 -0700
Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-06 16:49 +1000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-05 21:00 +0100
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-09 14:17 +0000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-09 15:46 +0100
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-10 11:50 +0000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-10 13:11 +0100
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-10 13:49 +0000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-10 15:57 +0100
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-12 14:17 +0000
Re: Recognizers discussion "Elizabeth D. Rather" <erather@forth.com> - 2017-05-02 09:25 -1000
Re: Recognizers discussion albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-03 01:19 +0200
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-05 15:50 +0000
Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-08 11:43 +1000
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-08 19:17 +0000
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-09 14:25 +0000
Re: Recognizers discussion "Elizabeth D. Rather" <erather@forth.com> - 2017-05-09 21:22 -1000
Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-13 13:33 +1000
Re: Recognizers discussion "Elizabeth D. Rather" <erather@forth.com> - 2017-05-12 21:32 -1000
Re: Recognizers discussion Howerd <howerdo@yahoo.co.uk> - 2017-05-13 07:12 -0700
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-13 14:30 +0000
Re: Recognizers discussion rickman <gnuarm@gmail.com> - 2017-05-04 11:37 -0400
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 17:51 +0100
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-05 07:31 +0000
Re: Recognizers discussion Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-05 20:35 +0200
Re: Recognizers discussion minforth@arcor.de - 2017-05-05 12:27 -0700
Re: Recognizers discussion Cecil Bayona <cbayona@cbayona.com> - 2017-05-05 15:03 -0500
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-06 16:26 +0000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-06 18:17 +0100
Re: Recognizers discussion Brad Eckert <hwfwguy@gmail.com> - 2017-05-06 12:26 -0700
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-06 21:39 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-07 03:58 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-07 10:39 +0100
Re: Recognizers discussion Bernd Paysan <bernd@net2o.de> - 2017-05-07 23:39 +0000
Re: Recognizers discussion Paul Rubin <no.email@nospam.invalid> - 2017-05-07 17:38 -0700
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-08 13:40 +0000
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-08 13:25 +0000
Re: Recognizers discussion Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-08 16:25 +0200
Flash (was: Recognizers discussion) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-07 10:51 +0000
Re: Flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-07 08:06 -0500
Re: Flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-07 13:57 +0000
Re: Flash Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-07 16:46 +0200
Re: Flash Alex <alex@rivadpm.com> - 2017-05-07 16:31 +0100
Re: Flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-07 17:16 +0000
Re: Flash Alex <alex@rivadpm.com> - 2017-05-07 19:18 +0100
Re: Flash albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-07 21:45 +0200
Re: Flash Matthias Trute <matthias.trute@gmail.com> - 2017-05-07 12:54 -0700
Re: Flash Alex <alex@rivadpm.com> - 2017-05-07 19:33 +0100
Re: Flash Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-07 08:50 -0700
Re: Flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-07 17:21 +0000
Re: Recognizers discussion Matthias Trute <matthias.trute@gmail.com> - 2017-05-04 10:07 -0700
Page 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2017-05-03 09:38 -0700 |
| Message-ID | <61b52df6-39a3-4283-be99-b39b996e0279@googlegroups.com> |
| In reply to | #58591 |
On Wednesday, 3 May 2017 16:51:33 UTC+1, Julian Fondren wrote: > On Wednesday, May 3, 2017 at 7:03:44 AM UTC-5, Mark Wills wrote: > > Primary uses I see for them are: > > > > 1) Nice way to recognise and deal with floating point numbers in source > > code. I.e. Instead of >f 3.141 we can just have 3.141 or (if your > > system produces doubles from a number with a decimal point (WTAF?) > > just f3.141 > > huh? > > Or more verbosely: > > What does ">f 3.141" mean? Is >f a parsing word that pushes a floating > point number? Why would you ever use that instead of 3.141e ? > > If "f3.141" is a floating point number, > Yes it is. > how is this better than 3.141e ? It's not. Didn't say it was. How is it better than 3.141. > What does "WTAF" mean? It means "What the *actual* f**k?" And why are you saying it in reply to a system > producing doubles from a number with a decimal point? Isn't that > virtually all systems? Yes it is. And it's dumb-fuckery of the highest order. I'm well aware of the historical legacy of the convention. It was a stupid ass idea then, in 1764 or whenever the first steam-powered Forth computer was invented, and it's most certainly a dumb idea in 2017 when world + dog cubed expects a FREAKING NUMBER WITH A DECIMAL POINT IN IT TO BE A FLOAT, NOT A F***ING INTEGER. I feel much better now. > > When I've wanted to have a bunch of floating point literals in code, > f.e. for OpenGL matrices and coordinates, I've just written a parsing > word to handle the nicer syntax, putting the numbers in storage, and > also doing stuff like translate - to 0e to reduce noise. This idea > also translates to 'literal mazes' for games, where each line is > padded appropriately before stored, which would be a lot messier for a > recognizer. With such you have exceptional parsing in a clearly > defined area (preceded by a parsing word) and you don't have to worry > about some random part of your program or a loaded library having its > doubles interpreted as floats. > Yes. This is how Forthers do it. Pathetic, isn't it? Meanwhile, on planet Earth, *EVERYONE ELSE* just types a freaking number with a decimal point in it. But not us. Not in the Forth world. That's far too bloody easy. No, let's just write our own IEEE754 number parser because, you, know, why wouldn't you? And don't use a library of (spit) "someone elses code" (better whisper that phrase, because it sets some of the older Forthers off and they're all having their afternoon naps) because, you know, where's the fun in that? No. Far better to invent your own method for your own Forth system, or even better, your own method JUST FOR THIS ONE APPLICATION (and future applications will be better/different, so bloody well pay attention) and make it just different enough from everyone else's methods to: a) Prove how clever you are; [1] b) (most important) be incompatible with everybody else's. [1] Not you specifically, i'm just being sarcastic in general! > > 2) Nice dotted OOP syntax > > Is this damning with faint praise? > Well, no intention to damn it. I think it's a much better method than writing all sorts of hooks. > I would say that recognizers are a nice way to implement the hooked > and exceptional parsers that Forths systems actually have. Recognizers > don't replace 'simplicity' with 'complexity', but 'system-specific > complexity' with 'standard complexity'. > I just think, as an implementor, it would actually be a major contributor to producing a very neart and tidy system (from the implementors POV); when one has to effectively hack one's own interpreter to add hooks, or worse, replace an interpreter with your own, it can leave a bit of a bad taste. Leaves one feeling that "there must be a better way than *this*". Recognisers may be it. I tend to agree with Andrew though, I would not advocate rushing into standardising anything right now. > This is a good replacement as it encourages people to actually use > those hooks to produce better code. It's also a worrying replacement > because it encourages people to actually use those hooks to produce > more obscure code. That may be true, but you could (presumably) remove them if they were not to your liking. I mean, they're (as proposed) on a recogniser stack, right? So we can DROP them, and hey presto, our system no longer understands roman numerals. Great! What have the Romans ever done for us anyway? :-)
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2017-05-03 09:59 -0700 |
| Message-ID | <6076816c-2a27-44fc-867f-4ac35b854a2f@googlegroups.com> |
| In reply to | #58594 |
On Wednesday, May 3, 2017 at 11:38:55 AM UTC-5, Mark Wills wrote:
> > When I've wanted to have a bunch of floating point literals in code,
> > f.e. for OpenGL matrices and coordinates, I've just written a parsing
> > word to handle the nicer syntax, putting the numbers in storage, and
> > also doing stuff like translate - to 0e to reduce noise. This idea
> > also translates to 'literal mazes' for games, where each line is
> > padded appropriately before stored, which would be a lot messier for a
> > recognizer. With such you have exceptional parsing in a clearly
> > defined area (preceded by a parsing word) and you don't have to worry
> > about some random part of your program or a loaded library having its
> > doubles interpreted as floats.
> >
> Yes. This is how Forthers do it. Pathetic, isn't it?
>
> Meanwhile, on planet Earth, *EVERYONE ELSE*
Writes code like this:
matrix = [
[1.05, 1.1, 1.2, 0.0, 0.0],
[0.0, 0.0, 1.2, 1.1, 1.05]
...
]
Instead of code like this:
create matrix
| 1.05 1.1 1.1 0 0
| 0 0 1.2 1.1 1.05
| ...
*****EVERYONE ELSE****** on ****PLANET EARTH**** don't have parsing
words so they're stuck with the verbose syntax their language gives
them even when they have a uniform wall of data.
To not use Forth is to suffer poverty in many ways. This is one.
> No, let's just write our own IEEE754 number parser
Your system already comes with one. In a pinch you can EVALUATE a
string after sticking an 'e' on it. This takes 1-3 lines total. It's a
convenience. If you want to enjoy the poverty of other languages you
can pretend you lack for parsing words and write
create matrix
1.05e fs, 1.1e fs, 1.1e fs, 0e fs, 0e fs,
0e fs, 0e fs, 1.2e fs, 1.1e fs, 1.05e fs,
Happy now?
OK, here it is without the 'e':
create matrix
1.05 fs, 1.1 fs, 1.1 fs, 0 fs, 0 fs,
0 fs, 0 fs, 1.2 fs, 1.1 fs, 1.05 fs,
I'd rather have the parsing version myself.
> a) Prove how clever you are; [1]
> b) (most important) be incompatible with everybody else's.
Parsing words are less clever and more portable. If a particular
parsing definition doesn't work for you, you can write a definition
for your system. With recognizer stacks you either have them or you
don't. And if you don't, and don't have hooks for literal Lisp strings
or whatever else is being used, the code is a porting headache on a
whole new level - one that you can't solve by defining a word, because
[1,2,3] and [3, 4,5] and [every,other,example] don't have words that
you can define anymore.
> > This is a good replacement as it encourages people to actually use
> > those hooks to produce better code. It's also a worrying replacement
> > because it encourages people to actually use those hooks to produce
> > more obscure code.
>
> That may be true, but you could (presumably) remove them if they were
> not to your liking. I mean, they're (as proposed) on a recogniser stack,
> right? So we can DROP them, and hey presto, our system no longer
... can no longer compile all this code written to use that stack.
I'll agree that if you can just throw away a bunch of code then it
isn't much of a problem that it was obscure...
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2017-05-03 10:16 -0700 |
| Message-ID | <3a8540ce-6e53-481a-ba45-08a384c75758@googlegroups.com> |
| In reply to | #58597 |
On Wednesday, 3 May 2017 17:59:31 UTC+1, Julian Fondren wrote: > Parsing words are less clever and more portable. If a particular > parsing definition doesn't work for you, you can write a definition > for your system. With recognizer stacks you either have them or you > don't. And if you don't, and don't have hooks for literal Lisp strings > or whatever else is being used, the code is a porting headache on a > whole new level - one that you can't solve by defining a word, because > [1,2,3] and [3, 4,5] and [every,other,example] don't have words that > you can define anymore. I don't think that that is true, is it? I mean, if you are having to write a parsing word and hook it into the interpreter in a traditional system, then adding the same functionality to a Recogniser system would entail: 1) Writing and testing the parsing word; 2) Adding it to the recogniser stack. The benefit would be that you no longer have to stick your hand down the interpreters pants (!) and deal with hooks (that may not be present), rather, you add your additional parsing functionality in a standardised way. So, to use my (silly example) of a roman numeral recogniser, I'd write the parser as a colon def, test it, and when satisfied add it to the recogniser. I don't see why that would be more objectionable than writing the parser, ticking it, and poking its address into some hook variable or deferred word that the system implementer may/may not have had the wisdom to leave for you. Am I missing something?
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-05-03 22:04 +0200 |
| Message-ID | <oedd3v$m7h$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #58594 |
In article <61b52df6-39a3-4283-be99-b39b996e0279@googlegroups.com>, Mark Wills <markwills1970@gmail.com> wrote: >On Wednesday, 3 May 2017 16:51:33 UTC+1, Julian Fondren wrote: >> On Wednesday, May 3, 2017 at 7:03:44 AM UTC-5, Mark Wills wrote: >> > Primary uses I see for them are: >> > >> > 1) Nice way to recognise and deal with floating point numbers in source >> > code. I.e. Instead of >f 3.141 we can just have 3.141 or (if your >> > system produces doubles from a number with a decimal point (WTAF?) >> > just f3.141 >> >> huh? >> >> Or more verbosely: >> >> What does ">f 3.141" mean? Is >f a parsing word that pushes a floating >> point number? Why would you ever use that instead of 3.141e ? >> >> If "f3.141" is a floating point number, >> >Yes it is. > >> how is this better than 3.141e ? >It's not. Didn't say it was. How is it better than 3.141. > > >> What does "WTAF" mean? >It means "What the *actual* f**k?" > >And why are you saying it in reply to a system >> producing doubles from a number with a decimal point? Isn't that >> virtually all systems? > >Yes it is. And it's dumb-fuckery of the highest order. I'm well aware >of the historical legacy of the convention. It was a stupid ass idea >then, in 1764 or whenever the first steam-powered Forth computer was >invented, and it's most certainly a dumb idea in 2017 when world + dog >cubed expects a FREAKING NUMBER WITH A DECIMAL POINT IN IT TO BE A >FLOAT, NOT A F***ING INTEGER. > >I feel much better now. A remark to the effect of "we must get rid of the decimal point for doubles" is to be found in a precursor document for Forth79. (The Dutch Chapter has dug that one up recently, Hans Nieuwenhuizen had it.) Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | minforth@arcor.de |
|---|---|
| Date | 2017-05-03 22:09 -0700 |
| Message-ID | <a2f4b0ed-1468-4ff3-9ab4-e1162031804b@googlegroups.com> |
| In reply to | #58612 |
Am Mittwoch, 3. Mai 2017 22:02:25 UTC+2 schrieb Albert van der Horst: > In article <61b52df6-39a3-4283-be99-b39b996e0279@googlegroups.com>, > Mark Wills <markwills1970@gmail.com> wrote: > >On Wednesday, 3 May 2017 16:51:33 UTC+1, Julian Fondren wrote: > >> On Wednesday, May 3, 2017 at 7:03:44 AM UTC-5, Mark Wills wrote: > >> > Primary uses I see for them are: > >> > > >> > 1) Nice way to recognise and deal with floating point numbers in source > >> > code. I.e. Instead of >f 3.141 we can just have 3.141 or (if your > >> > system produces doubles from a number with a decimal point (WTAF?) > >> > just f3.141 > >> > >> huh? > >> > >> Or more verbosely: > >> > >> What does ">f 3.141" mean? Is >f a parsing word that pushes a floating > >> point number? Why would you ever use that instead of 3.141e ? > >> > >> If "f3.141" is a floating point number, > >> > >Yes it is. > > > >> how is this better than 3.141e ? > >It's not. Didn't say it was. How is it better than 3.141. > > > > > >> What does "WTAF" mean? > >It means "What the *actual* f**k?" > > > >And why are you saying it in reply to a system > >> producing doubles from a number with a decimal point? Isn't that > >> virtually all systems? > > > >Yes it is. And it's dumb-fuckery of the highest order. I'm well aware > >of the historical legacy of the convention. It was a stupid ass idea > >then, in 1764 or whenever the first steam-powered Forth computer was > >invented, and it's most certainly a dumb idea in 2017 when world + dog > >cubed expects a FREAKING NUMBER WITH A DECIMAL POINT IN IT TO BE A > >FLOAT, NOT A F***ING INTEGER. > > > >I feel much better now. > > A remark to the effect of "we must get rid of the decimal point for > doubles" is to be found in a precursor document for Forth79. > (The Dutch Chapter has dug that one up recently, Hans Nieuwenhuizen > had it.) > > Groetjes Albert > -- > Albert van der Horst, UTRECHT,THE NETHERLANDS > Economic growth -- being exponential -- ultimately falters. > albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst In F83 " 12.00 DPL @ " is a double number ( -- 12 0 2 ) IIRC in F94 it is not(!) or "unspecified behavior" when it is recognized as such, and only when the double number wordest is included. The standard 8.3.1 says so. So the holy cow of legacy code protection had already been hit once in the past.
[toc] | [prev] | [next] | [standalone]
| From | Joel Rees <joel.rees@gmail.com> |
|---|---|
| Date | 2017-05-07 19:50 -0700 |
| Message-ID | <3bfb77ae-f710-4c37-8d5f-5d55a6cea02d@googlegroups.com> |
| In reply to | #58580 |
On Wednesday, May 3, 2017 at 9:03:44 PM UTC+9, Mark Wills wrote: > On Wednesday, 3 May 2017 12:49:25 UTC+1, minf...@arcor.de wrote: > > Am Mittwoch, 3. Mai 2017 11:38:26 UTC+2 schrieb Andrew Haley: > > > Bernd Paysan <> wrote: > > > > Am Tue, 02 May 2017 13:10:07 -0500 schrieb Andrew Haley: > > > > > > > >> Alex <> wrote: > > > >>> On 5/2/2017 18:35, Andrew Haley wrote: > > > >>> > > > >>> > > > >>>>> The only difference will be the inability to add recognizers, > > > >>>>> simple, literal or otherwise, in a standard way. > > > >>>> > > > >>>> I don't understand this last sentence. > > > >>> > > > >>> I mean that we will not be able, in a standard way, to extend number > > > >>> recognition. Matthias proposes recognizers, and having built a system > > > >>> that employs them, I can attest to their simplicity and universality. > > > >> > > > >> Yes, but you don't need recognizing numbers to come before the > > > >> dictionary search in order to do that. > > > > > > > > You are still locked into thinking that the recognizer is for numbers > > > > only. It isn't. Get out of your box. Recognizers can be dot parsers, > > > > can be scope parsers (scope:word), and where they sit in the recognizer > > > > order depends on the job. > > > > > > I get that, I really do. But user-defined recognizers for literals > > > have so far been the only reasonable use for them I've seen. > > > > > > > Literal recognizers will certainly be added after the dictionary > > > > search. Unless you want to parse a ton of literals quickly, then > > > > you reverse that temporarily. > > > > > > > > And one important factor for a clean design is that you have rules, > > > > but no exceptions. The dictionary search is just one recognizer, > > > > nothing special (people suggested that it's actually a stack of > > > > recognizers, with each vocabulary in the search order being one > > > > recognizer). > > > > > > I get that too. The question is whether it's a good thing or a bad > > > thing. > > > > > > Andrew. > > > > In my world there are users (customers) and implementers (engineers). Users will never touch recognizers or even know they exist. Software engineers are clever enough to extend NUMBER? in a small Forth System by a few lines of code to recognize application-specific formats. They really don't need recognizers. > > > > However things are not so easy when the Forth system source is not disclosed,, e.g. encrypted or protected by some other means. > > > > Then recognizers offer hooks to "crippled implementors" of new data formats while maintaining core system source protection. On the other hand recognizers are nice backdoor for incrementing target system vulnerability. ;-) > > Primary uses I see for them are: > > 1) Nice way to recognise and deal with floating point numbers in source > code. I.e. Instead of >f 3.141 we can just have 3.141 or (if your > system produces doubles from a number with a decimal point (WTAF?) > just f3.141 I've never understood the need for a separate floating point stack. Separating the return address from local state and parameters, yes, I understand that. I'm a strong advocate of that. Separating the parameters in local state from internal use variables in local state and having a third stack where the internal use variables can be maintained without messing with the parameters can be really useful when we don't want to use frame pointers (either run-time or compile-time) and otherwise keep the total system smallish. But we put doubles, pointers, string pointers, string records, and all sorts of other non-single-cell-integer non-scalar stuff on the parameter/local state stack. Why not floating point, as well? (Especially, now that 32 bit and 64 bit CPUs are becoming the norm, even in the embedded world.) > 2) Nice dotted OOP syntax Don't we already have a nice OOP syntax that doesn't depend on dots? -- Joel Rees Delusions of being an engineer: http://defining-computers.blogspot.jp/
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-05-07 21:33 -1000 |
| Message-ID | <0bSdnb9z76H5go3EnZ2dnUU7-VvNnZ2d@supernews.com> |
| In reply to | #58803 |
On 5/7/17 4:50 PM, Joel Rees wrote: > On Wednesday, May 3, 2017 at 9:03:44 PM UTC+9, Mark Wills wrote: >> On Wednesday, 3 May 2017 12:49:25 UTC+1, minf...@arcor.de wrote: >>> Am Mittwoch, 3. Mai 2017 11:38:26 UTC+2 schrieb Andrew Haley: >>>> Bernd Paysan <> wrote: >>>>> Am Tue, 02 May 2017 13:10:07 -0500 schrieb Andrew Haley: >>>>> >>>>>> Alex <> wrote: >>>>>>> On 5/2/2017 18:35, Andrew Haley wrote: >>>>>>> >>>>>>> >>>>>>>>> The only difference will be the inability to add recognizers, >>>>>>>>> simple, literal or otherwise, in a standard way. >>>>>>>> >>>>>>>> I don't understand this last sentence. >>>>>>> >>>>>>> I mean that we will not be able, in a standard way, to extend number >>>>>>> recognition. Matthias proposes recognizers, and having built a system >>>>>>> that employs them, I can attest to their simplicity and universality. >>>>>> >>>>>> Yes, but you don't need recognizing numbers to come before the >>>>>> dictionary search in order to do that. >>>>> >>>>> You are still locked into thinking that the recognizer is for numbers >>>>> only. It isn't. Get out of your box. Recognizers can be dot parsers, >>>>> can be scope parsers (scope:word), and where they sit in the recognizer >>>>> order depends on the job. >>>> >>>> I get that, I really do. But user-defined recognizers for literals >>>> have so far been the only reasonable use for them I've seen. >>>> >>>>> Literal recognizers will certainly be added after the dictionary >>>>> search. Unless you want to parse a ton of literals quickly, then >>>>> you reverse that temporarily. >>>>> >>>>> And one important factor for a clean design is that you have rules, >>>>> but no exceptions. The dictionary search is just one recognizer, >>>>> nothing special (people suggested that it's actually a stack of >>>>> recognizers, with each vocabulary in the search order being one >>>>> recognizer). >>>> >>>> I get that too. The question is whether it's a good thing or a bad >>>> thing. >>>> >>>> Andrew. >>> >>> In my world there are users (customers) and implementers (engineers). Users will never touch recognizers or even know they exist. Software engineers are clever enough to extend NUMBER? in a small Forth System by a few lines of code to recognize application-specific formats. They really don't need recognizers. >>> >>> However things are not so easy when the Forth system source is not disclosed,, e.g. encrypted or protected by some other means. >>> >>> Then recognizers offer hooks to "crippled implementors" of new data formats while maintaining core system source protection. On the other hand recognizers are nice backdoor for incrementing target system vulnerability. ;-) >> >> Primary uses I see for them are: >> >> 1) Nice way to recognise and deal with floating point numbers in source >> code. I.e. Instead of >f 3.141 we can just have 3.141 or (if your >> system produces doubles from a number with a decimal point (WTAF?) >> just f3.141 > > I've never understood the need for a separate floating point stack. > > Separating the return address from local state and parameters, yes, I understand that. I'm a strong advocate of that. > > Separating the parameters in local state from internal use variables in local state and having a third stack where the internal use variables can be maintained without messing with the parameters can be really useful when we don't want to use frame pointers (either run-time or compile-time) and otherwise keep the total system smallish. > > But we put doubles, pointers, string pointers, string records, and all sorts of other non-single-cell-integer non-scalar stuff on the parameter/local state stack. Why not floating point, as well? (Especially, now that 32 bit and 64 bit CPUs are becoming the norm, even in the embedded world.) The first reason is that processors with hardware FP had separate stacks, and it was fastest and most convenient to use them. But it's really convenient to have them separate, because you usually have several non-fp items that you're juggling (addresses, etc.) at the same time. Cheers, Elizabeth >> 2) Nice dotted OOP syntax > > Don't we already have a nice OOP syntax that doesn't depend on dots? > > -- > Joel Rees > > Delusions of being an engineer: > http://defining-computers.blogspot.jp/ > -- Elizabeth D. Rather FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-08 04:12 -0500 |
| Message-ID | <uuKdnfQCcLnnq43EnZ2dnUU7-SOdnZ2d@supernews.com> |
| In reply to | #58803 |
Joel Rees <joel.rees@gmail.com> wrote: > > I've never understood the need for a separate floating point stack. > [ ... ] > But we put doubles, pointers, string pointers, string records, and > all sorts of other non-single-cell-integer non-scalar stuff on the > parameter/local state stack. Why not floating point, as well? > (Especially, now that 32 bit and 64 bit CPUs are becoming the norm, > even in the embedded world.) It's really difficult to write portable code. If you could be really sure that a float was a single cell on the stack it'd be OK, kinda- sorta, but otherwise it gets really messy. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Joel Rees <joel.rees@gmail.com> |
|---|---|
| Date | 2017-05-08 20:21 -0700 |
| Message-ID | <f9db12f2-30bb-4819-9513-ad5f885dc19d@googlegroups.com> |
| In reply to | #58816 |
On Monday, May 8, 2017 at 6:12:31 PM UTC+9, Andrew Haley wrote: > Joel Rees <joel rees@somewhere> wrote: > > > > I've never understood the need for a separate floating point stack. > > [ ... ] > > But we put doubles, pointers, string pointers, string records, and > > all sorts of other non-single-cell-integer non-scalar stuff on the > > parameter/local state stack. Why not floating point, as well? > > (Especially, now that 32 bit and 64 bit CPUs are becoming the norm, > > even in the embedded world.) > > It's really difficult to write portable code. If you could be really > sure that a float was a single cell on the stack it'd be OK, kinda- > sorta, but otherwise it gets really messy. > > Andrew. If we need to know the byte-width of a CELL, we have a constant, right? (Or we can make one easily.) Why not include a constant or two with our floating point words -- FPCELLWIDTH and DFPCELLWIDTH, or the like?
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-08 12:35 +0000 |
| Subject | FP stack (was: Recognizers discussion) |
| Message-ID | <2017May8.143500@mips.complang.tuwien.ac.at> |
| In reply to | #58803 |
Joel Rees <joel.rees@gmail.com> writes:
>I've never understood the need for a separate floating point stack.
...
>But we put doubles, pointers, string pointers, string records, and all sort=
>s of other non-single-cell-integer non-scalar stuff on the parameter/local =
>state stack. Why not floating point, as well? (Especially, now that 32 bit =
>and 64 bit CPUs are becoming the norm, even in the embedded world.)
1) There is little overlap between integer and FP operations,
basically just the data-movement stuff @ ! DUP SWAP etc. By contrast,
we use, e.g., +, -, and u< on signed and unsigned integers, and on
addresses, and being able to access the individual cells of doubles
allows implementing various more refined operations (e.g., triple-cell
integers in M*/). Having the individual cells of a c-addr u string
descriptor accessible is the foundation for a number of string
operations, e.g., checking whether a string is a prefix of another
string. If we put these data on separate stacks, we would have to
introduce and then use all kinds of words for transfering cells
between these stacks; that's not the case for FP data.
2) How many cells should an FP value have on the data stack? 1? 2? 4?
None of these answers is good for all systems. Or maybe an FP value
should be an opaque type with an unspecified size? Then you cannot
access anything below it.
3) FP hardware usually works on separate FP registers, and transfers
between FP registers and integer registers are often pretty expensive
(sometimes they require a memory store and memory load). Many Forth
systems keep the top-of-data-stack in an integer register. On such a
system with a shared integer+FP-stack an FP operation would imply a
move from the integer registers to the FP registers and back. By
contrast, with a separate FP stack, the system can keep the
top-of-FP-stack in an FP register. On the 387 the whole Forth FP
stack is often kept in the 387 FP stack.
This has now come up several times, so I have added it to the FAQ:
https://www.complang.tuwien.ac.at/forth/faq/faq-general.html#toc5.15
- 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 | Joel Rees <joel.rees@gmail.com> |
|---|---|
| Date | 2017-05-08 20:50 -0700 |
| Subject | Re: FP stack (was: Recognizers discussion) |
| Message-ID | <850fb914-4c39-4142-888a-a0871d108b4a@googlegroups.com> |
| In reply to | #58827 |
On Monday, May 8, 2017 at 10:24:31 PM UTC+9, Anton Ertl wrote: > Joel Rees <joel rees@somewhere> writes: > >I've never understood the need for a separate floating point stack. > ... > >But we put doubles, pointers, string pointers, string records, and all sort= > >s of other non-single-cell-integer non-scalar stuff on the parameter/local = > >state stack. Why not floating point, as well? (Especially, now that 32 bit = > >and 64 bit CPUs are becoming the norm, even in the embedded world.) > > 1) There is little overlap between integer and FP operations, > basically just the data-movement stuff @ ! DUP SWAP etc. By contrast, > we use, e.g., +, -, and u< on signed and unsigned integers, and on > addresses, and being able to access the individual cells of doubles > allows implementing various more refined operations (e.g., triple-cell > integers in M*/). Well, the virtual word U+ is the same as + on two's complement, but D+ is still D+. And then there is UM* and UM/MOD, etc. It's not like type is completely transparent until you hit FP. > Having the individual cells of a c-addr u string > descriptor accessible is the foundation for a number of string > operations, e.g., checking whether a string is a prefix of another > string. If we put these data on separate stacks, we would have to > introduce and then use all kinds of words for transfering cells > between these stacks; that's not the case for FP data. I find that the first thing I want to do with an FP is split the fields out. OCD? No, I just don't like a useless equality compare operation. I suppose that's probably better done at the assembler level anyway, since it's not portable. > 2) How many cells should an FP value have on the data stack? 1? 2? 4? > None of these answers is good for all systems. Or maybe an FP value > should be an opaque type with an unspecified size? Then you cannot > access anything below it. As I mentioned elsewhere, I don't understand how this is a concern. When we need to know the byte width of a CELL, if we don't have a constant for it, we make one, just so we don't have to keep writing SP@ SP@ - all over in our code. We have to provide the floating point math words, why not just provide a few constants to tell us how big they are? Don't we have those constants anyway, since we sometimes need to pull FP values off the FP stack and put them somewhere? > 3) FP hardware usually works on separate FP registers, and transfers > between FP registers and integer registers are often pretty expensive > (sometimes they require a memory store and memory load). I'll grant that, although I don't think of a memory store/load sequence as all that expensive except in the tightest of loops. Still, having to move several values between top of the parameter stack and the FP stack every time you want to do math on a floating point does get in the way. > Many Forth > systems keep the top-of-data-stack in an integer register. On such a > system with a shared integer+FP-stack an FP operation would imply a > move from the integer registers to the FP registers and back. By > contrast, with a separate FP stack, the system can keep the > top-of-FP-stack in an FP register. On the 387 the whole Forth FP > stack is often kept in the 387 FP stack. The separate FP registers issue is about the only reason I can see that makes sense to me. Otherwise, I think I'd rather have them on the same stack(s) with other data. I'm not a real fan of most floating point hardware. Lack of support for a fully meaningful set of equality operators is just one of the problems. Separate registers is another, although, on a register- starved CPU, extra registers for floating point registers can be rather useful. > This has now come up several times, so I have added it to the FAQ: > > https://www.complang.tuwien.ac.at/forth/faq/faq-general.html#toc5.15 > > - 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/ Kudos, BTW, for your work for the community. -- Joel Rees randomly ranting: http://reiisi.blogspot.com
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-09 03:39 -0500 |
| Subject | Re: FP stack |
| Message-ID | <jaCdnd81L7PWHYzEnZ2dnUU7-TmdnZ2d@supernews.com> |
| In reply to | #58870 |
Joel Rees <joel.rees@gmail.com> wrote:
>
>> 2) How many cells should an FP value have on the data stack? 1? 2? 4?
>> None of these answers is good for all systems. Or maybe an FP value
>> should be an opaque type with an unspecified size? Then you cannot
>> access anything below it.
>
> As I mentioned elsewhere, I don't understand how this is a concern.
>
> When we need to know the byte width of a CELL, if we don't have a
> constant for it, we make one, just so we don't have to keep writing
>
> SP@ SP@ -
>
> all over in our code.
>
> We have to provide the floating point math words, why not just provide
> a few constants to tell us how big they are?
That's not the problem. Say you have
1 1.0e0
on an integrated stack with floating-point numbers and integers. How
do you SWAP them? A float might be 1, 2, or 3 cells in size.
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Joel Rees <joel.rees@gmail.com> |
|---|---|
| Date | 2017-05-09 20:59 -0700 |
| Subject | Re: FP stack |
| Message-ID | <86ae3a80-ffe1-4a25-a727-908f353587d0@googlegroups.com> |
| In reply to | #58878 |
On Tuesday, May 9, 2017 at 5:39:44 PM UTC+9, Andrew Haley wrote:
> Joel Rees <joel rees@somewhere> wrote:
> >
> >> 2) How many cells should an FP value have on the data stack? 1? 2? 4?
> >> None of these answers is good for all systems. Or maybe an FP value
> >> should be an opaque type with an unspecified size? Then you cannot
> >> access anything below it.
> >
> > As I mentioned elsewhere, I don't understand how this is a concern.
> >
> > When we need to know the byte width of a CELL, if we don't have a
> > constant for it, we make one, just so we don't have to keep writing
> >
> > SP@ SP@ -
> >
> > all over in our code.
> >
> > We have to provide the floating point math words, why not just provide
> > a few constants to tell us how big they are?
>
> That's not the problem. Say you have
>
> 1 1.0e0
>
> on an integrated stack with floating-point numbers and integers. How
> do you SWAP them? A float might be 1, 2, or 3 cells in size.
>
> Andrew.
Say you have
1 1.
on stack. How do you swap them?
Sure, you know a double is two cells. But that is just an implicit
constant. Hmm.
2>R S>D 2R> DSWAP
is a "robust" solution that does not reference the constant in the
programmer's mind. It could be followed by a D>S if we want to be
perfectly thorough.
F>R S>F FR> FSWAP
Admittedly, tagging an F>S on the end of that would require really
good rounding in the definition of F>S, and may induce unintentional
sensitivity to exceptions.
Or you could use run-time conditionals to cover the expected cases.
(How common is conditional compile in Forth interpreters these days?)
--
Joel Rees
randomly ranting about the computer industry:
http://defining-computers.blogspot.jp/
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2017-05-10 00:03 -0700 |
| Subject | Re: FP stack |
| Message-ID | <1cc42629-987f-4138-a6c1-02eb8eb203a2@googlegroups.com> |
| In reply to | #58921 |
On Tuesday, May 9, 2017 at 10:59:40 PM UTC-5, Joel Rees wrote: > On Tuesday, May 9, 2017 at 5:39:44 PM UTC+9, Andrew Haley wrote: > > That's not the problem. Say you have > > > > 1 1.0e0 > > > > on an integrated stack with floating-point numbers and integers. How > > do you SWAP them? A float might be 1, 2, or 3 cells in size. > > > > Andrew. > > Say you have > > 1 1. > > on stack. How do you swap them? > > Sure, you know a double is two cells. But that is just an implicit > constant. Hmm. ... it's also a constant constant. It's *always and everywhere* two cells. Which means you can code directly for it and not grope for 'robust' solutions that could be easily adapted to never to be seen cases like doubles taking other than double cells on the data stack. So you just write one of ROT ( s d -- d s ) -ROT ( d s -- s d ) (Which are approximately the factors you'd want to swap a float and a single cell on unified data stack.) > (How common is conditional compile in Forth interpreters these days?) It's standard. Forth-2012 added some.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-10 08:10 +0100 |
| Subject | Re: FP stack |
| Message-ID | <oeue6m$60g$1@dont-email.me> |
| In reply to | #58921 |
On 5/10/2017 04:59, Joel Rees wrote: > Say you have > > 1 1. > > on stack. How do you swap them? ROT 1 3. ok[3] rot ok[3] . 1 ok[2] d. 3 ok -- Alex
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-05-09 21:24 -1000 |
| Subject | Re: FP stack |
| Message-ID | <6tednSpqKomGXY_EnZ2dnUU7-N1QAAAA@supernews.com> |
| In reply to | #58927 |
On 5/9/17 9:10 PM, Alex wrote: > On 5/10/2017 04:59, Joel Rees wrote: >> Say you have >> >> 1 1. >> >> on stack. How do you swap them? > > ROT > > 1 3. ok[3] > rot ok[3] > . 1 ok[2] > d. 3 ok Ok, I'll bite, how do you know 1. doesn't occupy 4 cells? Cheers, Elizabeth -- Elizabeth D. Rather FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2017-05-10 00:37 -0700 |
| Subject | Re: FP stack |
| Message-ID | <515c74c3-33a0-4e5e-8521-72c6bf3936d4@googlegroups.com> |
| In reply to | #58930 |
On Wednesday, May 10, 2017 at 2:24:17 AM UTC-5, Elizabeth D. Rather wrote: > On 5/9/17 9:10 PM, Alex wrote: > > On 5/10/2017 04:59, Joel Rees wrote: > >> Say you have > >> > >> 1 1. > >> > >> on stack. How do you swap them? > > > > ROT > > > > 1 3. ok[3] > > rot ok[3] > > . 1 ok[2] > > d. 3 ok > > Ok, I'll bite, how do you know 1. doesn't occupy 4 cells? Alex knows that because it's a double and not a float. Joel was trying to show the problem Forth would have with floats having variable cell widths on the data stack is a problem that Forth already has from doubles taking up two cells on the data stack. > Cheers, > Elizabeth > > -- > Elizabeth D. Rather > FORTH, Inc. > 6080 Center Drive, Suite 600 > Los Angeles, CA 90045 > USA
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-05-09 22:53 -1000 |
| Subject | Re: FP stack |
| Message-ID | <9NudnRO-PJxjSY_EnZ2dnUU7-WXNnZ2d@supernews.com> |
| In reply to | #58935 |
On 5/9/17 9:37 PM, Julian Fondren wrote: > On Wednesday, May 10, 2017 at 2:24:17 AM UTC-5, Elizabeth D. Rather wrote: >> On 5/9/17 9:10 PM, Alex wrote: >>> On 5/10/2017 04:59, Joel Rees wrote: >>>> Say you have >>>> >>>> 1 1. >>>> >>>> on stack. How do you swap them? >>> >>> ROT >>> >>> 1 3. ok[3] >>> rot ok[3] >>> . 1 ok[2] >>> d. 3 ok >> >> Ok, I'll bite, how do you know 1. doesn't occupy 4 cells? > > Alex knows that because it's a double and not a float. > > Joel was trying to show the problem Forth would have with floats > having variable cell widths on the data stack is a problem that Forth > already has from doubles taking up two cells on the data stack. Ok, my bad, I forgot that 3. is a double, having focused on floats in this discussion! Cheers, Elizabeth -- Elizabeth D. Rather FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-10 08:53 +0100 |
| Subject | Re: FP stack |
| Message-ID | <oeugmr$d7s$1@dont-email.me> |
| In reply to | #58930 |
On 5/10/2017 08:24, Elizabeth D. Rather wrote: > On 5/9/17 9:10 PM, Alex wrote: >> On 5/10/2017 04:59, Joel Rees wrote: >>> Say you have >>> >>> 1 1. >>> >>> on stack. How do you swap them? >> >> ROT >> >> 1 3. ok[3] >> rot ok[3] >> . 1 ok[2] >> d. 3 ok > > Ok, I'll bite, how do you know 1. doesn't occupy 4 cells? > > Cheers, > Elizabeth > d double-cell signed number 2 cells +d double-cell non-negative number 2 cells ud double-cell unsigned number 2 cells d | ud[2] double-cell number 2 cells xd unspecified cell pair 2 cells -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Ron Aaron <rambamist@gmail.com> |
|---|---|
| Date | 2017-05-10 11:00 +0300 |
| Subject | Re: FP stack |
| Message-ID | <oeuh5h$eo7$1@dont-email.me> |
| In reply to | #58938 |
On 05/10/17 10:53, Alex wrote: > On 5/10/2017 08:24, Elizabeth D. Rather wrote: >> Ok, I'll bite, how do you know 1. doesn't occupy 4 cells? > d double-cell signed number 2 cells > +d double-cell non-negative number 2 cells > ud double-cell unsigned number 2 cells > d | ud[2] double-cell number 2 cells > xd unspecified cell pair 2 cells IMO, this is one of the weaknesses of ANS Forth. You have to keep track of how many cells your data takes up. Strings can be one or two cells, so can numbers; and, I suppose, other things as well. Wouldn't it have made some sense to make all items take one cell on the stack so that you could just use SWAP without worrying?
[toc] | [prev] | [next] | [standalone]
Page 4 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