Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #52738 > unrolled thread
| Started by | humptydumpty <ouatubi@gmail.com> |
|---|---|
| First post | 2016-11-19 13:34 -0800 |
| Last post | 2017-04-11 06:41 -0700 |
| Articles | 20 on this page of 159 — 26 participants |
Back to article view | Back to comp.lang.forth
Yet another draw of rectangle humptydumpty <ouatubi@gmail.com> - 2016-11-19 13:34 -0800
Re: Yet another draw of rectangle "Robert L." <No_spamming@noWhere_7073.org> - 2016-11-20 00:53 +0000
Re: Yet another draw of rectangle "HAA" <someone@microsoft.com> - 2016-11-20 14:46 +1100
Re: Yet another draw of rectangle Paul Rubin <no.email@nospam.invalid> - 2016-11-19 20:01 -0800
Re: Yet another draw of rectangle "HAA" <someone@microsoft.com> - 2016-11-20 20:10 +1100
Re: Yet another draw of rectangle Paul Rubin <no.email@nospam.invalid> - 2016-11-20 01:18 -0800
Re: Yet another draw of rectangle humptydumpty <ouatubi@gmail.com> - 2016-11-20 01:36 -0800
Re: Yet another draw of rectangle Paul Rubin <no.email@nospam.invalid> - 2016-11-20 02:16 -0800
Re: Yet another draw of rectangle humptydumpty <ouatubi@gmail.com> - 2016-11-20 02:36 -0800
Re: Yet another draw of rectangle Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-11-20 07:48 -0500
Re: Yet another draw of rectangle rickman <gnuarm@gmail.com> - 2016-11-22 23:36 -0500
Re: Yet another draw of rectangle humptydumpty <ouatubi@gmail.com> - 2016-11-20 02:03 -0800
Re: Yet another draw of rectangle "HAA" <someone@microsoft.com> - 2016-11-20 21:49 +1100
Re: Yet another draw of rectangle humptydumpty <ouatubi@gmail.com> - 2016-11-20 03:33 -0800
Re: Yet another draw of rectangle Paul Rubin <no.email@nospam.invalid> - 2016-11-20 08:52 -0800
Re: Yet another draw of rectangle Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-20 12:05 -0600
Re: Yet another draw of rectangle "HAA" <someone@microsoft.com> - 2016-11-21 10:43 +1100
Re: Yet another draw of rectangle Paul Rubin <no.email@nospam.invalid> - 2016-11-20 16:25 -0800
Re: Yet another draw of rectangle "HAA" <someone@microsoft.com> - 2016-11-21 15:20 +1100
Re: Yet another draw of rectangle Paul Rubin <no.email@nospam.invalid> - 2016-11-22 00:02 -0800
Re: Yet another draw of rectangle Mark Wills <markwills1970@gmail.com> - 2016-11-22 01:00 -0800
Re: Yet another draw of rectangle Paul Rubin <no.email@nospam.invalid> - 2016-11-22 01:13 -0800
Re: Yet another draw of rectangle "Robert L." <No_spamming@noWhere_7073.org> - 2016-11-22 20:54 +0000
Yet another language ( was Yet another draw of rectangle) "HAA" <someone@microsoft.com> - 2016-11-27 13:32 +1100
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-11-26 18:52 -0800
Re: Yet another language ( was Yet another draw of rectangle) "HAA" <someone@microsoft.com> - 2016-11-28 15:00 +1100
Re: Yet another language ( was Yet another draw of rectangle) "Elizabeth D. Rather" <erather@forth.com> - 2016-11-27 18:32 -1000
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-11-27 20:44 -0800
Re: Yet another language ( was Yet another draw of rectangle) "HAA" <someone@microsoft.com> - 2016-11-29 15:22 +1100
Re: Yet another language ( was Yet another draw of rectangle) Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-11-29 00:42 -0500
Re: Yet another language ( was Yet another draw of rectangle) "Elizabeth D. Rather" <erather@forth.com> - 2016-11-28 22:20 -1000
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-11-29 17:18 -0800
Re: Yet another language ( was Yet another draw of rectangle) Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-11-29 23:15 -0500
Re: Yet another language ( was Yet another draw of rectangle) Ron Aaron <rambamist@gmail.com> - 2016-11-30 07:08 +0200
Re: Yet another language ( was Yet another draw of rectangle) "Elizabeth D. Rather" <erather@forth.com> - 2016-11-29 21:51 -1000
Re: Yet another language ( was Yet another draw of rectangle) Ron Aaron <rambamist@gmail.com> - 2016-11-30 12:09 +0200
Re: Yet another language ( was Yet another draw of rectangle) "Elizabeth D. Rather" <erather@forth.com> - 2016-11-30 09:43 -1000
Re: Yet another language ( was Yet another draw of rectangle) Cecil Bayona <cbayona@cbayona.com> - 2016-11-30 17:36 -0600
Re: Yet another language ( was Yet another draw of rectangle) "Elizabeth D. Rather" <erather@forth.com> - 2016-11-30 14:31 -1000
Re: Yet another language ( was Yet another draw of rectangle) Ron Aaron <rambamist@gmail.com> - 2016-12-01 07:02 +0200
Re: Yet another language ( was Yet another draw of rectangle) "Elizabeth D. Rather" <erather@forth.com> - 2016-12-01 08:58 -1000
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-01 16:44 -0800
Re: Yet another language ( was Yet another draw of rectangle) "HAA" <someone@microsoft.com> - 2016-12-05 21:28 +1100
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-05 07:41 -0800
Re: Yet another language ( was Yet another draw of rectangle) "HAA" <someone@microsoft.com> - 2016-12-06 18:13 +1100
Re: Yet another language ( was Yet another draw of rectangle) "Elizabeth D. Rather" <erather@forth.com> - 2016-12-05 21:36 -1000
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-06 00:05 -0800
Re: Yet another language ( was Yet another draw of rectangle) "HAA" <someone@microsoft.com> - 2016-12-08 10:09 +1100
Re: Yet another language ( was Yet another draw of rectangle) Paul Rubin <no.email@nospam.invalid> - 2016-12-07 15:27 -0800
Re: Yet another language ( was Yet another draw of rectangle) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-08 04:22 -0600
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-08 17:05 -0800
Re: Yet another language ( was Yet another draw of rectangle) Mark Wills <markwills1970@gmail.com> - 2016-12-09 01:47 -0800
Re: Yet another language ( was Yet another draw of rectangle) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-09 04:01 -0600
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-09 06:49 -0800
Re: Yet another language ( was Yet another draw of rectangle) "HAA" <someone@microsoft.com> - 2016-12-10 10:15 +1100
Re: Yet another language ( was Yet another draw of rectangle) josv@planet.nl - 2017-04-12 04:47 -0700
Re: Yet another language ( was Yet another draw of rectangle) "Elizabeth D. Rather" <erather@forth.com> - 2016-12-07 14:34 -1000
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-07 18:39 -0800
Re: Yet another language ( was Yet another draw of rectangle) "HAA" <someone@microsoft.com> - 2016-12-10 09:38 +1100
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-09 16:25 -0800
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-06 00:14 -0800
Re: Yet another language ( was Yet another draw of rectangle) stephen@mpeforth.com (Stephen Pelc) - 2016-12-06 12:01 +0000
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-06 10:21 -0800
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-09 16:27 -0800
Re: Yet another language ( was Yet another draw of rectangle) Rob Sciuk <rob@controlq.com> - 2017-04-08 21:05 -0400
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2017-04-08 18:57 -0700
Re: Yet another language ( was Yet another draw of rectangle) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-09 05:28 -0700
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2017-04-09 06:45 -0700
Re: Yet another language ( was Yet another draw of rectangle) Rob Sciuk <rob@controlq.com> - 2017-04-10 16:54 -0400
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2017-04-10 17:21 -0700
Re: Yet another language ( was Yet another draw of rectangle) Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2017-04-11 08:03 +0100
Re: Yet another language ( was Yet another draw of rectangle) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-11 07:50 +0000
Re: Yet another language ( was Yet another draw of rectangle) Rob Sciuk <rob@controlq.com> - 2017-04-11 11:43 -0400
Re: Yet another language ( was Yet another draw of rectangle) lehs <skydda.barnen@gmail.com> - 2017-04-11 10:16 -0700
Re: Yet another language ( was Yet another draw of rectangle) Paul Rubin <no.email@nospam.invalid> - 2017-04-11 10:21 -0700
Re: Yet another language ( was Yet another draw of rectangle) lehs <skydda.barnen@gmail.com> - 2017-04-11 10:48 -0700
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2017-04-11 23:58 -0700
Re: Yet another language ( was Yet another draw of rectangle) rickman <gnuarm@gmail.com> - 2017-04-12 03:07 -0400
Re: Yet another language ( was Yet another draw of rectangle) lehs <skydda.barnen@gmail.com> - 2017-04-12 00:29 -0700
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2017-04-12 00:55 -0700
Re: Yet another language ( was Yet another draw of rectangle) rickman <gnuarm@gmail.com> - 2017-04-12 04:07 -0400
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2017-04-12 13:29 -0700
Re: Yet another language ( was Yet another draw of rectangle) rickman <gnuarm@gmail.com> - 2017-04-12 16:51 -0400
Re: Yet another language ( was Yet another draw of rectangle) lehs <skydda.barnen@gmail.com> - 2017-04-12 03:50 -0700
Re: Yet another language ( was Yet another draw of rectangle) Lars Brinkhoff <lars.spam@nocrew.org> - 2017-04-12 12:55 +0200
Re: Yet another language ( was Yet another draw of rectangle) lehs <skydda.barnen@gmail.com> - 2017-04-12 04:17 -0700
Re: Yet another language ( was Yet another draw of rectangle) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-12 06:03 -0500
Re: Yet another language ( was Yet another draw of rectangle) lehs <skydda.barnen@gmail.com> - 2017-04-12 04:30 -0700
Re: Yet another language ( was Yet another draw of rectangle) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-12 08:44 -0500
Re: Yet another language ( was Yet another draw of rectangle) rickman <gnuarm@gmail.com> - 2017-04-12 13:01 -0400
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2017-04-12 13:33 -0700
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2017-04-12 12:59 -0700
Re: Yet another language ( was Yet another draw of rectangle) rickman <gnuarm@gmail.com> - 2017-04-12 17:05 -0400
Re: Yet another language ( was Yet another draw of rectangle) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-11 10:27 -0700
Re: Yet another language ( was Yet another draw of rectangle) rickman <gnuarm@gmail.com> - 2017-04-11 14:02 -0400
Re: Yet another language ( was Yet another draw of rectangle) Julian Fondren <julian.fondren@gmail.com> - 2017-04-08 20:10 -0700
Re: Yet another language ( was Yet another draw of rectangle) rickman <gnuarm@gmail.com> - 2017-04-13 13:16 -0400
Re: Yet another language ( was Yet another draw of rectangle) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-05 12:01 -0600
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-05 10:39 -0800
Re: Yet another language ( was Yet another draw of rectangle) Alex <alex@rivadpm.com> - 2016-12-05 18:53 +0000
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-05 11:33 -0800
Re: Yet another language ( was Yet another draw of rectangle) Alex <alex@rivadpm.com> - 2016-12-05 22:22 +0000
Re: Yet another language ( was Yet another draw of rectangle) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-06 04:29 -0600
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-06 11:32 -0800
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-07 19:06 -0800
Re: Yet another language ( was Yet another draw of rectangle) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-06 04:27 -0600
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-06 10:24 -0800
Re: Yet another language ( was Yet another draw of rectangle) john <anon@example.com> - 2016-11-30 13:41 +0000
Re: Yet another language ( was Yet another draw of rectangle) stephen@mpeforth.com (Stephen Pelc) - 2016-11-30 15:15 +0000
Re: Yet another language ( was Yet another draw of rectangle) john <anon@example.com> - 2016-12-01 09:54 +0000
Re: Yet another language ( was Yet another draw of rectangle) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-01 04:42 -0600
Re: Yet another language ( was Yet another draw of rectangle) rickman <gnuarm@gmail.com> - 2017-04-12 13:09 -0400
Re: Yet another language ( was Yet another draw of rectangle) rickman <gnuarm@gmail.com> - 2017-04-12 13:14 -0400
Re: Yet another language ( was Yet another draw of rectangle) "Elizabeth D. Rather" <erather@forth.com> - 2017-04-12 08:32 -1000
Re: Yet another language ( was Yet another draw of rectangle) lehs <skydda.barnen@gmail.com> - 2017-04-12 12:42 -0700
Re: Yet another language ( was Yet another draw of rectangle) "Elizabeth D. Rather" <erather@forth.com> - 2017-04-12 10:36 -1000
Re: Yet another language ( was Yet another draw of rectangle) rickman <gnuarm@gmail.com> - 2017-04-12 16:41 -0400
Re: Yet another language ( was Yet another draw of rectangle) "Elizabeth D. Rather" <erather@forth.com> - 2017-04-12 13:25 -1000
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2017-04-12 14:13 -0700
Re: Yet another language ( was Yet another draw of rectangle) rickman <gnuarm@gmail.com> - 2017-04-12 17:45 -0400
Re: Yet another language ( was Yet another draw of rectangle) Mark Wills <markwills1970@gmail.com> - 2017-04-13 05:53 -0700
Re: Yet another language ( was Yet another draw of rectangle) rickman <gnuarm@gmail.com> - 2017-04-13 13:34 -0400
Re: Yet another language ( was Yet another draw of rectangle) john <anon@example.com> - 2016-11-29 11:48 +0000
Re: Yet another language ( was Yet another draw of rectangle) stephen@mpeforth.com (Stephen Pelc) - 2016-11-29 14:24 +0000
Re: Yet another language ( was Yet another draw of rectangle) john <anon@example.com> - 2016-11-29 21:27 +0000
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-11-29 18:15 -0800
Re: Yet another language ( was Yet another draw of rectangle) Alex <alex@rivadpm.com> - 2016-11-30 10:03 +0000
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-01 16:14 -0800
Re: Yet another language ( was Yet another draw of rectangle) "Elizabeth D. Rather" <erather@forth.com> - 2016-11-29 12:22 -1000
Re: Yet another language ( was Yet another draw of rectangle) albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-29 14:31 +0100
Re: Yet another language ( was Yet another draw of rectangle) "HAA" <someone@microsoft.com> - 2016-12-02 23:05 +1100
Re: Yet another language ( was Yet another draw of rectangle) Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-12-03 01:58 -0500
Re: Yet another language ( was Yet another draw of rectangle) "HAA" <someone@microsoft.com> - 2016-12-03 22:00 +1100
Re: Yet another draw of rectangle "HAA" <someone@microsoft.com> - 2016-11-23 10:11 +1100
Re: Yet another draw of rectangle Paul Rubin <no.email@nospam.invalid> - 2016-11-23 00:01 -0800
Re: Yet another draw of rectangle albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-23 13:49 +0100
Re: Yet another draw of rectangle foxaudioresearch@gmail.com - 2016-11-23 10:51 -0800
Re: Yet another draw of rectangle "Elizabeth D. Rather" <erather@forth.com> - 2016-11-24 09:26 -1000
Re: Yet another draw of rectangle Paul Rubin <no.email@nospam.invalid> - 2016-11-23 12:28 -0800
Re: Yet another draw of rectangle hughaguilar96@gmail.com - 2016-11-24 16:54 -0800
Re: Yet another draw of rectangle rickman <gnuarm@gmail.com> - 2016-11-25 02:20 -0500
Re: Yet another draw of rectangle albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-25 10:39 +0100
Re: Yet another draw of rectangle Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-22 04:17 -0600
Re: Yet another draw of rectangle Paul Rubin <no.email@nospam.invalid> - 2016-11-22 10:38 -0800
Re: Yet another draw of rectangle humptydumpty <ouatubi@gmail.com> - 2016-11-23 13:05 -0800
Re: Yet another draw of rectangle Paul Rubin <no.email@nospam.invalid> - 2016-11-29 15:23 -0800
Re: Yet another draw of rectangle Ron Aaron <rambamist@gmail.com> - 2016-11-24 07:46 +0200
Re: Yet another draw of rectangle Paul Rubin <no.email@nospam.invalid> - 2016-11-23 21:59 -0800
Re: Yet another draw of rectangle Ron Aaron <rambamist@gmail.com> - 2016-11-24 08:12 +0200
Re: Yet another draw of rectangle rickman <gnuarm@gmail.com> - 2016-11-23 22:22 -0500
Re: Yet another draw of rectangle humptydumpty <ouatubi@gmail.com> - 2016-11-23 21:14 -0800
Re: Yet another draw of rectangle rickman <gnuarm@gmail.com> - 2016-11-24 01:06 -0500
Re: Yet another draw of rectangle "HAA" <someone@microsoft.com> - 2016-11-25 11:56 +1100
Re: Yet another draw of rectangle hughaguilar96@gmail.com - 2016-11-19 23:14 -0800
Re: Yet another draw of rectangle hughaguilar96@gmail.com - 2016-11-24 18:11 -0800
Re: Yet another draw of rectangle luser droog <mijoryx@yahoo.com> - 2016-11-24 18:58 -0800
Re: Yet another draw of rectangle luser droog <mijoryx@yahoo.com> - 2016-11-24 20:01 -0800
Re: Yet another draw of rectangle Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-11-20 14:08 -0800
Re: Yet another draw of rectangle lehs <skydda.barnen@gmail.com> - 2017-04-11 06:41 -0700
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2017-04-13 05:53 -0700 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <0bcb7eb4-b21a-410e-929b-64ec42872f13@googlegroups.com> |
| In reply to | #57163 |
On Wednesday, 12 April 2017 18:09:47 UTC+1, rickman wrote: > I agree a bit with Hugh in that I've always wondered why there aren't > basic array defining words. I ended up with my own library which > posters here helped me develop. Writing that was a useful exercise and > I learned a few things, but I don't see why that library isn't out there > already. I expect apps that don't need arrays are few and far between. > > -- > > Rick C I used to think the same thing. However, the truth is, once you've gained a certain level of competence with Forth, developing your own array handling words that are specific to your application takes about as long as it takes to type them in. (I'm sure you're far beyond that level of proficiency - I didn't mean to imply you are not competent with Forth!) Structures and trees etc. are a different thing - much more involved to write. An excellent candidate for a standard library.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-13 13:34 -0400 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <ococlj$onr$1@dont-email.me> |
| In reply to | #57229 |
On 4/13/2017 8:53 AM, Mark Wills wrote: > On Wednesday, 12 April 2017 18:09:47 UTC+1, rickman wrote: >> I agree a bit with Hugh in that I've always wondered why there aren't >> basic array defining words. I ended up with my own library which >> posters here helped me develop. Writing that was a useful exercise and >> I learned a few things, but I don't see why that library isn't out there >> already. I expect apps that don't need arrays are few and far between. >> >> -- >> >> Rick C > > I used to think the same thing. However, the truth is, once you've gained > a certain level of competence with Forth, developing your own array > handling words that are specific to your application takes about as long > as it takes to type them in. (I'm sure you're far beyond that level of > proficiency - I didn't mean to imply you are not competent with Forth!) Just the opposite. I only program in any language sporadically. I've never learned Forth well enough for much of the details to survive the stretches when I don't program. So a bit like living groundhog day, I start most programs having to relearn and reinvent a lot. > Structures and trees etc. are a different thing - much more involved > to write. An excellent candidate for a standard library. Strings are very basic too, yet we have standard words to manipulate them. In fact, they are arrays of characters. Why do we have what is essentially a library for strings? I see no reason to not have a standard library to support other array types. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | john <anon@example.com> |
|---|---|
| Date | 2016-11-29 11:48 +0000 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <MPG.32a77b4df5d5ccf69896d0@news.virginmedia.com> |
| In reply to | #52944 |
> In article <20161129004209.27f63172@_>, NeedNotReplyHere@xrsevnneqk.cem says... > . . . > On Tue, 29 Nov 2016 15:22:40 +1100 > "HAA" <someone@microsoft.com> wrote: > > > hughaguilar96@gmail.com wrote: > "... where users could create from [the] ground up." > > I'd argue that statement describes the failing of Forth, not it's > merit. That's part of the reason why Forth is called a "write-once" > language. The others being that it's simple syntax can be > exceptionally cryptic, the code can be untraceable or difficult to > understand, and Forth requires the user to juggle stack items. Without > a large, standardized, and ubiquitous set of functionality, every Forth > application has to develop it's own solution to the same basic > programming problems and situations. This requires extra work, time or > man-hours, on the part of the programmer, and interferes with > portability, as the resulting code is non-standard. The code is unique > to that application, when every application could've used the same > functionality. It also means that any bad solutions or poor designs > will be passed along forever with that application. It also means that > numerous programs will most assuredly have bad, buggy, or limited > implementations of functionality which is commonly used. A programmer > needs to have a certain set of standard tools or components which are > widely available and easy to use. > > > Rod Pemberton This is a good point. The problem is - in whose interest is it to solve it? The forth world is so fragmented that everyone wants to take credit for writing their own forth and almost none ever have any real use. Its a tunnel vision thing I think. It doesn't just apply to forth. You can say the same about various other languages or products. Especially the OOP based ones. Look at the number of OOP designed games the creators just dump rather than release new levels - there's more money in releasing a "new" product than expanding an existing one In the pascal/Delphi/lazarus world everyone seems to want credit for creating yet another slightly modified copy of the same package and seldom tries to build or really create anything more complete that solves anything. While doing some research about a month ago we found a couple of really good Forth scientific libraries online - but they really were well hidden (not purposefully I don't think) I told jim at the time we could spare some bandwidth and offer a forth library online if he wanted. He made the suggestion here and was promptly ignored. So perhaps no one really cares enough to bother? No enough kudos perhaps. There are forth FTP and other sites out there but they are more like unmanaged "code dumps" than libraries. It's hard to know if their creators tried and lost interest because of everyone elses apathy about forth. People don't seem to want to actually use "forth" as much as they want to be known as a "creator" of "A" forth. Code dumps and link pages are easy - libraries take work. It all comes down to money and time and enthusiasm though. -- john ========================= http://johntech.co.uk "Bleeding Edge Forum" http://johntech.co.uk/forum/ =========================
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2016-11-29 14:24 +0000 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <583d8e51.1680985747@news.eternal-september.org> |
| In reply to | #52952 |
On Tue, 29 Nov 2016 11:48:18 -0000, john <anon@example.com> wrote: >There are forth FTP and other sites out there but they are more >like unmanaged "code dumps" than libraries. Gerald Wodni has put a lot of effort into the package manager and site at http://theforth.net/ Because it already has a package manager and support from several people in the Forth community, it is to be encouraged rather than copied. 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 | john <anon@example.com> |
|---|---|
| Date | 2016-11-29 21:27 +0000 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <MPG.32a8030741291f309896d1@news.virginmedia.com> |
| In reply to | #52956 |
> In article <583d8e51.1680985747@news.eternal-september.org>, stephen@mpeforth.com says... > > On Tue, 29 Nov 2016 11:48:18 -0000, john <anon@example.com> wrote: > > >There are forth FTP and other sites out there but they are more > >like unmanaged "code dumps" than libraries. > > Gerald Wodni has put a lot of effort into the package manager > and site at > http://theforth.net/ > Because it already has a package manager and support from several > people in the Forth community, it is to be encouraged rather than > copied. > > Stephen Now that's more like it Stephen. Absolutely this should be used. But needs more promotion maybe? (It didnt show up on our lists and a site that useful really needs to be found easier... ) If Gerold wants an ad on our site he'd be very welcome (I don't charge - anyone else welcome too within reason) -- john ========================= http://johntech.co.uk "Bleeding Edge Forum" http://johntech.co.uk/forum/ =========================
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-11-29 18:15 -0800 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <b447ccb9-919c-488d-bcd6-1c779f0658d7@googlegroups.com> |
| In reply to | #52956 |
On Tuesday, November 29, 2016 at 7:24:02 AM UTC-7, Stephen Pelc wrote:
> On Tue, 29 Nov 2016 11:48:18 -0000, john <anon@example.com> wrote:
>
> >There are forth FTP and other sites out there but they are more
> >like unmanaged "code dumps" than libraries.
>
> Gerald Wodni has put a lot of effort into the package manager
> and site at
> http://theforth.net/
> Because it already has a package manager and support from several
> people in the Forth community, it is to be encouraged rather than
> copied.
I haven't looked at that, and I won't bother. I can't contribute to it, so I have no interest in using it.
I did glance over FFL (Forth Foundation Library) and it was terrible. I looked at the singly-linked-list implementation and their EACH (or whatever they called it) held its own data on the data-stack when executing the xt, so it couldn't access the data on the data-stack that the parent function had left there. That is utterly stupid! I pointed this out, and the problem got fixed. Here is the new function:
: scl-execute ( i*x xt scl -- j*x = Execute xt for every cell data in list )
snl-first@ \ walk = first
BEGIN
nil<>? \ while walk<>nil do
WHILE
dup >r scn-cell@
swap
dup >r execute \ execute xt with cell
r> r>
snn-next@ \ walk = walk->next
REPEAT
drop
;
Notice how it is holding the internal data on the return-stack so it is not sitting on top of the data left by the calling function. I was the one who pointed out the need for this, but notice that Stephen Pelc doesn't give me credit for this.
Notice that scl-execute still has a bug in it. It is obtaining the next node after executing the xt. This is a bug because the current node may get destroyed by the xt's code, in which case the link to the next node is no longer valid. A typical example would be if the xt removes the node from the list and appends it to another list, in which case the link would be set to NIL because the node is now the tail node of the other list.
This is my EACH in the novice-package (working correctly since 2010):
: each ( i*x head 'toucher -- j*x ) \ toucher: i*x node -- j*x
>r
begin dup while \ -- node \r: -- 'toucher
r@ over .fore @ >r \ -- node 'toucher \r: -- 'toucher next
execute r> repeat drop
rdrop ;
Notice how my EACH is more efficient than scl-execute because I'm only doing one >R and one R> inside of the loop, whereas scl-execute is doing two >R and two R> inside of the loop. Also notice how my EACH is short and readable --- all of the FFL code is over-complicated and hard-to-read.
I haven't bothered to look at the rest of FFL. The fact that I had to point out the need for their scl-execute to hold its own data on the return-stack was not a confidence builder. And, scl-execute still has the bug in which it obtains the next node after doing the EXECUTE rather than before, which is pretty dumb. All in all, FFL looks worthless to me --- I'm not going to waste any further time in debugging it --- FFL certainly does have a grandiloquent name though!
I have my novice package: http://www.forth.org/novice.html
It is not an "unmanaged code dump" --- it is a code-library with documentation --- I have general-purpose data-structures in which you give an xt to a HOF in the usual way of modern languages.
In a few days I will release a new version with my string-stack.4th package, my OOP package, my disambiguifiers, and various other code. I have all this new code, so I might as well release it. This will likely be the last release of the novice package though --- it is pointless --- the only result has been flames such as these:
John Passaniti:
crap
Elizabeth Rather:
Does "*every* application" you write use exactly the same kind of data
arranged in the same way? If so, having written it once you can reuse it
often. If not, you either have to rearrange your data to make it work or
modify your "general-purpose" structure.
Stephen Pelc:
RTFM!
Alex McDonald:
You have serious misunderstanding of how pointers work.
You really don't understand how CREATE DOES> works.
etc., etc..
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2016-11-30 10:03 +0000 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <o1m82h$v2p$1@dont-email.me> |
| In reply to | #52973 |
On 11/30/2016 02:15, hughaguilar96@gmail.com wrote: > > Notice how it is holding the internal data on the return-stack so it > is not sitting on top of the data left by the calling function. I was > the one who pointed out the need for this, but notice that Stephen > Pelc doesn't give me credit for this. > Hahahaha! No credit... > This is my EACH in the novice-package (working correctly since > 2010): > > : each ( i*x head 'toucher -- j*x ) \ toucher: i*x > node -- j*x >> r > begin dup while \ -- node > \r: -- 'toucher r@ over .fore @ >r \ -- node > 'toucher \r: -- 'toucher next execute r> repeat drop > rdrop ; > > Notice how my EACH is more efficient than scl-execute because I'm > only doing one >R and one R> inside of the loop, whereas scl-execute > is doing two >R and two R> inside of the loop. Also notice how my > EACH is short and readable --- all of the FFL code is > over-complicated and hard-to-read. > I wrote that EACH for you, helped you eliminate a lot of rstack and stack juggling, and you haven't given me credit for it. https://groups.google.com/forum/#!original/comp.lang.forth/kH8lPSKdW30/_NzkfGsgnbkJ I asked you to remove it from your distribution here: https://groups.google.com/forum/#!original/comp.lang.forth/S59nQGxoUt0/dWhF1RSwgVAJ Now it's Hugh's brilliant code. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-01 16:14 -0800 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <4f3b708c-1a3f-4a5a-8e78-af51727ec600@googlegroups.com> |
| In reply to | #52983 |
On Wednesday, November 30, 2016 at 3:03:13 AM UTC-7, Alex wrote:
> On 11/30/2016 02:15, hughaguilar96@gmail.com wrote:
>
> >
> > Notice how it is holding the internal data on the return-stack so it
> > is not sitting on top of the data left by the calling function. I was
> > the one who pointed out the need for this, but notice that Stephen
> > Pelc doesn't give me credit for this.
> >
>
> Hahahaha! No credit...
This is scl-execute in FFL now.
: scl-execute ( i*x xt scl -- j*x = Execute xt for every cell data in list )
snl-first@ \ walk = first
BEGIN
nil<>? \ while walk<>nil do
WHILE
dup >r scn-cell@
swap
dup >r execute \ execute xt with cell
r> r>
snn-next@ \ walk = walk->next
REPEAT
drop
;
Prior to me pointing out that scl-execute should not hold its internal data on the data-stack, scl-execute was holding its internal data on the data-stack --- so why shouldn't I get credit for pointing out the bug?
scl-execute still has a bug in it. It is fetching the next-node from the link after doing EXECUTE --- the xt being executed, however, may clobber that link so it is no longer valid afterward --- for example, the node may get moved to another list.
My novice-package has been working correctly since 2010 --- FFL is still not working correctly --- I pointed out the first gigantic bug, and it got fixed, but I pointed out this second bug back in 2010 also, and it hasn't gotten fixed.
I would not use FFL --- it has bugs --- I don't think Stephen Pelc tests this code, and he doesn't use it for his own programs either.
> > This is my EACH in the novice-package (working correctly since
> > 2010):
> >
> > : each ( i*x head 'toucher -- j*x ) \ toucher: i*x
> > node -- j*x
> >> r
> > begin dup while \ -- node
> > \r: -- 'toucher r@ over .fore @ >r \ -- node
> > 'toucher \r: -- 'toucher next execute r> repeat drop
> > rdrop ;
> >
> > Notice how my EACH is more efficient than scl-execute because I'm
> > only doing one >R and one R> inside of the loop, whereas scl-execute
> > is doing two >R and two R> inside of the loop. Also notice how my
> > EACH is short and readable --- all of the FFL code is
> > over-complicated and hard-to-read.
> >
>
>
> I wrote that EACH for you, helped you eliminate a lot of rstack and
> stack juggling, and you haven't given me credit for it.
> https://groups.google.com/forum/#!original/comp.lang.forth/kH8lPSKdW30/_NzkfGsgnbkJ
Okay, I will give you credit for the optimization that reduced the number of >R and R> inside of the loop from two to one.
> I asked you to remove it from your distribution here:
> https://groups.google.com/forum/#!original/comp.lang.forth/S59nQGxoUt0/dWhF1RSwgVAJ
Trying to take credit for my LIST.4TH package is not going to work. You made a minor contribution.
You have also been telling a lot of lies about the novice-package. You said that my SORT doesn't work and that I "have a serious misunderstanding of how pointers work" --- you were lying --- my SORT works fine.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-11-29 12:22 -1000 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <orydnUR1Z4YmYqDFnZ2dnUU7-LvNnZ2d@supernews.com> |
| In reply to | #52952 |
On 11/29/16 1:48 AM, john wrote: >> In article <20161129004209.27f63172@_>, NeedNotReplyHere@xrsevnneqk.cem says... >> > . . . > >> On Tue, 29 Nov 2016 15:22:40 +1100 >> "HAA" <someone@microsoft.com> wrote: >> >>> hughaguilar96@gmail.com wrote: > >> "... where users could create from [the] ground up." >> >> I'd argue that statement describes the failing of Forth, not it's >> merit. That's part of the reason why Forth is called a "write-once" >> language. The others being that it's simple syntax can be >> exceptionally cryptic, the code can be untraceable or difficult to >> understand, and Forth requires the user to juggle stack items. Without >> a large, standardized, and ubiquitous set of functionality, every Forth >> application has to develop it's own solution to the same basic >> programming problems and situations. This requires extra work, time or >> man-hours, on the part of the programmer, and interferes with >> portability, as the resulting code is non-standard. The code is unique >> to that application, when every application could've used the same >> functionality. It also means that any bad solutions or poor designs >> will be passed along forever with that application. It also means that >> numerous programs will most assuredly have bad, buggy, or limited >> implementations of functionality which is commonly used. A programmer >> needs to have a certain set of standard tools or components which are >> widely available and easy to use. >> >> >> Rod Pemberton > > This is a good point. The problem is - in whose interest is it to solve it? > > The forth world is so fragmented that everyone wants to take credit for > writing their own forth and almost none ever have any real use. > Its a tunnel vision thing I think. It's also a property of comp.lang.forth. There's a whole world of professional Forth programmers working on major projects. That community is in touch with suppliers such as FORTH, Inc. and MPE and a few of the professionals here, but most of the people on comp.lang.forth are here out of intellectual curiosity or other motivations and either do their professional work in other languages or aren't professional programmers. > It doesn't just apply to forth. You can say the same about various other > languages or products. Especially the OOP based ones. > Look at the number of OOP designed games the creators just dump > rather than release new levels - there's more money in releasing > a "new" product than expanding an existing one > In the pascal/Delphi/lazarus world everyone seems to want credit > for creating yet another slightly modified copy of the same package and seldom > tries to build or really create anything more complete that solves anything. Again, that may be an indication of what brings people to comp.lang.<whatever>. > While doing some research about a month ago we found a couple of > really good Forth scientific libraries online - but they really were > well hidden (not purposefully I don't think) > > I told jim at the time we could spare some bandwidth and offer a forth > library online if he wanted. He made the suggestion here and was > promptly ignored. So perhaps no one really cares enough to bother? > No enough kudos perhaps. > > There are forth FTP and other sites out there but they are more > like unmanaged "code dumps" than libraries. It's hard > to know if their creators tried and lost interest because of > everyone elses apathy about forth. People don't seem to > want to actually use "forth" as much as they want to be known > as a "creator" of "A" forth. > > Code dumps and link pages are easy - libraries take work. > It all comes down to money and time and enthusiasm though. As I said above, that's typical of some online communities. Professional Forthers are generally pretty busy working on some project under deadline. In their spare time hanging out on a hobbyist board is the last thing they want to do. I am grateful to the few professionals here who provide that point of view. 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 | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2016-11-29 14:31 +0100 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <o1k00a$to5$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #52944 |
In article <20161129004209.27f63172@_>, Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> wrote: >On Tue, 29 Nov 2016 15:22:40 +1100 >I'd argue that statement describes the failing of Forth, not it's >merit. That's part of the reason why Forth is called a "write-once" >language. The others being that it's simple syntax can be >exceptionally cryptic, the code can be untraceable or difficult to >understand, and Forth requires the user to juggle stack items. Without >a large, standardized, and ubiquitous set of functionality, every Forth >application has to develop it's own solution to the same basic >programming problems and situations. This requires extra work, time or >man-hours, on the part of the programmer, and interferes with >portability, as the resulting code is non-standard. The code is unique >to that application, when every application could've used the same >functionality. It also means that any bad solutions or poor designs >will be passed along forever with that application. It also means that My experience is that by using a previous design for a slightly different application exposes the flaws of the design. Very often when I discovered that I couldn't make a required change to a program, after redesigning it a bit, the change became trivial, sometimes even a one line changes. So reuse of code results in reusable code. >numerous programs will most assuredly have bad, buggy, or limited >implementations of functionality which is commonly used. A programmer >needs to have a certain set of standard tools or components which are >widely available and easy to use. They must be based on abstractions and most abstractions are leaky. So as long as you stay on the highway all goes smooth. Now try to make terminal program that works through USB with most of the single board computers on Windows, like I did. > > >Rod Pemberton > 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 | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-12-02 23:05 +1100 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <o1ro66$1ugl$1@gioia.aioe.org> |
| In reply to | #52944 |
Rod Pemberton wrote: > On Tue, 29 Nov 2016 15:22:40 +1100 > "HAA" <someone@microsoft.com> wrote: > > > hughaguilar96@gmail.com wrote: > > > > It would make more sense to compare Forth to C than to assembler > > > --- Forth and C have similar uses --- of course, C has been > > > described as a portable assembly-language, and for a long time I > > > thought of Forth as being an over-grown macro-assembler, so > > > comparing both of them to assembler is reasonable. > > > > Interesting C being described that way. It's low level in a sense > > but users are still at the mercy of compiler, presupplied libraries > > and standards. Forth is one of the few languages that's truly 'grass > > roots' - where users could create from ground up. No reliance on > > anybody or thing. Anyone that's used MASM has probably discovered > > there are things which can't be done, except perhaps awkwardly. So > > Forth gets a tick over asm :) > > > > "... where users could create from [the] ground up." > > I'd argue that statement describes the failing of Forth, not it's > merit. That's part of the reason why Forth is called a "write-once" > language. The others being that it's simple syntax can be > exceptionally cryptic, the code can be untraceable or difficult to > understand, and Forth requires the user to juggle stack items. Without > a large, standardized, and ubiquitous set of functionality, every Forth > application has to develop it's own solution to the same basic > programming problems and situations. This requires extra work, time or > man-hours, on the part of the programmer, and interferes with > portability, as the resulting code is non-standard. The code is unique > to that application, when every application could've used the same > functionality. It also means that any bad solutions or poor designs > will be passed along forever with that application. It also means that > numerous programs will most assuredly have bad, buggy, or limited > implementations of functionality which is commonly used. A programmer > needs to have a certain set of standard tools or components which are > widely available and easy to use. > > > Rod Pemberton Elsewhere you mention x86 assembly. You appear to acknowledge the skill of asm programmers who work in environments largely devoid of standards and libraries. Yet when Forth programmers do the same, it's seen as a "failing" of the language?
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> |
|---|---|
| Date | 2016-12-03 01:58 -0500 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <20161203015814.7443a2d2@_> |
| In reply to | #53042 |
On Fri, 2 Dec 2016 23:05:54 +1100 "HAA" <someone@microsoft.com> wrote: > Rod Pemberton wrote: > > On Tue, 29 Nov 2016 15:22:40 +1100 > > "HAA" <someone@microsoft.com> wrote: > > > hughaguilar96@gmail.com wrote: > > > > It would make more sense to compare Forth to C than to assembler > > > > --- Forth and C have similar uses --- of course, C has been > > > > described as a portable assembly-language, and for a long time I > > > > thought of Forth as being an over-grown macro-assembler, so > > > > comparing both of them to assembler is reasonable. > > > > > > Interesting C being described that way. It's low level in a sense > > > but users are still at the mercy of compiler, presupplied > > > libraries and standards. Forth is one of the few languages > > > that's truly 'grass roots' - where users could create from ground > > > up. No reliance on anybody or thing. Anyone that's used MASM > > > has probably discovered there are things which can't be done, > > > except perhaps awkwardly. So Forth gets a tick over asm :) > > > > > > > "... where users could create from [the] ground up." > > > > I'd argue that statement describes the failing of Forth, not it's > > merit. That's part of the reason why Forth is called a "write-once" > > language. The others being that it's simple syntax can be > > exceptionally cryptic, the code can be untraceable or difficult to > > understand, and Forth requires the user to juggle stack items. > > Without a large, standardized, and ubiquitous set of functionality, > > every Forth application has to develop it's own solution to the > > same basic programming problems and situations. This requires > > extra work, time or man-hours, on the part of the programmer, and > > interferes with portability, as the resulting code is > > non-standard. The code is unique to that application, when every > > application could've used the same functionality. It also means > > that any bad solutions or poor designs will be passed along forever > > with that application. It also means that numerous programs will > > most assuredly have bad, buggy, or limited implementations of > > functionality which is commonly used. A programmer needs to have a > > certain set of standard tools or components which are widely > > available and easy to use. > > > > Elsewhere you mention x86 assembly. You appear to acknowledge the > skill of asm programmers who work in environments largely devoid of > standards and libraries. Yet when Forth programmers do the same, > it's seen as a "failing" of the language? > It's a general failing of assembly too. There are various assembly libraries, but they don't generally come with the assembler. The failing is that you have to do much more work to do if coding in assembly, when you aren't using a library. If you are using an assembly library, you have to learn the intricacies of a non-standard, non-portable library. Assembly can be harder to test too, as you have to code your own print routines and other code pieces to help you debug it. Of course, the assembly code isn't portable like a high-level language. C and Forth are the two most ubiquitous languages, but one is still quite popular and the other almost dead. One has libraries and structured syntax, and one doesn't. It can be a failing of C too, if you don't fully use the C libraries, or if you restrict usage of C to C itself and just a portion of the C library, as some do. E.g., if you want the C code to compile with a less-developed, more primitive, or simpler C compiler, you don't want to make heavy use of the C libraries. You might restrict C library usage to just <stdio.h>. The libraries for the less-developed C compiler won't be as developed or, will have bugs. A number of well known C compilers have had various long-term non-compliance issues with the C standards too. Assembly is generally harder to work with, less forgiving, usually doesn't come with a code optimizer, and requires register juggling. This is much like Forth needing stack juggling. If the assembler doesn't have a good preprocessor, then you won't be able to use named variables in the assembly code either. This is a huge drawback. So, the best way to use assembly, IMO, is to extend or enhance or complement a high-level language. I.e., I don't recommend using assembly, unless it's for something small or trivial or something which simply can't be easily done in a high-level language without it, e.g., special file format, interfacing with the operating system, special processor instructions, high-speed math or graphics routine, etc. If you look at all the publicly available C code which has been produced over the decades, much of it is still available and many projects are still used or recycled. You can't say that about the huge quantity of MS-DOS programs which were released with assembly code. The vast majority of these programs are dead. When x86 PCs migrated from 16-bit to 32-bit, they couldn't be recompiled easily 32-bit. C code could. C code didn't need a rewrite. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-12-03 22:00 +1100 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <o1u8kr$1lui$1@gioia.aioe.org> |
| In reply to | #53056 |
Rod Pemberton wrote: > ... > If you look at all the publicly available C code which has been produced > over the decades, much of it is still available and many projects are > still used or recycled. You can't say that about the huge quantity of > MS-DOS programs which were released with assembly code. The vast > majority of these programs are dead. When x86 PCs migrated from 16-bit > to 32-bit, they couldn't be recompiled easily 32-bit. C code could. C > code didn't need a rewrite. The picture isn't as rosy as you make out. C itself has undergone changes starting with K&R. Code written on one compiler would often produce errors when compiled on another. It may be the original programmer's fault but it falls to you to sort it out. The same for programs with OS specific code. No language is a panacea. All expect you to deal with issues and all are subject to change. If your program relies on certain user-created libraries it may become invalid with the next release of the language. If you didn't write the library yourself you may not be in a position to update it, or it's impossible, and the life of your program ends there. Is Forth dead? Only for those not using it :)
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-11-23 10:11 +1100 |
| Message-ID | <o12jcb$1um9$1@gioia.aioe.org> |
| In reply to | #52807 |
Mark Wills wrote: > On Tuesday, 22 November 2016 08:03:00 UTC, Paul Rubin wrote: > > "HAA" <someone@microsoft.com> writes: > > > MOVETO ( x y -- ) is a general-purpose function in the graphics > > > package and requires the 2DUP here. I think you have hit on the > > > definitive Forth definition for RECT. My original was 14 > > > instructions, yours would make it 11. > > > > Heh, I'm sure others have done it better. Paul, do you really think so? The rect problem has been floating around since Leo Brodie posed it as a 'worst case scenario' in Thinking Forth. You should drop him a line with your solution :) > > Is this really the language we want to entice schoolkids into > > programming with?! :) Chuck claimed Forth was the only language that's fun. What other language entertains children of all ages? > Guys, > > Just use locals and quit with the stack thrashing s**t! > > WTF guys???!!!!! <SLAP!> > > :-) Yes but locals double the code size and are no fun at all :)
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-11-23 00:01 -0800 |
| Message-ID | <8737iiaald.fsf@nightsong.com> |
| In reply to | #52822 |
"HAA" <someone@microsoft.com> writes: > The rect problem has been floating around since Leo Brodie posed it as > a 'worst case scenario' in Thinking Forth. You should drop him a line > with your solution :) I found the rectangle discussion (called [BOX] in the book) in the local variables section of chapter 7. He calls them local variables but they're actually globals since I guess Forth back then didn't have what we now call locals. Also, he starts with the 4-parameter line drawing primitive that takes both endpoints, then suggests some alternatives. Basically he doesn't even try for a stack juggling solution. He suggests using variables and also suggests reorganizing the API in a few different ways. So, I doubt the stuff in this thread would interest him much, especially after all these years, and with him no longer involved with Forth afaict. I remember enjoying the book a lot and thinking it was way ahead of its time, so I may re-read it. Thanks for the reminder!
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2016-11-23 13:49 +0100 |
| Message-ID | <o1437t$pvn$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #52825 |
In article <8737iiaald.fsf@nightsong.com>, Paul Rubin <no.email@nospam.invalid> wrote: >"HAA" <someone@microsoft.com> writes: >> The rect problem has been floating around since Leo Brodie posed it as >> a 'worst case scenario' in Thinking Forth. You should drop him a line >> with your solution :) > >I found the rectangle discussion (called [BOX] in the book) in the local >variables section of chapter 7. He calls them local variables but >they're actually globals since I guess Forth back then didn't have what >we now call locals. Also, he starts with the 4-parameter line drawing >primitive that takes both endpoints, then suggests some alternatives. They may have a lifetime of the program, and they may be accessible from everywhere, but they are logically locals. Because in Forth visibility may be manipulated separately from other aspects, e.g. hiding them can be accomplished by manipulating the headers in the wordlists, links or some such. > >Basically he doesn't even try for a stack juggling solution. He >suggests using variables and also suggests reorganizing the API in a few >different ways. This way of using VARIABLE's is idiomatic Forth, as Elizabeth Rather has pointed out, time and again. There is school of dogmatic abhorrence of "global" parameters. In order to be a good programmer it suffices to be aware of the this advantages of global data. 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 | foxaudioresearch@gmail.com |
|---|---|
| Date | 2016-11-23 10:51 -0800 |
| Message-ID | <6a0d28fd-5269-484c-a5f4-ad956e24f860@googlegroups.com> |
| In reply to | #52830 |
I dimly remember reading something about that in Thinking Forth. It was challenging what bad thing was going to come along and accidentally clobber your global variable. It's your code so it is your responsibility to to not clobber the variable. It's very true that after using variables in a definition you could "behead" them in some systems so they are no longer accessible by the compiler. BF
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-11-24 09:26 -1000 |
| Message-ID | <6o-dnZsUAuJyo6rFnZ2dnUU7-ffNnZ2d@supernews.com> |
| In reply to | #52832 |
On 11/23/16 8:51 AM, foxaudioresearch@gmail.com wrote: > I dimly remember reading something about that in Thinking Forth. It was challenging what bad thing was going to come along and accidentally clobber your global variable. It's your code so it is your responsibility to to not clobber the variable. > > It's very true that after using variables in a definition you could "behead" them in some systems so they are no longer accessible by the compiler. > Any half-way civilized Forth compiler will give you a message if it's redefining something, so you can examine and fix it if needed. It's really pretty low-risk. 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-11-23 12:28 -0800 |
| Message-ID | <87y40a7xg3.fsf@nightsong.com> |
| In reply to | #52830 |
albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes: > They may have a lifetime of the program, and they may be accessible > from everywhere, but they are logically locals. Yeah I understood that and was just mentioning that Forth back then didn't have locals like now. I don't remember if the Thinking Forth dialect had wordlists. > This way of using VARIABLE's is idiomatic Forth, as Elizabeth Rather > has pointed out, time and again. Thinking Forth quoted Chuck saying to allocate true globals in the initialization screen, and pseudo-locals in the same screen where they were used. Back then the program and data were both held in ram, so if you had a chunk of code that needed a temp variable, you could probably afford a permanent ram cell since its ram consumption was much smaller than the code's. These days on MCU's, ram is often considerably more scarce than program memory. So allocating permanent ram for variables needed only temporarily is even less pleasant than before. > There is school of dogmatic abhorrence of "global" parameters. > In order to be a good programmer it suffices to be aware of the > this advantages of global data. With today's larger programs things get out of control more easily, but when the program is small enough, using globals like that is manageable.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-11-24 16:54 -0800 |
| Message-ID | <44bc2a65-afbe-4822-bd1d-e7b40a072bc2@googlegroups.com> |
| In reply to | #52830 |
On Wednesday, November 23, 2016 at 5:38:34 AM UTC-7, Albert van der Horst wrote: > In article <8737iiaald.fsf@nightsong.com>, > Paul Rubin <no.email@nospam.invalid> wrote: > >"HAA" <someone@microsoft.com> writes: > >> The rect problem has been floating around since Leo Brodie posed it as > >> a 'worst case scenario' in Thinking Forth. You should drop him a line > >> with your solution :) > > > >I found the rectangle discussion (called [BOX] in the book) in the local > >variables section of chapter 7. He calls them local variables but > >they're actually globals since I guess Forth back then didn't have what > >we now call locals. Also, he starts with the 4-parameter line drawing > >primitive that takes both endpoints, then suggests some alternatives. > > They may have a lifetime of the program, and they may be accessible > from everywhere, but they are logically locals. > Because in Forth visibility may be manipulated separately from other > aspects, e.g. hiding them can be accomplished by manipulating the > headers in the wordlists, links or some such. > > > > >Basically he doesn't even try for a stack juggling solution. He > >suggests using variables and also suggests reorganizing the API in a few > >different ways. > > This way of using VARIABLE's is idiomatic Forth, as Elizabeth Rather > has pointed out, time and again. > There is school of dogmatic abhorrence of "global" parameters. > In order to be a good programmer it suffices to be aware of the > this advantages of global data. Using global variables is idiotic --- this will not be idiomatic Straight Forth. Elizabeth Rather says: ----------------------------------------------------------------------- Truly, I don't see the point of all this paranoia about reentrancy, particularly in systems without a multitasker. VARIABLE was *designed* for things that would be used in multiple definitions. I remember the horror of (*gasp*) global variables back in the 1960's in Fortran. But, frankly, in 30+ years of programming in Forth I never found them a problem. I think this is all about mythical dragons. ----------------------------------------------------------------------- Everybody is ignorant on a wide variety of subject. An ignoramus however, is proud of being ignorant, and consequently will never learn. Here is another quote: ----------------------------------------------------------------------- I hate locals :-) ----------------------------------------------------------------------- Elizabeth Rather is an ignoramus --- ANS-Forth was informed by ignorance and driven by arrogance --- ANS-Forth made the entire Forth community appear to be ignorant of even the most rudimentary computer-science concepts, such as reentrancy, that every first-year programmer should be aware of (concepts that I was familiar with when I was still in high-school).
[toc] | [prev] | [next] | [standalone]
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web