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 -- Любишь кататься - люби и саночки возить.