### Author Topic: DEF FN...  (Read 2656 times)

#### Galleon

• Hero Member
• Posts: 4664
• QB Forever
##### DEF FN...
« on: December 23, 2009, 01:10:30 PM »
No work on implementing this feature has been done yet.
Something old... Something new... Something borrowed... Something blue...

#### Clippy

• Hero Member
• Posts: 16431
• I LOVE π = 4 * ATN(1)    Use the QB64 WIKI >>>
##### Re: DEF FN...
« Reply #1 on: December 23, 2009, 01:37:11 PM »
Is it possible to make DEF Fn more like a real Function? The reason I ask is that currently there are many QB limitations such as recursion and changing return values. Sometimes you have to assign the return to a new variable to alter the result.

I think it would be great to create one line functions.

Ted
QB64 WIKI: Main Page

#### rpgfan3233

• Guest
##### Re: DEF FN...
« Reply #2 on: December 23, 2009, 06:59:19 PM »
Quote from: Clippy on December 23, 2009, 01:37:11 PM
Is it possible to make DEF Fn more like a real Function? The reason I ask is that currently there are many QB limitations such as recursion and changing return values. Sometimes you have to assign the return to a new variable to alter the result.

I think it would be great to create one line functions.
Honestly, DEF FN is more like a C/C++ macro:
Code: [Select]
`#include <stdio.h>#define FNadd1(x) (x + 1)intmain (void){  printf ("%u", FNadd1(4));  return 0;}`
That "call" to the FNsquare macro?  It's merely substituted with the contents of the macro, obviously with the parameter being used instead of `x'.  Example preprocessed source without #line statements:
Code: [Select]
`/* <insert stdio.h contents here> */intmain (void){  printf ("%u", (4 + 1));  return 0;}`
The output should be obvious.  The equivalent is easily defined in QB:
Code: [Select]
`DEF FNadd1(x) = x + 1`
DEF FN without parameters is a bit more difficult since its replacement value changes at run time rather than being determined at compile time.

#### Pete

• Moderator
• Hero Member
• Posts: 6240
• Cuz I sez so varmint!
##### Re: DEF FN...
« Reply #3 on: December 23, 2009, 07:23:05 PM »
Galleon will probably catch this, but just in case, DEF FN may also be used as a block statement:

DEF FNname[(parameterlist)]
[statements]
FNname = expression
[statements]
END DEF

So technically, we should have DEF FN and END DEF in this unimplemented statements category.

Pete

PS, I have not used the block form in programs, only the single line.

It's only rocket science; it's not Linux!

#### stylin

• Guest
##### Re: DEF FN...
« Reply #4 on: December 23, 2009, 07:26:03 PM »
Quote
Honestly, DEF FN is more like a C/C++ macro:
Well, no, not at all. DEF FN functions do not perform blind text-replacement like macros; they are type-aware just like normal FUNCTIONs and evaluate their arguments only once, but have different behavior with regards to local variable declaration, can't recurse and can't have external linkage.

Quote
DEF FN without parameters is a bit more difficult since its replacement value changes at run time rather than being determined at compile time.
Hmm ?

#### Clippy

• Hero Member
• Posts: 16431
• I LOVE π = 4 * ATN(1)    Use the QB64 WIKI >>>
##### Re: DEF FN...
« Reply #5 on: December 24, 2009, 10:18:08 PM »
It does not need parameters as it is module level like GOSUB. Values can be altered inside of the DEF Fn or outside. To keep the function from altering a value outside of it, you can use STATIC.

Ted
QB64 WIKI: Main Page

#### qbguy

• Full Member
• Posts: 239
##### Re: DEF FN...
« Reply #6 on: December 27, 2009, 11:51:51 AM »
Can you do a GOSUB inside a DEF FN to jump to a label outside of it and then return?
Also, even though DEF FNs can access variables in the main program, I think you can call the DEF FN from inside another subroutine. (ugh) [This feature could be implemented using nested functions for each DEF FN and having globally scoped function pointers to them].

