May 24, 2005
"G.Vidal" <gyvidal@wanadoo.fr> wrote in message news:pan.2005.05.24.20.09.54.952681@wanadoo.fr...
>
>> There are _so_ many languages that have tupls build in with exactly the
>> same
>> syntax, so what is "crazy" about it?
>
> What I meant by "crazy" is "totally different from the C/C++/C#/Java syntaxes"
>
> I'm just tired of seeing so many ideas from so many people and finally there's no response from the D compiler programmer.

"D compiler programmer" aka Walter?
One can hack on gdc but that would require knowledge about how gdc works. If
it can be implemented in the front-end then poking around in the dmd
front-end source can be illuminating, too.

> So what are we suppose to think ? He reads them and is still thinking about it, reads and thinks the idea is bad, or maybe he doesn't read them at all, how can we know ?

It can get frustrating, I know. Walter's Jedi mind tricks don't work through the newsreader :-P

> If he doesn't agree with the idea, we don't even know why. Maybe there should be more programmers for D.

Suggesting changes is easy. Implementing them is hard. Deciding what to
implement and what not to implement is impossible.
Maybe Walter will consider this for 1.0. Maybe he'll consider it for 2.0.
Maybe he'll do it for 0.126. Who knows... My guess would be it belongs in
the post 1.0 bucket.


May 24, 2005
> What I meant by "crazy" is "totally different from the C/C++/C#/Java
> syntaxes"

I agree.  Why not return a box[] or:

struct
{
   TypeInfo[] types;
   void* values;
}

Or something, instead?  Having this:

(a, b, c) = func(1, 2, 3);

Really looks like Perl to me, and thus ugly.  I would say that it'd need some sort of keyword to look C-like:

list (a, b, c) = func(1, 2, 3);

But even that looks strange.

> I'm just tired of seeing so many ideas from so many people and finally
> there's no response from the D compiler programmer.
> 
> So what are we suppose to think ? He reads them and is still thinking
> about it, reads and thinks the idea is bad, or maybe he doesn't read them
> at all, how can we know ?
> 
> If he doesn't agree with the idea, we don't even know why. Maybe there should be more programmers for D.

Well, Walter isn't superman.  Neither am I or you.  We can't be everywhere at once or read everything at once.  And it's not like his life is D or anything, either.

But, it seems to me he reads more than you might expect.  And, in the long run... you want things changed or commented on now... but I find, at least myself, that if you give things time to simmer out, the best solution will present itself much more cleanly.

Maybe Walter just doesn't want to get involved because he doesn't have the time or because he wants to watch what people come up with.

Or, maybe he just doesn't like it and isn't going to waste his time reading this thread.

-[Unknown]
May 24, 2005
Unknown W. Brackets wrote:
>> What I meant by "crazy" is "totally different from the C/C++/C#/Java
>> syntaxes"
> 
> 
> I agree.  Why not return a box[] or:

I don't agree. Wouldn't returning box[] impose too much runtime overhead ?


> Or something, instead?  Having this:
> 
> (a, b, c) = func(1, 2, 3);
> 
> Really looks like Perl to me, and thus ugly.  I would say that it'd need some sort of keyword to look C-like:

