peter@graffiti.UUCP (Peter da Silva) (10/21/85)
Since the current arguments seem to have broken down, how about something new:
what features would you add to 'C' if you were god or some other moral
equivalent of Dennis Ritchie?
Here are some wishes that the recent discussions have woken in me:
1. Extend the syntax of bit-feilds to ordinary numbers:
int x:16; /* x is of type int and at least 16 bits long */
typedef int int16:16; /* :-> */
2. Allow auto aggregate initialisations:
Why not? If you can pass structures this can hardly be
considered horridly inefficient.
3. Allow constant aggregates:
Currently only strings can be used this way, but wouldn't it
be nice to be able to say ioctl(2, TIOCSETC, {...});? Or to
combine execv and execl as exec(name, {args})? BCPL
allowed this, and I miss it.
4. Allow true block structuring:
outs(s) char*s; {
outc(c) char c; {...}
tputs(s, outc);
}
5. Add some real programmability to cpp.
I still haven't been able to write an assert() that satisfies
me... If you allowed '#foo' at other places than the beginning
of lines, and made it evaluate constant expressions. Maybe a #{
and #} instead of using backslash escapes for long lines...peter@graffiti.UUCP (Peter da Silva) (10/23/85)
> > 2. Allow auto aggregate initialisations: > > Already in X3J11. Good. It'd be even better if I could get a copy of X3J11 to look at (hint). > > 3. Allow constant aggregates: > > It's really hard to come up with a complete syntax for this. It's also > of limited (although non-zero) usefulness. So are enums, and they're there. I never understood why they bothered to implement enums (which are more elegant than #defines, admittedly, but don't really add any functionality) and structure assignment and passing (can you say inefficient?) rather than some of the more obvious things missing from 'C' (like function argument type checking... I know that's there now but who's got a compiler that does it?). As for the syntax: I added it to the small 'C' compiler as an exercise, and found it rather easy. Of course I didn't have any data structures to worry about... but... struct foo bar = {....}; /* initialised aggregates */ ... zot = (struct foo *){....}; /* constant aggregate of type struct foo */ And you can generate the same code you use to generate strings. It's a straightforward extension of the current syntax. It makes the language more orthogonal and less surprising. > > 4. Allow true block structuring: [functions within functions] > > Whatever for? As opposed to reasonable non-block structuring as in Modula, > I mean. Because, once again, it's a straightforward extension of current syntax. Never mind. I've already had "Why not" explained to me in great detail. Question: doesn't anyone else have a wish-list of their own? -- Name: Peter da Silva Graphic: `-_-' UUCP: ...!shell!{graffiti,baylor}!peter IAEF: ...!kitty!baylor!peter
henry@utzoo.UUCP (Henry Spencer) (10/23/85)
> 2. Allow auto aggregate initialisations: Already in X3J11. > 3. Allow constant aggregates: It's really hard to come up with a complete syntax for this. It's also of limited (although non-zero) usefulness. > 4. Allow true block structuring: [functions within functions] Whatever for? As opposed to reasonable non-block structuring as in Modula, I mean. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
rcd@opus.UUCP (Dick Dunn) (10/24/85)
> Since the current arguments seem to have broken down, how about something new: > what features would you add to 'C'... > ... > 4. Allow true block structuring: > > outs(s) char*s; { > outc(c) char c; {...} > tputs(s, outc); > } Let's call this "nested procedures" since C has its own sort of block structure. I would be very happy <<never>> to have to deal with nested procedures again. (I have had to deal with them more from the compiler- writer's side than from the user's side.) Nested procedures are neither easy nor cheap (unless done wrong, which happens often enough). They fight particularly with procedure variables, which I consider to be one of C's more useful features (and a moderately serious shortcoming of Pascal). First, what are the advantages of nested procedures? Two main ones: Procedure hiding--Inner procedures are local to the outer one, which keeps them out of the scope of people who shouldn't be using them--but there are better ways to get this protection, and the nesting (contour model) isn't necessarily the best anyway. Access to intermediate variables--the locals of an outer procedure are global to inner procedures. There are more arguments that use of this mechanism leads to hard-to-read code than that it is useful. Second, what are the costs? The major cost is that it is necessary to maintain the static linkage of procedures--a record of which stack frames from outer levels are accessible at inner levels. Either it has to be maintained by updating at each procedure call (which makes procedure calls much more expensive than a jsr or so) or it has to be dug out in order to access intermediate variables. Worse, when you pass a procedure as a parameter, you have to pass the static chain along with it. This means either a reference to static chain information stored somewhere, with beaucoup magic to reference intermediate variables, or you carry the entire static chain with you; procedure objects get large and you have to present an edict on the maximum static nesting of procedures. The worst of it is that <<nested procedures are seldom necessary>> IF a language provides other hiding mechanisms. Simple as it is, C's rule for limiting the scope of static objects to a compilation unit is entirely adequate for this sort of hiding. -- Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086 ...At last it's the real thing...or close enough to pretend.
caag@rlvd.UUCP (Crispin Goswell) (10/25/85)
In article <335@graffiti.UUCP> peter@graffiti.UUCP (Peter da Silva) writes: >what features would you add to 'C' if you were god or some other moral >equivalent of Dennis Ritchie? Are you listening, Dennis Ritchie? > >Here are some wishes that the recent discussions have woken in me: > > 1. Extend the syntax of bit-fields to ordinary numbers > 2. Allow auto aggregate initialisations > 3. Allow constant aggregates > 4. Allow true block structuring > 5. Add some real programmability to cpp. I'm one of those people who think that structs should be first class objects in C. Doing this properly could probably be done fairly easily. I don't think array aggregates could be added and remain in the spirit of the language, because of the intimate relationship between pointers and arrays. This would seem to require a non-linear address space. There is a language called C++ which is a (nearly) upward compatible superset of C, which provides some features that are on my wish list, but few of those you have mentioned. I don't have a reference to hand, but it is fairly well known. My wish list has things to remove from C, so I could not really call the result 'C', in any form. I largely agree with your list, though I'm not sure what 5. refers to. Generics? 1. I'm not a fan of cpp. I believe the features it provides should be part of the language proper. C++ provides constants, and inline functions, which should remove the need for macros. I like these, though the circumstances under which it is possible to use inline functions in C++ are unfortunate, since it is a direct result of the way separate compilation is usually achieved on UNIX. The latter leaves much to be desired. 2. I'm not in favour of #ifdef. I believe that machine specifics should be in separate files, and my programming methodology usually makes this easy to achieve. 3. Make static the default for global values, rather than extern (C++ does this). 4. Remove the default declaration of names to int. This is reminiscent of FORTRAN, and causes many problems. C++ doesn't do this, presumably because it breaks too many programs. There are many things that lint(1) checks which belong in the compiler. C++ does cross-'module' type checking better than C. The ANSI C standard adds checking of function arguments, I'm told. I haven't read it yet. 5. There are various parts of the syntax that I don't like: 1. = for assignment, bring back := 2. ;'s as statement terminators, I prefer the algol statement separator. 3. I don't like anonymous blocks. I like IF ... FI. I think Algol68 got this right. switch is not nice, but neither is Algol68's case. 6. Nameless functions would be useful. It is already possible to pass function pointers around (this business about taking the address of a function needs to be tidied up. Does anyone know what ANSI says about this?). It would be useful to make functions first class objects as well, so that one could have an aggregate of function bodies with no names. There are probably difficulties of scope with this, which may make it impractical for a language like C. 7. C needs modules: either the current method of treating a file as a module needs to be formalised, or some module structure should be added. I'm not sure what is the best answer to this one. 8. There has been much discussion recently about ints, shorts and the like. I hate to say this, but Ada seems to have the right sort of facility. Perhaps it could be simplified so that mortals can use it. Keeping the size of a number range in the abstract is probably good, and people who *know* they want a particular size for a particular dirty application can choose the range which will get them the size they want. There are separate issues regarding the use of shorts and ints: speed vs. space and fixed format data. Speed vs. space should probably be achieved with Compiler directives as it should not affect the semantics of a program. Fixed format data should probably be handled with user defined types created specially for the purpose. I hope it is clear to everyone reading, that I am not suggesting these changes be made to C. They would constitute a new language entirely, which is not sufficiently different to be worth designing at this stage. I am interested in comments however, since I may one day sit down and do this. I'm dissatisfied with C, but C++ doesn't fill some of the gaps I would like filled. Crispin Goswell.
tp@ndm20 (10/25/85)
> 1. Extend the syntax of bit-feilds to ordinary numbers: > > int x:16; /* x is of type int and at least 16 bits long */ > typedef int int16:16; /* :-> */ > Specifying the numeric range would be better (you don't have to do your own conversion to binary, or worry about 1's vs. 2's complement. It also encourages more correct coding. How many of you would code int x:22; rather than int x:32; even if that were the smallest range that would do the job? On my machine (Harris, 24 bit ints, 48 bit longs) you just wasted 3 bytes. > 2. Allow auto aggregate initialisations: > > Why not? If you can pass structures this can hardly be > considered horridly inefficient. Sounds good, but I pity the naive novice that doesn't realize the overhead and uses it indiscriminantly! > 3. Allow constant aggregates: > > Currently only strings can be used this way, but wouldn't it > be nice to be able to say ioctl(2, TIOCSETC, {...});? Or to > combine execv and execl as exec(name, {args})? BCPL > allowed this, and I miss it. Sounds good, but we'd need a syntax that didn't conflict with blocks. Braces are taken. > 4. Allow true block structuring: > > outs(s) char*s; { > outc(c) char c; {...} > tputs(s, outc); > } Maybe, but not that way (I used Pascal for a while. That is one of its misfeatures. Possibly a way to declare that a function definition was neither static nor external, but only visible within another function in the same file that declared it as static. Seems to me, though, that you can accomplish most things you would want this for by making the function static in the file containing only the functions that need it. So what if the other functions in the file can see it? You wrote them too, so you can avoid any problems. > 5. Add some real programmability to cpp. > > I still haven't been able to write an assert() that satisfies > me... If you allowed '#foo' at other places than the beginning > of lines, and made it evaluate constant expressions. Maybe a #{ > and #} instead of using backslash escapes for long lines... Yeah! I want to be able to write a macro that will expand into a something containing conditional compilation, and I would like to be able to get info from the parser (#if constant($1) comes to mind). Those 2 allow macros that optimize on particular constant arguments, which is often possible in some applications. One of my own: How about a good middle exit loop construct? That way I wouldn't have to implement my own and get flamed for it :-) The syntax on this is tricky though, and I don't feel like being flamed about it right now, so I won't bother giving it a shot. Note that while () s; and do s;...;s while() are both special cases of a middle exit loop, and ... no I had better shut up. Terry Poot Nathan D. Maier Consulting Engineers (214)739-4741 Usenet: ...!{allegra|ihnp4}!convex!smu!ndm20!tp CSNET: ndm20!tp@smu ARPA: ndm20!tp%smu@csnet-relay.ARPA
cjl@iuvax.UUCP (10/26/85)
I would like to see a loop-exit statement added to replace the break
statement. For example a loop with multi-exit points should not pretend
to be a "for" loop like :
for (i=0; i<100; i++) {
/* IN NATURAL LANG, THIS MEANS THE LOOP HAS A SIMPLE EXIT POINT,
-- AND WILL ITERATE EXACTLY 100 TIMES. */
checkReturn = function1(x);
if (checkReturn == BAD) break;
/* THE BREAK STATEMENT HERE FUNCTIONS LIKE GOTO AND DESTROYS
-- THE ORIGINAL, SIMPLE MEANING OF FOR STATEMENT. */
......
checkReturn = function5(x);
if (checkReturn == BAD)
result[i] = 0;
else
result[i] = function6(x);
}
With loop-exit statement, the reader is warned explicitly the
existence of multi-exit ( or break) points inside the loop.
i = 0;
loop {
/* WHENEVER WE SEE A LOOP STATEMENT, WE KNOW THERE MAY HAVE
-- SEVERAL EXIT POINTS. IT IS NOT AN EASY LOOP. */
if (i>=100) then exit;
/* NOW YOU DON'T HAVE THE IMPRESSION THAT THE LOOP
-- WILL ALWAYS ITERATE 100 TIMES BECAUSE THERE MAY EXIST
-- OTHER EXIT POINTS. */
checkReturn = function1(x);
if (checkReturn == BAD) exit;
.................
checkReturn = function5(x);
if (checkReturn == BAD)
result[i] = 0;
else
result[i] = function6(x);
i++;
}
This is a style encouraged by Ada or Modula-2 language.
In existing C language, we may use macro definitions to simulate
the loop-exit statement as :
define loop for(,,)
define exit break
C.J.Lo
Dept. of CIS, IUPUI
ARPA : cjl@Indiana@CSNet-Relay
UUCP : ...!iuvax!cjlbrooks@lll-crg.ARpA (Eugene D. Brooks III) (10/27/85)
I would leave the language alone, is it quite adequate for the task of writing good programs. The problem is with some of the programmers. I propose a new standard device driver /dev/cattleprod which the C compiler and lint could open when it detects sloppy code and non portable constructs. The device driver would operate a pair of electrodes that are imbedded in the seat in front of the terminal. The following dosages to be administered for various infractions. Use of "int foo;" in several files instead of "extern int foo;" in a header file and "int foo = 0;" in one file. (10 volts) Failing to check the returned value of system and library calls and use perror() to report the problem. (20 volts) Being sloppy about floats and doubles, and pointers to them. Every machine is like the Vax type of attitude. (10 volts) Not correctly delcaring types and other niceties to keep lint quiet. (10 volts for each warning) This list is endless.... I also recommend a scale factor be applied to the dosages with time so that penalties slowly get more severe. This would hopefully first give hints and then slowly force the progammer into line. PS. The now famous authors of several white books should not be exempt from /dev/cattleprod. Have your ever seen the insides of the "portable" device independent troff? Or even pcc for that matter? I don't exempt myself from /dev/cattleprod either. 1/2 a :-)
chris@umcp-cs.UUCP (Chris Torek) (10/28/85)
You like `loop' statements with `exit' clauses. I have a suggestion for you: Pretend the `for' statement in C is a `loop' statement with the first `exit' clause specified in the middle. Pretend the `break's within the loop are additional `exit' clauses. You now have what you like, *without* using #defines that will cause trouble for other C programmers. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
jdb@mordor.UUCP (John Bruner) (10/28/85)
In article <946@lll-crg.ARpA> brooks@lll-crg.UUCP (Eugene D. Brooks III) writes: >I propose a new standard device driver /dev/cattleprod which the C compiler >and lint could open when it detects sloppy code and non portable constructs. >The device driver would operate a pair of electrodes that are imbedded in the >seat in front of the terminal.... I'd suggest that only the C compiler use "/dev/cattleprod". The use of "lint" to find sloppy/non-portable code shouldn't be discouraged. -- John Bruner (S-1 Project, Lawrence Livermore National Laboratory) MILNET: jdb@mordor [jdb@s1-c.ARPA] (415) 422-0758 UUCP: ...!ucbvax!dual!mordor!jdb ...!seismo!mordor!jdb
franka@mmintl.UUCP (Frank Adams) (10/28/85)
[Not food] In article <895@rlvd.UUCP> caag@rlvd.UUCP (Crispin Goswell) writes: > > 5. There are various parts of the syntax that I don't like: > 2. ;'s as statement terminators, I prefer the algol statement > separator. I disagree; I prefer ;'s as statement terminators. Trying to look at it objectively, I can see very little reason to prefer one or the other. I suspect most people prefer whichever they first dealt with. I am reasonably certain that essentially the same problem occurs either way: leaving them out when they are required, or inserting them when they are illegal. It is unreasonable to ask that there be no further discussion on this point. Let me at least ask that no further replies be made unless you have a reason for preferring one over the other. Frank Adams ihpn4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108
henry@utzoo.UUCP (Henry Spencer) (10/29/85)
> PS. The now famous authors of several white books should not be exempt > from /dev/cattleprod. Have your ever seen the insides of the > "portable" device independent troff? ... Go easy on the dear (?) departed Joe Ossanna. Troff was originally written in pdp11 assembler. If you think the source of troff looks grubby, it's partly because it appears to have been more-or-less mechanically translated from assembler! -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
rlk@chinet.UUCP (Richard L. Klappal) (10/29/85)
[] Reminds me of the cartoon of the programmer's chair with a flyswatter built into the back, and the flat-headed programmer. -- Richard Klappal UUCP: ..!ihnp4!chinet!uklpl!rlk | "Money is truthful. If a man MCIMail: rklappal | speaks of his honor, make him Compuserve: 74106,1021 | pay cash." USPS: 1 S 299 Danby Street | Villa Park IL 60181 | Lazarus Long TEL: (312) 620-4988 | (aka R. Heinlein) -------------------------------------------------------------------------
brooks@lll-crg.ARpA (Eugene D. Brooks III) (10/29/85)
In article <4106@mordor.UUCP> jdb@mordor.UUCP (John Bruner) writes: >I'd suggest that only the C compiler use "/dev/cattleprod". The use >of "lint" to find sloppy/non-portable code shouldn't be discouraged. Agreed, the C compiler should have an extra factor of 10 applied to any corrective actions that would have been warned about in lint.
dgary@ecsvax.UUCP (D Gary Grady) (10/31/85)
> > 5. There are various parts of the syntax that I don't like: > > 2. ;'s as statement terminators, I prefer the algol statement > > separator. > > I disagree; I prefer ;'s as statement terminators. Trying to look at it > objectively, I can see very little reason to prefer one or the other. I have read several places (sorry I can't come up with a specific reference) that beginning programmers seem to have far less trouble with semicolons at the ends of statments than between statements. This is borne out by my own experience teaching novices. I expect the reason is that they view statements as sentences, and we all learn early on that one puts a mark at the end of a sentence. One might argue that we also learn that semicolons separate rather than terminate clauses, but you must understand that the average student hasn't the foggiest notion what a semicolon is for (he observed with well-earned cynicism). -- D Gary Grady Duke U Comp Center, Durham, NC 27706 (919) 684-3695 USENET: {seismo,decvax,ihnp4,akgua,etc.}!mcnc!ecsvax!dgary
tim@ISM780B.UUCP (10/31/85)
/* Written 3:35 pm Oct 28, 1985 by franka@mmintl in ISM780B:net.lang.c */ [ subject is ; as terinator vs. ; as seperator ] It is unreasonable to ask that there be no further discussion on this point. Let me at least ask that no further replies be made unless you have a reason for preferring one over the other. /* End of text from ISM780B:net.lang.c */ Actually, it IS reasonable to ask that there be no further discussion on this point, since even if one finds a reason to prefer ; as a seperator, it is now far beyond the point where one could expect C to be changed.
jbs@mit-eddie.UUCP (Jeff Siegal) (11/01/85)
In article <742@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes: >I disagree; I prefer ;'s as statement terminators. Trying to look at it >objectively, I can see very little reason to prefer one or the other. I >suspect most people prefer whichever they first dealt with. I am reasonably >certain that essentially the same problem occurs either way: leaving them >out when they are required, or inserting them when they are illegal. > Not exactly true. With the statement separator model (Algol, Pascal), one is free on insert or remove semi's at the end of the last statement of a block with both forms being syntactically correct. This does not work with the statement terminator model (C). As in: BEGIN a := a + 1; b := b + 1; END or BEGIN a := a + 1; b := b + 1 END Of course, in the first case, the last statement in the block is really the-null-statement which is between the semi (statement separator) and the END (complex statement terminator). Jeff Siegal - EECS P.S. I like statement terminators better too.
peter@graffiti.UUCP (Peter da Silva) (11/02/85)
> With loop-exit statement, the reader is warned explicitly the > existence of multi-exit ( or break) points inside the loop. OK, make the following changes to your loop to make it 'C'... > > i = 0; for(;;) { > /* WHENEVER WE SEE A LOOP STATEMENT, WE KNOW THERE MAY HAVE > -- SEVERAL EXIT POINTS. IT IS NOT AN EASY LOOP. */ > > if (i>=100) break; > /* NOW YOU DON'T HAVE THE IMPRESSION THAT THE LOOP > -- WILL ALWAYS ITERATE 100 TIMES BECAUSE THERE MAY EXIST > -- OTHER EXIT POINTS. */ > > checkReturn = function1(x); > if (checkReturn == BAD) break; > ................. > checkReturn = function5(x); > if (checkReturn == BAD) { > result[i] = 0; break; } > else > result[i] = function6(x); > i++; > } > This is a style encouraged by Ada or Modula-2 language. > In existing C language, we may use macro definitions to simulate > the loop-exit statement... ...or just use the existing syntax. Why do you need to "simulate" something that's already there? Remember that "exit" already has a meaning to 'C' programmers... -- Name: Peter da Silva Graphic: `-_-' UUCP: ...!shell!{graffiti,baylor}!peter IAEF: ...!kitty!baylor!peter
henry@utzoo.UUCP (Henry Spencer) (11/02/85)
> ... I prefer ;'s as statement terminators. Trying to look at it > objectively, I can see very little reason to prefer one or the other... I can; the limited experiments that have been done on this strongly suggest that semicolons as terminators are rather less error-prone. I conjecture that the basic reason is the two-dimensional structure of programs: a semicolon on the end of each "line" is a consistent rule, but leaving it out on the last line is counter-intuitive. Contrast this with the situation in, say, argument lists, where separators work well because all the structure is on one line and the commas are really perceived as being *between* the individual items. Languages like Pascal and C are specified in terms of one-dimensional token streams, but that is *not* the form in which human beings deal with them. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
franka@mmintl.UUCP (Frank Adams) (11/04/85)
In article <264@mit-eddie.UUCP> jbs@mit-eddie.UUCP (Jeff Siegal) writes: >Not exactly true. With the statement separator model (Algol, Pascal), >one is free on insert or remove semi's at the end of the last statement >of a block with both forms being syntactically correct. This does not >work with the statement terminator model (C). This only works if the language allows null statements. Not all of them do. There are even (broken) Pascal compilers which do not allow it. Also, this is fine for blocks, but not in some other contexts: IF a < b THEN a := a + 1; ELSE b := b + 1; Frank Adams ihpn4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108
henry@utzoo.UUCP (Henry Spencer) (11/05/85)
> > ... It's also of limited (although non-zero) usefulness. > > So are enums, and they're there... Right you are, they're there. They are ALREADY THERE. This is a key distinction. Somewhat silly though they are, they are in the language and in real implementations of it already. This is a strong reason why they should be kept while other mildly interesting notions aren't. Actually, I understand that there was a significant faction within X3J11 that wanted to scrap them anyway. > Because, once again, it's a straightforward extension of current syntax. Many things are straightforward extensions of current syntax. That is not necessarily a virtue. > Question: doesn't anyone else have a wish-list of their own? Yeah, the following: 1. A published C standard standardizing the EXISTING LANGUAGE, that is to say K&R and not much else, with everyone's pet neat ideas LEFT OUT. I class the current X3J11 drafts as only marginally meeting this specification; there has been some creeping featurism. 2. A shift to suggesting neat ideas for C++ (or C++++), leaving C alone as a stable base. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
caag@rlvd.UUCP (Crispin Goswell) (11/07/85)
In article <6107@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >> ... I prefer ;'s as statement terminators. Trying to look at it >> objectively, I can see very little reason to prefer one or the other... > > ... Languages like Pascal and C are specified in terms of >one-dimensional token streams, but that is *not* the form in which human >beings deal with them. Oh? How about: bar fred (a, b) foo a; baz b; { return wop (b, a); } | | Yick! Ick! Ugh! Pascal: | procedure fred (a : foo; b : baz) : bar; begin return wop (b, a) end messy aren't they? in ALOGOL68, you get: PROC fred = (FOO a, BAZ b) bar: wop (b, a) My functions would benefit from being laid out one-dimensionally (I often have lots of small functions). I lay them out two dimensionally in C because they look so bad if I don't. It is unwise to try to out-guess users... Crispin Goswell P.S. I still claim to be a human being :-)