shelley@atc.sps.mot.com (Norman K. Shelley) (02/15/90)
Comments on I.S.E.'s proposed changes for Eiffel 3.0 (14Feb90) The new creation syntax and semantics looks very nice. The demise of the special keywords - Clone, Forget, and Void - in favor of the new syntax and semantics is welcomed. "void references" problem: The Void concept being replaced by the use of the class NONE appears to be a very nice improvement. The "improved syntax and semantics for the preconditions and postconditions" is most welcomed. New feature: As an addition for novice or unsuspecting programmers, it would be useful when a redefined routine trys to copy its parents pre or post condition if the compiler would warn the user of the redundancy. Proposed variable argument enhancement. > Many people do like, however, the flexibility of routines for which the > number of arguments is not known in advance. Printing procedures are > the classical example. I must agree! An Eiffel variable argument mechanism would be most useful. > The mechanism may also be useful at the level of interfaces between > Eiffel and other languages such as C and (some versions of) Fortran > which support variable numbers of arguments; an example in C is > printf. Another example is SUN's "Xview" library which uses variable arguments heavily. > Finally, although the default alphabet for identifiers is > still the English letters plus digits and underscore, it becomes > possible to use others if they are specified in a special file New feature: I would like to propose that the hyphen be added to the default alphabet for identifiers and that the hyphen take over the accepted use of the underscore for separating words in an identifier. Page 240 of "Eiffel: The Language" states that "internal upper-case letters ... as in putAtRight, contradicts the standard conventions of English ... and is not part of the recommended style." I agree BUT must note that the underscore ('_') as a word separator is NOT English either. A whitespace is the accepted standard but computers have troubles with whitespace in names/labels so what do we do? Common Lisp uses hypens ('-') as a separator and this has more acceptance in English than an underscore. So if we can't use blanks because of computer limitation and internal upper-case because it does not match current language conventions, then I think hyphens make MUCH more sense than underscores which themself do NOT conform to current language conventions. ------------------------------------------------------------------------------- The reason for some qualified approvals is that until I can actually try something I usually can not find the really deep problems that are hiding beneath the surface. Norman Shelley Motorola - ATC 2200 W. Broadway AZ09/M350 Mesa, AZ 85202 ...!uunet!dover!atc!shelley shelley@atc.sps.mot.com (602) 962-2473
brucec@crl.labs.tek.com (02/17/90)
In article <48a55876.12c9a@digital.sps.mot.com> shelley@atc.sps.mot.com (Norman K. Shelley) writes: >Comments on I.S.E.'s proposed changes for Eiffel 3.0 (14Feb90) > ... assorted non-controversial comments ... >Page 240 of "Eiffel: The Language" states that "internal upper-case letters ... >as in putAtRight, contradicts the standard conventions of English ... >and is not >part of the recommended style." I agree BUT must note that the >underscore ('_') This opinion has bothered me for some time, and I couldn't quite place why, until I happened to be typing in an address. There are, in fact, words used in English, though they are proper names to be sure, which have internal upper-case letters. McDonnell, LeCompte, etc., etc. The fact that they are names doesn't hurt the argument: that's exactly what the symbols of a computer language are. That they are accretions from other languages is true, but not very important; that's where most words in English have come from. So there is a precedent for internal upper-case, and now I have a justification for using a style that happens to suit me. 1/2 :-) Bruce Cohen brucec@tekcrl.labs.tek.com Computer Research Lab, Tektronix Laboratories Tektronix, Inc. M/S 50-662, P.O. Box 500, Beaverton, OR 97077
ok@goanna.oz.au (Richard O'keefe) (02/20/90)
In article <48a55876.12c9a@digital.sps.mot.com>, shelley@atc.sps.mot.com (Norman K. Shelley) writes: > Page 240 of "Eiffel: The Language" states that "internal upper-case letters ... > as in putAtRight, contradicts the standard conventions of English ... > and is not part of the recommended style." I agree BUT must note that the > underscore ('_') > as a word separator is NOT English either. A whitespace is the accepted > standard but computers have troubles with whitespace in names/labels so what do > we do? This is contrary to fact. Computers have no trouble whatsoever with layout inside names. Consider Fortran, Algol 68, and IMP for starters. I also have a modified Prolog which allows layout inside names as well, where I adopted the rule that 1 or more layout characters inside an identifier were equivalent to a single underscore, so that translation of identifier(New Style Identifier, Old Style Id) was read the way that translation_of_identifier(New_Style_Identifier, Old_Style_Id) is read in normal Prolog syntax, so this could coexist with a standard tokeniser/parser. The only thing that tokenisers have trouble with is telling where one identifier ends and another begins. There are several ways around this. One of them is to use a syntax where the issue just doesn't arise. For example, require latest x = old y; would cause a problem, but if it were require (latest x = old(y)); so that identifier never met identifier, the problem would go away. Another is to use a form of stropping; there were four official methods of stropping for Algol 68 and IMP used another, e.g. %require latest x = %old y; I _don't_ agree that the Eiffel lexical rules for identifiers warrant changing, but let's but delude ourselves, the only reason for not allowing spaces in identifiers is the language designer's careful choice.
sakkinen@tukki.jyu.fi (Markku Sakkinen) (02/21/90)
In article <2888@goanna.oz.au> ok@goanna.oz.au (Richard O'keefe) writes: >In article <48a55876.12c9a@digital.sps.mot.com>, shelley@atc.sps.mot.com (Norman K. Shelley) writes: >> ... >> underscore ('_') >> as a word separator is NOT English either. A whitespace is the accepted >> standard but computers have troubles with whitespace in names/labels >> so what do we do? > >This is contrary to fact. Computers have no trouble whatsoever with >layout inside names. Consider Fortran, Algol 68, and IMP for starters. Fortran's stupid lexical conventions certainly cause trouble both to computers (compilers: separate lexical analysis is impossible) and more importantly, to programmers. Everybody knows some classic example like DO 100 I = 1.10 >The only thing that tokenisers have trouble with is telling where one >identifier ends and another begins. There are several ways around this. > .... >Another is to use a form of stropping; there were four official >methods of stropping for Algol 68 and IMP used another, e.g. > %require latest x = %old y; Please give a more enlightening example. In the above, the '%' characters appear only at places where they contribute nothing to separating the identifiers. Also, what is/was IMP? Some old Algol-60 compiler(s) required the language keywords to be within apostrophes: 'begin' 'integer' n, m ... 'end' Is that called 'stropping' also? It wasn't such a bad idea: now when language standards are updated and new features added, there is often a problem of new keywords clashing with identifiers in existing software. > ... Markku Sakkinen Department of Computer Science University of Jyvaskyla (a's with umlauts) Seminaarinkatu 15 SF-40100 Jyvaskyla (umlauts again) Finland SAKKINEN@FINJYU.bitnet (alternative network address)
jacob@gore.com (Jacob Gore) (02/22/90)
/ comp.lang.eiffel / sakkinen@tukki.jyu.fi (Markku Sakkinen) / Feb 21, 1990 / > Some old Algol-60 compiler(s) required the language keywords > to be within apostrophes: > 'begin' 'integer' n, m ... 'end' > Is that called 'stropping' also? It wasn't such a bad idea: > now when language standards are updated and new features added, > there is often a problem of new keywords clashing with identifiers > in existing software. My understanding is that in those days the expectation was that Algol keywords would become part of the character set and engraved on keyboards (think that's silly? think APL). Denoting keywords with apostrophes was a nice, cheap, workaround in the meantime. Jacob -- Jacob Gore Jacob@Gore.Com boulder!gore!jacob
ok@goanna.oz.au (Richard O'keefe) (02/22/90)
In article <3476@tukki.jyu.fi>, sakkinen@tukki.jyu.fi (Markku Sakkinen) writes: > In article <2888@goanna.oz.au> ok@goanna.oz.au (Richard O'keefe) writes: > >Computers have no trouble whatsoever with > >layout inside names. Consider Fortran, Algol 68, and IMP for starters. > > Fortran's stupid lexical conventions certainly cause trouble both to > computers (compilers: separate lexical analysis is impossible) > and more importantly, to programmers. Everybody knows some classic > example like > DO 100 I = 1.10 No, Fortran's conventions don't cause any trouble to computers at all. I have written two Fortran preprocessors; the hacks for lexical analysis require nothing deeper than counting parens and looking out for '=' and ','. It wasn't at all hard. The DO statement is not a problem with Fortran's *lexical* rules. If the syntax were DO <variable> FROM(<expr>) TO(<expr>) [BY(<expr>)] ... END DO [<variable>] -- which would fit very nicely indeed with Fortran lexical style -- that kind of mistake couldn't happen. No way am I going to defend the Fortran "DO" statement. There is an interesting reason why Fortran, Algol 60, and Algol 68 allow and ignore embedded spaces in tokens. They were all intended for "scientific" programming. When you enter a 40 digit number from a set of tables such as Abramowitz & Stegun or from some other source, it is very easy to make typing mistakes. It is _much_ easier to check 3.14159 26535 89793 23846 than it is to check 3.14159265358979323846 Ada compromises and allows embedded and ignored underscores in numbers, which is nearly as good. I do _not_ advocate allowing spaces in Eiffel tokens, but I _do_ think that allowing underscores in numbers would be useful. The syntax of "Reals" is very much downplayed in "Eiffel: the language", "Real" is used but not defined in the syntax appendices and the change wouldn't invalidate existing programs (to keep it under control one could rule that an underscore in a number must be preceded and followed by a digit). > >Another is to use a form of stropping; there were four official > >methods of stropping for Algol 68 and IMP used another, e.g. > > %require latest x = %old y; > > Please give a more enlightening example. In the above, the '%' > characters appear only at places where they contribute nothing > to separating the identifiers. Also, what is/was IMP? IMP is the IMPlementation language of the EMAS operating system. Sorry about the example; the point here was simply that it had yet another stropping convention. > Some old Algol-60 compiler(s) required the language keywords > to be within apostrophes: > 'begin' 'integer' n, m ... 'end' > Is that called 'stropping' also? I think it's called "quote stropping" or "prime stropping", another one is "point stropping" (leading "." and optional following "."), then there are Case, UPPER, and "reserved" stropping. The Algol 68C compiler supports most of them. I think this has gone on long enough; anyone who wants to talk about spaces in tokens can do it in comp.lang.misc. The relevance to Eiffel is that -- Eiffel uses reserved words and prohibits embedded spaces, not because computers can't handle anything else (PL/I has no reserved words!) but because Eiffel's designers thought that was the right choice. -- Some method of clumping digits in numeric literals _would_ make some kinds of Eiffel programs easier to desk check.
jgk@osc.COM (Joe Keane) (02/23/90)
In article <48a55876.12c9a@digital.sps.mot.com>, shelley@atc.sps.mot.com (Norman K. Shelley) writes: >Page 240 of "Eiffel: The Language" states that "internal upper-case letters >... as in putAtRight, contradicts the standard conventions of English ... >and is not part of the recommended style." I agree BUT must note that the >underscore ('_') as a word separator is NOT English either. A whitespace is >the accepted standard but computers have troubles with whitespace in >names/labels so what do we do? I heartily agree with the Eiffel people here. I remember the first time i saw capitalization used as a word separator, as in `addLine'. I thought it's a complete abomination and haven't changed my mind since. I think most people have the same initial reaction but unfortunately manage to get over it. I'm undecided as to whether this style is more repulsive than simply butting the words together, as in `addline'. My favorite style is hypenation, as in `add-line'. This is the prefered style in Lisp and similar languages, and conforms exactly with English usage for using multi-word phrases as words. Unfortunately, in most languages this is precluded by the fact that the hyphen character is taken to be the subtration operator. In these languages, IMHO the next-best choice is to separate words with underscores in place of hyphens. It does look a little strange to non-programmers, but it sure beats the alternatives.
firth@sei.cmu.edu (Robert Firth) (02/24/90)
In article <2067@osc.COM> jgk@osc.osc.COM (Joe Keane) writes: >... In these languages, IMHO the next-best choice is to separate words >with underscores in place of hyphens. It does look a little strange to >non-programmers, but it sure beats the alternatives. Well, in my opinion, the best choice is to separate words with spaces, as we do in English and as we did in Algol, back before we started designing languages for the convenience of compilers rather than the convenience of humans.