Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #52599 > unrolled thread
| Started by | polymorph self <jackvanc3@gmail.com> |
|---|---|
| First post | 2016-11-13 18:33 -0800 |
| Last post | 2016-11-29 13:58 -0500 |
| Articles | 20 on this page of 129 — 26 participants |
Back to article view | Back to comp.lang.forth
Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-11-13 18:33 -0800
Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-13 23:02 -0500
Re: Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-11-14 16:59 -0800
Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-14 22:27 -0500
Re: Are stack machines inherently faster? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-11-17 06:26 -0800
Re: Are stack machines inherently faster? foxaudioresearch@gmail.com - 2016-11-17 08:08 -0800
Re: Are stack machines inherently faster? mhx@iae.nl - 2016-11-17 10:52 -0800
Re: Are stack machines inherently faster? "Elizabeth D. Rather" <erather@forth.com> - 2016-11-17 09:57 -1000
Re: Are stack machines inherently faster? Paul Rubin <no.email@nospam.invalid> - 2016-11-17 15:58 -0800
Re: Are stack machines inherently faster? foxaudioresearch@gmail.com - 2016-11-17 16:29 -0800
Re: Are stack machines inherently faster? john <anon@example.com> - 2016-11-18 08:26 +0000
Re: Are stack machines inherently faster? stephen@mpeforth.com (Stephen Pelc) - 2016-11-18 11:17 +0000
Re: Are stack machines inherently faster? foxaudioresearch@gmail.com - 2016-11-18 06:37 -0800
Re: Are stack machines inherently faster? stephen@mpeforth.com (Stephen Pelc) - 2016-11-18 15:30 +0000
Re: Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-11-27 00:25 -0800
Re: Are stack machines inherently faster? Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-11-27 05:08 -0500
Re: Are stack machines inherently faster? "Elizabeth D. Rather" <erather@forth.com> - 2016-11-27 15:12 -1000
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-27 21:06 -0800
Re: Are stack machines inherently faster? john <anon@example.com> - 2016-11-28 12:20 +0000
Re: Are stack machines inherently faster? Alex <alex@rivadpm.com> - 2016-11-28 13:43 +0000
Re: Are stack machines inherently faster? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-28 08:52 -0600
Re: Are stack machines inherently faster? Alex <alex@rivadpm.com> - 2016-11-28 17:19 +0000
Re: Are stack machines inherently faster? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-28 11:58 -0600
Re: Are stack machines inherently faster? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-28 20:39 +0100
Re: Are stack machines inherently faster? john <anon@example.com> - 2016-11-28 21:56 +0000
Re: Are stack machines inherently faster? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-28 23:22 +0100
Re: Are stack machines inherently faster? john <anon@example.com> - 2016-11-29 11:06 +0000
Re: Are stack machines inherently faster? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-29 09:44 -0600
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-12-02 13:07 -0800
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-28 19:37 -0800
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-28 19:02 -0800
Re: Are stack machines inherently faster? Alex <alex@rivadpm.com> - 2016-11-29 14:41 +0000
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-29 21:32 -0800
Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-29 12:43 -0500
Re: Are stack machines inherently faster? Alex <alex@rivadpm.com> - 2016-11-29 18:38 +0000
Re: Are stack machines inherently faster? Brad Eckert <hwfwguy@gmail.com> - 2016-11-29 13:57 -0800
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-12-02 16:50 -0800
Re: Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-12-01 00:19 -0800
Re: Are stack machines inherently faster? mhx@iae.nl - 2016-11-18 10:58 -0800
Re: Are stack machines inherently faster? "HAA" <someone@microsoft.com> - 2016-11-19 11:29 +1100
Re: Are stack machines inherently faster? "Elizabeth D. Rather" <erather@forth.com> - 2016-11-18 18:18 -1000
Re: Are stack machines inherently faster? Paul Rubin <no.email@nospam.invalid> - 2016-11-19 00:31 -0800
Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-20 14:02 +0000
Re: Are stack machines inherently faster? Paul Rubin <no.email@nospam.invalid> - 2016-11-20 23:16 -0800
Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-22 09:51 +0000
Re: Are stack machines inherently faster? Brad Eckert <hwfwguy@gmail.com> - 2016-11-24 14:16 -0800
Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-25 15:26 +0000
Re: Are stack machines inherently faster? stephen@mpeforth.com (Stephen Pelc) - 2016-11-19 17:42 +0000
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-21 14:26 -0800
Re: Are stack machines inherently faster? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-11-22 10:38 +0000
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-24 12:46 -0800
Re: Are stack machines inherently faster? Cecil Bayona <cbayona@cbayona.com> - 2016-11-24 15:15 -0600
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-24 14:30 -0800
Re: Are stack machines inherently faster? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-11-25 05:37 -0800
Re: Are stack machines inherently faster? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-25 09:58 -0600
Re: Are stack machines inherently faster? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-11-26 10:39 -0800
Re: Are stack machines inherently faster? Cecil Bayona <cbayona@cbayona.com> - 2016-11-25 12:26 -0600
Re: Are stack machines inherently faster? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-11-26 10:57 -0800
Re: Are stack machines inherently faster? Cecil Bayona <cbayona@cbayona.com> - 2016-11-26 13:40 -0600
Re: Are stack machines inherently faster? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-12-01 05:35 -0800
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-12-01 18:38 -0800
Re: Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-12-01 21:52 -0800
Re: Are stack machines inherently faster? Ron Aaron <rambamist@gmail.com> - 2016-12-02 08:45 +0200
Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-02 08:50 +0000
Re: Are stack machines inherently faster? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-02 10:34 +0100
Re: Are stack machines inherently faster? john <anon@example.com> - 2016-12-02 10:20 +0000
Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-02 10:04 +0000
Re: Are stack machines inherently faster? Ron Aaron <rambamist@gmail.com> - 2016-12-02 11:59 +0200
Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-02 10:44 +0000
Re: Are stack machines inherently faster? Ron Aaron <rambamist@gmail.com> - 2016-12-02 13:23 +0200
Re: Are stack machines inherently faster? Lars Brinkhoff <lars.spam@nocrew.org> - 2016-12-02 15:12 +0100
Re: Are stack machines inherently faster? Ron Aaron <rambamist@gmail.com> - 2016-12-03 17:35 +0200
Re: Are stack machines inherently faster? Lars Brinkhoff <lars.spam@nocrew.org> - 2017-01-09 10:31 +0100
Re: Are stack machines inherently faster? Ron Aaron <rambamist@gmail.com> - 2017-01-09 12:01 +0200
Re: Are stack machines inherently faster? Lars Brinkhoff <lars.spam@nocrew.org> - 2017-01-09 13:53 +0100
Re: Are stack machines inherently faster? Ron Aaron <rambamist@gmail.com> - 2017-01-09 14:59 +0200
Re: Are stack machines inherently faster? minforth@arcor.de - 2017-01-09 08:15 -0800
Re: Are stack machines inherently faster? Lars Brinkhoff <lars.spam@nocrew.org> - 2017-01-09 19:33 +0100
Re: Are stack machines inherently faster? Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-12-03 01:58 -0500
Re: Are stack machines inherently faster? "Elizabeth D. Rather" <erather@forth.com> - 2016-12-02 21:09 -1000
Re: Are stack machines inherently faster? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-03 13:01 +0100
Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-04 14:51 +0000
Re: Are stack machines inherently faster? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-12-02 04:28 -0800
Re: Are stack machines inherently faster? stephen@mpeforth.com (Stephen Pelc) - 2016-11-25 16:10 +0000
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-25 16:51 -0800
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-26 15:09 -0800
Re: Are stack machines inherently faster? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-26 13:03 +0100
Re: Are stack machines inherently faster? franck.bensusan@gmail.com - 2016-11-27 10:11 -0800
Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-25 16:00 +0000
Re: Are stack machines inherently faster? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-11-24 22:44 +0000
Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-24 23:11 +0000
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-24 16:38 -0800
Re: Are stack machines inherently faster? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-11-25 07:28 +0000
Re: Are stack machines inherently faster? foxaudioresearch@gmail.com - 2016-11-25 04:24 -0800
Re: Are stack machines inherently faster? Alex <alex@rivadpm.com> - 2016-11-25 14:37 +0000
Re: Are stack machines inherently faster? foxaudioresearch@gmail.com - 2016-11-26 10:54 -0800
Re: Are stack machines inherently faster? luser droog <mijoryx@yahoo.com> - 2016-11-27 10:56 -0800
Re: Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-11-27 00:27 -0800
Re: Are stack machines inherently faster? luser droog <mijoryx@yahoo.com> - 2016-11-27 11:42 -0800
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-21 14:35 -0800
Re: Are stack machines inherently faster? "HAA" <someone@microsoft.com> - 2016-11-22 17:43 +1100
Re: Are stack machines inherently faster? john <anon@example.com> - 2016-11-22 12:51 +0000
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-24 13:30 -0800
Re: Are stack machines inherently faster? Paul Rubin <no.email@nospam.invalid> - 2016-11-18 20:27 -0800
Re: Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-11-27 00:23 -0800
Re: Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-11-27 00:22 -0800
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-11-17 12:50 -0800
Re: Are stack machines inherently faster? polymorph self <jackvanc3@gmail.com> - 2016-11-27 00:22 -0800
Re: Are stack machines inherently faster? Manuel Rodriguez <aa5@gmx.net> - 2016-11-28 11:00 -0800
Re: Are stack machines inherently faster? Walter Banks <walter@bytecraft.com> - 2016-11-28 16:10 -0500
Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-29 13:58 -0500
Re: Are stack machines inherently faster? Cecil Bayona <cbayona@cbayona.com> - 2016-11-30 00:46 -0600
Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-30 02:01 -0500
Re: Are stack machines inherently faster? Walter Banks <walter@bytecraft.com> - 2016-12-01 13:01 -0500
Re: Are stack machines inherently faster? hughaguilar96@gmail.com - 2016-12-03 17:15 -0800
Re: Are stack machines inherently faster? Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-12-04 02:29 -0500
Re: Are stack machines inherently faster? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-04 03:41 -0600
Re: Are stack machines inherently faster? Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-12-04 10:10 -0500
Re: Are stack machines inherently faster? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-04 17:16 +0000
Re: Are stack machines inherently faster? Paul Rubin <no.email@nospam.invalid> - 2016-11-28 13:33 -0800
Re: Are stack machines inherently faster? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-28 23:17 +0100
Re: Are stack machines inherently faster? Brad Eckert <hwfwguy@gmail.com> - 2016-11-29 09:17 -0800
Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-29 14:46 -0500
Re: Are stack machines inherently faster? Brad Eckert <hwfwguy@gmail.com> - 2016-11-29 13:44 -0800
Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-29 18:39 -0500
Re: Are stack machines inherently faster? Brad Eckert <hwfwguy@gmail.com> - 2016-11-30 15:00 -0800
Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-30 18:42 -0500
Re: Are stack machines inherently faster? "Elizabeth D. Rather" <erather@forth.com> - 2016-11-30 14:26 -1000
Re: Are stack machines inherently faster? rickman <gnuarm@gmail.com> - 2016-11-29 13:58 -0500
Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2016-12-03 13:01 +0100 |
| Message-ID | <o1uc79$dpc$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #53058 |
In article <tuednS4Dc7cH8t_FnZ2dnUU7-cnNnZ2d@supernews.com>, Elizabeth D. Rather <erather@forth.com> wrote: >On 12/2/16 8:58 PM, Rod Pemberton wrote: >>> Then one would have to write all the applications in Forth. >> What's wrong with translation of C code? e.g., C2Forth etc. It would >> require far less time to convert C code to Forth than to write Forth >> code from scratch. Many translated programs wouldn't need any further >> work, i.e., low-use or no need for major improvements. Only a few >> programs would likely need to be coded in Forth from nothing. This >> would likely either be for efficiency or code maintainability. > >That is actually something that has been done a number of times (at >least 10 in my direct personal experience), in real world projects. In >fact, it's quite a lot faster to write original Forth from scratch, >using the C version as a specification. You have to use that spec for >*what* is being done, rather than *how*, because the economics of Forth >are so very different: like building with steel and concrete instead of >bricks requires very different strategies. A direct translation of C >would be hideously inefficient and unmaintainable. A re-implemented >version can work fine. The major issue is more convincing management >rather than technical issues. The builder of noforth (Willem Ouwerkerk) complains that specs for microcontrollers are hard to come by, or unclear. He spends a large part of his time studying c-code, because most vendors supply working c-libraries. He doesn't consider direct translations from c neither. > >Cheers, >Elizabeth 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-12-04 14:51 +0000 |
| Message-ID | <2016Dec4.155142@mips.complang.tuwien.ac.at> |
| In reply to | #53057 |
Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> writes:
>On Fri, 02 Dec 2016 10:44:21 GMT
>anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>
>> Concerning the software, there is the myth and dream of a pure Forth
>> software base that consumes much less resources.
>
>Even if that Forth dream of fewer resources was true, which I doubt,
>transformative technologies can't simply be equivalent, or marginally
>superior, or be a substitute good. They must be radically superior in
>order to displace the "good enough" solution that's currently in use.
>
>Also, in the time that is needed to implement such a system, existing
>microprocessors will double in speed, perhaps multiple times. So, the
>real goal becomes designing a Forth processor and computer that is
>perhaps 3200% faster than what exists today just to match the growth of
>existing processors 5 years in the future.
Even in the glory days of Dennard scaling, we did not get 3200% in 5
years (e.g., from a P54CS (1995) to an Athlon 800 (2000) we got a
speedup by a factor 10.6 on our LaTeX benchmark
<https://www.complang.tuwien.ac.at/franz/latex-bench>). Since that
has stopped, single-core speeds have improved very slowly. E.g., an
upgrade from a 2008 Core 2 Duo E8400 to a 2016 Core i7-6700K gives a
speedup by a factor 2.4 when running LaTeX.
And anyway, software written in Forth will profit from the hardware
improvements just as any other software.
If you are thinking of Forth-based hardware, I have my doubts that it
will provide a significant benefit, except maybe in the extreme
low-power area; and if we can write useful software with huge number
of threads (each consuming little memory bandwidth), maybe the small
size of a stack-based core can help produce a useful many-core CPU;
but the GA144 is too limited for that.
>What's wrong with translation of C code? e.g., C2Forth etc.
It will not consume fewer resources. Also, another important element
in the dream of a pure Forth software base is the purity, and that
would be missing in that scenario.
Such a compiler would help creating a wider market for Forth hardware,
though.
- 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 | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2016-12-02 04:28 -0800 |
| Message-ID | <a6b31e6e-9c8f-421c-99d1-ebf478e86ff1@googlegroups.com> |
| In reply to | #53027 |
> > If you think ... evil siberian bear forcing me to drink vodka you are probably wrong. > > Probably wrong? Does that mean that there is a probability less than 0.5 that an evil siberian bear is forcing you to drink vodka? What is a probability to meet dinosaur? 0.5 - to meet or not to meet :) At least I have vodka and bears in ~50km radius so nothing is impossible... > For a long time, I thought of Forth as being an over-grown macro-assembler. There was no issue of "switching to assembler" --- writing code in assembly was the focus throughout. Forth as an extended macroassembler for abstract stack processor is a strong enough point. When programmers step from this point too far, they facing problems like 'no IDE, low performance, poor libraries support' etc. Improving performance is an infinite process, so why don't return to area where Forth is strong?
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2016-11-25 16:10 +0000 |
| Message-ID | <58385882.1339518247@news.eternal-september.org> |
| In reply to | #52848 |
On Thu, 24 Nov 2016 15:15:53 -0600, Cecil Bayona <cbayona@cbayona.com> wrote: >Pardon my ignorance but in what way does ANSI Forth create slow code by >using CREATE DOES ? Hugh's folderol of beliefs and assumptions leads him to assume that children of CREATE ... DOES> are slow ... because a fetch has to be performed for some data, e.g. when defining a CONSTANT. : constant create , does> @ ; \ x -- ; -- x The fault is not that of CREATE ... DOES> but of the lack of memory address qualifiers. In other languages, qualifiers such as const and volatile give the compiler hints or instructions about memory. The problem is actually easier for cross compilers which already describe memory type. However, since cross compilers treat Flash as writable, when can a read from Flash be considered as reading a constant? On desktops, all application memory is RAM, so how to tell Forth when it is read-only. If anyone was actually to try such a system in Forth, Hugh would then complain that the notation was not part of the now obsolete ANS Forth standard. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-11-25 16:51 -0800 |
| Message-ID | <34b59304-8b06-44b3-81e7-f09fa275851d@googlegroups.com> |
| In reply to | #52871 |
On Friday, November 25, 2016 at 9:10:00 AM UTC-7, Stephen Pelc wrote: > On Thu, 24 Nov 2016 15:15:53 -0600, Cecil Bayona <cbayona@cbayona.com> > wrote: > > >Pardon my ignorance but in what way does ANSI Forth create slow code by > >using CREATE DOES ? > > Hugh's folderol of beliefs and assumptions leads him to assume that > children of CREATE ... DOES> are slow ... because a fetch has to be > performed for some data, e.g. when defining a CONSTANT. > > : constant create , does> @ ; \ x -- ; -- x I had to look up "folderol" --- you are confusing me with big words --- the definition is: "trivial or nonsensical fuss." That isn't true. Memory access kills the speed. > The fault is not that of CREATE ... DOES> but of the lack of > memory address qualifiers. In other languages, qualifiers such > as const and volatile give the compiler hints or instructions > about memory. The only language I'm aware of that has compile-time declarations such as CONST and VOLATILE is C. > If anyone was actually to try such a system in Forth, Hugh would > then complain that the notation was not part of the now obsolete > ANS Forth standard. Forth-200x is mandated to be 100% compatible with Elizabeth Rather's toy language. Anyway, another problem with CREATE DOES> is that there is only one action associated with the data. To get other actions you need to use >BODY to obtain the base address, which the DOES> code gets automatically. Yet another problem is that CREATE builds the struct in the dictionary at compile-time --- you almost always need to build structs in the heap at run-time --- CREATE DOES> is only useful in programs, such as assemblers, when all the data (in the case of an assembler, all the opcodes) are known at compile-time and speed isn't an issue (because all of these constants will be fetched from memory at run-time rather than get compiled into the code as literals). All in all, CREATE DOES> is a very crude kind of OOP --- I already posted code for an OOP system that does everything that CREATE DOES> can do and a lot more, and does it more efficiently (also, more efficiently than Bernd Paysan's MiniOOF that relies on CREATE DOES> internally) --- CREATE DOES> is a product of the 1970s when Charles Moore first invented Forth.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-11-26 15:09 -0800 |
| Message-ID | <8e7aa360-b582-4681-b371-1cb4294ea5bf@googlegroups.com> |
| In reply to | #52875 |
On Friday, November 25, 2016 at 5:51:13 PM UTC-7, hughag...@gmail.com wrote: > Anyway, another problem with CREATE DOES> is that there is only one action associated with the data. To get other actions you need to use >BODY to obtain the base address, which the DOES> code gets automatically. > > Yet another problem is that CREATE builds the struct in the dictionary at compile-time --- you almost always need to build structs in the heap at run-time --- CREATE DOES> is only useful in programs, such as assemblers, when all the data (in the case of an assembler, all the opcodes) are known at compile-time and speed isn't an issue (because all of these constants will be fetched from memory at run-time rather than get compiled into the code as literals). I think CREATE DOES> was invented solely for supporting arrays. Arrays are the only data-structure described in "Starting Forth." Arrays are usually defined at compile-time because the size is known at compile-time --- also, arrays can't easily change size anyway, so putting them in the heap is pretty much pointless. Elizabeth Rather says: -------------------------------------------------------------------------- Virtually every Forth application needs some kind of array structures. The reason that some general-purpose one might be "little used" is because it's so easy to make a version that does *exactly* what the application needs rather than some generic definition. ... The objective is to master the toolset and be able to think clearly about exactly what kind of arrays will be useful in your application and then build exactly that kind. -------------------------------------------------------------------------- I almost never use arrays. I use LIST.4TH or ASSOCIATION.4TH, both of which allow insertion and deletion of nodes. Both of these use the heap, so they can't be defined with CREATE DOES> which uses ALLOT to provide memory for the data-structure. I very much doubt that Elizabeth Rather knows how to implement any data-structure other than the array, or even knows that there are other data-structures. All of this discussion of CREATE DOES> seems like nonsense to me --- this is 1970s technology! I might put <BUILDS DOES> in Straight Forth --- I might discard it as cruft though (I already discarded DO loops) --- as a practical matter, porting ANS-Forth programs over to Straight Forth isn't very important, because there aren't any ANS-Forth programs. > All in all, CREATE DOES> is a very crude kind of OOP --- I already posted code for an OOP system that does everything that CREATE DOES> can do and a lot more, and does it more efficiently (also, more efficiently than Bernd Paysan's MiniOOF that relies on CREATE DOES> internally) --- CREATE DOES> is a product of the 1970s when Charles Moore first invented Forth. This OOP system should work well for almost all programs.
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2016-11-26 13:03 +0100 |
| Message-ID | <o1btm0$a6s$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #52871 |
In article <58385882.1339518247@news.eternal-september.org>, Stephen Pelc <stephen@mpeforth.com> wrote: >On Thu, 24 Nov 2016 15:15:53 -0600, Cecil Bayona <cbayona@cbayona.com> >wrote: > >>Pardon my ignorance but in what way does ANSI Forth create slow code by >>using CREATE DOES ? > >Hugh's folderol of beliefs and assumptions leads him to assume that >children of CREATE ... DOES> are slow ... because a fetch has to be >performed for some data, e.g. when defining a CONSTANT. > >: constant create , does> @ ; \ x -- ; -- x > >The fault is not that of CREATE ... DOES> but of the lack of >memory address qualifiers. In other languages, qualifiers such >as const and volatile give the compiler hints or instructions >about memory. > >The problem is actually easier for cross compilers which already >describe memory type. However, since cross compilers treat Flash as >writable, when can a read from Flash be considered as reading a >constant? > >On desktops, all application memory is RAM, so how to tell Forth >when it is read-only. > >If anyone was actually to try such a system in Forth, Hugh would >then complain that the notation was not part of the now obsolete >ANS Forth standard. In my experimental optimiser I have an analyser that finds out all properties of all words (with some manual help). This may be different from the usual ways. There is no automatic optimisation, you have to ask for it. Emphasis is knowledge about words, not the compilation process. The stack effect is indicated by coloring of the first and last char's. 12 CONSTANT AAP LATEST ID. AAP ( the first A and last P are purple: stack unknown.) FILL-ALL ( Add information, based on existing information) LATEST ID. AAP ( A's are white, P is aqua : nothing in,one out) Other flags remember that AAP is a compile time constant. : test AAP 3 * ; SEE test : test AAP 0000,0003 * ; test 'test OPTIMISE See AAP : test 0000,0024 ; > >Stephen 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 | franck.bensusan@gmail.com |
|---|---|
| Date | 2016-11-27 10:11 -0800 |
| Message-ID | <4386209c-fe46-4a60-af20-514bae3b95b9@googlegroups.com> |
| In reply to | #52876 |
Le samedi 26 novembre 2016 12:52:39 UTC+1, Albert van der Horst a écrit : > > In my experimental optimiser I have an analyser that finds out all > properties of all words (with some manual help). > This may be different from the usual ways. There is no automatic > optimisation, you have to ask for it. Emphasis is knowledge about > words, not the compilation process. > The stack effect is indicated by coloring of the first and last > char's. > > 12 CONSTANT AAP > LATEST ID. > AAP ( the first A and last P are purple: stack unknown.) > > FILL-ALL ( Add information, based on existing information) > LATEST ID. > AAP ( A's are white, P is aqua : nothing in,one out) > > Other flags remember that AAP is a compile time constant. > : test AAP 3 * ; > SEE test > : test > AAP 0000,0003 * > ; > test > > 'test OPTIMISE > See AAP > : test > 0000,0024 > ; > > > 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 Oforth, a word in the dictionary is an object, and, as all objects, has a type. The #interpret method is polymorphic and declared for each word type. It is called by the outer interpreter if FIND retrieves a word from the dictionary. For constants objects, #interpret adds its value as literal to the current definition. For instance (version in current development) 8 const: A ok #A dup value .s [1] (Integer) 8 [2] (Constant) A ok : test A 5 A ; ok #test see c7:47:fc: 8 : 0 : mov c0000008, -4(edi) c7:47:f8: 8 : 7 : mov c0000005, -8(edi) c7:47:f4: 8 : E : mov c0000008, -12(edi) 83:ef: c:c3 : 15 : sub c, edi c3: 0: 0: 0 : 18 : ret ok Franck http://www.oforth.com
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-11-25 16:00 +0000 |
| Message-ID | <2016Nov25.170039@mips.complang.tuwien.ac.at> |
| In reply to | #52848 |
Cecil Bayona <cbayona@cbayona.com> writes:
>Pardon my ignorance but in what way does ANSI Forth create slow code by
>using CREATE DOES ?
: field1 ( n "name" -- )
create ,
does> ( n1 -- n2 )
@ + ;
here .
5 field1 foo1
here .
: bar1 foo1 @ ;
: field2 ( n "name" -- )
>r : r> postpone literal postpone + postpone ; ;
here .
5 field2 foo2
here .
: bar2 foo2 @ ;
On VFX this produces:
BAR1
( 080C0930 031D10090C08 ) ADD EBX, [080C0910]
( 080C0936 8B1B ) MOV EBX, 0 [EBX]
( 080C0938 C3 ) NEXT,
( 9 bytes, 3 instructions )
BAR2
( 080C09D0 8B5B05 ) MOV EBX, [EBX+05]
( 080C09D3 C3 ) NEXT,
( 4 bytes, 2 instructions )
And that's not a failure of VFX (here it does as well as possible),
it's due to the way CREATE..DOES> is specified: you can change the
data, so the compiler cannot perform the @ earlier.
In Forth-94/2012 you can use ":" to get around the issue, but that
typically costs more memory than a CREATE...DOES>-defined word.
One way around the memory consumption problem is to optimize the
CREATE...DOES>-created word with a SET-OPTIMIZER method:
: field3 ( n "name" -- )
\ you must not change the body of "name"
create ,
[: @ + ;] set-does>
[: >body @ postpone literal postpone + ;] set-optimizer ;
5 field3 foo3
This means that in the normal case, when FOO3 is performed, it does
the usual pushing of the body address and then performs @ +; when foo3
is COMPILE,d, the optimizer routine kicks in and it first uses >BODY @
to get the 5 on the top of stack, then compiles it with LITERAL and
compiles a +; so the fetch overhead is not present in the compiled
code. Some systems use a mechanism like this internally, for defining
various defining words.
- 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 | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2016-11-24 22:44 +0000 |
| Message-ID | <o17qdc$pv7$1@dont-email.me> |
| In reply to | #52847 |
On 24/11/2016 20:46, hughaguilar96@gmail.com wrote: > BTW: I found it rather humorous that you said: "ignoring the wid which is non-standard anyway." What??? SYNONYM and ALIAS are not in the ANS-Forth Standard. What Standard is my wid feature being non-standard to??? Forth 2012, see http://forth-standard.org/standard/tools/SYNONYM -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-11-24 23:11 +0000 |
| Message-ID | <2016Nov25.001125@mips.complang.tuwien.ac.at> |
| In reply to | #52811 |
Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>Because it compiles a colon definition for the synonym I don't think
>your definition of SYNONYM works in all cases. For example (ignoring the
>wid which is non-standard anyway):
>
>123 value foo
>synonym bar foo
>456 to bar \ Fails as TO can't save a value to a colon definition
>
>Similarly
>
>defer x
>:noname ... ; is x
>synonym y x
>:noname ... ; is y \ Would fail
>
>Probably a minor restriction.
In Forth-2012 SYNONYM copies only the interpretation and compilation
semantics, not the TO <name> run-time semantics, and not the property
"defined by DEFER", nor (not relevant above) "defined by CREATE"; so
the examples above are not required to work in Forth-2012. Maybe we
will change that in the next standard.
- 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 | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-11-24 16:38 -0800 |
| Message-ID | <295d4c23-cbec-41d6-8c24-49b7a646ee94@googlegroups.com> |
| In reply to | #52854 |
On Thursday, November 24, 2016 at 4:16:10 PM UTC-7, Anton Ertl wrote:
> Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
> >Because it compiles a colon definition for the synonym I don't think
> >your definition of SYNONYM works in all cases. For example (ignoring the
> >wid which is non-standard anyway):
> >
> >123 value foo
> >synonym bar foo
> >456 to bar \ Fails as TO can't save a value to a colon definition
> >
> >Similarly
> >
> >defer x
> >:noname ... ; is x
> >synonym y x
> >:noname ... ; is y \ Would fail
> >
> >Probably a minor restriction.
>
> In Forth-2012 SYNONYM copies only the interpretation and compilation
> semantics, not the TO <name> run-time semantics, and not the property
> "defined by DEFER", nor (not relevant above) "defined by CREATE"; so
> the examples above are not required to work in Forth-2012. Maybe we
> will change that in the next standard.
Maybe you should stop using the word "standard" --- this is an insult to the entire Forth community --- just because Elizabeth Rather appointed you to be the chairperson of the Forth-200x committee doesn't mean that you have any authority over Forth programmers such as myself.
Elizabeth Rather's toy language was a failure at everything. The fact that the parameters for LOCALS| were backwards was ridiculous; that alone makes ANS-Forth a joke. Then you wrote {: to define locals. You had to change the name from { despite the fact that { (the John Hopkin's format) had been in use since prior to ANS-Forth. This was because SwiftForth uses { for multi-line comments. You also screwed up the definition of {: because you failed to zero out the locals to the right of the | --- you said that these values were "undefined," meaning that they could be anything. When I pointed out the obvious problem with this (programs don't necessarily do the same thing from one compilation to the next, or even one run to the next), you said that your code was correct because it was written to spec. What spec? Obviously, you are just Leon Wagner's code monkey --- he writes the spec --- you implement the code without concern for obvious blunders in the spec.
I will never become an ANS-Forth programmer --- not Forth-200x either --- these are both just marketing gimmicks from Forth Inc. whose sole purpose is to convince the world that Forth Inc. owns the Forth language and that the entire Forth community is dependent upon Forth Inc. for leadership.
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2016-11-25 07:28 +0000 |
| Message-ID | <o18p4r$vfn$1@dont-email.me> |
| In reply to | #52854 |
On 24/11/2016 23:11, Anton Ertl wrote: > Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes: >> Because it compiles a colon definition for the synonym I don't think >> your definition of SYNONYM works in all cases. For example (ignoring the >> wid which is non-standard anyway): >> >> 123 value foo >> synonym bar foo >> 456 to bar \ Fails as TO can't save a value to a colon definition >> >> Similarly >> >> defer x >> :noname ... ; is x >> synonym y x >> :noname ... ; is y \ Would fail >> >> Probably a minor restriction. > > In Forth-2012 SYNONYM copies only the interpretation and compilation > semantics, not the TO <name> run-time semantics, and not the property > "defined by DEFER", nor (not relevant above) "defined by CREATE"; so > the examples above are not required to work in Forth-2012. Maybe we > will change that in the next standard. Be that as it may but my comments to Hugh still stand as his SYNONYM is incomplete as is the Forth 2012 standard. As a user I would expect a word defined as a synonym to behave and be treated exactly as the parent word, i.e. to be able to use it (or not use it because of restrictions on the parent) in all situations that the parent word is used. So yes I would support changing the standard. The alternative is yet another ambiguous condition and I think we're all agreed there are too many of them already. I see that GForth, VFX Forth, Win32 Forth and my system all handle TO and IS on a synonym correctly (Swiftforth hasn't implemented SYNONYM) so there shouldn't be too much opposition. -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | foxaudioresearch@gmail.com |
|---|---|
| Date | 2016-11-25 04:24 -0800 |
| Message-ID | <47002a42-d278-44be-9165-988d0c04a1a2@googlegroups.com> |
| In reply to | #52864 |
I heartily agree. There has to be some accommodation for common sense. Forth has enough hurdles for the new user without adding one that is so counter-intuitive.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2016-11-25 14:37 +0000 |
| Message-ID | <o19i98$kmk$1@dont-email.me> |
| In reply to | #52866 |
On 11/25/2016 12:24, foxaudioresearch@gmail.com wrote: > I heartily agree. There has to be some accommodation for common sense. Forth has enough hurdles for the new user without adding one that is so counter-intuitive. > Heartily agree with what? You've cut away the entire thread. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | foxaudioresearch@gmail.com |
|---|---|
| Date | 2016-11-26 10:54 -0800 |
| Message-ID | <0dc21599-7bf8-4799-830b-876e9ac22a25@googlegroups.com> |
| In reply to | #52868 |
On Friday, November 25, 2016 at 9:37:41 AM UTC-5, Alex wrote: > On 11/25/2016 12:24, foxaudioresearch@gmail.com wrote: > > I heartily agree. There has to be some accommodation for common sense. Forth has enough hurdles for the new user without adding one that is so counter-intuitive. > > > > Heartily agree with what? You've cut away the entire thread. > > -- > Alex I agreed with Gerry's comments. (didn't realize my new phone posts only my comments.)
[toc] | [prev] | [next] | [standalone]
| From | luser droog <mijoryx@yahoo.com> |
|---|---|
| Date | 2016-11-27 10:56 -0800 |
| Message-ID | <1981eead-f7c2-42ca-a805-26800adbab43@googlegroups.com> |
| In reply to | #52878 |
On Saturday, November 26, 2016 at 12:54:10 PM UTC-6, foxaudio...@gmail.com wrote: > On Friday, November 25, 2016 at 9:37:41 AM UTC-5, Alex wrote: > > On 11/25/2016 12:24, foxaudioresearch@gmail.com wrote: > > > I heartily agree. There has to be some accommodation for common sense. Forth has enough hurdles for the new user without adding one that is so counter-intuitive. > > > > > > > Heartily agree with what? You've cut away the entire thread. > > > > -- > > Alex > > I agreed with Gerry's comments. > > (didn't realize my new phone posts only my comments.) If you're using google-groups, you have to select the Desktop Version of the page for it to do quoting. Zooming and scrolling will be more of a chore. :(
[toc] | [prev] | [next] | [standalone]
| From | polymorph self <jackvanc3@gmail.com> |
|---|---|
| Date | 2016-11-27 00:27 -0800 |
| Message-ID | <e1a5204a-5197-4d8d-884c-6162ccebbdd5@googlegroups.com> |
| In reply to | #52795 |
On Monday, November 21, 2016 at 5:26:19 PM UTC-5, hughag...@gmail.com wrote:
> On Saturday, November 19, 2016 at 10:42:25 AM UTC-7, Stephen Pelc wrote:
> > It is also a fallacy to assume that the commercial Forth
> > vendors are in competition with each other. We are very rarely
> > in competition for the same client. Our competition is the
> > toolchains for other languages.
>
> Your goal in supporting ANS-Forth seems to be to make the Forth community look stupid. Good job! Having the parameters backwards in LOCALS| was, by itself, the killing stroke for the entire Forth community.
>
> You are not in competition with Forth Inc.. I think you rely on them to do your sales, then when they find a customer they outsource the actual programming to you, so you both make money.
>
> You are in competition with Forth programmers such as myself. The whole purpose of ANS-Forth is to allow you to tell everybody in the Forth community that they are non-standard unless they adhere to the idiotic restrictions of Elizabeth Rather's toy language.
>
> You don't adhere to ANS-Forth though. You routinely abandon ANS-Forth compatibility, even when doing so is not necessary. For example, in regard to SYONYM and ALIAS, you told me (quite condescendingly) to RTFM. You meant the VFX manual where you provide a SYNONYM that is VFX-specific and would get me trapped in vendor lock-in. I wrote SYNONYM and ALIAS in ANS-Forth though --- it was easy --- it did require me to have the disambiguifiers already installed.
>
> Here is the code, so RTFM yourself:
>
> : :synonym { xt flg str wid -- } \ FLG is 1 for immediate and -1 for non-immediate
> str wid :name
> flg 1 = if xt lit, execute, ;, immediate exit then
> flg -1 = if xt compile, ;, exit then
> true abort" *** :SYNONYM given an invalid xt ***" ;
>
> : :synonym-fast-check ( -- )
> state @ 0= abort" *** a word created by :SYNONYM-FAST can't be used in interpretive mode ***" ;
>
> : :synonym-fast { xt flg str wid -- } \ FLG is 1 for immediate and -1 for non-immediate
> str wid :name
> flg 1 = if xt lit, execute, ;, immediate exit then
> flg -1 = if postpone :synonym-fast-check
> xt lit, postpone compile, ;, immediate exit then
> true abort" *** :SYNONYM-FAST given an invalid xt ***" ;
>
> : 'find ( -- xt flg ) \ stream: name \ FLG is 1 for immediate and -1 for non-immediate
> bl word find dup 0= abort" *** 'FIND couldn't find the word ***" ;
>
> : synonym { wid | new -- } \ stream: new-name old-name \ the new word is compiled into the WID word-list
> bl word hstr to new
> 'find new wid :synonym
> new dealloc ;
>
> : synonym-fast { wid | new -- } \ stream: new-name old-name \ the new word is compiled into the WID word-list
> bl parse <hstr> to new
> 'find new wid :synonym-fast
> new dealloc ;
>
> \ :SYNONYM-FAST generates faster executing code than :SYNONYM but the words can't be used in interpretive mode.
> \ This may not be necessary with a good optimizing compiler, but I'm not aware of any at this time.
>
> 1234512345 constant alias-id \ an arbitrary number used to identify alias'd definitions
>
> 0
> w field alias.xt \ this should be the first field so the DOES> portion of ALIAS will be fast (no addition needed)
> w field alias.adr \ the address of the body, used to identify alias'd definitions
> w field alias.id \ the constant ALIAS-ID, used to identify alias'd definitions
> constant alias-struct
>
> : alias ( wid -- ) \ stream: new-name old-name \ the new word is compiled into the WID word-list
> get-current swap set-current create set-current
> here >r alias-struct allot
> 'find 1 = if immediate then r@ alias.xt !
> r@ r@ alias.adr !
> alias-id r@ alias.id !
> rdrop
> does>
> alias.xt @ execute ;
>
> \ ALIAS does the same thing as SYNONYM but has the advantage that >BODY will work on it.
> \ It is slower executing though (especially under SwiftForth in which CREATE DOES> words are very inefficient).
>
> : >body ( xt -- adr )
> >body >r
> r@ alias.adr @ r@ = if r@ alias.id @ alias-id = if \ is this an alias'd word?
> r> alias.xt @ >body exit then then \ return the body of the original word
> r> ; \ return the body of this word
>
> \ Note that >BODY still has an undefined result if used on a word that wasn't defined with CREATE or isn't an alias of such a word.
Elizabeth seems nice why not be more polite and work together to make money while replacing all the crappy java?
[toc] | [prev] | [next] | [standalone]
| From | luser droog <mijoryx@yahoo.com> |
|---|---|
| Date | 2016-11-27 11:42 -0800 |
| Message-ID | <540a6ee3-6e20-462a-9d6c-bd25172e069a@googlegroups.com> |
| In reply to | #52891 |
On Sunday, November 27, 2016 at 2:27:55 AM UTC-6, polymorph self wrote: > On Monday, November 21, 2016 at 5:26:19 PM UTC-5, hughag...@gmail.com wrote: > Elizabeth seems nice why not be more polite and work together to make money while replacing all the crappy java? This is pretty telling. The trolling is bothering the trolls. Try not using anybody's name for like, a week or two. Just talk code. -- "I am the man with no name.... Zapp Branigan, at your service."
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-11-21 14:35 -0800 |
| Message-ID | <93352bb0-a286-453a-81c5-0df566d0f652@googlegroups.com> |
| In reply to | #52736 |
On Saturday, November 19, 2016 at 10:42:25 AM UTC-7, Stephen Pelc wrote: > That performance is just one factor in tool chain selection > is obvious. Another is the GUI. Another is the level of library > support. And so on, and so on. This is what Elizabeth Rather says: -------------------------------------------------------------------------- ...in Forth it's so easy to build data structures that are exactly right for the particular application at hand that worrying about what pre-built structures you have and how to use them is just not worth the bother. -------------------------------------------------------------------------- What "level of library support" does ANS-Forth have? Zilch! Elizabeth Rather has spent her entire career railing against code-libraries. There are no code libraries. > It is also a fallacy to assume that the commercial Forth > vendors are in competition with each other. We are very rarely > in competition for the same client. Our competition is the > toolchains for other languages. What "toolchain" does ANS-Forth have? You can't have toolchains without having code-libraries. I think you see me and my novice-package as your competition --- because this package is provided to allow common Forth programmers to write application programs --- this is what you and Elizabeth Rather are primarily opposed to.
[toc] | [prev] | [next] | [standalone]
Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
Back to top | Article view | comp.lang.forth
csiph-web