cik@l.cc.purdue.edu (Herman Rubin) (04/20/88)
In article <Apr.18.19.01.07.1988.13299@porthos.rutgers.edu>, gaynor@porthos.rutgers.edu (Silver) writes: > firth@sei.cmu.edu (Robert Firth) writes: > > It seems clearly desirable that every control construct be able to > > contain multiple statements, embedded within clear starting and > > ending delimiters. > > I find these delimiters an annoying eyesore at best. I usually write > algorithms without them, using indentation show heirarchy. I only > include them in fulfillment of a target language's definition. In > fact, there are languages whose heirarchical structure is determined > solely by indentation (the only one that comes to mind is > josh@rutgers.edu's CAML, still under development). > > Regards, > [Ag] I find both of these methods at times easy to follow, and at times hard to follow. There is also the problem of a multiple break. If we use indentation, there is the problem of following the indentation 20 or 50 or 100 lines; in addition, this greatly limits the number of hierarchical levels. Admittedly 10 levels are already difficult to read, but with indentation lines also get shorter. One may also want to use some form of indentation within blocks to inprove readability. The problem with if...fi, case...esac, do...od etc. is that there may be several pending; which is now ended? I hereby make a proposal which I believe may treat the problem in a better manner. First, I am willing to have unlabelled blocks with appropriate delimiters such as the above pairs and also with {...}. (It is my under- standing that if the latter is used that the reversed name does not have to be used also.) I suggest that labelled blocks also be allowed, with possible notations as LABEL{ ... }LABEL if(....) LABEL:: end LABEL; Also if a break is desired which goes back several levels, this could be indicated as break LABEL and another useful "gadget" might be endall LABEL which would close all blocks since LABEL was invoked. This is a suggestion for the introduction of labelled blocks. In no way do I claim that this is necessarily the best way to do it, nor do I believe that I have found all of the uses for labelled blocks. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (ARPA or UUCP) or hrubin@purccvm.bitnet
jefu@pawl14.pawl.rpi.edu (Jeffrey Putnam) (04/20/88)
All this discussion about which delimiters we should be using seems to me rather off the mark. (I personally see nothing wrong with either the C block "{...}" or the Algol 68 "if ... fi" etc.) I think that what is really needed is better editors and appropriate software to handle transformations. That is, if I write with "{...}" in a syntax smart editor, there is no reason why it could not be transformed to "begin...end" or any other pair demanded by the formal language description. Indeed, two people working on the same program might see it in quite different ways. In a nice bitmap oriented editor, blocks might be indicated by drawing lines around the block, drawing a vertical line in front of it, or even by changing color or font (:-). I think we are forgetting - or not yet realizing - that the kinds of things demanded by a language definition is not necessarily what is presented to the programmer. Time and space do not permit me to describe what i would like to see in my fantasy editor, but suffice it to say that i dont think delimiters would ever appear (unless requested). jeff putnam jefu@pawl.rpi.edu -or- jeff_putnam%rpitsmts@itsgw.rpi.edu "People would rather believe a simple lie than the complex truth."
jesup@pawl13.pawl.rpi.edu (Randell E. Jesup) (04/21/88)
In article <732@imagine.PAWL.RPI.EDU> jefu@pawl14.pawl.rpi.edu (Jeffrey Putnam) writes: >In a nice bitmap oriented editor, blocks might be indicated by >drawing lines around the block, drawing a vertical line in front of it, >or even by changing color or font (:-). Don't joke: the first version of C I used (for the C-64, no less!) had an editor that allowed giving any of 15 colors to any line (against a black background). It really makes the structure of a routine jump out at you. // Randell Jesup Lunge Software Development // Dedicated Amiga Programmer 13 Frear Ave, Troy, NY 12180 \\// beowulf!lunge!jesup@steinmetz.UUCP (518) 272-2942 \/ (uunet!steinmetz!beowulf!lunge!jesup) BIX: rjesup (-: The Few, The Proud, The Architects of the RPM40 40MIPS CMOS Micro :-)
bhs@mitre-bedford.ARPA (Beverly H. Sobelman) (04/21/88)
In article <732@imagine.PAWL.RPI.EDU> jefu@pawl14.pawl.rpi.edu (Jeffrey Putnam) writes: >In a nice bitmap oriented editor, blocks might be indicated by >drawing lines around the block, drawing a vertical line in front of it, >or even by changing color or font (:-). I think we are forgetting >- or not yet realizing - that the kinds of things demanded by a language >definition is not necessarily what is presented to the programmer. If memory serves correctly, the Builder language developed at Cortex (Waltham, MA) has an associated editing capability that indicates a block via vertical lines down the left side of the display; e.g., when you start an "if" construct, you automatically get the "end" construct (don't remember the exact syntax), with a thin line at the left running between the two, and all code for the body is inserted into that region at appropriate levels of indentation. Makes for a visually appealing and informative display. >Time and space do not permit me to describe what i would like to see >in my fantasy editor, but suffice it to say that i dont think delimiters >would ever appear (unless requested). > As I said above, I think Builder requires delimiters, but the editor ensures proper closure of all blocks. Bev Sobelman MITRE Corp. bhs@mitre-bedford.arpa (617) 271-754
daveb@geac.UUCP (David Collier-Brown) (04/23/88)
In article <757@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: >I find both of these methods at times easy to follow, and at times hard to >follow. There is also the problem of a multiple break. >[...] > break LABEL > endall LABEL Well, both have been tried, with mixed results. One could label begin-end blocks in PL/1, and add either the block label of the name of the control structure between the "end" and its ";". At least two compilers used this to double-check block nesting and produce warning messages. Similarly, some PL/1 variants (and my memory is fuzzy here...) allowed a leave <label> statement which exited a named block. This may have been part of the ANSI standard, but that was too long ago. Labelled blocks and "endall" existed in BCPL, but were very little-used. It was not obvious whether it was because it was non-traditional or buggy, but is usually remembered in terms of the claim that it lead to making block-balancing errors. -- David Collier-Brown. {mnetor yunexus utgpu}!geac!daveb Geac Computers International Inc., | Computer Science loses its 350 Steelcase Road,Markham, Ontario, | memory (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.
henry@utzoo.uucp (Henry Spencer) (04/24/88)
> ... If we use indentation, > there is the problem of following the indentation 20 or 50 or 100 lines; in > addition, this greatly limits the number of hierarchical levels... At risk of starting another flame war, if this is a problem, the function in question is too complex and should be split up into more manageable pieces. If efficiency demands avoiding function calls, the integration of the pieces into a single function should be done mechanically, either by the compiler or by a special-purpose source-transformation tool, so the programmer can continue to deal with the cleanly-partitioned version. -- "Noalias must go. This is | Henry Spencer @ U of Toronto Zoology non-negotiable." --DMR | {ihnp4,decvax,uunet!mnetor}!utzoo!henry
ken@aiva.ed.ac.uk (Ken Johnson) (04/25/88)
jefu@pawl14.pawl.rpi.edu (Jeffrey Putnam) writes: >In a nice bitmap oriented editor, blocks might be indicated by >drawing lines around the block,... The MIT Media Lab developed a language called `Boxer' which does precisely this. The basic unit is the proceudre, analogous with a Lisp function. The procedure is represented by a box. To loop, etc, you enclose the box inside the box that represents the procedure you are writing. The editor does not have to be bitmap-orienbted, though it probably is. You do not need any function that is not available through Termcap. -- ------------------------------------------------------------------------------ From Ken Johnson, AI Applications Institute, The University, EDINBURGH Phone 031-225 4464 ext 212 Email k.johnson@ed.ac.uk