Function result type 
Author Message
 Function result type

A function written in Turbo Pascal 6.0 cannot return a type other than
simple, string, or pointer. If you try to compile the following
program, you would get a compiler error message 34: Invalid function
result type. Does this feature differ TP from the standard Pascal,
designed by Wirth? I cannot test the following code with a compiler
other than TP presently, and if someone can, I would appreciate
his/her help.

Is the only solution to convert this procedure to a function?
====
program m(input, output);

const
   max = 10;

type
   matrix = array[1..max, 1..max] of integer;

function t(x: matrix): matrix;
   begin
      {Do some stuff}
   end;

begin
   {...}
end.



Tue, 29 Jul 2003 23:40:36 GMT  
 Function result type

Quote:
>Is the only solution to convert this procedure to a function?

Function to a procedure. Sorry.


Tue, 29 Jul 2003 23:55:24 GMT  
 Function result type

Quote:

> A function written in Turbo Pascal 6.0 cannot return a type other than
> simple, string, or pointer. If you try to compile the following
> program, you would get a compiler error message 34: Invalid function
> result type. Does this feature differ TP from the standard Pascal,
> designed by Wirth? I cannot test the following code with a compiler
> other than TP presently, and if someone can, I would appreciate
> his/her help.

> Is the only solution to convert this procedure to a function?
> ====
> program m(input, output);
> ...

The function result restriction is defined by Wirth. The String
result was opposed to Wirth by Borland. Anything more is illegal.

Pascal will never degrade to C++ / Java / Perl etc. levels / manners.
Hopefully.

But there are bypasses available. They are complicated and made
for use by professionals only.

Greetings
--
Franz Glaser, Glasau 3, A-4191 Vorderweissenbach Austria +43-7219-7035-0
Muehlviertler Elektronik Glaser.  Industrial control and instrumentation
http://members.eunet.at/meg-glaser/    http://members.xoom.com/f_glaser/
http://www.geocities.com/~franzglaser/            http://start.at/bedarf



Wed, 30 Jul 2003 21:43:59 GMT  
 Function result type
Yes, the solution is to turn the function into a procedure.

Desired (but not legal Pascal) --

  FUNCTION myfunction (inputargs : complicatedtype) :
anothercomplicatedtype;

Procedure recast (legal Pascal) --

  PROCEDURE myprocedure (inputargs : complicatedtype;
                                                VAR outputargs :
anothercomplicatedtype);

Make sure that you declare the output variable as a "VAR" variable, so
that values can
be returned by it.  I've used this trick to build complex arithmetic
routines in Standard Pascal.  While it would be nice to say

   a := complexadd (b,  complexproduct (c, d));

I can accomplish the same thing (though less legibly) with

complexproduct (c, d, temp);
complexadd (b, temp, a);

Bob Schor
Pascal Enthusiast

Quote:

> A function written in Turbo Pascal 6.0 cannot return a type other than
> simple, string, or pointer. If you try to compile the following
> program, you would get a compiler error message 34: Invalid function
> result type. Does this feature differ TP from the standard Pascal,
> designed by Wirth? I cannot test the following code with a compiler
> other than TP presently, and if someone can, I would appreciate
> his/her help.

> Is the only solution to convert this procedure to a function?
> ====
> program m(input, output);

> const
>    max = 10;

> type
>    matrix = array[1..max, 1..max] of integer;

> function t(x: matrix): matrix;
>    begin
>       {Do some stuff}
>    end;

> begin
>    {...}
> end.



Fri, 01 Aug 2003 02:13:36 GMT  
 Function result type
Ing. Franz Glaser:

Quote:
> The function result restriction is defined by Wirth. The String
> result was opposed to Wirth by Borland. Anything more is illegal.

> Pascal will never degrade to C++ / Java / Perl etc. levels / manners.
> Hopefully.

This sounds sour grapes... Sucessors of Pascal have functions
returning whatever type without any of the awful degradation
you mention...

G.

Sent via Deja.com
http://www.deja.com/



Fri, 01 Aug 2003 22:36:33 GMT  
 Function result type

Quote:

> Ing. Franz Glaser:

> > The function result restriction is defined by Wirth. The String
> > result was opposed to Wirth by Borland. Anything more is illegal.

> > Pascal will never degrade to C++ / Java / Perl etc. levels / manners.
> > Hopefully.

> This sounds sour grapes... Sucessors of Pascal have functions
> returning whatever type without any of the awful degradation
> you mention...

This is a religious matter, I am afraid. If you have a very
sharp knife, it is suggested to give it in the hands of a
highly experienced cook only!

Else you get application programs as they are usual nowadays -
some people assort all the mistakes which I think of here with
typical Windows programming. But - it is a religious matter :-)

