barnett@grymoire.crd.ge.com (Bruce Barnett) (04/24/91)
In article <4_XAYQ1@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: > >And perhaps > > the language is too awkward; postfix if's are hard to read. > How much actual programming in Postscript would you expect the typical > application programmer to do? I think that depends on the toolkit and development environment. Using tNt 2.0 and DevGuide, you can develop an application interactively, and then link in the toolkit without writing any PostScript at all, I believe. If you want to modify one of the widgets, you have to get into PostScript programming, but it's Object Oriented, so that helps. I agree about the language. The problem is parsing code like foo bar blatz mumble tilderoll You have to know each operator and how many items it pops/pushes off the stack. I really wish there was some way to add parentheses, even if there were syntatic sugar. Too bad all of the bracket characters are defined. I wanted to define a set of brackets to use just to help me balance the operators... -- Bruce G. Barnett barnett@crdgw1.ge.com uunet!crdgw1!barnett
barnett@grymoire.crd.ge.com (Bruce Barnett) (04/25/91)
In article <.VYA9Y1@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: > You young kids today. You're spoiled by all this memory! Watch it! I cut my programming teeth on a Intel 4004 microprocessor! >Use whitespace and comments! I know how to use whitespace and comments. But does everyone else? Sometimes white spaces are detrimental. Having the entire routine on a single page is better than putting each command on it's own line and making the code three times longer. There are advantages to the lisp syntax. At least you can parse the code without knowing each command and without REQUIRING comments to document the operand stack. Forth/PostScript has some nice points as an interactive language. I wonder if some special characters can be added to the NeWS/PostScript language using a different font that allows a programmer to insert special brackets that have no function but do allow vi/emacs and the programmers to balance the stack parameters. -- Bruce G. Barnett barnett@crdgw1.ge.com uunet!crdgw1!barnett
barnett@grymoire.crd.ge.com (Bruce Barnett) (04/26/91)
In article <12231@exodus.Eng.Sun.COM> rberlin@birdlandEng.Sun.COM (Rich Berlin) writes: > You could always define a couple of postscript "commands" which do > nothing, e.g. > > /|- {} def > /-| {} def > > and then mark things like this: > > |- 100 50 8 [1 0 0 -1 0 900] {<00>} false 3 -| colorimage Yeah - that's what I was thinking of. But would everyone use it? There would need to be a large number of tools to make this popular. Like - positioning the mouse on the first bracket and hitting a command key that executes the commands within the bracket. (Like lisp). And having double/triple clicks expand fill the brackets. Then drag, copy and drop the code from one routine into another, call up a parser to check for the proper number of parameters. (e.g. selected text takes two parameters as input and generates 3 items on the stack.) You would also need some code to read a PostScript/NeWS program and generate the proper nesting of brackets. Now there's an interesting idea! This would tell you which commands consumed data, and which ones generated data. It would indicate nesting depth, and might go a long way to making NeWS easier to use. Let's extend the syntax a little. Maybe |- is a bracket indicating there is the same number of operates on the stack as the matching -|. If you have a procedure that takes three parameters, and consumes them all, use a different character. Perhaps |+++ to go with -|? > You mentioned in an earlier message that you'd prefer prefix notation, I wouldn't say it's the prefix part that is important. It's the clear indication of data flow that I like so much, and vanilla PostScript lacks. If NeWS was extended to have this sort of "syntactic sugar" without penalty, and the tools were added to make this usage desirable, it might be easier for people to pick up a random piece of code and follow it without memorizing AHEAD OF TIME the input/output of every procedure/command used. -- Bruce G. Barnett barnett@crdgw1.ge.com uunet!crdgw1!barnett
gaynor@yoko.rutgers.edu (Silver) (04/28/91)
[What follows is a little jumbled because I'm in something of a rush. Also, I had to nuke the References: line, my modem ate it and I didn't feel like regenerating it. Since this discussion does not pertain to unix internals or NeWS per se, I've directed followups to comp.lang.misc.] > Sometimes white spaces are detrimental. Hear, hear!, or Here, here!, or something! White space can be cheap, but it's rarely free. Horizontal whitespace is typically cheaper than vertical whitespace because almost all fonts are taller than they are wide. That is, there are more units of space available across the page than down. The use of whitespace must be weighed against the amount of code visible at one time, because scrolling around is as much a detriment to readability as too much or too little whitespace. Code is only written once. After that, it's a matter of staring it down to find out what/how to modify it. So, after the initial heavy editing, give it a beautifying pass. Eliminate a lot of unnecessary whitespace. Comments kind of fall in the same category. Never comment in-line that which is obvious or self-documenting. It's a fairly common practice to put atomic operations on seperate lines without even considering the operations surrounding it. I think it's better to put an single _semantic_ operation on a single line if it's reasonably short. I could spout more blather here, but I'll hold off for now. Here's a few things I usually do: 1. Within expressions, I like to use whitespace to indicate operator precedence. For example, I'll write "1 + 2*3" instead of "1 + 2 * 3", or "1 2 3 * +" instead of "1 2 3 * +". 2. Rarely will I devote an entire line to a mere grouping operator. For instance, I'll take the left over the right any day. /foo /foo {add} { define add } define 3. An example of putting a semantic operation on a single line: ... /* `cat' F to stdout */ { int c; while ((c = getc(F)) != EOF) putchar(c); } ... as opposed to ... /* `cat' F to stdout */ {int c; while ((c = getc(F)) != EOF) putchar(c);} ... I concede that less-compressed versions of the second form are easier to read. But this is such a trivial operation that the lack of whitespace does not impair its readability enough to justify adding more. Flamers: Try playing the devil's advocate before you send your followups. Regards, [Ag] gaynor@paul.rutgers.edu