Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #50849 > unrolled thread
| Started by | Alex Dowad <alexinbeijing@gmail.com> |
|---|---|
| First post | 2016-09-11 06:12 -0700 |
| Last post | 2016-09-12 14:08 +0200 |
| Articles | 20 on this page of 96 — 19 participants |
Back to article view | Back to comp.lang.forth
Given a string, create word with that name (in ANS Forth)? Alex Dowad <alexinbeijing@gmail.com> - 2016-09-11 06:12 -0700
Re: Given a string, create word with that name (in ANS Forth)? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-11 10:51 -0500
Re: Given a string, create word with that name (in ANS Forth)? Alex Dowad <alexinbeijing@gmail.com> - 2016-09-11 09:49 -0700
Re: Given a string, create word with that name (in ANS Forth)? Lars Brinkhoff <lars.spam@nocrew.org> - 2016-09-11 19:57 +0200
Re: Given a string, create word with that name (in ANS Forth)? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-12 02:43 -0500
Re: Given a string, create word with that name (in ANS Forth)? Paul Rubin <no.email@nospam.invalid> - 2016-09-11 14:31 -0700
Re: Given a string, create word with that name (in ANS Forth)? hughaguilar96@gmail.com - 2016-09-11 10:14 -0700
Re: Given a string, create word with that name (in ANS Forth)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-12 07:46 +0000
Re: Given a string, create word with that name (in ANS Forth)? Paul Rubin <no.email@nospam.invalid> - 2016-09-12 01:10 -0700
Re: Given a string, create word with that name (in ANS Forth)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-12 09:01 +0000
Re: Given a string, create word with that name (in ANS Forth)? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-12 14:02 +0200
Re: Given a string, create word with that name (in ANS Forth)? "HAA" <someone@microsoft.com> - 2016-09-20 12:06 +1000
Re: Given a string, create word with that name (in ANS Forth)? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-20 11:27 +0200
Re: Given a string, create word with that name (in ANS Forth)? Paul Rubin <no.email@nospam.invalid> - 2016-09-12 13:02 -0700
Re: Given a string, create word with that name (in ANS Forth)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-13 16:20 +0000
Re: Given a string, create word with that name (in ANS Forth)? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-13 21:08 +0200
Re: Given a string, create word with that name (in ANS Forth)? Paul Rubin <no.email@nospam.invalid> - 2016-09-13 17:30 -0700
Re: Given a string, create word with that name (in ANS Forth)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-14 07:11 +0000
Re: Given a string, create word with that name (in ANS Forth)? hughaguilar96@gmail.com - 2016-09-14 18:30 -0700
Re: Given a string, create word with that name (in ANS Forth)? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-15 02:46 -0500
Re: Given a string, create word with that name (in ANS Forth)? "Elizabeth D. Rather" <erather@forth.com> - 2016-09-20 14:27 -0700
Re: Given a string, create word with that name (in ANS Forth)? hughaguilar96@gmail.com - 2016-09-20 15:05 -0700
Re: Given a string, create word with that name (in ANS Forth)? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-09-20 22:19 +0000
Re: Given a string, create word with that name (in ANS Forth)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-21 12:26 +0000
Re: Given a string, create word with that name (in ANS Forth)? Coos Haak <htrofhc@gmail.com> - 2016-09-21 15:11 +0200
Re: Given a string, create word with that name (in ANS Forth)? mhx@iae.nl - 2016-09-21 10:06 -0700
Re: Given a string, create word with that name (in ANS Forth)? Coos Haak <htrofhc@gmail.com> - 2016-09-21 21:12 +0200
Re: Given a string, create word with that name (in ANS Forth)? "Elizabeth D. Rather" <erather@forth.com> - 2016-09-21 12:06 -1000
Re: Given a string, create word with that name (in ANS Forth)? Paul Rubin <no.email@nospam.invalid> - 2016-09-21 15:40 -0700
Re: Given a string, create word with that name (in ANS Forth)? "HAA" <someone@microsoft.com> - 2016-09-22 13:04 +1000
Re: Given a string, create word with that name (in ANS Forth)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-22 07:40 +0000
Re: Given a string, create word with that name (in ANS Forth)? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-09-22 15:46 +0100
Re: Given a string, create word with that name (in ANS Forth)? hughaguilar96@gmail.com - 2016-09-22 11:08 -0700
Re: Given a string, create word with that name (in ANS Forth)? Lars Brinkhoff <lars.spam@nocrew.org> - 2016-09-22 22:04 +0200
Re: Given a string, create word with that name (in ANS Forth)? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-09-23 10:21 +0100
Re: Given a string, create word with that name (in ANS Forth)? Lars Brinkhoff <lars.spam@nocrew.org> - 2016-09-23 12:06 +0200
Re: Given a string, create word with that name (in ANS Forth)? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-23 10:44 -0500
Re: Given a string, create word with that name (in ANS Forth)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-23 16:26 +0000
Re: Given a string, create word with that name (in ANS Forth)? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-24 03:46 -0500
Re: Given a string, create word with that name (in ANS Forth)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-24 10:13 +0000
Re: Given a string, create word with that name (in ANS Forth)? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-24 10:34 -0500
Re: Given a string, create word with that name (in ANS Forth)? Lars Brinkhoff <lars.spam@nocrew.org> - 2016-09-24 20:19 +0200
Re: Given a string, create word with that name (in ANS Forth)? "Elizabeth D. Rather" <erather@forth.com> - 2016-09-24 09:47 -1000
Re: Given a string, create word with that name (in ANS Forth)? Paul Rubin <no.email@nospam.invalid> - 2016-09-24 14:29 -0700
Re: Given a string, create word with that name (in ANS Forth)? "Elizabeth D. Rather" <erather@forth.com> - 2016-09-24 13:00 -1000
Re: Given a string, create word with that name (in ANS Forth)? Paul Rubin <no.email@nospam.invalid> - 2016-09-24 16:19 -0700
Re: Given a string, create word with that name (in ANS Forth)? jim.brakefield@ieee.org - 2016-09-24 19:02 -0700
Re: Given a string, create word with that name (in ANS Forth)? "Elizabeth D. Rather" <erather@forth.com> - 2016-09-24 21:23 -1000
Re: Given a string, create word with that name (in ANS Forth)? hughaguilar96@gmail.com - 2016-09-25 19:08 -0700
Re: Given a string, create word with that name (in ANS Forth)? jim.brakefield@ieee.org - 2016-09-25 19:53 -0700
Re: Given a string, create word with that name (in ANS Forth)? hughaguilar96@gmail.com - 2016-09-25 20:00 -0700
Re: Given a string, create word with that name (in ANS Forth)? hughaguilar96@gmail.com - 2016-09-25 17:40 -0700
Re: Given a string, create word with that name (in ANS Forth)? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-25 01:42 -0500
Re: Given a string, create word with that name (in ANS Forth)? Paul Rubin <no.email@nospam.invalid> - 2016-09-24 23:45 -0700
Re: Given a string, create word with that name (in ANS Forth)? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-25 02:22 -0500
Re: Given a string, create word with that name (in ANS Forth)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-26 15:31 +0000
Re: Given a string, create word with that name (in ANS Forth)? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-26 10:42 -0500
Re: Given a string, create word with that name (in ANS Forth)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-27 15:57 +0000
Re: Given a string, create word with that name (in ANS Forth)? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-27 19:11 +0200
Re: Given a string, create word with that name (in ANS Forth)? "Elizabeth D. Rather" <erather@forth.com> - 2016-09-24 21:28 -1000
Re: Given a string, create word with that name (in ANS Forth)? hughaguilar96@gmail.com - 2016-09-25 18:55 -0700
Re: Given a string, create word with that name (in ANS Forth)? Lars Brinkhoff <lars.spam@nocrew.org> - 2016-09-25 09:35 +0200
Re: Given a string, create word with that name (in ANS Forth)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-26 15:38 +0000
Re: Given a string, create word with that name (in ANS Forth)? hughaguilar96@gmail.com - 2016-09-26 12:36 -0700
Re: Given a string, create word with that name (in ANS Forth)? Lars Brinkhoff <lars.spam@nocrew.org> - 2016-09-24 20:26 +0200
Re: Given a string, create word with that name (in ANS Forth)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-25 15:22 +0000
Re: Given a string, create word with that name (in ANS Forth)? Paul Rubin <no.email@nospam.invalid> - 2016-09-25 10:44 -0700
Re: Given a string, create word with that name (in ANS Forth)? Coos Haak <htrofhc@gmail.com> - 2016-09-25 19:55 +0200
Re: Given a string, create word with that name (in ANS Forth)? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-25 20:15 +0200
Re: Given a string, create word with that name (in ANS Forth)? Coos Haak <htrofhc@gmail.com> - 2016-09-25 20:26 +0200
Re: Given a string, create word with that name (in ANS Forth)? Paul Rubin <no.email@nospam.invalid> - 2016-09-25 11:12 -0700
Re: Given a string, create word with that name (in ANS Forth)? Julian Fondren <julian.fondren@gmail.com> - 2016-09-25 11:30 -0700
Re: Given a string, create word with that name (in ANS Forth)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-26 14:51 +0000
Re: Given a string, create word with that name (in ANS Forth)? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-27 14:16 +0200
Re: Given a string, create word with that name (in ANS Forth)? "Elizabeth D. Rather" <erather@forth.com> - 2016-09-23 07:52 -1000
Re: Given a string, create word with that name (in ANS Forth)? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-23 10:36 -0500
Re: Given a string, create word with that name (in ANS Forth)? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-12 13:55 +0200
Re: Given a string, create word with that name (in ANS Forth)? Lars Brinkhoff <lars.spam@nocrew.org> - 2016-09-12 15:01 +0200
Re: Given a string, create word with that name (in ANS Forth)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-12 17:29 +0000
Re: Given a string, create word with that name (in ANS Forth)? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-12 21:02 +0200
Re: Given a string, create word with that name (in ANS Forth)? Paul Rubin <no.email@nospam.invalid> - 2016-09-12 13:04 -0700
Re: Given a string, create word with that name (in ANS Forth)? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-12 22:33 +0200
Re: Given a string, create word with that name (in ANS Forth)? lawrencedo99@gmail.com - 2016-09-16 18:38 -0700
Re: Given a string, create word with that name (in ANS Forth)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-17 05:33 +0000
Re: Given a string, create word with that name (in ANS Forth)? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-17 01:40 -0500
Re: Given a string, create word with that name (in ANS Forth)? lawrencedo99@gmail.com - 2016-09-16 23:47 -0700
Re: Given a string, create word with that name (in ANS Forth)? Julian Fondren <julian.fondren@gmail.com> - 2016-09-17 00:08 -0700
Re: Given a string, create word with that name (in ANS Forth)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-17 17:03 +0000
Re: Given a string, create word with that name (in ANS Forth)? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-12 22:35 +0200
Re: Given a string, create word with that name (in ANS Forth)? Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-09-17 08:16 +0100
Re: Given a string, create word with that name (in ANS Forth)? Mark Wills <markwills1970@gmail.com> - 2016-09-12 02:49 -0700
Re: Given a string, create word with that name (in ANS Forth)? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-12 14:04 +0200
Re: Given a string, create word with that name (in ANS Forth)? Cecil Bayona <cbayona@cbayona.com> - 2016-09-12 09:34 -0500
Re: Given a string, create word with that name (in ANS Forth)? Mark Wills <markwills1970@gmail.com> - 2016-09-12 08:10 -0700
Re: Given a string, create word with that name (in ANS Forth)? Cecil Bayona <cbayona@cbayona.com> - 2016-09-12 12:02 -0500
Re: Given a string, create word with that name (in ANS Forth)? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-12 14:08 +0200
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-09-24 10:34 -0500 |
| Message-ID | <svqdnYT5RPmWAHvKnZ2dnUU7-c3NnZ2d@supernews.com> |
| In reply to | #51239 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>My take on it is that the dictionary is a very specific structure >>>>which is optimized for the job it does. It doesn't necessarily >>>>provide O(1) access, for example. >>> >>> So what? >> >>That was obvious from the context. >> >>> There are no performance guarantees anywhere in the Forth >> >>That was my point. That was obvious from the context. > > Which context? The context you deleted from the message to which I was replying. >>> Why should I use a system-specific interface? >> >>If the O(1) performance of a hash table is essential to your design, > > Where did you get the idea that it was essential? Note the "if" in the statement above. A hash table was mentioned, I think. >>then you'll have to use a hash table; the dictionary might be a linear >>search. > > If average-constant access performance is essential, there are several > options: > > 1) I can use the dictionary, and choose one of the Forth systems that > provide average-constant access performance for that. Of course. > Just because there may be a few systems that do not provide the > necessary performance yet, does not mean it is a good idea or even > recommended to use a system-specific interfaces, because that would > restrict usage of the program to that one system; then I would not > even notice that other Forth systems provide average-constant access > performance, maybe in a later version. Of course. > 2) If I want more performance portability, I can define the lookup > table myself in Forth, or use a library, e.g., the ffl. And in that > context a system-specific interface makes even less sense. Sure, but the system-specific interface *is* needed in the context where strings with embedded spaces are used as keys. (Having said that, the strings can be encoded in some way, so the dictionary could be used even then, but it would be inconvenient.) > So you put up a straw man that does not even support your case. The question which arose was to do with the usage of the dictionary as a general-purpose lookup table for arbitrary strings. The disadvantage of the dictionary for that purpose is that its performance varies widely and that it doesn't accept arbitrary strings. Some systems might well have fast dictionary lookup, and they might support arbitrary strings as an extension. In practice I suspect that the prorammer will know which system they are writing for and do whatever works best for that system. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2016-09-24 20:19 +0200 |
| Message-ID | <86twd5f9et.fsf@molnjunk.nocrew.org> |
| In reply to | #51241 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > A hash table was mentioned, I think. I mentioned "hash table", but now I'm sorry I did. I could have written "mapping" or "associative array" or something.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-09-24 09:47 -1000 |
| Message-ID | <9e2dncJAOdaoRXvKnZ2dnUU7-I_NnZ2d@supernews.com> |
| In reply to | #51244 |
On 9/24/16 8:19 AM, Lars Brinkhoff wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> A hash table was mentioned, I think. > > I mentioned "hash table", but now I'm sorry I did. I could have written > "mapping" or "associative array" or something. > The thing is, each of those application areas has its own needs. The dictionary is, itself, an application with certain needs, and complicating the dictionary to make a general-purpose facility will not benefit either Forth or any of those uses. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-09-24 14:29 -0700 |
| Message-ID | <87k2e19eaw.fsf@jester.gateway.pace.com> |
| In reply to | #51246 |
"Elizabeth D. Rather" <erather@forth.com> writes: >> "mapping" or "associative array" or something. > The thing is, each of those application areas has its own needs. The > dictionary is, itself, an application with certain needs, and > complicating the dictionary to make a general-purpose facility will > not benefit either Forth or any of those uses. Associative tables have shown themselves to be a very useful datatype in many other languages, and the implementation details are usually not that important. Forth uses one to implement dictionaries/wordlists, but its interface is very restricted. And if the application implements its own, but that means there are now two different implementations in the Forth running the app. If a general purpose table had been available from the beginning, the Forth dictionary would be able to use it, and the user app could use it too.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-09-24 13:00 -1000 |
| Message-ID | <0eadnZbYKYgVmHrKnZ2dnUU7-VPNnZ2d@supernews.com> |
| In reply to | #51250 |
On 9/24/16 11:29 AM, Paul Rubin wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >>> "mapping" or "associative array" or something. >> The thing is, each of those application areas has its own needs. The >> dictionary is, itself, an application with certain needs, and >> complicating the dictionary to make a general-purpose facility will >> not benefit either Forth or any of those uses. > > Associative tables have shown themselves to be a very useful datatype in > many other languages, and the implementation details are usually not > that important. Forth uses one to implement dictionaries/wordlists, but > its interface is very restricted. And if the application implements its > own, but that means there are now two different implementations in the > Forth running the app. > > If a general purpose table had been available from the beginning, the > Forth dictionary would be able to use it, and the user app could use it > too. > Well, it's been a basic principal of Forth since before I met Chuck (1971) that it's preferable to solve specific problems optimally than to attempt to define generalized structures that might or might not be optimal for a specific case. The dictionary is one example of this principal at work. You may not agree, and you're perfectly entitled to device a general purpose table and use it for your dictionary, but at this stage an attempt to force Forth into that mold is unlikely to be popular. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-09-24 16:19 -0700 |
| Message-ID | <87d1jsant2.fsf@jester.gateway.pace.com> |
| In reply to | #51253 |
"Elizabeth D. Rather" <erather@forth.com> writes: > it's preferable to solve specific problems optimally than > to attempt to define generalized structures that might or might not be > optimal for a specific case. If 3 similar problems arise in a program, is it more optimal to have 3 separate solutions that are almost but not quite all alike, or to have one solution that handles all 3 problems?
[toc] | [prev] | [next] | [standalone]
| From | jim.brakefield@ieee.org |
|---|---|
| Date | 2016-09-24 19:02 -0700 |
| Message-ID | <f199d064-433e-4894-b82a-5a6c3a76c40c@googlegroups.com> |
| In reply to | #51253 |
On Saturday, September 24, 2016 at 6:00:29 PM UTC-5, Elizabeth D. Rather wrote: > On 9/24/16 11:29 AM, Paul Rubin wrote: > > "Elizabeth D. Rather" <erather@forth.com> writes: > >>> "mapping" or "associative array" or something. > >> The thing is, each of those application areas has its own needs. The > >> dictionary is, itself, an application with certain needs, and > >> complicating the dictionary to make a general-purpose facility will > >> not benefit either Forth or any of those uses. > > > > Associative tables have shown themselves to be a very useful datatype in > > many other languages, and the implementation details are usually not > > that important. Forth uses one to implement dictionaries/wordlists, but > > its interface is very restricted. And if the application implements its > > own, but that means there are now two different implementations in the > > Forth running the app. > > > > If a general purpose table had been available from the beginning, the > > Forth dictionary would be able to use it, and the user app could use it > > too. > > > > Well, it's been a basic principal of Forth since before I met Chuck > (1971) that it's preferable to solve specific problems optimally than to > attempt to define generalized structures that might or might not be > optimal for a specific case. The dictionary is one example of this > principal at work. > > You may not agree, and you're perfectly entitled to device a general > purpose table and use it for your dictionary, but at this stage an > attempt to force Forth into that mold is unlikely to be popular. > > Cheers, > Elizabeth > > -- > ================================================== > Elizabeth D. Rather (US & Canada) 800-55-FORTH > FORTH Inc. +1 310.999.6784 > 5959 West Century Blvd. Suite 700 > Los Angeles, CA 90045 > http://www.forth.com > > "Forth-based products and Services for real-time > applications since 1973." > ================================================== ]> it's preferable to solve specific problems optimally than to ]> attempt to define generalized structures that might or might not be ]> optimal for a specific case. The dictionary is one example of this ]> principal at work In much of my scientific/research programming, made the decision that if it was in a factor of two in time efficiency, that was good enough: my time versus the computer's time. In this situation generalized solutions were more easily verified and held out greater chance of reuse. Many years later, the case of a interrupt handler for a Z80, needed to handle 24 distinct interrupts, each slightly different. A single piece of code would not meet timing due to the time it took to stuff all the bit fields. 24 separate routines, each with all the bit fields pre-stuffed easily met timing. Was using assembler, so wrote a large macro and called it 24 times. If using Forth, would have had Forth generate the code for the 24 routines. Am not sure what Chuck Moore considered optimal? And why are the Forth dictionary text stings not compressed to save space?
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-09-24 21:23 -1000 |
| Message-ID | <zsSdnVmEU6Tg5nrKnZ2dnUU7-UXNnZ2d@supernews.com> |
| In reply to | #51257 |
On 9/24/16 4:02 PM, jim.brakefield@ieee.org wrote: > ]> it's preferable to solve specific problems optimally than to > ]> attempt to define generalized structures that might or might not be > ]> optimal for a specific case. The dictionary is one example of this > ]> principal at work > > In much of my scientific/research programming, made the decision that if it was in a factor of two in time efficiency, that was good enough: my time versus the computer's time. In this situation generalized solutions were > more easily verified and held out greater chance of reuse. > > Many years later, the case of a interrupt handler for a Z80, needed to handle 24 distinct interrupts, each slightly different. A single piece of code would not meet timing due to the time it took to stuff all the bit fields. 24 separate routines, each with all the bit fields pre-stuffed easily met timing. Was using assembler, so wrote a large macro and called it 24 times. If using Forth, would have had Forth generate the code for the 24 routines. :-) > Am not sure what Chuck Moore considered optimal? No absolute answers, it depended on the particular situation what to optimize. > And why are the Forth dictionary text stings not compressed to save space? Interesting question. For many years Chuck's systems and those of FORTH, Inc. saved the count and first 3 characters of the name rather than the full name, to save space. This provided a level of uniqueness that was adequate most of the time. This persisted until Forth94, by which time memories were sufficient to hold whole names except in small embedded systems, which by that time were programmed with cross-compilers at FORTH, Inc. The standards require uniqueness for 32 characters. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-09-25 19:08 -0700 |
| Message-ID | <447ac89d-98a8-41cb-be97-d217516e47e5@googlegroups.com> |
| In reply to | #51265 |
On Sunday, September 25, 2016 at 12:23:46 AM UTC-7, Elizabeth D. Rather wrote: > On 9/24/16 4:02 PM, jim.brakefield@ieee.org wrote: > > And why are the Forth dictionary text stings not compressed to save space? > > Interesting question. For many years Chuck's systems and those of FORTH, > Inc. saved the count and first 3 characters of the name rather than the > full name, to save space. This provided a level of uniqueness that was > adequate most of the time. This persisted until Forth94, by which time > memories were sufficient to hold whole names except in small embedded > systems, which by that time were programmed with cross-compilers at > FORTH, Inc. The standards require uniqueness for 32 characters. That compression system of saving the count and the first 3 characters was only used at Forth Inc.. It was not adequate; there were a lot of clashes! Elizabeth Rather is projecting her own incompetance on to the entire Forth community --- she says that this goofy system, which was used only at Forth Inc., "persisted until Forth94" --- the implication is that the entire Forth community was unable to do anything that made sense until ANS-Forth came out in 1994. Anyway, I'm not aware of any Forth system that used data-compression on the 65c02 and Z80 systems --- this was due to those processors being too slow to support data-compression --- later on the MS-DOS machines came out, and they had enough memory that data-compression was not needed. UR/Forth stored the dictionary headers in a 64KB segment accessed with ES. I actually did run out of memory in the dictionary segment though --- this was in my 65c02 cross-compile --- this was because I was using the dictionary as an association to hold line-numbers for the symbolic-debugger to use.
[toc] | [prev] | [next] | [standalone]
| From | jim.brakefield@ieee.org |
|---|---|
| Date | 2016-09-25 19:53 -0700 |
| Message-ID | <f68302e9-47e9-4e3d-b51a-2e86e580183c@googlegroups.com> |
| In reply to | #51306 |
On Sunday, September 25, 2016 at 9:08:03 PM UTC-5, hughag...@gmail.com wrote: > On Sunday, September 25, 2016 at 12:23:46 AM UTC-7, Elizabeth D. Rather wrote: > > On 9/24/16 4:02 PM, jim.brakefield@ieee.org wrote: > > > And why are the Forth dictionary text stings not compressed to save space? > > > > Interesting question. For many years Chuck's systems and those of FORTH, > > Inc. saved the count and first 3 characters of the name rather than the > > full name, to save space. This provided a level of uniqueness that was > > adequate most of the time. This persisted until Forth94, by which time > > memories were sufficient to hold whole names except in small embedded > > systems, which by that time were programmed with cross-compilers at > > FORTH, Inc. The standards require uniqueness for 32 characters. > > That compression system of saving the count and the first 3 characters was only used at Forth Inc.. It was not adequate; there were a lot of clashes! Elizabeth Rather is projecting her own incompetance on to the entire Forth community --- she says that this goofy system, which was used only at Forth Inc., "persisted until Forth94" --- the implication is that the entire Forth community was unable to do anything that made sense until ANS-Forth came out in 1994. > > Anyway, I'm not aware of any Forth system that used data-compression on the 65c02 and Z80 systems --- this was due to those processors being too slow to support data-compression --- later on the MS-DOS machines came out, and they had enough memory that data-compression was not needed. > > UR/Forth stored the dictionary headers in a 64KB segment accessed with ES. I actually did run out of memory in the dictionary segment though --- this was in my 65c02 cross-compile --- this was because I was using the dictionary as an association to hold line-numbers for the symbolic-debugger to use. ]>due to those processors (65c02 & Z80) being too slow to support data-compression ?? There are plenty of adhoc compression schemes that will save 20-30% over 8-bit ASCII, and that are reasonably fast.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-09-25 20:00 -0700 |
| Message-ID | <ec3c3c04-be25-45a7-9f8a-328d6815b3eb@googlegroups.com> |
| In reply to | #51308 |
On Sunday, September 25, 2016 at 7:53:15 PM UTC-7, jim.bra...@ieee.org wrote: > On Sunday, September 25, 2016 at 9:08:03 PM UTC-5, hughag...@gmail.com wrote: > ]>due to those processors (65c02 & Z80) being too slow to support data-compression > > ?? > There are plenty of adhoc compression schemes that will save 20-30% over 8-bit ASCII, and that are reasonably fast. Maybe so --- I'm not an expert on data-compression --- I don't really know what is available. The only data-compression algorithm I'm familiar with is Huffman Encoding --- I doubt that it would have been fast enough on those old processors. Anyway, it is a moot point now because memory is no longer an issue.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-09-25 17:40 -0700 |
| Message-ID | <8499c868-9dcf-47aa-989c-a6f27c7cb192@googlegroups.com> |
| In reply to | #51253 |
On Saturday, September 24, 2016 at 4:00:29 PM UTC-7, Elizabeth D. Rather wrote: > Well, it's been a basic principal of Forth since before I met Chuck > (1971) that it's preferable to solve specific problems optimally than to > attempt to define generalized structures that might or might not be > optimal for a specific case. This is a great quote! I think this really shows who Elizabeth Rather is entirely informed about computer-science by her experience as a COBOL programmer in the 1970s.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-09-25 01:42 -0500 |
| Message-ID | <gfKdncpZpK1D7HrKnZ2dnUU7-WGdnZ2d@supernews.com> |
| In reply to | #51250 |
Paul Rubin <no.email@nospam.invalid> wrote: > If a general purpose table had been available from the beginning, the > Forth dictionary would be able to use it, and the user app could use it > too. Perhaps so, but the system might not then have fit in the tiny space available on small computers. Every byte was valuable, and every byte occupied by the Forth system was a byte that couldn't be used by the application programmer. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-09-24 23:45 -0700 |
| Message-ID | <874m54a34z.fsf@jester.gateway.pace.com> |
| In reply to | #51262 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > Perhaps so, but the system might not then have fit in the tiny space > available on small computers. Every byte was valuable, and every byte > occupied by the Forth system was a byte that couldn't be used by the > application programmer. The really tiny systems might not have supported word lists, which is about where generality starts making sense. But, as someone mentioned, Forth dictionary implementations generally had the general interfaces as internal factors even if they weren't exposed to the user. So it starts to sound like burying a tool.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-09-25 02:22 -0500 |
| Message-ID | <Q4qdnQqQe7jQ5nrKnZ2dnUU7-N3NnZ2d@supernews.com> |
| In reply to | #51263 |
Paul Rubin <no.email@nospam.invalid> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> Perhaps so, but the system might not then have fit in the tiny space >> available on small computers. Every byte was valuable, and every byte >> occupied by the Forth system was a byte that couldn't be used by the >> application programmer. > > The really tiny systems might not have supported word lists, which is > about where generality starts making sense. I'm sure they all had vocabularies. They at least had to have EDITOR and ASSEMBLER. > But, as someone mentioned, Forth dictionary implementations > generally had the general interfaces as internal factors even if > they weren't exposed to the user. Not always. Some small systems I know about have very tightly- integrated interpreter and compiler, for example. WORD copies a name from the input stream to a small offset from HERE, so CREATE has only to fill in a link field and a code field and it's done. It's a tiny simplification, but all those tiny simplifications add up. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-09-26 15:31 +0000 |
| Message-ID | <2016Sep26.173117@mips.complang.tuwien.ac.at> |
| In reply to | #51264 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Some small systems I know about have very tightly-
>integrated interpreter and compiler, for example. WORD copies a name
>from the input stream to a small offset from HERE, so CREATE has only
>to fill in a link field and a code field and it's done. It's a tiny
>simplification, but all those tiny simplifications add up.
On the contrary, it's a complication. Instead of copying the name
only when defining a new word, this scheme always copies the name; and
in order to make use of it, you have to have the name field first in a
word, and the link field afterwards, leading to the complication and
slowness of TRAVERSE in fig-Forth (the option of having either full
names or shortened names also played a role in that complication).
You can get rid of all these complications by using PARSE-NAME instead
of WORD and copying the name on header definition.
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-09-26 10:42 -0500 |
| Message-ID | <DvidnS9p18R83HTKnZ2dnUU7-SGdnZ2d@supernews.com> |
| In reply to | #51334 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Some small systems I know about have very tightly- >>integrated interpreter and compiler, for example. WORD copies a name >>from the input stream to a small offset from HERE, so CREATE has only >>to fill in a link field and a code field and it's done. It's a tiny >>simplification, but all those tiny simplifications add up. > > On the contrary, it's a complication. Instead of copying the name > only when defining a new word, this scheme always copies the name; > and in order to make use of it, you have to have the name field > first in a word, and the link field afterwards, leading to the > complication and slowness of TRAVERSE in fig-Forth (the option of > having either full names or shortened names also played a role in > that complication). No you don't. You can have the link field first. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-09-27 15:57 +0000 |
| Message-ID | <2016Sep27.175711@mips.complang.tuwien.ac.at> |
| In reply to | #51336 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Some small systems I know about have very tightly-
>>>integrated interpreter and compiler, for example. WORD copies a name
>>>from the input stream to a small offset from HERE, so CREATE has only
>>>to fill in a link field and a code field and it's done. It's a tiny
>>>simplification, but all those tiny simplifications add up.
>>
>> On the contrary, it's a complication. Instead of copying the name
>> only when defining a new word, this scheme always copies the name;
>> and in order to make use of it, you have to have the name field
>> first in a word, and the link field afterwards, leading to the
>> complication and slowness of TRAVERSE in fig-Forth (the option of
>> having either full names or shortened names also played a role in
>> that complication).
>
>No you don't. You can have the link field first.
Judging from your "small offset from HERE" phrase above, I guess that
you are implying that they could have had the name, say 2 bytes after
HERE, and put the link field at HERE.
However, an offset<>0 is contrary to established Forth practice to
this day (in Gforth, SwiftForth, and VFX WORD puts the string HERE,
not elsewhere). And that was certainly more important for fig-Forth,
because in fig-Forth (and probably other Forth systems of the day)
WORD has the stack effect ( c -- ), and a typical phrase for using
WORD is
bl word here count ...
So if they did not put the string at HERE, the programs would not
work.
Looking at the dump of a definition, I find that SwiftForth does
indeed have the name where WORD puts it (I don't know if it uses WORD
for that, though), VFX puts the name elsewhere (6 bytes further in my
experiment). Gforth (which uses PARSE-NAME anyway) uses a count cell
and puts the name 16 bytes after the old here in 0.7.0, and (for my
experiment) 13 byes after the old name, followed by the count cell in
the current development version.
I also looked WORD up in "All about Forth", and the two
implementations given in Forth (fig-Forth and F83) both first scanned
the whole string, and then copied it; so it's not as if the copying
came for free.
Overall, the copying of the string by WORD is just a bad idea, that
led to complications. It may have been not so bad in the original
system, but it's definitely not an example of good design.
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2016-09-27 19:11 +0200 |
| Message-ID | <nse98s$4ic$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #51392 |
In article <2016Sep27.175711@mips.complang.tuwien.ac.at>, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > >Overall, the copying of the string by WORD is just a bad idea, that >led to complications. It may have been not so bad in the original >system, but it's definitely not an example of good design. With PARSE and PARSE-NAME we can make WORD obsolescent. WORD is not needed in a kernel any more. In ciforth it is made a loadable extension. > >- anton 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 | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-09-24 21:28 -1000 |
| Message-ID | <h8OdnSbcXIUm4XrKnZ2dnUU7-bnNnZ2d@supernews.com> |
| In reply to | #51263 |
On 9/24/16 8:45 PM, Paul Rubin wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> Perhaps so, but the system might not then have fit in the tiny space >> available on small computers. Every byte was valuable, and every byte >> occupied by the Forth system was a byte that couldn't be used by the >> application programmer. > > The really tiny systems might not have supported word lists, which is > about where generality starts making sense. But, as someone mentioned, > Forth dictionary implementations generally had the general interfaces as > internal factors even if they weren't exposed to the user. So it starts > to sound like burying a tool. Word lists (aka vocabularies) were first used in 1972, on a computer with 64K bytes of memory. Word lists are not memory hogs, although names were stored as count+first 3 chars. And, in Chuck's (and FORTH, Inc.) systems, these factors were always exposed. Chuck never buried anything. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | comp.lang.forth
csiph-web