Greetings
--
Franz Glaser, Glasau 3, A-4191 Vorderweissenbach Austria +43-7219-7035-0
Muehlviertler Elektronik Glaser.  Industrial control and instrumentation
http://members.eunet.at/meg-glaser/    http://members.xoom.com/f_glaser/
http://www.geocities.com/~franzglaser/            http://start.at/bedarf



Sat, 02 Aug 2003 05:25:26 GMT  
 Function result type

Quote:

> A function written in Turbo Pascal 6.0 cannot return a type other than
> simple, string, or pointer. If you try to compile the following
> program, you would get a compiler error message 34: Invalid function
> result type. Does this feature differ TP from the standard Pascal,
> designed by Wirth? I cannot test the following code with a compiler
> other than TP presently, and if someone can, I would appreciate
> his/her help.

> Is the only solution to convert this procedure to a function?
> ====
> program m(input, output);

> const
>    max = 10;

> type
>    matrix = array[1..max, 1..max] of integer;

> function t(x: matrix): matrix;
>    begin
>       {Do some stuff}
>    end;

> begin
>    {...}
> end.

Depends on how many results you want to return. Functions were (despite the
bad example of C) designed to return a single result into the context of an expression.
The next level is a procedure that accepts a list of VAR parameters.
The next level is to make those parameters complex so that whole tables
are modified.
The unsaid context is that you want to make everything a procedure operates on
a formal parameter of that procedure, a laudable goal.

--

"I'm a marvelous housekeeper. Every time I leave a
man, I keep his house".

Zsa Zsa Gabor.



Mon, 04 Aug 2003 03:51:22 GMT  
 Function result type

Quote:


>Depends on how many results you want to return. Functions were (despite the
>bad example of C) designed to return a single result into the context of an expression.

Interesting. Then I should check this for FPC.

Due to the operator overloading, expressions using functions that return
complex (but not dynamic types) make sense.



Mon, 04 Aug 2003 05:47:33 GMT  
 Function result type

Quote:


> >Depends on how many results you want to return. Functions were (despite the
> >bad example of C) designed to return a single result into the context of an expression.

> Interesting. Then I should check this for FPC.

> Due to the operator overloading, expressions using functions that return
> complex (but not dynamic types) make sense.

Pppppppprrrrrrooooobbbbaaaallllyyy,

I would tend to wonder about the efficentcy of a function result whose only purpose is
to have a single bit selected out and the rest discarded. Ie., if you have structured
returns, "myfunc.whats" or "myfunc[x]" to return a member of the complex return
myfunc must of nessity discard all but one element of the result.

ie,
ie,

Functions inherently return a single atom of data. If you have:

x := func;

Where x and func are complex, this preserves the whole complex object, but then this
is equivalent to:

proc(x)

where proc uses VAR to deposit the complex result.

Ie., is a feature of a language there to accomplish a goal, or to amuse the designer ?

Mail me a 2x4, and I'll whack myself with it if desired.

--

"I'm a marvelous housekeeper. Every time I leave a
man, I keep his house".

Zsa Zsa Gabor.



Wed, 06 Aug 2003 03:17:31 GMT  
 Function result type

Quote:




>> >Depends on how many results you want to return. Functions were (despite the
>> >bad example of C) designed to return a single result into the context of an expression.

>> Interesting. Then I should check this for FPC.

>> Due to the operator overloading, expressions using functions that return
>> complex (but not dynamic types) make sense.

>Pppppppprrrrrrooooobbbbaaaallllyyy,

>I would tend to wonder about the efficentcy of a function result whose only
>purpose is to have a single bit selected out and the rest discarded. Ie.,
>if you have structured returns, "myfunc.whats" or "myfunc[x]" to return a
>member of the complex return myfunc must of nessity discard all but one
>element of the result.

Yup.

Quote:

>Functions inherently return a single atom of data. If you have:

>x := func;

>Where x and func are complex, this preserves the whole complex object, but then this
>is equivalent to:

>proc(x)

>where proc uses VAR to deposit the complex result.

Officially yes, but often operator overloading functions are inlined.

And any  every simplification can cost performance.

Quote:
>Ie., is a feature of a language there to accomplish a goal, or to amuse the
>designer ?

To accomplish a goal, and I clearly gave an example above, that simplifies
code, and in combination with inline doesn't cost performance.

Not that I think that introducing simplificity for performance tradeoffs is
a bad thing if it doesn't affect ordinary programming, and as long as they
are sane.



Wed, 06 Aug 2003 07:37:54 GMT  
 Function result type


Quote:
> A function written in Turbo Pascal 6.0 cannot return a type other than
> simple, string, or pointer. If you try to compile the following
> program, you would get a compiler error message 34: Invalid function
> result type. Does this feature differ TP from the standard Pascal,
> designed by Wirth? I cannot test the following code with a compiler
> other than TP presently, and if someone can, I would appreciate
> his/her help.

I checked your example with two Macintosh Pascal Compilers. I needed to add
a few lines to make it a working example (see below). Both ThinkPascal and
MPW Pascal got no problems with complex result types. However the type must
be a named type, that means, it must be declared in a type statement.

