"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

so much hassle for so little (read: for nothing).

I prefer the "out" method much better.

Just my opinion.

James Dunne wrote:
> "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

Many functions are logical using "out".  Anyway, this is an idea that comes from interfaces, and goes along with "in" and "inout".

Since your proposal doesn't remove the need for, or the keywords for, "in" and "inout" it seems strange to remove the corresponding "out".

-[Unknown]


> "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

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

Requires support for tuples, no?  Definitely cool, more intuitive function calls, but requires a lot of changes to compiler.  Walter would never do this.

-Craig

James Dunne wrote:
> "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

I really can sympathize with the desire for separating input and output.  It seems to make so much more sense to do in this fashion.  Not only is it simple to understand, but it's clear to read.  If you keep input as "input" in the function parameter section, and output separate... well it just seems more intuitive.  About the only reason we still use the 'in' and 'out' methods is because of it's relationship to the old C/C++ style; but compatibility with that is simply maintained with the presence or absense '&' operator (more or less, I know... it's more equivalent to inout).

Interestingly, we call inputs to a function "arguments" or "parameters" for a reason.  We don't think of them as "outputs." That seems to be something computer languages have crammed into the design.

In short, James, I like the general idea.  It makes much more sense. This may not be the exact way one would go about this, but it's something to think about for the future.  At the very least, it would be nice if it were enabled as an "alternative" in D, such that the current scheme would not be lost; breaking huge compatibility might not be a popular move.

-JJR

John Reimer wrote:
> James Dunne wrote:
> 
>> "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
> 
> 
> I really can sympathize with the desire for separating input and output.  It seems to make so much more sense to do in this fashion.  Not only is it simple to understand, but it's clear to read.  If you keep input as "input" in the function parameter section, and output separate... well it just seems more intuitive.  About the only reason we still use the 'in' and 'out' methods is because of it's relationship to the old C/C++ style; but compatibility with that is simply maintained with the presence or absense '&' operator (more or less, I know... it's more equivalent to inout).
> 
> Interestingly, we call inputs to a function "arguments" or "parameters" for a reason.  We don't think of them as "outputs." That seems to be something computer languages have crammed into the design.
> 
> In short, James, I like the general idea.  It makes much more sense. This may not be the exact way one would go about this, but it's something to think about for the future.  At the very least, it would be nice if it were enabled as an "alternative" in D, such that the current scheme would not be lost; breaking huge compatibility might not be a popular move.
> 
> -JJR

There are alot of things that can be done in new languages, but one of D's design goals is to keep the "look and feel" of C/C++ syntax.

I see no problem with the "out" parameter. If it's not broken, don't fix it.
unintuitive? well, I have to disagree. Any half decent programmer will find it familiar since it's applied the same way in many other languages.
Even if it wasn't so intuitive, it makes for simple syntax.
I think multipe return values would add uneeded complexity to the syntax.

On Tue, 7 Jun 2005 13:02:29 +0000 (UTC), James Dunne wrote:

> "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?

What problem is this trying to solve?
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.

> 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).

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);

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.

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.

> 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. And problem (B) is not easily fixed because it might mean alternative syntaxes are needed to cater for personal styles. I also suspect that your suggestion would add quite a degree of new complexity to the compiler, as both function declarations and assignment statements would need extra parsing and different code generation.

-- 
Derek
Melbourne, Australia
8/06/2005 10:10:02 AM

John Reimer wrote:
> Hasan Aljudy wrote:
> 
>>
>> There are alot of things that can be done in new languages, but one of D's design goals is to keep the "look and feel" of C/C++ syntax.
>>
>> I see no problem with the "out" parameter. If it's not broken, don't fix it.
>> unintuitive? well, I have to disagree. Any half decent programmer will find it familiar since it's applied the same way in many other languages.
>> Even if it wasn't so intuitive, it makes for simple syntax.
>> I think multipe return values would add uneeded complexity to the syntax.
> 
> 
> Hmmm... you stated your opinion already, so there was no need to give it again; and I've been around here longer than you to know what D is about, so you stated nothing that nobody knows already.  I was just giving my own opinion on this.   I know D's relationship to C.  I know languages have used this method of passing/returning arguments for a long time.  I just decided to step "outside the box" for a moment and evaluate what might be more logical.
> 
> What are trying to do?  Pick a fight?  Well good for you.
> 
> -JJR


whoa man, chill.

Hasan Aljudy wrote:
> John Reimer wrote:
> 
>> Hasan Aljudy wrote:
>>
>>>
>>> There are alot of things that can be done in new languages, but one of D's design goals is to keep the "look and feel" of C/C++ syntax.
>>>
>>> I see no problem with the "out" parameter. If it's not broken, don't fix it.
>>> unintuitive? well, I have to disagree. Any half decent programmer will find it familiar since it's applied the same way in many other languages.
>>> Even if it wasn't so intuitive, it makes for simple syntax.
>>> I think multipe return values would add uneeded complexity to the syntax.
>>
>>
>>
>> Hmmm... you stated your opinion already, so there was no need to give it again; and I've been around here longer than you to know what D is about, so you stated nothing that nobody knows already.  I was just giving my own opinion on this.   I know D's relationship to C.  I know languages have used this method of passing/returning arguments for a long time.  I just decided to step "outside the box" for a moment and evaluate what might be more logical.
>>
>> What are trying to do?  Pick a fight?  Well good for you.
>>
>> -JJR
> 
> 
> 
> whoa man, chill.


Gotchya... sorry. Just a little touchy today.

-JJR

In article <7v4u469qtki1$.1tdcxi3k65eui.dlg@40tude.net>, Derek Parnell says...
>
>On Tue, 7 Jun 2005 13:02:29 +0000 (UTC), James Dunne wrote:
>
>> "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?
>
>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.

>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!

>> 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 ;).  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).

>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.

>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.

>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)

>> 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.

>And problem (B) is not easily fixed because it might mean
>alternative syntaxes are needed to cater for personal styles. I also
>suspect that your suggestion would add quite a degree of new complexity to
>the compiler, as both function declarations and assignment statements would
>need extra parsing and different code generation.
>
>-- 
>Derek
>Melbourne, Australia
>8/06/2005 10:10:02 AM

Regards,
James Dunne