On 24/11/2010 12:35 AM, Peter Hull wrote:
I would go for #1. But, this is a bit horrible
auto x = { auto t = 11; if (foo()) { t = 10; }; t; };
Could it be written as
auto x;
if (foo()) { x = 10; } else {x = 11; }
or would the 'auto' type determination run into problems?
No, that would work fine. And it is definitely the road I went down
during the first ... several years of this project! I have argued
strenuously in favour of sticking to a statement-heavy approach in the
past. Partly this email thread is to serve as a record to myself and
others reading why there's even a change-of-plan happening here. To make
sure "hallway conversations" (and their IRC equivalents) don't disappear
from the records.
Where this strategy runs into acute difficulty is in contexts I
mentioned near the beginning of the email: initializing a (compile-time)
constant via a conditional, or returning a conditional from a syntax
extension used in an expression context. In those cases you have to have
at least "block as expr" to nest statement-sequences into blocks. And
"conditional as expr" follows easily due to not wanting to have to
simulate state-evolution in your constant-folding device.
Particularly when it comes to constants -- and those are really
important, you actually wind up having a lot of compile-time-constant
data in a static language, think "most literals" -- it feels more
natural to only talk about constant expressions rather than constant
statements-with-side-effects.
(Attentive readers will note that in rustboot there is presently a
"cexp" language floating outside the main grammar which handles just
such pure, constant, scalar-typed expressions, including conditional
forms for alt and if, and interprets them in a little micro-interpreter
in the frontend during crate construction. We want to get rid of cexp
and just define it as a subset of the normal expression grammar. Too
many similar-looking grammars will confuse users.)
None of these issues *doom* the statement-centric approach, but they
make it increasingly unnatural-feeling inside the compiler. Combine with
the fact that *users* are really quite fond of a fair number of
larger-than-a-primitive-statement expression forms, so you're already
parsing such things and then "desugaring" them (which itself messes up
error reporting by the compiler), and it gets to be a convincing
argument: the statement fixation is awkward for (many) users *and* for
the implementers. Who's it good for? Increasingly, I found myself unable
to answer that question. Possibly editor modes?
This is not to say that the visible structure of the grammar, or most
programs, is likely to change a lot. It will *permit* a more
nested-expressions form, but it won't actually read well if you over-do
it; particularly since block-local declarations end in a semi, and our
conditional and loop forms are braced, these are natural places to put
linebreaks. So most of the block-containing expressions will read best
arranged as a sequence of lines, not mushed into a nested expression
context. I'm also a bit concerned about how easy it'll be to convince
editor modes to handle this change, but I'm willing to give it a try. If
editor modes are the last issue, it ... feels like a solvable problem.
I imagine that 'if' and 'alt' are the most useful statements to have
as expressions, so would it be possible to add the C ternary ?:
operator, and something similar for alt?
It would be possible, but I get a little tingle about "doing the wrong
thing" when considering adding expression forms that perfectly mirror
statement forms. The ternary operator is Not The Most Popular Idea from
C. Besides which, it implies control flow; it doesn't actually evaluate
both arms. So we'd be desugaring it anyway, the way we desugar && and ||
in rustboot. See above wrt. "awkward for all parties".
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
