On Wed, 8 Jun 2005 13:05:15 +0000 (UTC), James Dunne wrote:


[snip]

>>
>>What problem is this trying to solve?
> 
> We always view changes as trying to solve problems ... interesting.  Sometimes I just like to go against the flow of current and try something different, just for change's sake.  Some people say, "If it ain't broke, don't fix it."  Well, I'd be one to say "It is broke, so I am fixing it"; but to some it just doesn't *look* broke.

Another way of looking at this sort of change is that it involves a cost. Is that cost justified? One way of working that out is to see if it is solving a problem that is already costing us so as to reduce that.

>>I'll take a guess at a couple...
>>
>>(A) Making it clearer to a reader looking at a call statement as to which parameters are being modified by the called function.
>>
>>(B) Making the visual appearance of function declarations tidier and thus
>>cheaper to maintain.
>>
> 
> You certainly nailed the two problems I was trying to solve here!

Lucky guess ;-)

>>> Opinions?
>>
>>Using some general principles (large changes to the language's syntax should be minimised, D syntax should retain the flavour of the C family, syntax changes must benefit people using the language, syntax changes must not overly complicate the compiler).
>>
> 
> That's not a sentence, but I get your parenthesized meaning ;).

The final period was meant to be an ellipsis.

>  I was more
> throwing the idea out there because I'm working on my own pet language (ask me
> about it sometime - here is not the place).

You have talking pets !?!? :D

>>I think that problem (A) could also be solved by allowing the 'out' specifier on a standard function call.
>>
>>e.g.
>>
>>  a = myfunction(4, out x, out y);
>>
> 
> Hmm, that could get a bit ugly when your function parameters are numerous.  But you're right - it certainly would be clear where the inputs and outputs lie.

Beauty is in the eye of the beholder...;-)

I suggested this because it is very simple to implement and does not change
the syntax in any dramatic manner.

>>This could also be used for inout arguments as well.
>>
>>Problem (B) is, in essence, a style issue. It could be said that
>>
>>  (int x, real y, float[] a) myfunction (int b)
>>
>>is easier or harder to read than
>>
>>  float[] a myfunction (int b, out int x, out real y)
>>
>>depending on the way individuals see things.
>>
> 
> Exactly.  I think that in order to progress we must disobey the Bob of Backwards Compatibility every now and then.  You can't serve two masters.

Oh! I didn't realize you were asking to replace the current syntax with your alternative. That would break *so* much existing code it could create enemies ;-)

>>However, one difference between the two syntaxes is that the current method *requires* that the return value is mandatory but it is not a requirement that the 'out' arguments are updated. The proposed method implies that none of the 'return' values are mandatory, and this is a fundamental idiom shift.
>>
> 
> I noticed this as well.  Doesn't it seem odd that forgetting to set the value of "out" arguments is allowed?  It seems to me that they are outputs, and not input-outputs, and should be set at all times.  Returning an output argument value with its default type initializer just doesn't seem to have much of a point to me. (Unless Exceptions are thrown, but let's not get into that - they're exceptional)

To repeat: one of your proposals makes all 'return' values optional.

>>> Concerns?
>>
>>I suspect that this would be a medium change in the syntax rules and it is a definite step away from the C family syntax. I can see that the problem (A) is one that is justifiably addressed though a simpler way might be better.
> 
> Do you have a "simpler way" suggestion?  As I said before, I'm working on my own pet language, so any insight you've got could be helpful to me.

For D, only the one I've already mentioned.

However, for a totally new/different language then returning tuples seems a nice idea. The only sugar needed would be some syntax to indicate that you are accepting a pseudo tuple.

The simple case would be something like ...

  tuple A;
  A = myfunction(4);

but a pseudo tuple might be needed if updating elements currently belonging to disparate variables...

  int A;
  real B;
  string C;
  { A, B, C } = myfunction(4);


But back to D, eh?

