public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: dewar@gnat.com (Robert Dewar)
To: dewar@gnat.com, kth@srv.net
Cc: gcc@gcc.gnu.org
Subject: Re: c++ "with" keyword
Date: Sun, 05 Jan 2003 00:38:00 -0000	[thread overview]
Message-ID: <20030105003746.4BA41F28C4@nile.gnat.com> (raw)

> So, you are saying that nobody should be able to understand a hardcopy
> printout of code on it's own. They should be required to examine it
> inside of a GUI infested enviornment?

As an old paper reader myself, I will say that it is hard to go back to
paper once you are used to a competent browser.

> Also, the clickie thingie will only work if it can parse the code, but
> if I'm trying to get someone elses code to run on my *other-brand*
> machine, and I have syntax errors, the GUI tools will probably not
> be able to get their info until the syntax errors are gone, but I can't
> get rid of the syntax errors if I can't figure out what the code is
> supposed to do, which requires the tools, which ...

Well again, it depends on the tools. GPS can operate with partial semantic
information just fine. GNAT has an option to force generation of semantic
information to the extent possible even if there are errors, and it works
very nicely in practice in this situation.

But remember that you are talking about your *own* code here. If you are
using a library, and are deathly afraid of having to change your code for
new versions (perhaps because you only read stuff on paper, and indeed
you don't understand the code you are working with), then you may decide
to write in a style without WITH (or its equivalents), or to keep all
variable names very short. But if you are happy to use an environment in
which the very unlikely case of WITH causing trouble could be easily fixed,
then you may find that it is worth using to make your code more readable.

And again, to play broken record, this entire discussion is about an issue
that can perfectly well be left moot (= undecided, arguable), since the
powerful argument against WITH that it is expressively unnecessary since
there are better ways of doing the same thing already. 

The burden for a language change is always severe, you damage a language
by adding a new feature (by making it more complex) so you have to be
super sure that it is buying a gain that is *more* than this cost.

In this case we have a proposed feature WITH that provides minimal gains
at best and in addition has possible negatives. There is no way that the
burden of a new feature is met in this case.

             reply	other threads:[~2003-01-05  0:37 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-05  0:38 Robert Dewar [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-01-06 13:07 Robert Dewar
2003-01-05 18:41 Robert Dewar
2003-01-05 13:03 Robert Dewar
2003-01-05 13:39 ` Toon Moene
2003-01-05 12:56 Robert Dewar
2003-01-06 12:18 ` Andrew Haley
2003-01-05 12:56 Robert Dewar
2003-01-05 18:22 ` Joseph S. Myers
2003-01-05 12:44 Robert Dewar
2003-01-05  3:16 Robert Dewar
2003-01-05  0:29 Robert Dewar
2003-01-05  0:37 ` Kevin Handy
2003-01-04 23:27 Robert Dewar
2003-01-04 23:36 ` Lynn Winebarger
2003-01-05  2:55 ` Gianni Mariani
2003-01-04 22:13 Robert Dewar
2003-01-04 20:59 Robert Dewar
2003-01-04 22:36 ` Gianni Mariani
2003-01-04 20:09 Robert Dewar
2003-01-04 19:36 Robert Dewar
2003-01-04 19:59 ` Tolga Dalman
2003-01-04 19:13 Robert Dewar
2003-01-04 20:58 ` Gianni Mariani
2003-01-04 18:11 Robert Dewar
2003-01-04 18:47 ` Gianni Mariani
2003-01-04 17:52 Robert Dewar
2003-01-04 17:59 ` Gianni Mariani
2003-01-04 17:06 Robert Dewar
2003-01-04 17:22 ` Daniel Berlin
2003-01-05 11:33 ` Andrew Haley
2003-01-05 11:36   ` Toon Moene
2003-01-04 14:29 Robert Dewar
2003-01-04 15:00 ` Momchil Velikov
2003-01-04 15:24   ` Andrew Haley
2003-01-04 16:25     ` Neil Booth
2003-01-04 17:35     ` Gianni Mariani
2003-01-04 17:59       ` Tolga Dalman
2003-01-04 18:36         ` Gianni Mariani
2003-01-04 18:54           ` Tolga Dalman
2003-01-04 23:32         ` Kevin Handy
2002-12-29  8:32 Norman Jonas
2002-12-29 12:46 ` Russ Allbery
2002-12-29  6:49 Erik Schnetter

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=20030105003746.4BA41F28C4@nile.gnat.com \
    --to=dewar@gnat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=kth@srv.net \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).