Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #43233 > unrolled thread
| Started by | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| First post | 2015-11-04 14:44 +0000 |
| Last post | 2015-11-08 06:12 -0500 |
| Articles | 20 on this page of 72 — 17 participants |
Back to article view | Back to comp.lang.forth
objects build up from other objects Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-04 14:44 +0000
Re: objects build up from other objects franck.bensusan@gmail.com - 2015-11-04 09:17 -0800
Re: objects build up from other objects Doug Hoffman <glidedog@gmail.com> - 2015-11-05 10:07 -0500
Re: objects build up from other objects Hans Bezemer <the.beez.speaks@gmail.com> - 2015-11-05 18:34 +0100
Re: objects build up from other objects Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-06 00:09 +0000
Re: objects build up from other objects Doug Hoffman <glidedog@gmail.com> - 2015-11-05 21:47 -0500
Re: objects build up from other objects Hans Bezemer <the.beez.speaks@gmail.com> - 2015-11-06 09:37 +0100
Re: objects build up from other objects Doug Hoffman <glidedog@gmail.com> - 2015-11-06 04:52 -0500
Re: objects build up from other objects Hans Bezemer <the.beez.speaks@gmail.com> - 2015-11-06 12:36 +0100
Re: objects build up from other objects Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-06 12:13 +0000
Re: objects build up from other objects hughaguilar96@gmail.com - 2015-11-06 15:32 -0800
Re: objects build up from other objects hughaguilar96@gmail.com - 2015-11-05 13:15 -0800
Re: objects build up from other objects franck.bensusan@gmail.com - 2015-11-05 15:19 -0800
Re: objects build up from other objects hughaguilar96@gmail.com - 2015-11-05 22:10 -0800
Re: objects build up from other objects franck.bensusan@gmail.com - 2015-11-07 07:50 -0800
Re: objects build up from other objects hughaguilar96@gmail.com - 2015-11-07 13:46 -0800
Re: objects build up from other objects franck.bensusan@gmail.com - 2015-11-07 14:46 -0800
Re: objects build up from other objects Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-06 00:20 +0000
Re: objects build up from other objects Ron Aaron <rambamist@gmail.com> - 2015-11-06 07:39 +0200
Re: objects build up from other objects Doug Hoffman <glidedog@gmail.com> - 2015-11-04 15:33 -0500
Re: objects build up from other objects Chris Curl <ccurl609@gmail.com> - 2015-11-06 06:31 -0800
Re: objects build up from other objects Hans Bezemer <the.beez.speaks@gmail.com> - 2015-11-06 18:48 +0100
Re: objects build up from other objects "Elizabeth D. Rather" <erather@forth.com> - 2015-11-06 08:15 -1000
Re: objects build up from other objects Doug Hoffman <glidedog@gmail.com> - 2015-11-06 13:44 -0500
Re: objects build up from other objects "Elizabeth D. Rather" <erather@forth.com> - 2015-11-06 11:10 -1000
Re: objects build up from other objects josv@planet.nl - 2015-11-06 15:19 -0800
Re: objects build up from other objects "Elizabeth D. Rather" <erather@forth.com> - 2015-11-06 14:54 -1000
Re: objects build up from other objects anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-07 16:57 +0000
Re: objects build up from other objects "Elizabeth D. Rather" <erather@forth.com> - 2015-11-07 08:13 -1000
Re: objects build up from other objects Chris Curl <ccurl609@gmail.com> - 2015-11-06 19:31 -0800
Re: objects build up from other objects hughaguilar96@gmail.com - 2015-11-06 20:03 -0800
Re: objects build up from other objects josv@planet.nl - 2015-11-07 01:43 -0800
Re: objects build up from other objects "HAA" <someone@microsoft.com> - 2015-11-07 15:03 +1100
Re: objects build up from other objects hughaguilar96@gmail.com - 2015-11-06 20:42 -0800
Re: objects build up from other objects Doug Hoffman <glidedog@gmail.com> - 2015-11-07 10:12 -0500
Re: objects build up from other objects Chris Curl <ccurl609@gmail.com> - 2015-11-07 10:01 -0800
Re: objects build up from other objects Doug Hoffman <glidedog@gmail.com> - 2015-11-08 08:22 -0500
Re: objects build up from other objects Chris Curl <ccurl609@gmail.com> - 2015-11-08 06:37 -0800
Re: objects build up from other objects "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-11-08 15:01 -0500
Re: objects build up from other objects Doug Hoffman <glidedog@gmail.com> - 2015-11-09 07:27 -0500
Re: objects build up from other objects "Elizabeth D. Rather" <erather@forth.com> - 2015-11-07 08:20 -1000
Re: objects build up from other objects franck.bensusan@gmail.com - 2015-11-08 23:44 -0800
Re: objects build up from other objects "Elizabeth D. Rather" <erather@forth.com> - 2015-11-08 21:58 -1000
Re: objects build up from other objects Mark Wills <markwills1970@gmail.com> - 2015-11-09 01:57 -0800
Re: objects build up from other objects Ron Aaron <rambamist@gmail.com> - 2015-11-09 12:46 +0200
Re: objects build up from other objects Mark Wills <markwills1970@gmail.com> - 2015-11-09 03:04 -0800
Re: objects build up from other objects hughaguilar96@gmail.com - 2015-11-09 23:14 -0800
Re: objects build up from other objects - even Forth? Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-11-09 12:15 +0000
Re: objects build up from other objects - even Forth? franck.bensusan@gmail.com - 2015-11-09 12:25 -0800
Re: objects build up from other objects - even Forth? Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-11-10 10:48 +0000
Re: objects build up from other objects - even Forth? franck.bensusan@gmail.com - 2015-11-10 04:31 -0800
Re: objects build up from other objects - even Forth? hughaguilar96@gmail.com - 2015-11-10 18:06 -0800
Re: objects build up from other objects - even Forth? franck.bensusan@gmail.com - 2015-11-11 00:49 -0800
Re: objects build up from other objects - even Forth? Paul Rubin <no.email@nospam.invalid> - 2015-11-11 01:13 -0800
Re: objects build up from other objects - even Forth? franck.bensusan@gmail.com - 2015-11-11 01:52 -0800
Re: objects build up from other objects - even Forth? hughaguilar96@gmail.com - 2015-11-11 15:54 -0800
Re: objects build up from other objects - even Forth? stephen@mpeforth.com (Stephen Pelc) - 2015-11-12 11:01 +0000
Re: objects build up from other objects - even Forth? hughaguilar96@gmail.com - 2015-11-12 11:07 -0800
Re: objects build up from other objects - even Forth? Paul Rubin <no.email@nospam.invalid> - 2015-11-11 15:55 -0800
Re: objects build up from other objects - even Forth? Mark Wills <markwills1970@gmail.com> - 2015-11-12 00:50 -0800
Re: objects build up from other objects - even Forth? Paul Rubin <no.email@nospam.invalid> - 2015-11-12 18:21 -0800
Re: objects build up from other objects anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-09 12:16 +0000
Re: objects build up from other objects Doug Hoffman <glidedog@gmail.com> - 2015-11-09 07:38 -0500
Re: objects build up from other objects franck.bensusan@gmail.com - 2015-11-09 04:15 -0800
Re: objects build up from other objects Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-09 15:29 +0000
Re: objects build up from other objects "Elizabeth D. Rather" <erather@forth.com> - 2015-11-09 09:09 -1000
Re: objects build up from other objects hughaguilar96@gmail.com - 2015-11-09 22:41 -0800
Re: objects build up from other objects Chris Curl <ccurl609@gmail.com> - 2015-11-06 19:14 -0800
Re: objects build up from other objects hughaguilar96@gmail.com - 2015-11-06 19:39 -0800
Re: objects build up from other objects Doug Hoffman <glidedog@gmail.com> - 2015-11-07 09:04 -0500
Re: objects build up from other objects lehs <skydda.barnen@gmail.com> - 2015-11-06 09:20 -0800
Re: objects build up from other objects Doug Hoffman <glidedog@gmail.com> - 2015-11-08 06:12 -0500
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-11-07 08:20 -1000 |
| Subject | Re: objects build up from other objects |
| Message-ID | <po6dndyySouf3KPLnZ2dnUU7-b_46u6z@supernews.com> |
| In reply to | #43300 |
On 11/7/15 5:12 AM, Doug Hoffman wrote: > On 11/6/15 4:10 PM, Elizabeth D. Rather wrote: >> On 11/6/15 8:44 AM, Doug Hoffman wrote: >>> On 11/6/15 9:31 AM, Chris Curl wrote: >>> >>>> Forth has its own strengths. It is my opinion that "we don't need no >>>> stinking object orientation in Forth". >>> >>> Other languages also support the following: >>> >>> - structured programming >>> - if/then/else program control >>> - loops >>> - case statements >>> - floating point >>> - variables >>> - local variables (Forth has 2 kinds of locals in the standard) >>> - structures >>> - a lot more >>> >>> Should we shun the above features in Forth just because "other languages >>> use them"? After all, we can't have any part of Forth have anything at >>> all in common with other languages now can we? >> >> Chris's point, which I agree with, is that Forth should have whatever >> facilities prove useful in application programming, but we shouldn't >> feel compelled to add a feature solely because another currently >> fashionable language has it. > > You state the obvious and Chris Curl did not say that. > > The topic of the post was/is "It would be interesting to see how (doing > x feature) works in other (extensions that might support x feature). > > Chris Curl responds by saying "we don't need that kind of extension at > all". But gives no *reason* other than a form of feature x exists in > C++. That is not a reason and it is off topic IMO. SwiftForth has long > supported a form of the feature being discussed. Should that feature be > removed from SF(rhetorical question)? I was addressing motivation. Adding a feature because other languages have it is a poor reason. As I described in another recent post, OO techniques have been used in Forth since the 70's. They are appropriate for some situations, including Windows features (which is the primary motivation in SwiftForth). Attempting to impose OO techniques on all programming seems as misguided as implementing a feature just to be a copycat. The needs of an application should drive the design of the program. 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 | franck.bensusan@gmail.com |
|---|---|
| Date | 2015-11-08 23:44 -0800 |
| Subject | Re: objects build up from other objects |
| Message-ID | <ad27da57-76c8-44d0-afad-87f1903af898@googlegroups.com> |
| In reply to | #43317 |
Le samedi 7 novembre 2015 19:20:51 UTC+1, Elizabeth D. Rather a écrit : > > I was addressing motivation. Adding a feature because other languages > have it is a poor reason. As I described in another recent post, OO > techniques have been used in Forth since the 70's. They are appropriate > for some situations, including Windows features (which is the primary > motivation in SwiftForth). Attempting to impose OO techniques on all > programming seems as misguided as implementing a feature just to be a > copycat. The needs of an application should drive the design of the program. > Hello, Can you give one "application need" that will disqualify OO to be used ? Or is it as simplistic as GUI = OO, not GUI = not OO ? All mainstream and popular languages that implement OO paradigm refute what your are saying : yes, it is possible to apply OO paradigm to many kind of applications, regardless their need. And this does not seems to be such a bad strategy if we look at those languages popularity. Let me tell you a secret : there are, somewhere, some people that are not beginning from scratch for each application, they are not recreating arrays, list, structure, ... everytime just because "the application needs drives the design" and they use OO as a paradigm, not as an extension dedicated to GUI. I know this seems totally crazy but it is the truth. Yes, how misguided they are... Franck
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-11-08 21:58 -1000 |
| Subject | Re: objects build up from other objects |
| Message-ID | <m8udnT9l5om4z93LnZ2dnUU7-R2dnZ2d@supernews.com> |
| In reply to | #43410 |
On 11/8/15 9:44 PM, franck.bensusan@gmail.com wrote: > Le samedi 7 novembre 2015 19:20:51 UTC+1, Elizabeth D. Rather a écrit : >> >> I was addressing motivation. Adding a feature because other languages >> have it is a poor reason. As I described in another recent post, OO >> techniques have been used in Forth since the 70's. They are appropriate >> for some situations, including Windows features (which is the primary >> motivation in SwiftForth). Attempting to impose OO techniques on all >> programming seems as misguided as implementing a feature just to be a >> copycat. The needs of an application should drive the design of the program. >> > > Hello, > > Can you give one "application need" that will disqualify OO to be used ? > Or is it as simplistic as GUI = OO, not GUI = not OO ? A purely procedural application, with essentially 1 each devices and processes. Most simple data acquisition projects. GUI is a good example of OO, but so are many other applications of which I've given recent examples (image processing, industrial controls, etc.). > All mainstream and popular languages that implement OO paradigm > refute what your are saying : yes, it is possible to apply OO paradigm > to many kind of applications, regardless their need. > And this does not seems to be such a bad strategy if we look at those > languages popularity. Depends on whether you care about code size, performance, and programming effort. If you do, then you want to match the coding paradigm to the problem. > Let me tell you a secret : there are, somewhere, some people that are > not beginning from scratch for each application, they are not recreating > arrays, list, structure, ... everytime just because "the application > needs drives the design" and they use OO as a paradigm, not as an extension > dedicated to GUI. Neither are Forth programmers who have written more than one application. As they gain experience, they have back pockets stuffed with strategies, and can modify something from one of them to today's need in tiny moments. Cheers, Elizabeth > I know this seems totally crazy but it is the truth. > > Yes, how misguided they are... -- ================================================== 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 | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-11-09 01:57 -0800 |
| Subject | Re: objects build up from other objects |
| Message-ID | <b805b945-b4ff-4ff5-9964-a1d408f9b130@googlegroups.com> |
| In reply to | #43412 |
On Monday, 9 November 2015 07:58:31 UTC, Elizabeth D. Rather wrote: > On 11/8/15 9:44 PM, franck.bensusan@gmail.com wrote: > > Le samedi 7 novembre 2015 19:20:51 UTC+1, Elizabeth D. Rather a écrit : > >> > >> I was addressing motivation. Adding a feature because other languages > >> have it is a poor reason. As I described in another recent post, OO > >> techniques have been used in Forth since the 70's. They are appropriate > >> for some situations, including Windows features (which is the primary > >> motivation in SwiftForth). Attempting to impose OO techniques on all > >> programming seems as misguided as implementing a feature just to be a > >> copycat. The needs of an application should drive the design of the program. > >> > > > > Hello, > > > > Can you give one "application need" that will disqualify OO to be used ? > > Or is it as simplistic as GUI = OO, not GUI = not OO ? > > A purely procedural application, with essentially 1 each devices and > processes. Most simple data acquisition projects. > > GUI is a good example of OO, but so are many other applications of which > I've given recent examples (image processing, industrial controls, etc.). > > > All mainstream and popular languages that implement OO paradigm > > refute what your are saying : yes, it is possible to apply OO paradigm > > to many kind of applications, regardless their need. > > And this does not seems to be such a bad strategy if we look at those > > languages popularity. > > Depends on whether you care about code size, performance, and > programming effort. If you do, then you want to match the coding > paradigm to the problem. > > > Let me tell you a secret : there are, somewhere, some people that are > > not beginning from scratch for each application, they are not recreating > > arrays, list, structure, ... everytime just because "the application > > needs drives the design" and they use OO as a paradigm, not as an extension > > dedicated to GUI. > > Neither are Forth programmers who have written more than one > application. As they gain experience, they have back pockets stuffed > with strategies, and can modify something from one of them to today's > need in tiny moments. > > Cheers, > Elizabeth > > > I know this seems totally crazy but it is the truth. > > > > Yes, how misguided they are... > > > > > -- > ================================================== > 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." > ================================================== One of the best examples of OO being useful in Forth would be Forth itself! A pure OO Forth would need only an object stack and a return stack. Integers, floats, strings, database connections, GUI object references would all go on the same stack regardless of type. Contrast that with todays situation where floats *may* go on the data stack, but may not, etc. This could actually simplify life for both the implementor and the programmer!
[toc] | [prev] | [next] | [standalone]
| From | Ron Aaron <rambamist@gmail.com> |
|---|---|
| Date | 2015-11-09 12:46 +0200 |
| Subject | Re: objects build up from other objects |
| Message-ID | <n1ptdu$4ev$1@dont-email.me> |
| In reply to | #43418 |
On 11/09/2015 11:57, Mark Wills wrote: > One of the best examples of OO being useful in Forth would be > Forth itself! A pure OO Forth would need only an object stack > and a return stack. Integers, floats, strings, database connections, > GUI object references would all go on the same stack regardless > of type. That's how it is in 8th, actually. All the data types can go on the same stack, and each takes only one "cell" (on the stack).
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-11-09 03:04 -0800 |
| Subject | Re: objects build up from other objects |
| Message-ID | <a7917368-3110-48a1-b2ab-d94d87ac014b@googlegroups.com> |
| In reply to | #43420 |
On Monday, 9 November 2015 10:46:31 UTC, Ron Aaron wrote: > On 11/09/2015 11:57, Mark Wills wrote: > > > One of the best examples of OO being useful in Forth would be > > Forth itself! A pure OO Forth would need only an object stack > > and a return stack. Integers, floats, strings, database connections, > > GUI object references would all go on the same stack regardless > > of type. > > That's how it is in 8th, actually. All the data types can go on the > same stack, and each takes only one "cell" (on the stack). Exactly. You could have an integer and an entire result set from an SQL query on the stack. They're both objects. In reality, the stack would be a list of object pointers to the real objects in the heap, but that's an implementation issue. Objects make sense in Forth. And so do locals. :-)
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-11-09 23:14 -0800 |
| Subject | Re: objects build up from other objects |
| Message-ID | <0930a730-0170-45ef-8fd9-e19300a95d6f@googlegroups.com> |
| In reply to | #43421 |
On Monday, November 9, 2015 at 4:04:05 AM UTC-7, Mark Wills wrote: > On Monday, 9 November 2015 10:46:31 UTC, Ron Aaron wrote: > > On 11/09/2015 11:57, Mark Wills wrote: > > > > > One of the best examples of OO being useful in Forth would be > > > Forth itself! A pure OO Forth would need only an object stack > > > and a return stack. Integers, floats, strings, database connections, > > > GUI object references would all go on the same stack regardless > > > of type. > > > > That's how it is in 8th, actually. All the data types can go on the > > same stack, and each takes only one "cell" (on the stack). > > Exactly. You could have an integer and an entire result set from an SQL > query on the stack. They're both objects. In reality, the stack would be > a list of object pointers to the real objects in the heap, but that's > an implementation issue. Objects make sense in Forth. And so do locals. > > :-) Well, in FloatForth there is a 64-bit stack, so one cell can hold different kinds of data: 1.) In the fixed-version a number is defined as a 64-bit fixed-point number with unity assumed to be 2^32. 2.) In the float-version a number is defined as a double-precision IEEE-754 float. 3.) In either version a string is a two 32-bit numbers (address and count) packed together into a 64-bit cell. It is possible to unpack a string into two cells of address and count, similar to what is used in ANS-Forth, but this is only done in low-level code. All the string functions that the programmer uses will work with single-cell strings. We have a HOF that iterates through a string and apply a quotation to every character --- --- a char is defined to be UTF-32 (the string is actually UTF-8, but this isn't important to the programmer because he doesn't work with the string at that low-level). It is also idiomatic for the programmer to rely heavily on structs as described by Mark Wills above. I've already covered this here: https://groups.google.com/forum/#!topic/comp.lang.forth/ZSmddcV_Idc On Saturday, October 31, 2015 at 2:10:24 PM UTC-7, hughag...@gmail.com wrote: > On Saturday, October 31, 2015 at 12:04:21 AM UTC-7, François wrote: > > tank's to all :-) > > > > my problem, is when i download a Forth, there is no example to help > > beginner for is first step... > > > > And the first step must be "fun" :-p > > > > (with my forth) i create the word BMP>SPR > > You give to it : name of BMP file, X,Y,W,H of a part of this bmp, > > and the of the new sprite. > > 54 32 32 32 BMP>SPR SPRITE1 TEST.BMP > > create a 32x32 sprite > > > > after that, in graphic mode, i just have to enter : > > 10 10 SPRITE1 > > to display my sprite at X:10 Y:10 > > > > easy, powerful ... so Forth :+) > > > > mmmh.... i wish to do the same with standard Forth.... > > Here is a quote from my file: http://www.forth.org/Stundurd.txt > --------------------------------------------------------------------------- > A good way to avoid stack-juggling is to use structs, and only have the pointers to the structs on the data-stack. Our LINE.LENGTH function shown earlier was an example of this. Stundurd provides a heap (that is something else we can expect that Charles Moore won't provide ever), so the heap should be used. Whenever several data are used together and are only meaningful in relation to each other (like the X and Y coordinates of a point), then these data should be packed together into a struct and the struct held in the heap, and only the pointer to the struct passed around on the stack. This greatly reduces the amount of data on the stack, which increases both readability and efficiency. > --------------------------------------------------------------------------- > > So far on comp.lang.forth, nobody has ever said anything in support of this. Also, I routinely see people doing what you are doing, which is to put all the parameters on the stack. This is a dead end! Your code will become increasingly difficult to write and hard to read, due to all of the stack-juggling. > > For example, your SPRITE1 would take one parameter, which is a pointer to a struct of data-type POINT that contains two fields, which are .X and .Y (note that the dot in front of a field name is my naming convention, which is derived from Pascal). Doing this wrong (having SPRITE1 take two parameters, which are the X and Y coordinates) is an easy trap to fall into because it seems simple and obvious at first, and there is little or no stack-juggling beyond what is required for one parameter. When you get more than one point however, such as the LINE.LENGTH function that I mentioned, then my method has two parameters (the two end points) and your method has four parameters (the X and Y for both end points) --- now you have more than three parameters on the stack, and three is generally considered to be the most that you want. Lets say that you have a function called LINE.INTERSECTION that returns the intersection point of two line segments --- it would have two parameters on the stack (pointers to two structs each of data-type LINE) --- this is as compared to 8 parameters which are the X and Y coordinates of all 4 end-points involved. > > You don't really need somebody to write a graphics package for you, and especially not if they do it wrong. You can write this yourself. What you need is a way to define structs. Reading "Starting Forth" and "Thinking Forth" or any other book from Forth Inc. will not help you, because none of these books teach you how to define structs. > > Download my novice package: http://www.forth.org/novice.html > Learn how to define structs with the FIELD definer. Also, learn how inheritance works (study the LIST.4TH file for this). Then write your own graphics code-library on top of the novice package. If you do this and it is good code, I will include it in the next novice package release. So far, nobody has ever written any code-library on top of the novice package --- you would be the first --- that was the original intention though, that the novice package would be the basis of a variety of code-libraries.
[toc] | [prev] | [next] | [standalone]
| From | Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> |
|---|---|
| Date | 2015-11-09 12:15 +0000 |
| Subject | Re: objects build up from other objects - even Forth? |
| Message-ID | <20151109121508.46ca9b27@TP-T500> |
| In reply to | #43418 |
On Mon, 9 Nov 2015 01:57:43 -0800 (PST) Mark Wills <markwills1970@gmail.com> wrote: > One of the best examples of OO being useful in Forth would be > Forth itself! A pure OO Forth would need only an object stack > and a return stack. Integers, floats, strings, database > connections, GUI object references would all go on the same > stack regardless of type. You can see an implementation of this in the Python stack engine - it's about two pages of code in C. But this is probably too much of a speed burden for those used to Forth. > Contrast that with todays situation where floats *may* go on > the data stack, but may not, etc. Some [no ref!] have used tagged data as a compromise: A stack item can then be an integer or an object pointer. This allows relatively quick numeric computation, and also object pointers for any more complex data type. This tag could be extended to also support a float type on the same stack. > This could actually simplify life for both the implementor and > the programmer! Current hardware (mostly) does not provide support for tagged data. New hardware could do this, and substantially improve processor system efficiency. [1] A hardware stack processor with tagged data could take these simplicity, assured precision, and efficiency prospects much further than register based processor systems. Jan Coombs -- [1a] [Slides] Unum [precice and 'green'] float representation: http://sites.ieee.org/scv-cs/files/2013/03/Right-SizingPrecision1.pdf [1b] Brief report with ascii-pic of proposed float data layout: https://github.com/tbreloff/Unums.jl/wiki/Unum-Summary-%28in-progress%29 email valid, else fix dots and hyphen jan4clf2014@murrayhyphenmicroftdotcodotuk
[toc] | [prev] | [next] | [standalone]
| From | franck.bensusan@gmail.com |
|---|---|
| Date | 2015-11-09 12:25 -0800 |
| Subject | Re: objects build up from other objects - even Forth? |
| Message-ID | <771e793c-e8cf-468e-9dca-335382ff90df@googlegroups.com> |
| In reply to | #43422 |
Le lundi 9 novembre 2015 13:15:14 UTC+1, Jan Coombs <Jan-54 > a écrit : > Some [no ref!] have used tagged data as a compromise: A stack > item can then be an integer or an object pointer. This allows > relatively quick numeric computation, and also object pointers > for any more complex data type. This tag could be extended to > also support a float type on the same stack. > Hi , [no ref!] ==> Oforth works like this. Franck
[toc] | [prev] | [next] | [standalone]
| From | Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> |
|---|---|
| Date | 2015-11-10 10:48 +0000 |
| Subject | Re: objects build up from other objects - even Forth? |
| Message-ID | <20151110104826.1cdbb672@TP-T500> |
| In reply to | #43438 |
On Mon, 9 Nov 2015 12:25:26 -0800 (PST) franck.bensusan@gmail.com wrote: > Le lundi 9 novembre 2015 13:15:14 UTC+1, Jan Coombs <Jan-54 > > a écrit : > > Some [no ref!] have used tagged data as a compromise: A stack > > item can then be an integer or an object pointer. This allows > > relatively quick numeric computation, and also object > > pointers for any more complex data type. This tag could be > > extended to also support a float type on the same stack. > > > > Hi > , > [no ref!] ==> Oforth works like this. Thanks Franck, thats a good hot reference! Does Oforth support floats? Do/would your floats be stored in the stack, in a separate stack, or with a stack reference to an external objects? If a system implementers chooses to allow the data stack to support more complex data types, then should they refrain from calling their systems 'Forth' as one poster asserted? Jan Cooombs -- email valid, else fix dots and hyphen jan4clf2014@murrayhyphenmicroftdotcodotuk
[toc] | [prev] | [next] | [standalone]
| From | franck.bensusan@gmail.com |
|---|---|
| Date | 2015-11-10 04:31 -0800 |
| Subject | Re: objects build up from other objects - even Forth? |
| Message-ID | <4f70050f-1eb6-4f7e-b3a1-3e81c92a286a@googlegroups.com> |
| In reply to | #43444 |
Le mardi 10 novembre 2015 11:48:28 UTC+1, Jan Coombs <Jan-54 > a écrit : > On Mon, 9 Nov 2015 12:25:26 -0800 (PST) > franck.bensusan@gmail.com wrote: > > > Le lundi 9 novembre 2015 13:15:14 UTC+1, Jan Coombs <Jan-54 > > > a écrit : > > > Some [no ref!] have used tagged data as a compromise: A stack > > > item can then be an integer or an object pointer. This allows > > > relatively quick numeric computation, and also object > > > pointers for any more complex data type. This tag could be > > > extended to also support a float type on the same stack. > > > > > > > Hi > > , > > [no ref!] ==> Oforth works like this. > > Thanks Franck, thats a good hot reference! > > Does Oforth support floats? > > Do/would your floats be stored in the stack, in a separate > stack, or with a stack reference to an external objects? Yes Oforth supports floats. On 32bits version, there is a reference (on the same stack) to an external object (a double 64bits float). On 64bits version (not release yet), tag will be extended to support floats stored on the same stack. > > If a system implementers chooses to allow the data stack to > support more complex data types, then should they refrain > from calling their systems 'Forth' as one poster asserted? > > Jan Cooombs > -- > email valid, else fix dots and hyphen > jan4clf2014@murrayhyphenmicroftdotcodotuk You mean calling this system a Forth system ? Or do you mean using "forth" into the name ? As for Oforth, all I can say is that it keeps Forth principles (stack, RPN, immediate words, interpreter, ...), and adds OO support as a built-in feature (using references on the stack). And it tries to keep Forth words when possible. For sure, Oforth is not a Forth implementation and is not compatible with ANS Forth standard. Perhap's I would call it a Forth dialect. As for the name, it is to show that it keeps Forth principles while adding OO support as a built-in feature and not as an extension. And, if your question is about the name, while it keeps Forth principles, I don't see any problem with that. I don't think that what is on the stack breaks Forth principles. Does Hugh's FloatForth, with the way it allows the data stack to support different kind of data can use "forth" ? Does ColorForth is considered a Forth ? Can it use "forth" ? And does C# is considered a C ? Can it use C ? Franck
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-11-10 18:06 -0800 |
| Subject | Re: objects build up from other objects - even Forth? |
| Message-ID | <44518d49-f2fe-4788-aa64-c89a6a5593d0@googlegroups.com> |
| In reply to | #43447 |
On Tuesday, November 10, 2015 at 5:32:01 AM UTC-7, franck....@gmail.com wrote: > On 32bits version, there is a reference (on the same stack) to an external > object (a double 64bits float). > > On 64bits version (not release yet), tag will be extended to support floats > stored on the same stack. IEEE-754 defines a double-precision float as being 64-bit --- not 62-bit --- there is no room for a 2-bit tag --- also, if you are going to have more than 4 data-types then you can't have a 2-bit tag; you need a 3-bit tag for 8 data-types. I suppose you could put your tag at the bottom of the significand and reduce precision slightly, but this isn't strictly IEEE-754 anymore and won't provide the expected numeric results (some people do care about every bit). This is also a problem for integers --- they are only 30-bit (2-bit tag) or 29-bit (3-bit tag) not 32-bit, and hence the user gets different overflow problems than they would in another language. Also, pointers are either 30-bit or 29-bit, which is a problem for people who really need 4GB of memory (mostly game programmers who have gigantic image files held in RAM). This is another reason why I don't like tags; they cut down the size of the data. Racket is pretty cool, but it only has 3 primitive data types (3 primitive data types plus the 4th is a pointer to a struct) --- it is cool so long as your program needs only those 3 primitive data types ---- it is not so cool when you need more data types and have to put them in the heap and work indirectly with through pointers (like oForth having IEEE-754 floats in the heap as you described above).
[toc] | [prev] | [next] | [standalone]
| From | franck.bensusan@gmail.com |
|---|---|
| Date | 2015-11-11 00:49 -0800 |
| Subject | Re: objects build up from other objects - even Forth? |
| Message-ID | <38220763-deb6-4946-a764-a5c513bc9e6d@googlegroups.com> |
| In reply to | #43460 |
Le mercredi 11 novembre 2015 03:06:07 UTC+1, hughag...@gmail.com a écrit :
> On Tuesday, November 10, 2015 at 5:32:01 AM UTC-7, franck....@gmail.com wrote:
> > On 32bits version, there is a reference (on the same stack) to an external
> > object (a double 64bits float).
> >
> > On 64bits version (not release yet), tag will be extended to support floats
> > stored on the same stack.
>
> IEEE-754 defines a double-precision float as being 64-bit --- not 62-bit --- there is no room for a 2-bit tag --- also, if you are going to have more than 4 data-types then you can't have a 2-bit tag; you need a 3-bit tag for 8 data-types. I suppose you could put your tag at the bottom of the significand and reduce precision slightly, but this isn't strictly IEEE-754 anymore and won't provide the expected numeric results (some people do care about every bit).
For Floats on 64bits, I don't know. Haven't done yet. If not possible, I will
keep reference to a external object for floats (as for 32 bits).
>This is also a problem for integers --- they are only 30-bit (2-bit tag) or 29-bit (3-bit tag) not 32-bit, and hence the user gets different overflow problems than they would in another language.
Oforth checks for integers overflow.
Integers have arbitray precision and user never get overflow problem.
I agree, this is different from overflow problems with other
languages (security issues, ...).
>Also, pointers are either 30-bit or 29-bit, which is a problem for people who really need 4GB of memory (mostly game programmers who have gigantic image files held in RAM). This is another reason why I don't like tags; they cut down the size of the data.
This is not enough to be able to address 4GB.
For instance, on Windows 32bits, one process will never be able
to use more than 2GB, no matter you can address 4GB or not and
mo matter how RAM you have. And this applies to games, too... :)
In Oforth 32bits, pointers are 31bits lenght and can address 2GB.
On 64bits, there is not this 2GB limitation, but there is no problem
either with 1 bit dedicated for integer/address on the stack.
> Racket is pretty cool, but it only has 3 primitive data types (3 primitive data types plus the 4th is a pointer to a struct) --- it is cool so long as your program needs only those 3 primitive data types ---- it is not so cool when you need more data types and have to put them in the heap and work indirectly with through pointers (like oForth having IEEE-754 floats in the heap as you described above).
Oforth 32bits has only 1 bit dedicated for integer/address on the stack.
- Integers go from -2^30 to 2^30 and are checked for overflow. If they overflow they are handled like floats (reference to an external object) and this is
transparent for the user.
- Object pointers can address 2GB and can have up to 4096 differents data types.
I answer also on your remark on polymorphism from a previous post.
For me, polymorphism is essential for OO Paradigm. Of course, you can have
OO without polymorphism but this is not what I think OO paradigm is.
But I don't see how polymorphism is in contradiction with Charles Moore's maxim.
("Let the dictionary do the deciding").
Example :
Object Class new: A
A method: test "test A" ;
Object Class new: B
B method: test "test B" ;
A new test .
test A ok
B new test .
test B ok
Oforth's polymorphism is part of the dictionary and it is the dictionary that
decides what test method to run : no if, no condition, no control structure.
Or ... I don't understand this maxim...
Franck
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-11-11 01:13 -0800 |
| Subject | Re: objects build up from other objects - even Forth? |
| Message-ID | <87k2posxul.fsf@nightsong.com> |
| In reply to | #43465 |
franck.bensusan@gmail.com writes: > For Floats on 64bits, I don't know. Haven't done yet. If not possible, > I will keep reference to a external object for floats (as for 32 > bits). The usual Lisp trick for unboxed floats is to steal a few exponent bits. That way you don't lose any precision in the mantissa. If the number gets too big/small to fit in the reduced exponent range, then go to a boxed representation.
[toc] | [prev] | [next] | [standalone]
| From | franck.bensusan@gmail.com |
|---|---|
| Date | 2015-11-11 01:52 -0800 |
| Subject | Re: objects build up from other objects - even Forth? |
| Message-ID | <39de0779-f51e-4643-a328-6ba4056413de@googlegroups.com> |
| In reply to | #43466 |
Le mercredi 11 novembre 2015 10:13:08 UTC+1, Paul Rubin a écrit : > franck.bensusan@gmail.com writes: > > For Floats on 64bits, I don't know. Haven't done yet. If not possible, > > I will keep reference to a external object for floats (as for 32 > > bits). > > The usual Lisp trick for unboxed floats is to steal a few exponent bits. > That way you don't lose any precision in the mantissa. If the number > gets too big/small to fit in the reduced exponent range, then go to a > boxed representation. Very interesting ! I note this preciously. Do you know if this is used for Lisp 64bits or also used for 32 bits versions with no particular problem ?
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-11-11 15:54 -0800 |
| Subject | Re: objects build up from other objects - even Forth? |
| Message-ID | <f1f17003-6986-433c-948c-d76746d102d0@googlegroups.com> |
| In reply to | #43467 |
On Wednesday, November 11, 2015 at 2:52:47 AM UTC-7, franck....@gmail.com wrote: > Le mercredi 11 novembre 2015 10:13:08 UTC+1, Paul Rubin a écrit : > > franck.bensusan@gmail.com writes: > > > For Floats on 64bits, I don't know. Haven't done yet. If not possible, > > > I will keep reference to a external object for floats (as for 32 > > > bits). > > > > The usual Lisp trick for unboxed floats is to steal a few exponent bits. > > That way you don't lose any precision in the mantissa. If the number > > gets too big/small to fit in the reduced exponent range, then go to a > > boxed representation. > > Very interesting ! I note this preciously. > > Do you know if this is used for Lisp 64bits or also used for 32 bits versions > with no particular problem ? The tag has to be in the same place for every kind of data. If you use the low bits of the exponent as your tag, the tag is in the middle of the datum. So, the tag would have to be in the middle of the datum with integers and pointers too. Or, you could put the tag at the top or the bottom, but then have to shift things around to reconstruct your float. This is getting very complicated! You might be better off to just stick with your 1-bit tag indicating either integer or pointer --- unless you are doing a lot of floating-point arithmetic, you don't want to slow everything down just to support floats as a primitive data-type, especially if all this shifting bits around is slower for floats than just doing the indirection through memory to access the float. If you have a good GC system, then you might as well just put floats on the heap. You might want to have a separate heap just for floats --- if every datum in the heap is the same type, then there won't be any memory fragmentation. I will say one thing positive about VFX --- it allows the programmer to just use the x87 float-stack as the Forth float stack, so there is no moving data in and out of memory, which boosts the speed --- the downside is that the x86 stack is somewhat small, but this issue can be worked around (it would be a lot easier to work around though, if VFX supported double-cell locals like FloatForth does). All in all, I think that tagged data is inherently slow --- as I said, this doesn't mean that I think oForth is bad --- but this isn't where I'm going with FloatForth.
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-11-12 11:01 +0000 |
| Subject | Re: objects build up from other objects - even Forth? |
| Message-ID | <56447140.113219784@news.eternal-september.org> |
| In reply to | #43483 |
On Wed, 11 Nov 2015 15:54:24 -0800 (PST), hughaguilar96@gmail.com wrote: >(it wou= >ld be a lot easier to work around though, if VFX supported double-cell loca= >ls like FloatForth does). VFX supports locals of any size. RTFM. Does FloatForth exist? Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-11-12 11:07 -0800 |
| Subject | Re: objects build up from other objects - even Forth? |
| Message-ID | <84c9b815-c5cc-4010-9bfc-32f8c6d94884@googlegroups.com> |
| In reply to | #43498 |
On Thursday, November 12, 2015 at 4:01:34 AM UTC-7, Stephen Pelc wrote: > On Wed, 11 Nov 2015 15:54:24 -0800 (PST), hughaguilar96@gmail.com > wrote: > > >(it wou= > >ld be a lot easier to work around though, if VFX supported double-cell loca= > >ls like FloatForth does). > > VFX supports locals of any size. RTFM. The only manual that I've read is the ANS-Forth document and it says that Forth is only allowed to support one-cell locals. I might get into VFX in which case I would have a reason to RTFM the VFX manual, but I would need to have $1248 to give to you and I would need to be willing to accept vendor lock-in as all the good features of VFX are non-standard --- both of these conditions imply that I have a customer paying me to write some program --- that is not likely to happen anytime soon, as there is pretty much zero interest in Forth out in the real world (because people have read the ANS-Forth document). > Does FloatForth exist? It exists but only partially. It doesn't really matter though, because I have no intention of making it public. I'm definitely not going to release it open-source, as I have already seen my code posted on comp.lang.forth by Marcel Hendrix with my name removed from the copyright notice. Are you planning on releasing VFX open-source any time soon? I didn't think so. Everybody on comp.lang.forth is going to say that it "sucks" and that it is "crap" --- I get plenty of that already for my novice-package, so why should I invest more time and effort in obtaining abuse tomorrow that I can get for free today? You seem to want Forth to be several mutually-exclusive things simultaneously: 1.) You want VFX to be ANS-Forth standard because that is a big selling point, and because of this you are loyal to Elizabeth Rather (that plus she signs your paycheck when MPE does "joint projects" with Forth Inc.). 2.) You want VFX to have useful features and so you routinely break compatibility with ANS-Forth, but you make no effort to include these features in Forth-200x and instead you just do what Leon Wagner tells you to do. 3.) You want to trap your customers in vendor lock-in (this is why you break compatibility with ANS-Forth even in situations where I succeeded in providing the same feature in my novice-package that is fully ANS-Forth compatible). Elizabeth Rather says this about my novice package: ------------------------------------------------------------------------------ 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. ------------------------------------------------------------------------------ This was why I left the Forth-200x mailing list. I told you already that all you have to do is agree that Elizabeth Rather is telling the truth and I will stop posting messages on comp.lang.forth.. Why do you have so much difficulty with this? Lying is easy! You can be the winner here with one minute on the keyboard and then click [post] --- almost everybody on comp.lang.forth wants you to succeed, and I have made it super-easy for you --- you are letting down Forth-200x and don't deserve to be on the committee if you fail at this simple task (Elizabeth Rather could replace you on the committee with Alex McDonald or Rickman or John Passaniti or somebody else who is capable of doing your job that you are incapable of doing, and would do it without hesitation or remorse). Ultimately, it is all about the money --- stay focused! --- money is what matters here.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-11-11 15:55 -0800 |
| Subject | Re: objects build up from other objects - even Forth? |
| Message-ID | <87vb98qef0.fsf@nightsong.com> |
| In reply to | #43467 |
franck.bensusan@gmail.com writes: >> steal a few exponent bits. > Do you know if this is used for Lisp 64bits or also used for 32 bits > versions with no particular problem ? Well obviously it limits the range of exponent that you can still represent, and it's a more severe restriction for 32 bits since there are fewer exponent bits to begin with. But I think it can still be workable, especially if your representation doesn't use a lot of tag bits and the numbers in your application don't get too large or small. Otherwise it might be enough to have some primitive structures for vectors of floats, where those are normal unboxed floats.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-11-12 00:50 -0800 |
| Subject | Re: objects build up from other objects - even Forth? |
| Message-ID | <2bfb4119-c1c6-4bdf-892a-432e87b5d4ab@googlegroups.com> |
| In reply to | #43484 |
Just have a separate tag stack. 8 bit cells would suffice. The tag stack would be totally invisible ţo the user.
[toc] | [prev] | [next] | [standalone]
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
Back to top | Article view | comp.lang.forth
csiph-web