-- 
Derek Parnell
Melbourne, Australia
8/06/2005 11:33:07 PM

In article <ip8as8je57ds$.jwl7zh79xait.dlg@40tude.net>, Derek Parnell says...
>
>On Wed, 8 Jun 2005 13:05:15 +0000 (UTC), James Dunne wrote:
>
>
>[snip]
>
>>>
>>>What problem is this trying to solve?
>> 
>> We always view changes as trying to solve problems ... interesting.  Sometimes I just like to go against the flow of current and try something different, just for change's sake.  Some people say, "If it ain't broke, don't fix it."  Well, I'd be one to say "It is broke, so I am fixing it"; but to some it just doesn't *look* broke.
>
>Another way of looking at this sort of change is that it involves a cost. Is that cost justified? One way of working that out is to see if it is solving a problem that is already costing us so as to reduce that.
>
>>>I'll take a guess at a couple...
>>>
>>>(A) Making it clearer to a reader looking at a call statement as to which parameters are being modified by the called function.
>>>
>>>(B) Making the visual appearance of function declarations tidier and thus
>>>cheaper to maintain.
>>>
>> 
>> You certainly nailed the two problems I was trying to solve here!
>
>Lucky guess ;-)
>
>>>> Opinions?
>>>
>>>Using some general principles (large changes to the language's syntax should be minimised, D syntax should retain the flavour of the C family, syntax changes must benefit people using the language, syntax changes must not overly complicate the compiler).
>>>
>> 
>> That's not a sentence, but I get your parenthesized meaning ;).
>
>The final period was meant to be an ellipsis.
>
>>  I was more
>> throwing the idea out there because I'm working on my own pet language (ask me
>> about it sometime - here is not the place).
>
>You have talking pets !?!? :D
>

African Grey parrots do

>>>I think that problem (A) could also be solved by allowing the 'out' specifier on a standard function call.
>>>
>>>e.g.
>>>
>>>  a = myfunction(4, out x, out y);
>>>
>> 
>> Hmm, that could get a bit ugly when your function parameters are numerous.  But you're right - it certainly would be clear where the inputs and outputs lie.
>
>Beauty is in the eye of the beholder...;-)
>
>I suggested this because it is very simple to implement and does not change the syntax in any dramatic manner.
> 
>>>This could also be used for inout arguments as well.
>>>
>>>Problem (B) is, in essence, a style issue. It could be said that
>>>
>>>  (int x, real y, float[] a) myfunction (int b)
>>>
>>>is easier or harder to read than
>>>
>>>  float[] a myfunction (int b, out int x, out real y)
>>>
>>>depending on the way individuals see things.
>>>
>> 
>> Exactly.  I think that in order to progress we must disobey the Bob of Backwards Compatibility every now and then.  You can't serve two masters.
>
>Oh! I didn't realize you were asking to replace the current syntax with your alternative. That would break *so* much existing code it could create enemies ;-)
>

Agreed, but I wasn't referring to D specifically - I have a bad habit of doing that...  My bad

>>>However, one difference between the two syntaxes is that the current method *requires* that the return value is mandatory but it is not a requirement that the 'out' arguments are updated. The proposed method implies that none of the 'return' values are mandatory, and this is a fundamental idiom shift.
>>>
>> 
>> I noticed this as well.  Doesn't it seem odd that forgetting to set the value of "out" arguments is allowed?  It seems to me that they are outputs, and not input-outputs, and should be set at all times.  Returning an output argument value with its default type initializer just doesn't seem to have much of a point to me. (Unless Exceptions are thrown, but let's not get into that - they're exceptional)
>
>To repeat: one of your proposals makes all 'return' values optional.
> 
>>>> Concerns?
>>>
>>>I suspect that this would be a medium change in the syntax rules and it is a definite step away from the C family syntax. I can see that the problem (A) is one that is justifiably addressed though a simpler way might be better.
>> 
>> Do you have a "simpler way" suggestion?  As I said before, I'm working on my own pet language, so any insight you've got could be helpful to me.
>
>For D, only the one I've already mentioned.
>
>However, for a totally new/different language then returning tuples seems a nice idea. The only sugar needed would be some syntax to indicate that you are accepting a pseudo tuple.
>
>The simple case would be something like ...
>
>  tuple A;
>  A = myfunction(4);
>
>but a pseudo tuple might be needed if updating elements currently belonging to disparate variables...
>
>  int A;
>  real B;
>  string C;
>  { A, B, C } = myfunction(4);
>

