[bitc-dev] Opinions wanted: Infix shift operators

[Nathan Tuggy]

  On 2010-07-27 16:35, Jonathan S. Shapiro wrote:
> I promised that I wasn't going to solicit surface syntax opinions. I 
> lied. :-) This one is a question that just about anyone can usefully 
> contribute on, so it will give me a chance to find out how many of you 
> are still actually *reading* this list. :-)
>
> I have provisionally decided to adopt the template-like syntax of C#, 
> where one writes:
>
>    struct S<typevar, typevar>... { ... }
>
> that is: using angle brackets. The reason not to use parenthesis 
> becomes apparent when we look at functions:
>
>   int f('a, 'b)(arg1, arg2) { ... }
>
> we didn't see this case in the S-expression syntax because it's never 
> necessary to add the type variables in a completely inferred language 
> and the S-expression syntax had a way to "lift" the forall into the 
> type. Unfortunately, we're heading in a direction where, in unusual 
> cases, it may become necessary to be explicit about type parameters 
> that do not have associated arguments. I'ld like to choose a syntax 
> that anticipates and allows for that possibility.
>
> As in C# and C++, angle brackets introduce a lexical ambiguity. Given:
>
>   vector<List<'a>>
>
> we currently get the tokens "vector" "<" "List" "<" "'a" ">>". That 
> is: we get right shift rather than the intended two closing angle 
> brackets.

This may have been explained already somewhere in the thread, but what 
is C#'s solution to this?

> There are three possible "fixes" for this:
>
>   1. Adopt the convention used in C++ that you need to put spaces
>      between closing angle brackets when they occur doubled up in
>      this way. I have always hated this convention.

Since it breaks consistency with the whitespace-ignorance of the rest of 
the language, I tend to agree.

>   2. Replace >> and << with some other, similar, lexical symbol.
>       Perhaps >=> and <=<.

To be honest, I actually like this alternative, although it breaks 
look-alike compatibility with C-family languages, which is a significant 
drawback.

>   3. Introduce a parser hack, in which the *expression* parser
>      accepts "a" "<" "<" "b" as a shift operation, but warns
>      if the two "<" symbols are separated by white space.

I'm not sure I understand what you mean here. Isn't the issue with two 
closing brackets lexing the same as a right-shift operator, rather than 
anything directly to do with opening brackets/left-shift?

> Options [2] and [3] both require that we forbid "<<" and ">>" as valid 
> operators.

This confuses me, because later you appear to use "<<" and ">>" as valid 
operators in examples of (presumably) option 3.

> I actually like option [3]. It is undeniably sleazy, but It preserves 
> the syntax that people are accustomed to but removes the parse ambiguity.
>
> However! It admits the following surprise that should be noted:
>
> Normally, << and >> are only done with an integer-ish type on the 
> right. I've been planning to take advantage of this to overload them 
> for I/O in the same way that C++ does. This means that you can write:
>
>    stdout >> e1 >> e2
>
> The << operator is extensible via type classes in the expected way. 
> Note, however, that expressions can be type qualified. So one could see:
>
>   stdout >> e1:list<'a> >> e2
>
> Now that one doesn't look too awful, but now consider:
>
>   stdout >> e1:list<'a>>> e2
>
> Under proposal [3] this will parse correctly, but it introduces real 
> visual confusion. The two "fixes" for the visual confusion are:
>
>   1. Add the space

I would tend to go for this, but I'm a fan of compiler-enforced safety 
perhaps to a larger extent than necessary.

>   2. Require that type qualifications of this form be surrounded by 
> parentheses:
>
>      stdout >> (e1:list<'1>)>>e2
>
>      Note that this requirement is introduced purely for visual 
> readability, and
>      I think it's probably a case of going too far to protect the 
> programmer.
>
> Offhand, I think that the compiler can be made to warn about this case 
> as well. Also, if it matters, this whole situation is something that 
> the pretty printer will handle sensibly.
>
>
> So: my vote is for [3] here, with no compiler-imposed "safety bumpers" 
> on the syntax. Opinions?
>
>
> shap
-- 
Nathan Tuggy, Computer Tech
    nathan at tuggycomputer.com
    +1 (559) 862-1227  (tel)
All email digitally signed.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5148 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.coyotos.org/pipermail/bitc-dev/attachments/20100728/1be4c89b/attachment.bin