On Friday, 17 February 2012 at 06:25:49 UTC, H. S. Teoh wrote:
On Fri, Feb 17, 2012 at 06:47:20AM +0100, F i L wrote:
I would use them over '||' and '&&' for the reasons bearophile
gave.
Highlighted as keywords, they're easily set appart, easier to
type,
and more distinguished... then again if I had my way I'd
remove the
'('/')' brackets, ending marks, and auto keyword; switched the
definition name-type placement and change
if/else/return/contract
syntax...
Well, if you're going to reinvent the language syntax, I'd like
to
replace:
= with :=
== with =
I would agree with this, only there should be a distinction
between assignment and declaration. Which in my syntax is ':'.
Maybe the keyword 'is' could apply to runtime conditions.. might
go nicely with the 'not' statement.
These two are the most annoying syntax inherited from C,
IMNSHO. I mean,
mathematically speaking, = is equality, not assignment.
Traditionally :=
has been used for assignment; so why mix them up? Besides, what
on earth
is == anyway? Equal-equal? It makes no sense. And even worse,
languages
like Javascript that copied C's lousy choice of equality
operator made
it worse by introducing ===, which is both nonsensical in
appearance and
semantically a symptom of language maldesign.
Next on the list is, of course:
&& with and (or perhaps &)
|| with or (or perhaps even |)
The symbol '&' is commonly used to mean 'and', such as "John &
Wiley's".
So why the && stutter? Bitwise operations aren't used very much
anyway,
so they shouldn't be hogging single-character operators. Let
bitwise AND
be &&, and I'd be OK with that. But C has gotten it the wrong
way round.
Similarly '|' *has* been used traditionally to separate
alternatives,
such as in BNF notation, so there's no reason for that silly ||
stutter.
Bitwise OR isn't used very often anyway, so if anything, |
should be
logial OR, and I suppose it's OK for || to be bitwise OR. Again
C has it
the wrong way round.
Agreed. Though '|' is used to accumulate bit flags, but I guess
"flag1 || flag2 || etc" isn't so bad. Especially since, as you
said, these situations aren't uses nearly as much as conditional
OR. Still, I think the best would be to simply use keyword and/or
and leave &/| as bitwise operations.
But more importantly:
^^ with ^
^ with something else altogether
I mean, c'mon. Everybody knows ^ means superscript, that is,
exponentiation. So why waste such a convenient symbol on
bitwise XOR,
which is only rarely used anyway?! It should simply be called
'xor' at
best. Nobody who hasn't learned C (or its derivatives) knows
what '^'
means (in C) anyway.
And then:
! with not
Everyone knows ! means exclamation mark, or factorial. Having
it also
mean logical NOT is just needlessly confusing. What's wrong
with 'not'?
Or, since we have Unicode, what about ¬? Much clearer.
As for bitwise NOT, '~' is about the most counterintuitive
symbol for
such a thing. My presumptuous guess is that Kernighan ran out
of symbols
on the keyboard for operators, so he resorted to ~. The symbol
'~'
should've been reserved for an "approximately equal" operator,
useful in
comparing floating-point numbers (which as we know usually
shouldn't be
compared with equality due to roundoff errors), like this:
if (a ~ b) { ... }
rather than today's baroque dance of:
if (fabs(b-a) < EPSILON) { ... }
Yep! Though, I like D's '~' as append operator for arrays. Though
I i'm not sure this wouldn't work better:
a, b: [1, 2, 3, 4, 5]
a += b[2] // appends b[0] to a
a[] += b[2] // adds b[0]'s value to all of a
Seeing as how your right, '~' means "about" in math.
And what about:
. with : or ;
OK. The symbol '.' is supposed to be used for the end of a
sentence. At
least, so we were told in grade school. In the case of
programming, it
should denote the end of a statement. So why is it that ';' is
used to
end statements, and '.' to access struct/class members? It
seems so
bass-ackwards. A semicolon (or a colon) is much more suitable
for what
amounts to a name composed of parts (module:object:property),
because
they signify partial stop, implying there's more to come. The
period (or
full-stop for you brits) '.' should be used to *end*
statements, not to
*continue* a multi-part name.
I don't think lines need ending marks at all. So, seeing as how
':' takes two key presses and '.' only takes one, I'd opt to keep
that as the default member-access operator.
But who am I to speak out against more than four decades of
historical
accidents, right? I think I'll shut up now.
Nothing wrong with being creative ;-) Even if we know these
changes will most likely never be used. I've been experimenting
with LLVM to write a proof-of-concept for Tuple syntax, language
State-objects, and a modularized compiler designed to be also be
an IDE parser. Just a simple test obviously, but I'm using these
syntax concepts. Thanks for the input.