My new language is more or less like C with a few extensions and a slightly "new" paradigm.  I don't want it to turn into LISP by throwing tuples everywhere - only where they make sense.

>
>But back to D, eh?
>

Indeed.  Sorry about my digressions, but it seems this is a familiar place for me to discuss general language features/syntax/ideas.

>-- 
>Derek Parnell
>Melbourne, Australia
>8/06/2005 11:33:07 PM

Regards,
James Dunne

seems im the only one who likes this idea?

also, i dont see why it would have to break any code. the compiler should be easily capable of converting between both syntaxes, no? its basicly just a matter of sweeping all out parameters to the left.

both syntaxes could coexist with a little change here and there.

"James Dunne" <james.jdunne@gmail.com> wrote in message news:d845t5$2ck6$1@digitaldaemon.com...
> "out" variables would be much more useful as a set of multiple return values:
>
> : (int x, real y, float[] a) myfunction (int b);
>
> I'd say the only complications arise in handling the return statement
> syntax -
> whether or not to specify a set of return values, or to implicitly return
> values
> by setting return-value variables.
>
> method 1: return with a set of values
> : (int, real, float[]) myfunction (int b) {
> :     return (b + 2, b * 4.5, null);
> : }
>
> or
>
> method 2: return by setting return-value variables
> : (int x, real y, float[] a) myfunction (int b) {
> :     x = b + 2;
> :     y = b * 4.5;
> :     a = null;
> :     return;
> : }
>
> Both *examples* are equivalent, but each approach has its strengths and
> weaknesses.  No weaker than forgetting to set an "out" variable as the
> language
> is now.
>
> Method 1 allows for cleaner reading until the list of return values gets unreasonably large.  It also accomodates all return-values on function return.
>
> Method 2 allows more readability for longer lists of return values, but
> sacrifices understandability in following setting of return values
> throughout a
> complex control flow.
>
> Personally, I'd prefer method 2; but perhaps both forms can be supported.
>
> Calling syntax is up for debate as well:
>
> : int x;
> : real y;
> : float[] a;
> : (x, y, a) = myfunction(4);
>
> Thoughts?  Opinions?  Concerns?
>
> Regards,
> James Dunne

In article <d8u60n$vdm$1@digitaldaemon.com>, Eelco Hoogendoorn says...
>seems im the only one who likes this idea?
me too

>"James Dunne" <james.jdunne@gmail.com> wrote in message news:d845t5$2ck6$1@digitaldaemon.com...
>> "out" variables would be much more useful as a set of multiple return
>> values:
>> : (int x, real y, float[] a) myfunction (int b);

Good idea, we should learn more from Perl.
Not that D should be like Perl, but some good ideas could be borrowed.


>> method 1: return with a set of values
>> : (int, real, float[]) myfunction (int b) {
>> :     return (b + 2, b * 4.5, null);
>> : }
>>
>> or
>>
>> method 2: return by setting return-value variables
>> : (int x, real y, float[] a) myfunction (int b) {
>> :     x = b + 2;
>> :     y = b * 4.5;
>> :     a = null;
>> :     return;
>> : }

>> Personally, I'd prefer method 2; but perhaps both forms can be supported.

I think method 1 has to be there. It's much pratical in many situations. Both should be supported.


>> Calling syntax is up for debate as well:
>> : int x;
>> : real y;
>> : float[] a;
>> : (x, y, a) = myfunction(4);

