chris@umcp-cs.UUCP (07/09/84)
I can live with 6 character names: I'll just run programs I want
to be ``portable'' through another program that finds identifiers
that aren't unique to 6 characters, and replaces them with new
made up ones that are. For example,
int ReplaceString () { ... }
int ReplaceChar () { ... }
would turn into
int _1ReplaceString () { ... }
int _2ReplaceChar () { ... }
Remember, identifiers can be arbitrarily long; it's just that some
of the characters might be ignored.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci (301) 454-7690
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris@marylandstevens@inuxh.UUCP (W Stevens) (07/11/84)
> I can live with 6 character names: I'll just run programs I want > to be ``portable'' through another program that finds identifiers > that aren't unique to 6 characters, and replaces them with new > made up ones that are. For example, > > int ReplaceString () { ... } > int ReplaceChar () { ... } > > would turn into > > int _1ReplaceString () { ... } > int _2ReplaceChar () { ... } Okay. But what if ReplaceString and ReplaceChar are to be placed in a library? How do you guarantee that your special program will generate _1ReplaceString for ReplaceString, and _2ReplaceChar for ReplaceChar, in any program that tries to use these routines (e.g., in a program that includes a function called ReplaceNode)? -- Scott Stevens AT&T Consumer Products Indianapolis, Indiana, USA UUCP: inuxh!stevens
brennan@iuvax.UUCP (07/11/84)
Why not make the filter transparent to the user? Make the standard 32 characters dualcase unique and let the implementations that have sub-standard linkers use a filter to map symbols. Would this make symbolic debugging that much harder?? I don't think so. The Eunice C compiler does exactly this! VMS allows 32 characters, but monocase. And the mapping is not very straightforward. BufNameFree -> BUFNAMEFREE_884000X BufName -> BUFNAMES_090000X (I'll let you figure it on your own.) I don't find this to be a problem when debugging. And you have to do a lot of debugging under Eunice ;-) JD Brennan ...!ihnp4!inuxc!iuvax!brennan (USENET) Brennan@Indiana (CSNET) Brennan.Indiana@CSnet-Relay (ARPA)
guido@mcvax.UUCP (Guido van Rossum) (07/12/84)
There is a rather elegant way to replace long external identifiers by shorter ones: use the C preprocessor. It should be easy to write a program which generates a set of lines to a file "rename.h" like: #define ThisIsAVeryLongName _1ThisIsAVeryLongName #define ThisIsAnother _2ThisIsAnother etc. The advantage is clear: no need to read a program full of cryptical short names. You may also choose your own abbreviations, if this help interpreting debugger or loader diagnostics. It especially works well with the ANSI standard because the preprocessor has to distinguish such long names. Also, it is easy to add this later to any existing program. [This idea was used by James Gosling to get Emacs on a PDP. He even modified the preprocessor to *automatically* #include a file "map.h" in front of every file processed. I wonder if he succeeded, given the size of the code :-)] -- Guido van Rossum, "Stamp Out BASIC" Committee, CWI, Amsterdam guido @ mcvax
chris@umcp-cs.UUCP (07/14/84)
* From: stevens@inuxh.UUCP
Okay. But what if ReplaceString and ReplaceChar are to be placed
in a library? How do you guarantee that your special program will
generate _1ReplaceString for ReplaceString, and _2ReplaceChar for
ReplaceChar, in any program that tries to use these routines
(e.g., in a program that includes a function called ReplaceNode)?
Well, it depends. If the library is part of a package including other
programs, then no problem; I already need to remember symbols across
invocations (well, I don't *have* to but it isn't hard anyway) so there's
simply a file of established translations someplace. If this is a library
that is being submitted for others to use, then you're out of luck; you
just have to come up with shorter names.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci (301) 454-7690
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris@marylandhansen@pegasus.UUCP (Tony L. Hansen) (07/16/84)
> There is a rather elegant way to replace long external identifiers by > shorter ones: use the C preprocessor. It should be easy to write a > program which generates a set of lines to a file "rename.h" like: > > #define ThisIsAVeryLongName _1ThisIsAVeryLongName > #define ThisIsAnother _2ThisIsAnother > etc. > > .... It especially works well with the > ANSI standard because the preprocessor has to distinguish such long > names. .... > > [This idea was used by James Gosling to get Emacs on a PDP. ....] I don't recall in Henry Spencer's summary any mention on the significant character limits on the C preprocessor. Will that remain at the old limit of 8 characters, will it be extended as well to 31 characters, or will it go to an infinite limit as currently allowed by the BSD and S5r2 flexnames implementation? If it stays at 8 characters, then the above-mentioned CPP hack will not work. I ran into this very problem when I tried to use James Gosling's CPP hack to put his Emacs on a System III and System V machine. (I eventually wound up throwing out his CPP hack and did the preprocessing with m4, which has never [that I know of] had a limit on identifier length.) CPP just wasn't capable of differentiationg between AFunctionToDoThis() and AFunctionToDoThat(). Henry, what's the scoop on the length of CPP identifiers? Did I miss something in your original note? Tony Hansen pegasus!hansen
lcc.barry@UCLA-LOCUS.ARPA@sri-unix.UUCP (07/16/84)
From: Barry Gold <lcc.barry@UCLA-LOCUS.ARPA> > > I can live with 6 character names: I'll just run programs I want > > to be ``portable'' through another program that finds identifiers > > that aren't unique to 6 characters, and replaces them with new > > made up ones that are. For example, > > > > int ReplaceString () { ... } > > int ReplaceChar () { ... } > > > > would turn into > > > > int _1ReplaceString () { ... } > > int _2ReplaceChar () { ... } > > Okay. But what if ReplaceString and ReplaceChar are to be placed in a > library? How do you guarantee that your special program will generate > _1ReplaceString for ReplaceString, and _2ReplaceChar for ReplaceChar, in > any program that tries to use these routines (e.g., in a program that > includes a function called ReplaceNode)? There's a very elegant dictionary scheme for this that we used in the Swift project at System Development Corporation. Depending on the degree of interest expressed, I'll either send it to you (Scott Stevens) for summarization or post it to this newsgroup. It may be awhile, though; it'll take several pages to describe adequately and I'm kind of busy on other projects right now. barry gold
henry@utzoo.UUCP (Henry Spencer) (07/17/84)
> Henry, what's the scoop on the length of CPP identifiers? Did I miss > something in your original note? Yup. Here's an excerpt: .............................. Internal names (including pre- processor names) are now significant to 31 characters. ... -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
guido@mcvax.UUCP (Guido van Rossum) (07/17/84)
>From: hansen@pegasus.UUCP (Tony L. Hansen) > >I don't recall in Henry Spencer's summary any mention on the significant >character limits on the C preprocessor. Will that remain at the old limit of >8 characters, will it be extended as well to 31 characters, or will it go to >an infinite limit as currently allowed by the BSD and S5r2 flexnames >implementation? Don't worry. To quote from Henry Spencer's summary: 1. Long identifiers. [...] Internal names (including pre- processor names) are now significant to 31 characters.
jim@ism780b.UUCP (08/01/84)
#R:umcp-cs:-780400:ism780b:25500005:000:410 ism780b!jim Jul 14 11:46:00 1984 > There is a rather elegant way to replace long external identifiers by > shorter ones: use the C preprocessor. It should be easy to write a > program which generates a set of lines to a file "rename.h" like: > > #define ThisIsAVeryLongName _1ThisIsAVeryLongName > #define ThisIsAnother _2ThisIsAnother > etc. I submitted such a program, called shortc.c, to net.sources a while back.