wsmith@uiucdcsb.UUCP (12/16/84)
Ordinary languages like C, Pascal, etc... either make no restrictions on case of letters in identifiers, make both cases be the same, or they require you to use only one case. Is there any reason that case can not be used to contain semantic information? For example, all identifiers would have to begin with an upper case letter and the rest of the identifier would be lower case. The language could then define lowercase prefixes that determine different types so you would use pFoo for a pointer to a structure named Foo. (typedef struct Foo *pFoo;) If Foo had a field of type pFoo that was named Down, (pFoo Down;) then with these conventions to reference the fourth element from beginning the varable List (struct Foo *List) and assign the second element to point to it, this would suffice pListDown = pListDownDownDown; or equivalently in C List->Down = List->Down->Down->Down; The p prefix is needed to indicate that the pointers are to be assigned and not the structures themselves. An alternative notation is pList.Down = pList.Down.Down.Down; with . also being used as the separator for normal field references. I am interested in peoples reactions to either of these conventions as opposed to C's Bill Smith (ihnp4|pur-ee)!uiucdcs!wsmith
jans@mako.UUCP (Jan Steinman) (12/17/84)
In article <8900018@uiucdcsb.UUCP> wsmith@uiucdcsb.UUCP writes: >Is there any reason that case can not be used to contain semantic >information? ... For example, all identifiers would have to begin with an >upper case letter and the rest of the identifier would be lower case. Smalltalk style uses this very construct for global (vs local) object identifiers. This maps nicely to the English (not english) language concept of proper nouns and common nouns. But alas, this style is merely a convention, and is not enforced by the compiler. -- :::::: Jan Steinman Box 1000, MS 61-161 (w)503/685-2843 :::::: :::::: tektronix!tekecs!jans Wilsonville, OR 97070 (h)503/657-7703 ::::::
jlg@lanl.ARPA (12/18/84)
> Is there any reason that case can not be used to contain semantic > information? There is no reason other than general inconvenience. It would make a nice convention if properly used, but when TREE differs from TREe, which differs from TReE, etc. I can get pretty nasty. I once had this argument before, and I pointed out the the difference in case is not really distinct from other differences between letters. Suppose, for example, you had a terminal capable of color I/O. Should a red T be distinct from a blue one which is different from a green one...? The thing is, it's not really necessary for case to be distinguished, and it can make code unreadable if it is adopted.
greg@ncr-tp.UUCP (Greg Noel) (12/18/84)
In article <8900018@uiucdcsb.UUCP> wsmith@uiucdcsb.UUCP writes: > pListDown = pListDownDownDown; >or equivalently in C > List->Down = List->Down->Down->Down; Congratulations! You've just re-invented L6 ((Bell) Labs Low-Level Linked- List Language), a language so ancient that I'm hesitant to admit I've even heard of it. -- -- Greg Noel, NCR Torrey Pines Greg@ncr-tp.UUCP or Greg@nosc.ARPA
rick@uwmacc.UUCP (the absurdist) (12/19/84)
In article <8900018@uiucdcsb.UUCP> wsmith@uiucdcsb.UUCP writes: >Ordinary languages like C, Pascal, etc... either make no restrictions >on case of letters in identifiers, make both cases be the same, or they >require you to use only one case. > >Is there any reason that case can not be used to contain semantic >information? > Yes, an excellent reason. Not adding bugs to programs. I thought 30 years of research into programming design would be enough to encourage the languages of the 80s to be case-insensitive. Names of objects in a program need a LOT of perceived distance between them if you want to write readable (and bug-free) programs. This computer system, for example, knows that I am "rick" and not some variant of that name. On the other hand, human beings will completely fail to distinguish between "rick", "rich", "Rick", "Richard", etc. A human reading a program will have the same problem. In addition, use of upper-case specifically is a pain in the neck. For most type fonts, it is easy to show that reading the same passage in UPPERCASE IS MUCH MORE DIFFICULT THAN READING IT IN lower case. Lower case letters are easier to distinguish. -- "When I use a word, it means just what I choose it to mean -- neither more nor less" -- Humpty Dumpty, the noted linguist Rick Keir -- MicroComputer Information Center, MACC 1210 West Dayton St/U Wisconsin Madison/Mad WI 53706 {allegra, ihnp4, seismo}!uwvax!uwmacc!rick
rcd@opus.UUCP (Dick Dunn) (12/19/84)
> > Is there any reason that case can not be used to contain semantic > > information? > > There is no reason other than general inconvenience... > ... > The thing is, it's not really necessary for case to be distinguished, and > it can make code unreadable if it is adopted. It might be worth an experiment in a toy language. There are various case conventions that I have encountered which I find difficult to read, such as the MixedCaseStyle. Some folks like that one; my objection is that I find it visually jarring--I'm not used to seeing words with isolated case shifts within. HOWEVER, there's material for experimentation. Natural language has a lot of redundancy in it and programming languages have comparatively little. In natural language, we ignore some case distinctions such as the capitalization of the first word of a sentence but regard others (such as all-caps, usually indicating an acronym these days) as significant. (Gee, maybe we could capitalize the first letter of the first word of a statement, to give some redundancy over the semicolon terminator:-) -- Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086 ...Nothing left to do but smile, smile, smile.
tli@uscvax.UUCP (12/20/84)
> > Is there any reason that case can not be used to contain semantic > > information? > > There is no reason other than general inconvenience. It would make a > nice convention if properly used, but when TREE differs from TREe, which > differs from TReE, etc. I can get pretty nasty. I once had this argument > before, and I pointed out the the difference in case is not really distinct > from other differences between letters. Suppose, for example, you had a > terminal capable of color I/O. Should a red T be distinct from a blue one > which is different from a green one...? > > The thing is, it's not really necessary for case to be distinguished, and > it can make code unreadable if it is adopted. Modula-2, an otherwise beautiful language, enforces case distinction on identifiers (TREE <> TREe). Further, all keywords must be in UPPER CASE. I find this painful and bothersome. Sigh. -- Tony Li ;-) Usc Computer Science Uucp: {sdcrdcf,randvax}!uscvax!tli Csnet: tli@usc-cse.csnet Arpa: tli@usc-ecl
david@ukma.UUCP (David Herron, NPR Lover) (12/21/84)
[ Line eater, Line eater, eat me a line ] [Previous line was a sacrifice to the line eater bug.] [ somebody please tell me if the previous two lines didn't make it through.] [thank you]. >Bill Smith >(ihnp4|pur-ee)!uiucdcs!wsmith >From: wsmith@uiucdcsb.UUCP >Subject: Alternative Structures >Message-ID: <8900018@uiucdcsb.UUCP> >Date: Sat, 15-Dec-84 23:05:00 EST >Ordinary languages like C, Pascal, etc... either make no restrictions >on case of letters in identifiers, make both cases be the same, or they >require you to use only one case. >Is there any reason that case can not be used to contain semantic >information? Probably not. Case is useful for making things stand out. That is semantic information. For a human though, not a computer. Computer doesn't care what case things are in, everythings a number to it. >For example, all identifiers would have to begin with an upper case letter >and the rest of the identifier would be lower case. The language could then >define lowercase prefixes that determine different types so you would use pFoo >for a pointer to a structure named Foo. (typedef struct Foo *pFoo;) All which identifiers. User identifiers or compiler identifiers? The idea of using prefixes here isn't too bad. C already does that. To declare a pointer, you prefix the identifier with "*". To get it's value you prefix it with "*". You have to be able to say that your prefix is better than the prefix already in use. >If Foo had a field of type pFoo that was named Down, (pFoo Down;) >then with these conventions to reference the fourth element from beginning >the varable List (struct Foo *List) and assign the second element to point to >it, this would suffice > pListDown = pListDownDownDown; >or equivalently in C > List->Down = List->Down->Down->Down; >The p prefix is needed to indicate that the pointers are to be assigned and >not the structures themselves. Your notation is getting rather confused here. First, what would tell the compiler that the identifier "ListDown" is different from the structure reference "ListDown"? Or are you restricting us from using uppercase letters in the middle of an identifier? I can see how you are saying that "pListDown" is equivalent to "List->Down". "p" is equivalent to "*", and saying "ListDown" is equivalent to "List.Down". So it converts to "(*List).Down" in C. What I don't see is "pListDownDown" being equal to "List->Down->Down". The conversion makes it "(*List).Down.Down". But, it should convert to "(*(*List).Down).Down" for what you want. And this doesn't have the 'p' --------- applied to it? | | How come this Down has ------ | the 'p' applied to it? | | | | >An alternative notation is v v > pList.Down = pList.Down.Down.Down; >with . also being used as the separator for normal field references. >I am interested in peoples reactions to either of these conventions as opposed >to C's I don't see how this is an improvement over C. C already has an operator which gives you the contents of a pointed to object ("*"). C also has other operators which are useful. What other kind of things are you wanting these prefixes to do? Why can't these things be handled using unary operators? Also the idea of using caps to start all identifiers seems equivalent to the idea in Pascal of capitalizing (or underlining) all keywords. You soon get lost in a sea of capitalized words. When I use a capitalized identifier, it is because I want it to stand out. The Pascal people are saying "Capitalize all identifiers so they stand out". With Pascal this is rather necessary since Pascal programs are so wordy. With C this isn't necessary since the control structures serve to seperate identifiers from keywords already. Ok. So what happens if we say that a capital letter starts all identifiers. We lose the ability to make certain identifiers stand out. That can be an important thing in making a program readable. While we are on the subject of how tokens get seperated visually..... With these prefixes on tokens, the prefix gets lost visually as well. The prefix is this symbol called a letter, our internal English parser knows that letters are the component parts of symbols called words. (My first grade teacher taught me this when I was 6, not using the same words, but with the same meaning). While reading the program, my mind (which is used to reading english text) parses "pList" as a word, albeit with a funny idea of where the capital letters go, but a word just the same. I have to do some mental work to know that pList is actually saying "the contents of List". This mental work slows down my parsing of the expression that pList is a part of, and eventually of the program as a whole. Maybe there is just something here I am not seeing. --:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:- David Herron; ARPA-> "ukma!david"@ANL-MCS (Try the arpa address w/ and w/o the quotes, I have had much trouble with both.) UUCP -:--:--:--:--:--:--:--:--:- (follow one of these routes) {ucbvax,unmvax,boulder,research} ! {anlams,anl-mcs} -----\ vvvvvvvvvvv >-!ukma!david {cbosgd!hasmed,mcvax!qtlon,vax135,mddc} ! qusavx -----/ ^^^^^^^^^^^
arnold@ucsfcgl.UUCP (Ken Arnold%CGL) (12/22/84)
In article <18218@lanl.ARPA> jlg@lanl.ARPA writes: >> Is there any reason that case can not be used to contain semantic >> information? > >The thing is, it's not really necessary for case to be distinguished, and >it can make code unreadable if it is adopted. Many people use entirely upper case names for macros always, and deletion of this would cause problems. And the INGRES project at Berkeley adopted a standard for case that I find very convenient. Global variables start with upper case letters; locals start with lower case letters. So, aside from breaking existing programs, eliminating case distinction also eliminates a useful band to carry semantic information. Ken Arnold
david@ukma.UUCP (David Herron, NPR Lover) (12/22/84)
I have thought over my posting of yesterday. (In response to
wsmith@uiucdcs.uucp giving a suggestion for using prefixes to identifiers
to give them extra powers). I still stand by what I said yesterday,
but want to say something more.
There may have been something in what he was saying. He wasn't
saying it clearly enough such that I could see it.
--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:-
David Herron; ARPA-> "ukma!david"@ANL-MCS
(Try the arpa address w/ and w/o the quotes, I have had much trouble with both.)
UUCP -:--:--:--:--:--:--:--:--:- (follow one of these routes)
{ucbvax,unmvax,boulder,research} ! {anlams,anl-mcs} -----\ vvvvvvvvvvv
>-!ukma!david
{cbosgd!hasmed,mcvax!qtlon,vax135,mddc} ! qusavx -----/ ^^^^^^^^^^^