Andrei Alexandrescu, el  6 de julio a las 10:44 me escribiste:
> >>And what did those people use when they wanted to express a range of case labels? In other words, where did those people turn their heads towards?
> >They probably used an if.
> 
> So they used an inferior means to start with.

Yes, but when you try to make people move to a different language, you have to do considerably better. When I have to choose between something well know, well supported and mature and something that is, at least, unknown (even if it's mature and well supported, I won't know that until I use it a lot so is a risk), I want to be really good, not just barely good.

Details as this one are not deal breaker on their own, but when they are a lot, it tends to make the language look ugly as a whole.

What bugs me the most is there are a lot of new constructs in the language that are plain ugly, from the start. D is buying it's own baggage (__traits, enum for manifest constants, now the case range, and I'm sure I'm forgetting something else) with no reason...

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------

Leandro Lucarella pisze:
> Andrei Alexandrescu, el  6 de julio a las 10:44 me escribiste:
>>>> And what did those people use when they wanted to express a range of case labels? In other words, where did those people turn their heads towards?
>>> They probably used an if.
>> So they used an inferior means to start with.
> 
> Yes, but when you try to make people move to a different language, you
> have to do considerably better. When I have to choose between something
> well know, well supported and mature and something that is, at least,
> unknown (even if it's mature and well supported, I won't know that until
> I use it a lot so is a risk), I want to be really good, not just barely
> good.
> 
> Details as this one are not deal breaker on their own, but when they are
> a lot, it tends to make the language look ugly as a whole.
> 
> What bugs me the most is there are a lot of new constructs in the language
> that are plain ugly, from the start. D is buying it's own baggage
> (__traits, enum for manifest constants, now the case range, and I'm sure
> I'm forgetting something else) with no reason...
> 

...
* foreach_reverse
* access to variadic function parameters with _argptr & _arguments
* mess with compile time is expression (sorry, that's my favorite ugliness :-] )

I believe that this issues are greatly underestimated by D language designers...

BR
Marcin Kuszczak
(aarti_pl)

Leandro Lucarella wrote:
> Andrei Alexandrescu, el  6 de julio a las 10:44 me escribiste:
>>>> And what did those people use when they wanted to express a range of case labels? In other words, where did those people turn their heads towards?
>>> They probably used an if.
>> So they used an inferior means to start with.
> 
> Yes, but when you try to make people move to a different language, you
> have to do considerably better. When I have to choose between something
> well know, well supported and mature and something that is, at least,
> unknown (even if it's mature and well supported, I won't know that until
> I use it a lot so is a risk), I want to be really good, not just barely
> good.

That goes without saying.

> Details as this one are not deal breaker on their own, but when they are
> a lot, it tends to make the language look ugly as a whole.

You are just saying it's ugly. I don't think it's ugly. Walter doesn't think it's ugly. Other people don't think it's ugly. Many of the people who said it's ugly actually came up with proposals that are arguably ugly, hopelessly confusing, or both. Look at only some of the rehashed proposals of today: the genial "case [0 .. 10]:" which is horribly inconsistent, and the awesome "case 0: ... case 10:", also inconsistent (and gratuitously so) because ellipses today only end lists without having something to their right. The authors claim those are better than the current syntax, and one even claimed "beauty", completely ignoring the utter lack of consistency with the rest of the language. I don't claim expertise in language design, so I wish there were a few good experts in this group.

> What bugs me the most is there are a lot of new constructs in the language
> that are plain ugly, from the start. D is buying it's own baggage
> (__traits, enum for manifest constants, now the case range, and I'm sure
> I'm forgetting something else) with no reason...

I agree there are ugly constructs in D, and is-expressions would near the top of the list (particularly the absolutely awful is(T : T[])), but you have no case (heh) with the switch statement.


Andrei

> You are just saying it's ugly. I don't think it's ugly. Walter doesn't think it's ugly. Other people don't think it's ugly. Many of the people who said it's ugly actually came up with proposals that are arguably ugly, hopelessly confusing, or both. Look at only some of the rehashed proposals of today: the genial "case [0 .. 10]:" which is horribly inconsistent, and the awesome "case 0: ... case 10:", also inconsistent (and gratuitously so) because ellipses today only end lists without having something to their right. The authors claim those are better than the current syntax, and one even claimed "beauty", completely ignoring the utter lack of consistency with the rest of the language. I don't 

I oriented this on the syntax of array slices. Which work that way. Not inconsistent at all. It's also consistent with foreach(_; x..y).

Other than that, I realize it's not that good of a choice and it's not elegant at all. But I think it's still better than some of your horrible language crimes (including yours) that are being forced into D.

In any way, I think we should completely redesign the switch statement and give it a different syntax. No more C compatibility. No more Duff's device. We can keep the "old" switch statement for that.

> In any way, I think we should completely redesign the switch statement and give it a different syntax. No more C compatibility. No more Duff's device. We can keep the "old" switch statement for that.

PS: we could add awesome stuff like pattern matching to this, which would make D much more functional language like, which seems to be the new cool thing to do. We can also omit case labels completely, which will reduce repeated typing of keywords.

On Mon, 06 Jul 2009 14:42:12 -0500, Andrei Alexandrescu wrote:

> Well, I think I'd call that aggravation.

Ok, if we do not have to bend to the C winds, then the default would be to have switch NOT fall through. That way we do not have to code "break;" at all. Is that aggravation?

And then for those rare times when a falling through is required, recycle the "goto" or any other existing key word - (I hear that "static" is always available) - to affect a fall through behaviour.

Anyhow, sorry to have been a nuisance again.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

grauzone wrote:
> I oriented this on the syntax of array slices. Which work that way. Not inconsistent at all. It's also consistent with foreach(_; x..y).

It would look consistent, but it would behave very differently. x..y for foreach and slices is exclusive of the y, while case x..y is inclusive.

Creating such an inconsistency would sentence programmers to forever thinking "which way is it this time".

To avoid such confusion an obviously different syntax is required.

grauzone wrote:
>> You are just saying it's ugly. I don't think it's ugly. Walter doesn't think it's ugly. Other people don't think it's ugly. Many of the people who said it's ugly actually came up with proposals that are arguably ugly, hopelessly confusing, or both. Look at only some of the rehashed proposals of today: the genial "case [0 .. 10]:" which is horribly inconsistent, and the awesome "case 0: ... case 10:", also inconsistent (and gratuitously so) because ellipses today only end lists without having something to their right. The authors claim those are better than the current syntax, and one even claimed "beauty", completely ignoring the utter lack of consistency with the rest of the language. I don't 
> 
> I oriented this on the syntax of array slices. Which work that way.

No, it works differently because the slice is open to the right, whereas with switch one seldom wants to specify an open range.

> Not inconsistent at all. It's also consistent with foreach(_; x..y).

No, it isn't consistent. It's a lose-lose proposition. If you want to make it consistent you'd need to have ['a' .. 'z'] exclude the 'z'. That would confuse people who expect ['a' .. 'z'] to contain 'z'. On the other hand, if you choose to include 'z' you will confuse people who expect behavior to be similar with that in arrays.

Going with a syntax that uses ".." just as punctuation but otherwise firmly departs from the slice notation eliminates expectation of semantic similarity. And the presence of the second "case" firmly clarifies that the last label is to be included in the range, even to the first-time reader. There would be seldom a need to check the manual for that.

> Other than that, I realize it's not that good of a choice and it's not elegant at all. But I think it's still better than some of your horrible language crimes (including yours) that are being forced into D.

Thanks for emphasizing twice that it's about me. Yep, they're my horrible language crimes - and those definitely include mine :o). I genuinely appreciate the honesty, and to reciprocate, I don't think very highly of your competence either (as every other post of yours makes some technical mistake), and I find your attitude corrosive.


Andrei

"Walter Bright" <newshound1@digitalmars.com> wrote in message news:h2u735$sn8$1@digitalmars.com...
> grauzone wrote:
>> I oriented this on the syntax of array slices. Which work that way. Not inconsistent at all. It's also consistent with foreach(_; x..y).
>
> It would look consistent, but it would behave very differently. x..y for foreach and slices is exclusive of the y, while case x..y is inclusive.
>

The current way has that inconsistency:

variable .. variable   // exclusive end
caseLabel .. caseLabel    // inclusive end

And yes, I know that's not how it's actually parsed, but that's how people visually parse it.

Ah the hell with it, I don't care any more: The *real* issue here is that the current switch, being based on C's, is horribly antiquated and what we really need is a comprehensive redesign incorporating some sort of generalized pattern matching. Like "case > 1, <= 10:" or something like Nemerle, or whatever. I don't care, as long as it doesn't continue to get trivialized as something that can be solved by tossing in a recycled ".." here, a recycled "final" there, etc.

> Thanks for emphasizing twice that it's about me. Yep, they're my horrible language crimes - and those definitely include mine :o). I genuinely appreciate the honesty, and to reciprocate, I don't think very highly of your competence either (as every other post of yours makes some technical mistake), and I find your attitude corrosive.

It was a typo, I meant to diss you only once. There are plenty of language crimes not caused by you, as well as good features which were proposed by you. I hope this makes you happy.