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