Why is there no or or and ?

[H. S. Teoh]

On Fri, Feb 17, 2012 at 08:44:48AM +0100, F i L wrote:
> 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.

Are you referring to:

	int x = 10;

vs.

	x = 10;

?

In that case I would still prefer :=, since the first can be thought of
as shorthand for "int x; x := 10".


[...]
> 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.

I've always been of the opinion that common things should be shorter to
type, and less common things is OK to be harder to type. So I still
sorta lean towards & and | for logical and/or.


[...]
> >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.

Well, using + for array append leads to all sorts of problems, as you
can see in Javascript:

	[] + [] = ""
	[] + {} = {}
	{} + [] = NaN

OK, this craziness is also the responsibility of JS's implicit
conversion rules, which D doesn't have (fortunately), but overloading +
for both numerical addition and array append is not a good thing.


> >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.

This leads to ambiguity problems if it's unclear whether two adjacent
lines are a single statement or two. It also makes the grammar much
harder to implement in a parser, because it can't easily tell between
the end of a statement and a wrapped line.  Having a statement separator
is a good thing.


[...]
> >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.

More like, they will obviously never be used. :-) We have 4 decades of
historical accidents weighing against us. Still, it's nice to dream
about the ideal language sometimes. :-)

Having said that though, I have to admit that I'm *still* most
comfortable with C-like syntax (and by extension, current D syntax).
It's not perfect, but it's nice and concise and to-the-point, and also
I've grown accustomed to its quirks, so what I wrote was more a nitpick
and a what-my-ideals-are rather than real complaints about the current
syntax.


> 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.
[...]

Wait, you're trying to reimplement D syntax??


T

-- 
Любишь кататься - люби и саночки возить.