[bitc-dev] Opinions wanted: Infix shift operators

Jonathan S. Shapiro shap at eros-os.org
Wed Jul 28 12:11:24 PDT 2010

On Wed, Jul 28, 2010 at 8:34 AM, Ian P. Cooke <ipc at srand.net> wrote:
> I consider that approach to be a hack for lazy compiler users (and overzealous compiler creators).

Thanks. :-)

> Therefore your answer should reflect that position and select the
> choice that most effectively communicates your meaning to another
> person, not to the compiler.

Great. By that rule, a space definitely should NOT be required at this
point. It's lexically irregular in the context of this language
family, and it is visually confusing that a space is present where
unexpected. Apparently to the degree that C++ is going to some length
to eliminate the confusion (thanks to Eric for that pointer).

> Other kinds of authors use whitespace to increase the chance
> that a reader will comprehend their meaning,  why shouldn't
> programmers?

White space is not inherently a source of clarity or of confusion. It
is the *use* of whitespace that enhances clarity, and then only when
that use is consistent.

> I'm ... reasonably certain that in the presence of ambiguous text,
> whitespace is the right way to clarify meaning.

In this case, the text actually *isn't* ambiguous. As several people
have noted, the language has expression contexts and type contexts. >>
(right shift) is only accepted in expression contexts, and '>' as type
parameter closing bracket is only accepted in type context. The
ambiguity here is not a human ambiguity. It's purely an artifact of a
particular tokenization strategy.


More information about the bitc-dev mailing list