Jarrett Billingsley wrote:
> On Tue, Jul 7, 2009 at 4:15 PM, Andrei Alexandrescu<SeeWebsiteForEmail@erdani.org> wrote:
>> Jarrett Billingsley wrote:
>>> On Tue, Jul 7, 2009 at 3:49 PM, Jarrett Billingsley<jarrett.billingsley@gmail.com> wrote:
>>>> On Tue, Jul 7, 2009 at 3:38 PM, Walter
>>>> Bright<newshound1@digitalmars.com> wrote:
>>>>> Nick Sabalausky wrote:
>>>>>> Someone else said it's also an expression that evaluates to
>>>>>> 3, but that seems beyond useless to me.
>>>>> It's handy when you want to prefix one expression to another,
>>>>> as in:
>>>>> 
>>>>> (foo(), x + 3)
>>>> Cause you want to do that so often, after all.
>>>> 
>>>> *snort*
>>> A more constructive reply: tuuuuples.  TUPLES.  Returning them!
>>> Using them as first-class values!  Yes.
>> Just prepend "tuple" and you're home at a low price.
> 
> I can't return tuples.  I have to wrap them in a struct.

Yes, the struct is called Tuple and is present in std.typecons. There's
also a function called tuple() that returns a Tuple with deduced
parameters. Try it!

> If I do that, then I can't index the struct as if it were a real
> tuple.  Okay, then I use 'alias this', and I end up with this struct
> that exists for no purpose other than to get around a silly
> limitation in the type system.

Alias this has vastly more applications. Tuple has alias this commented
out because there are related bugs in the compiler that I didn't get to.

> Well, geez!  Why not just make tuples first-class?

That would be a fish. We want to learn fishing.


Andrei

Ary Borenszweig wrote:
> Jarrett Billingsley wrote:
>> On Tue, Jul 7, 2009 at 4:15 PM, Andrei
>> Alexandrescu<SeeWebsiteForEmail@erdani.org> wrote:
>>> Jarrett Billingsley wrote:
>>>> On Tue, Jul 7, 2009 at 3:49 PM, Jarrett
>>>> Billingsley<jarrett.billingsley@gmail.com> wrote:
>>>>> On Tue, Jul 7, 2009 at 3:38 PM, Walter Bright<newshound1@digitalmars.com>
>>>>> wrote:
>>>>>> Nick Sabalausky wrote:
>>>>>>>  Someone else said it's also an expression
>>>>>>> that evaluates to 3, but that seems beyond useless to me.
>>>>>> It's handy when you want to prefix one expression to another, as in:
>>>>>>
>>>>>>  (foo(), x + 3)
>>>>> Cause you want to do that so often, after all.
>>>>>
>>>>> *snort*
>>>> A more constructive reply: tuuuuples.  TUPLES.  Returning them!  Using
>>>> them as first-class values!  Yes.
>>> Just prepend "tuple" and you're home at a low price.
>>
>> I can't return tuples.  I have to wrap them in a struct.  If I do
>> that, then I can't index the struct as if it were a real tuple.  Okay,
>> then I use 'alias this', and I end up with this struct that exists for
>> no purpose other than to get around a silly limitation in the type
>> system.  Well, geez!  Why not just make tuples first-class?
> 
> Yeah, really. The TupleType already exists in the compiler, but just can't be expressed and passed around in the language.

