D - [Suggestion] Alternative switch/case syntax
- Stewart Gordon (60/60) Jan 29 2004 In line with the multiple syntaxes for align and member access keywords,...
- J Anderson (4/62) Jan 29 2004 Oh no, not switch statements again. And this was my idea ;)
- C (5/84) Jan 29 2004 Why do people put thier responses at the bottom :P. All that scrolling
- Matthew (4/91) Jan 29 2004 do
-
Stewart Gordon
(11/13)
Jan 30 2004
- Vathix (2/11) Jan 30 2004 LOL -- that's a good way of putting it.
- Olaf Rogalsky (11/13) Jan 30 2004 I like paragraph 3 best :-)
- Carlos Santander B. (6/9) Jan 30 2004 Very cool! And that program advertised there (oe-quotefix) is really coo...
- Mark T (3/6) Feb 01 2004 yes please snip out all that is not relevent to the reply. We have all l...
- Sadjuuk Kar (4/64) Jan 29 2004 You could create an enhanced extended switch. Then you could have a bas...
- Sadjuuk Kar (4/64) Jan 29 2004 You could create an enhanced extended switch. Then you could have a bas...
- Stephan Wienczny (12/86) Jan 29 2004 I like that idea.
- Matthew (3/89) Jan 29 2004 A parsing nightmare, surely!
- Ilya Minkov (5/6) Jan 29 2004 No, not necessarily. But type ocassionally that extra : as used to from
- kinghajj (20/20) Jan 29 2004 I think it's a great idea! Maybe, instead of 'switch', it should be 'sel...
-
Stewart Gordon
(25/38)
Jan 30 2004
- Matthew (5/65) Jan 29 2004 I think that you've assumed that everyone writes with the egregious K&R
- Andy Friesen (7/11) Jan 29 2004 I think that the switch/case issue comes up way too often, considering
- kinghajj (19/19) Jan 29 2004 I think it's a great idea! Maybe, instead of 'switch', it should be 'sel...
- J Anderson (5/16) Jan 30 2004 Depends what your writing. If your were writing a state machine, then
- Andy Friesen (4/8) Jan 30 2004 I usually use the GoF state pattern to implement FSMs, actually. :) It's...
- LordSyl (7/63) May 19 2004 That is sometimes pretty damn useful, specially the boolean switch "case...
-
Stewart Gordon
(12/29)
May 21 2004
In line with the multiple syntaxes for align and member access keywords,
it would make sense to have this syntax for cases:
switch (qwert) {
case 1 {
yuiop = 3;
}
case 2 {
yuiop = 4;
}
case 3, 4, 5 {
yuiop = 5;
}
}
(Note no colons)
The idea:
- Having the case clauses as block statements seems the logical thing to me.
- Declarations/initialisations local to case clauses - I know you can do
case 1: {
Asdfg hjkl = new Asdfg;
// ...
} break;
but I still think my idea is neater.
- When this syntax is used, there would be no default fall-through - it
would simply execute the block specified by the parameter. Further, it
could be permissible for cases to overlap, in which case (NPI) all would
be executed. Maybe an 'else' could be used to override this, e.g.
switch (qwert) {
case 0, 5, 10 {
// do stuff if qwert is 0, 5 or 10
} else case 1..9 {
/* do stuff if qwert is 1, 2, 3, 4, 6, 7, 8 or 9
* (or should this be semi-inclusive like array
* slicing?)
*/
}
case 6..13 {
/* do stuff if qwert is 6..13, even if a
* previous case matched
*/
}
default {
// this would still mean do stuff if none match
}
}
Nesting could also be allowed, for a bit of syntactic sugar:
switch (qwert) {
case 0..10 {
// do something
case 4 {
// do something more specific
}
// now do something else
}
}
What do you think?
Stewart.
--
My e-mail is valid but not my primary mailbox, aside from its being the
unfortunate victim of intensive mail-bombing at the moment. Please keep
replies on the 'group where everyone may benefit.
Jan 29 2004
Stewart Gordon wrote:
In line with the multiple syntaxes for align and member access
keywords, it would make sense to have this syntax for cases:
switch (qwert) {
case 1 {
yuiop = 3;
}
case 2 {
yuiop = 4;
}
case 3, 4, 5 {
yuiop = 5;
}
}
(Note no colons)
The idea:
- Having the case clauses as block statements seems the logical thing
to me.
- Declarations/initialisations local to case clauses - I know you can do
case 1: {
Asdfg hjkl = new Asdfg;
// ...
} break;
but I still think my idea is neater.
- When this syntax is used, there would be no default fall-through -
it would simply execute the block specified by the parameter.
Further, it could be permissible for cases to overlap, in which case
(NPI) all would be executed. Maybe an 'else' could be used to
override this, e.g.
switch (qwert) {
case 0, 5, 10 {
// do stuff if qwert is 0, 5 or 10
} else case 1..9 {
/* do stuff if qwert is 1, 2, 3, 4, 6, 7, 8 or 9
* (or should this be semi-inclusive like array
* slicing?)
*/
}
case 6..13 {
/* do stuff if qwert is 6..13, even if a
* previous case matched
*/
}
default {
// this would still mean do stuff if none match
}
}
Nesting could also be allowed, for a bit of syntactic sugar:
switch (qwert) {
case 0..10 {
// do something
case 4 {
// do something more specific
}
// now do something else
}
}
What do you think?
Stewart.
Oh no, not switch statements again. And this was my idea ;)
--
-Anderson: http://badmama.com.au/~anderson/
Jan 29 2004
Why do people put thier responses at the bottom :P. All that scrolling makes me dizzy. C "J Anderson" <REMOVEanderson badmama.com.au> wrote in message news:bvb7ip$1umk$2 digitaldaemon.com...Stewart Gordon wrote:In line with the multiple syntaxes for align and member access keywords, it would make sense to have this syntax for cases: switch (qwert) { case 1 { yuiop = 3; } case 2 { yuiop = 4; } case 3, 4, 5 { yuiop = 5; } } (Note no colons) The idea: - Having the case clauses as block statements seems the logical thing to me. - Declarations/initialisations local to case clauses - I know you can do case 1: { Asdfg hjkl = new Asdfg; // ... } break; but I still think my idea is neater. - When this syntax is used, there would be no default fall-through - it would simply execute the block specified by the parameter. Further, it could be permissible for cases to overlap, in which case (NPI) all would be executed. Maybe an 'else' could be used to override this, e.g. switch (qwert) { case 0, 5, 10 { // do stuff if qwert is 0, 5 or 10 } else case 1..9 { /* do stuff if qwert is 1, 2, 3, 4, 6, 7, 8 or 9 * (or should this be semi-inclusive like array * slicing?) */ } case 6..13 { /* do stuff if qwert is 6..13, even if a * previous case matched */ } default { // this would still mean do stuff if none match } } Nesting could also be allowed, for a bit of syntactic sugar: switch (qwert) { case 0..10 { // do something case 4 { // do something more specific } // now do something else } } What do you think? Stewart.Oh no, not switch statements again. And this was my idea ;) -- -Anderson: http://badmama.com.au/~anderson/
Jan 29 2004
"Matthew" <matthew.hat stlsoft.dot.org> "C" <dont respond.com> wrote in message news:bvbp1d$2rji$1 digitaldaemon.com...Why do people put thier responses at the bottom :P. All that scrolling makes me dizzy. C "J Anderson" <REMOVEanderson badmama.com.au> wrote in message news:bvb7ip$1umk$2 digitaldaemon.com...doStewart Gordon wrote:In line with the multiple syntaxes for align and member access keywords, it would make sense to have this syntax for cases: switch (qwert) { case 1 { yuiop = 3; } case 2 { yuiop = 4; } case 3, 4, 5 { yuiop = 5; } } (Note no colons) The idea: - Having the case clauses as block statements seems the logical thing to me. - Declarations/initialisations local to case clauses - I know you canI agree!case 1: { Asdfg hjkl = new Asdfg; // ... } break; but I still think my idea is neater. - When this syntax is used, there would be no default fall-through - it would simply execute the block specified by the parameter. Further, it could be permissible for cases to overlap, in which case (NPI) all would be executed. Maybe an 'else' could be used to override this, e.g. switch (qwert) { case 0, 5, 10 { // do stuff if qwert is 0, 5 or 10 } else case 1..9 { /* do stuff if qwert is 1, 2, 3, 4, 6, 7, 8 or 9 * (or should this be semi-inclusive like array * slicing?) */ } case 6..13 { /* do stuff if qwert is 6..13, even if a * previous case matched */ } default { // this would still mean do stuff if none match } } Nesting could also be allowed, for a bit of syntactic sugar: switch (qwert) { case 0..10 { // do something case 4 { // do something more specific } // now do something else } } What do you think? Stewart.Oh no, not switch statements again. And this was my idea ;) -- -Anderson: http://badmama.com.au/~anderson/
Jan 29 2004
While it was 29/1/04 10:12 pm throughout the UK, C sprinkled little black dots on a white screen, and they fell thus:Why do people put thier responses at the bottom :P. All that scrolling makes me dizzy.<snip top of upside-down reply> Because they're not playing Jeopardy. However, the rest of us still shouldn't have to scroll to see it: http://smjg.port5.com/faqs/usenet/quote.html Stewart. -- My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment. Please keep replies on the 'group where everyone may benefit.
Jan 30 2004
Stewart Gordon wrote:While it was 29/1/04 10:12 pm throughout the UK, C sprinkled little black dots on a white screen, and they fell thus:LOL -- that's a good way of putting it.Why do people put thier responses at the bottom :P. All that scrolling makes me dizzy.<snip top of upside-down reply> Because they're not playing Jeopardy.
Jan 30 2004
Stewart Gordon wrote:However, the rest of us still shouldn't have to scroll to see it: http://smjg.port5.com/faqs/usenet/quote.htmlI like paragraph 3 best :-) Olaf -- +-------------------------------------------------------------------+ I Dr. rer. nat. Olaf Rogalsky Institut fuer Theoretische Physik I I Universitaet Erlangen-Nuernberg I I Tel.: 09131 8528440 Staudtstr. 7 B3 I I Fax.: 09131 8528444 D-91058 Erlangen I | rogalsky theorie1.physik.uni-erlangen.de I +-------------------------------------------------------------------+
Jan 30 2004
Stewart Gordon wrote:Very cool! And that program advertised there (oe-quotefix) is really cool. It even replaces smileys :)! The link doesn't work, but I could dl it from http://home.in.tum.de/~jain/downloads/OEQuoteFix1192.exe. ----------------------- Carlos Santander BernalHowever, the rest of us still shouldn't have to scroll to see it: http://smjg.port5.com/faqs/usenet/quote.html
Jan 30 2004
Stewart Gordon wrote:yes please snip out all that is not relevent to the reply. We have all learned how to cut text by now. thank youHowever, the rest of us still shouldn't have to scroll to see it: http://smjg.port5.com/faqs/usenet/quote.html
Feb 01 2004
You could create an enhanced extended switch. Then you could have a basic
switch for backward compatability and more complex power switch statement
althogh the syntax and name could be slightly different.
In article <bvb6lc$1t7a$1 digitaldaemon.com>, Stewart Gordon says...
In line with the multiple syntaxes for align and member access keywords,
it would make sense to have this syntax for cases:
switch (qwert) {
case 1 {
yuiop = 3;
}
case 2 {
yuiop = 4;
}
case 3, 4, 5 {
yuiop = 5;
}
}
(Note no colons)
The idea:
- Having the case clauses as block statements seems the logical thing to me.
- Declarations/initialisations local to case clauses - I know you can do
case 1: {
Asdfg hjkl = new Asdfg;
// ...
} break;
but I still think my idea is neater.
- When this syntax is used, there would be no default fall-through - it
would simply execute the block specified by the parameter. Further, it
could be permissible for cases to overlap, in which case (NPI) all would
be executed. Maybe an 'else' could be used to override this, e.g.
switch (qwert) {
case 0, 5, 10 {
// do stuff if qwert is 0, 5 or 10
} else case 1..9 {
/* do stuff if qwert is 1, 2, 3, 4, 6, 7, 8 or 9
* (or should this be semi-inclusive like array
* slicing?)
*/
}
case 6..13 {
/* do stuff if qwert is 6..13, even if a
* previous case matched
*/
}
default {
// this would still mean do stuff if none match
}
}
Nesting could also be allowed, for a bit of syntactic sugar:
switch (qwert) {
case 0..10 {
// do something
case 4 {
// do something more specific
}
// now do something else
}
}
What do you think?
Stewart.
--
My e-mail is valid but not my primary mailbox, aside from its being the
unfortunate victim of intensive mail-bombing at the moment. Please keep
replies on the 'group where everyone may benefit.
Jan 29 2004
You could create an enhanced extended switch. Then you could have a basic
switch for backward compatability and more complex power switch statement
althogh the syntax and name could be slightly different.
In article <bvb6lc$1t7a$1 digitaldaemon.com>, Stewart Gordon says...
In line with the multiple syntaxes for align and member access keywords,
it would make sense to have this syntax for cases:
switch (qwert) {
case 1 {
yuiop = 3;
}
case 2 {
yuiop = 4;
}
case 3, 4, 5 {
yuiop = 5;
}
}
(Note no colons)
The idea:
- Having the case clauses as block statements seems the logical thing to me.
- Declarations/initialisations local to case clauses - I know you can do
case 1: {
Asdfg hjkl = new Asdfg;
// ...
} break;
but I still think my idea is neater.
- When this syntax is used, there would be no default fall-through - it
would simply execute the block specified by the parameter. Further, it
could be permissible for cases to overlap, in which case (NPI) all would
be executed. Maybe an 'else' could be used to override this, e.g.
switch (qwert) {
case 0, 5, 10 {
// do stuff if qwert is 0, 5 or 10
} else case 1..9 {
/* do stuff if qwert is 1, 2, 3, 4, 6, 7, 8 or 9
* (or should this be semi-inclusive like array
* slicing?)
*/
}
case 6..13 {
/* do stuff if qwert is 6..13, even if a
* previous case matched
*/
}
default {
// this would still mean do stuff if none match
}
}
Nesting could also be allowed, for a bit of syntactic sugar:
switch (qwert) {
case 0..10 {
// do something
case 4 {
// do something more specific
}
// now do something else
}
}
What do you think?
Stewart.
--
My e-mail is valid but not my primary mailbox, aside from its being the
unfortunate victim of intensive mail-bombing at the moment. Please keep
replies on the 'group where everyone may benefit.
Jan 29 2004
I like that idea.
I would make it an more generic expression instead of an block
then you could write:
switch (qwert)
{
case 1 foo();
case 2
{
foo2();
}
}
Stewart Gordon wrote:
In line with the multiple syntaxes for align and member access keywords,
it would make sense to have this syntax for cases:
switch (qwert) {
case 1 {
yuiop = 3;
}
case 2 {
yuiop = 4;
}
case 3, 4, 5 {
yuiop = 5;
}
}
(Note no colons)
The idea:
- Having the case clauses as block statements seems the logical thing to
me.
- Declarations/initialisations local to case clauses - I know you can do
case 1: {
Asdfg hjkl = new Asdfg;
// ...
} break;
but I still think my idea is neater.
- When this syntax is used, there would be no default fall-through - it
would simply execute the block specified by the parameter. Further, it
could be permissible for cases to overlap, in which case (NPI) all would
be executed. Maybe an 'else' could be used to override this, e.g.
switch (qwert) {
case 0, 5, 10 {
// do stuff if qwert is 0, 5 or 10
} else case 1..9 {
/* do stuff if qwert is 1, 2, 3, 4, 6, 7, 8 or 9
* (or should this be semi-inclusive like array
* slicing?)
*/
}
case 6..13 {
/* do stuff if qwert is 6..13, even if a
* previous case matched
*/
}
default {
// this would still mean do stuff if none match
}
}
Nesting could also be allowed, for a bit of syntactic sugar:
switch (qwert) {
case 0..10 {
// do something
case 4 {
// do something more specific
}
// now do something else
}
}
What do you think?
Stewart.
Jan 29 2004
A parsing nightmare, surely!
"Stephan Wienczny" <wienczny web.de> wrote in message
news:bvbtok$2h7$1 digitaldaemon.com...
I like that idea.
I would make it an more generic expression instead of an block
then you could write:
switch (qwert)
{
case 1 foo();
case 2
{
foo2();
}
}
Stewart Gordon wrote:
In line with the multiple syntaxes for align and member access keywords,
it would make sense to have this syntax for cases:
switch (qwert) {
case 1 {
yuiop = 3;
}
case 2 {
yuiop = 4;
}
case 3, 4, 5 {
yuiop = 5;
}
}
(Note no colons)
The idea:
- Having the case clauses as block statements seems the logical thing to
me.
- Declarations/initialisations local to case clauses - I know you can do
case 1: {
Asdfg hjkl = new Asdfg;
// ...
} break;
but I still think my idea is neater.
- When this syntax is used, there would be no default fall-through - it
would simply execute the block specified by the parameter. Further, it
could be permissible for cases to overlap, in which case (NPI) all would
be executed. Maybe an 'else' could be used to override this, e.g.
switch (qwert) {
case 0, 5, 10 {
// do stuff if qwert is 0, 5 or 10
} else case 1..9 {
/* do stuff if qwert is 1, 2, 3, 4, 6, 7, 8 or 9
* (or should this be semi-inclusive like array
* slicing?)
*/
}
case 6..13 {
/* do stuff if qwert is 6..13, even if a
* previous case matched
*/
}
default {
// this would still mean do stuff if none match
}
}
Nesting could also be allowed, for a bit of syntactic sugar:
switch (qwert) {
case 0..10 {
// do something
case 4 {
// do something more specific
}
// now do something else
}
}
What do you think?
Stewart.
Jan 29 2004
Matthew wrote:A parsing nightmare, surely!No, not necessarily. But type ocassionally that extra : as used to from C and you spoil it - thus this syntax is unstable to use. So i'd be against it. -eye
Jan 29 2004
I think it's a great idea! Maybe, instead of 'switch', it should be 'select'.
programmers! Here's my idead:
select(qwert)
{
where(1) // like 'case 1'
{
// do whatever
}
where(1 .. 3)
{
// do whatever
}
else // like default
{
// do if no 'where's are true
}
}
(If you don't know, I got this syntax *sorta* from SQL)
P.S. Sorry if this double-posts :(
Jan 29 2004
While it was 29/1/04 9:26 pm throughout the UK, Stephan Wienczny
sprinkled little black dots on a white screen, and they fell thus:
I like that idea.
I would make it an more generic expression instead of an block
then you could write:
switch (qwert)
{
case 1 foo();
case 2
{
foo2();
}
}
<snip top of upside-down reply>
Potential ambiguity:
case qwert ++ yuiop;
Maybe with "code has no effect" being an error, that'll be only
syntactic and not semantic ambiguity. But allowing it anyway would
destroy context-free grammar. For that matter, will a property (which
could have a side effect in itself) ever be able to take a ++?
Moreover,
case qwert (&yuiop) (asdfg(hjkl));
could be equivalent to
case qwert(&yuiop) { asdfg(hjkl); }
or
case qwert { yuiop(asdfg(hjkl)); }
which would both make sense if qwert is a property.
Maybe requiring brackets like in F90
case (qwert) ++yuiop;
would work, but still, letting that coexist in the language with the
old-fashioned C syntax would still be a parsing nightmare.
Stewart.
--
My e-mail is valid but not my primary mailbox, aside from its being the
unfortunate victim of intensive mail-bombing at the moment. Please keep
replies on the 'group where everyone may benefit.
Jan 30 2004
I think that you've assumed that everyone writes with the egregious K&R bracing, and that your proposal relies on that for digestibility. "Stewart Gordon" <smjg_1998 yahoo.com> wrote in message news:bvb6lc$1t7a$1 digitaldaemon.com...In line with the multiple syntaxes for align and member access keywords, it would make sense to have this syntax for cases: switch (qwert) { case 1 { yuiop = 3; } case 2 { yuiop = 4; } case 3, 4, 5 { yuiop = 5; } } (Note no colons) The idea: - Having the case clauses as block statements seems the logical thing tome.- Declarations/initialisations local to case clauses - I know you can do case 1: { Asdfg hjkl = new Asdfg; // ... } break; but I still think my idea is neater. - When this syntax is used, there would be no default fall-through - it would simply execute the block specified by the parameter. Further, it could be permissible for cases to overlap, in which case (NPI) all would be executed. Maybe an 'else' could be used to override this, e.g. switch (qwert) { case 0, 5, 10 { // do stuff if qwert is 0, 5 or 10 } else case 1..9 { /* do stuff if qwert is 1, 2, 3, 4, 6, 7, 8 or 9 * (or should this be semi-inclusive like array * slicing?) */ } case 6..13 { /* do stuff if qwert is 6..13, even if a * previous case matched */ } default { // this would still mean do stuff if none match } } Nesting could also be allowed, for a bit of syntactic sugar: switch (qwert) { case 0..10 { // do something case 4 { // do something more specific } // now do something else } } What do you think? Stewart. -- My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment. Please keep replies on the 'group where everyone may benefit.
Jan 29 2004
Stewart Gordon wrote:What do you think? Stewart.I think that the switch/case issue comes up way too often, considering how little use it gets. To date, I have only used D's switch/case to deal with win32-styled message handlers. (maybe I'm atypical in this regard) That having been said, I suppose that means I'm neutral on the matter. ;) -- andy
Jan 29 2004
I think it's a great idea! Maybe, instead of 'switch', it should be 'select'.
programmers! Here's my idead:
select(qwert)
{
where(1) // like 'case 1'
{
// do whatever
}
where(1 .. 3)
{
// do whatever
}
else // like default
{
// do if no 'where's are true
}
}
(If you don't know, I got this syntax *sorta* from SQL)
Jan 29 2004
Andy Friesen wrote:Stewart Gordon wrote:Depends what your writing. If your were writing a state machine, then your view would probably be different. -- -Anderson: http://badmama.com.au/~anderson/What do you think? Stewart.I think that the switch/case issue comes up way too often, considering how little use it gets. To date, I have only used D's switch/case to deal with win32-styled message handlers. (maybe I'm atypical in this regard) That having been said, I suppose that means I'm neutral on the matter. ;) -- andy
Jan 30 2004
J Anderson wrote:Depends what your writing. If your were writing a state machine, then your view would probably be different.I usually use the GoF state pattern to implement FSMs, actually. :) It's much easier to work with. -- andy
Jan 30 2004
In article <bvb6lc$1t7a$1 digitaldaemon.com>, Stewart Gordon says...
In line with the multiple syntaxes for align and member access keywords,
it would make sense to have this syntax for cases:
switch (qwert) {
case 1 {
yuiop = 3;
}
case 2 {
yuiop = 4;
}
case 3, 4, 5 {
yuiop = 5;
}
}
(Note no colons)
The idea:
- Having the case clauses as block statements seems the logical thing to me.
- Declarations/initialisations local to case clauses - I know you can do
case 1: {
Asdfg hjkl = new Asdfg;
// ...
} break;
but I still think my idea is neater.
- When this syntax is used, there would be no default fall-through - it
would simply execute the block specified by the parameter. Further, it
could be permissible for cases to overlap, in which case (NPI) all would
be executed. Maybe an 'else' could be used to override this, e.g.
switch (qwert) {
case 0, 5, 10 {
// do stuff if qwert is 0, 5 or 10
} else case 1..9 {
/* do stuff if qwert is 1, 2, 3, 4, 6, 7, 8 or 9
* (or should this be semi-inclusive like array
* slicing?)
*/
}
case 6..13 {
/* do stuff if qwert is 6..13, even if a
* previous case matched
*/
}
default {
// this would still mean do stuff if none match
}
}
Nesting could also be allowed, for a bit of syntactic sugar:
switch (qwert) {
case 0..10 {
// do something
case 4 {
// do something more specific
}
// now do something else
}
}
What do you think?
Stewart.
That is sometimes pretty damn useful, specially the boolean switch "case (a>b)".
(If there are two different cases which can be "true", just pick up the first
one).
It's a pity things syntactic tricks like that one weren't included in Java at
its time...
D isn't set-in-stone yet, so this could be a neat inclusion :) .
May 19 2004
LordSyl wrote: <snip excessive quote><snip>case 0, 5, 10 { // do stuff if qwert is 0, 5 or 10 } else case 1..9 { /* do stuff if qwert is 1, 2, 3, 4, 6, 7, 8 or 9 * (or should this be semi-inclusive like array * slicing?) */ } case 6..13 { /* do stuff if qwert is 6..13, even if a * previous case matched */ }That is sometimes pretty damn useful, specially the boolean switch "case (a>b)". (If there are two different cases which can be "true", just pick up the first one).<snip> You unnecessarily quoted my whole post, but did you read my whole post? The 'pick up the first one' and 'pick up all' possibilities are perfectly there, just as they are with if. Stewart. -- My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment. Please keep replies on the 'group where everyone may benefit.
May 21 2004