wmb@MITCH.ENG.SUN.COM (09/20/90)
> The question I have at this point is what weight should be given to the > consistency position you cite in your new-user case. I assume you also > have problems explaining why IF THEN DO LOOP and so on also > don't work if interpreted? Not any more. I fixed them so that they do work if interpreted. It is remarkably easy to do; the trick is to switch to compile state when the beginning of a control structure is encountered, and execute the temporary definition when that control structure is completed. I wrote a paper about this that was published in the 1987 (I think) FORML proceedings, and John Hayes recently published an extension of same in Forth Dimensions (issue before last). The whole mechanism for interpreted conditionals adds 200 bytes to the Forth system. The reason I was motivated to work out this interpreted control structure scheme was because I was trying to explain to a new Forth user (who happens to be a world-class C programmer) why control structures don't work in interpret state. He persisted in thinking it was stupid that Forth was inconsistent in this respect, and I discovered that I agreed with him. So I fixed it. I would also note that >R and R> can be used in interpret state in the latest version of my system. Mitch
bouma@cs.purdue.EDU (William J. Bouma) (09/22/90)
In article <9009211313.AA26438@ucbvax.Berkeley.EDU> wmb%MITCH.ENG.SUN.COM@SCFVM.GSFC.NASA.GOV writes: >Not any more. I fixed them so that they do work if interpreted. It is >remarkably easy to do; the trick is to switch to compile state when the >beginning of a control structure is encountered, and execute the temporary >definition when that control structure is completed. I wrote a paper about Just curious. Does something like [ IF THEN ] work? What about? [ IF [ IF THEN ] THEN ] How about? IF [ : ... ; ] THEN Or? IF [ : ... [ : ... ; ] ... ; ] THEN 8^) I once made my system work for all of the above and more. Yes, it was easy to implement, the problem was error recovery! I found that making forth COMPLETELY consistent was actually quite painful to do right. It may be nice not to have to explain the superficial inconsistencies to a beginner, though, as you say. You got a paper out of that!? -- Bill <bouma@cs.purdue.edu> Just ask the Axis He knows everything
wmb@MITCH.ENG.SUN.COM (09/22/90)
> Just curious. > Does something like [ IF THEN ] work? Yes > What about? [ IF [ IF THEN ] THEN ] > How about? IF [ : ... ; ] THEN > Or? IF [ : ... [ : ... ; ] ... ; ] THEN 8^) No I was interested in making interpreted control structures work correctly, within the context of otherwise-traditional Forth usage. Nested brackets, and colon definitions nested within control structures, are outside the scope of what I was trying to accomplish. In order to support nested brackets/colon-definitions, one must dispense with the traditional notion of STATE as a global variable. (Defining new and better interpretations of Forth operators is fun and I have done my share of it in private, but I had a much less ambitious, and thus more likely achievable, goal in this case.) > You got a paper out of that!? Sure, why not? I did not claim to be the first person to have invented such a scheme (in fact I cited several examples of "prior art"). I was simply reminding implementors who may not have thought of it (and there are many of them) that it is very easy and inexpensive to do (and I showed them how), so why aren't they doing it? Papers do not have to be earth-shattering. If they did, the Forth literature would be pretty sparse. Forth to the Future, Mitch Bradley, wmb@Eng.Sun.COM
dwp@willett.pgh.pa.us (Doug Philips) (09/22/90)
In <9009220119.AA14290@ucbvax.Berkeley.EDU>, wmb@MITCH.ENG.SUN.COM writes: > Sure, why not? I did not claim to be the first person to have invented > such a scheme (in fact I cited several examples of "prior art"). I was > simply reminding implementors who may not have thought of it (and there > are many of them) that it is very easy and inexpensive to do (and I showed > them how), so why aren't they doing it? I think you ask a very good question. From what I have heard, the stock answer is "Forth programmers are too independant" to use someone elses code/ideas. Or "Forth means do it your way." Or "Do it the way that best suits the problem at hand" which is really just "A general purpose solution is anathema to Forth." I think those are nice anecdotal replies, but I'm not convinced they are the real explanation. There are those who claim that Forth is more philosophy than programming particulars, and they probably aren't even interested in the question. Personally, I think it is because there is no longer (if there really ever was, and I don't want to get into that debate here) a standard Forth which allows code sharing. I hope the ANS Forth, when it becomes widely available, will change that. > Papers do not have to be earth-shattering. If they did, the Forth > literature would be pretty sparse. As it is its fairly dense, esp. for such a so-called niche language. I gave my personal belief as to why ideas which have been written about again and again haven't caught on. I think input from those that have been in the trenches would be better. -Doug --- Preferred: dwp@willett.pgh.pa.us Ok: {pitt,sei,uunet}!willett!dwp
shri@ncst.ernet.in (H.Shrikumar) (10/02/90)
In article <9009220119.AA14290@ucbvax.Berkeley.EDU> wmb%MITCH.ENG.SUN.COM@SCFVM.GSFC.NASA.GOV writes: > >> How about? IF [ : ... ; ] THEN >> Or? IF [ : ... [ : ... ; ] ... ; ] THEN 8^) > >No > >Nested brackets, and colon definitions nested within control structures, >are outside the scope of what I was trying to accomplish. In order to >support nested brackets/colon-definitions, one must dispense with the >traditional notion of STATE as a global variable. I plan to do this in myForth. Well, actually I am trying to get rid of STATE. The definition of a word in myForth is allowed to have other word definitions within, Pascal style, recursively. Dictionary searches while compiling a word begin with the local definitions which therefore over-ride the top-level definition of the same ideogram. The compiler is not overly complicated, since I have precisely one context-free construct ( ... ). While compiling, myForth compiler would first compile the innermost definition, and proceed outward in level of nested parens. The link field of each top-level ideogram would skip all the local definitions and keep them invisible. Am I headed for big trouble with this ? (This being my first go a post-fixing, I am a bit nervous.) -- shrikumar ( shri@ncst.in ) Disclaimer: myForth is just in the works, admittedly my syntax needs some more cleaning up, so I avoid giving a concrete example at this stage.