Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Alexander Skobelev Newsgroups: comp.lang.forth Subject: Re: FORTH on the Advanced Placement Computer Science ! Date: Sat, 10 Jan 2015 16:48:35 +0300 Organization: A noiseless patient Spider Lines: 141 Message-ID: References: <7xd277yybp.fsf@ruckus.brouhaha.com> <7xbnmquimp.fsf@ruckus.brouhaha.com> <3d03e403-7181-4ab3-8a2f-a23d0c4843f7@googlegroups.com> <87y4pt4qkl.fsf@jester.gateway.sonic.net> <2014Dec27.111715@mips.complang.tuwien.ac.at> <878uhs4zxk.fsf@jester.gateway.sonic.net> <871tnd9dg0.fsf@jester.gateway.pace.com> <87387q5hi8.fsf@jester.gateway.sonic.net> <87iogkweeq.fsf@jester.gateway.sonic.net> <87zj9vrhe5.fsf@jester.gateway.sonic.net> <87mw5vbnf9.fsf@jester.gateway.sonic.net> <15be3232-0368-404b-a5fe-d18d0fbd305d@googlegroups.com> <87zj9uv8n2.fsf@jester.gateway.sonic.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="9c0b930d8ac4a57f81167d1a74f8f538"; logging-data="2081"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18StryjtW38TfJy8Jp6FpdR" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (darwin) Cancel-Lock: sha1:GngmRhFwF+rl3s7kzR5jMWhEGEc= sha1:2JjylVyujOBXWw2Xwm/YLqk7jLw= Xref: csiph.com comp.lang.forth:35697 Julian Fondren writes: > On Wednesday, January 7, 2015 10:49:24 AM UTC-6, Paul Rubin wrote: >> Julian Fondren writes: >> > The author of BAR in file1.fs is not the slightest bit inconvenienced by >> > the earlier X that only FOO cared about. ... >> > The problems you're worrying about aren't Forth problems to begin with. >> >> But now there's two variables of dead weight in the microcontroller's >> scarce ram instead of just one, or better yet none. > > I think that you need a series of concrete examples for you to to > really get anywhere talking about this. In a game of 'what if' > other people will just keep saying, OK, if that were the case, > then I would do something different, but since that's hardly ever > the case, it doesn't have a lot to do with what's actually done... > which is what I'd assume you're interested in. > > Anyway, I've never written for a microcontroller, so I won't reply > to this. > >> Also not explained is what to do if FOO or BAR is recursive. > > variable x > : foo ( n-lim n -- ) 2dup = if 2drop exit then > x @ over cr type 1+ recurse ; > : bar ( c-addr u -- ) > swap x ! 1+ 1 foo ; > > s" hello" bar > h > he > hel > hell > hello ok > > Recursive functions still have stacks. If you're walking a tree, > you don't need to keep copying the tree for each recursive call; > just keep navigation information on the stack. Meanwhile, in the > context of actual code, a variable might be a reasonable place for > the tree. > >> I wrote a word a while back >> that I just couldn't see a decent way to write without locals or (if >> general) some kind of ALLOCed or ALLOTed resizeable auxiliary array. It >> was recursive so it couldn't use VARIABLEs to hold temporaries, and it >> had enough stuff on the stack that juggling with DUP/ROT/etc. would have >> been awful. In practice the recursion depth was never higher than about >> 4, so setting aside a static buffer would have been ok for the >> application, but still. > > Why not post stuff like this to clf? You still might not like the > answer, but you'd have it. > >> Maybe things would ease up if we were less squeamish about reaching into >> the data stack. > > Yuck. > >> Let's face it, we already have started down >> that path if we accept the existence of ROT, 2OVER, and so on. > > No, we haven't. There has indeed been no movement along that path > at all. 2OVER operates on a stack of three elements -- it just > looks like more when you use the wrong stack notation. Avoiding > ROT and -ROT just causes your code to grow little return-stack > mushrooms. I tried. They grew. I said: this is just giving the > return-stack a bad name. > > (And the way I think of it is: I use ROT want I want the third > element to come to me. I use -ROT when I want the first element > to go away from me. Come, come, come; go away go away go away. > There's even something subtly negative about the word -ROT) > >> So we could have OVER0, OVER1, OVER2, ... up to OVER8 say. >> OVER[k] is the same as k PICK so OVER0 is like DUP, OVER1 is like >> OVER, and so on. These aren't as ugly as PICK since they each have >> a predictable (not data dependent) stack action. > > They are exactly as ugly as PICK . You must be considering beauty > from the perspective of a static analysis program. For a human > OVER[k] is just going to be interchangable with k PICK > > > Meanwhile, have some ugly attempts at delocalizing some > triangle-drawing: > > 2e wide s>f f/ fconstant width > 2e deep s>f f/ fconstant depth > > ... > > : brick, { F: x F: y -- } \ bottom-left-coord -- > x sf, y sf, > x width f+ sf, y sf, > x width f+ sf, y depth f+ sf, > x sf, y sf, > x width f+ sf, y depth f+ sf, > x sf, y depth f+ sf, > > ... > > : x'th ( n -- r ) 2* sfloats here + sf@ ; > : y'th ( n -- r ) 2* 1+ sfloats here + sf@ ; > > : brick ( F: x F: y -- ) \ bottom-left-coord -- > fswap sf, sf, > -1 y'th -1 x'th wide f+ sf, sf, > -2 y'th -1 x'th sf, depth f+ sf, > -3 y'th -3 x'th sf, sf, > -2 y'th -2 x'th sf, sf, > -1 y'th -2 x'th sf, sf, ; > > ... > > fvariable x fvariable y > : coord, ( -- ) x sf@ sf, y sf@ sf, ; > : deeper ( -- ) here 2 sfloats - dup sf@ depth + swap sf! ; > : wider ( -- ) here 1 sfloats - dup sf@ wide + swap sf! ; > > : brick ( F: x F: y -- ) y sf! x sf! \ bottom-left coord -- > coord, > coord, wider > coord, wider deeper > coord, > coord, wider deeper > coord, deeper ; > > -- Julian Why just don't use FOVER and FDUP? : brick, ( x y -- ) \ bottom-left-coord -- fover sf, fdup sf, fover width f+ sf, fdup sf, fover width f+ sf, fdup depth f+ sf, fover sf, fdup sf, fover width f+ sf, fdup depth f+ sf, fover sf, fdup depth f+ sf, FDROP FDROP ;