I prefer:
: (int x, real y, float[] a) = myfunction(4);


Also:

: /* function returning arrays should be flexible: */
:
: int[] fA(int n) {
:   if(n == 1) return 1;
:   if(n == 2) return [1, 2];
:   if(n == 3) return [1, 2, 3];
:   return;
: }
:
: a = fA(1); // a=1
: (a, b) = fA(1); // a=1, b=null
: (a, b) = fA(2); // a=1, b=2
: (a, b) = fA(3); // a=1, b=2 (third return value discarded)
: (a, b) = fA(0); // a=null, b=null
: (a, b) = fA(3)[1..3]; // a=2, b=3
: (a, null, b) = fA(3); // a=1, b=3 (discard second value)
: (int x, int y) = fA(2); // declare and set
:
:
: /* for list of types, it's more controversial
:    to loosen syntax restriction so much
:  */
:
: (int i, char c) fM(int n) {
:   if(n == 1) return 1; // syntax ok? c would be null
:   if(n == 2) return (1, 'a');
:   return; // syntax ok? both would be null
: }

Rodolfo Borges

Value types, like int and char, cannot be null.  They'd have to be 0 in your example.

-[Unknown]


> In article <d8u60n$vdm$1@digitaldaemon.com>, Eelco Hoogendoorn says...
> 
>>seems im the only one who likes this idea?
> 
> me too
> 
> 
>>"James Dunne" <james.jdunne@gmail.com> wrote in message news:d845t5$2ck6$1@digitaldaemon.com...
>>
>>>"out" variables would be much more useful as a set of multiple return values:
>>>: (int x, real y, float[] a) myfunction (int b);
> 
> 
> Good idea, we should learn more from Perl.
> Not that D should be like Perl, but some good ideas could be borrowed.
> 
> 
> 
>>>method 1: return with a set of values
>>>: (int, real, float[]) myfunction (int b) {
>>>:     return (b + 2, b * 4.5, null);
>>>: }
>>>
>>>or
>>>
>>>method 2: return by setting return-value variables
>>>: (int x, real y, float[] a) myfunction (int b) {
>>>:     x = b + 2;
>>>:     y = b * 4.5;
>>>:     a = null;
>>>:     return;
>>>: }
> 
> 
>>>Personally, I'd prefer method 2; but perhaps both forms can be supported.
> 
> 
> I think method 1 has to be there. It's much pratical in many situations.
> Both should be supported.
> 
> 
> 
>>>Calling syntax is up for debate as well:
>>>: int x;
>>>: real y;
>>>: float[] a;
>>>: (x, y, a) = myfunction(4);
> 
> 
> I prefer:
> : (int x, real y, float[] a) = myfunction(4);
> 
> 
> Also:
> 
> : /* function returning arrays should be flexible: */
> :
> : int[] fA(int n) {
> :   if(n == 1) return 1;
> :   if(n == 2) return [1, 2];
> :   if(n == 3) return [1, 2, 3];
> :   return;
> : }
> :
> : a = fA(1); // a=1
> : (a, b) = fA(1); // a=1, b=null
> : (a, b) = fA(2); // a=1, b=2
> : (a, b) = fA(3); // a=1, b=2 (third return value discarded)
> : (a, b) = fA(0); // a=null, b=null
> : (a, b) = fA(3)[1..3]; // a=2, b=3
> : (a, null, b) = fA(3); // a=1, b=3 (discard second value)
> : (int x, int y) = fA(2); // declare and set
> :
> :
> : /* for list of types, it's more controversial
> :    to loosen syntax restriction so much
> :  */
> :
> : (int i, char c) fM(int n) {
> :   if(n == 1) return 1; // syntax ok? c would be null
> :   if(n == 2) return (1, 'a');
> :   return; // syntax ok? both would be null
> : }
> 
> Rodolfo Borges