karl@ficc.uu.net (karl lehenbauer#) (09/01/88)
In article <535@hudson.acc.virginia.edu>, pmy@vivaldi.acc.virginia.edu (Pete Yadlowsky) writes: > Baggage, baggage and more baggage. Type checking?! *gag* I don't want > some uppity compiler protecting me from myself and telling me how I > may and may not use my computer. That stuff's fine for beginners, but > when it's time to cut loose and actually put the machine to work... Oh, please! I once spent days finding a bug in a Forth program where a guy had done a store (rather than a c-store) into a CVARIABLE, clobbering an adjacent data byte (1802 polyForth with separate symbol table) Most of my C bugs seem to be type conflicts in function calls, incorrect number of arguments and such, which ANSI X3J11 addresses at last. I expect that the ANSI C compiler is going to catch 90% of my bugs. Don't get me wrong, I like Forth a lot, but in Forth when one gets the number of arguments wrong, like in a loop, one typically blows the stack and crashes the machine. Eliminating type checking from the language leaves it to the programmer, in FORTH a word for every operation for every data type, and Forth (and FORTRAN where one has to kludge pointers as array indexes and such to get around not having data types) will merrily compile bogus code that a type-checking compiler would gritch at, leaving it to the programmer to debug. Again, I am not constrained by type checking; type checking catches bugs; type checking finds and notifies the programmer of *impossible* usages of data. Although it is "telling me how I may and may not use my computer," it is never appropriate to do word writes into byte fields, use floating point numbers as pointers, pass ints to routines that want pointers to floats &c &c &c (I just have to keep harping. Consider the DO..LOOP, IF..THEN, BEGIN..REPEAT security in Forth that insure control structures are properly nested. Hey, that's the machine telling me what to do!? If I want to write a routine with a LOOP that doesn't have a DO, that's my business. :-) -- -- +1 713 274 5184, uunet!ficc!karl -- Ferranti International Controls, 12808 W. Airport Blvd., Sugar Land, TX 77478
pmy@vivaldi.acc.virginia.edu (Pete Yadlowsky) (09/02/88)
In article <1389@ficc.uu.net> karl@ficc.uu.net (karl lehenbauer#) writes: >In article <535@hudson.acc.virginia.edu>, pmy@vivaldi.acc.virginia.edu (Pete Yadlowsky) writes: >> Baggage, baggage and more baggage. Type checking?! *gag* I don't want >> some uppity compiler protecting me from myself and telling me how I >> may and may not use my computer. That stuff's fine for beginners, but >> when it's time to cut loose and actually put the machine to work... >Oh, please! I once spent days finding a bug in a Forth program where a guy >had done a store (rather than a c-store) into a CVARIABLE, clobbering an >adjacent data byte (1802 polyForth with separate symbol table) If you spent days searching for this bug, it must have been buried pretty deeply into the code. Why was this? Forth code is supposed to be developed incrementally, with careful testing all along. I think one of the reasons large compilers need type checking is because they make incremental development relatively difficult. Nobody wants to write a main driver to test each and every subroutine. So they lean on the compiler. When habits like monolith-writing and compiler-leaning are carried over into Forth, disasters like the above occur. >Don't get me wrong, I like >Forth a lot, but in Forth when one gets the number of arguments wrong, like >in a loop, one typically blows the stack and crashes the machine. Well, don't *DO* that! :-) >Again, I am not constrained by type checking; type checking catches bugs; >type checking finds and notifies the programmer of *impossible* usages of >data. Although it is "telling me how I may and may not use my >computer," it is never appropriate to do word writes into byte fields, use >floating point numbers as pointers, pass ints to routines that want pointers >to floats &c &c &c Never? Ever? I think such decisions should be left to the application, not to the compiler. Granted, the things mentioned above do sound weird and maybe dangerous. But if I want to do "crazy" stuff, I should have that freedom. Sometimes crazy is appropriate. Suppose I need a word that will accept pointers or ints, and act according to some flag or code vector? What if I want to access two bytes sometimes as bytes, sometimes as a single word? C, for instance, will allow such things with pointer coercion, but in Forth I can just go ahead and do it without worrying about pleasing the compiler. This kind of freedom is, to me, worth the price of being careful. >(I just have to keep harping. Consider the DO..LOOP, IF..THEN, BEGIN..REPEAT >security in Forth that insure control structures are properly nested. Hey, >that's the machine telling me what to do!? No, that's the compiler saying "Hey, I don't know how to handle this", not "Yo! Dummy! You can't do that." >If I want to write a routine with >a LOOP that doesn't have a DO, that's my business. :-) Certainly is, and you certainly may. You'll just have to write your own control structure, that's all. There's nothing inherent in the compiler that disallows such a thing. Peter M. Yadlowsky Academic Computing Center University of Virginia pmy@vivaldi.acc.Virginia.EDU
karl@ficc.uu.net (karl lehenbauer#) (09/08/88)
In article <544@hudson.acc.virginia.edu>, pmy@vivaldi.acc.virginia.edu (Pete Yadlowsky) writes: > If you spent days searching for this bug, it must have been buried pretty > deeply into the code. Why was this? Forth code is supposed to be developed > incrementally, with careful testing all along. Not all bugs can be found by unit testing. Some bugs do not manifest themselves until some other criteria are met, perhaps after the system is installed, even in Forth. > Suppose I need a word that will > accept pointers or ints, and act according to some flag or code vector? > What if I want to access two bytes sometimes as bytes, sometimes as a > single word? In C, unions exist for this purpose. > No, that's the compiler saying "Hey, I don't know how to handle this", not > "Yo! Dummy! You can't do that." You sure there's a difference? Not for the control structure example, I think. Anyway, *I* still want it to not let me do things that can't possibly be valid, such as my examples before: storing words into character variables, comparing integer and floating point without a prior conversion, calling a routine that expects a pointer with an integer, &c &c Sorry, but I think most computer scientists will agree that while Forth provides a very nice programming environment, it is not a particularly good programming language. -- -- +1 713 274 5184, uunet!ficc!karl -- Ferranti International Controls, 12808 W. Airport Blvd., Sugar Land, TX 77478
jax@well.UUCP (Jack J. Woehr) (09/10/88)
In article <1423@ficc.uu.net> karl@ficc.uu.net (karl lehenbauer#) writes: > >Sorry, but I think most computer scientists will agree that while Forth provides >a very nice programming environment, it is not a particularly good programming >language. >-- Well, some people who *call* themselves computer scientists talk trash like that ... but rarely someone from the *control industry* which your mail addr seems to peg you as, friend! Do you mean to tell me that in 1988 you are doing control applications and are not using Forth? ********************* jax@well.UUCP jax works at Vesta Technology Inc. jax@chariot.UUCP "Controllers 'R' US" JAX on GEnie just my opinion, etc. but i'm pretty damn smart.
karl@ficc.uu.net (karl lehenbauer#) (09/12/88)
In article <7071@well.UUCP>, jax@well.UUCP (Jack J. Woehr) writes: > Well, some people who *call* themselves computer scientists talk > trash like that ... but rarely someone from the *control industry* > which your mail addr seems to peg you as, friend! > > Do you mean to tell me that in 1988 you are doing control applications > and are not using Forth? Neither does the Forth language nor any Forth environment to my knowledge adequately support the development of millions of lines of code by hundreds of programmers, which is the scale of the activities at this mail address. I asserted that Forth was a good environment but not so good of a language. You Forth fanatics are all in love with the environment, so you're willing to overlook the problems with the language, such as the lack of data types, inability to determine if words have their parameters set up properly (again, no types and no ability to specify number of arguments passed to or received by a word) and lack of an infix notation (important, I think, to broaden the popularity of the language). Disk I/O could be improved (standardized and add some sort of standard or quasi-standard file support) There needs to be some sort of stdio-type thing. String processing is pretty abysmal. Floating point standards are nonexistent. Most Forth environments are not well integrated with the native operating system, when Forth is not used as the native operating system. In most cases, it is hard or impossible to execute a Forth program from a command line as a simple application, as one does all the time with C, assembly or whatever programs. There is no widespread ability to call Forth from other languages or to call code written in other languages from Forth. One might say, "yeah, but why would I want to do this?" Consider it a good neighbor policy. Those other languages are able to interact, I can call C from LISP, why not Forth? And as for realtime, most Forth environments are not realtime, because they use a polyForth-style polled task switcher rather than a preemptive exec. Believe me, I understand the appeal of Forth for programming. I used Forth to do a dual-processor, multitasking control system and it was wonderful to be able to type the words into the console and scan the points, switch the relays and such. Indeed, the ability to quickly turn around a change or a test, one the order of a minute instead of several hours once it was in the field certainly saved my butt. Nonetheless, it should be possible to improve the language while maintaining the thing everyone likes: the environment. There are those who will continue to argue that no data types, postfix notation and such make the language better. People and companies vote with their time and money, however. Their resources remain solidly behind the C/FORTRAN conventional language axis. Forth remains a curious, tho' interesting and capable, footnote, and will continue to be one at least until it appears viable to the mainstream of the computer community. Are they just a bunch of old retreads who wouldn't know a fish if we hit them in the face with one? Possibly. :-) But we shouldn't dismiss their indifference as being entirely due to their ignorance: We too may be considered to have failed for not having adequately communicated to them the language's capabilities and utility, or for the arrogance of not having taken seriously their suggestions, criticisms and complaints. Taking the attitude that anyone who disagrees is a fool or a bloody fish-face only helps to perpetuate Forth's outcast status. -- -- +1 713 274 5184, uunet!ficc!karl -- Ferranti International Controls, 12808 W. Airport Blvd., Sugar Land, TX 77478
jbn@glacier.STANFORD.EDU (John B. Nagle) (09/13/88)
"while maintaining the thing everybody likes - the environment."
The block-oriented disk files and the heap-structured dictionary?
That's a desirable environment?
I've used Forth out of dire necessity on very tiny machines in
embedded applications. But I cannot see much use for it on anything
large enough to support a serious compiler. On the other hand, a
compiled Forth with type checking might be useful.
One observation is that novice programmers get excited about small
scale syntactical issues, such as RPN vs infix, and more experienced
programmers get excited about large scale issues, such as modularity and
name-space management. As program size grows, these issues dominate,
for combinatorial reasons.
In some ways, Forth is reminiscent of APL, another language for small
programs. APL is a language of clever one-liners, like Forth. APL is also
almost unmaintainable. As well as being almost forgotten.
John Naglepmy@vivaldi.acc.virginia.edu (Pete Yadlowsky) (09/14/88)
In article <17702@glacier.STANFORD.EDU> jbn@glacier.UUCP (John B. Nagle) writes: > "while maintaining the thing everybody likes - the environment." >The block-oriented disk files and the heap-structured dictionary? >That's a desirable environment? Apparently so, to those who know it. Actually, many modern forths interface well to the presiding OS, and use named disk files instead of blocks. > I've used Forth out of dire necessity on very tiny machines in >embedded applications. But I cannot see much use for it on anything >large enough to support a serious compiler. You may be confusing "serious" with "traditional" here. There's nothing I see about, say, C (which I write in quite a bit), which makes it more serious than Forth. The main reason I use traditional compilers is for convenience. They are much more heavily supported by the OSs I work in than is Forth. This does not mean that Forth is somehow less "serious". >On the other hand, a compiled Forth with type checking might be useful. Such a "Forth" would not be Forth at all, but a crippled facsimile. We already have lots of languages with the above characteristics. Why add another? Why mutilate Forth? > One observation is that novice programmers get excited about small >scale syntactical issues, such as RPN vs infix, and more experienced >programmers get excited about large scale issues, such as modularity and >name-space management. As program size grows, these issues dominate, >for combinatorial reasons. Yes, but what is your point here? Peter M. Yadlowsky Academic Computing Center University of Virginia pmy@vivaldi.acc.Virginia.EDU
neal@druhi.ATT.COM (Neal D. McBurnett) (09/14/88)
I see strong parallels between Forth and PostScript(tm). In most respects, PostScript is much better for significant development efforts: type checking, object-orientation, readability, etc. It may be less efficient in stack usage, but I see no other basic advantage to forth. I'm amazed that there is still no product to let me develop forth-like applications in PostScript. I don't need all the graphics stuff that is in PostScript, and which makes it so large and difficult to implement. I just want a fast, interpreted environment which doesn't have the horrible block-structured forth file system and lack of type checking. I'm willing to pay - where are the vendors? Start off with the PC and Mac markets. -Neal McBurnett, att!druhi!neal
mdg@smegma.UUCP (Marc de Groot) (09/15/88)
In article <1457@ficc.uu.net> karl@ficc.uu.net (karl lehenbauer#) writes: >Neither does the Forth language nor any Forth environment to my knowledge >adequately support the development of millions of lines of code by hundreds >of programmers, which is the scale of the activities at this mail address. One of my clients has a data acquisition package for the IBM PC written in Forth. 14 megabytes of source, or approximately 100,000 lines of Forth code. The project has been running for six years. The code is VERY maintainable, due to the self-discipline of the programmers involved. The project has been worked on by about a dozen different people over six years, some who were short- term, and others who have been there the whole time. They have even developed a "programming option" for their package, which is programmed by scientifically-oriented end-users IN FORTH. They have very good market acceptance. Their product consistently out-performs similar packages coded in C. There are many environments that allow development of millions of lines of Forth code. I would submit for the consideration of the net that Forth suffers more from bad image than bad performance. -- Marc de Groot (KG6KF) UUCP: uunet!hoptoad!smegma!mdg Internet:mdg@smegma.UUCP "Quoiqu'elle soit tres solidement montee, il faut ne pas *brutaliser* la machine." -Oliver Wendell Holmes
don@brillig.umd.edu (Don Hopkins) (09/19/88)
Hey all you Forth enthusiasts (and antagonists!!!) out there: If you want a powerful flexible object oriented multitasking interactive PostScript programming environment, then get NeWS! NeWS officially stands for "Network extensible Window System", but once you see it in action, you'll realize that it really means "Neat Window System!" c(-; NeWS was written to be portable, and it currently runs on a wide variety of machine's: Silicon Graphics, Sun, Mac II (under AUX), PS/2 and other 386 boxes (under OS/2), and many other systems. I could go on and on about how great it is to have a window system with the high level, device independent PostScript imaging model, and how much fun you can have with arbitrarily shaped windows, and what a performance win it is to have an extension language built into the window system that can perform local input processing and feedback, and its profound impact on client-server network traffic, and what an interactive programming environment means for the rapid prototyping of user interfaces, but I'll leave such discussions for comp.windows.news. The issue here is PostScript, the *programming language*! (Like xerox, the verb ;-) PostScript is a cross between Forth and Lisp. Objects are typed, like in Lisp. PostScript procedures can be passed around as arguments on the stack, and manipulated like any other data type, since they're just executable arrays. (i.e. "if" takes 2 arguments: a boolean and a procedure to execute (if the boolean's true)) Arrays are polymorphic -- each element can be an object of any type. Dictionaries can be used like Lisp association lists or Forth vocabularies. To define procedures and variables, you associate names with executable arrays and other values, in dictionaries. The scope is defined by the contents of the dictionary stack, searched top to bottom. PostScript procedures can have named local variables just by pushing a new dictionary onto the dict stack, storing into it the arguments passed on the parameter stack, and other local variables, and popping the dict stack before exiting. Names in PostScript are more like atoms in Lisp than like words in Forth: they don't have value slots or parameter fields -- they are associated with values in dictionaries. To execute a name, it is looked up on the dictionary stack, and its associated value is executed. One thing that makes NeWS such a powerful environment is Owen Densmore's object oriented PostScript programming package. It provides a Smalltalk-like class mechanism, using the dictionary stack to implement inheritence. NeWS user interface objects such as menus, windows, buttons, and scroll bars are defined as classes. You can customize their look and feel by defining subclasses of these objects, saving time and reusing code by building on top of what is already there. The NeWS server is a MuLTiTaSKiNG PostScript interpreter, with an event queue, and a hierarchy of arbitrarily shaped overlapping drawing surfaces (canvases). Lightweight PostScript processes live together in the server, sharing code and data. Keyboard and mouse input generate events, which are put on the event queue and delivered to interested processes in the order that they happened. NeWS processes can communicate with each other by sharing data and sending events. NeWS provides monitors to synchronize access to shared data structures. You express interest in the types of event you want, and loop awaiting and servicing them. You can fork off processes to manage interactive objects, service events, do background processing, or whatever you like -- they're cheap! There is also a PostScript debugger that lets you enter broken processes, examine their guts, fix them up, and send them on their way. NeWS smoothly incorporates many important extensions to the PostScript language. Certain NeWS data types, such as processes, canvases, and events, behave just like dictionaries. You can even push them onto the dictionary stack. A process dictionary contains keys like /ExecutionStack, /OperandStack, /State, and /Interests, and a canvas dictionary contains keys like /Mapped, /Parent, /CanvasBelow, /Color, and /Retained. Reading and writing the values of these keys can have magical effects. For example, setting /Mapped in a canvas dictionary to true makes it appear on the screen; the /XLocation and /YLocation keys of an event are automatically transformed in terms of the current coordinate system. If you want to learn PostScript, NeWS is the way to go -- it's an exciting and gratifying programming environment! Don't waste your time trying to learn an interactive interpretive language like PostScript by spooling files to a laser printer. NeWS isn't just for Display -- it's for Interaction! You can take a look and feel for yourself, if you go to the Sun User Group Southwest Regional Conference in Albuquerque, on September 30th. I'll be demonstrating the HyperTIES hypermedia browser, and the UniPress Emacs text editor, two NeWS applications I've worked on that make extensive use of interactive PostScript. If you want to know more, send me mail or post questions to the "comp.windows.news" newsgroup (or the Internet mailing list "NeWS-makers@brillig.umd.edu"). (If you want to be added to the mailing list, please send me mail at the address "NeWS-makers-REQUEST@brillig.umd.edu".) -Don don@brillig.umd.edu ...!uunet!mimsy!don
roy@phri.UUCP (Roy Smith) (09/19/88)
don@brillig.umd.edu.UUCP (Don Hopkins) writes: > If you want to learn PostScript, NeWS is the way to go -- it's an exciting > and gratifying programming environment! Don't waste your time trying to > learn an interactive interpretive language like PostScript by spooling files > to a laser printer. NeWS isn't just for Display -- it's for Interaction! While I happen to be a true-blue fan of PostScript, and at least a mild afficiando of NeWS, I can't agree that learning NeWS is the way to learn PostScript. It's like trying to learn yacc at the same time you are learning C, or trying to appreciate Shakespere at the same time you are learning how to read. NeWS in a complex system and you can't hope to understand what is going on unless you already know the fundementals of how PostScript works. -- Roy Smith, System Administrator Public Health Research Institute {allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net "The connector is the network"
koopman@a.gp.cs.cmu.edu (Philip Koopman) (09/19/88)
In article <504@smegma.UUCP>, mdg@smegma.UUCP (Marc de Groot) writes: ......... > One of my clients has a data acquisition package for the IBM PC written in > Forth. 14 megabytes of source, or approximately 100,000 lines of Forth code. > The project has been running for six years. The code is VERY maintainable, > due to the self-discipline of the programmers involved. The project has been > worked on by about a dozen different people over six years, some who were short- > term, and others who have been there the whole time. >......... The way to get the word out is to publish. I would urge Marc and any others who have done large software projects to publish something about them. A good place to publish would be in the ACM or IEEE journals if you can. It's a lot of work, but Forth has almost zero respectability in the academic arena now. If you don't think you can publish in one of the heavy journals, try IEEE Micro, they're more willing to take chances and they are usually looking for material. You can also try the EE professional magazines. These are targetted at EE managers, and those are the people we need to reach to get Forth used on more projects. Publishing in JFAR is all well and good (and you ought to do it, since they can use the support), but it doesn't get the message out to the "unwashed masses", and *that's* the group we need to inform. Phil Koopman koopman@maxwell.ece.cmu.edu Arpanet 5551 Beacon St. Pittsburgh, PA 15217 PhD student at CMU and sometime consultant to Harris Semiconductor.
mh@wlbr.EATON.COM (Mike Hoegeman) (09/20/88)
In article <3492@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: >don@brillig.umd.edu.UUCP (Don Hopkins) writes: >> If you want to learn PostScript, NeWS is the way to go -- it's an exciting >> and gratifying programming environment! Don't waste your time trying to >> learn an interactive interpretive language like PostScript by >> - spooling files >> to a laser printer. NeWS isn't just for Display -- it's for Interaction! > > While I happen to be a true-blue fan of PostScript, and at least a >mild afficiando of NeWS, I can't agree that learning NeWS is the way to learn >PostScript. It's like trying to learn yacc at the same time you are learning >C, >or trying to appreciate Shakespere at the same time you are learning how to >read. NeWS in a complex system and you can't hope to understand what is going >on unless you already know the fundementals of how PostScript works. I think your analogies are pretty weak. You make it seem like there is tons and tons of NeWS stuff you have to learn before ever getting your hands on PostScript and that simply is not true. No one says you HAVE to start out using the NeWS extensions to postscript. You can just fire up a psh (PostScript Shell) which gives you an environment pretty similar to that of a plain 'ol printer and start typing away!! Here's all you have to do. newshost % psh newshost % executive Welcome to NeWS 1.1 erasepage 10 10 moveto (Hello world!) show : ...etc... : And, As Don was trying pointing out IT's INTERACTIVE !! Using a printer to do PostScript development on is downright primitive in comparison. How would you prefer to program in C? By submitting batch jobs via ftp to some remote machine where it get's compiled and then it mails you back the errors from the compiler? This is pretty much what you have to put up with if you are programming in PosctrScript via a printer. You don't really have to get into using processes, classes, etc.. at first if you don't want to but you get the bonus of an interactive environment and the debugger which is worth the price of NeWS alone if need to do alot of postscript debugging. -mike
karl@sugar.uu.net (Karl Lehenbauer) (09/20/88)
In article <1457@ficc.uu.net> I wrote: >Neither does the Forth language nor any Forth environment to my knowledge >adequately support the development of millions of lines of code by hundreds ^^^^^^^^ ^^^^^^^^ >of programmers, which is the scale of the activities at this mail address. In response to which mdg@smegma.UUCP (Marc de Groot), in article <504@smegma.UUCP>, wrote: > One of my clients has a data acquisition package for the IBM PC written in > Forth. 14 megabytes of source, or approximately 100,000 lines of Forth code. ^^^^^^^ > The project has been running for six years. The code is VERY maintainable, > due to the self-discipline of the programmers involved. The project has been > worked on by about a dozen different people over six years, some who were ^^^^^ > short-term, and others who have been there the whole time. Big difference in scale here, over a magnitude both in lines and number of programmers. > There are many environments that allow development of millions of lines > of Forth code. I would submit for the consideration of the net that Forth > suffers more from bad image than bad performance. What Forth environment even supports the *concurrent* editing of a few hundred thousand lines of code by a dozen programmers, let alone millions by hundreds? Do you have a Forth source code control system that's up to the task? Can't I still crash multiuser development in most Forth environments by doing a ": DIE BEGIN AGAIN ; DIE"? email support? networking? We need a real realtime operating system, too, not a polled task switcher. Of course it has to run protected mode multiuser multitasking. We insist on not having errant tasks clobbering each other when inexpensive hardware (even the '286) can prevent it. It must be able to swap and run a hundred tasks concurrently. Although there may be one, there is certainly no well known, moderately standard, successful implementation. I doubt most companies would let one write all that stuff from scratch if something else could be found that would do most of it. More reasons, I guess, why Forth hasn't received wider acceptance. -- -- uunet!sugar!karl, Unix BBS (713) 438-5018
jax@well.UUCP (Jack J. Woehr) (09/21/88)
In article <2654@sugar.uu.net> karl@sugar.uu.net (Karl Lehenbauer) writes: >In article <1457@ficc.uu.net> I wrote: >>Neither does the Forth language nor any Forth environment to my knowledge >>adequately support the development of millions of lines of code by hundreds > ^^^^^^^^ ^^^^^^^^ >>of programmers, which is the scale of the activities at this mail address. > > >What Forth environment even supports the *concurrent* editing of a few hundred >thousand lines of code by a dozen programmers, let alone millions by hundreds? The name of the Forth environment you are looking for is "Unix". Email Mitch Bradley of Sun Microsystems for his quite sofistycated C Forth, wmb@sun.com. *********** jax@well jax@chariot : FOO ( ---) ." Ask a tougher one!" ; JAX on GEnie
barnett@grymoire.steinmetz.ge.com (Bruce G. Barnett) (09/21/88)
In article <23378@wlbr.EATON.COM>, mh@wlbr (Mike Hoegeman) writes: > You can just fire up a psh (PostScript Shell) A much easier way is to use the postscript.el mode that comes with the GNU-emacs/NeWS package on columbia.edu. Then edit your postscript file, type C-c C-c, and the postscript is displayed on the screen. Change one line, whatever, type C-c C-c again, and you see the differences. You may have to write something that draws a blank box as the image is temporary, and a new image overwrites the old one. (without clearing). But this is a very easy way to learn what postscript is doing, and requires NO knowledge of NeWS other than starting, installation, etc. You can learn NeWS by adding extensions later. -- -- Bruce G. Barnett <barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP> uunet!steinmetz!barnett
childers@unet.pacbell.COM (Richard Childers) (09/23/88)
In article <13613@mimsy.UUCP> don@brillig.umd.edu.UUCP (Don Hopkins) writes: >Hey all you Forth enthusiasts (and antagonists!!!) out there: Postscript is, *at best*, a highly specialized subset of Forth ... >You can take a look and feel for yourself, if you go to the Sun User >Group Southwest Regional Conference in Albuquerque, on September 30th. Ah, I knew there was *something* commercial involved. >I'll be demonstrating the HyperTIES hypermedia browser, and the >UniPress Emacs text editor, two NeWS applications I've worked on that >make extensive use of interactive PostScript. And selling them, no doubt. Please don't use the Usenet for advertising, covertly or overtly. -- "The leech's kiss, the squid's embrace, ..!{amdahl,ames,oliveb,pacbell}! The prurient ape's defiling touch: childers@chaos.unet.pacbell.COM And do you like the human race ? No, not much." -- Aldous Huxley, 'Ape And Essence'
ron@topaz.rutgers.edu (Ron Natalie) (09/24/88)
Lighten up, chum. HyperTies and pie-menus are Don's research projects at the University of Maryland. Don has done more than anyone outside of Sun (perhaps even inside of Sun as well) to further the interactive postscript environment as provided by NeWS. Don's stuff is of such a high quality that Sun goes out of their way to make sure that there is a workstation at his disposal to demonstrate whatever he's cooked up this time.
ns@cat.cmu.edu (Nicholas Spies) (09/25/88)
Could someone explain the relation between NeWS and Display PostScript? Also, does anyone know _why_ PostScript and Forth are similar? Is it just a consequence of both being stack-based, or was PostScript developed from Forth? Or from L* (L-star)? (L* was developed at CMU some years ago and also used datatyping of stack items; sorry I don't name of its author offhand...) I've always wondered what might constitute the smallest set of language primitives that would allow the construction of an arbitrary number of program constructs of arbitrary complexity (that is, "any program"). Forth, as defined in F-83, has about 130 language primitives (of which, usually, only a third or so are Forth "primitives" defined in machine code, depending on the taste of the implementor). In contrast, POP-11 (mentioned by Dick Pountain in Byte a while ago) is based on a vitual machine that has only 17 instructions (it is also stack-based). POP-11 combines aspects of Forth, LISP, Prolog and even Pascal: it compiles to VM instructions and in interpreted (sort of like Forth); makes extensive used of lists; has built-in sophisticated pattern-matching and database support, but looks fairly much like a structured procedural language. You also have access to compiler, as in Forth... As a further digression, factorial of n can be calculated in POP-11 with: define fact(n); if n == 1 then 1 else n * fact(n-1) endif; enddefine; Although Forth is fun to work with, its primitives seem rather arbitrary, with (useful) oddities such as -TRAILING, >BODY and TIB having the same official status as DUP and SWAP. Perhaps Forth standardization (which I feel is sine qua non for its general acceptance) would benefit from factoring and defining genuine, irreducable primitives on the one hand, and then the environment/I-O aspects of the language in terms of these primitives, of course leaving actual details of implementation to implementors. Distilling Forth down to a smaller set of kernal primitives might make it more consistant and, paradoxically, closer to the minimalist philosophy espoused by Chuck Moore than Forth as it now exists... Alpha-POP for the Mac is available from: Cognitive Appliations Ltd Computable Functions, Inc. 4 Sillwood Terrace 35 South Orchard Drive Brighton Amherst, MA 01002 BN1 2LR 413-253-7637 England My only connection with Alpha-POP or its authors is as a satisfied customer. -- Nicholas Spies ns@cat.cmu.edu.arpa Center for Design of Educational Computing Carnegie Mellon University