A Discussion of Tuple Syntax

John Colvin john.loughran.colvin at gmail.com
Mon Aug 19 10:30:27 PDT 2013


On Monday, 19 August 2013 at 16:53:06 UTC, Wyatt wrote:
> Note: I'm leading off with a reply to bearophile transplanted 
> here to stop making OT noise in John's thread about TypeTuple.
>
> On Friday, 16 August 2013 at 23:23:59 UTC, bearophile wrote:
>>
>> It's short, clear, has a precedent with q{}.
>
> Wait, what is q{}?  That's something in D?  What does that even 
> do?  I can infer that q{} is probably some manner of scoping or 
> grouping _something_ somehow, but I have to dig into lexical 
> and manually search for q{ to find out it's [neither of the 
> things I expected].  In my view, this right here is really just 
> a fundamental problem with single-character prefixes and I feel 
> that's something we should endeavour to avoid, if possible.
>
>> I don't like it a lot, but it's way better than not having
>> language support for tuples.
>>
> On this, I think we all agree.
>
>>> I'd prefer just using parentheses, but I think there were 
>>> readability problems that caused the DIP to end up with:
>>
>> More than just readability problems. They were discussed when 
>> Kenji presented the DIP 32 in this forum. Timon found a 
>> significant problem with the {} syntax.
>>
> To be clear, I'm not talking about braces, {}; I'm talking 
> about parentheses, ().  I read over that whole DIP32 thread a 
> couple times, and didn't see any rationale offered for why the 
> likely "cleanest" version "can't be used".  It wasn't even 
> brought up (unless I've missed something subtle).  In the 
> second thread, linked in the OP here, they were glossed over 
> again.  Now, I fully believe there's a very good reason that's 
> been written somewhere, but I _would_ like to know what that 
> is, preferably documented somewhere less ephemeral and 
> difficult to search than the newsgroup (such as in DIP32).  The 
> closest I've seen so far is the pull request where Walter and 
> Andrei expressed that it should be considered further.
>
> On Friday, 16 August 2013 at 21:07:52 UTC, Meta wrote:
>> - #(a, b) is unambiguous and would probably be the easiest 
>> option. I don't think it looks too bad, but some people might 
>> find it ugly and noisy
>>
> The octothorpe _is_ much better than the t simply in terms of 
> readability, though, even more than q{} or t{}, I have concerns 
> about its ability to be found with an ordinary search engine by 
> an ordinary user.  Have you tried looking for documentation on 
> weird operators with a search engine lately?  They don't 
> exactly take to it well. :/ (cf. Perl's <=>)
>

All we have left from the standard keyboard layout as far as 
single keys go is # and ¬
I don't think the mathematics crowd would be too happy with ¬ not 
meaning not.

The only op() options I can think of that aren't ambiguous:
$(a, b)
%(a, b)
^(a, b)
&(a, b) //I like this one
:(a, b)
#(a, b)
'(a, b) //I think....
/(a, b)
\(a, b)
>(a, b)
<(a, b)
|(a, b)
¬(a, b) //not in std ascii
?(a, b)

however, most of those are binary operators too, so it could be 
quite accident prone and confusing to look at

Some of this could be helped by enforcing at least 1 ','.

e.g.

   &(3)   //illegal
   &(3,)  //legal

There is precedent for this in python.


More information about the Digitalmars-d mailing list