ORIGINAL CODE EXAMPLE:

Quote:
> program m(input, output);

> const
>  max = 10;

> type
>  matrix = array[1..max, 1..max] of integer;

> function t(x: matrix): matrix;
>  begin
>     {Do some stuff}
>  end;

> begin
>  {...}
> end.

MODIFIED CODE EXAMPLE:

program m (input, output);
  const
    max = 10;

  type
    matrix = array[1..max, 1..max] of integer;

  function t (var x: matrix): matrix;
    var
      i, j: integer;

  begin
    for i := 1 to max do
      for j := 1 to max do
        t[i, j] := x[max - i + 1, max - j + 1];
  end;

  var
    i, j: integer;
    x, y: matrix;

begin
  for i := 1 to max do
    for j := 1 to max do
      x[i, j] := i * j;

  y := t(x);

  for i := 1 to max do
    begin
      for j := 1 to max do
        write(x[i, j] : 4);
      writeln;
    end;

  writeln;
  for i := 1 to max do
    begin
      for j := 1 to max do
        write(y[i, j] : 4);
      writeln;
    end;
end.

RESULT:

   2   3   4   5   6   7   8   9  10  11
   3   4   5   6   7   8   9  10  11  12
   4   5   6   7   8   9  10  11  12  13
   5   6   7   8   9  10  11  12  13  14
   6   7   8   9  10  11  12  13  14  15
   7   8   9  10  11  12  13  14  15  16
   8   9  10  11  12  13  14  15  16  17
   9  10  11  12  13  14  15  16  17  18
  10  11  12  13  14  15  16  17  18  19
  11  12  13  14  15  16  17  18  19  20

  20  19  18  17  16  15  14  13  12  11
  19  18  17  16  15  14  13  12  11  10
  18  17  16  15  14  13  12  11  10   9
  17  16  15  14  13  12  11  10   9   8
  16  15  14  13  12  11  10   9   8   7
  15  14  13  12  11  10   9   8   7   6
  14  13  12  11  10   9   8   7   6   5
  13  12  11  10   9   8   7   6   5   4
  12  11  10   9   8   7   6   5   4   3
  11  10   9   8   7   6   5   4   3   2

I had a look at the generated 68k assembly. On function entry the result
address (4 bytes) is pushed onto the stack. This is not worse compared to
pushing the address of a VAR parameter onto the stack. Since the components
of the result can be accessed individually, there is neither a performance
loss nor a performance gain within t() compared to the alternative coding of
making t() a procedure with x and y being VAR parameters. However, the given
example enforces an unnecessary copy statement -  y := t(x);  - but, this is
simply a matter of program design - no question, I would prefer the
procedure alternative in this case. Although, in other cases I might find
functions with complex result types to be more appropriate.

Best regards

Rolf Jansen

____________________________________________________________________________
 InstantWare Dr. Rolf Jansen * Postfach 1123 * D-55272 Oppenheim * Germany

 http://home.t-online.de/home/InstantWare
____________________________________________________________________________



Thu, 07 Aug 2003 19:50:13 GMT  
 Function result type


Quote:


>>Depends on how many results you want to return. Functions were (despite the
>>bad example of C) designed to return a single result into the context of an expression.

>Interesting. Then I should check this for FPC.

I tried with FPC finally, and it worked fine. I don't do operator
overloading in Pascals, but the following:

Quote:
>Due to the operator overloading, expressions using functions that return
>complex (but not dynamic types) make sense.

seems as a good reason why that program worked. IMHO, of course.


Tue, 12 Aug 2003 17:48:40 GMT  
 Function result type

Quote:





>>>Depends on how many results you want to return. Functions were (despite the
>>>bad example of C) designed to return a single result into the context of an expression.

>>Interesting. Then I should check this for FPC.

>I tried with FPC finally, and it worked fine. I don't do operator
>overloading in Pascals, but the following:

So here is the proof that even Core members don't know everything :-)

Quote:
>>Due to the operator overloading, expressions using functions that return
>>complex (but not dynamic types) make sense.

>seems as a good reason why that program worked. IMHO, of course.

Could also be because of Delphi (I don't know what Delphi does in this
case), and Delphi only will have operator overloading in the next version.


Tue, 12 Aug 2003 20:11:58 GMT  
 
 [ 13 post ] 

 Relevant Pages 

1. function result type

2. BP7: Function of type function

3. Function result

4. function resulting in array?

5. TQuery as a result of a function

6. How to Pass a file type to a function or procedure

7. Calculating functions typed in by user..

8. Passing variable object types to procedures/functions

9. Need help with type casting on numeric values from AVG aggregate functions

10. changing real type data to word type

11. Money field type same as Currency data type??

12. numeric field type same as float type??

 

 
Powered by phpBB® Forum Software