Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #16411 > unrolled thread
| Started by | "Charles Richmond" <numerist@aquaporin4.com> |
|---|---|
| First post | 2012-10-17 16:56 -0500 |
| Last post | 2012-10-22 04:20 -0400 |
| Articles | 20 on this page of 89 — 23 participants |
Back to article view | Back to comp.lang.forth
FORTH Trouble--Please Show Me "Charles Richmond" <numerist@aquaporin4.com> - 2012-10-17 16:56 -0500
Re: FORTH Trouble--Please Show Me all2001@spambog.com (Wolfgang Allinger) - 2012-10-17 19:11 -0300
Re: FORTH Trouble--Please Show Me Mark Wills <forthfreak@gmail.com> - 2012-10-18 01:15 -0700
Re: FORTH Trouble--Please Show Me "Charles Richmond" <numerist@aquaporin4.com> - 2012-10-18 05:25 -0500
Re: FORTH Trouble--Please Show Me mhx@iae.nl (Marcel Hendrix) - 2012-10-18 00:14 +0200
Re: FORTH Trouble--Please Show Me Spam@ControlQ.com - 2012-10-17 18:45 -0400
Re: FORTH Trouble--Please Show Me Anonymous <nobody@remailer.paranoici.org> - 2012-10-18 08:49 +0000
Re: FORTH Trouble--Please Show Me Spam@ControlQ.com - 2012-10-18 15:58 -0400
Re: FORTH Trouble--Please Show Me albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-10-18 21:53 +0000
Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-19 18:39 -0700
Re: FORTH Trouble--Please Show Me Mark Wills <markrobertwills@yahoo.co.uk> - 2012-10-19 23:22 -0700
Re: FORTH Trouble--Please Show Me "Charles Richmond" <numerist@aquaporin4.com> - 2012-10-21 13:40 -0500
Re: FORTH Trouble--Please Show Me "Elizabeth D. Rather" <erather@forth.com> - 2012-10-19 21:00 -1000
Re: FORTH Trouble--Please Show Me "A. K." <akk@nospam.org> - 2012-10-20 09:18 +0200
Re: FORTH Trouble--Please Show Me "Elizabeth D. Rather" <erather@forth.com> - 2012-10-20 08:40 -1000
Re: FORTH Trouble--Please Show Me mhx@iae.nl (Marcel Hendrix) - 2012-10-21 12:22 +0200
Re: FORTH Trouble--Please Show Me Doug Hoffman <glidedog@gmail.com> - 2012-10-21 08:46 -0400
Re: FORTH Trouble--Please Show Me mhx@iae.nl (Marcel Hendrix) - 2012-10-18 21:08 +0200
Re: FORTH Trouble--Please Show Me Mark Wills <markrobertwills@yahoo.co.uk> - 2012-10-18 12:29 -0700
Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-17 20:24 -0700
Re: FORTH Trouble--Please Show Me "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-19 19:46 -0400
Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-19 18:46 -0700
Re: FORTH Trouble--Please Show Me "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-20 21:03 -0400
Re: FORTH Trouble--Please Show Me "Elizabeth D. Rather" <erather@forth.com> - 2012-10-20 15:40 -1000
Re: FORTH Trouble--Please Show Me Paul Rubin <no.email@nospam.invalid> - 2012-10-20 18:52 -0700
Re: FORTH Trouble--Please Show Me "Elizabeth D. Rather" <erather@forth.com> - 2012-10-20 16:27 -1000
Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-20 20:56 -0700
Re: FORTH Trouble--Please Show Me "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-21 09:40 -0400
Re: FORTH Trouble--Please Show Me Paul Rubin <no.email@nospam.invalid> - 2012-10-21 12:51 -0700
Re: FORTH Trouble--Please Show Me mhx@iae.nl (Marcel Hendrix) - 2012-10-21 23:50 +0200
Re: FORTH Trouble--Please Show Me Paul Rubin <no.email@nospam.invalid> - 2012-10-21 17:11 -0700
Re: FORTH Trouble--Please Show Me mhx@iae.nl - 2012-10-22 00:19 -0700
Re: FORTH Trouble--Please Show Me Paul Rubin <no.email@nospam.invalid> - 2012-10-22 00:41 -0700
Re: FORTH Trouble--Please Show Me Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-22 09:31 -0500
Re: FORTH Trouble--Please Show Me Paul Rubin <no.email@nospam.invalid> - 2012-10-22 08:13 -0700
Re: FORTH Trouble--Please Show Me mhx@iae.nl (Marcel Hendrix) - 2012-10-22 21:40 +0200
Re: FORTH Trouble--Please Show Me Paul Rubin <no.email@nospam.invalid> - 2012-10-22 13:14 -0700
Re: FORTH Trouble--Please Show Me "Elizabeth D. Rather" <erather@forth.com> - 2012-10-22 10:41 -1000
Re: FORTH Trouble--Please Show Me mhx@iae.nl (Marcel Hendrix) - 2012-10-22 23:21 +0200
Re: FORTH Trouble--Please Show Me Paul Rubin <no.email@nospam.invalid> - 2012-10-22 14:27 -0700
Re: FORTH Trouble--Please Show Me "Elizabeth D. Rather" <erather@forth.com> - 2012-10-22 14:16 -1000
Re: FORTH Trouble--Please Show Me Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2012-10-23 21:42 +0100
Re: FORTH Trouble--Please Show Me vandys@vsta.org - 2012-10-22 00:24 +0000
Re: FORTH Trouble--Please Show Me "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-22 04:12 -0400
Re: FORTH Trouble--Please Show Me Paul Rubin <no.email@nospam.invalid> - 2012-10-22 01:40 -0700
Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-22 02:39 -0700
Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-22 02:30 -0700
Re: FORTH Trouble--Please Show Me "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-22 22:27 -0400
Re: FORTH Trouble--Please Show Me David Thompson <dave.thompson2@verizon.net> - 2012-11-04 22:18 -0500
Re: FORTH Trouble--Please Show Me Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-05 15:35 +0100
Re: FORTH Trouble--Please Show Me humptydumpty <ouatubi@gmail.com> - 2012-10-22 12:22 -0700
Re: FORTH Trouble--Please Show Me Paul Rubin <no.email@nospam.invalid> - 2012-10-22 12:51 -0700
Re: FORTH Trouble--Please Show Me humptydumpty <ouatubi@gmail.com> - 2012-10-22 23:40 -0700
Re: FORTH Trouble--Please Show Me anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-23 12:50 +0000
Re: FORTH Trouble--Please Show Me humptydumpty <ouatubi@gmail.com> - 2012-10-24 09:13 -0700
Re: FORTH Trouble--Please Show Me anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-25 12:31 +0000
Re: FORTH Trouble--Please Show Me humptydumpty <ouatubi@gmail.com> - 2012-10-26 09:58 -0700
Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-21 16:24 -0700
Re: FORTH Trouble--Please Show Me Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-22 02:51 +0200
Re: FORTH Trouble--Please Show Me Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-21 19:55 -0500
Re: FORTH Trouble--Please Show Me Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-22 03:02 +0200
Re: FORTH Trouble--Please Show Me "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-22 03:50 -0400
Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-22 01:03 -0700
Re: FORTH Trouble--Please Show Me stephenXXX@mpeforth.com (Stephen Pelc) - 2012-10-22 10:12 +0000
Re: FORTH Trouble--Please Show Me stephenXXX@mpeforth.com (Stephen Pelc) - 2012-10-22 10:08 +0000
Re: FORTH Trouble--Please Show Me Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-22 18:06 +0200
Re: FORTH Trouble--Please Show Me mhx@iae.nl (Marcel Hendrix) - 2012-10-22 22:14 +0200
Re: FORTH Trouble--Please Show Me albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-10-23 00:50 +0000
Re: FORTH Trouble--Please Show Me Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-23 03:43 +0200
Re: FORTH Trouble--Please Show Me Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-23 03:14 -0500
Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-22 19:54 -0700
Re: FORTH Trouble--Please Show Me Mark Wills <markrobertwills@yahoo.co.uk> - 2012-10-22 22:59 -0700
Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-24 09:23 -0700
Re: FORTH Trouble--Please Show Me stephenXXX@mpeforth.com (Stephen Pelc) - 2012-10-23 10:33 +0000
Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-24 10:05 -0700
Re: FORTH Trouble--Please Show Me Doug Hoffman <glidedog@gmail.com> - 2012-10-24 14:56 -0400
Re: FORTH Trouble--Please Show Me anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-23 11:50 +0000
Re: FORTH Trouble--Please Show Me stephenXXX@mpeforth.com (Stephen Pelc) - 2012-10-23 14:39 +0000
Application Benchmarks (was: FORTH Trouble--Please Show Me) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-23 15:59 +0000
Re: Application Benchmarks (was: FORTH Trouble--Please Show Me) stephenXXX@mpeforth.com (Stephen Pelc) - 2012-10-24 14:33 +0000
Re: Application Benchmarks (was: FORTH Trouble--Please Show Me) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-25 14:19 +0000
Re: FORTH Trouble--Please Show Me "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-22 03:56 -0400
Re: FORTH Trouble--Please Show Me "Elizabeth D. Rather" <erather@forth.com> - 2012-10-21 22:12 -1000
Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-22 02:51 -0700
Re: FORTH Trouble--Please Show Me Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-21 05:29 -0500
Re: FORTH Trouble--Please Show Me "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-21 09:35 -0400
Re: FORTH Trouble--Please Show Me Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-21 15:44 +0200
Re: FORTH Trouble--Please Show Me Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-21 18:43 -0500
Re: FORTH Trouble--Please Show Me "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-22 04:20 -0400
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2012-10-22 14:16 -1000 |
| Message-ID | <_Iqdnb8d1p5EfBjNnZ2dnUVZ_o6dnZ2d@supernews.com> |
| In reply to | #16600 |
On 10/22/12 11:27 AM, Paul Rubin wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> A better implementation would be to put those values in a reusable >> space such as PAD. > > Then they could get overwritten by something else while still in use. > Really, we're talking about a language feature that just doesn't fit > into the Forth way of doing things. The most sensible approximation is > probably with OOP and whatever methods Forthers normally use to reclaim > storage from dead objects. > Probably not. PAD is entirely under the control of the application programmer, systems are forbidden to use it. It is not common practice in Forth to "reclaim" storage. Instead, we prefer to use temporary buffers in unallocated space, of which PAD is the most standard and most easily manageable. Depending on the implementation, there are anywhere from hundreds to millions of bytes of space there. An application can define buffers at PAD, PAD+n, etc. They are easily reusable within a section of code that the programmer manages. In multitasked Forths, each task has its own PAD workspace. 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 | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2012-10-23 21:42 +0100 |
| Message-ID | <k66vfk$kal$1@dont-email.me> |
| In reply to | #16602 |
On 23/10/2012 01:16, Elizabeth D. Rather wrote: > On 10/22/12 11:27 AM, Paul Rubin wrote: >> "Elizabeth D. Rather" <erather@forth.com> writes: >>> A better implementation would be to put those values in a reusable >>> space such as PAD. >> >> Then they could get overwritten by something else while still in use. >> Really, we're talking about a language feature that just doesn't fit >> into the Forth way of doing things. The most sensible approximation is >> probably with OOP and whatever methods Forthers normally use to reclaim >> storage from dead objects. >> > > Probably not. PAD is entirely under the control of the application > programmer, systems are forbidden to use it. Not quite true as a system can provide non-standard words that *can* use PAD. Also a system can move PAD (which is the same as corrupting it as far as an application programmer is concerned) if anything is added to the dictionary or dataspace allotted. So you probably wouldn't want to use PAD if creating closures etc. > > It is not common practice in Forth to "reclaim" storage. Instead, we > prefer to use temporary buffers in unallocated space, of which PAD is > the most standard and most easily manageable. Depending on the > implementation, there are anywhere from hundreds to millions of bytes of > space there. A portable program can only assume PAD can hold 84 characters. The upshot is that you have to be very careful when using PAD i.e the dictionary and use of dataspace are static, be wary of using non-standard words provided by a system and, if you want the program to run on other ANS Forth systems, don't use PAD for more than 84 characters. -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | vandys@vsta.org |
|---|---|
| Date | 2012-10-22 00:24 +0000 |
| Message-ID | <aeji28FfqunU1@mid.individual.net> |
| In reply to | #16545 |
Paul Rubin <no.email@nospam.invalid> wrote:
> "Rod Pemberton" <do_not_have@notemailnotz.cnm> writes:
>> C has structs and arrays. That's what's needed.
> Well, C doesn't really have arrays ;-).
Well, no, C really does have arrays. You're confused because C also has
a connection between pointer arithmetic and arrays. But C does also have
plain old arrays. If I do array accesses like:
int
myfunc(void)
{
int a[4][4];
int x, y;
for (x = 0; x < 4; ++x) {
for (y = 0; y < 4; ++y) {
a[x][y] = x*y;
}
}
}
a[] is *not* an array of pointers. a[1][2] is calculated in the
classic Fortran style by scaling the indices of each subscript of
the multi-dimensional array.
--
Andy Valencia
Home page: http://www.vsta.org/andy/
To contact me: http://www.vsta.org/contact/andy.html
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailnotz.cnm> |
|---|---|
| Date | 2012-10-22 04:12 -0400 |
| Message-ID | <k62uto$nib$1@speranza.aioe.org> |
| In reply to | #16545 |
"Paul Rubin" <no.email@nospam.invalid> wrote in message news:7x3917hacl.fsf@ruckus.brouhaha.com... > "Rod Pemberton" <do_not_have@notemailnotz.cnm> writes: > > C has structs and arrays. That's what's needed. > > Well, C doesn't really have arrays ;-). > That's true. But, I can't seem to convince other C programmers, be it novices or "experts" of that. So, I've stopped placing arrays in quotes and preferencing it with: C as in C "arrays". And, I always seem to get one guy from comp.lang.c that insists C does have arrays... Of course, they've never read the early B and C papers by Dennis Ritchie, Brian Kernighan, Ken Thompson, and Steve Johnson where this is revealed, or even realize a famous quote they've likely quoted applies to arrays in C. Most C programmers don't seem to understand how C fits onto assembly or is converted to it. They all believe that a house (C specification) without a foundation (assembly and a machine model) is perfectly valid. Of course, as those original authors and others like Samuel Harbison and Guy Steele, Jr. have noted, that's not true either. C fits onto certain processor architectures very well and doesn't fit others. > > "Closures" seems to be the one "magic" feature that everyone seems to > > think is missing from their favorite language. What's so special about > > closures? > > They're not magic. You can do similar things with OOP or structs > containing function pointers and data, but closures avoid a lot of > syntactic clutter and bureaucracy compared to that. Example in Python: > > def square(x): > return x*x > > def derivative(f, h): # approximate numerical derivative > def df(x): > return (f(x+h) - f(x)) / h > return df > > print square(3) # prints 9 > print derivative(square,0.0001)(3) # prints approximately 6 > > You could write something like "derivative" in C with function pointers, > but it would be much messier. I only understand this in two ways: 1) passing function pointers 2) as macro processing I don't understand this in the object-oriented sense of code plus data that is always mentioned in regards to closures. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-10-22 01:40 -0700 |
| Message-ID | <7xd30a528l.fsf@ruckus.brouhaha.com> |
| In reply to | #16563 |
"Rod Pemberton" <do_not_have@notemailnotz.cnm> writes: > I only understand this in two ways: > > 1) passing function pointers > 2) as macro processing > > I don't understand this in the object-oriented sense of code plus data that > is always mentioned in regards to closures. There is no macro processing going on. The thing returned from derivative is a structure containing a pointer to some code (the function that computes (f(x+h)-f(x))/h given f and h, plus some data (a pointer to the function f, and the number h). It's messy to do in C partly because of having to deal with those pointers and structures explicitly, and partly with having to allocate and free the storage for them.
[toc] | [prev] | [next] | [standalone]
| From | Hugh Aguilar <hughaguilar96@yahoo.com> |
|---|---|
| Date | 2012-10-22 02:39 -0700 |
| Message-ID | <530cdf35-b6ab-4b53-89be-d1ad85f1273a@tr7g2000pbc.googlegroups.com> |
| In reply to | #16566 |
On Oct 22, 1:40 am, Paul Rubin <no.em...@nospam.invalid> wrote: > "Rod Pemberton" <do_not_h...@notemailnotz.cnm> writes: > > I only understand this in two ways: > > > 1) passing function pointers > > 2) as macro processing > > > I don't understand this in the object-oriented sense of code plus data that > > is always mentioned in regards to closures. > > There is no macro processing going on. The thing returned from > derivative is a structure containing a pointer to some code (the > function that computes (f(x+h)-f(x))/h given f and h, plus some data (a > pointer to the function f, and the number h). It's messy to do in C > partly because of having to deal with those pointers and structures > explicitly, and partly with having to allocate and free the storage for > them. It is messy to do in Forth because the function passed in doesn't have access to the parent function's local variables. This is what Straight Forth will provide. In the novice package I wrote the iterators such as EACH in such a way that they held all of their internal data on the return stack when calling the function that was passed in. This means that the passed-in function has access to the parameter stack --- everything that the parent function had on the stack is right there available for the passed-in function to modify. This is how the passed-in function communicates with the parent function. It is a half-step towards closures. Everything in the novice package is just a work-around for all of the problems in ANS-Forth --- it is depressing --- it inspires me to write my own Forth and forget about ANS-Forth altogether. I wouldn't mess with anything like this in C. For one thing, typedefing a pointer to a function is just painful. Also, the function is not going to have access to the parent function's local variables, which is the whole point of the exercise. C is actually much worse than Forth --- and Forth is pretty bad.
[toc] | [prev] | [next] | [standalone]
| From | Hugh Aguilar <hughaguilar96@yahoo.com> |
|---|---|
| Date | 2012-10-22 02:30 -0700 |
| Message-ID | <c5c77fa4-fa4c-465d-b702-3af8a402abcc@q7g2000pbj.googlegroups.com> |
| In reply to | #16563 |
On Oct 22, 1:08 am, "Rod Pemberton" <do_not_h...@notemailnotz.cnm> wrote: > Of course, they've never read the early B and C papers by Dennis Ritchie, > Brian Kernighan, Ken Thompson, and Steve Johnson where this is revealed, or > even realize a famous quote they've likely quoted applies to arrays in C. > > Most C programmers don't seem to understand how C fits onto assembly or is > converted to it. They all believe that a house (C specification) without a > foundation (assembly and a machine model) is perfectly valid. > > Of course, as those original authors and others like Samuel Harbison and Guy > Steele, Jr. have noted, that's not true either. C fits onto certain > processor architectures very well and doesn't fit others. Does your extensive reading on C include the ugly-fish book? http://www.e-reading.org.ua/bookreader.php/138815/Expert_C_Programming%3A_Deep_C_Secrets.pdf
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailnotz.cnm> |
|---|---|
| Date | 2012-10-22 22:27 -0400 |
| Message-ID | <k64v38$rdu$1@speranza.aioe.org> |
| In reply to | #16568 |
"Hugh Aguilar" <hughaguilar96@yahoo.com> wrote in message news:c5c77fa4-fa4c-465d-b702-3af8a402abcc@q7g2000pbj.googlegroups.com... > On Oct 22, 1:08 am, "Rod Pemberton" <do_not_h...@notemailnotz.cnm> > wrote: ... > > Of course, they've never read the early B and C papers by Dennis > > Ritchie, Brian Kernighan, Ken Thompson, and Steve Johnson > > where this is revealed, or even realize a famous quote they've > > likely quoted applies to arrays in C. Most C programmers don't > > seem to understand how C fits onto assembly or is converted to it. > > They all believe that a house (C specification) without a > > foundation (assembly and a machine model) is perfectly valid. > > > > Of course, as those original authors and others like Samuel Harbison > > and Guy Steele, Jr. have noted, that's not true either. C fits onto > > certain processor architectures very well and doesn't fit others. > > Does your extensive reading on C include the ugly-fish book? > Yes, it does, many years ago, in book form. I bought it. Was there a section in the .pdf that you want me to re-read? I have a large number of C books in my library. I've read all of them too. I'm not claiming that I remember any of them ... One book not in my C library is the one by K&R. At the time, I deemed it "unworthy" (too simple) by the time I started buying books on C, mostly early 1990's but upto early 2000's. Unfortunately, all of my C books have been boxed up for many years now, except for two: Harbison and Steele's "C: A Reference Manual" 3rd. Ed., and Plauger's "The Standard C Library". That latter is not really needed, but is informative if you don't have any idea of how a C library is constructed. It's built from only 18 or so system functions and the C language, like Forth using "primitives". The first is invaluable, if you're a C programmer. All the other books on C and C++ were basically a waste of money. Fortunately, I don't think I bought any "bad C" books by Schildt, or the book "C Unleashed" by numerous self-declared C "experts" from comp.lang.c. Today, you can get a number of C books in .pdf form for free, such as the modern version of K&R's book, or ANSI/ISO 'C Rationale' document, or Bell Telephone's 1974 "C Reference Manual" by Ritchie, as well as the ISO C draft specifications. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | David Thompson <dave.thompson2@verizon.net> |
|---|---|
| Date | 2012-11-04 22:18 -0500 |
| Message-ID | <3vbe98hve4noju3pvl05nukl0rm7dqngss@4ax.com> |
| In reply to | #16563 |
On Mon, 22 Oct 2012 04:12:16 -0400, "Rod Pemberton" <do_not_have@notemailnotz.cnm> wrote: > "Paul Rubin" <no.email@nospam.invalid> wrote in message > news:7x3917hacl.fsf@ruckus.brouhaha.com... > > "Rod Pemberton" <do_not_have@notemailnotz.cnm> writes: > > > C has structs and arrays. That's what's needed. > > > > Well, C doesn't really have arrays ;-). > > > > That's true. But, I can't seem to convince other C programmers, be it > novices or "experts" of that. So, I've stopped placing arrays in quotes > and preferencing it with: C as in C "arrays". > > And, I always seem to get one guy from comp.lang.c that insists C does have > arrays... > > Of course, they've never read the early B and C papers by Dennis Ritchie, > Brian Kernighan, Ken Thompson, and Steve Johnson where this is revealed, or > even realize a famous quote they've likely quoted applies to arrays in C. > BCPL and B, and C, have arrays aka vectors in memory, but the first two don't have them in the (named) variable. I'm not sure which papers you mean. The most definitive I've seen is Ritchie's for ACM's 2nd conference on the History of Programming Languages (abbreviated HOPL2) in 1993 which explains carefully that the replacement of a pointer (to an actual array) with an actual array (that converts to a pointer) was one of the changes that made the first "Embryonic" C a different language from B and even "New B". http://cm.bell-labs.com/who/dmr/chist.html
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-11-05 15:35 +0100 |
| Message-ID | <1711866.BFPYEF2kHx@sunwukong.fritz.box> |
| In reply to | #17051 |
David Thompson wrote: > I'm not sure which papers you mean. The most definitive I've seen is > Ritchie's for ACM's 2nd conference on the History of Programming > Languages (abbreviated HOPL2) in 1993 which explains carefully that > the replacement of a pointer (to an actual array) with an actual array > (that converts to a pointer) was one of the changes that made the > first "Embryonic" C a different language from B and even "New B". Funny enough is that Go (the C-like language made by Ken Thompson) again has real arrays and even slices (this is something that you can expand up to the array limits it is inside), passed as addr+len (and in case of a slice as a pair of addr+len, one the bounds, one the actual slice). -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | humptydumpty <ouatubi@gmail.com> |
|---|---|
| Date | 2012-10-22 12:22 -0700 |
| Message-ID | <11e9d197-43f7-4a76-97c1-e74e8cb19dad@googlegroups.com> |
| In reply to | #16545 |
On Sunday, October 21, 2012 7:52:00 PM UTC, Paul Rubin wrote:
> "Rod Pemberton" <do_not_have@notemailnotz.cnm> writes:
>
> > C has structs and arrays. That's what's needed.
>
>
>
> Well, C doesn't really have arrays ;-).
>
>
>
> > "Closures" seems to be the one "magic" feature that everyone seems to think
>
> > is missing from their favorite language. What's so special about closures?
>
>
>
> They're not magic. You can do similar things with OOP or structs
>
> containing function pointers and data, but closures avoid a lot of
>
> syntactic clutter and bureaucracy compared to that. Example in Python:
>
>
>
> def square(x):
>
> return x*x
>
>
>
> def derivative(f, h): # approximate numerical derivative
>
> def df(x):
>
> return (f(x+h) - f(x)) / h
>
> return df
>
>
>
> print square(3) # prints 9
>
> print derivative(square,0.0001)(3) # prints approximately 6
>
>
>
> You could write something like "derivative" in C with function pointers,
>
> but it would be much messier.
>
>
>
> > C has been used to implement nearly all, if not all, of the languages on
>
> > Wikipedia's "closure" page that have closures or closure like structures. I
>
> > know I've been over _this_ previously on c.l.f. ...
>
>
>
> It's just the usual situation of using a simpler tool to implement a
>
> more advanced one. Jet engines are made using screwdrivers, not the
>
> other way around. C is the screwdriver in that picture.
Hi Paul!
Tested in gforth:
: fsqr ( F: x -- y )
fdup f* ;
: derivative ( -- xt[F:x--y] ) ( F: h -- )
:noname
postpone fdup fdup postpone fliteral postpone f+ ' dup compile,
postpone fswap compile, postpone f- postpone fliteral
postpone f/ postpone ;
; immediate
3e0 1e-4 derivative fsqr execute
Have a nice day,
humptydumpty
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-10-22 12:51 -0700 |
| Message-ID | <7xr4oqs2u3.fsf@ruckus.brouhaha.com> |
| In reply to | #16586 |
humptydumpty <ouatubi@gmail.com> writes: > : derivative ( -- xt[F:x--y] ) ( F: h -- ) > :noname > postpone fdup fdup postpone fliteral postpone f+ ' dup compile, > postpone fswap compile, postpone f- postpone fliteral > postpone f/ postpone ; > ; immediate > > 3e0 1e-4 derivative fsqr execute Thanks. I don't really understand that but I thought I'd test it. I wrote: : dsin ( F: x -- y ) 1e-4 derivative fsin execute ; which should approximately compute cos x, by taking the derivative of sin at x. It gave me a floating stack undeflow error as soon as I tried to compile the word. Any advice? The next thing I wanted to try was finding -sin(x) by differentiating again: : d2sin ( F: x -- y) 1e-4 derivative dsin execute ; Overall I think the solution uses too much metaprogramming.
[toc] | [prev] | [next] | [standalone]
| From | humptydumpty <ouatubi@gmail.com> |
|---|---|
| Date | 2012-10-22 23:40 -0700 |
| Message-ID | <7d17f5dc-afe9-4e9b-8d68-d14fa0485523@googlegroups.com> |
| In reply to | #16588 |
On Monday, October 22, 2012 10:51:01 PM UTC+3, Paul Rubin wrote:
> humptydumpty writes:
>
> > : derivative ( -- xt[F:x--y] ) ( F: h -- )
>
> > :noname
>
> > postpone fdup fdup postpone fliteral postpone f+ ' dup compile,
>
> > postpone fswap compile, postpone f- postpone fliteral
>
> > postpone f/ postpone ;
>
> > ; immediate
>
> >
>
> > 3e0 1e-4 derivative fsqr execute
>
Hi!
> Thanks. I don't really understand
It's nothing magic, `derivative' compiles a new unnamed definition.
To see what compiles do `1e-4 derivative fsqr xt-see'. You will understand.
> : dsin ( F: x -- y ) 1e-4 derivative fsin execute ;
> It gave me a floating stack undeflow error as soon as I tried
> to compile the word. Any advice?
Because it wants `1e-4' at compile-time, don't have it and aborts.
I wrote example to be used only at execute-time. It cannot be used at compile-time, as Forth don't support compiling nested definitions.
To meet your new requirement we resort to:
: (derivative) ( "word[F:x--y]" -- ) ( F: h -- ;need at compile-time)
\G Compiles a 'derivative block' into current definition
postpone fdup fdup postpone fliteral postpone f+ ' dup compile,
postpone fswap compile, postpone f- postpone fliteral
postpone f/
; immediate
: derivative ( "word[F:x--y]" -- xt[F:x--y] ) ( F: h -- )
:noname postpone (derivative) postpone ; ; immediate
1e-4 fconstant (GSTEP) immediate \ Grid Step, at compile-time
: fdsin ( F: x -- y )
(GSTEP) (derivative) fsin ;
: fd2sin ( F: x -- y )
(GSTEP) (derivative) fdsin ;
: fsqr fdup f* ;
Tests:
3e0 (GSTEP) derivative fsqr execute f. 6.00010000001205 ok
0e0 fsin f. 0. ok
0e0 fdsin f. 0.999999998333333 ok
0e0 fd2sin f. -0.0000999999993922529 ok
cr .s f.s
<0> <0> ok
> Overall I think the solution uses too much metaprogramming.
Once you get the flavour, is not that much.. ;)
Have a nice day,
humptydumpty
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-10-23 12:50 +0000 |
| Message-ID | <2012Oct23.145002@mips.complang.tuwien.ac.at> |
| In reply to | #16612 |
humptydumpty <ouatubi@gmail.com> writes:
>On Monday, October 22, 2012 10:51:01 PM UTC+3, Paul Rubin wrote:
>> humptydumpty writes:
>>
>> > : derivative ( -- xt[F:x--y] ) ( F: h -- )
>>
>> > :noname
>>
>> > postpone fdup fdup postpone fliteral postpone f+ ' dup compile,
>>
>> > postpone fswap compile, postpone f- postpone fliteral
>>
>> > postpone f/ postpone ;
>>
>> > ; immediate
>>
>> >
>>
>> > 3e0 1e-4 derivative fsqr execute
>>
>Hi!
>
>> Thanks. I don't really understand
>It's nothing magic, `derivative' compiles a new unnamed definition.
>To see what compiles do `1e-4 derivative fsqr xt-see'. You will understand.
>
>> : dsin ( F: x -- y ) 1e-4 derivative fsin execute ;
>> It gave me a floating stack undeflow error as soon as I tried
>> to compile the word. Any advice?
>
>Because it wants `1e-4' at compile-time, don't have it and aborts.
>I wrote example to be used only at execute-time. It cannot be used at compile-time, as Forth don't support compiling nested definitions.
No nested definitions necessary here. The problem is that DERIVATIVE
parses, and if you do that, you have to decide if you want to parse
during compilation or at run-time. The better approach is to avoid
parsing by passing in the word as xt. Maybe the following will also
be easier to understand in other ways:
: derivative { xt1 F: r -- xt2 }
:noname ]]
fdup [[ r ]] fliteral f+ [[ xt1 compile, ]] fswap [[ xt1 compile, ]] f-
[[ r ]] fliteral f/ ;
[[ ;
: dsin ( rx -- ry ) 1e-4 ['] fsin derivative execute ;
1e dsin f.
Of course Paul's use of currying is totally pointless in this case,
and the memory for the anonymous definition is not reclaimed. If he
does not want to waste that memory, it is easy to write a non-curried
variant of DERIVATIVE with a stack effect like: ( xt1 r rx -- ry ).
- 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 2012: http://www.euroforth.org/ef12/
[toc] | [prev] | [next] | [standalone]
| From | humptydumpty <ouatubi@gmail.com> |
|---|---|
| Date | 2012-10-24 09:13 -0700 |
| Message-ID | <db63d141-9d7f-454d-a4b4-f5ea5c556be7@googlegroups.com> |
| In reply to | #16620 |
On Tuesday, October 23, 2012 1:16:23 PM UTC, Anton Ertl wrote:
> humptydumpty writes:
>
> >On Monday, October 22, 2012 10:51:01 PM UTC+3, Paul Rubin wrote:
>
> >> humptydumpty writes:
>
> >>
>
> >> > : derivative ( -- xt[F:x--y] ) ( F: h -- )
>
> >>
>
> >> > :noname
>
> >>
>
> >> > postpone fdup fdup postpone fliteral postpone f+ ' dup compile,
>
> >>
>
> >> > postpone fswap compile, postpone f- postpone fliteral
>
> >>
>
> >> > postpone f/ postpone ;
>
> >>
>
> >> > ; immediate
>
> >>
>
> >> >
>
> >>
>
> >> > 3e0 1e-4 derivative fsqr execute
>
> >>
>
> >Hi!
>
> >
>
> >> Thanks. I don't really understand
>
> >It's nothing magic, `derivative' compiles a new unnamed definition.
>
> >To see what compiles do `1e-4 derivative fsqr xt-see'. You will understand.
>
> >
>
> >> : dsin ( F: x -- y ) 1e-4 derivative fsin execute ;
>
> >> It gave me a floating stack undeflow error as soon as I tried
>
> >> to compile the word. Any advice?
>
> >
>
> >Because it wants `1e-4' at compile-time, don't have it and aborts.
>
> >I wrote example to be used only at execute-time. It cannot be used at compile-time, as Forth don't support compiling nested definitions.
>
>
>
> No nested definitions necessary here. The problem is that DERIVATIVE
>
> parses, and if you do that, you have to decide if you want to parse
>
> during compilation or at run-time. The better approach is to avoid
>
> parsing by passing in the word as xt. Maybe the following will also
>
> be easier to understand in other ways:
>
>
>
> : derivative { xt1 F: r -- xt2 }
>
> :noname ]]
>
> fdup [[ r ]] fliteral f+ [[ xt1 compile, ]] fswap [[ xt1 compile, ]] f-
>
> [[ r ]] fliteral f/ ;
>
> [[ ;
>
>
>
> : dsin ( rx -- ry ) 1e-4 ['] fsin derivative execute ;
>
>
>
> 1e dsin f.
>
>
>
> Of course Paul's use of currying is totally pointless in this case,
>
> and the memory for the anonymous definition is not reclaimed. If he
>
> does not want to waste that memory, it is easy to write a non-curried
>
> variant of DERIVATIVE with a stack effect like: ( xt1 r rx -- ry ).
>
>
>
> - 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 2012: http://www.euroforth.org/ef12/
Hi, Anton!
Thanks for your insights. Could you give me a hint where the use of parsing words become an abuse? Where is the borderline, if this exists?
Gforth info about parsing words: 'Parsing words are hard to use in other words, because it is hard to pass program-generated parameters through the input stream.' In what domains are used 'program-generated parameters'? Thanks.
Have a nice day,
humptydumpty
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-10-25 12:31 +0000 |
| Message-ID | <2012Oct25.143137@mips.complang.tuwien.ac.at> |
| In reply to | #16652 |
humptydumpty <ouatubi@gmail.com> writes:
>Thanks for your insights. Could you give me a hint where the use of parsing words become an abuse? Where is the borderline, if this exists?
It's a bad idea to have parsing words that are used inside and outside
colon definitions, and where the programmer wants the parsing to
happen at text interpretation time, like S", TO, and your parsing
DERIVATIVE.
Parsing words that are typically used in only one state, or are
intended to parse at run-time when compiled, such as defining words,
are less malicious, although still troublemakers: If you want to pass
a string that's not in the input stream as a parameter, how do you do
it? Ok, there is EXECUTE-PARSING (not standardized), but what if you
need to pass several string parameters?
Parsing words seem to be useful for words that are used directly by
the end user, but when called from other words, at some point such
words lead to problems. Some say that you should not do that, and
they are right: do not use parsing words.
>Gforth info about parsing words: 'Parsing words are hard to use in other words, because it is hard to pass program-generated parameters through the input stream.' In what domains are used 'program-generated parameters'? Thanks.
Everywhere. The string might come from a file, or a database, or it
might be produced by a concatenation or modification of other strings,
etc.
Please limit lines to about 70 characters. Thank you.
- 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 2012: http://www.euroforth.org/ef12/
[toc] | [prev] | [next] | [standalone]
| From | humptydumpty <ouatubi@gmail.com> |
|---|---|
| Date | 2012-10-26 09:58 -0700 |
| Message-ID | <171f3b9f-679c-4102-ac7c-14669415ff3b@googlegroups.com> |
| In reply to | #16697 |
On Thursday, October 25, 2012 12:31:37 PM UTC, Anton Ertl wrote: > humptydumpty <ouatubi@gmail.com> writes: > > >Thanks for your insights. Could you give me a hint where the use of parsing words become an abuse? Where is the borderline, if this exists? > > > > It's a bad idea to have parsing words that are used inside and outside > > colon definitions, and where the programmer wants the parsing to > > happen at text interpretation time, like S", TO, and your parsing > > DERIVATIVE. > > > > Parsing words that are typically used in only one state, or are > > intended to parse at run-time when compiled, such as defining words, > > are less malicious, although still troublemakers: If you want to pass > > a string that's not in the input stream as a parameter, how do you do > > it? Ok, there is EXECUTE-PARSING (not standardized), but what if you > > need to pass several string parameters? > > > > Parsing words seem to be useful for words that are used directly by > > the end user, but when called from other words, at some point such > > words lead to problems. Some say that you should not do that, and > > they are right: do not use parsing words. > > > > >Gforth info about parsing words: 'Parsing words are hard to use in other words, because it is hard to pass program-generated parameters through the input stream.' In what domains are used 'program-generated parameters'? Thanks. > > > > Everywhere. The string might come from a file, or a database, or it > > might be produced by a concatenation or modification of other strings, > > etc. > > > > Please limit lines to about 70 characters. Thank you. > > > > - 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 2012: http://www.euroforth.org/ef12/ Hi Anton! Thank you for clarifications. I never want to replace use of data-stack with parsing practice. Mostly wanted to write useful 'macros'. Could you give me a hint about this? \ Borrowed from old post in c.l.f. of J.Thomas : _eval_ ( "code block" -- ;compile-time ) char parse evaluate ; \ It could be an iterator, etc.. Here a generic loop: : _LOOP_ ( "code block" -- ;compile-time ) postpone DO _eval_ postpone LOOP ; immediate : test cr ." start.. " 10 0 _LOOP_ | I dup * . | ." end." ; see test test .s cr bye Have a nice day, humptydumpty
[toc] | [prev] | [next] | [standalone]
| From | Hugh Aguilar <hughaguilar96@yahoo.com> |
|---|---|
| Date | 2012-10-21 16:24 -0700 |
| Message-ID | <1d7dd236-5952-41eb-8fe6-1ae8acdc0f1b@i7g2000pbf.googlegroups.com> |
| In reply to | #16540 |
On Oct 21, 6:36 am, "Rod Pemberton" <do_not_h...@notemailnotz.cnm> wrote: > "Hugh Aguilar" <hughaguila...@yahoo.com> wrote in message > > news:717bab9e-8733-4399-a881-bd6766ba6ef2@i2g2000pbi.googlegroups.com...> On Oct 20, 6:00 pm, "Rod Pemberton" <do_not_h...@notemailnotz.cnm> > > wrote: > > ... > > > [Novices] should have basic stuff such as records, > > arrays and linked-lists available already. > > C has structs and arrays. That's what's needed. > > > This is necessary for even the simplest program. > > As C proves - it's missing them too - there is minimal need for > linked-lists. Are they needed from time to time? Yes. So are complex > numbers, but C didn't support those for a long time either. I was impressed by how Factor uses "sequences" as its primary data structure (these are arrays, but with Factor's dynamic memory they can be resized easily). There are other data structures available, and you can write whatever you want, but all the libraries primarily expect data in sequences. Similarly, Scheme and Lisp use lists, which behave very similarly to sequences although they are implemented differently internally. Lua has tables. Awk has associations, which are similar. I think that every language needs to have a standard data structure that all the libraries primarily work with. This is what Forth sorely lacks however. I implemented linked-lists in the novice package for this purpose. Almost all programs can use them. In some cases a different data structure, such as a hash table or a binary tree, might be a better choice (I provided association arrays based on LLRB trees in the novice package for anybody who needs this). You can go pretty far with lists however --- I use them all the time. Complex numbers are completely different. This isn't a general-purpose data-structure; this is for a specific and rare use. Fortran had complex numbers and matricies, but it was not a general-purpose language --- it was for numerical work (something that most programmers avoid like the plague). The word "computer" implies that the things compute numerically. This may have been true in the 1950s when the machines were replacing rooms full of guys with slide-rules, but it isn't true anymore. Beginning in the 1960s, almost all software involves converting data from one format to another. The machines should be called "formatters" rather than "computers." > > I remember in MS-DOS days that we had QBasic that lacked records. > > The typical solution was to define multiple arrays, each of which > > contained one field of the record. After you calculate your index it > > would be used in the appropriate array to get whatever field you need. > > Isn't that the way Forth _still_ does it? > > See CFA, LFA, PFA, or >BODY, >NAME, >LINK, etc. They all define > offsets from the start of a "struct". I think I may have mentioned this in > a prior conversation. The only C compiler I'm aware of that requires the > user to use offsets to implement struct's is an old and very primitive > compiler known as SmallC. I don't understand what you are saying. All records (structs) are implemented with offsets. You have the record with all of the fields adjacent to each other, and you access the fields by their offset from the base of the record. In QBasic, the fields weren't adjacent to each other. There was a separate array for each field. This was a crude workaround for QBasic's lack of support for records. > > I agree that Forth has weaknesses. I don't think that C is any better > > though; C is worse. > > Yet, nearly every language in existence uses or has used C as it's backend. > Doesn't that prove C's effectiveness? That doesn't "prove" anything. Look at how horribly slow Gforth is. That is because it was written in C rather than assembly-language. Your C-based Forth will also be horribly slow for the same reason. I have never seen any language written in C that provided decent speed. C is used primarily for convenience. We have scripting languages such as Lua or AutoLisp that don't have to be fast, but are just provided to allow the user of the software to customize it. We also have languages such as Gambit or Chicken Scheme that allow the programmer to take advantage of the many C libraries available. In all cases however, C implementations are grossly inefficient compared to assembly-language implementations. > > In Forth something like EACH is difficult to implement because > > ANS-Forth lacks closures. Both Forth and C are seriously hamstrung > > by their lack of support for closures. > > "Closures" seems to be the one "magic" feature that everyone seems to think > is missing from their favorite language. What's so special about closures? > > What does C need closures for? What does Forth ... ? > > I may have asked you that previously. I know I've asked others on > comp.lang.misc and elsewhere. I doubt I've gotten a satisfactory answer so > far. I may need to see sample code to grasp the issue ... Look at my slide-rule program. See how I use EACH. ANS-Forth doesn't really support closures, but this is pretty close. Closures are hugely important! I think that OOP is overrated; I'm only going to support a very rudimentary form of OOP in Straight Forth. By comparison however, closures can't be overrated --- they really simplify programs a lot. > C has been used to implement nearly all, if not all, of the languages on > Wikipedia's "closure" page that have closures or closure like structures. I > know I've been over _this_ previously on c.l.f. ... > > > [...] and C be phased out. > > Lol! (I just don't foresee that happening any time soon.) > > C still very effectively captures the "essence" of a modern microprocessor. That is definitely bad news, that the essence of modern microprocessors could be something so ugly and limiting as C. I think that is more the essence of C programmers, rather than the essence of the hardware --- the hardware can support any language. It is true that many microprocessors were designed to support C. The x86, for example, has support for the C stack-frame, and it even has ENTER and LEAVE instructions (as does the 68000). The processors were designed this way because C was popular, and this doesn't at all imply that C became popular because it C is a natural language for micro- processors --- you are getting cause and effect mixed up. Processors can be designed to support any language --- Forth and Lisp have both been targeted successfully. As a practical matter, I agree that C won't get phased out any time soon. I am learning Gambit Scheme primarily because it compiles into C and hence can use C libraries. There are a lot of C libraries! By comparison, Racket Scheme and the several Common Lisp systems can interface to C libraries but this isn't really what they are for --- they each have their own ecosystem of libraries. By using Gambit Scheme I can use C without having to actually program in C --- keep the ugliness hidden under the hood.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-10-22 02:51 +0200 |
| Message-ID | <4915176.bI2hdeRrkA@sunwukong.fritz.box> |
| In reply to | #16547 |
Hugh Aguilar wrote: > Look at how horribly slow Gforth is. That is because it was written in > C rather than assembly-language. Your C-based Forth will also be > horribly slow for the same reason. I don't know what you mean with "horribly slow". E.g. take a very classical Forth benchmark, the Byte sieve one. On my machine, gforth- fast does this benchmark in 0.325s (1000 times primes, x64 architecture). VFXForth, which has a way more sophisticated compiler, does it in 0.215s. bigForth, which is a less sophisticated native code compiler for x86, does it in 0.277s - both use the x86 architecture, i.e. the register starved 32 bit model. We did put quite some effort into Gforth to make it fast while still using the C compiler - the latter to make it easy enough to port. The effort to write a compiler like the one in VFX is tremendous, and not worth to repeat for more than a very few popular platforms. I.e. the result wouldn't be a very portable Forth. I'm not actually looking forward to your "straight Forth", because I don't think it ever will see light. But if it does, I hope it is at least a factor 10 faster than Gforth, because "horribly slow" is usually something you can't only measure, but you can really perceive as big difference. A factor 10 is perceivable. If you achieve this, I will call you Superman. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-10-21 19:55 -0500 |
| Message-ID | <sc2dneiPqJIaBBnNnZ2dnUVZ8imdnZ2d@supernews.com> |
| In reply to | #16551 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > Hugh Aguilar wrote: >> Look at how horribly slow Gforth is. That is because it was written in >> C rather than assembly-language. Your C-based Forth will also be >> horribly slow for the same reason. > > I don't know what you mean with "horribly slow". Hold on! I'm sure you just told me "Don't feed the trolls." Andrew.
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | comp.lang.forth
csiph-web