#### Pete

• Moderator
• Hero Member
• Posts: 6240
• Cuz I sez so varmint!
##### Re: DEF FN...
« Reply #7 on: December 27, 2009, 09:35:43 PM »
QuickBasic doesn't allow you to place a GOSUB in a block DEF FN statement. It causes an error 8 label not found.

Pete
It's only rocket science; it's not Linux!

#### Pete

• Moderator
• Hero Member
• Posts: 6240
• Cuz I sez so varmint!
##### Re: DEF FN...
« Reply #8 on: December 28, 2009, 05:53:30 AM »

What will be interesting is trying DEF FN with the way Galleon has the SHARED "AS" in QB64 subs.

Pete
« Last Edit: December 28, 2009, 03:11:53 PM by Galleon »
It's only rocket science; it's not Linux!

#### toml_12953

• Jr. Member
• Posts: 86
##### Re: DEF FN...
« Reply #9 on: December 30, 2009, 06:49:20 AM »
Quote from: Clippy on December 23, 2009, 01:37:11 PM
Is it possible to make DEF Fn more like a real Function? The reason I ask is that currently there are many QB limitations such as recursion and changing return values. Sometimes you have to assign the return to a new variable to alter the result.

I think it would be great to create one line functions.

Ted

I'd think it should operate exactly the way QB FN does for compatibility.  QB can create one-line functions now:

DEF FNA(x) = 4 * ATN(X)

Tom L

#### Clippy

• Hero Member
• Posts: 16431
• I LOVE π = 4 * ATN(1)    Use the QB64 WIKI >>>
##### Re: DEF FN...
« Reply #10 on: December 30, 2009, 09:57:32 AM »
"Compatability" could still be maintained while offering LESS restrictions to future usages.

Because it is a module level function, recursion may be unavoidable in certain circumstances.

QB64 can allow greater flexability than QB ever did and still run the "old" code properly.

Ted

QB64 WIKI: Main Page

#### Pete

• Moderator
• Hero Member
• Posts: 6240
• Cuz I sez so varmint!
##### Re: DEF FN...
« Reply #11 on: December 30, 2009, 10:23:25 AM »
Ah Clippy, from one lousy speller to another, I've wanted to tell you for a long time, since we both use this word a lot, it's "Compatibility" not "Compatability."  It reminds me of that whole "Ask your financial adwiser." commercial, but I digress.

Anyway, I think Galleon has been exceptionally on track for supporting QB compatibility while adding a little extra here and there to QB64 ability. It isn't taking a different course, so no one should really be worried. The course change is what kept most of us hard core QBer's from going to FB.

DEF FN is a bit tricky though. I only use the one-liner, so Galleon won’t be able to rely on me for the block statement testing. For instance, support for things like using gosub or calls within a DEF FN block could be supported in QB64. They are not in QB.

Pete

It's only rocket science; it's not Linux!

#### Clippy

• Hero Member
• Posts: 16431
• I LOVE π = 4 * ATN(1)    Use the QB64 WIKI >>>
##### Re: DEF FN...
« Reply #12 on: December 30, 2009, 12:27:47 PM »
Hey, I'm from Pittsburgh! What can I say? I gave up on perfect spelling long ago. Especially in forum posts. Just as long as you knew what I meant...

Anyhow, that is the way I feel too. Less restrictions are better as long as old code still works. However I don't place it as a high priority. QB64 SHOULD be able to do more than DOS though.

Many of QB's limitations could not be avoided back then. Plus it WAS written by M\$. I even had to fix their "Nibbles" game for faster PC's.

Ted

PS: Instead of one line with = just place code down one line with END DEF on the next. But you knew that already.
« Last Edit: December 30, 2009, 01:26:27 PM by Clippy »
QB64 WIKI: Main Page