Return-Path: Received: from B.GP.CS.CMU.EDU by B.GP.CS.CMU.EDU id aa02137; 25 May 93 19:57:57 EDT To: cmu-dylan-members@CS.CMU.EDU Subject: Final (?) Dylan Infix Notation Critique. Date: Tue, 25 May 93 19:57:50 -0400 Message-ID: <2135.738374270@B.GP.CS.CMU.EDU> From: Paul_Gleichauf@B.GP.CS.CMU.EDU Guys, Here is an updated form of my criticisms of about a week ago, which if it passes muster will get sent along to Mike Kahl at Apple. Only Scott sent along refinements. There is some duplication with other messages that have been sent, but did not elicit any reaction. Paul ==================================================================== Dylan Infix Syntax This document offers some criticisms of the Dylan infix notation and suggestions for its improvement. The topic heading is listed first, then critical comments, followed by suggestions for a better way of accomplishing the same or a similar purpose. Infix notation will attract more C and novice programmers than the LISP syntax. There seems to be a pervasive ambiguity in the current philosophy of the infix synatx. One is that if adequate syntax exists in C for the same purpose, adopt it, if it does not exist or is inadequate look to Lisp, if it does not exist or is inadequate in either case, be creative. Yet in other places the notiation is inspired by LISP and hybridized with C. An example of the latter in the infix notation is the use of the # character as a dispatch prefix with a variety of uses. If this is the design intent it should be made explicit in the documentation of the proposal, for there is no madness in clear method. It is our opinion that the threshold for adapting to Dylan should be minimized in the notation. If there is adequate precendent in C for a specific infix notation, and it isn't manifestly brain-dead, let's use it and make the evolution of the C programmer to Dylan simple. The same argument applies to the Lisp programmer. When it makes sense use Common Lisp like notation. Only a relatively few of us will cross back and forth over the boundary. Character Set Comments are prefaced by a # and a white space character and the comment continues until the end of the line. This makes blocks of comments awkward or the commenting out of sections of code keystroke intensive. Add an additional reserved combination of characters like /* and */ in C for comment block begin and end. Perhaps the #| and |# from LISP should be added to the LISP syntax and to the infix notation for dispatch. Symbols The list of operator symbols seems to be incomplete and inconsistent. There is mention in the code examples of ==, but it is not included in the list of logical operators. How about other logical operators for AND, OR, etc.? These might well follow the C pattern (&& and ||), but even clearer is the reservation of the symbols AND, OR, == as logical operators. Literals Is case significant for determining the exponent (E) for a floating point number? There is mention of #x for hexadecimal, which implies mixed case. Suggestion: case insensitive. How about single (S) and double float (D) symbols? [This is an issue for the language in either notation.] Do not include an escape mechanism for including arbitrary characters in a string literal unless a string argument can be made which is not based on the history of LISP. In the Infix proposal: A string literal is contained within double quotes. A backslash may be used as an escape character to include a double quote or a backslash in the string. (An escape mechanism for including arbitrary characters has not been determined.) The current alternative is to type something like "foo/'/'/[", a string of alternating backslashes and reserved puctuation characters. The LISP "solution" is to use | bounding. This mechanism is used so infrequently that no special mechanism need be supplied; rely on the current slightly cumbersome but seldom used solution. This does not prohibit against being able to include arbitrary program literals. (This is mentioned as something that needs to be determined.) Grammar There is insufficient explanation for the use of . , especially as it pertains to its application as both a terminator for top level define forms, and its second application inside expressions. Dylan Lisp syntax has a respectable COND conditional construct that permits multiple expressions as a consequence of a given conditional clause. The infix replacement, when, allows only a single consequence (condition-clauses: condition[opt] expression ; [opt]). The present work around is to use begin and end to render the consequent expression as a block. What is the semantic meaning of body as ^expression? More documentation is needed here. The for-clause grammar introduces the use of a range specifier in the form of upto. The Dylan manual provides for the generic function RANGE which does everything necessary for iteration without the need for additional reserved word like UPTO for iteration. Use it rather than adding addition redundant syntax. Get rid of the { predicate => form1 ; form2 } syntax entirely. It is ugly in C, and no better here. Stick with the if construction. The literal quoting mechanism is not simple logically, it is inherited from other languages. Character literals constants require the use of the single quote character ' on both sides, vary C like. And what about the unquoted escape sequence for things like carriage returns. A symbolic literal is a hybrid #'foo'. Then we should document the ubiquitous use of # as a dispatch character. The inconsistency is that strings are just "string", so characters and strings do not use the dispatch character #, but are two side bounded by the ' and " characters. The symbolic literal case might seem a little strange to both camps when seen for the first time without a little more documentary motivation.