multiple return values for functions 
Author Message
 multiple return values for functions

I'd suggest a multiple return value mechanism for functions.
Declare functions like this:

+------------ - -
|PROCEDURE GetScreenWH(thisScreen: Screen):(w,h:INTEGER);
|.....
|.....
|RETURN(thisX, thisY);
|END GetScreenWH;
+------------ - -
Used like that:
+------------ - -
|(myW,myH) := GetScreenWH(primaryScreen);
+------------ - -

As you can see, this style clearly seperates input and output
parameters of functions. On the left side one can see what the
function is given, and on the right what it gives back...

Of course, all of this is possible via VAR-params, too.
But these annoying side effects... I just think the proposed
style simplifies handling of multiple return values and
makes programs easier to understand.
I'm no compiler writer, so I've no
idea if this extension is possible at all ;>
What do you think?



Tue, 07 Sep 1999 03:00:00 GMT  
 multiple return values for functions


Quote:
>I'd suggest a multiple return value mechanism for functions.
>Declare functions like this:

>+------------ - -
>|PROCEDURE GetScreenWH(thisScreen: Screen):(w,h:INTEGER);
>|.....
>|.....
>|RETURN(thisX, thisY);
>|END GetScreenWH;
>+------------ - -
>Used like that:
>+------------ - -
>|(myW,myH) := GetScreenWH(primaryScreen);
>+------------ - -

>As you can see, this style clearly seperates input and output
>parameters of functions. On the left side one can see what the
>function is given, and on the right what it gives back...

>Of course, all of this is possible via VAR-params, too.
>But these annoying side effects... I just think the proposed
>style simplifies handling of multiple return values and
>makes programs easier to understand.
>I'm no compiler writer, so I've no
>idea if this extension is possible at all ;>
>What do you think?

I don't like it very much though on first view it might look
appealing. But once you introduce this feature, you have to make it
applicable throughout the whole language, e.g. in statements like
these:

  (myW, myH) := (oldW, oldH);
  (myW, myH) := (myH, myW) + (10,20);

Personally, I'd like to see structured types as return types instead;
with having

  PROCEDURE Foo (args...) : RecordType;

the semantics of

  PROCEDURE Foo (VAR hidden_result_var: RecordType; args...)

Both violates the minimalistic principle of Oberon, though.
--



Fri, 10 Sep 1999 03:00:00 GMT  
 multiple return values for functions

Minimalism is a key concept. As Wirth quotes from Einstein:
   "Keep it as simple as possible, but not simpler"

Use of a pointer to a record as a return type provides the
required functionality. The Oberon syntactic convenience of
omitting the dereference caret (^) means that for most uses,
the pointer and the record appear interchangeable.

TYPE
  SamplePT = POINTER TO SampleT;
  SampleT =
  RECORD
     AnyField : INTEGER;
     Another  : ARRAY 20 OF CHAR;
     ...
  END;

PROCEDURE Proc (InVar : INTEGER) : SamplePT;

VAR
  OurPtr : SamplePT;

BEGIN
  NEW(OurPtr);
  IF OurPtr # NIL THEN
    OurPtr.AnyField := InVar;
    OurPtr.Another  := "THIS IS A TEST";
  END;
  RETURN OurPtr;
END Proc;

The original point of the proposal below was to clearly separate input
from output parameters. I grant that this is desirable, but the proposed
solution adds great complexity for what is really a very small gain in
readability. If you want to ensure that fields are not altered, you can
mark them as readonly before export from their defining module.

Regards,
Chris Peachment
Developer of the Edipar Oberon Compiler for DOS
http://www.interlog.com/~edpar/oberon.html

---------------

Quote:

>>I'd suggest a multiple return value mechanism for functions.
>>Declare functions like this:

>>+------------ - -
>>|PROCEDURE GetScreenWH(thisScreen: Screen):(w,h:INTEGER);
>>|.....
>>|.....
>>|RETURN(thisX, thisY);
>>|END GetScreenWH;
>>+------------ - -
>>Used like that:
>>+------------ - -
>>|(myW,myH) := GetScreenWH(primaryScreen);
>>+------------ - -

>>As you can see, this style clearly seperates input and output
>>parameters of functions. On the left side one can see what the
>>function is given, and on the right what it gives back...

>>Of course, all of this is possible via VAR-params, too.
>>But these annoying side effects... I just think the proposed
>>style simplifies handling of multiple return values and
>>makes programs easier to understand.
>>I'm no compiler writer, so I've no
>>idea if this extension is possible at all ;>
>>What do you think?

>I don't like it very much though on first view it might look
>appealing. But once you introduce this feature, you have to make it
>applicable throughout the whole language, e.g. in statements like
>these:

>  (myW, myH) := (oldW, oldH);
>  (myW, myH) := (myH, myW) + (10,20);

>Personally, I'd like to see structured types as return types instead;
>with having

>  PROCEDURE Foo (args...) : RecordType;

>the semantics of

>  PROCEDURE Foo (VAR hidden_result_var: RecordType; args...)

>Both violates the minimalistic principle of Oberon, though.
>--




Fri, 10 Sep 1999 03:00:00 GMT  
 multiple return values for functions

Quote:

> Minimalism is a key concept. As Wirth quotes from Einstein:
>    "Keep it as simple as possible, but not simpler"

> Use of a pointer to a record as a return type provides the
> required functionality. The Oberon syntactic convenience of
> omitting the dereference caret (^) means that for most uses,
> the pointer and the record appear interchangeable.

> TYPE
>   SamplePT = POINTER TO SampleT;
>   SampleT =
>   RECORD
>      AnyField : INTEGER;
>      Another  : ARRAY 20 OF CHAR;
>      ...
>   END;

> PROCEDURE Proc (InVar : INTEGER) : SamplePT;

> VAR
>   OurPtr : SamplePT;

> BEGIN
>   NEW(OurPtr);
>   IF OurPtr # NIL THEN
>     OurPtr.AnyField := InVar;
>     OurPtr.Another  := "THIS IS A TEST";
>   END;
>   RETURN OurPtr;
> END Proc;

> The original point of the proposal below was to clearly separate input
> from output parameters. I grant that this is desirable, but the proposed
> solution adds great complexity for what is really a very small gain in
> readability. If you want to ensure that fields are not altered, you can
> mark them as readonly before export from their defining module.

> Regards,
> Chris Peachment
> Developer of the Edipar Oberon Compiler for DOS
> http://www.interlog.com/~edpar/oberon.html

I'm not very fond of this approach because it allocates a new heap object
with every call. It works fine if Proc is only called from time to time
but puts an immense burden on the GC if Proc is called thousands of times
from within a loop. My advice would be not to return temporarily used
values within a heap object allocated by the callee. If it has to be
a heap object, let the caller allocate it and pass it to the callee as
a parameter.

Another drawback is of course that you'll always get an object of type
SamplePT even if you'd rather have an extension.

IMHO, not being able to return structured types is just implementation
restriction and not one imposed by the language.

Just my CHF 0.02

Erich
--
Erich Oswald
Institute for Computer Systems
ETH Zurich, Switzerland



Sat, 11 Sep 1999 03:00:00 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. return multiple values from an awk function?

2. multiple values in a return from function

3. ???Eiffel idiom for multiple return values???

4. Tuples, iterators, and multiple return values in Eiffel?

5. Wait ms Timer Multiple returning inaccurate timer value

6. Multiple return values

7. multiple return values

8. Multiple return values

9. Newbie on multiple return values

10. Multiple return values

11. 1st-class method closures (was Re: Multiple return values)

12. C-interface and multiple return values

 

 
Powered by phpBB® Forum Software