Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: david carlton <carlton@math.stanford.edu>
To: Andrew Cagney <ac131313@ges.redhat.com>
Cc: Daniel Jacobowitz <drow@mvista.com>,
	Tom Tromey <tromey@redhat.com>,
	gdb-patches@sources.redhat.com
Cc: carlton@math.stanford.edu
Subject: Re: RFA: >, >>, and "tee" operators
Date: Wed, 31 Jul 2002 09:36:00 -0000	[thread overview]
Message-ID: <15688.4371.193070.843000@jackfruit.Stanford.EDU> (raw)
In-Reply-To: <3D4758A5.8050605@ges.redhat.com>

On Tue, 30 Jul 2002 23:25:25 -0400, Andrew Cagney
<ac131313@ges.redhat.com> said:

>> So in other words, I'd like to stick with 
>> 
>>> >  redirect [-a[ppend]] FILE [COMMAND]
>>> >  log [-a[ppend]] FILE [COMMAND]

> Don't forget that prefix `-' and `--' are valid C operators.  You
> can't tell the difference between the above and a valid C
> expressions.  I think that rules `-...' out.

It makes '-...' undesirable, but I don't think it rules it out.  Yes,
there are situations where what had previously been a legitimate print
statement now becomes either a syntax error or, worse yet, remains
legitimate but with a different meaning.  But I doubt they are all
_that_ common, and there is an easy workaround once you're aware of
this problem, namely enclosing your expression in parentheses.

The reason why I don't think they're all that common is that I don't
think that it's all that common to want to print the value of an
expression starting with a unary minus.  I don't think I'd do that
very frequently in everyday interactive use: even if the value that I
happen to care about is -something, I'd probably just do 'p something'
and negate the answer mentally.  I find it easier to imagine printing
an expression that begins with a unary minus if that print command is
run automatically when hitting a breakpoint, but even there I doubt it
would be too uncommon.

And, furthermore, it only breaks code where the next character after
the unary - is one of the formatting symbols and the character after
that is whitespace.  (So the fact that '--' is a valid C operator
isn't so relevant, because '-' isn't a formatting character.  Good
thing, too, because I print expressions starting with '--' more often
than ones starting just with '-'.)  Unfortunately, some of the
formatting symbols are common variable names - probably '-x' would be
the most common clash - but even so I'm sure that, the vast majority
of the time an expression starts with a unary minus, the unary minus
is unambiguously part of the expression.

And it seems to me that it isn't so big a problem when previously
valid print statements become syntax errors: in those situations, the
user at least is aware that something's wrong, and can insert
parentheses to solve the problem.  Situations where previously valid
print statements remain valid but have their meaning changed are more
problematic; but those are even more rare.  Sure, there are some
examples - 'p -x - 3' is one (though 'p -x-3' isn't, or 'p (-x) - 3')
- but they're not at all common.

So I think that, if this syntax is changed, the fact that expressions
could start with unary minus signs is going to cause much less
grumbling from users than the fact that, once the old p/x syntax gets
obsoleted, they'll have to convert over to typing p -x instead.

David Carlton
carlton@math.stanford.edu


  parent reply	other threads:[~2002-07-31 16:32 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-23 11:51 Daniel Jacobowitz
2002-07-23 12:23 ` Tom Tromey
2002-07-23 13:18   ` Daniel Jacobowitz
2002-07-23 13:20     ` Tom Tromey
2002-07-23 13:58       ` Daniel Jacobowitz
2002-07-24 20:10         ` Andrew Cagney
2002-07-24 20:14           ` Daniel Jacobowitz
2002-07-25  9:17             ` Andrew Cagney
2002-07-25 10:36               ` Daniel Jacobowitz
2002-07-25 10:46                 ` Andrew Cagney
2002-07-30 13:00                   ` Daniel Jacobowitz
2002-07-30 20:36                     ` Andrew Cagney
2002-07-30 20:51                       ` Daniel Jacobowitz
2002-07-30 20:58                         ` Andrew Cagney
2002-07-30 22:45                           ` Daniel Jacobowitz
2002-07-31  9:36                       ` david carlton [this message]
2002-07-31  9:39                         ` Daniel Jacobowitz
2002-08-01  8:05                           ` Andrew Cagney
2002-08-01 10:24                             ` david carlton
2002-08-01 12:03                               ` Daniel Jacobowitz
2002-08-01 12:16                                 ` david carlton
2002-08-13 15:20             ` Fernando Nasser
2002-07-23 14:23       ` Grant Edwards
2002-07-24  1:59 ` Eli Zaretskii
2002-07-24 19:01 ` Andrew Cagney
2002-07-24 22:15   ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=15688.4371.193070.843000@jackfruit.Stanford.EDU \
    --to=carlton@math.stanford.edu \
    --cc=ac131313@ges.redhat.com \
    --cc=drow@mvista.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=tromey@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox