[Coco] Back to DEF FN

Tue Jan 28 14:13:03 EST 2014

My recollection is that DEF FN in Color Basic could not take a function
name, and that Extended Basic allowed the function to be named, so that
more than one function definition (up to 10?) could be used.  I would think
the original usage with no function name would still be valid even with
Extended Basic, for compatibility's sake.

Art

On Tue, Jan 28, 2014 at 2:08 PM, William Astle <lost at l-w.ca> wrote:

> If I'm reading the code right, the original value of the parameter
> variable is saved before the formula is evaluated. Then the original value
> is put back again after. So the value of P should be unchanged.
>
> The flag for FN values only applies to the function name (say the X in DEF
> FNX(P) = P + 3).
>
> BTW, the example code below has a syntax error - there's no function name
> following "FN".
>
>
> On 14-01-28 11:35 AM, Aaron Wolfe wrote:
>
>> There is a bit flag for each variable entry that indicates whether it
>> is a DEF variable.  I believe this means scalar P in BASIC is not the
>> same variable as P in the DEF function.  Somebody more familiar might
>> know for sure.
>>
>> On Tue, Jan 28, 2014 at 1:29 PM, Arthur Flexser <flexser at fiu.edu> wrote:
>>
>>> Well, this raises the more general question of what happens if a dummy
>>> argument used in a function definition has the same name as a scalar
>>> variable used by the program.  For example:
>>>
>>> 10 DEF FN(P) = P+3
>>>
>>> 20 P=20
>>>
>>> 30 Z=FN(5)
>>>
>>> The value of Z should now be 8, but what is now the value of P?  Is it
>>> still 20, or has it changed to 5?
>>>
>>> Art
>>>
>>>
>>>
>>> On Tue, Jan 28, 2014 at 1:14 PM, Aaron Wolfe <aawolfe at gmail.com> wrote:
>>>
>>>  There are two tables of variables in BASIC as William mentioned.  One
>>>> holds scalars, one holds arrays.  The ARYDIS flag causes the variable
>>>> lookup routine to simply skip the table of arrays when looking for a
>>>> match to the input variable name.  In the DEF FN case, this
>>>> effectively prevents arrays from ever being used as the variable
>>>> argument.  In your example the DEF FN(B) would always refer to the
>>>> scalar B, never the array B.
>>>>
>>>> On Tue, Jan 28, 2014 at 12:49 PM, Arthur Flexser <flexser at fiu.edu>
>>>> wrote:
>>>>
>>>>> Aaron, what does that "array search disable" do?   I'm guessing that if
>>>>>
>>>> you
>>>>
>>>>> define FN(B)=B+3, that the array search disable means it makes no
>>>>> difference if the dummy variable B happens to be the name of a declared
>>>>> array or not.  Is that correct?
>>>>>
>>>>> Art
>>>>>
>>>>>
>>>>> On Tue, Jan 28, 2014 at 12:29 PM, Aaron Wolfe <aawolfe at gmail.com>
>>>>> wrote:
>>>>>
>>>>>  Extended Basic Unravelled contains a detailed disassembly of the DEF
>>>>>> code.  Here is the relevant bit:
>>>>>>
>>>>>>
>>>>>> 1015 8880 BD B2 6A // JSR LB26A
>>>>>>      SYNTAX CHECK FOR '('
>>>>>>
>>>>>> 1016 8883 C6 80 // LDB #$80
>>>>>>     GET THE FLAG TO INDICATE ARRAY VARIABLE SEARCH DISABLE
>>>>>>
>>>>>> 1017 8885 D7 08  // STB ARYDIS
>>>>>>     AND SAVE IT IN THE ARRAY DISABLE FLAG
>>>>>>
>>>>>> 1018 8887 BD B3 57 // JSR LB357
>>>>>>     GET VARIABLE DESCRIPTOR
>>>>>>
>>>>>> 1019 888A 8D 25 // BSR L88B1
>>>>>>     'TM' ERROR IF STRING
>>>>>>
>>>>>> 1020 888C BD B2 67 // JSR LB267
>>>>>>     SYNTAX CHECK FOR ')'
>>>>>>
>>>>>> As you can see, there is no loop or any other mechanism that might
>>>>>> allow more than a single variable to be parsed.
>>>>>> The docs might be inconsistent or confusing, but the code is clear.
>>>>>>
>>>>>> -Aaron
>>>>>>
>>>>>>
>>>>>> On Mon, Jan 27, 2014 at 7:37 PM, Rogelio Perea <os9dude at gmail.com>
>>>>>>
>>>>> wrote:
>>>>
>>>>>  Just got delivered a library copy of Peter Vernon's "Making The Mos of
>>>>>>>
>>>>>> Your
>>>>>>
>>>>>>> TRS-80 Color Computer", it was the bargain bin on Amazon
>>>>>>>
>>>>>> (Prentice-Hall
>>>>
>>>>>  Australia 1983 ISBN 0 7248 0752 7).
>>>>>>>
>>>>>>> Leafing through the pages I came to the section where each ECB
>>>>>>>
>>>>>> command is
>>>>
>>>>>  listed, an odd wording of the old DEF FN caught my eye:
>>>>>>>
>>>>>>> 10 DEF FN( A B C)=(A+B+C)/3
>>>>>>> 20 INPUT"ENTER THREE NUMBERS";A,B,C
>>>>>>> 30 D=FNA(A B C)
>>>>>>> 40 PRINT"THE AVERAGE IS";D
>>>>>>> 50 PRINT
>>>>>>> 60 GOTO 20
>>>>>>>
>>>>>>> I was perplexed for a bit. Could it be that the proper syntax on the
>>>>>>>
>>>>>> CoCo's
>>>>>>
>>>>>>> DEF FN requires the variables to be separated by a space instead of a
>>>>>>> comma? could it be *that* simple?
>>>>>>>
>>>>>>> I retyped the MOD routine into the CoCo as:
>>>>>>>
>>>>>>> 10 DEF FNRE=(N1 N2)=N1-INT(N1/N2)*N2
>>>>>>> 20 CLS
>>>>>>> 30 INPUT"NUMBER 1";N1
>>>>>>> 40 INPUT"NUMBER 2";N2
>>>>>>> 50 PRINT
>>>>>>> 60 PRINT N1;"MOD";N2;"IS";FNRE(N1 N2)
>>>>>>> 70 PRINT
>>>>>>> 80 GOTO 30
>>>>>>>
>>>>>>> And it worked. This routine above is based on one shown by Lewis
>>>>>>> Rosenfelder in "Basic Faster And Better & Other Mysteries" book. I
>>>>>>> was
>>>>>>>
>>>>>> on a
>>>>>>
>>>>>>> roll and ported another one from Rosenfelder's (date day # finder):
>>>>>>>
>>>>>>> 10 CLS
>>>>>>> 20 DEF FNJD(Y M
>>>>>>> D)=(M-1)*28+VAL(MID$("000303060811131619212426",(M-1)*2+1,2))-((M>2)
>>>>>>>
>>>>>> AND
>>>>
>>>>>  ((Y AND NOT -4)=0))+D
>>>>>>> 30 INPUT"YEAR (1901-2099)";Y
>>>>>>> 40 INPUT"MONTH (1-12)";M
>>>>>>> 50 INPUT"DAY (1-31)";D
>>>>>>> 60 PRINT
>>>>>>> 70 PRINT"THAT IS THE";FNJD(Y M D);"DAY OF THE YEAR"
>>>>>>> 80 PRINT
>>>>>>> 90 END
>>>>>>>
>>>>>>> Still smiling as I type this. The CoCo ECB book sins in being sparse
>>>>>>>
>>>>>> at
>>>>
>>>>>  best on covering one of the most underrated functions in the BASIC
>>>>>>> repertoire, one that can come useful if applied properly. It had been
>>>>>>>
>>>>>> years
>>>>>>
>>>>>>> (decades actually) since the first time I fiddled with DEF FN and it
>>>>>>>
>>>>>> was
>>>>
>>>>>  disappointing back then that I could not get it to work with 2 or more
>>>>>>> arguments... I was using the syntax I knew from the TRS-80 Model I
>>>>>>> and
>>>>>>>
>>>>>> III
>>>>>>
>>>>>>> BASIC separating the arguments by commas.
>>>>>>>
>>>>>>> With all this, the CoCo's DEF FN is still limited to numeric
>>>>>>>
>>>>>> functions as
>>>>
>>>>>  far as I know; ran a routine trying to define a string variable
>>>>>>>
>>>>>> function
>>>>
>>>>>  (simple concatenation) and the CoCo returned a type mismatch error. Oh
>>>>>>> well, having this found to work with multiple variable arguments is
>>>>>>>
>>>>>> in my
>>>>
>>>>>  eye *the* discovery of the 21st century. Old ECB CoCo style :-)
>>>>>>>
>>>>>>>
>>>>>>> -- RP
>>>>>>>
>>>>>>> --
>>>>>>> Coco mailing list
>>>>>>> Coco at maltedmedia.com
>>>>>>> http://five.pairlist.net/mailman/listinfo/coco
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Coco mailing list
>>>>>> Coco at maltedmedia.com
>>>>>> http://five.pairlist.net/mailman/listinfo/coco
>>>>>>
>>>>>>
>>>>> --
>>>>> Coco mailing list
>>>>> Coco at maltedmedia.com
>>>>> http://five.pairlist.net/mailman/listinfo/coco
>>>>>
>>>>
>>>> --
>>>> Coco mailing list
>>>> Coco at maltedmedia.com
>>>> http://five.pairlist.net/mailman/listinfo/coco
>>>>
>>>>
>>> --
>>> Coco mailing list
>>> Coco at maltedmedia.com
>>> http://five.pairlist.net/mailman/listinfo/coco
>>>
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>>
>>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>