[Coco] Back to DEF FN

Arthur Flexser flexser at fiu.edu
Tue Jan 28 14:17:53 EST 2014


On the other hand, maybe I'm thinking of DEF USR.  It's been so long....

Art


On Tue, Jan 28, 2014 at 2:13 PM, Arthur Flexser <flexser at fiu.edu> wrote:

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



More information about the Coco mailing list