It looks perfectly clear to me ( maybe because my mind hasn't been spoiled by Perl ;) )


> list (a, b, c) = func(1, 2, 3);
> 
> But even that looks strange.

Confusing. Looks like assigning the result of one function call to the result of another. For someone with a C++ background this might look like depending on some weird side effects of the assignment or even worse tricks :o


-- 
Tomasz Stachowiak  /+ a.k.a. h3r3tic +/
May 25, 2005
G.Vidal wrote:
> i Like: 
> 
> (int,double) func (int param) {
> 	......
> 	......
> 	return (a,b);
> }
> 
> 
> int a;
> double b;
> 
> (a,b) = func(0);
> 
> 
> 
> This is possible to implement, I'm sure.
> 
> Unfortunately, I doubt Walter would consider it. He doesn't seem
> interested by such dramatically "new" ideas.
> 
> I regret that. There should be an "unofficial" DMD version reserved for
> implementing crazy things like that and test.
> 

Hmmm ..

Looks like a struct to me.

C-like Code:
-------------------------
struct { int a, double b } func (..)
{
...
return { 4, 3.0 };
}

struct { int a; double b; } x;
x = func(...)
-------------------------

I'm not sure if that's valid C code.

This is just a "struct" with syntactic sugar, nothing new at all. Remove the "struct" keyword, and use some ( ) instead of { }.

Oh, and this is not the case with goto's and while loops, because the while loop is not merely a syntactic sugar for goto.


Anyway, I don't really like the original idea anyway.
May 25, 2005
In article <pan.2005.05.24.20.09.54.952681@wanadoo.fr>, G.Vidal says...
>
>
>> There are _so_ many languages that have tupls build in with exactly the same syntax, so what is "crazy" about it?
>
>What I meant by "crazy" is "totally different from the C/C++/C#/Java syntaxes"


C++ TR1 includes a proposal for tuples (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1403.pdf) but with slightly more awkward syntax...:


tuple<int,int,double> foo add_multiply_divide(int a, int b) {
return make_tuple(a+b, a*b, double(a)/double(b));
}

/*...*/

int a,b;
double d;
tie(a,b,d) = add_multply_divide(3,7);

So there is definitely reason to believe that tuples and multiple return values will become a standardised practise in C++.


May 25, 2005
Oh no, another "it looks like X and X is ugly"..

What does "if (x is y)" look like? Or "int* b = c in hash;" ? "templ!(int)" ?

L.


May 25, 2005
On Wed, 25 May 2005 01:06:02 -0600, Hasan Aljudy wrote:

> G.Vidal wrote:
>> i Like:
>> 
>> (int,double) func (int param) {
>> 	......
>> 	......
>> 	return (a,b);
>> }
>> 
>> 
>> int a;
>> double b;
>> 
>> (a,b) = func(0);
>> 
>> 
>> 
>> This is possible to implement, I'm sure.
>> 
>> Unfortunately, I doubt Walter would consider it. He doesn't seem interested by such dramatically "new" ideas.
>> 
>> I regret that. There should be an "unofficial" DMD version reserved for implementing crazy things like that and test.
>> 
> 
> Hmmm ..
> 
> Looks like a struct to me.

It doesn't have to be though.

  (Foo.a, Bar.b) = func( x );

In other words, the receiving variables do not have to be located in the same aggregate item.

It is syntactic sugar for ...

  struct Temp
  {
     int a;
     double b;
  }

  Temp r;
  Temp func (int param) {
       Temp x;
  	......
 	......
        x.a = a;
        x.b = b;
 	return x;
  }
  r = func( x );
  Foo.a = r.a;
  Bar.b = r.b;

But because the 'struct' is defined and created by the compiler as a transient item, it saves the coder from having to do the menial task.

-- 
Derek Parnell
Melbourne, Australia
25/05/2005 6:46:58 PM
May 25, 2005
> What does "if (x is y)" look like?

Horrible, yes.  I prefer ===, as much as blind people who insist upon using crappy fonts may disagree.


> Or "int* b = c in hash;" ?

In that case, there aren't that many other options.  The in keyword in this case makes sense to me.  At least it's not:

if (x eq y)
if (x ne y)
if (x gt y)

And so forth.  Boy I hated those.

> "templ!(int)" ?

Kinda funky, but it's a syntax.  The point is, this:

(x, y) = func();

Is somewhat ambiguous, especially with the way C and D already handle commas.  I'd actually support this:

[x, y] = func();

Or even:

<x, y> = func();

Much more than with parenthesis.  The parenthesis mean expression to me, at which point it makes absolutely no sense to assign to it.  This is how C is.

If you don't understand what I mean, compile this:

	int a, b;

	(a, b) = 1;
	writefln(a, " ", b);

It should output:

0 1

-[Unknown]
May 25, 2005
G.Vidal wrote:

>>There are _so_ many languages that have tupls build in with exactly the same
>>syntax, so what is "crazy" about it?
> 
> 
> What I meant by "crazy" is "totally different from the C/C++/C#/Java
> syntaxes"
> 
> I'm just tired of seeing so many ideas from so many people and finally
> there's no response from the D compiler programmer.
> 
> So what are we suppose to think ? He reads them and is still thinking
> about it, reads and thinks the idea is bad, or maybe he doesn't read them
> at all, how can we know ?
> 
> If he doesn't agree with the idea, we don't even know why. Maybe there should be more programmers for D.
>  
> 
> 
I for one am very glad Walter does not take a 'knee jerk' reaction to good ideas.  He rightly weighs each idea on how it fits with the language's capabilities and its purpose(A systems language similar to C++/Java but better :) ).

Slapping feature on top of feature is one reason C++ has been described as 'an octopus created by taping four legs on a dog'.

-DavidM
May 26, 2005
"Regan Heath" <regan@netwin.co.nz> wrote in message news:opsq64r6tt23k2f5@nrage.netwin.co.nz...
> On Fri, 20 May 2005 02:15:10 -0500, TechnoZeus <TechnoZeus@PeoplePC.com> wrote:
>
> >
> "TechnoZeus" <TechnoZeus@PeoplePC.com> wrote in message news:d6k32d$d6r$1@digitaldaemon.com...
> > "Regan Heath" <regan@netwin.co.nz> wrote in message news:opsq1tkott23k2f5@nrage.netwin.co.nz...
> >
> > Now, I would have espected it to choose long over float
> > since long anf int are both integer types and float is not...
> > however, I would say that if this ambiguity of passed parameters
> > would cause a compile-time error, then the same ambiguity when applied to
> > a choice of overloaded functions based on return types should also cause
> > a compile-time error... for consistancy.
> >
> > TZ
> >
>
> Agreed. Where ppl seem to disagree is what the soln for that would be :)
>
> Regan
>
>

The solution, I would think, would be to be consistant.

Lionello Lunesu made a suggestion that return values could be thought of
and treated as additional arguments.  In that sense, there is no need to
determine any special rules for implicit casting specific to return values.
just treat them the same as you would any other argument... including the
ability to have zero or more of them (rather than always one) and the ability
to overload a function based on different combinations of parameters.
The problem would be, as I see it, in getting the compiler implementation to
know what all of the return parameters are so that it could treat them as
a special set of additional parameters.  So far, this is done by declaring a
function type, and having the return parameter match that type. For multiple
or zero return parameters an alternative or extended syntax would be needed.

One possibility would be to introduce the "function" keyword to declare a typeless function.
This would allow such a function to act as any type that it is capable of returning.
The problem with this is that if the end of the function is reached and the correct type is not yet returned,
a run-time error would be in order.

Another possibility would be to allow type declaration to be a list of type returned, and return them all.
Since with a single return type we are allowed the option of not using it, I would think that with this possibility
we should have the option of leaving any of the returned types unused.
The problem here is what typeof.this would represent.  My first thought is that it should be treated as a set of types,
and that any assignment of that set could be to a set with matching types or any subset thereof.

TZ