Topic : The GFA-Basic Compendium Author : GFA Systemtechnik GmbH Version : GFABasic.HYP v2.98 (12/31/2023) Subject : Documentation/Programming Nodes : 899 Index Size : 28056 HCP-Version : 3 Compiled on : Atari @charset : atarist @lang : @default : Document not found @help : Help @options : +g -i -s +z @width : 75 @hostname : STRNGSRV @hostname : CAB @hostname : HIGHWIRE @hostname : THING View Ref-FileDEFFN func[(x1,x2,...)]=expression FN func[(y1,y2,...)] func: function name x1, x2: var expression, y1, y2: exp The command DEFFN allows the definition of single-line functions. These functions can appear at any point in the program. The term 'expression' can be any numeric or string expression which can include any of the parameters x1, x2, etc listed in the definition. These parameters are local variables to the function, and if they are also globally defined, no reference can be made to them in the expression as the local variables will be used instead. When the function is called these variables will contain the values listed within the brackets of the function call. Note: The function can be called using either 'FN func' or '@func'. Functions can be nested at will, to any depth. However, recursion is not possible and if attempted, the break-key combination will not work. Examples: DEFFN test(y,a$)=x-y+LEN(a$) x=2 PRINT @test(4,"abcdef") --> The number 4, i.e. 2-4+6 is displayed on the screen. DEFFN first_last$(a$)=LEFT$(a$)+RIGHT$(a$) b$=@first_last$("TEST") PRINT b$ --> The text "TT" is displayed on the screen. DEFFN fourth_power(x)=x^4 DEFFN fourth_root(x)=x^(1/4) PRINT @fourth_root(@fourth_power(1024)) --> The number 1024 is displayed on the screen. Note: Return value is always a float, thus slower. It allows the use of VAR but it can't return anything, thus useless. Memo: If positioned as the first line of a PROCEDURE or FUNCTION definition which has no parameters, a bug in the compiler occurs. In the editor it seems ok. Symptoms: Program works fine in the editor but when compiled acts really strange. Doing things you know it should not be doing. The problem will persist even if the DEFFN is not called! Further investigation shows that the compiler compiles the functions right where it encounters them. Thus, if the DEFFN is defined inside another routine, it jumps over it with a BRAnch always instruction. This makes for some really messing looking code in the dis-assembler! Regardless of where you place them the compiler generates needless BRAnch statements anyway, making the binary larger. When using this command, do not define them inside other subroutines. Best place to put them is between the main body of code and the first subroutine or at the very end of the listing after the last subroutine. ' works in the editor, fails compiled ' insert a line of code above the DEFFN, then it works compiled @test EDIT PROCEDURE test !no parameters DEFFN dummy=0 PRINT "test" RETURN I recommend this command be avoided. The multi-line FUNCTION command is much more flexible and you can control what type of variable is passed back via compiler commands. Use the FUNCTION command instead. This listing for example... PROCEDURE proc LOCAL a& DEFFN test=0 !inside subroutine RETURN Produces this compiled code segment... _PROC: bsr GOSUB lea -32768(a5),a0 bsr LOCALB bra L38 ;jump over the DEFFN... _TEST: moveq #0,d2 rts L38: bra RETURN Versus this method... PROCEDURE proc LOCAL a& RETURN DEFFN test=0 !outside subroutine Result... (cleaner/smaller code) _PROC: bsr GOSUB lea -32768(a5),a0 bsr LOCALB bra RETURN _TEST: moveq #0,d2 rts