> I think it's a universe/unidata difference. I get the segmentation fault
> running unidata in ecl type U as well.
> Here's some interesting info and an ugly hack--in unidata.
It seems completely wrong to me (UV in Prime flavour)
> Apparently, the keywords SUBROUTINE and FUNCTION are interchangable as
> far as BASIC is concerned, so create a subroutine
> SUBROUTINE MYHACK(A,B)
Actually, I don't think they are ... at least npt the way you imply.
> A=B*2 ;* note that we both assign the result
> to a parameter AND return the result
> RETURN A
This is weird ...
>Then you can call it as a function with
> PROGRAM HACKTEST
> DEFFUN MYHACK(A,B)
> CRT MYHACK('',2) ;* <--- there's the hack. You need that
> placeholder parameter
This is why it blows up ...
> Or use it as a subroutine:
> PROGRAM HACK2
> CALL MYHACK(A,2)
> CRT A
> Or from a virtual attribute:
> I
> SUBR('MYHACK',EXTRACT(@RECORD,1,0,0))
Let's say we want a function called MYHACK. The following two declarations are
identical...
SUBROUTINE MYHACK( RESULT, A, B)
...
RESULT = whatever
RETURN
or
FUNCTION MYHACK( A, B)
...
RETURN (whatever)
If you want to access the first version from a calling program by doing
DEFFUN MYHACK( A, B)
ANSWER = MYHACK( 1, 2)
that'll work. As will calling the latter version with
CALL MYHACK( ANSWER, 1, 2)
So you can mix and match between treating it as a subroutine and as a function,
but the function version always has one less argument - the first one is
missing as it is an "implied" result.
Someone said "don't risk this because it may change in future". As far as I'm
aware, it WON'T change, because the SUBR call relies on this behaviour. Look up
SUBR in the docu, and you'll see that anything it calls MUST be this sort of
function, after all, when you call a subroutine using SUBR, you can't pass in
the first argument ...
Cheers,
Wol
-------
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
