Missed opportunities

Posted Jun 10, 2013 13:35 UTC (Mon) by renox (guest, #23785)
In reply to: Missed opportunities by tjc
Parent article: Little things that matter in language design

> most notably with type casts

Which have an AWFUL notation in C-like language: let's make a very *dangerous* operation non-greppable, yeah fun!

That said, your issue isn't too difficult to fix when you realize that a cast is in fact a two parameters operation: the type name and the object, so this syntax fix your issue I think: cast(T@,p)
or better(?) in C++ like notation cast<T@>(p)

IMHO this is a better way to solve the issue..

to post comments

Missed opportunities

Posted Jun 10, 2013 16:06 UTC (Mon) by tjc (guest, #137) [Link] (6 responses)

Thanks for the suggestions.

What I like about: cast(T@,p):

The operator is outfix with respect to its operands, so there is no precedence problem with the indirection operator, or any other pre- or postfix unary operator.
It's "greppable," as you say.

I don't like the "angle brackets" in the second form, since these lexemes are already commonly overloaded as operators: <, <=, <<, etc.

And I'm not crazy about the comma in the first form. It makes it look like a function call, but a cast is not much like a function call. A function call has operands that are at the same lexical level, but a cast has one operand that acts on the other. I think the syntax should reflect this difference in semantics. ':' might be a better separator.

One alternative is cast(p T@), since 'p' is an identifier and never contains spaces. It reads nicely too: "cast p to whatever." If the first operand is a complex expression, then things get messy again, and extra parenthesis are required. But at least the common case is clean. There's always something. :)

Missed opportunities

Posted Jun 10, 2013 22:05 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (5 responses)

> cast(T@,p)

Not to mention that if T is something like std::map<K, T>, the comma is ambiguous. Related, GCC bug #35 (or so) where this is a parse error:

> void foo(std::map<std::string, int> const& map = std::map<std::string, int>())

because "int>()" is not a valid parameter declaration. You need parentheses (or a typedef) to get GCC to accept it.

Missed opportunities

Posted Jun 14, 2013 10:53 UTC (Fri) by pjm (guest, #2080) [Link] (4 responses)

Does anyone here know how the unparsable but more mathematically conventional < > angle brackets won out in C++ over, say, [ ], as in vector[int] ? Cf PolyJ, one of the early Java extensions for template parameters, and its FAQ entry on this issue: http://www.pmg.csail.mit.edu/polyj/comparison.html#angle . I thought it a shame that in the end Java too opted for unparsable < >.

Missed opportunities

Posted Jun 14, 2013 11:59 UTC (Fri) by mpr22 (subscriber, #60784) [Link] (3 responses)

Regardless of whether [] would be easier for the machine to parse, the decision to allow values (rather than just types) as template parameters means that [] would make life harder for humans trying to parse the code.

Missed opportunities

Posted Jun 16, 2013 3:20 UTC (Sun) by tjc (guest, #137) [Link] (2 responses)

Why is that?

Missed opportunities

Posted Jun 16, 2013 3:31 UTC (Sun) by hummassa (guest, #307) [Link] (1 responses)

because you couldn't know by glancing if

a[3]

is an array dereferencing or a template instantiation.

Missed opportunities

Posted Jun 16, 2013 12:19 UTC (Sun) by pjm (guest, #2080) [Link]

Can you expand on that? So far I'm not convinced:

It seems no worse than the fact that one can't tell whether ‘a’ by itself is a variable or a type (or a macro), or that one can't tell whether or not ‘a[3]’ involves a function call without knowing the type of a.
As has been discussed in this thread, angle brackets cause their own share of difficulty and "embarassment" (in the word of the later proposal for introducing even more parsing complexity to avoid the need for a space in ‘set<set<int> >’).