From: cgra@btmaa.bel.alcatel.be (Chris Gray) Subject: Re: Forth is a toy (Was: 0123 Forth) Date: 17 Apr 1996 07:34:02 GMT Message-ID: <4l26ta$75m@btmpjg.god.bel.alcatel.be> References: Reply-To: grayc@btmaa.bel.alcatel.be hbezemer@vsngroep.nl (Hans Bezemer) wrote: > "Most Forths use four different datatypes: signed 16 bit numbers, unsigned 16 > bit > numbers, signed 32 bit numbers and unsigned 32 bit numbers. The latter two are > usually called "double numbers". Unlike C they all have their own operators. On > top of that there are mixed operators too. Highly confusing! > > We never liked that in the first place. Application programmers want to program > their application. They don't want to worry whether any intermediate result > could > possibly be larger than 65535. So 4tH gets rid of most data-types and > operators. > It uses signed 32 bit numbers. That's it. No mixed, double or unsigned > operators. Of course you still have to worry about intermediate results being larger than 2147483647. And if you think that's a joke, try applying a finite impulse response filter to a 16-bit data stream ... -- __________________________________________________________________________ Chris Gray Chris_Gray@bcs.org.uk Compuserve: 100065,2102 __________________________________________________________________________ From: Wayne Ward Subject: svgalib Date: Wed, 17 Apr 1996 06:09:47 -0400 Message-ID: References: <1995Jul3.034108.4193@rcmcon.com> <3v29qp$him@miranda.gmrc.gecm.com> <3v7jr8$ptf@miranda.gmrc.gecm.com> <3vbafo$7lu@ixnews6.ix.netcom.com> <3vbn6f$e96@iaehv.IAEhv.nl> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In-Reply-To: <3vbn6f$e96@iaehv.IAEhv.nl> Hello, Can someone tell me where to get the documentation for svgalib? Thanks. Wayne From: jpass@frontiernet.net (John M. Passaniti) Subject: Re: Forth is a toy (Was: 0123 Forth) Date: 17 Apr 1996 11:36:41 GMT Message-ID: <4l2l49$g3u@cheatum.frontiernet.net> References: > hbezemer@vsngroep.nl (Hans Bezemer) writes: > "Most Forths use four different datatypes: signed 16 bit numbers, > unsigned 16 bit numbers, signed 32 bit numbers and unsigned 32 > bit numbers. The latter two are usually called "double numbers". > Unlike C they all have their own operators. On top of that there > are mixed operators too. Highly confusing! Makes sense when you approach Forth as being closer to assembly language than a higher level language, which it is, sometimes. > We never liked that in the first place. Application programmers > want to program their application. They don't want to worry whether > any intermediate result could possibly be larger than 65535. So 4tH > gets rid of most data-types and operators. It uses signed 32 bit > numbers. That's it. No mixed, double or unsigned operators. Well, mandating 32-bit numbers everywhere certainly is one way to address the issue. For me, I took a more object-oriented approach. In my Forth-based scripting language, each push on the stack is an object (actually, a pointer to an object, but that's a detail). Each object has a field that describes itself. This lets me overload words, like overloaded operators in C++, that let me things like this: "123" . 123 123 . 123 "123" "456" + . 123456 123 456 + . 579 These simple examples show the word overloading of "." and "+". The "." word prints the top of stack-- and here you can see that "." is overloaded so that it can print strings ("123") as well as straight numbers (123). The "+" operator works as a concatenation word when the top two elements on the stack are strings, and as a straight integer add when they are numbers. I haven't ever looked at anyone else's object-oriented Forth system, but I suspect they have similar capabilities. It's one way that I reconciled my love of Forth with the fact that my calendar says we are in 1996, not the 1970's. It also makes programming easier and more efficient for me. Oh, since I determine the types of objects on my stack at runtime, this isn't very efficient in terms of execution speed. Of course, this is a scripting engine, where flexibility is more important to me than raw execution speed. ---------------------------------------------------------------------- John Passaniti "Lead me not into temptation; jpass@frontiernet.net I can find the way myself." ---------------------------------------------------------------------- From: "James P. Meyer" Subject: Re: MAKE $50,000 in 60 days Date: Wed, 17 Apr 1996 09:16:38 -0400 Message-ID: References: <4ksd29$775@bubba.NMSU.Edu> <317448D8.B08@gate.net> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In-Reply-To: <317448D8.B08@gate.net> On Tue, 16 Apr 1996, Jerry Petrey wrote: > BEVERLY JEAN DENNEY wrote: > > > > email me for details > > Better yet, email postmaster@nmsu.edu and inform them of what the > 'children' using their University Internet account are doing with it! And just where do you think most of the children are going to spend their new-found wealth? Might not students spend the majority of their cash in and around campus? Might not this chain letter have actually been started by someone on the university payroll? Who, but the university, stands to gain the most from this scheme? Why should they care if their students get wealthy or not? Either way, it would be a valuable "learning experience". 8-) Jim "Just sorry I didn't think of it first." Meyer From: Marc de Groot Subject: Re: Can OO be successful in real-time embedded systems? Date: Wed, 17 Apr 1996 05:39:08 -0700 Message-ID: <3174E66C.16B1@immersive.com> References: <316BF0C5.1FE1@condat.de> <31710F7A.1F82@headwaters.com> <968@purr.demon.co.uk> <4l0k9a$5nk@uruguay.it.earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0 (WinNT; I) Elizabeth Rather wrote: > > jack@purr.demon.co.uk (Jack Campin) wrote: > > > > >Which makes me wonder: has Forth made it into space yet? > > > > Yes! A list compiled by folks at NASA/GSFC a few years ago listed over 40 > space projects (including Shuttle experiments and satellites) coded in Forth. > There have presumably been more since. Some are described in our web site > (addr. below). NASA is presently developing a whole generation of systems for > interfacing "guest" payloads to the shuttle computing systems based on the > RTX2000 and programmed in Forth. AMSAT, the ham radio satellite organization, also uses Forth for the software on its satellites. The language they use is has an acronym for a name. The acronym stands for the German equivalent of "language for satellites" or something like that. I can't remember exactly what it is anymore... -- ---- Marc de Groot | Immersive Systems, Inc. | http://www.immersive.com | Real VR for the net! "Under the most strictly controlled conditions of temperature, lighting and pH, the organism does as it damn well pleases." From: sleech@ozemail.com.au (Christopher Slee) Subject: String Concatentation problem Date: Thu, 18 Apr 1996 17:43:09 +1000 Message-ID: Hi All I'm working with F-PC v3.56 and I'm trying to write a word to append one string on to the end of another. This is proving to be an impossible task. Can anyone help? Here's my code so far. I can't see why it doesn't work. \ --------------------------------------- appends $a1 to end of $a2 : +string ( a1 a2 -- a3 ) \ appends $a1 to $a2 >r count tuck r@ count + swap cmove \ append string to buffer bl r@ count + c! \ append a blank 1+ r> c+! ; \ update count byte Answers by email would be appreciated as my news server is a bit wobbly. Thanks in advance Chris Slee sleech@ozemail.com.au 靈컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� � e-mail: sleech@ozemail.com.au "No wife! No horse! No moustache!" � 聃컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� From: MABS85B@prodigy.com (Leo Wong) Subject: Re: 0123 Forth Date: 18 Apr 1996 12:51:45 GMT Message-ID: <4l5dt1$1tis@usenetp1.news.prodigy.com> References: <4l3j9u$1q22@usenetp1.news.prodigy.com> \ PRIMES, adapted from Wirth, Programming in Modula-2, 2nd ed., p. 41 200 CONSTANT #PRIMES \ number of primes to compute 3 CONSTANT #KNOWN \ I know the first 3: 2 3 5 VARIABLE NOW \ a counter \ first so many primes are used to determine if a number is prime \ only these primes are stored; the rest are just displayed 15 CONSTANT YOUNG \ need the square root of #PRIMES, says Wirth CREATE YOUTH YOUNG CELLS ALLOT HERE CONSTANT OLD \ don't care about middle age \ display words : TITLE ( -- ) CR ." The first " #PRIMES U. ." prime numbers are:" CR ; : .PRIME ( u) 8 U.R ; \ display the first 3 primes : .KNOWN ( -- ) 2 .PRIME 3 .PRIME 5 .PRIME ; \ determine if a number is prime : SQUARED ( n - n**2) DUP * ; : PRIME? ( u -- u a|0 ) \ a|0 used as a flag YOUTH BEGIN 2DUP @ 2DUP SQUARED U< 0= WHILE MOD 0= IF DROP 0 EXIT THEN CELL+ REPEAT 2DROP ; \ display the prime number and increase the counter : NOTIFY ( u -- ) .PRIME 1 NOW +! ; \ if a young prime, store it in the array and update pointer : ?YOUNG ( a1 u -- a2 u ) OVER OLD U< IF SWAP 2DUP ! CELL+ SWAP THEN ; \ if it's prime, do some work : ?PRIME ( a1 u -- a2 u ) PRIME? IF DUP NOTIFY ?YOUNG THEN ; \ skip multiples of 2 and 3 by alternately adding 2 or 4 \ to the previous candidate for prime : 2~4 ( 2|4 -- 4|2 ) 6 XOR ; : NEXT-CANDIDATE ( a1 u 2|4 -- a2 u+2|u+4 4|2 ) DUP >R + ?PRIME R> 2~4 ; \ the toy : PRIMES ( -- ) TITLE .KNOWN #KNOWN NOW ! 5 YOUTH ! YOUTH CELL+ \ won't need to divide by 2 or 3 5 2 \ first candidate will be 7 BEGIN NEXT-CANDIDATE NOW @ #PRIMES = UNTIL CR 2DROP DROP ; \ Leo Wong 18APR96 + From: MikeMcQuade@connect.com (Mike McQuade) Subject: PIC FORTH, where can I find info ? Date: Thu, 18 Apr 1996 04:41:11 GMT Message-ID: <4l4gk6$67d@wisdom.connectsoft.net> Im wondering if there is a FORTH for PIC microcontrollers, and if there is, can it be found on the net ? Is the PIC design not very FORTHable ? Thanks From: anton@a0.complang.tuwien.ac.at (Anton Ertl) Subject: Re: ANSForth A0005 re Initiation Semantics Date: 18 Apr 1996 14:05:11 GMT Message-ID: <4l5i6n$re4@news.tuwien.ac.at> References: In article , greg@minerva.com (Greg Bailey) writes: |> >I can not find the definition of " Initiation [semantics]" in the |> >" 2.1 Definitions of terms" but see this term in " 6.1.0450 :", p.30. |> > |> >Best regards, Michael |> >--- |> >Michael L. Gassanenko |> >gml@ag.pu.ru |> |> [Co-author Elizabeth Rather adds:] |> |> You will see it in 6.1.1250 DOES> as well. This describes the behavior of |> a word defined by : or a DOES> word when it begins to execute. The |> realization that this should be specified separately came rather late in |> the process, and I believe you are correct that we have not defined this |> term adequately. Why was this concept(?) added? Wouldn't it do just as well if this stuff was added to the description of the execution semantics of the defined word? E.g., for ":" name Execution: ( i*x -- j*x ) ( R: -- nest-sys ) Save implementation-dependent information nest-sys about the calling definition. Execute the definition name. The stack effects i*x and j*x represent arguments to and results from name, respectively. - anton -- M. Anton Ertl Some things have to be seen to be believed anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen http://www.complang.tuwien.ac.at/anton/home.html From: anton@a0.complang.tuwien.ac.at (Anton Ertl) Subject: Re: Forth is a toy (Was: 0123 Forth) Date: 18 Apr 1996 14:31:33 GMT Message-ID: <4l5jo5$re4@news.tuwien.ac.at> References: In article , wilbaden@netcom.com (W.Baden) writes: |> |>For me, Forth offers several features that C does not, e.g., the |> |>ability to create new code at run-time. |> |> Yes, Forth is an interactive compiler. |> No, C (e.g. in Unix) can create new code at run-time. I don't find any provision for run-time code generation in the C language standard, in contrast to Forth. Even with the restriction to Unix, I don't buy C run-time code generation. Please post code that does this, and I will try it out on all the Unix systems here. The requirements are that the code is generated at run-time and is called as a normal C procedure in the same run. |> |>User variables are a different concept for a different purpose. |> |> No, user variables are a special form of local variables. They |> are variables that are local to a user in a multi-user system. |> Some names are common to all users; some are particular to an |> application. But they were meant to be local variables. The commonalities between locals and user variables are: There are several instances of them. The differences are: the lifetime (end of definition vs. end of task) the visibility (only within a definition vs. everywhere) locals do not require a new user area for reentrancy (e.g., recursion and interrupt handlers) The difference in lifetime also implies a difference in memory usage. To me the differences are just as big as between global variables and locals. BTW, what makes you say that user variables work better in embedded control applications? |> |>|> And don't preach recursion to me. An important part of writing |> |>|> efficient programs is replacing recursion with iteration. |> |> |>Sounds like another dogma to me. |> |> No, still Occam's Razor. Occam's Razor (according to you): "It's vain to do with more what can be done with fewer." Sorry, I don't see how this says anything about efficient programs, but then your idea of program efficency may be different from mine (looking at the speed of ThisForth and Gforth suggests that). |> The future of Forth is as a tool, not a language. Forth is a language, so it can only have a future as a language. I don't see a contradiction between "tool" and "language", though. On the other hand, I would not regularly use a toy as a tool. - anton -- M. Anton Ertl Some things have to be seen to be believed anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen http://www.complang.tuwien.ac.at/anton/home.html From: ahorne@aa.net (Art Horne) Subject: Home Automation Forth Date: 18 Apr 1996 14:51:17 GMT Message-ID: <4l5kt7$njf@Holly.aa.net> References: <4kdrqe$skn@canyon.sr.hp.com> Reply-To: ahorne@aa.net In message <4kdrqe$skn@canyon.sr.hp.com> - Timothy Ressel,Non,HP,Unkn 9 Apr 1996 14:22:06 GMT writes: :> :>Anyone interested in a Forth which is customized for home automation? It has :>some nice features which make it quick and easy to program in. For example, :>my dampered HVAC code took a day to write and debug. :> :>-- Timster I'd be very interested also. Art _________________________ Art Horne K6KFH ahorne@aa.net May the FORTH be with you _________________________ From: nell@norland.idcnet.com (Russell R. Nell) Subject: Re: Can OO be successful in real-time embedded systems? Date: 18 Apr 1996 17:36:12 GMT Message-ID: <4l5uic$pr3@norgate.norland.com> References: <31710F7A.1F82@headwaters.com> >Dave Baldwin wrote: >> Henning Rietz (rietz@condat.de) wrote:[snip] >> >> : - "OO systems are too slow" >> : - "OO systems eat up too much memory"[snip] >> Object-dis-oriented programming is (like some others) intended to hide >> the hardware from the programmer. How useful can this possibly be when >> small embedded systems are expressly for dealing with the hardware? Why should any but the lowest level code know about hardware? Even without OO would you not put an abstraction layer around the hardware? Or is that abstraction layer just treating that hardware like the object it is??? Hello by the way, long time listener, first time poster. Will be starting an OO re-design of a 10 year old product soon. When I have the time to devote I will be posting a description of the project and a lot of questions. OO is a new (and overdue) idea for this company!!! -- Rusty Nail (Russell R. Nell) +============================+ /`-_ nell@norland.icdnet.com || Wisconsin Cheese-Head || { }/ (414) 563-8456 ext. 214 || and Damn Proud of it!!! || \ * / Norland Corporation +============================+ |___| W6340 Hackbarth Road, Fort Atkinson, WI 53538-8999 From: vern_tallman@usa.pipeline.com(Vernon M. Tallman) Subject: Re: Z80 Date: 19 Apr 1996 06:41:29 GMT Message-ID: <4l7cip$ad3@news1.h1.usa.pipeline.com> References: <4l65rk$bg9@newsbf02.news.aol.com> X-PipeUser: vern_tallman X-PipeHub: usa.pipeline.com X-PipeGCOS: (Vernon M. Tallman) There is an hforth for the Z80. I believe the file name is hfz80v97 and can be found at taygeta.com, I think in the /pub/Forth/Reviewed/ directory. If you can't find it, let me know & I'll search it out. From: Jim Subject: Spectra International, Inc. - Residual Gas Analyzers Date: Fri, 19 Apr 1996 10:39:12 -0700 Message-ID: <3177CFC0.20CD@ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-NETCOM-Date: Fri Apr 19 10:36:47 AM PDT 1996 X-Mailer: Mozilla 2.01 (Win95; I) Spectra is dedicated to the development and manufacture of an innovative range of residual gas analyzers (RGA) for industry and research vacuum systems. These instruments are the most sophisticated 5th generation technology and provide the leading edge software and electronic excellence required by the industry. Visit our New Web Site: http://www.spectra-rga.com Each product is developed through close liaison with customers working in real application environments. Precision engineering coupled with the latest in software and electronic technology is then used to produce high performance instruments and systems tailored to the real needs of the user. From: James@moose.co.uk (John Cornetto) Subject: WTB: Jupiter Ace Date: Sat, 20 Apr 1996 09:10:06 GMT Message-ID: <3178a96a.394908@news.moose.co.uk> Reply-To: James@moose.co.uk Remember this Forth-using blast from the past... I want to buy one or find an EMULATOR for the PC or Amiga... Replies via E-Mail.... Thanks! "If only I could wander freely thru the BBC Archives armed with Video and Tape Recorders.... Aaahh Damn!" ----- James@Moose.co.uk From: "Bruce R. McFarling" Subject: Re: Forth and Robots etc. Date: 20 Apr 1996 09:46:30 GMT Message-ID: <4labpm$e5b@seagoon.newcastle.edu.au> References: <66e9BcG67QB@business.forth-ev.de> <4ku8l6$lmn@uruguay.it.earthlink.net> <671AeJXr7QB@business.forth-ev.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.2N (Windows; I; 16bit) All@business.forth-ev.de (Wolfgang Allinger) wrote: > > I'm sorry that I made not clear, that this TOTSTEPS example should > only show an interface to the PC or service personal communication. > > The pumps number n addresses the pump. The PC wants to 'set' or to > 'get' the value of pump n. So the number may not be hidden inside a > word. If I followed the Forth 'rules' it will end up in a mess of > stack noise words or have different words for getting and setting > a variable. ... So I think, my solution should be acceptable ( as > users interface ) even to Forth guru's, because it shows the power > of Forth to create a friendly interface. To me, the problem is that demonstrating Forth of the ability to create a 'friendly interface' while stripping it of the ability to add new capabilities based on the capability that has just been defined. I don't see what is so unfriendly about letting the user say whether they want to get or to put the stuff. 0 VARIABLE DATA_READ? \ Are variables still defined this way? \ Or am I being obsolete, again? : GET ( -- ) \ Set the data direction for reading values (DATA_READ? == TRUE) TRUE DATA_READ? ! ; : PUT ( -- ) \ Set the data direction for writing values (DATA_READ? == FALSE) FALSE DATA_READ? ! ; \ What was the pumps word, again? Pretend it was "PUMP_STEPS" \ This should be done as a defining word making PUMP_STEPS, but \ I'm a rusty, genuine, non-guru : PUMP_STEPS ( ... \ I forget how you comment old fig-style \ variable stack effect words, other than: \ WARNING: Don't imitate this definition! DATA_READ? @ \ TRUE is autofetch, false, autostore IF @ ELSE ! ENDIF ; Now, admittedly, it's pretty horrible (evil, vile, etc). But at least it doesn't break when the stack depth changes, which pretty much misses the point of FORTH altogether (as opposed to abusing it) Virtually, Bruce R. McFarling, Newcastle, NSW ecbm@cc.newcastle.edu.au From: dibald@netcom.com (Dave Baldwin) Subject: Re: Can OO be successful in real-time embedded systems? Message-ID: References: <316BF0C5.1FE1@condat.de> <31710F7A.1F82@headwaters.com> <968@purr.demon.co.uk> <829849927snz@tcontec.demon.co.uk> <31783CC7.777B@immersive.com> Date: Sat, 20 Apr 1996 02:59:57 GMT After reading all of this, I wonder what you people think small, medium, and large embedded systems are. Maybe the things I was referring to are just considered 'tiny' to you. -- -=-=-=-=-=-=-=-=-=-=-=- Check out 'alt.tcj' -=-=-=-=-=-=-=-=-=-=-=-=-=- Dave Baldwin: dibald@netcom.com | The Computer Journal 1(800)424-8825 DIBs Electronic Design | Home page "http://www.psyber.com/~tcj/" Voice : (916) 722-3877 | Hands-on hardware and software TCJ/DIBs BBS: (916) 722-5799 | TCJ/DIBs FAX: (916) 722-7480 -=-=-=-=-=- @#$%^&* I can't even quote myself! Oh,well. -=-=-=-=-=- From: Elizabeth Rather Subject: Re: Z80 Date: 20 Apr 1996 15:54:53 GMT Message-ID: <4lb1ce$pkm@ecuador.it.earthlink.net> References: <4l8b0m$b5h@nadine.teleport.com> <4l8v7m$8ne@newsbf02.news.aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.12(Macintosh; I; 68K) To: cls@forthinc.demon.co.uk X-URL: news:4l8v7m$8ne@newsbf02.news.aol.com regnirps@aol.com (Regnirps) wrote: >I have checked the taygeta offerings, and they seem to be written for >CP/M. Forth has been around for 25 years, and the Z80 for a long time as >well. You would think there would be products for embedded development >available. My Forth Inc. brochure has no Z80 ChipForth. Perhaps we will >switch to the 68HC16 or an embedded PC, but it seems a shame. > >Charlie Springer Contact our UK rep, Chris Stephens, at cls@forthinc.demon.co.uk. I believe he has a Z80 version of chipFORTH. Cheers, Elizabeth Elizabeth D. Rather FORTH, Inc. Products and services for 111 N. Sepulveda Blvd. professional Forth programmers Manhattan Beach, CA 90266 since 1973. See us at: 310-372-8493/fax 318-7130 http://home.earthlink.net/~forth/ From: Elizabeth Rather Subject: Re: Reversible Forth? Date: 20 Apr 1996 16:07:05 GMT Message-ID: <4lb239$pkm@ecuador.it.earthlink.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.12(Macintosh; I; 68K) X-URL: news:Dq3uqH.AoD@hkuxb.hku.hk h9290246@hkuxa.hku.hk (Zsoter Andras) wrote: >Robert J. Brown (rj@eli.wariat.org) wrote: >> >>I was also trying to integrate these ideas with the Dreams OO >>approach. That proved to require implementing a full fledged shallow >>binding system such as is used in many modern Lisp interpreters. > > The question always is if it is worth to imitate Lisp (Smalltalk, etc.) >in Forth as precisely as possible or just use the "real thing" and get >a Lisp interpreter/compiler. We prefer a third alternative: use those concepts and strategies from OOP that are relevant to the application domain you're working in, and implement them in the way most appropriate to that environment. This is the approach we used in applying OOP techniques in our Class-based Data Base and EXPRESS industrial control system. Elizabeth D. Rather FORTH, Inc. Products and services for 111 N. Sepulveda Blvd. professional Forth programmers Manhattan Beach, CA 90266 since 1973. See us at: 310-372-8493/fax 318-7130 http://home.earthlink.net/~forth/ From: rj@eli.wariat.org (Robert J. Brown) Subject: Re: Forth and AI Date: 19 Apr 1996 14:49:55 GMT Message-ID: References: <4j93es$62@nadine.teleport.com> <4jckle$or8@news1.h1.usa.pipeline.com> <4jegvu$2ht@myst.plaza.ds.adp.com> <948@purr.demon.co.uk> <4km09d$rii@news.tuwien.ac.at> <316EDBFB.43B189D3@informatik.tu-muenchen.de> In-reply-to: Bernd Paysan's message of Sat, 13 Apr 1996 00:40:59 +0200 >>>>> "Bernd" == Bernd Paysan writes: Bernd> Anton Ertl wrote: [clever implementation deleted] >> This works right (on the example) in Gforth. It probably does >> not work well with the locals implementation in Gforth, but >> that can be fixed. Bernd> It worked out of the box with bigforth - except the ENDIF Bernd> (THEN is standard). However, the bigforth decompiler has Bernd> lots of problems with "test", because it doesn't expect a Bernd> word ending somewhere in the middle, starting with a new Bernd> word. Bernd> Locals: obviously :noname (and :) has to save the state of Bernd> the local variable's wordlist (and other states), and ; has Bernd> to restore them. Bernd> I like :[ ]:, and I think, I will use them in my bigFORTH Bernd> widgets packet. Thanks! I am glad to see a convention starting regarding this thing, even if it is de facto. Maybe in the next version of the ANS Forth standard... Bernd> Comment guideline: Use stack comments for every occurence Bernd> of :[, and say what it is meant to do (e.g. "click and drag Bernd> handler"). Excellent idea! Which commenting style do you think is better: : foo ( x y -- z ) blah blah :[ ( a -- b c ) blather blather ]: blah ; or: : foo ( x y -- z ) blah blah :[ blather blather ]: ( a -- b c ) blah ; The second is more Lisp-like, but I think I like the first better for Forth. What do you think? I also think the first reads better when the :[ and ]: operators are nested. I vote for the second. Bernd> -- Bernd Paysan "Late answers are wrong answers!" Bernd> http://www.informatik.tu-muenchen.de/~paysan/ -- ----------- "... And the men went up and viewed Ai." [Jos 7:2] ----------- Robert Jay Brown III rj@eli.wariat.org http://eli.wariat.org 1 847 705-0370 Elijah Laboratories Inc; 759 Independence Drive; Suite 5; Palatine IL 60074 ----- M o d e l i n g t h e M e t h o d s o f t h e M i n d ------ From: bobduff@world.std.com (Robert A Duff) Subject: Re: Can OO be successful in real-time embedded systems? Message-ID: References: <316BF0C5.1FE1@condat.de> <968@purr.demon.co.uk> <829849927snz@tcontec.demon.co.uk> <31783CC7.777B@immersive.com> Date: Sat, 20 Apr 1996 23:34:12 GMT In article <31783CC7.777B@immersive.com>, Marc de Groot wrote: >IMO, the essence of object-oriented programming is the explicit declaration >of the relationship between a data structure and the algorithms that operate >on it--which is what a class declaration is. Nah. That's just plain old abstract data types. Modula-2 modules can do this. Ada 83 packages can do this. Neither are "object oriented", in the usual sense. OO requires polymorphism, in addition to that other good stuff. - Bob From: Jim Subject: Spectra International, Inc. - Residual Gas Analyzers (RGA) Date: Sat, 20 Apr 1996 08:49:04 -0700 Message-ID: <31790770.4443@ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-NETCOM-Date: Sat Apr 20 10:46:27 AM CDT 1996 X-Mailer: Mozilla 2.01 (Win95; I) Spectra is dedicated to the development and manufacture of an innovative range of residual gas analyzers (RGA) for industry and research vacuum systems. These instruments are the most sophisticated 5th generation technology and provide the leading edge software and electronic excellence required by the industry. Visit our New Web Site: http://www.spectra-rga.com Each product is developed through close liaison with customers working in real application environments. Precision engineering coupled with the latest in software and electronic technology is then used to produce high performance instruments and systems tailored to the real needs of the user. From: "Paul E. Bennett" Subject: Re: Can OO be successful in real-time embedded systems? Date: Sat, 20 Apr 96 10:30:54 GMT Message-ID: <829996254snz@tcontec.demon.co.uk> References: <316BF0C5.1FE1@condat.de> <31710F7A.1F82@headwaters.com> <968@purr.demon.co.uk> <829849927snz@tcontec.demon.co.uk> <31783CC7.777B@immersive.com> Reply-To: peb@transcontech.co.uk X-NNTP-Posting-Host: tcontec.demon.co.uk X-Mail2News-Path: tcontec.demon.co.uk In article <31783CC7.777B@immersive.com> marc@immersive.com "Marc de Groot" writes: > Forth's CREATE...DOES>... construct embodies this essence neatly and simply. > The code following CREATE allocates the data structure, and the code > following DOES> operates on it. A Forth defining word is both > a class declaration and an implementation of its methods. Executing the > defining word constructs an object of that class. > > One powerful and unique aspect of Forth is that all words are members > of a single metaclass. That class has a uniform structure, consisting > (in an indirect-threaded system) of a pointer to native code followed > by an arbitrary data structure. This structure allows very high > efficiency at run time. The uniformity facilitates the implementation > of such tools as debuggers and decompilers. It also makes LISP-like > programming techniques more tractable, such as code creating and > modifying other code. With all that you state above, do you mean to say I have been doing "Object Oriented Design and Programming" all this time without realising it?. Wow!. You realise of course that it will now be just about impossible for me to consider programming systems with anything other than Forth. :) -- Paul E. Bennett Transport Control Technology Ltd. Tel: +44 (0)117-9499861 Going Forth Safely From: wtanksle@sdcc15.ucsd.edu (William Tanksley) Subject: Re: Reversible Forth? Date: Sat, 20 Apr 1996 08:46:02 -0400 Message-ID: <4lc711$c9p@sdcc12.ucsd.edu> References: h9290246@hkuxa.hku.hk (Zsoter Andras) wrote to us all: >Robert J. Brown (rj@eli.wariat.org) wrote: >>I was also trying to integrate these ideas with the Dreams OO >>approach. That proved to require implementing a full fledged shallow >>binding system such as is used in many modern Lisp interpreters. > The question always is if it is worth to imitate Lisp (Smalltalk, etc.) >in Forth as precisely as possible or just use the "real thing" and get >a Lisp interpreter/compiler. Let me point out a problem with that. First of all, nobody is concerned about 'precision' in imitating Scheme here; Mr. Brown was extending Forth. Okay, now to answer the question as asked: yes! That is, if your purpose is the acquisition of knowledge. I learned more about OO by first fitting it into Forth than I've learned ever since. There's also another reason, although you can't justify a perfect imitation this way. When you add things to Forth, you get to build them your own way, and perhaps you can make them faster. At the very least, the other things (the ones that don't use the fancy features) will go faster than they would have in Scheme, since in Scheme you HAVE to use the features. (I'm excluding the Scheme compilers that take up more than 60 megs, of course. They can outoptimise anything, I'm sure.) >Andras -Billy From: Bill Woods <74230.3552@CompuServe.COM> Subject: Forth instead of JAVA (RFC) Date: 21 Apr 1996 14:44:04 GMT Message-ID: <4ldhjk$pg5$1@mhadg.production.compuserve.com> I am playing the devil's advocate here ... If anyone has read on or checked into what JAVA (HOTJAVA) is all about will realize that it is compiled (in C) tokenized FORTH for creating on-line and downloadable APPS for INTERNET Browsers. In particular it is built into NETSCAPE. I'd like to hear some comments from everyone that knows more than myself about FORTH on why they would or would'nt think that FORTH can be tailored to this medium. (personally I think it would be no problem!). his could revolutionize the use of FORTH for better or worse. I also beleive that if not for use on the INTERNET and the like, that will be the death bell for the potential mass use of FORTH as we had all hoped when we were first introduced to it. Please POST to the news group "comp.lang.forth" any and all comments. let this start the beginning of that thread. From: Bill Woods <74230.3552@CompuServe.COM> Subject: Re: WHICH WAY TO GO, JAVA? VISUAL BASIC? HELP!!!! Date: 21 Apr 1996 14:56:53 GMT Message-ID: <4ldibl$pg5$2@mhadg.production.compuserve.com> References: <316F61EA.7D0E@immersive.com> Your last comment sounds like a great idea, could you please re-post those comments to the latest new thread "Forth or JAVA (RFC) thanks From: chris@nihilist.demon.co.uk (Chris Savage) Subject: Re: Can OO be successful in real-time embedded systems? Date: Sun, 21 Apr 1996 14:27:09 GMT Message-ID: <317a4454.60854648@news.demon.co.uk> References: <316BF0C5.1FE1@condat.de> <31710F7A.1F82@headwaters.com> <968@purr.demon.co.uk> <829849927snz@tcontec.demon.co.uk> <31783CC7.777B@immersive.com> X-NNTP-Posting-Host: nihilist.demon.co.uk dibald@netcom.com (Dave Baldwin) wrote: |After reading all of this, I wonder what you people think small, medium, |and large embedded systems are. Maybe the things I was referring to are |just considered 'tiny' to you. |-- I'm with you there. How many people use / would think of using OO in a highly cost-constrained _small_ microcontroller application (e.g. engine management, vcr, toaster, fork lift truck ?) |-=-=-=-=-=-=-=-=-=-=-=- Check out 'alt.tcj' -=-=-=-=-=-=-=-=-=-=-=-=-=- |Dave Baldwin: dibald@netcom.com | The Computer Journal 1(800)424-8825 |DIBs Electronic Design | Home page "http://www.psyber.com/~tcj/" |Voice : (916) 722-3877 | Hands-on hardware and software |TCJ/DIBs BBS: (916) 722-5799 | TCJ/DIBs FAX: (916) 722-7480 |-=-=-=-=-=- @#$%^&* I can't even quote myself! Oh,well. -=-=-=-=-=- ================================================= Chris Savage MSc Applications Software Engineer Sevcon Ltd. Kingsway Gateshead NE11 0QA UK Tel: +44 191 487 8516 Fax: +44 191 482 4223 ================================================= From: Stephen Pelc Subject: Re: Z80 Date: Sun, 21 Apr 96 16:27:21 GMT Message-ID: <830104041snz@mpeltd.demon.co.uk> References: <4l65rk$bg9@newsbf02.news.aol.com> Reply-To: sfp@mpeltd.demon.co.uk X-NNTP-Posting-Host: mpeltd.demon.co.uk X-Mail2News-Path: mpeltd.demon.co.uk In article <4l65rk$bg9@newsbf02.news.aol.com> regnirps@aol.com "Regnirps" writes: > I am looking for a Z80 Forth that targets an embedded Z80 and compiles on > a host PC. I need to do some trials without buying any software, (or I > would just go for the Forth Inc. product from the start). Any ideas? When you're prepared to spend some money, MPE's Z80/64180 cross compiler will do all that you need, and a lot more. Please send us your postal address to receive a catalogue. -- Stephen Pelc, sfp@mpeltd.demon.co.uk MicroProcessor Engineering - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 1703 631441, fax: +44 1703 339691 From: smurf@noris.de (Matthias Urlichs) Subject: Re: Forth and AI Date: 21 Apr 1996 18:45:30 +0200 Message-ID: <4ldona$ghe@work.smurf.noris.de> References: <4j93es$62@nadine.teleport.com> <4km09d$rii@news.tuwien.ac.at> <316EDBFB.43B189D3@informatik.tu-muenchen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit In comp.lang.forth, article , rj@eli.wariat.org (Robert J. Brown) writes: > > : foo ( x y -- z ) blah blah :[ ( a -- b c ) blather blather ]: blah ; > : foo ( x y -- z ) blah blah :[ blather blather ]: ( a -- b c ) blah ; > > The second is more Lisp-like, but I think I like the first better for > Forth. What do you think? I also think the first reads better when > the :[ and ]: operators are nested. I vote for the second. > I vote for the first. The second is confusing because it's not at the right nesting level. If you really want to have the comment at the end, why not use : foo ( x y -- z ) blah blah :[ blather blather ( a -- b c ) ]: blah ; The first way is also more readable because, just like with regular stack comments, you see what the word is supposed to do with the stack at the beginning; that helps to understand the beast when you next look at your code. ;-) -- Maybe Jesus was right when he said that the meek shall inherit the earth -- but they inherit very small plots, about six feet by three. --Lazarus Long -- Matthias Urlichs \ XLink-POP N�rnberg | EMail: urlichs@smurf.noris.de Schleiermacherstra�e 12 \ Unix+Linux+Mac | Phone: ...please use email. 90491 N�rnberg (Germany) \ Consulting+Networking+Programming+etc'ing 42 PGP: 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE Click here. From: ehp@ear.co.at (Ewald Pfau) Subject: Forth is a toy (Was: 0123 Forth) Message-ID: <830105923.AA00243@ear.co.at> Date: Sun, 21 Apr 1996 16:32:47 +0100 X-FTN-To: Hans Bezemer hbezemer@vsngroep.nl (Hans Bezemer) wrote: HB> Thank you. Let me be generous too. I think you know pretty HB> well what I mean with a mainstram programming language. I HB> mean the language programmers use to make their HB> applications. And face it: a programmer is not a programmer. My intention has been to put an eye as well on some absurdity which is the more involved, the more calculation steps are to be tamed in time, and as well the more people are involved in making use of it. The promise for an ease of interaction seems to have more weight, than the analysis and a precise description of what the interaction should be with. This is absurd. I apostrophated that ease by a 'click', the perfectly reduced scheme for waiting an expectation to be fulfilled. This expectation seems to have some religious connotation... Rolling this up from more a practical view, traditionally, numerical descriptions have been the domain of computatation. The concentration on this makes forget that this only holds for an ever getting smaller part of what is done. Yes, maybe as an expectation to mainstream programming it will still remain, to have all things reduced on relations between numerical data. But this gives by principle a low level description of what is done with those clocked beasts. And it expresses rather a (widely accepted) bored phantasy, instead that it could be held for realistic for the domains which are since of now be delegated to mechanical computation. Think of the computational description of how these lines written here are handled mechanically - is it really anymore best to be described by numerical parameters? Yes, I hold it for a sensible aspect, that logical layers of description remain transparent, so this handling may be described by relations of numerical data in the end. But this has hardly to do with constant cell sizes or typed operators. Yet more, I think, it has to do with corresponding data structures. Corresponding occurs among people attributing programs which I may use for writing the lines here. They accept given data structures and share its use. In a lot of domains of computation, this kind of sharing occurs at a public level. It could be watched the power games, by which such data structuring is tried ever and ever again to keep it hidden and only release pre-programmed schemes for accessing it (or but only ready-made programs). Since of now, mostly the public schemes have won. Say, TCP for moving data around the world, or a common description of a hypertext format. This would be for entering political questions at this point, with different answers given in different parts of the world. For example, algorithms may not be copyright protected by European understanding. By U.S. understanding, some use of mechanical computation is understood as weapon use. Now, what is a mainstream programmer in a context, which may not be cut into too narrow bounds? Since of some short time ago, the analogy would hold as proposed by theory of the exact sciences. That is, have the methods, as introduced by mathematics, as a common tool for description purposes of that sciences. This has been reflected at a common layer in programming mechanical computation: write down numbers, write down formulae. But the use of these machines isn't anymore the same. At an industrial level, the resulting gap in description has been tried to be filled by introduction of classes techniques. But this did not hold to the extend as having been supposed it should hold. So the gap is still there. The most realistic effort to fill it seems to have been made in database description languages. HB> There are guru's and people who just want to code their HB> address database and are very proud of what they HB> accomplished. Not everybody writes compilers. Therfore, in HB> my view Forth should be hiding more of its internals. Object HB> Orientation is a possibility, other schemes (like mine) are HB> possible too. As I see it, Forth is quite a unique tool, giving access to program mechanical computation transparently, by starting much more from a 'phenomenon of programming', instead by starting from a ready-made inplementation of some paradigmatical idea (that come and go as could be seen). The effort necessary is the one, to raise the small set, of what is there in a Forth implementation, to the level which should be dealt with. Only in a small number of applications, the best fitting description of what is done is that of 'numeric computation'. In most cases, this will be just an underlying concept and may be skipped with a few lines of code. All the same if it comes out to be sound or graphics or whatever, the elementary thing to be handled is that of interfacing, through data structures in memory, through files and databases. Bare computation is only a small part embedded in this. (Yes, interfacing may as well be described in terms of computation, but a more high level of description makes live easier here). HB> Let's face this scenario. Forth is interactive, huh? Nice HB> for "sitting behind the terminal and just start developing", HB> huh? Making prototypes, huh? Ok, this programmer starts HB> writing and has developed quite a lot. And then he finds out HB> that while his lower level routines SEEMED to get along HB> quite nicely with 16bits numbers, actually do not. He has to HB> rewrite most of the code to allow double numbers to be used. HB> In C (when you program properly) this is not much of a HB> problem since all operators (+, -, etc) work with double HB> numbers (longs) nice too. I gave the alert above, not to restrict a term of a 'mainstream programmer' to a partial term of her just being interested in enumerating numerical relations, since this only traditionally has been a main aspect, and has changed. The view you give above, should be best covered by complete (and as well interactive) database handling machines, but not by Forth in its 'phenomenon' state. There are at least two ways then, to have it done in Forth: The one is given traditionally in Forth, as well when it is sleeping with quite nice but naive dreams. This gives the well-known scheme of 'give the tools so you can help yourself on your own'. We know from political scenarious, that this scheme is superiour to the scheme 'help by donating'. Now, as seen from the naive side of the dreaming, each one does each thing by starting fresh and newly. There comes up the question: Where are all those tools for interfacing to all those common data formats, to be shared among Forth programmers? This scheme is an elementary one, and, if covered well, helps for acknowledgement of this kind for programming. The question is not the one about 'mainstream' but the one about how much effort is envolved to start off from a manageable level to succeed in a given task. The other scheme is: Suppose the 'programmer' to be a 'user' who is willing to consume ready-mades. Sell him the read-made factorizing of some given topic. Now in this aspect, the Forth way of coding is a beast, bearable only in a technical environment. There is no other means to prevent a 'user' from being held for dumb and bored than the responsibility of the one who writes those ready-mades. Something hidden in a Forth envirnonment may be hidden quite annoyingly perfectly. HB> Before programming anything, start out with a consistent HB> philosophy of what the application should do and what it's My veto: this is not philosophy but analysis. HB> limitations are. My 4tH doesn't use floating point, but HB> 32bits integers. One could make a floating point version, It is supposed to be supported if the respective ANS wordsets are claimed to be there. HB> but one has to reconsider the entire application. terminal HB> I/O changes (my 4tH uses the Forth way of converting and HB> displaying numbers), and some functions (like bitshifting) HB> have to disappear, while other have to be included (TAN, HB> COS, EXP, etc). This is because the scope of the application HB> have changed. May be some of the basic framework remains, That decision what should be there or not, beyond of the now given 'wordset description' scheme, is quite a personal decision. It hardly covered in a more common sense of use by asking generally for a 'mainstream', this has become quite diffuse. The assumption what a programmer could do, may be frozen by such a decision, to a partial view. Say, if someone builds the interfacing to WAVE files for sound cards, he wants to analyse read-in data and produce data according to this format. He will hardly ask if his task is in accordance to the implementation. An ANS Forth implementation will give him the tools he needs. He should write it in a way not to depend on a specific cell size and byte order of storing. If you promise to have 32 bit, he has to re-write it anyway, since the byte order of storage is critical. This is for scheme 1. of above. For scheme 2., the implementation itself is hidden behind an additional set of words, so the 'user' will not ask what the properties of the implementation are as far as this is covered by the additional set of words he uses. Those aspects remain the same, say, if someone wants to make up an interface to the widely used dB-3 format, say, by adding relational database access. HB> but not all of it. I guess your programmer didn't have any HB> "scope" or "philosophy" of what his application had to do. I HB> can give you more examples, because I've learned to work HB> this way in 15 years of programming more than a handful of HB> languages. I am afraid, as well in this case, philosophy is not of an issue for the view of that programmer. He behaved in the typical sense of someone who may regard himself not being responsible for anything in this regards, as someone who made donations to him (the icons he may apply his 'clicks' to) claims the responsibility to be on his side. The outcome has been that nice piece of harmless nonsense. >Put technically, he coded a bit of nonsense. Put in a pragmatical context, he >has the best arguments on his side. He talks the coding language which is >propagated anyway. HB> I don't get the last sentence. May be your english is better HB> than mine. I just think it's BAD coding! Hopefully my use of 'internationalized English' is not too much a translated German ;) I meant, that nice piece of harmless nonsense to be an outcome of the habits envolved. I have tried to make up a view of propagated classification schemes, by which each and every thing tends to be explained trivially and in terms of 'perfect control' (ready to fit in a set of icons to which that primitive way of interaction with 'clicks' may be applied). The one who programmed that bit field shifting by use of floating point operations, just only relied on this classification scheme to be right anyway. So he had no reason to make up an own idea of responsibility for what he does. To be embedded in that social context I named the 'pragmatical context' of his programming work. Ewald From: hbezemer@vsngroep.nl (Hans Bezemer) Subject: Re: Forth is a toy (Was: 0123 Forth) X-Nntp-Posting-Host: ztm99-15.zoetermeer.nl.net Message-ID: References: <830105923.AA00243@ear.co.at> Date: Sun, 21 Apr 1996 20:59:37 GMT ehp@ear.co.at (Ewald Pfau) wrote: >My intention has been to put an eye as well on some absurdity which is the more >involved, the more calculation steps are to be tamed in time, and as well the >more people are involved in making use of it. The promise for an ease of >interaction seems to have more weight, than the analysis and a precise >description of what the interaction should be with. This is absurd. Although I think this kind of discussions are useful, try to keep it readable. I have to make a translation just to make clear to others where the .. we are talking about. You just said here that the ease of use seems to be more important than a precise description of the datastructures lying behind. No, that is not what I meant. I meant that some programmers just think in numbers and strings. No more datatypes should be offered. That means the scope of this language is restricted and so is its use. Agreed, so what? >I apostrophated that ease by a 'click', the perfectly reduced scheme for >waiting an expectation to be fulfilled. This expectation seems to have some >religious connotation... C'mon, who is philosophical here? It's advertisement from the old days: 'all your figures in a simple keystroke". It has nothing to do with religion. But it has to do with several classes of programmers with different needs and thus different tools. Don't kill all that in order to give academic highpriests their status. It has to do with very smart programmers, writing tools for less smart programmers, less smart programmers making applications for users. Some days computers are as easy to use as any other device. >Think of the computational description of how these lines written here are >handled mechanically - is it really anymore best to be described by numerical >parameters? Yes, I hold it for a sensible aspect, that logical layers of >description remain transparent, so this handling may be described by relations >of numerical data in the end. But this has hardly to do with constant cell >sizes or typed operators. Whow, you're going down to earth pretty quickly! But these layers have to be written. And they get more abstract and more concrete at the same time. At the very bottom there are datastructures (char types, char arrays, dynamic memory). But when I write an application that takes care of mail, I may not want to get bothered by this. So some smart programmer writes a text-datatype, that I may pass to an editor-function, and get me back my text-datatype. That may mean that handling individual characters is more difficult. But on the other hand that is well beyond the scope of this application. A text-datype will do very well. But some programmer had to create a text-datatype and he did it, so the users of his toolkit could handle their problems more easily. He uses different tools. I write my programs preferably in C, which is too hard to handle for occasional programmers. Their task is to use my tool, which has to be as easy as possible. I know they don't want to be bothered by the sorrows of hard iron, so embedded are tools to show them where they go wrong. That their scope is different from mine is only logical. >Yet more, I think, it has to do with corresponding data structures. >Corresponding occurs among people attributing programs which I may use for >writing the lines here. They accept given data structures and share its use. Where do we differ in our views? >In a lot of domains of computation, this kind of sharing occurs at a public >level. It could be watched the power games, by which such data structuring is >tried ever and ever again to keep it hidden and only release pre-programmed >schemes for accessing it (or but only ready-made programs). Since of now, >mostly the public schemes have won. Say, TCP for moving data around the world, >or a common description of a hypertext format. I think both the lower datastructures should be hidden from lesser gods. They just have to use them, not to understand them. But at the same time the inner workings of these structures should be made publicly available for other programmers (their peers) to understand and use (or modify) It's not either or! >This would be for entering political questions at this point, with different >answers given in different parts of the world. For example, algorithms may not >be copyright protected by European understanding. By U.S. understanding, some >use of mechanical computation is understood as weapon use. Who is getting philosophical here? I get your point, different parts of the world have different views on the value of a "method", or software technology if you prefer. I take a different point of view. The sharing of knowledge in general gives rise to the Lamarckian evolution which is typical of every culture. Making this knowledge a privilege makes it more prone to extinction. But this is political. >But the use of these machines isn't anymore the same. At an industrial level, >the resulting gap in description has been tried to be filled by introduction of >classes techniques. But this did not hold to the extend as having been supposed >it should hold. Translation: right, object orientation promised a lot of reuse and it didn't. But people wrote libraries long before that. Any C++ program can be rewritten in C. But no tool of technique alone has brought salvation. But we're getting there. People are bying widgets (X-windows), VBX-es and that is a step in the right directions. Let's face it, 20 years before, everybody bought only programs or maybe subroutines. >So the gap is still there. The most realistic effort to fill it seems to have >been made in database description languages. When you refer to SQL I start laughing! >HB> There are guru's and people who just want to code their >HB> address database and are very proud of what they >HB> accomplished. Not everybody writes compilers. Therfore, in >HB> my view Forth should be hiding more of its internals. Object >HB> Orientation is a possibility, other schemes (like mine) are >HB> possible too. >As I see it, Forth is quite a unique tool, giving access to program mechanical >computation transparently, by starting much more from a 'phenomenon of >programming', instead by starting from a ready-made inplementation of some >paradigmatical idea (that come and go as could be seen). That's why it's so wonderful! And the only thing I see there are no levels here! You either hit it hard, or you use a kind of entry level Forth. I don't mean to say "you out there from ANS-Forth, kill all datatypes", but may be a little simplification could make it easier to programmers to choose Forth instead of Basic. I think we should have levels of Forth, compatible up to a certain point, like some BASIC's or Pascals. >All the same if it comes out to be sound or graphics or whatever, the >elementary thing to be handled is that of interfacing, through data structures >in memory, through files and databases. Bare computation is only a small part >embedded in this. (Yes, interfacing may as well be described in terms of >computation, but a more high level of description makes live easier here). Right, but don't tackle the whole world in the same go. I think it should be done consistently. Not reinvent a whole new set of words to tackle the same thing. E.g. "3 + 3" can be tackled in three ways in Forth, floating, single, double, unsigned, unsigned double and mixed. Do you really think a Basic Programmer wants to use that? In C he starts calling everyting an int and it works, then he climbs up to another level, but her doesn't have to learn a whole new set of words, like: int c = a + b; long c = ladd (a, b); unsigned c = uiadd (a,b); float c = fadd (a,b); double c = dadd (a,b); >I gave the alert above, not to restrict a term of a 'mainstream programmer' to >a partial term of her just being interested in enumerating numerical relations, >since this only traditionally has been a main aspect, and has changed. I asked you what a 'mainstream porgrammer' is. If you ask my dad whether he is interested in enumerating numerical relations, he'll probably says, that he is just an ordinary guy who wants to program his address-book and occasionally something to help him filling in this taxes. Mainstream programmers do not know what you mean, but sometimes they DO wanna add up things. As easily as possible. [SNIPP!!] I'm getting tired of this. We're getting nowhere, when we don't come down on common ground, I guess. And I got other things to do. Like documenting my new interpreter. >Hopefully my use of 'internationalized English' is not too much a translated >German ;) Take my word for it. Try to keep your sentences down to one line and your words to an average of two-three syllables. That will stop you from thinking in German, since no English sentence is THAT long. And are you sure every concept you use is clear with your readers or are you just showing off? Hans. From: wtanksle@sdcc15.ucsd.edu (William Tanksley) Subject: Re: Forth and AI Date: Sun, 21 Apr 1996 12:14:57 -0400 Message-ID: <4lecg5$r03@sdcc12.ucsd.edu> References: <4j93es$62@nadine.teleport.com> <4jckle$or8@news1.h1.usa.pipeline.com> <4jegvu$2ht@myst.plaza.ds.adp.com> <948@purr.demon.co.uk> <4km09d$rii@news.tuwien.ac.at> <316EDBFB.43B189D3@informatik.tu-muenchen.de> rj@eli.wariat.org (Robert J. Brown) wrote to us all: >>>>>> "Bernd" == Bernd Paysan writes: > Bernd> I like :[ ]:, and I think, I will use them in my bigFORTH > Bernd> widgets packet. >Thanks! I am glad to see a convention starting regarding this thing, >even if it is de facto. Maybe in the next version of the ANS Forth >standard... I hope so. It's amazing that we can get so many to agree ;). > Bernd> Comment guideline: Use stack comments for every occurence > Bernd> of :[, and say what it is meant to do (e.g. "click and drag > Bernd> handler"). >Excellent idea! Which commenting style do you think is better: > : foo ( x y -- z ) blah blah :[ ( a -- b c ) blather blather ]: blah ; >or: > : foo ( x y -- z ) blah blah :[ blather blather ]: ( a -- b c ) blah ; >The second is more Lisp-like, but I think I like the first better for >Forth. What do you think? I also think the first reads better when >the :[ and ]: operators are nested. I vote for the second. I DEFINITELY prefer the first, because the :[]: expressions are supposed to be independant of the word they're in. They could quite well be executing way later, after all, and not affecting the stack of the word they're in. If you put the comment after, it actually looks like it's part of the containing word. Let's have a little more dicussion as well. What words have you found to be effective as auxilaries for :[]: phrases? What factorizations (i.e. can you use the primitives that make these up to make other useful words)? I would imagine that some thought into this would result in a very powerful concept. One thing that occurs to me is that, in a way, the ":" and ";" words are extremely similar to :[]:. Suppose that the STATE variable were 'fuzzy' rather than boolean? You could define regular words like this: :[ 10 + ]: :DEFINES 10-MORE Of course, this looks like a reversal of tradition-- normally we have [ and ] indicate a backing out of compilation. We'd have to change that if we did this regularly, and that's not good. No fair regularizing one new element if we destroy one old one, eh? That could be an argument against :[]:. Bad. Hmm, I've got another one-- it's hard to type. How about .[].? Less shift key action. Or maybe :():? <<>>? -<>-? >----------- "... And the men went up and viewed Ai." [Jos 7:2] -------- Curiosity: why this particular quote? -Billy From: filter@firthcom.demon.co.uk (Steve Firth) Subject: Re: WTB: Jupiter Ace Date: Sun, 21 Apr 1996 23:51:40 +0100 Message-ID: References: <3178a96a.394908@news.moose.co.uk> Reply-To: filter@firthcom.demon.co.uk X-NNTP-Posting-Host: firthcom.demon.co.uk In article <3178a96a.394908@news.moose.co.uk>, James@moose.co.uk (John Cornetto) wrote: >Remember this Forth-using blast from the past... I want to buy one or >find an EMULATOR for the PC or Amiga... > >Replies via E-Mail.... Thanks! So tell me, is there any reason why you don't answer email sent to you? I did offer an Ace to you but had no reply.... From: pcg@aber.ac.uk (Piercarlo Grandi) Subject: Re: Can OO be successful in real-time embedded systems? Date: 21 Apr 1996 23:42:17 +0100 Message-ID: References: <316BF0C5.1FE1@condat.de> <968@purr.demon.co.uk> <829849927snz@tcontec.demon.co.uk> <31783CC7.777B@immersive.com> Reply-To: pcg@aber.ac.uk (Piercarlo Grandi) In-reply-to: bobduff@world.std.com's message of Sat, 20 Apr 1996 23:34:12 GMT >>> On Sat, 20 Apr 1996 23:34:12 GMT, bobduff@world.std.com (Robert A >>> Duff) said: bobduff> In article <31783CC7.777B@immersive.com>, bobduff> Marc de Groot wrote: marc> IMO, the essence of object-oriented programming is the explicit marc> declaration of the relationship between a data structure and the marc> algorithms that operate on it--which is what a class declaration marc> is. bobduff> Nah. That's just plain old abstract data types. Modula-2 bobduff> modules can do this. Ada 83 packages can do this. Neither are bobduff> "object oriented", in the usual sense. OO requires ^^^^^^^^ bobduff> polymorphism, in addition to that other good stuff. Therefore as program which just does not happen to use polymorphism cannot be called an OO program :-/. From: h9290246@hkuxa.hku.hk (Zsoter Andras) Subject: Re: Reversible Forth? Message-ID: References: <4lb239$pkm@ecuador.it.earthlink.net> Date: Mon, 22 Apr 1996 08:59:13 GMT Elizabeth Rather (erather@forth.com) wrote: >the way most appropriate to that environment. This is the approach we used in >applying OOP techniques in our Class-based Data Base and EXPRESS industrial >control system. Is this sytem documented anywhere (journals, books and the like) what I can access? I always see you posting that Forth Inc. does it better but I have to BELIEVE what you said, I cannot read the code. (Well, I know in industrial and NASA projects everything is secret but I find it annoying that I cannot see any actual code. Even in papers in FD and such there is only a succeess story. No code not even examples. :-((((( ) Andras From: h9290246@hkuxa.hku.hk (Zsoter Andras) Subject: Re: Reversible Forth? Message-ID: References: <4lc711$c9p@sdcc12.ucsd.edu> Date: Mon, 22 Apr 1996 13:11:41 GMT William Tanksley (wtanksle@sdcc15.ucsd.edu) wrote: > >Let me point out a problem with that. First of all, nobody is concerned >about 'precision' in imitating Scheme here; Mr. Brown was extending Forth. > >Okay, now to answer the question as asked: yes! That is, if your purpose is >the acquisition of knowledge. I learned more about OO by first fitting it >into Forth than I've learned ever since. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ;-) Well once you learned OOP what else do you want? I do not believe that Dreams was written for "aquisition of knowledge". To write a system so complicated (it took me a while to get its concepts from the JFAR paper) already REQUIRED a LOT of knowledge beforehand! You have actually explained why I am asking the question: >There's also another reason, although you can't justify a perfect imitation >this way. When you add things to Forth, you get to build them your own way, >and perhaps you can make them faster. At the very least, the other things >(the ones that don't use the fancy features) will go faster than they would >have in Scheme, since in Scheme you HAVE to use the features. > >(I'm excluding the Scheme compilers that take up more than 60 megs, of ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >course. They can outoptimise anything, I'm sure.) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Good programmers spent several decades to improve Lisp, SmallTalk and the like. If you can do something BETTER in Forth then that is the way to go. If you feel the need to implement a partial Lisp interpreter and program in that, you really should think about getting an "off the shelf" Lisp, which is very likely to be much better than your "hacked" one. Andras From: M.L.Gassanenko Subject: Re: Who needs the Forth text interpreter? Date: 22 Apr 1996 17:42:05 +0400 Message-ID: X-Return-Path: ttpl!ttpl.iias.spb.su!mlg I liked the approach mentioned in this thread and decided to repeat it on top of my classical model system. (I haven't done it, but I think it will be interesting to hear why; probably, I will return to it.) --- The approach is: to have no interpret-mode, always compile (to a temporary buffer) and execute what has been compiled when the control flow stack is empty. The advantage of this approach is that definitions like : tuck compile dup compile -rot ; immediate become executable; so are all compilation-only words. --- I could think out an exception: BEGIN and UNTIL (and DO and LOOP) implemented wholely via return stack manipulations: : begin r@ >r ; ( R: -- addr ) : until ( f -- ; R: addr -- addr ; ip:=addr | t -- ; R: addr -- ) if ( leave the loop) r> r> drop >r else ( repeat it once more ) r> drop r@ >r then ; but it is rather exotic (even although it can be meaningful for DO and LOOP). --- My old interpreter worked like (I hope there's no typo) begin bl word find dup if 1 = if execute else state @ if compile, else execute then then else drop number? dup 0= ?undefined state @ if #literal else drop then then again \ 4 if's The new interpreter should work as begin bl word find dup if 1 = if execute else compile, then else number? dup 0= ?undefined #literal ( compile properly) then cs-depth 0= if then again \ only 3 if's so far But: 1. I had to have a temporary compilation buffer I could not compile at HERE because 10 0 do i , loop would destroy itself and hang. 2. If I wanted to build sometimes colon definitions, I had to have a switch indicating where I compile to -- the STATE (and the 4th IF in INTERPRET). 3. I had to create a separate control flow stack and to redefine the control structure words: my system used the data stack for this purpose. But there is 1 more thing most compiling interpreters miss: ability to conditionally compile a : definition. I decided that my implementation must be able to compile: .( Is the weather fine? [y/n] ) key char y = if : hello ." hello! " ; else : hello ." I am bored " ; then This meant that : would have a very unstandard behaviour, but this could show in only a few cases, so I decided to go on. I borrowed the idea from Postscript that : must leave a string and the beginning of a code fragment on the stack, while ; must pick them up and create a new definition. The threaded code in my implementation was relocatable, so ; could MOVE it to HERE where the new function was created. So far I managed to avoid system recompilation. But then I realised that COMPILE, must ALWAYS compile to the temporary buffer, and that I have to either redefine all words that use COMPILE, or change the COMPILE, , and this stopped me. Somewhy I did not want to change my existing system. --- SO, 1. the compiling interpreter cannot be an ANS Forth program (which probably characterizes the set of techniques left in the standard as insufficient) 2. implementation of the compiling interpreter on a classical model system requires many changes 3. it may be ANSI-compatible from user's point of view 4. it is of some additional value 5. changing the behaviour of : can lead to interesting effects. --- M.L.Gassanenko mlg@iias.spb.su gml@agspbu.spb.su From: h9290246@hkuxa.hku.hk (Zsoter Andras) Subject: Re: Can OO be successful in real-time embedded systems? Message-ID: References: <829996254snz@tcontec.demon.co.uk> Date: Mon, 22 Apr 1996 13:27:11 GMT "Paul E. Bennett" (peb@transcontech.co.uk) wrote: >> One powerful and unique aspect of Forth is that all words are members >> of a single metaclass. That class has a uniform structure, consisting >> (in an indirect-threaded system) of a pointer to native code followed >> by an arbitrary data structure. This structure allows very high >> efficiency at run time. The uniformity facilitates the implementation >> of such tools as debuggers and decompilers. It also makes LISP-like >> programming techniques more tractable, such as code creating and >> modifying other code. > >With all that you state above, do you mean to say I have been doing "Object >Oriented Design and Programming" all this time without realising it?. Wow!. Whether you believe it or not some programmers actually think so. :-( Some even claim that OOP is unnecessary because "we had it all the time as CREATE DOES>". :-((( Andras From: h9290246@hkuxa.hku.hk (Zsoter Andras) Subject: What about another CATCH and THROW Message-ID: Date: Mon, 22 Apr 1996 13:33:49 GMT I was thinking about what is wrong with CATCH and THROW and it is the stack effect. If something gets consumed it becomes messy. Also depending on success/failure the stack effect is different. What I could make up is this: NewCatch ( #count token ) #count is the difference in the number of stack items before and after EXECUTE-ing token. The word NewCatch could adjust the stack by so and so many items, so it can remove debris from the stack and the stack effect of a #params ['] Whatever NewCatch could always be the same. I would be curious what other programmers think about it. Andras From: MABS85B@prodigy.com (Leo Wong) Subject: Re: 0123 Forth Date: 22 Apr 1996 14:07:29 GMT Message-ID: <4lg3r1$n52@usenetp1.news.prodigy.com> \ PRIMES, adapted from Wirth, Programming in Modula-2, 2nd ed., p. 41 \ using /mod \ miscellaneous tools 1 CELLS CONSTANT CELL : CELL- ( a1 -- a2 ) 1 CELLS - ; 200 CONSTANT #PRIMES \ number of primes to compute 3 CONSTANT #KNOWN \ I know the first 3: 2 3 5 VARIABLE NOW \ a counter \ first so many primes are used to determine if a number is prime \ only these primes are stored; the rest are just displayed 15 CONSTANT YOUNG \ need the square root of #PRIMES, says Wirth CREATE YOUTH YOUNG CELLS ALLOT HERE CONSTANT OLD CELL ALLOT \ don't care about middle age \ display words : TITLE ( -- ) CR ." The first " #PRIMES U. ." prime numbers are:" CR ; : .PRIME ( u) 8 U.R ; \ display the first 3 primes : .KNOWN ( -- ) 2 .PRIME 3 .PRIME 5 .PRIME ; \ determine if a number is prime : PRIME? ( u -- u remainder ) YOUTH BEGIN 2DUP @ DUP >R /MOD R> > WHILE DUP WHILE DROP CELL+ REPEAT THEN NIP ; \ display the prime number and increase the counter : NOTIFY ( u -- ) .PRIME 1 NOW +! ; \ if a young prime, store it in the array and update pointer : ?YOUNG ( a1 u -- a2 u ) OVER OLD U< IF SWAP 2DUP ! CELL+ SWAP THEN ; \ if it's prime, do some work : ?PRIME ( a1 u -- a2 u ) PRIME? IF DUP NOTIFY ?YOUNG THEN ; \ skip multiples of 2 and 3 by alternately adding 2 or 4 \ to the previous candidate for prime : 2~4 ( 2|4 -- 4|2 ) 6 XOR ; : NEXT-CANDIDATE ( a1 u 2|4 -- a2 u+2|u+4 4|2 ) DUP >R + ?PRIME R> 2~4 ; \ the toy : PRIMES ( -- ) TITLE .KNOWN #KNOWN NOW ! 5 YOUTH ! YOUTH CELL+ \ won't need to divide by 2 or 3 5 2 \ first candidate will be 7 BEGIN NEXT-CANDIDATE NOW @ #PRIMES = UNTIL CR 2DROP DROP ; \ Leo Wong 22APR96 + From: MABS85B@prodigy.com (Leo Wong) Subject: Re: 0123 Forth Date: 22 Apr 1996 14:08:26 GMT Message-ID: <4lg3sq$1ba8@usenetp1.news.prodigy.com> \ ANSified Sieve of Eratosthenes 8192 CONSTANT SIZE \ will test this many odd numbers CREATE FLAGS SIZE CHARS ALLOT \ make list of flags HERE CONSTANT END-FLAGS \ the address after the list \ miscellaneous tools : CHAR- ( a1 -- a2 ) 1 CHARS - ; : UNDER+ ( n1 n2 n3 -- n1+n3 n2 ) \ n2 is an address from COUNT ROT + SWAP ; \ not needed in implementations that \ use FLAGS I + C@ : ZERO-MULTIPLES ( incrment a1 a2 -- ) DO 0 I C! DUP +LOOP DROP ; : SIEVE ( -- ) FLAGS SIZE 1 FILL \ assume all the numbers are prime 0 \ 0 the count of primes FLAGS \ start with first flag SIZE 0 DO \ outer loop COUNT IF \ prime? ; address now next flag I 3 * 3 + SIZE < IF \ is the next multiple in the array? I 2* 3 + CHARS \ inner loop increment 2DUP + CHAR- \ inner loop start END-FLAGS \ inner loop end SWAP ZERO-MULTIPLES \ the inner loop THEN 1 UNDER+ \ increment count of primes THEN LOOP DROP U. ." Primes" ; \ Leo Wong 22APR96 + From: hbezemer@vsngroep.nl (Hans Bezemer) Subject: Re: Forth instead of JAVA (RFC) X-Nntp-Posting-Host: asp99-24.amsterdam.nl.net Message-ID: Reply-To: hbezemer@vsngroep.nl References: <4ldhjk$pg5$1@mhadg.production.compuserve.com> Date: Mon, 22 Apr 1996 13:32:21 GMT Bill Woods <74230.3552@CompuServe.COM> wrote: >I'd like to hear some comments from everyone that knows more >than myself about FORTH on why they would or would'nt think >that FORTH can be tailored to this medium. (personally I think >it would be no problem!). I've got already experience with a Forth producing portable bytecode. I'm willing to share this technology with any person or group who wants to venture into this. Hans. From: anton@a0.complang.tuwien.ac.at (Anton Ertl) Subject: Re: Forth instead of JAVA (RFC) Date: 22 Apr 1996 16:34:58 GMT Message-ID: <4lgcfi$hu1@news.tuwien.ac.at> References: <4ldhjk$pg5$1@mhadg.production.compuserve.com> if WE can STOP this NONSENSE ..., I will write a little about my view of JavaVM and Forth. I have a student who does a JavaVM->native code compiler for his Diplomarbeit (~master's thesis). Because we are already writing a Forth->native code compiler, he will do his compiler as a JavaVM->Forth compiler (and do another target for the Forth->native code compiler). Some of the non-trivial pieces in translating JavaVM to Forth, that we have identified, are: garbage collection threads control structures (branches->ANS Forth's seven universal control structure words) exceptions subroutines (JavaVM does not specify that a subroutine returns to its caller) JavaVM makes the same mistake as Forth standards up to Forth-83: It specifies type sizes (e.g., a JavaVM int is always 32-bit). A few operators have to be added to support this. The native libraries (without them JavaVM can do nothing). - anton -- M. Anton Ertl Some things have to be seen to be believed anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen http://www.complang.tuwien.ac.at/anton/home.html From: "Ellis D. Cooper" Subject: FORTH Date: Mon, 22 Apr 1996 11:46:51 -0500 Message-ID: <317BB7FB.3ED3@delphi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0 (WinNT; I) Please let me know whether there is a commercially available FORTH with the following characteristics: 1. Runs on a PC 2. 32 bit 3. text (not block) based 4. can produce a compiled .EXE to run under DOS 5. can read/write strings from/to ascii text files 6. can do basic low-level i/o Thank you. Ellis D. Cooper, xtalv1@delphi.com From: lekollar@nyx10.cs.du.edu (larry kollar) Subject: Re: Can OO be successful in real-time embedded systems? Date: 22 Apr 1996 11:47:09 -0600 Message-ID: <4lggmt$kip@nyx10.cs.du.edu> References: <316BF0C5.1FE1@condat.de> <31783CC7.777B@immersive.com> <317a4454.60854648@news.demon.co.uk> Thus spake Dave Baldwin: >After reading all of this, I wonder what you people think small, medium, >and large embedded systems are. Maybe the things I was referring to are >just considered 'tiny' to you. A company I *used* to work for made a terminal server by embedding a stripped-down UNIX, plus TCP/IP, in ROM. To me, that would be a large embedded system. I once hung a Rat Shack motion detector off the joystick port of my Amiga and used JForth to monitor (and react to) someone tripping the detector. That would have been a medium system, if I'd taken it beyond that point and actually made it into something useful. :-) As for small... well, what would a small system have been in the days when 16K of RAM was a lot of memory in a computer? Times change, and so does the capability of the hardware. -- Larry Kollar, Dawsonville GA | *** Hatred is murder *** (1 Jn 3:15) lekollar@nyx.net | http://www.nyx.net/~lekollar/ "So don't try to turn my head away Flirtin' with disaster every day" From: Lee Webber Subject: Re: Can OO be successful in real-time embedded systems? Date: 22 Apr 1996 16:23:30 GMT Message-ID: <4lgbq2$fri@wizard.pn.com> References: <316BF0C5.1FE1@condat.de> <31710F7A.1F82@headwaters.com> <968@purr.demon.co.uk> <829849927snz@tcontec.demon.co.uk> <31783CC7.777B@immersive.com> <317a4454.60854648@news.demon.co.uk> chris@nihilist.demon.co.uk (Chris Savage) wrote: > > dibald@netcom.com (Dave Baldwin) wrote: > > |After reading all of this, I wonder what you people think small, medium, > |and large embedded systems are. Maybe the things I was referring to are > |just considered 'tiny' to you. > |-- > I'm with you there. How many people use / would think of using OO in a > highly cost-constrained _small_ microcontroller application (e.g. > engine management, vcr, toaster, fork lift truck ?) Hardly anyone. What's amazing to me is how few people would use OO in a somewhat larger system, say 128K to 1 Meg of memory, 16-bit processor -- and how few OO language vendors think such targets are worth supporting. From: anton@a0.complang.tuwien.ac.at (Anton Ertl) Subject: Re: Reversible Forth? Date: 22 Apr 1996 16:04:43 GMT Message-ID: <4lgamr$49t@news.tuwien.ac.at> References: <828369021snz@apvpeter.demon.co.uk> <316D6537.7083@tis.com> In article <316D6537.7083@tis.com>, Peter Churchyard writes: |> 15 Years ago I had a Forth system that could run programs backwards since it was |> being used to implement a Prolog system. It had a shadow stack that kept track of |> whether each item on the forth stack was defined or undefined, kept a list of |> decision points and a list of modified things. |> |> so running |> 10 + |> backwards would initially give you on the stack |> 10 0 |> if you failed it would give you |> 9 1 |> etc... I came upon a similar concept (when I though how I could extend the parser generator Gray to general attributed grammars): Replace every value appearing in a Forth program with a logic variable. We can now execute a Forth program symbolically (without specifying the initial stack) and get a constraint network (you need a Prolog system that supports arithmetic constraints to do Forth arithmetic in this way). Now we can instantiate the input and output variables to compute in any direction: forward (instantiate input), backwards (instantiate output), mixed (instantiate some input and some output), check (instantiate input and output). E.g., for the little Forth interpreter that is written in Prolog and shown below, we can run the Forth program "dup +": ?- forth([dup,'+'],[X],[],D,R). The data stack contains [X] at the start and D at the end, the return stack [] at the start and R at the end. The Prolog system gives the following solution: D = [_A], R = [], {_A=2*X} (The "{_A=2*X}" is a constraint). Now we can do a little backwards computation: ?- forth([dup,'+'],[X],[],[Y],R), {Y=4}. i.e., we specify that the data stack at the end is [4]. The Prolog system gives the following solutions R = [], X = 2, Y = 4 i.e., the data stack at the start is [2]. Here's the Forth interpreter that does this. It uses Sicstus Prolog's CLP(Q) package. This is a slight variation of the Prolog program for optimizing stack manipulation sequences that I posted some time ago. :- use_module(library(clpq)). %eff(Word,Data_Stack_in, Return_Stack_in, Data_Stack_out, Return_Stack_out). eff(swap,[A,B|D],R,[B,A|D],R). eff(dup,[A|D],R,[A,A|D],R). eff(drop,[A|D],R,D,R). eff('>r',[A|D],R,D,[A|R]). eff('r>',D,[A|R],[A|D],R). eff('r@',D,[A|R],[A|D],[A|R]). eff(rot,[A,B,C|D],R,[C,A,B|D],R). eff(over,[A,B|D],R,[B,A,B|D],R). eff('2dup',[A,B|D],R,[A,B,A,B|D],R). eff(nip,[A,B|D],R,[A|D],R). eff(tuck,[A,B|D],R,[A,B,A|D],R). eff('+',[A,B|D],R,[C|D],R):-{A+B=C}. eff('-',[A,B|D],R,[C|D],R):-{B-A=C}. %forth(List,Data_Stack_in, Return_Stack_in, Data_Stack_out, Return_Stack_out). forth([],D,R,D,R). forth([Word|Words],Din,Rin,Dout,Rout):- eff(Word,Din,Rin,D1,R1), forth(Words,D1,R1,Dout,Rout). - anton -- M. Anton Ertl Some things have to be seen to be believed anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen http://www.complang.tuwien.ac.at/anton/home.html From: drichmond@utah-inter.net (David Richmond) Subject: Exceptions in pF32-386/MSD from Forth, Inc. Message-ID: <4167cc$b324.19d@NNTP> Date: Mon, 22 Apr 1996 16:58:19 GMT I've been trying to get protected mode exception handlers working in a target compiled system (the FORTH is pF32-386/MSD from Forth, Inc.), where the target system does not have an assembler or compiler. I am not having much success. Is there anyone out there who has mastered this task that could provide any insights? Any help will be greatly appreciated. Thank You, David Richmond From: Keith <73760.3521@CompuServe.COM> Subject: FORTH FAQ Wanted Date: 22 Apr 1996 20:47:00 GMT Message-ID: <4lgr84$psk$1@mhafn.production.compuserve.com> I've been out of the FORTH world for some time and would like to get a recent FAQ for this group to see what is new and going on. Can anyone point me to it? For what it is worth, although I'm sure the FAQ will have my answers, is there a pd, shareware, or commercial (that costs about the same as BC++) that has a good graphics library, printing support, and doesn't require (or hides them from me) unusual tricks to access all the memory in a system. This would be for DOS; 32-bit systems would be appreciated but I don't expect there are low-cost versions. Thanks in advance. Keith R. Frederick / 73760.3521@compuserve.com / 206 286 0356 / 800 708 0356 ps. Does FIG (Forth Interest Group) still exist? I use to be a member but let membership lapse many years ago. From: wtanksle@sdcc15.ucsd.edu (William Tanksley) Subject: Re: Reversible Forth? Date: 22 Apr 1996 20:57:16 GMT Message-ID: <4lgrrc$2vq@sdcc12.ucsd.edu> References: <4lc711$c9p@sdcc12.ucsd.edu> In article h9290246@hkuxa.hku.hk (Zsoter Andras) writes: >William Tanksley (wtanksle@sdcc15.ucsd.edu) wrote: >>Let me point out a problem with that. First of all, nobody is concerned >>about 'precision' in imitating Scheme here; Mr. Brown was extending Forth. >>Okay, now to answer the question as asked: yes! That is, if your purpose is >>the acquisition of knowledge. I learned more about OO by first fitting it >>into Forth than I've learned ever since. >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ;-) >Well once you learned OOP what else do you want? I deserved that, didn't I. ;) Okay, how about "than I've learned about OOP ever since." Happy now? :) > I do not believe that Dreams was written for "aquisition of knowledge". >To write a system so complicated (it took me a while to get its concepts >from the JFAR paper) already REQUIRED a LOT of knowledge beforehand! Of course! The more you have the more you want, true? When I had no knowledge I didn't think. When I gained a bit of knowledge I thought I had it all and wanted no more. The more I know the more I know how little I know. ;) C'est la vie. >You have actually explained why I am asking the question: >>There's also another reason, although you can't justify a perfect imitation >>this way. When you add things to Forth, you get to build them your own way, >>and perhaps you can make them faster. At the very least, the other things >>(the ones that don't use the fancy features) will go faster than they would >>have in Scheme, since in Scheme you HAVE to use the features. >>(I'm excluding the Scheme compilers that take up more than 60 megs, of >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>course. They can outoptimise anything, I'm sure.) >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Good programmers spent several decades to improve Lisp, SmallTalk and the >like. If you can do something BETTER in Forth then that is the way to >go. If you feel the need to implement a partial Lisp interpreter and >program in that, you really should think about getting an "off the shelf" >Lisp, which is very likely to be much better than your "hacked" one. Let me say it again. I, and probably others want to use some of the things that exist in Scheme some of the time. We don't want to use them all of the time, because they tend to slow most things down; we don't want to buy 56 more megs of RAM to run a good Scheme compiler. Plus, we like Forth. There you have it. And why not? Yes, Lisp is undoubtably a better Lisp than Forth would be; most of its implementations probably handle the Lisp-specific stuff better than we could write it into Forth. But Lisp can't do Forth stuff without adding Lisp overhead, and Forth can. Lisp can't do ANY Lisp stuff without adding most of the Lisp overhead, and we could theoretically avoid that. >Andras -Billy From: MABS85B@prodigy.com (Leo Wong) Subject: Re: 0123 Forth Date: 24 Apr 1996 12:42:39 GMT Message-ID: <4ll7jv$16fi@usenetp1.news.prodigy.com> References: <4kbb00$1mbc@usenetp1.news.prodigy.com> <66yaqsv67qb@business.forth-ev.de> <4lj0ia$2ir@hkusuc.hku.hk> <4ljcuo$lgg@usenetp1.news.prodigy.com> <4ljdjd$18lk@usenetp1.news.prodigy.com> \ Fractions \ adapted from Wirth, Programming in Modula-2, 2nd ed., pp. 40-41 \ for Bob Nash \ miscellaneous tools : OOZE ( a b c -- b a c a ) ROT TUCK ; : SWOOP ( a b -- b a a ) SWAP DUP ; : UNDER+ ( a b c -- a+c -- b ) ROT + SWAP ; : .CHAR ( -- ) POSTPONE [CHAR] POSTPONE EMIT ; IMMEDIATE : CHAR-ARRAY CREATE ( u -- ) CHARS ALLOT DOES> ( u -- addr ) SWAP CHARS + ; \ data structures DECIMAL 32 CONSTANT MAXDIVISOR MAXDIVISOR CHAR-ARRAY DIGIT MAXDIVISOR CHAR-ARRAY INDEX \ display words : .DIVISOR ( u -- ) CR 4 U.R 2 SPACES ; : .DIGITS ( u1 u2 -- ) ?DO I DIGIT C@ 0 U.R LOOP ; : .FRACTION ( count index -- ) ." 0." DUP 1 .DIGITS .CHAR ' 1 UNDER+ .DIGITS SPACE ; \ the instrument : FRACTIONS ( -- ) MAXDIVISOR 1+ 2 DO 0 INDEX MAXDIVISOR 0 FILL 0 1 \ starting count, remainder BEGIN 1 UNDER+ 2DUP INDEX C! 10 * I /MOD OOZE DIGIT C! SWOOP INDEX C@ ?DUP UNTIL NIP \ discard remainder I .DIVISOR .FRACTION LOOP ; : F ( -- ) FRACTIONS ; \ Leo Wong 24APR96 + From: h9290246@hkuxa.hku.hk (Zsoter Andras) Subject: Re: Can OO be successful in real-time embedded systems? Date: 24 Apr 1996 10:26:40 GMT Message-ID: <4lkvl0$5o9@hkusuc.hku.hk> References: <316BF0C5.1FE1@condat.de> <31710F7A.1F82@headwaters.com> <968@purr.demon.co.uk> <829849927snz@tcontec.demon.co.uk> <31783CC7.777B@immersive.com> <4ljfqo$j17@rational.rational.com> Bob Kitzberger (rlk@rational.com) wrote: >Dave Baldwin (dibald@netcom.com) wrote: >: After reading all of this, I wonder what you people think small, medium, >: and large embedded systems are. Maybe the things I was referring to are >: just considered 'tiny' to you. > tiny 0 -- 1k lines > small 1k -- 10k lines ^^^^^^^^^^ Are we still living in the FORTRAN age? Andras From: Dan McGinn-Combs Subject: Re: Forth instead of JAVA (RFC) Message-ID: <317E2F3D.1279@dbsoftware.com> Date: Wed, 24 Apr 1996 09:40:13 -0400 References: <4ldhjk$pg5$1@mhadg.production.compuserve.com> X-Mailer: Mozilla 2.01 (WinNT; I) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bill Woods wrote: > > I am playing the devil's advocate here ... > If anyone has read on or checked into what JAVA (HOTJAVA) is all > about will realize that it is compiled (in C) tokenized FORTH > for creating on-line and downloadable APPS for INTERNET Browsers. > In particular it is built into NETSCAPE. > > I'd like to hear some comments from everyone that knows more > than myself about FORTH on why they would or would'nt think > that FORTH can be tailored to this medium. (personally I think > it would be no problem!). I was actually considering the possibility of using one of the FORTH chips as the primary processor of the much touted Internet PC. Then the native machine language would be "Java" and one could write much faster "applets." Anyone who has played much with Java will tell you, it really needs a very fast processor. Why? Because of all the tokenization and layering to get to the machine beneath, right? So, why not bring the machine to the Java? Just a thought, Dan McGinn-Combs danx@dbsoftware.com D&B Software, Atlanta, Georgia From: Todd Hoff Subject: Re: Can OO be successful in real-time embedded systems? Date: Wed, 24 Apr 1996 07:52:40 -0700 Message-ID: <317E4038.7AB5@possibility.com> References: <316BF0C5.1FE1@condat.de> <31710F7A.1F82@headwaters.com> <968@purr.demon.co.uk> <829849927snz@tcontec.demon.co.uk> <31783CC7.777B@immersive.com> <317a4454.60854648@news.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.01 (WinNT; I) C. T. Nadovich wrote: > A manager can pay a co-op to click and drag together a > toaster's embedded control system in a few minutes using third-party OO > widgets. The reason i don't see this happening is that every embedded target, for cost and other reasons, is very custom. Devices are swapped in at the last minute, a lot of ASICs and FPGAs are used, PIOs and serial protocols vary hugely. Not to mention switching OSs to get a smaller cost per copy. It's a very difficult environment to automate for. > useful skill with megabit DRAMS selling for less than $2. If the toaster It's not $2, not even close. And yes, people will kill over $2. And don't forget PROM will probably have to scale up as RAM increases. > costs $0.10 more with OO, but I can get it to market 6 months earlier, my > bottom line tells me what to do. There's a lot more to making a system than generating a few classes, but yes, it would be nice to automate more of it. You seem to be confusing OO with automation. OO may or may not cut the per unit cost, but automation would. And if you are automating the style of generated code is not critical. > I know that point of view may rub some embedded SW gurus the wrong way, No, not all, many of us aggresively push for automation. But automation implies a degree of standardization. And standardization doesn't exist in the embedded world. From: Jason McDonald Subject: Internet Resource Lists - Forth and Embedded Systems - Pointer Date: 24 Apr 1996 14:43:04 GMT Message-ID: <4llelo$arg@nntp1.best.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.22 (Windows; U; 16bit) We maintain a series of internet resource lists on embedded systems, including Forth at: Main Home Page: http://www.cera2.com/ebox.htm http://www.eg3.com/ebox.htm Forth Page http://www.cera2.com/forth.htm http://www.eg3.com/forth.htm If you know of other free or non-commercial Internet resources, please email comments@eg3.com for inclusion. Thank you.