spir: > They should also let down ';' noise, like Go.
My experience so far has shown me that there are two options: 1) You design the whole language syntax on the fact that most times you don't use semicolons (see Python and Haskell. Or even Delight); 2) You keep the semicolons obligatory (see D). Most of the other options I've seen (JavaScript, Go) are train wrecks :-) > Nice, but introduces syntactic exception for rare cases. I agree. On the other hand it makes the code less noisy and its semantics is clear. So overall I'm weakly against it. > May be good. I think pattern matching was considered for D2 too. It introduces a significant amount of complexity, but it's also powerful (this shows one example: http://rosettacode.org/wiki/Pattern_matching ), expecially if you have algebraic data types. Scala language has a decent implementation of pattern matching, despite it's partiall an object oriented language. > Ditto. A related shortening feature for enums was proposed for D too. > Great! Does this mean non-nullable is the standard case in Archetype? I don't remember, but I presume so. > Great as well! Tuples are very useful. > I'm now shared on this point. Feels great when coding in Pascal or Module, but > do we really miss it? ... even Oberon (of the Pascal line) let this feature > down. They are quite useful. Recently there was a discussion (coming from a type that's limited on the range of month days only) of an implementation in D of a ranged type (so not a built-in). Maybe a library implementation will be good enough, there's no need for lot of syntax here. > Python's comprehension syntax is broken as well: It's less "broken" than every other list comp syntax I've even seen, including Haskell one :-) In my opinion if you change it just a bit, you produce something significantly worse. > # filter alone requires identity function as map! lol! > [x for x in coll if cond] # should be [x in call if cond] Yes, for uniformity, this is not so bad. > # Logically, the following should produce a copy: > [x in coll] # dont work Your logic is broken. > This weirdness, because 'in' is also an operator, so that "x in call" would be > misinterpreted by the parser. To save *one* keyword in the language, python's > designers introduced a broken syntax for comprehensions. Funny, ain't it? Nope, you are mistaken, I think. > Far too ambiguous. And exceptional. It's normal operator overloading, and there is no ambiguity. It has caused me no problems in the little amount of Ruby code I have written. > I want this for D! I am willing to write an enhancement request on this. But first I'd like to know about negative side effects of it. > Thank for the info, You are welcome. Bye, bearophile