It can be expressed, just not as a literal. Use TypeTuple. (By the way there's some confusion in this discussion about Tuple vs. TypeTuple.)

Andrei

Leandro Lucarella Wrote:

> Can you at least use:
> case X:
> ..
> case Y:
> 
> in the examples/documentation/specs? I think most case X: .. case Y: haters found that format pretty acceptable

I like that syntax too, but not a good idea to use in the Digital Mars code samples, because another one with an extra dot is already being used to mean "omitted lines of code":

case X:
...
case Y:

Ali

On Tue, 07 Jul 2009 10:50:08 -0700, Walter Bright wrote:

> I like:
> 
>     a .. b+1
> 
> to mean inclusive range.

LOL, now that *is* funny.

And I like the Euphoria language's version ...

   case X to Y

but so what, eh?

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

Per: NG D
Soggetto: Re: Case Range Statement ..

Andrei Alexandrescu Wrote:
> That would be a fish. We want to learn fishing.

Tuples (as the tuples of Python, but represented with a different literal syntax, please) can be useful in really many situations, so hard-coding them in a language can be acceptable (that's why D has built-in dynamic arrays and associative arrays, for example).

Currently the tuples (the Record/record of my dlibs) of Phobos doesn't support "necessary" usages like:

for x,y in [(1,2), (3,4)]: ...
x, y, z = (1, 2, 3)
Or even, from Python 3+:
x, y, *z = (1, 2, 3, 4)

So it's a matter of balance, sometimes you need the flexibility (to learn fishing) and sometimes a handy and hard-coded solution is fine (because you need to eat a bowl of rice every day). You can add some built-in "defaults" too, with a nice short syntax for the programmer and a semantic that allows the compiler to digest them well (because very general features are often more hard for the compiler to compile them well, and require a more complex compiler. If you want a simple example, in D even foreach() is slower than for() when compiled with DMD, so I usually avoid foreach in the inner loops).

Regarding the "learn fishing", for example recently I have discussed about adding an OpBool to structs and classes, to allow to use if(x) when x is a BigInt (in the meantime I have found C# has such thing, even if they allow to define both true() and false(), I don't know why). There are other similar things that can be done in such regard.

Too much hard-coding leads to languages like Java, and too much flexibility leads to languages like Lisp where you can do anything, and where essentially every programmer does thigns in a different way, and this leads to the mess that's now Lisp. Python is less flexible than Lisp, you can't metaprogram it much, and both the semantic, the syntax and even the way people write source code is hard-coded and standard, the result is that today you can find a Python module to do anything, because re-using modules written by other people is easy, and it's easy to understand what's inside such modules. Here too you can see that's it's better to find a compromise between having a fish and learning fishing.

Bye,
bearophile

On Tue, 07 Jul 2009 12:38:49 -0700, Walter Bright wrote:

> Nick Sabalausky wrote:
>>  Someone else said it's also an expression
>> that evaluates to 3, but that seems beyond useless to me.
> 
> It's handy when you want to prefix one expression to another, as in:
> 
>     (foo(), x + 3)

I took what Nick said to mean that expressions in the form

   ( integerA , integerB )

were useless as they always evaluate to integerB, so why bother to code them as expressions. Whereas such an expression *in* the context of a case clause could be made to mean that an inclusive range was being requested by the coder.

Walter's example, using a function call, could be useful as the function can have side-effects that influence the next sub-expression "x + 3".

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

On Wed, 8 Jul 2009 07:48:07 +1000, Derek Parnell wrote:

> On Tue, 07 Jul 2009 10:50:08 -0700, Walter Bright wrote:
> 
>> I like:
>> 
>>     a .. b+1
>> 
>> to mean inclusive range.
> 
> LOL, now that *is* funny.
> 
> And I like the Euphoria language's version ...
> 
>    case X to Y
> 
> but so what, eh?

OMG! ... having read the rest of the posts I see that you were serious.

Sorry, didn't mean to show disrespect; I really thought it was a joke.

Are you honestly suggesting that the sequence of

  Expression ".." Expression "+1"

be recognized by the tokenizer as meaning Inclusive-End-Range?

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

On Tue, 07 Jul 2009 14:47:06 -0500, Andrei Alexandrescu wrote:

> The .name syntax and the number. syntax are confusing. Using "..." as a separator multiplies confusion by a billion.


A "billion" - really? And yet I'm not confused by it, so does that make me very clever or very stupid ... hmmmm?

By the way, I don't like triple-dot either, but just making a point.

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

"Walter Bright" <newshound1@digitalmars.com> wrote in message news:h30845$2kla$2@digitalmars.com...
> bearophile wrote:
>> Walter Bright Wrote:
>>> I like:
>>>     a .. b+1
>>> to mean inclusive range.
>>
>> Me too, but does it work when the upper interval is int.max, char.max, ulong.max, ucent.max, etc?
>
> Nope. Wrap around is always a special case, not just for ranges. It's in the nature of 2's complement arithmetic.

Suppose, hypothetically, that we did have a "right-inclusive-range" token. At the moment I don't give a rat's ass what it actually is, '...', '..#', 'poopiesOnAFlyingStick', whatever. Now, as has been pointed out far to many times by now to still not get:

a .. int.max+1   // wraparound breaks it
a right_inclusive_range_tok int.max    // works fine, wraparound isn't even
relevant.

And another problem people have already pointed out numerous times with making "a .. b+1" the inclusive range syntax:

double a=1, b=5;
// Let's make an inclusive range from 1.0 to 5.0!
a .. b+1
// Oh look! 5.5f is in the range! It didn't f*^* work!

And yet another:
float a=1, b=somethingReallyLarge;
assert(b+1 == b);
// Let's make an inclusive range!
a .. b+1
// Oh look! b is missing from the range! It didn't f*^* work again!

"a .. b+1" as *the* inclusive range is just plain broken. There is no "Yea, but...!" that can change that.

And while I'm ranting, why in the world is anyone defending the continued existance of "5." and ".5"? "Because it's already there and it basically still works and isn't hurting anyone." Well it seems to be hurting the adoption of an inclusive range that actually works. I thougt the point of D was to clean up useless cruft like that, even if it still works (header files) to make way for better approaches.

"Walter Bright" <newshound1@digitalmars.com> wrote in message news:h3088a$2kla$3@digitalmars.com...
> Nick Sabalausky wrote:
>>  Someone else said it's also an expression
>> that evaluates to 3, but that seems beyond useless to me.
>
> It's handy when you want to prefix one expression to another, as in:
>
>    (foo(), x + 3)
>

I guess I'm not familiar with that syntax. What does that do and for what purpose?