gaynor@topaz.RUTGERS.EDU (Silver) (07/05/86)
[SysAdms - for a real laugh, temporarily replace the normal]
[contents of curses.h with strings resembling "$@%^&#!#!!!"]
In many languages, the body of a program or subprogram consists of a
compound statement. This seems like an arbitrary restriction, and is
quite annoying at times. Often the action of a program or subprogam
is expressable as a single statement, and I would never otherwise
enclose a single statement within a compound statement.
For example, consider the following piece of pseudo code (feel free to
flame my pseudo, as long as it's followed with ' > /dev/null')
(fellow posters - when giving examples via code, try to produce
something non-trivial; it makes reading the article more interesting):
equal-trees (tree t1, t2) returns boolean
if t1 = null
then
equal-trees <- (t1 = t2)
else
if t2 = null
then
equal-trees <- false
else
equal-trees <- (t1 (data) = t2 (data))
and
equal-trees (t1 (left), t2 (left))
and
equal-trees (t1 (right), t2 (right))
endif
endif
Now why should a compiler want to force someone to embed such pretty
code :-) within a pair of curly braces, or a begin-end pair, or what-
have-you? Certainly it's no big deal to recognize the statement, as
compilers are so often forced to recognize statements that they've
become quite good at it. If the code were any longer, one could argue
that it's done to increase readability by imposing delimeters. That's
not the case here (albeit ~borderline). Regardless, a comment or two
would suffice anyway. If the code were any longer, one could argue
that it's done as a built-in error check. But, the recent trends in
programming place emphasis on modular code; hence, people are writing
more, smaller procedures.
And to top it all off, many of the same languages that impose this
restriction allow as clauses of structured statements a single
statement of any type, which contradicts any justification for
requiring the body of a program or subprogram to be a compound
statement! What I mean is, if it's required that the bodies of
programs and subprograms be a compound statement, it would only be
natural that the same hold true for "if"'s "then" and "else" clauses,
and loop bodies, and "case"/"switch"'s clauses, and... AND!...
ARGHH!
Whew! It's over. I don't know what came over me, it all just seemed
to come in a single rush of uninhibited frustration!
_ /|
\`o_O'
( ) Aachk! Phft!
U
Disclaimer: The opinions and/or information and/or code expressed
here were generated by this characature, stolen from
Dave Rasmussen, to which I have taken the liberty of
adding ears. So don't look to me for a disclaimer!
Silver {...!topaz!gaynor}ark@alice.UucP (Andrew Koenig) (07/05/86)
> In many languages, the body of a program or subprogram consists of a > compound statement. This seems like an arbitrary restriction, and is > quite annoying at times. Often the action of a program or subprogam > is expressable as a single statement, and I would never otherwise > enclose a single statement within a compound statement. What languages? The only one that comes to mind is C. I suspect that it makes parsing much easier in C.
gaynor@topaz.RUTGERS.EDU (Silver) (07/06/86)
[oh give me a home, where the line-eaters rome, and the...] ark@alice.UucP (Andrew Koenig) writes... > [...!topaz!gaynor writes] > > > In many languages, the body of a program or subprogram consists of a > > compound statement. This seems like an arbitrary restriction, and is > > quite annoying at times. Often the action of a program or subprogam > > is expressable as a single statement, and I would never otherwise > > enclose a single statement within a compound statement. > > What languages? > > The only one that comes to mind is C. I suspect that it makes parsing > much easier in C. Oh, a couple of languages come to mind. Particularly Algol (?) and its descendants, C, Pascal, and Ada (to name a few biggies). There are plenty of others. 10 pts to the one who can name the most. !!Simpler parsing methods is *NO*EXCUSE* for compromising a language!! May you someday be forced to program in microcode (knock on wood :-). I'm sure many compiler schemes would surely handle the removal of this restriction no problem. Especially those that are generated by a compiler generator. I myself modified my Compilers-1 project (a simple recursive-descent compiler for a subset of Pascal) to do (sub)program bodies this way in about four minutes. One good thing about this modification is that all existing code still works. _ /| \`o_O' ( ) Aachk! Phft! U Disclaimer: The opinions and/or information and/or code expressed here were generated by this characature (stolen from Dave Rasmussen, to which I have taken the liberty of adding ears). So don't look to me for a disclaimer! Silver {...!topaz!gaynor}
djfiander@watnot.UUCP (David J. Fiander) (07/06/86)
>> In many languages, the body of a program or subprogram consists of a >> compound statement. This seems like an arbitrary restriction, and is >> quite annoying at times. Often the action of a program or subprogam >> is expressable as a single statement, and I would never otherwise >> enclose a single statement within a compound statement. > >The only one that comes to mind is C. I suspect that it makes parsing >much easier in C. Don't forget : Pascal (even if you want to), Modula-2 (same thing really), Ada (tm), and COBOL (I think, it's been a while). It's very common. In fact a friend of mine here at the university was also wondering why that restriction exists, although he was mainly concerned with C at the time. -- ---------- "The opinions expressed here are mine and almost definitely no-one elses" UUCP : {allegra,ihnp4,decvax,utzoo,clyde}!watmath!watnot!djfiander CSNET : djfiander%watnot@waterloo.CSNET ARPA : djfiander%watnot%waterloo.csnet@csnet-relay.ARPA BITNET: djfiande@watdcs
render@uiucdcsb.CS.UIUC.EDU (07/07/86)
I like the use of compound statements for the bodies of subprograms,
as they better separate the declarative section from the executable
section of the code. I wouldn't find it unbelievable, though, that
the guiding reason for the convention is that it is a carryover from the
earliest days of language design when you needed something to visually
separate one logical section of code from another. Ada was supposedly
designed with the hope that the syntactic structure of the code would
mirror the logical structure of the program it implemented, under the
assumption that this would make the code more understandable.
As a sidebar to this, let me mention a related issue:
A guy I knew to be designing a language, when asked about a particular
construct he was using, told me that the syntax didn't matter because it
was "ephemeral." In response, I argued that the syntax was very important
for a few reasons.
(1) Syntax is the medium through which we communicate our program to the
system and to other users.
(2) A syntax which more directly expresses the algorithm used in a program
makes it easier to read, understand and debug that program.
(3) People who look at a particular language construct will automatically
form some idea of its function, regardless of whether or not they are
familiar with the language. The designer must therefore take great
pains to ensure that any construct used does not differ too wildly
with the users' preconceptions of the function of such a construct.
I could go on, but I am interested in other peoples opinions. So, a few
questions for open discussion:
+ What factors should go into the design of a language's syntax?
Readability? Parsability? Theoretical aesthetics?
+ Should the syntax be as brief as possible (APL, FP), or is some verbosity
good (Pascal, Ada)?
+ How much can be expected of the average programmer when learning and trying
to assimilate a new language for regular usage? In other words, is it
reasonable to design a language which uses very unfamiliar constructs and
notation, and, if so, what should the guidelines be when deciding this?
Hal Render
University of Illinois at Urbana-Champaign
render@b.cs.uiuc.edu (ARPA)
render@uiuc.csnet (CSNET)
{pur-ee, ihnp4}!uiucdcs!render (USENET)sommar@enea.UUCP (Erland Sommarskog) (07/07/86)
In article <5287@topaz.RUTGERS.EDU> gaynor@topaz.UUCP writes: > >Oh, a couple of languages come to mind. Particularly Algol (?) and >its descendants, C, Pascal, and Ada (to name a few biggies). There >are plenty of others. 10 pts to the one who can name the most. > I would guess Algol doen NOT force you to use BEGIN-END. Simula does definitely not do it, and as far I know Algol is a true subset of Simula. I think the reason why many languages forces you to use BEGIN-END even for a one-statement body is the sake of readability. (But don't ask me why a {} increases the readability in C, I don't know that language luckilly.) In your original article you wrote you as an inconsistence with IF-, WHILE- and other compund statements. Let me draw your attention, that e.g. Ada does not have this inconsistence in a way, since you write WHILE <logical-expression> DO <statement(s)> END WHILE; (With my excuses for potenial errors, Ada is not my every-day language.) OK, in a procedure you do need a BEGIN also, but I would guess is due to the declarations.
mangoe@umcp-cs.UUCP (Charley Wingate) (07/08/86)
Funny thing: this 'feature' dates back to Fortran II. It also appears in Simpl-t. (Simpl-t also got rid of the semicolons.) In languages like Pascal, where there may be functions within functions, it is necessary to have some sort of "end-of-procedure" delimiter. C. Wingate
cmt@myrias.UUCP (07/08/86)
> > In many languages, the body of a program or subprogram consists of a > > compound statement. This ... is quite annoying at times. > > What languages? > The only one that comes to mind is C. I suspect that it makes parsing > much easier in C. Algol 68 also has this annoying property (but only for procedures, nowhere else). It makes parsing *possible*, not just easier. -- Chris Thomson, Myrias Research Corporation ihnp4!alberta!myrias!cmt 200 10328 81 Ave, Edmonton Alberta, Canada 403 432 1616
bright@dataio.UUCP (Walter Bright) (07/08/86)
In article <5287@topaz.RUTGERS.EDU> gaynor@topaz.RUTGERS.EDU (Silver) writes: >!!Simpler parsing methods is *NO*EXCUSE* for compromising a language!! >May you someday be forced to program in microcode (knock on wood :-). >I'm sure many compiler schemes would surely handle the removal of this >restriction no problem. Especially those that are generated by a >compiler generator. Ah, but hard-to-understand languages are also hard-to-parse. There is a direct correlation. I have designed a computer language (ABEL), and wrote the parser for it at the same time. Whenever I ran into trouble with the parser, I changed the language. The result is a simple to parse language, however, I did not sacrifice any features. The C language is difficult to parse (like the declarations), and just those constructs which are difficult to parse are also difficult to understand. C could be made much easier to parse without sacrificing any of its features (but of course it wouldn't be C anymore...).
gaynor@topaz.RUTGERS.EDU (Silver) (07/09/86)
[] In article <2296@umcp-cs.UUCP>, mangoe@umcp-cs.UUCP (Charley Wingate) writes: [clarification, not really there] > Silver {...!topaz!gaynor} writes: > > > [flamage about languages requiring the body of (sub-)programs be > > restricted to compound statements] [clarifaction, not really there] > > In languages like Pascal, where there may be functions within > functions, it is necessary to have some sort of "end-of-procedure" > delimiter. Not true. What gives rise to ambiguity is the null statement. Consider a language that allows null statements, and an arbitrary statement as a (sub-)program body. In the following, example, to which procedure would the 'writestring' be bound? == example.pseudo == # I consider the 'program' keyword to be unnecessary. # procedure example (output - text) procedure this procedure that # the code in question # writestring (output, "What procedure calls this statement?") ==================== Recall how Pascal resolves 'else' clause ambiguities. Simply bind it to the nearest unclosed 'if-then' (not 'if-then-else') statement. That convention is applicable here. If the definition of the language stated that a statement is bound to the nearest unclosed procedure, then no ambiguity results. The 'writestring' statement is bound to 'that', a null-statement to 'this' and 'test'. If you need to verify this to yourself (I did, of course, because I'm posting :-), write some sample test code and mentally parse it... _ /| \`o_O' ( ) Aachk! Phft! U Disclaimer: The opinions and/or information and/or code expressed here were generated by this characature, stolen from Dave Rasmussen, to which I have taken the liberty of adding ears. So don't look to me for a disclaimer! Silver {...!topaz!gaynor}
bobc@tikal.UUCP (Bob Campbell) (07/09/86)
In article <11865@watnot.UUCP> djfiander@watnot.UUCP (David J. Fiander) writes: >Don't forget : Pascal (even if you want to), Modula-2 (same thing really), ^^^^^^^^ No way, Modula-2 does not have "compound statements" all control structures end with a "END" as in IF ... THEN ... END IF ... THEN ... ELSE ... END IF ... THEN ... ELSIF ... THEN ... ELSE ... END WHILE ... DO ... END etc etc etc. The only place a BEGIN is required (or even allowed) is at the begining of a function or module initialization code block. Bob Campbell Teltone Corporation 18520 - 66th AVE NE P.O. Box 657 Seattle, WA 98155 Kirkland, WA 98033 {amc,dataio,fluke,hplsla,sunup,uw-beaver}!tikal!bobc
mangoe@umcp-cs.UUCP (Charley Wingate) (07/10/86)
Silver writes: >> In languages like Pascal, where there may be functions within >> functions, it is necessary to have some sort of "end-of-procedure" >> delimiter. >Not true. >What gives rise to ambiguity is the null statement. Consider a >language that allows null statements, and an arbitrary statement as a >(sub-)program body. In the following, example, to which procedure >would the 'writestring' be bound? ># I consider the 'program' keyword to be unnecessary. # >procedure example (output - text) > > procedure this > > procedure that > ># the code in question # >writestring (output, "What procedure calls this statement?") >==================== >Recall how Pascal resolves 'else' clause ambiguities. Simply bind it >to the nearest unclosed 'if-then' (not 'if-then-else') statement. >That convention is applicable here. If the definition of the language >stated that a statement is bound to the nearest unclosed procedure, >then no ambiguity results. The 'writestring' statement is bound to >'that', a null-statement to 'this' and 'test'. Well, ACCCKK PTHT. What if you have TWO statements? Which belongs to whom? Program X(output); Procedure Y; { Begin } Writeln("A"); { End; } { Begin } Writeln ("b"); Y; { End. } Now, with all the begin-end constructs eliminated, how do you tell which statements belong to which procedure? (Obviously, the "begins" are all superfluous. The "ends" aren't, though.) C. Wingate
wsmith@uiucdcsb.UUCP (07/11/86)
Another argument for forcing the brackets on a function: (derived from experience in programming in pascal...) You have your fancy, one statement function/procedure. it's three screenfuls and you just found out that the fancy 1 statement function now is a two statement function. Blech! Now you have to find the beginning of the procedure, the end of the procedure and add a begin/end pair at the ends. The related problem that exists currently is in pascal: Semicolons.... You have your one statement part of the `then' and then the obligatory semicolon since there is a following statement. Now the fancy if then ; becomes if then ; else ; (oops... where's that semicolon belong?) The general principle being violated here is that local changes to the program ought (at least in my book) only have local changes to the text of the code. needing to add the begin/end or play with semicolons are non- local and thus are annoying and a source of errors. Bill Smith ihnp4!uiucdcs!wsmith wsmith@b.cs.uiuc.edu
gaynor@topaz.RUTGERS.EDU (Silver) (07/11/86)
[ If there is a line-eater, give me a sign!! ] [ See, I told you there was no li In article <2322@umcp-cs.UUCP], mangoe@umcp-cs.UUCP (Charley Wingate) writes: ] Silver writes: ] [....] ] ] What gives rise to ambiguity is the null statement. Consider a ] ] language that allows null statements, and an arbitrary statement as a ] ] (sub-)program body. In the following, example, to which procedure ] ] would the 'writestring' be bound? ] ] ] ===== example ===== ] ] # I consider the 'program' keyword to be unnecessary. # ] ] procedure example (output - text) ] ] ] ] procedure this ] ] ] ] procedure that ] ] ] ] # the code in question # ] ] writestring (output, "What procedure calls this statement?") ] ] =================== ] ] ] Recall how Pascal resolves 'else' clause ambiguities. Simply bind it ] ] to the nearest unclosed 'if-then' (not 'if-then-else') statement. ] ] That convention is applicable here. If the definition of the language ] ] stated that a statement is bound to the nearest unclosed procedure, ] ] then no ambiguity results. The 'writestring' statement is bound to ] ] 'that', a null-statement to 'this' and 'test'. ] ] Well, ACCCKK PTHT. What if you have TWO statements? Which belongs to whom? ] ] Program X(output); ] ] Procedure Y; { Begin } ] ] Writeln("A"); ] ] { End; } { Begin } ] ] Writeln ("b"); Y; ] ] { End. } ] ] Now, with all the begin-end constructs eliminated, how do you tell which ] statements belong to which procedure? ] ] (Obviously, the "begins" are all superfluous. The "ends" aren't, though.) ] ] C. Wingate It's not how do you tell which STATEMENTS belong to which procedure, but which STATEMENT. If you want to have more than one statement for the body of your (sub-)program, there MUST be some form of grouping (ie terminator, delimiters). I think therein lies the source of your confusion. I am not proposing that the groupers be thrown out, only excluded when they're not necessary and there's no loss in clarity. So, in your example, Writeln("A") would be bound to Procedure Y, Writeln ("b") to Program X, and the code after that would probably then generate some 'end of program expected' error. To bind both the Writeln ("b") and the call to Y to Program X, they must be grouped somehow (the second commented-out begin-end pair would do nicely). [ This appears to have been intended to be Pascal, which uses the ] [ single quote to delimit text constants. Flame on you! :-) ] _ /| \`o_O' ( ) Aachk! Phft! U Disclaimer: The opinions and/or information and/or code expressed here were generated by this characature, stolen from Dave Rasmussen, to which I have taken the liberty of adding ears. So don't look to me for a disclaimer! Silver {...!topaz!gaynor}
kurt@fluke.UUCP (07/11/86)
Q: Why do many languages require the statement that is the body of a
function to be a compound statement?
A1: Languages which permit the null statement are ambiguous in a serious
and not intuitively resolvable way. (This was pointed out previously).
A2: Using a statement block delimits the function. This is important
visually and syntactically. Just because it is *possible* to parse a
single statement as the statement block does not make it a good idea.
Consider the problem of parser error recovery. Good error recovery is
more probable when there is a good chance of finding the block/function
delimiting END statement. If this statement is not available, error
recovery actions may eat into the following declaration, with confusing
and comical results.
As mentioned in another article, the visual delimitation is helpful in
reading the code. The original claim was that it was easier to read if
the function body was a single statement. This is possibly true, but we
can't write parsers that say, "If the function body is only a couple of
lines, it may be a single statement. Otherwise it must be a block."
A3: Some recent languages use a "comb" syntactic structure to evade this
problme altogether. Consider this obviously psudo-code
integer function factorial (x) is
integer x
if x = 1 then
return 1
else
return x * factorial (x)
end if
end factorial
The function is delimited on top and bottom. So is the if statement.
Ada has this approximate structure. A 1-line body is possible, and the
statement doesn't have to be enclosed in a block. In fact, blocks are
completely unnecessary in such languages, although they are often
provided to delimit scope for local variable definition.gaynor@topaz.UUCP (07/12/86)
[eat me (non-line-eaters need not apply)] In article <8900039@uiucdcsb>, wsmith@uiucdcsb.CS.UIUC.EDU writes: > You have your fancy, one statement function/procedure. it's three > screenfuls and you just found out that the fancy 1 statement function > now is a two statement function. Blech! Now you have to find the > beginning of the procedure, the end of the procedure and add a begin/end > pair at the ends. In my original posting, I outlined several cases when one could argue that the delimeters were necessary (and I quote): (1) If the code [example code included, ~2/3 of a page, one single deeply nested 'if-then-else'] were any longer, one could argue that it's done to increase readability by imposing delimeters. (2) If the code were any longer, one could argue that it's done as a built-in error check. I certainly did not mean to imply that these arguments are invalid! Sorry for any misconceptions there. They certainly are valid, under the conditions you outlined. But those conditions are NOT the same as those under which I based my argument. I specifically referred to the shorter pieces of code that are written. Besides the references above, I remind the reader of the conditions of my argument with: But, the recent trends in programming place emphasis on modular code; hence, people are writing more, smaller procedures. It's those smaller procedures that have no need of delimeters. For a really extreme example, consider: procedure init-tree (ref tree t1) | procedure init-tree (ref tree t1) | t1 <- null-tree | begin | t1 <- null-tree | end I mean, it doesn't make a damn bit of difference whether the begin-end pair is there or not. Both are perfectly clear, and neither will be any source of syntactic error in the long run... I'm generating a "Somebody-Else's-Problem Field" for your next issue. Errors in both block delimitation and statement seperation/termination may cause both local AND global errors in most languages. Generally, though, the sep/term errors are much more localized than the block delimeter errors. > [ discussion concerning inadvertant leftover seps/terms in ] > [ if ... then ... ; ... --> if ... then ... ; else ... ; ... ] > [ discussion asserting local changes should affect local ] > [ code only and how the above errors are non-local ] > Bill Smith _ /| \`o_O' ( ) Aachk! Phft! U Disclaimer: The opinions and/or information and/or code expressed here were generated by this characature, stolen from Dave Rasmussen, to which I have taken the liberty of adding ears. So don't look to me for a disclaimer! Silver {...!topaz!gaynor}
aglew@ccvaxa.UUCP (07/13/86)
... > Discussion of compound statements for procedure bodies;
... > ambiguity in null statements without BEGIN..END brackets.
Personally, I prefer PROCEDURE..END PROCEDURE brackets (single character
symbols if the character set is large enough - hell! I prefer LISP
parentheses) but would like to point out that the above problem with
null statements only occurs because the null statement is BEGIN..END
or {} or ;, ie. because the null statement is implicit.
Dijkstra argues that making the null statement explicit, `skip', with
defined semantics, may be as important for computer science as the
invention of zero was for arithmetic.
On many occasions I have found that explicitly putting in a null statement
(in whatever form the language permits) is clearer than not; ie.
if( long_and_complicated_condition )
/* do nothing */;
else {
...
}
is easier to read and maintain (and add debug lines to) than
if( !( long_and_complicated_condition ) ) {
...
}
with no else branch. Especially if somebody has tried to `simplify' things by
applying DeMorgan's rule.
I would take this further, and say that for every class of construct there
should be a null construct. C, for example, has a null statement in a
solitary semicolon, but doesn't have a null declaration, ie. a declaration
that declares absolutely nothing.
foo()
{
int a;
;
int b;
isn't allowed. That's not really serious; something that I have thought would
be more useful would be a null character - not '\0', but a character that
generates no output in strings, just acts as a place holder. It would be nice
to break up long escape command sequences in strings, so that you can see the
components: "\e[1;8...\em9..." where ... is the place holder. Although
ANSI C with string constant concatenation does better "\e[1;8" "\em9" ...
OK, who's going to tell me I'm brain damaged now? I hope that they can do
arithmetic in Roman numerals...
Andy "Krazy" Glew. Gould CSD-Urbana. USEnet: ihnp4!uiucdcs!ccvaxa!aglew
1101 E. University, Urbana, IL 61801 ARPAnet: aglew@gswd-vmsemjej@uokvax.UUCP.UUCP (07/14/86)
/* Written 3:56 pm Jul 7, 1986 by sommar@enea.UUCP in net.lang */ I would guess Algol doen NOT force you to use BEGIN-END. Simula does definitely not do it, and as far I know Algol is a true subset of Simula. /* End of text from net.lang */ In Algol W, a program is a statement (see the BNF), so beginning programmers often see programs like for i:= 10 to 100 by 5 do write(i, " degrees C = ", 1.8 * i + 32.0, " degrees F"). In Algol 68, if memory serves, a particular-program is a unit, so one should be able to do similar things. Same goes for procedure bodies, so to show the halting problem is insoluble, one can write (perhaps prepending "Behold!" as was done for a famous proof of the Pythagorean theorem :-) proc paradox void: while halts(paradox) do skip od James Jones
franka@mmintl.UUCP (07/14/86)
In article <5323@topaz.RUTGERS.EDU> gaynor@topaz.UUCP writes: >In article <8900039@uiucdcsb>, wsmith@uiucdcsb.CS.UIUC.EDU writes: > But, the recent trends in programming place emphasis on modular > code; hence, people are writing more, smaller procedures. Question: when is a small procedure not a small procedure? Answer: five years later. Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108
rcd@nbires.UUCP (07/16/86)
> Dijkstra argues that making the null statement explicit, `skip', with > defined semantics, may be as important for computer science as the > invention of zero was for arithmetic. Mmph. That's either a misattribution or one of the craziest analogies I'VE ever heard. I'd like to think that I can guess what the semantics of the null statement might be (!), so I'm puzzled. Either the semantics ARE obvious (nothing) in which case they're uninteresting, or they're far from obvious in which case something is seriously wrong (because a simple but un-obvious construct will get your users in trouble). So to get the effect equivalent to "zero" out of the null statement, do we invent some sort of "positional notation" for statements?!?! (Seriously, a context for the Dijkstra statement would be appreciated.) > ...OK, who's going to tell me I'm brain damaged now? I hope that they can do > arithmetic in Roman numerals... Was this just a coincidental .signature? Curiously relevant. -- Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086 ...At last it's the real thing...or close enough to pretend.
latham@bsdpkh.UUCP (07/16/86)
In article <8900039@uiucdcsb> wsmith@uiucdcsb.UUCP writes: > >Another argument for forcing the brackets on a function: ^^^^^^^^ >(derived from experience in programming in pascal........etc. > Bill (Smith) if you see this, I don't mean to pick on you, you just happened to be convenient and guilty. ( didn't I hear that from a policeman once :-) ) Believe me there are Soooo many people that do it !!!! these things ---> { } are called BRACES not brackets! these things ---> [ ] are brackets! Look up 'braces' in the dictionary, they were first used in music to denote the grouping of staffs on sheets of music. I appologize if this in any way offends anyone, but I don't know how many times I have called them braces only to be "told" they are : "Curly brackets" "Brackets, only a different kind." "NO, they're, Brackets, you don't know what you're talking about." I know this is PETTY, but I just had to get it off my chest!!! ( it feels soooooo goooood ! :-) Ken Latham, AT&T-IS (via AGS Inc.), Orlando , FL uucp: ihnp4!bsdpkh!latham
blake@cit-vlsi.UUCP (07/17/86)
In article <463@opus.nbires.UUCP> rcd@nbires.UUCP (Dick Dunn) writes: >> Dijkstra argues that making the null statement explicit, `skip', with >> defined semantics, may be as important for computer science as the >> invention of zero was for arithmetic. > >Mmph. That's either a misattribution or one of the craziest analogies I'VE >ever heard... > >(Seriously, a context for the Dijkstra statement would be appreciated.) > >Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086 "Those who think it a waste of characters to introduce an explicit name such as 'skip' for the empty statement while 'nothing' expresses its semantics so eloquently, should realize that the decimal number system was only possible thanks to the the introduction of the character '0' for the concept zero" Edsger W. Dijkstra, A Discipline of Programming (p. 25) The analogy isn't so farfetched. Viewed as a predicate transformer, skip represents a simple but indispensable function, namely the identity. It must be included in some guise in every reasonsable language. It is essential to realize that the empty statement *is* a statement in order to define programming language semantics sensibly. Similarly, it had to be understood that zero is a number before a good notation for numbers could be devised. One can certainly argue that a good notation for program semantics is as important for the development of computer science as the decimal system was for arithmetic.
faustus@ucbcad.BERKELEY.EDU (Wayne A. Christopher) (07/17/86)
According to quantum physicists, < > are brackets. The < is called a "bra" and the > is a "ket"... Wayne
flaps@utcs.UUCP (07/18/86)
In article <8900039@uiucdcsb> wsmith@uiucdcsb.CS.UIUC.EDU writes: > >Another argument for forcing the brackets on a function: > >You have your fancy, one statement function/procedure. it's three >screenfuls and you just found out that the fancy 1 statement function >now is a two statement function. Blech! Now you have to find the >beginning of the procedure, the end of the procedure and add a begin/end >pair at the ends. This is an argument for USING braces, not for requiring them. This problem is averted by you personally using braces. This problem is not averted by forcing other people to use braces. Braces on a one-statement function should be optional for the same reason that programs can compile without being able to pass lint. I use lint myself, but if you don't, you might as well still be able to use the compiler. Now if functions without braces are harder to parse, that's a different question. -- Alan J Rosenthal {cbosgd|ihnp4}!seismo!mnetor!utcs!flaps, utzoo!utcs!flaps
gaynor@topaz.RUTGERS.EDU (Silver) (07/18/86)
In article <1986Jul18.023314.21855@utcs.uucp>, flaps@utcs.uucp (Alan J Rosenthal) writes: > In article <8900039@uiucdcsb> wsmith@uiucdcsb.CS.UIUC.EDU writes: > > > >Another argument for forcing the brackets on a function: > > > >You have your fancy, one statement function/procedure. it's three ^^^^^ spelt c-o-m-p-l-i-c-a-t-e-d > >screenfuls and you just found out that the fancy 1 statement function > >now is a two statement function. Blech! Now you have to find the > >beginning of the procedure, the end of the procedure and add a begin/end > >pair at the ends. I think it's relatively clear that my original gripe was that sometimes a certain elegance is lost on a small procedure when enclosed within a compound statement. Perhaps the sheer unnecessity of a delimeter is distracting if it is present. I would NEVER recommend this practice with a procedure of any great length or complexity - in fact, I came out and said it time and time again that the example included (about 2/3 of a screenful) was borderline. I chose the example carefully (not the algorithm itself - it was on my mind, and happened to be the right length and complexity). Any smaller or less complex, disclude. Any larger or more complex, include. Just that size and complexity, total up the debits and the credits, and then decide. Do your homework BEFORE you post. Saves on phone bills. [ I apologize to those who are annoyed by seeing every little thing ] [ spelt out repeatedly. I find it annoying to do. ] > [...] > > Braces on a one-statement function should be optional for the same reason > that programs can compile without being able to pass lint. I use lint > myself, but if you don't, you might as well still be able to use the > compiler. Lint's general purpose is to detect bad programming practices. If I were lint, I would only complain about the abscence of the compound statement in question only if the code was greater than 20 or so lines and/or unusually complex (ie containing deeeeep nesting, gotos (which probably would flag lint anyway, don't bother correcting me if I'm wrong), things of that ilk). Warning: procedure wsmiths_fancy_one_statement_procedure long enough to warrant enclosure in compound statement (length: 68) Warning: procedure deeply_nested_if complicated enough to warrant enclosure in compound statement (nesting: 6) > Now if functions without braces are harder to parse, that's a different > question. Consider the major parsing schemes. It makes little difference to a parser generator. I did it in a *simple* recursive-descent parser in minutes. Without going into a heavy discussion, it depends more upon the individual language and ambiguity. Error recovery will probably be a bit tougher, but not impossible. It all depends upon the language. > Alan J Rosenthal > {cbosgd|ihnp4}!seismo!mnetor!utcs!flaps, utzoo!utcs!flaps _ /| \`o_@' (*) Aachk! Phft! U Disclaimer: The opinions and/or information and/or code expressed here were generated by this characature, stolen from Dave Rasmussen, to which I have taken the liberty of modifying. So don't look to me for a disclaimer! Silver {...!topaz!gaynor}
aglew@ccvaxa.UUCP (07/19/86)
>> Dijkstra argues that making the null statement explicit, `skip', with >> defined semantics, may be as important for computer science as the >> invention of zero was for arithmetic. > >Mmph. That's either a misattribution or one of the craziest analogies I'VE >ever heard. Reference: _A_Discipline_Of_Programming_, Edsger W. Dijkstra, Prentice-Hall, 1976. (I am very attached to this book, as it was one of the first books on Computer Science, as opposed to programming, that I ever read. I keep it on my bookshelf at work, and every now and again try to understand it ;-) p. 25: The semantics of the statement named `skip' are therefore given by wp(skip,R) = R ... Note: Those who think it a waste of characters to introduce an explicit name such as `skip' for the empty statement while "nothing" expresses its semantics so eloquently, should realize that the decimal number system was only possible thanks to the introduction of the character "0" for the concept zero. (End of note.) The semantics should be intuitively obvious (`wp' means weakest precondition, so wp(skip,R)=R means that for R to be true after a skip it must have been true before (unless you're time based)). Are they uninteresting because they are obvious? Maybe so: do you find zero uninteresting? Maybe you do (I don't), but even so, is interest a prerequisite for a notation? The point is, programming is a positional notation. S1;S2 is not the same as S2;S1, hence it is position sensitive, and in any position sensitive system you need a placeholder. --- Yep. I guess with a signature like mine any statement I make is open to doubt. But with a name like mine you take the first decent nickname that comes along. Andy "Krazy" Glew. Gould CSD-Urbana. USEnet: ihnp4!uiucdcs!ccvaxa!aglew 1101 E. University, Urbana, IL 61801 ARPAnet: aglew@gswd-vms
aglew@ccvaxa.UUCP (07/19/86)
... > Ken Latham is being pedantic about braces and brackets.
Welll.... {} are braces. [] are brackets, () are parens. I forget the
proper name for < > or << >>.
Buttt... These symbols all perform a similar function - they are all matchfix
operators, if you will. I find the term `matchfix' obnoxious, so I prefer to
use `brackets' as a generic term. In which case adjectives are useful to
distinguish {} curly brackets from [] square brackets and () round brackets
and < > angle brackets and << >> double angle brackets and BEGIN END verbose
brackets and ...
Andy "Krazy" Glew. Gould CSD-Urbana. USEnet: ihnp4!uiucdcs!ccvaxa!aglew
1101 E. University, Urbana, IL 61801 ARPAnet: aglew@gswd-vmsron@brl-sem.ARPA (Ron Natalie <ron>) (07/19/86)
In article <1986Jul18.023314.21855@utcs.uucp>, flaps@utcs.uucp (Alan J Rosenthal) writes: > > Now if functions without braces are harder to parse, that's a different > question. > Functions without braces are impossible to parse in C. Unfortunaetly C uses the open brace to terminate the declarations. It's only two characters. -Ron
hoffman@hdsvx1.UUCP (Richard Hoffman) (07/21/86)
> According to quantum physicists, < > are brackets. The < is called > a "bra" and the > is a "ket"... > > Wayne Brackets they may be (though I have usually heard them called "angle" brackets, to distinguish them from "square" brackets -- "[]"), but the bra and the ket refer not to the symbol but to the entities they enclose. For example, in the term "<x|F|y>", the "ket" is |y>, a dual vector which is operated upon by F and then matrix multiplied with the "bra" vector <x|. Personally, I think we should start compound statements with "this_is_the_start_of_a_compound_statement" and end them with "tnemetats_dnuopmoc_a_fo_trats_eht_si_siht". :-) ;-> :-). -- Richard Hoffman | "If you take a starving dog from the street Schlumberger Well Services | and make him prosperous, the dog will not hoffman%hdsvx1@slb-doll.csnet | bite you. This is the principle difference PO Box 2175, Houston, TX 77252 | between a dog and a man." -- M. TWAIN
ph@wucec2.UUCP (07/21/86)
In article <800019@ccvaxa> aglew@ccvaxa.UUCP writes: >... > Ken Latham is being pedantic about braces and brackets. > >Welll.... {} are braces. [] are brackets, () are parens. I forget the >proper name for < > or << >>. I don't know if there is a "proper name" as such, but the Hackers' Dictionary calls < and > _brokets_. --pH /* * "PLUGH" */
rcd@nbires.UUCP (Dick Dunn) (07/24/86)
> >> Dijkstra argues that making the null statement explicit, `skip', with > >> defined semantics, may be as important for computer science as the > >> invention of zero was for arithmetic. > > > >Mmph. That's either a misattribution or one of the craziest analogies I'VE > >ever heard. OK, thanks to Andy Glew, I can correct that last statement: >Reference: _A_Discipline_Of_Programming_, Edsger W. Dijkstra, Prentice-Hall... > p. 25: The semantics of the statement named `skip' are therefore given by > wp(skip,R) = R > ... > Note: Those who think it a waste of characters to introduce an explicit > name such as `skip' for the empty statement while "nothing" expresses its > semantics so eloquently, should realize that the decimal number system > was only possible thanks to the introduction of the character "0" for > the concept zero. (End of note.) So he (EWD) didn't really SAY that `skip' might be as zero, but he certainly encourages such an interpretation. I guess I'll go with calling it one of the craziest analogies I've ever heard. > The semantics should be intuitively obvious (`wp' means weakest precondition, > so wp(skip,R)=R means that for R to be true after a skip it must have been > true before (unless you're time based)). Are they uninteresting because they > are obvious? Maybe so: do you find zero uninteresting? Maybe you do (I > don't), but even so, is interest a prerequisite for a notation? The fact that wp(skip,R)=R is true; it may be of notational interest; in a formal system you may have to have just such a statement. But stripped of the notation, it says "if something is true and absolutely nothing happens, that something is still true." This is not only obvious to the meanest of intelligences; it is a tautology. The question "do you find zero uninteresting?" has nothing (!) to do with the matter of the empty statement. Somehow zero the digit and zero the value (which happens to be denoted by an occurrence of zero the digit) have gotten horribly confused here. [If you want to play some little games, you can construct a notation in which a zero value is denoted by the absence of any symbols, yet 0 is still used as a placeholder in positional notation! To arrive at such a notation, just take what we normally use and ALWAYS remove ALL leading 0 digits from values.] > The point is, programming is a positional notation. S1;S2 is not the same > as S2;S1, hence it is position sensitive, and in any position sensitive > system you need a placeholder. The analogy here seems to be made with positional number systems. It is true that 10 is not the same as 01. But the analogy just doesn't work--if it did, S1;skip would not be the same as skip;S1! The form S1;S2 is a spatial representation of a temporal concept. Positional number notation is atemporal. Finally...just because Dijkstra said it, it ain't necessarily so. He's good but not infallible, and he often uses hyperbole to make a point. -- Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086 ...Never attribute to malice what can be adequately explained by stupidity.
taylor@glasgow.glasgow.UUCP (Jem Taylor) (07/29/86)
>> According to quantum physicists, < > are brackets. The < is called >> a "bra" and the > is a "ket"... I'm a pedant too ! I believe '<' and '>' to be 'carets', rather than 'brackets'. If anyone really cares, they could look up that word in a dictionary; I haven't. -Jem. -- -------------------------------------------------------------------------------- JANET: ' , ' , ' taylor@uk.ac.glasgow.cs ' ___ , ' USENET: , / | \ , { uk }!cs.glasgow.ac.uk!taylor ' -o| Royal Mail: , ' (J=) ' , J.A.Taylor ~~~~~~~~~~~~~~ Computer Science <>< 17 Lilybank Gardens ><> Jemima GB-GLASGOW G12 8QQ ><> Puddleduck "who says it doesn't rain on the west coast ?"
sambo@ukma.UUCP (Father of micro-ln) (08/02/86)
In article <659@glasgow.glasgow.UUCP> taylor@glasgow.UUCP (Jem Taylor) writes: >I'm a pedant too ! I believe '<' and '>' to be 'carets', rather than 'brackets'. >If anyone really cares, they could look up that word in a dictionary; I haven't. I think this discussion has probably gone too far. Not that I really care, but according to a "The Merriam-Webster Dictionary" published by Pocket Books a previous office dweller left lying around, a caret is "a mark ^ used to indicate the place where something is to be inserted," and a bracket, among other things, is "one of a pair of punctuation marks [ ] used esp. to enclose interpolated matter." Now this is a 1974 edition, so someone might want to check a more recent edition to see if the meanings have changed. :-) _________________________ Samuel A. Figueroa, Dept. of CS, Univ. of KY, Lexington, KY 40506-0027 UUCP: cbosgd!ukma!sambo CSNET: sambo@uky.csnet "Micro-ln is great, if only people would start using it."