[Coco] DEFFN in Extended BASIC

[Allen Huffman]

More observations. From the Super Extended Color Basic manual on page 205, they show this example:

10 DEF FNTWO(N)=N*2
20 INPUT X
30 PRINT FNTWO(X)
40 GOTO 20

They call it "temporary variables", and indeed, if there is just ONE parameter, that is how it works. I am not sure if N is even allocated, but I plan to dig deeper.

Now, if you use multiple variables, apparently the "temporary variables" no longer works.

10 DEF FNADD(N1 N2)=N1+N2
20 INPUT A,B
30 PRINT FNADD(A B)
40 GOTO 20

This prints 0, because it seems to fall back to using the names you used in the DEFFN statement. Instead of A and B, if you use N1 and N2, it works.

20 INPUT N1,N2
30 PRINT FNADD(N1 N2)

Trying to do FNADD(0) resulted in 0. However, trial and errors shows it is trying to match up the names of the multi variables. If you do this:

N1=1:N2=100
PRINT FNADD(0 N2)

...and N2 is 100, then it prints 100.

PRINT FNADD(N1 0) prints 101. The additional parameters do not seem to matter what they are, as it is using the global. Thus, only the first parameter seems to be checked, then it uses the rest:

PRINT FNADD(N1 42)
...still prints the correct 101.

Bug? Undocumented actual desired usage? I mean, you CAN put the correct variables there and it works, but it's ignoring anything after the first one

Output is also messed up. Using this FNADD example:

PRINT FNADD(1 1) -- produces 12. Huh? So I did more checking:

N1=100:N2=1000
This way I can tell what is being used to add 1 or 2 based on the result

PRINT FNADD(0) -- 1000... N1=0, N2=1000

PRINT FNADD(1) --- 1001... N1=1, N2=1000

PRINT FNADD(1 1) --- 1011... Huh?

PRINT FNADD(3 4) --- 1034. 34? 3 and 4?

PRINT FNADD(9 8) --- 1098. Houston, we have a pattern.

The routine is just merging things together.

PRINT FNADD(123 987) --- 124987. It makes that one big string (123987) as N1, then adds N2 (1000) to it. Okay, that's what it's doing, but that's probably wrong.

Maybe this is a bug, or maybe it was a shortcut. There is only code for parsing the first parameter to replace the first variable, whatever it was called in the define. Then, any others are just used from the DEF globally.

PRINT FNADD(1 Z) --- produces a syntax error. Because Z isn't part of the formula? It doesn't check the first, but the second can't be anything unless it matches?

PRINT FNADD(N2 N1) --- 2000... N2(1000) goes in so N1 becomes 1000, then it adds N2 (1000) to it. Correct.

I'd love to hear what's going if someone cares to dig through the assembly.
-
Allen Huffman - PO Box 22031 - Clive IA 50325 - 515-999-0227 (vmail/TXT only)
http://www.subethasoftware.com - https://www.facebook.com/subethasoftware
Sent from my iPad.

P.S. Since 4/15/2014, I have earned over $600 in Amazon gift cards! Sign up using my link and I get credit:
http://swagbucks.com/refer/allenhuffman


On Jan 4, 2015, at 12:15 AM, Allen Huffman <alsplace at pobox.com> wrote:

>> On Jan 3, 2015, at 11:33 PM, Allen Huffman <alsplace at pobox.com> wrote:
>> 
>> 10 DEFFNA(A B C D)=A+B+C+D
>> 20 A=1:B=10:C=100:C=1000
>> 30 PRINT FNA(1 10 100 1000)
>> 
>> …prints 1111.
>> 
>> Tests show it does not work with direct numbers like FNA(1 2 3 4) but works with variables.
> 
> And, I might add, it has to be the variables you used in DEFN() for it to work. It must just simply be making a note of where that formula is, and when it sees FNx( it jumps there?
> 
> I notice it produces the expected result even if you call it as FNA(0). It just uses the A and B you defined earlier, and jumps to whatever code. It's a function GOSUB. Cool.
> 
> I guess it's time to look at Unravelled and see how it's doing this since there is an understanding that it doesn't work when clearly it does.
> 
> 10 DEFFNA(A B)=A+B
> 20 A=10:B=1:PRINTFNA(0)
> RUN
> 11
> 
> Slower, but could save memory.
> 
>        -- Allen