From: David Abrahams (dave_at_[hidden])
Date: 2005-07-16 08:27:02
"Paul Mensonides" <pmenso57_at_[hidden]> writes:
>> it is a nontrivial thing to create a policy that actually works.
>
> In this case it is trivial. Use tabs xor spaces to indent (and only
> to indent).
So, no spaces anywhere else on the line? Try again.
>> We wanted to get about the business of building Boost, and
>> that policy is what we ended up with.
>
> I don't want to get into this argument either. I mention it because
> I think it is a heavy-handed policy. It is a ban on something that
> can cause problems, but doesn't have to cause problems.
Sorta like the design choice we're debating right now?
> For my part, it doesn't matter much because I write preprocessor
> code differently than regular code. I always use spaces to indent
> preprocessor code, but never in my other work. Otherwise it makes
> writing code require an editor capable of treating sequences of some
> number of spaces as tabular indentation.
Your editor can't do that?
>> > My conception of Boost, and the basis for my involvement (for whatever
>> > its worth), is that Boost isn't just about providing tools to get the
>> > job done. It's about providing tools--written the right way--to get
>> > the job done the right way to the greatest extent possible given the
>> > compilers and platforms that we have to deal with.
>>
>> Right. But, people of goodwill and reasonable intelligence
>> can disagree about how to evaluate "the right way." It's not
>> an absolute.
>
> Actually, the right way nearly always *is* an absolute;
I said that *how to evaluate* "the right way" isn't absolute. I
believe that, and as a result people can come to different
conclusions.
> it's just
> that none of us are smart enough to always know what that right way
> is. I generally don't even bother taking sides unless I've given a
> subject a great deal of thought--even if I have an opinion. This is
> one case that I've been thinking about for years. Specifically, the
> root causes of the antipathy for the preprocessor.
Yes, and that is a more important issue to you than to some other
people. A person's system of values will affect how he evaluates "the
right way."
>> > If that isn't part of it, I have no interest in sticking around.
>> > Catering to editors in the face of purity is taking "compilers
>> > and platforms that we have to deal with" to the point of being
>> > asinine.
>>
>> Are you being intentionally insulting?
>
> No, I'm saying what I think. I honestly think it is ridiculous for
> Boost to worry about editor compatibility. We have enough
> difficulty with just compiler compatibility.
It's not the same class of problem at all. For one thing, it's much
less critical: when a compiler is incompatible with some code, the
code simply doesn't work. There's not much to worry about if you've
found a way to do it that's compatible with all known editors and
causes problems for none.
>> Well, I don't view myself as doing either one, FWIW.
>> "Looking like underlying syntax" is not a design criterion for me.
>
> It appears to me that it is (a design criterion for you) by proxy.
No. I'm sorry to be blunt, but "by proxy" or otherwise, it isn't a
design criterion for me. Accessibility and comfort for my users is
the criterion. I don't really care *why* they're more comfortable.
> You've given the argument that "many people think it looks more
> natural",
Yes.
> which is another way of saying "looking like the
> underlying syntax".
I'm not sure of that, but I really don't care.
> If an editor has problems with a construct, then a workaround should
> be applied for that editor (or family of editors), but not globally.
> You can take your macro (which, for the sake of argument, includes
> the semicolon) and wrap it in another macro:
>
> // library code:
>
> #define MACRO(id) struct id { };
>
> // normal client code:
>
> MACRO(xyz)
>
> // client with editor problems library code...
>
> namespace empty { };
>
> #define MACRO_II(id) MACRO(id) using namespace ::empty
>
> // client with editor problems code...
>
> MACRO_II(xyz);
I'm really surprised you'd suggest that. The impurity of that
workaround is enormous compared with that of the workaround that adds
a semicolon when the macro starts without on.
>> >> Don't underestimate how much easier it gets for people to read and
>> >> write code when it's syntactically pleasing.
>> >
>> > If the preprocessor had more of an ability to manipulate syntax or was
>> > part of the syntax (as in Lisp or Scheme), then we could do this.
>>
>> Do what? Are you saying we can't syntactic pleasantness into
>> account because the PP can't manipulate syntax?
>
> I'm saying that we can't make PP syntax as syntactically pleasing as the
> underlying language syntax (e.g. a healthy distribution of operators, keywords,
> etc.). If we could manipulate the syntax, then we could make it that
> syntactically pleasing.
I didn't say we could make it "that syntactically pleasing." I'm
saying syntactic pleasantness counts, and we do have the power to make
choices on that basis in the design of macros.
>> > But it doesn't, and all this does is make it look like the macro
>> > is something that it is not.
>>
>> Still looks like a code-generating macro to me, with or without the
>> semicolon.
>
> I agree, but I also think it looks like a macro that's supposed to
> act as a syntactic entity.
Only if you misjudge the motivations of the author.
-- Dave Abrahams Boost Consulting www.boost-consulting.com