Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #49737 > unrolled thread
| Started by | JUERGEN <epldfpga@aol.com> |
|---|---|
| First post | 2016-08-02 09:33 -0700 |
| Last post | 2016-08-20 01:43 -0700 |
| Articles | 20 on this page of 91 — 19 participants |
Back to article view | Back to comp.lang.forth
The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc JUERGEN <epldfpga@aol.com> - 2016-08-02 09:33 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Paul Rubin <no.email@nospam.invalid> - 2016-08-02 10:35 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc JUERGEN <epldfpga@aol.com> - 2016-08-02 11:46 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-03 00:04 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-04 00:41 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc rickman <gnuarm@gmail.com> - 2016-08-04 09:35 -0400
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-04 10:08 -0500
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Brad Eckert <hwfwguy@gmail.com> - 2016-08-02 15:45 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-02 19:56 -0500
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc JUERGEN <epldfpga@aol.com> - 2016-08-02 22:43 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-03 00:12 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-03 02:42 -0500
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-03 10:41 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-03 12:56 -0500
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-03 13:09 -0500
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc rickman <gnuarm@gmail.com> - 2016-08-03 14:15 -0400
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Richard Owlett <rowlett@cloud85.net> - 2016-08-03 18:00 -0500
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-05 20:35 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-06 00:16 -0500
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-06 16:58 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-06 18:01 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-06 21:28 -0500
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-06 19:46 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-06 22:54 -0500
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Julian Fondren <julian.fondren@gmail.com> - 2016-08-06 21:39 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Paul Rubin <no.email@nospam.invalid> - 2016-08-06 22:28 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-06 23:49 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-07 02:32 -0500
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Paul Rubin <no.email@nospam.invalid> - 2016-08-07 01:06 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-07 07:05 -0500
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-07 13:01 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-07 16:02 -0500
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-07 14:20 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc franck.bensusan@gmail.com - 2016-08-08 03:13 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-08 11:25 -0500
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Paul Rubin <no.email@nospam.invalid> - 2016-08-07 13:55 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-07 16:22 -0500
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-07 15:03 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Håkan Thörngren <hth313@gmail.com> - 2016-08-07 23:02 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc "Elizabeth D. Rather" <erather@forth.com> - 2016-08-07 21:10 -1000
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-09 00:36 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-08 09:06 +0000
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-07 09:33 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Håkan Thörngren <hth313@gmail.com> - 2016-08-07 11:31 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-07 12:35 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-07 16:11 -0500
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Håkan Thörngren <hth313@gmail.com> - 2016-08-07 22:43 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Håkan Thörngren <hth313@gmail.com> - 2016-08-07 22:48 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-08 08:34 +0000
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-08 23:59 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-09 13:53 +0000
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-10 19:56 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Julian Fondren <julian.fondren@gmail.com> - 2016-08-11 00:33 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-11 11:58 +0000
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-11 13:16 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc stephen@mpeforth.com (Stephen Pelc) - 2016-08-11 23:36 +0000
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-11 20:49 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-28 11:20 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-28 17:33 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-28 21:10 -0500
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-28 22:49 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-12 23:10 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Julian Fondren <julian.fondren@gmail.com> - 2016-08-06 20:20 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-07 09:58 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Julian Fondren <julian.fondren@gmail.com> - 2016-08-07 11:08 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-08 09:10 +0000
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-08 10:47 +0000
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc JennyB <jennybrien@googlemail.com> - 2016-08-08 13:44 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc mhx@iae.nl - 2016-08-08 11:32 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-09 06:13 +0000
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-09 06:19 +0000
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc mhx@iae.nl - 2016-08-09 02:54 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-09 10:22 +0000
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc lawrencedo99@gmail.com - 2016-08-15 20:33 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-16 10:40 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc lawrencedo99@gmail.com - 2016-08-17 02:21 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-17 11:14 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Roberto Waltman <usenet@rwaltman.com> - 2016-08-03 18:21 -0400
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc rickman <gnuarm@gmail.com> - 2016-08-03 02:46 -0400
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc endlessboomcapitalism@gmail.com - 2016-08-13 09:51 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc JUERGEN <epldfpga@aol.com> - 2016-08-13 12:18 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc endlessboomcapitalism@gmail.com - 2016-08-14 19:13 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc JUERGEN <epldfpga@aol.com> - 2016-08-15 07:43 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Cecil Bayona <cbayona@cbayona.com> - 2016-08-15 12:34 -0500
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc Brad Eckert <hwfwguy@gmail.com> - 2016-08-17 22:08 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-18 15:26 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc endlessboomcapitalism@gmail.com - 2016-08-14 19:18 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc hughaguilar96@gmail.com - 2016-08-15 08:24 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc JUERGEN <epldfpga@aol.com> - 2016-08-15 08:31 -0700
Re: The Fourth Forth eBook in our little series - Programming Forth- Stephen Pelc "WJ" <w_a_x_man@yahoo.com> - 2016-08-19 23:54 +0000
Re: The Fourth Forth eBook in our little series - Programming Forth- Stephen Pelc JUERGEN <epldfpga@aol.com> - 2016-08-20 01:43 -0700
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-08-28 22:49 -0700 |
| Subject | Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc |
| Message-ID | <8cdd9698-6020-4a5c-89e8-c3b22c3b505a@googlegroups.com> |
| In reply to | #50536 |
On Sunday, August 28, 2016 at 7:10:54 PM UTC-7, Cecil - k5nwa wrote: > On 8/28/2016 7:33 PM, hughaguilar96@gmail.com wrote: > > > I was looking through some old Jeff Fox emails and I found this: > > ------------------------------------------------------------------ > > It is nearly impossible to get Elizabeth to say anything > > that isn't marketing language. But eventually I got [her] to > > say simply, "FORTH Inc. supports the standard and the > > standard supports FORTH Inc." > > ------------------------------------------------------------------ > "ANS Forth a guide to alternate realities" is a book that could deal > with all these possibilities and alternate realities. Soon to be > available at a store near you, in Hardback and eBook versions available > soon. > > Buy a dozen with a 20% discount, and give it as a gift to your enemies, > and relatives! > -- > Cecil - k5nwa The whole idea of a book is just a big joke --- Forth has been dead since 1994 --- maybe I should use this title: "ANS-Forth --- the zombie programming language --- no flicker of intelligence, but still lurching forward"
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-08-12 23:10 -0700 |
| Subject | Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc |
| Message-ID | <6c38080c-43e4-4325-8e9e-25901f9e62e8@googlegroups.com> |
| In reply to | #49963 |
On Thursday, August 11, 2016 at 4:36:05 PM UTC-7, Stephen Pelc wrote: > On Thu, 11 Aug 2016 13:16:42 -0700 (PDT), hughaguilar96@gmail.com > wrote: > > >In VFX tick and FIND return= > > an xt for these words, but when the xt is given to EXECUTE (whether STATE = > >is compiling or interpreting), the system aborts. > > Bollocks! Well, I looked up "bollocks" in Urban Dictionary. I now claim that my disambiguifiers are the "dog's bollocks" because they fix the problem in VFX of words that traditionally were immediate (such as IF semicolon etc.) being non-immediate and having a non-executable execution-token (it aborts when given to EXECUTE whether in compilation mode or interpretation mode). They also fix problem in Gforth of these words aborting the system when ticked. They also fix the problem in Gforth of FIND returning different xt values for these words depending upon what STATE is when FIND is executed. They also fix the problem in ANS-Forth that these words given to tick or FIND is in an "ambiguous condition" (meaning that pretty much anything can happen, including reformatting the hard-disk, and that is considered to be Standard) --- this is why VFX and Gforth and SwiftForth all behave differently, but are all ANS-Forth Standard compliant --- the disambiguifiers not only work on VFX, Gforth and SwiftForth, but also on any ANS-Forth compliant system that may be written in the future (this is because they rely on POSTPONE internally which, unlike tick and FIND, isn't ambiguous). Disambiguifiers! The dog's bollocks! The only people who don't like disambiguifiers are those who do like ambiguity...
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2016-08-06 20:20 -0700 |
| Subject | Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc |
| Message-ID | <f4a132d9-7375-41e8-88d6-7eec2e5dc0a1@googlegroups.com> |
| In reply to | #49827 |
On Saturday, August 6, 2016 at 9:28:45 PM UTC-5, Cecil - k5nwa wrote: > With many people demanding that Forth continue to stay in the 1970s, Name one of these many people. > no libraries, Put definitions in a file. Save. > no structures, http://www.forth200x.org/structures.html > no decently built object system, Forth has an abundance of object systems. Please, tell us about how indecent they all are. You don't have to be exhaustive. Just list off some of these indencies that you've noticed. I'll start: it is indecent of objects.fs to rely on ALLOCATE at compile time; this prevents it from being used in images or turnkey applications. > it will be hard to duplicate the Pascal code. Well it would be hard for anyone to duplicate code who is more interested in hallucinating obstacles to action than he is in putting finger to keyboard.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-08-07 09:58 -0700 |
| Subject | Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc |
| Message-ID | <d358f9ba-d7e4-493c-9a50-d4a13d1a74b2@googlegroups.com> |
| In reply to | #49830 |
On Saturday, August 6, 2016 at 8:20:04 PM UTC-7, Julian Fondren wrote:
> On Saturday, August 6, 2016 at 9:28:45 PM UTC-5, Cecil - k5nwa wrote:
> > no structures,
>
> http://www.forth200x.org/structures.html
> ...
> > it will be hard to duplicate the Pascal code.
>
> Well it would be hard for anyone to duplicate code who is more
> interested in hallucinating obstacles to action than he is in
> putting finger to keyboard.
Julien Fondren is such a brown-noser! People such as this absolutely disgust me!
Anyway, I looked up that Forth-200x document that he provide a link to. Here is an excerpt:
-----------------------------------------------------------------------------
The name first implementation of STRUCT and END-STRUCT is not
difficult.
: STRUCT \ -- addr 0 ; -- size
CREATE HERE 0 0 , DOES> @ ;
: END-STRUCT \ addr n --
SWAP ! ; \ set size
: +FIELD \ n1 n2 "name" -- n3 ; addr -- addr+n1
CREATE OVER , + DOES> @ + ;
The name last implementations of STRUCT{ and }STRUCT are trivial
even for native code compilers:
: STRUCT{ \ -- 0
0 ;
: }STRUCT \ size "name" --
CONSTANT ;
: +FIELD \ n1 n2 "name" -- n3 ; addr -- addr+n1
CREATE OVER , + DOES> @ + ;
In both cases the definition of +FIELD is the same. Further words
that operate on types can all use +FIELD and so can be common to
both camps.
For many modern compilers, implementing +FIELD to provide efficient
execution requires carnal knowledge of the system.
-----------------------------------------------------------------------------
This looks familiar. This is just Stephen Pelc's code copied directly out of Pelc's book discussed in this thread --- the names have all been changed (we have STRUCT{ instead of STRUCT[ and +FIELD instead of FIELD and }STRUCT instead of ]STRUCT) --- the code is still grossly inefficient because it uses CREATE DOES> and it still has the problem of forcing the starting offset to be zero.
Most humorous is that last sentence:
"For many modern compilers, implementing +FIELD to provide efficient
execution requires carnal knowledge of the system."
This is not true! I have FIELD defined in the novice-package in ANS-Forth, and it provides efficient execution. Humorously, Stephen Pelc also has a version of FIELD written in ANS-Forth that provides equivalent efficiency to mine (although it is written differently), but the Forth-200x committee are standardizing his grossly inefficient version of FIELD that he most likely wrote 30 years ago when he was still learning Forth (isn't it true that that book of his was originally published about 30 years ago?).
I am disgusted by Forth-200x and their brown-nosers because they are obsessed with declaring themselves to be the sole arbiters of what is Standard, and insisting that they know everything there is to know about Forth, and insisting that people such as myself are obliged to learn from them but can never write Forth code of our own. The Forth-200x committee are arrogant jackasses --- I will continue to point out how grossly inefficient their code is when it is brought to my attention (as Julien Fondren brought it to my attention here) --- all of their code is grossly inefficient!
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2016-08-07 11:08 -0700 |
| Subject | Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc |
| Message-ID | <22909417-a911-459a-9da6-10f04bb07b7b@googlegroups.com> |
| In reply to | #49847 |
On Sunday, August 7, 2016 at 11:58:35 AM UTC-5, hughag...@gmail.com wrote:
> the code is still grossly inefficient because it uses CREATE DOES>
You keep saying "because it uses CREATE DOES>" , like CREATE DOES>
is inherently inefficient. It's only worse when you have a simple
constant -- like a field offset. If you're going to give a class of
words each their own private memory that will actually be mutated
or that will store more than a single cell, then CREATE DOES>
handles this neatly.
Although, with a word to indicate that some memory is fixed, an
optimizer remove the difference, replacing an inlined address and
fetch with whatever's already at that address.
( in a definition )
P.Y
<address> @ +
4 +
> and it still has the problem of forcing the starting offset to be zero.
The recommended "portable code" version makes the zero explicit and
easily changed. The 'forced' starting point can still be changed in
any case with code like
begin-structure list-of-frogs
list +
cell +field frog
end-structure
which might also look OK with +STRUCTURE as a synonym of +
> I am disgusted by Forth-200x and their brown-nosers because [blah blah blah]. The Forth-200x committee are arrogant jackasses
You, and now Cesyl, are constantly putting stupid libelous words in
other people's mouths. Why don't you pay attention to your own
words in your own mouth and shut up about other "so many people" who
"want to keep Forth in the 1970s" or who "want to prevent
cross-compilers" or who are "the sole arbiters" of things? Don't
you have anything to talk about except the horrible conspiracies of
Forth programmers?
In the real world, I've started to think that maybe the French
Revolution wasn't so bad of a thing. Previously I would've
described it as literally the worst event that ever happened to any
civilization, ever. But there are so many political and media
personalities who so clearly deserve to be butchered in job lots or
served to the guillotine. Hell, Canada is ruled now by someone who
is more Marie Antoinette than she actually was. But then I go check
on what's up with Forth - a relaxing, non-political subject - and
here you are speaking as if the *nothing* that anyone has ever done
to you is why you can't have nice things. Be serious for a bit.
-- Julian
"Why are you doing this to me?!"
"Because it's 2016."
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-08-08 09:10 +0000 |
| Subject | Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc |
| Message-ID | <2016Aug8.111051@mips.complang.tuwien.ac.at> |
| In reply to | #49849 |
Julian Fondren <julian.fondren@gmail.com> writes:
>On Sunday, August 7, 2016 at 11:58:35 AM UTC-5, hughag...@gmail.com wrote:
>> the code is still grossly inefficient because it uses CREATE DOES>
>
>You keep saying "because it uses CREATE DOES>" , like CREATE DOES>
>is inherently inefficient. It's only worse when you have a simple
>constant -- like a field offset. If you're going to give a class of
>words each their own private memory that will actually be mutated
>or that will store more than a single cell, then CREATE DOES>
>handles this neatly.
Well, if it's 2 cells, as in 2CONSTANT, the required memory access can
still be inefficient:
: 2const create swap , , does> 2@ ;
1. 2constant x1
1. 2const x2
: foo1 x1 d+ ;
: foo2 x2 d+ ;
see foo1
see foo2
Compiling and decompiling this on VFX produces:
FOO1
( 080C0B60 8B5500 ) MOV EDX, [EBP]
( 080C0B63 83C201 ) ADD EDX, 01
( 080C0B66 83D300 ) ADC EBX, 00
( 080C0B69 895500 ) MOV [EBP], EDX
( 080C0B6C C3 ) NEXT,
( 13 bytes, 5 instructions )
FOO2
( 080C0B90 8B5500 ) MOV EDX, [EBP]
( 080C0B93 0315340B0C08 ) ADD EDX, [080C0B34]
( 080C0B99 131D300B0C08 ) ADC EBX, [080C0B30]
( 080C0B9F 895500 ) MOV [EBP], EDX
( 080C0BA2 C3 ) NEXT,
( 19 bytes, 5 instructions )
Two additional memory accesses, and 6 additional bytes in the code.
>Although, with a word to indicate that some memory is fixed, an
>optimizer remove the difference, replacing an inlined address and
>fetch with whatever's already at that address.
Yes, that is one of the approaches considered (and possibly
implemented in VFX and/or iForth) for getting rid of this
inefficiency.
The standard way is to let 2const define a colon definition:
: 2const ( n1 n2 -- ; run-time -- n1 n2 )
2>r : 2r> postpone 2literal postpone ; ;
The disadvantage is that each child consumes more memory than the
children of CREATE...DOES> words.
Another approach is to define an optimizer for the newly-defined word:
\ works on the development version of Gforth
: 2const ( n1 n2 -- )
create 2,
[: 2@ ;] set-does>
[: >body 2@ postpone 2literal ;] set-optimizer ;
(SET-OPTIMIZER is present in VFX under the misleading name
SET-COMPILER, but you also have to work around the absence of 2, and
SET-DOES>).
#1. 2const x ok
: foo x ; ok
simple-see foo
$7F8871BE8A90 lit
$7F8871BE8A98 <$1>
$7F8871BE8AA0 lit
$7F8871BE8AA8 <$0>
$7F8871BE8AB0 ;s ok
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-08-08 10:47 +0000 |
| Subject | Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc |
| Message-ID | <2016Aug8.124756@mips.complang.tuwien.ac.at> |
| In reply to | #49871 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>Julian Fondren <julian.fondren@gmail.com> writes:
>>You keep saying "because it uses CREATE DOES>" , like CREATE DOES>
>>is inherently inefficient. It's only worse when you have a simple
>>constant -- like a field offset. If you're going to give a class of
>>words each their own private memory that will actually be mutated
>>or that will store more than a single cell, then CREATE DOES>
>>handles this neatly.
>
>Well, if it's 2 cells, as in 2CONSTANT, the required memory access can
>still be inefficient:
>
>: 2const create swap , , does> 2@ ;
>1. 2constant x1
>1. 2const x2
>: foo1 x1 d+ ;
>: foo2 x2 d+ ;
>see foo1
>see foo2
>
>Compiling and decompiling this on VFX produces:
>
>FOO1
>( 080C0B60 8B5500 ) MOV EDX, [EBP]
>( 080C0B63 83C201 ) ADD EDX, 01
>( 080C0B66 83D300 ) ADC EBX, 00
>( 080C0B69 895500 ) MOV [EBP], EDX
>( 080C0B6C C3 ) NEXT,
>( 13 bytes, 5 instructions )
>
>FOO2
>( 080C0B90 8B5500 ) MOV EDX, [EBP]
>( 080C0B93 0315340B0C08 ) ADD EDX, [080C0B34]
>( 080C0B99 131D300B0C08 ) ADC EBX, [080C0B30]
>( 080C0B9F 895500 ) MOV [EBP], EDX
>( 080C0BA2 C3 ) NEXT,
>( 19 bytes, 5 instructions )
>
>Two additional memory accesses, and 6 additional bytes in the code.
>
>>Although, with a word to indicate that some memory is fixed, an
>>optimizer remove the difference, replacing an inlined address and
>>fetch with whatever's already at that address.
>
>Yes, that is one of the approaches considered (and possibly
>implemented in VFX and/or iForth) for getting rid of this
>inefficiency.
>
>The standard way is to let 2const define a colon definition:
>
>: 2const ( n1 n2 -- ; run-time -- n1 n2 )
> 2>r : 2r> postpone 2literal postpone ; ;
>
>The disadvantage is that each child consumes more memory than the
>children of CREATE...DOES> words.
>
>Another approach is to define an optimizer for the newly-defined word:
>
>\ works on the development version of Gforth
>: 2const ( n1 n2 -- )
> create 2,
> [: 2@ ;] set-does>
> [: >body 2@ postpone 2literal ;] set-optimizer ;
>
>(SET-OPTIMIZER is present in VFX under the misleading name
>SET-COMPILER, but you also have to work around the absence of 2, and
>SET-DOES>).
>
>#1. 2const x ok
>: foo x ; ok
>simple-see foo
>$7F8871BE8A90 lit
>$7F8871BE8A98 <$1>
>$7F8871BE8AA0 lit
>$7F8871BE8AA8 <$0>
>$7F8871BE8AB0 ;s ok
I forgot two more, as yet unimplemented (or inefficiently
implemented) approaches:
CONST-DOES> is designed for exactly this problem. You specify how
many stack items you want to pass from the word creation time to the
run-time, as follows:
: 2const ( n1 n2 "name" -- )
2 0 const-does> ( -- n1 n2 )
;
... u1 u2 CONST-DOES> creates a word <name>, consumes u1 cells and u2
floats at creation time. At <name> run-time, it pushes these u1 cells
and u2 floats on the respective stacks, in the original order.
You can find the proposal and a paper about it at:
<http://www.forth200x.org/const-does.html>
http://www.complang.tuwien.ac.at/anton/euroforth/ef00/ertl00.pdf
The reference implementation does not get rid of the memory accesses,
though, and is also inefficient in other ways, but an efficient
implementation is not hard.
Another, unimplemented approach (but totally natural for people
familiar with lamda-calculus-inspired languages) would be this:
: 2const {: n1 n2 -- :}
create does> drop n1 n2 ;
Of course, if you pass locals in this way, there is no need to pass
data in memory, so there is no need to have a DOES> that pushes an
address, and also no need for separating CREATE from DOES> (there is
no commaing going on between CREATE and DOES>), so one can have a word
CREATE> used as follows:
: 2const {: n1 n2 -- :}
create> n1 n2 ;
Is this implementable? There have been discussions about closures
with explicity memory management. In the present case, the memory for
the closure would be allocated with ALLOT, and a syntax for that might
be ALLOT[: ... ;]. With that, and a word <CREATE that takes a
closure, this would become
: 2const {: n1 n2 -- :}
allot[: n1 n2 ;] <create ;
I think that an implementation of that is within reach. The cost: in
addition to n1 and n2, the trampoline for the closure (2-4 cells,
depending on the implementation) would need to be stored. And to
avoid memory accesses, there is quite a bit of compiler sophistication
necessary: The compiler would have to notice that there are no TO
accesses to n1 and n2, and would have to inline the closure into
calls, resolving the (memory) access to the locals during compilation
and thus optimizing the references to n1 and n2 in the inlined closure
into literals.
All this complexity seems more appropriate for Haskell than for Forth,
so while this is cute, I think that the SET-OPTIMIZER approach is more
Forth-like.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | JennyB <jennybrien@googlemail.com> |
|---|---|
| Date | 2016-08-08 13:44 -0700 |
| Subject | Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc |
| Message-ID | <8d756ba1-1d5d-4a34-95a7-876a2cbd6b4c@googlegroups.com> |
| In reply to | #49873 |
A different approach: for every possible kind of Constant there is an equivalent literal. A constant is simply a memoised literal; it does a get-from-memory instead of a parse. Therefore, a new kind of constant should be defined something like a new kind of recognizer. You need to specify the GET action and the PUT action. Something like this: : CONSTANT ['] @ ['] LITERAL make-const , ; : 2CONSTANT ['] 2@ ['] 2LITERAL make-const 2, ;
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2016-08-08 11:32 -0700 |
| Subject | Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc |
| Message-ID | <31871abf-8a7d-4165-8747-4174b063b8e2@googlegroups.com> |
| In reply to | #49871 |
On Monday, August 8, 2016 at 11:43:13 AM UTC+2, Anton Ertl wrote: > Julian Fondren <julian.fondren@gmail.com> writes: > [..] > >> the code is still grossly inefficient because it uses CREATE DOES> > > > >You keep saying "because it uses CREATE DOES>" , like CREATE DOES> > >is inherently inefficient. It's only worse when you have a simple > >constant -- like a field offset. If you're going to give a class of > >words each their own private memory that will actually be mutated > >or that will store more than a single cell, then CREATE DOES> > >handles this neatly. > > Well, if it's 2 cells, as in 2CONSTANT, the required memory access can > still be inefficient: > > : 2const create swap , , does> 2@ ; > 1. 2constant x1 > 1. 2const x2 > : foo1 x1 d+ ; > : foo2 x2 d+ ; > see foo1 > see foo2 > > Compiling and decompiling this on VFX produces: > > FOO1 > ( 080C0B60 8B5500 ) MOV EDX, [EBP] > ( 080C0B63 83C201 ) ADD EDX, 01 > ( 080C0B66 83D300 ) ADC EBX, 00 > ( 080C0B69 895500 ) MOV [EBP], EDX > ( 080C0B6C C3 ) NEXT, > ( 13 bytes, 5 instructions ) > > FOO2 > ( 080C0B90 8B5500 ) MOV EDX, [EBP] > ( 080C0B93 0315340B0C08 ) ADD EDX, [080C0B34] > ( 080C0B99 131D300B0C08 ) ADC EBX, [080C0B30] > ( 080C0B9F 895500 ) MOV [EBP], EDX > ( 080C0BA2 C3 ) NEXT, > ( 19 bytes, 5 instructions ) > > Two additional memory accesses, and 6 additional bytes in the code. > > >Although, with a word to indicate that some memory is fixed, an > >optimizer remove the difference, replacing an inlined address and > >fetch with whatever's already at that address. > > Yes, that is one of the approaches considered (and possibly > implemented in VFX and/or iForth) for getting rid of this > inefficiency. [..] Did you check what happens when you use foo1 and foo2? FORTH> : 2const create swap , , does> 2@ ; ok FORTH> 1. 2constant x1 ok FORTH> 1. 2const x2 ok FORTH> : foo1 x1 d+ ; ok FORTH> : foo2 x2 d+ ; ok FORTH> see foo1 Flags: TOKENIZE, ANSI : foo1 [trashed] D+ ; ok FORTH> see foo2 Flags: TOKENIZE, ANSI : foo2 x2 D+ ; ok FORTH> : test 22. foo1 33. foo2 d+ d. ; ok FORTH> see test Flags: ANSI $01322F80 : test $01322F8A mov rbx, $01322A48 qword-offset $01322F91 add rbx, #33 b# $01322F95 mov rdi, $01322A40 qword-offset $01322F9C adc rdi, 0 b# $01322FA0 add rbx, #23 b# $01322FA4 adc rdi, 0 b# $01322FA8 push rbx $01322FA9 push rdi $01322FAA jmp D.+10 ( $012395BA ) offset NEAR Doubles are not well optimized in iForth -- the carry poses specialized problems for register allocation. -marcel
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-08-09 06:13 +0000 |
| Subject | Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc |
| Message-ID | <2016Aug9.081357@mips.complang.tuwien.ac.at> |
| In reply to | #49877 |
mhx@iae.nl writes:
>On Monday, August 8, 2016 at 11:43:13 AM UTC+2, Anton Ertl wrote:
>> Julian Fondren <julian.fondren@gmail.com> writes:
>> Well, if it's 2 cells, as in 2CONSTANT, the required memory access can
>> still be inefficient:
>>
>> : 2const create swap , , does> 2@ ;
>> 1. 2constant x1
>> 1. 2const x2
>> : foo1 x1 d+ ;
>> : foo2 x2 d+ ;
>> see foo1
>> see foo2
>>
>> Compiling and decompiling this on VFX produces:
>>
>> FOO1
>> ( 080C0B60 8B5500 ) MOV EDX, [EBP]
>> ( 080C0B63 83C201 ) ADD EDX, 01
>> ( 080C0B66 83D300 ) ADC EBX, 00
>> ( 080C0B69 895500 ) MOV [EBP], EDX
>> ( 080C0B6C C3 ) NEXT,
>> ( 13 bytes, 5 instructions )
>>
>> FOO2
>> ( 080C0B90 8B5500 ) MOV EDX, [EBP]
>> ( 080C0B93 0315340B0C08 ) ADD EDX, [080C0B34]
>> ( 080C0B99 131D300B0C08 ) ADC EBX, [080C0B30]
>> ( 080C0B9F 895500 ) MOV [EBP], EDX
>> ( 080C0BA2 C3 ) NEXT,
>> ( 19 bytes, 5 instructions )
>>
>> Two additional memory accesses, and 6 additional bytes in the code.
>>
>> >Although, with a word to indicate that some memory is fixed, an
>> >optimizer remove the difference, replacing an inlined address and
>> >fetch with whatever's already at that address.
>>
>> Yes, that is one of the approaches considered (and possibly
>> implemented in VFX and/or iForth) for getting rid of this
>> inefficiency.
>[..]
>
>
>Did you check what happens when you use foo1 and foo2?
11. foo2 d. 4294967307
Obviously not:-)
Ok, the correct definition of 2CONST is:
: 2const create , , does> 2@ ;
With that SEE FOO2 gives:
FOO2
( 080C0B30 8B5500 ) MOV EDX, [EBP]
( 080C0B33 0315040B0C08 ) ADD EDX, [080C0B04]
( 080C0B39 131D000B0C08 ) ADC EBX, [080C0B00]
( 080C0B3F 895500 ) MOV [EBP], EDX
( 080C0B42 C3 ) NEXT,
( 19 bytes, 5 instructions )
Also 2 memory accesses and 6 bytes more than FOO1.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-08-09 06:19 +0000 |
| Subject | Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc |
| Message-ID | <2016Aug9.081928@mips.complang.tuwien.ac.at> |
| In reply to | #49877 |
mhx@iae.nl writes:
>Doubles are not well optimized in iForth -- the carry poses
>specialized problems for register allocation.
You are not alone with this problem. See
<2016May24.093059@mips.complang.tuwien.ac.at> for an example of how
bad code generated by gcc for 256-bit addition looks, and my
explanation why.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2016-08-09 02:54 -0700 |
| Subject | Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc |
| Message-ID | <3c20552d-1270-421d-a562-d2893936301a@googlegroups.com> |
| In reply to | #49891 |
On Tuesday, August 9, 2016 at 8:25:40 AM UTC+2, Anton Ertl wrote: > mhx@iae.nl writes: > >Doubles are not well optimized in iForth -- the carry poses > >specialized problems for register allocation. > > You are not alone with this problem. See > <2016May24.093059@mips.complang.tuwien.ac.at> for an example of how > bad code generated by gcc for 256-bit addition looks, and my > explanation why. Such links appear not to work for Google anymore. In what group is that? -marcel
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-08-09 10:22 +0000 |
| Subject | Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc |
| Message-ID | <2016Aug9.122237@mips.complang.tuwien.ac.at> |
| In reply to | #49899 |
mhx@iae.nl writes:
>On Tuesday, August 9, 2016 at 8:25:40 AM UTC+2, Anton Ertl wrote:
>> mhx@iae.nl writes:
>> >Doubles are not well optimized in iForth -- the carry poses
>> >specialized problems for register allocation.
>>
>> You are not alone with this problem. See
>> <2016May24.093059@mips.complang.tuwien.ac.at> for an example of how
>> bad code generated by gcc for 256-bit addition looks, and my
>> explanation why.
>
>Such links appear not to work for Google anymore.
One site that offers Message-Id search is <http://al.howardknight.net/>
>In what group is that?
comp.arch.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | lawrencedo99@gmail.com |
|---|---|
| Date | 2016-08-15 20:33 -0700 |
| Subject | Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc |
| Message-ID | <c3d5a346-d06c-4137-9c60-f40353dca391@googlegroups.com> |
| In reply to | #49822 |
On Sunday, August 7, 2016 at 11:58:14 AM UTC+12, hughag...@gmail.com wrote: > What is sad about this, is that Forth has better support for > code-libraries than C does. In C, a struct has to start on offset zero. That’s not how data abstraction is supposed to work. With an abstract data type, you have no knowledge of the internal data layout at all, you have to use library-provided accessors to do everything. Consider a Cairo drawing context <https://www.cairographics.org/manual/cairo-cairo-t.html>. Somewhere in there is a reference to a surface <https://www.cairographics.org/manual/cairo-cairo-surface-t.html>. But the only way to get it is via cairo_get_target <https://www.cairographics.org/manual/cairo-cairo-t.html#cairo-get-target>. This way, the internals of the objects can change in a few version of the library, and your existing code will still work, without even needing to be recompiled. And that works with straight C. Can Forth say the same?
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-08-16 10:40 -0700 |
| Subject | Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc |
| Message-ID | <6bfcac21-94c8-4c21-a51e-2f8592965bb2@googlegroups.com> |
| In reply to | #50163 |
On Monday, August 15, 2016 at 8:33:49 PM UTC-7, lawren...@gmail.com wrote: > On Sunday, August 7, 2016 at 11:58:14 AM UTC+12, hughag...@gmail.com wrote: > > What is sad about this, is that Forth has better support for > > code-libraries than C does. In C, a struct has to start on offset zero. > > That’s not how data abstraction is supposed to work. With an abstract data type, you have no knowledge of the internal data layout at all, you have to use library-provided accessors to do everything. > > Consider a Cairo drawing context <https://www.cairographics.org/manual/cairo-cairo-t.html>. Somewhere in there is a reference to a surface <https://www.cairographics.org/manual/cairo-cairo-surface-t.html>. But the only way to get it is via cairo_get_target <https://www.cairographics.org/manual/cairo-cairo-t.html#cairo-get-target>. > > This way, the internals of the objects can change in a few version of the library, and your existing code will still work, without even needing to be recompiled. > > And that works with straight C. Can Forth say the same? Well, in LIST.4TH I have SEQ that inherits from LIST. A person writing code for SEQ doesn't need to know what fields are in LIST. All he needs to know are what methods are available for LIST. If you look at my code supporting SEQ you will find functions that use EACH and LINK and various other methods belonging to LIST --- you will not find any functions that use .FORE which is the field being inherited from LIST --- only functions such as EACH and LINK etc. that support LIST will access the .FORE field. To ask if Forth OOP supports abstraction seems like a funny question --- abstraction is the whole point of OOP --- if an OOP system doesn't support abstraction, then it is not an OOP system. I don't think that OOP in C supports abstraction as well as OOP in Forth --- C has serious problems, not the least of which being that STRUCT forces the first offset to be zero, and the type-checking gets in the way so a pointer to a child object can't be treated as a pointer to the parent object without a typecast being done, but after the typecast has been done then SIZEOF doesn't work correctly anymore.
[toc] | [prev] | [next] | [standalone]
| From | lawrencedo99@gmail.com |
|---|---|
| Date | 2016-08-17 02:21 -0700 |
| Subject | Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc |
| Message-ID | <a18bf709-f429-43b4-b1ae-5df623db4bc2@googlegroups.com> |
| In reply to | #50174 |
On Wednesday, August 17, 2016 at 5:41:00 AM UTC+12, hughag...@gmail.com wrote: > I don't think that OOP in C supports abstraction as well as OOP in Forth --- > C has serious problems, not the least of which being that STRUCT forces the > first offset to be zero, and the type-checking gets in the way so a pointer > to a child object can't be treated as a pointer to the parent object without > a typecast being done... None of which has anything to do with data abstraction, as I pointed out in my example--one of many more I can offer if you like.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-08-17 11:14 -0700 |
| Subject | Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc |
| Message-ID | <624c9ff8-940c-474f-baa6-f61190bfcf04@googlegroups.com> |
| In reply to | #50174 |
On Tuesday, August 16, 2016 at 10:41:00 AM UTC-7, hughag...@gmail.com wrote: > On Monday, August 15, 2016 at 8:33:49 PM UTC-7, lawren...@gmail.com wrote: > > With an abstract data type, you have no knowledge of the internal data layout at all, you have to use library-provided accessors to do everything. > > ... > > This way, the internals of the objects can change in a few version of the library, and your existing code will still work, without even needing to be recompiled. > > > > And that works with straight C. Can Forth say the same? > > Well, in LIST.4TH I have SEQ that inherits from LIST. A person writing code for SEQ doesn't need to know what fields are in LIST. All he needs to know are what methods are available for LIST. > > If you look at my code supporting SEQ you will find functions that use EACH and LINK and various other methods belonging to LIST --- you will not find any functions that use .FORE which is the field being inherited from LIST --- only functions such as EACH and LINK etc. that support LIST will access the .FORE field. It is not clear to me what you mean by "abstract data type" --- apparently not the same thing that I mean. Maybe you are referring to virtual functions. These I would provide similar to Oberon --- they are just W fields in the object that contain the xt of the function that does it (they get filled in by the constructor) --- I wouldn't have a VMT like in C++ (I doubt there is any C system that has a VMT either). I still think that Forth is better than C because C's type-checking gets in the way --- pointers to functions in C involve complicated declarations --- also, you often have to use a void pointer because your function (such as a HOF) doesn't know the type of the function-pointer, but later on you use a typecast to get back to the actual function-type in the code that will actually use the function-pointer. Anyway, this discussion should be moved to here: https://groups.google.com/forum/#!topic/comp.lang.forth/cH-pGXhBCfE Our current thread is just a salesman of MPE promoting a book written by Stephen Pelc which makes no mention of OOP or inheritance at all and provides a rather useless and inefficient way to define structs --- there is no evidence to indicate that Stephen Pelc knows what inheritance is --- him and his salesman don't want their thread hijacked with a discussion of OOP code that is useful! The goal of that book that Stephen Pelc wrote was to present Forth as being a toy language --- similar to "Starting Forth" but without the cartoons.
[toc] | [prev] | [next] | [standalone]
| From | Roberto Waltman <usenet@rwaltman.com> |
|---|---|
| Date | 2016-08-03 18:21 -0400 |
| Subject | Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc |
| Message-ID | <cdr4qbd28f6epj8snh876jrpeu1714erbu@4ax.com> |
| In reply to | #49758 |
hughaguilar96@gmail.com wrote: >The only hard-bound book on Forth that I'm aware of was: "Threaded Interpretive Languages" (R.G.Loeliger). Also hard-bound: [ Kelly & Spies ] "FORTH: a Text and Reference" and [ Payne ] "Embedded Controller FORTH" R.W.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-08-03 02:46 -0400 |
| Subject | Re: The Fourth Forth eBook in our little series - Programming Forth - Stephen Pelc |
| Message-ID | <nns3v9$nks$1@dont-email.me> |
| In reply to | #49752 |
On 8/2/2016 6:45 PM, Brad Eckert wrote: > On Tuesday, August 2, 2016 at 9:33:47 AM UTC-7, JUERGEN wrote: >> It took longer than expected, but as Stephen allowed me to reformat his book for publication on amazon, it had to be finished - came out today https://www.amazon.co.uk/dp/B01JIWVB5S or your local amazon. > > No hard copy? It looks like my tree-killing days are numbered. Can't you print a copy? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | endlessboomcapitalism@gmail.com |
|---|---|
| Date | 2016-08-13 09:51 -0700 |
| Message-ID | <30686109-9cd3-4cba-ae07-948d47121d96@googlegroups.com> |
| In reply to | #49737 |
On Tuesday, August 2, 2016 at 12:33:47 PM UTC-4, JUERGEN wrote: > It took longer than expected, but as Stephen allowed me to reformat his book for publication on amazon, it had to be finished - came out today https://www.amazon.co.uk/dp/B01JIWVB5S or your local amazon. > After Chuck Moore - Early Years https://www.amazon.de/dp/B00JZI64U8 > and Chuck Moore - Programming a Problem Oriented Language https://www.amazon.de/dp/B00K3PIYX2 > leading to the Forth Lite Tutorial - https://www.amazon.de/dp/B00L0F32Q8 > we have 4 now. > Enjoy Stephen's eBook. what apps did you make with forth?
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | comp.lang.forth
csiph-web