DEF FNname (GWBASIC-style functions)

[Galleon]

No work has been done on this command yet.

[angros47]

In QBasic and GWBasic DEF FN works in different ways:

In GwBasic, you can define and redefine functions at runtime:

Code: [Select]

DEF FNA(x)=2*x
PRINT fna(10)
DEF FNA(x)=x/2
PRINT fna(10)
Works in GwBasic, don't work in QB (duplicate definition)

In GWBasic, you can also do things like:

Code: [Select]

10 IF X = 1 THEN DEF FNA(x)=2*x

It doesn't work in QBasic

[Clippy]

In Qbasic you only need to define a function once. Why redefine it again? Just use a different Fn name for each definition.

Your second example is not necessary in either GW or QB.

DEF FnA(x) = x * 2
IF x = 1 THEN x = FnA(x)

If the value was not one, then why call the function?

I don't think Galleon is gonna adapt to GW Basic any time soon.

Ted

[angros47]

In Qbasic you only need to define a function once. Why redefine it again? Just use a different Fn name for each definition.

Redefining a function may be useful, to "simulate" function pointers (that were not available in GwBasic and QBasic).

Example:

Code: [Select]

0 DEF FNY(X) = X
10 INPUT "SELECT FUNCTION";A
20 IF A = 1 THEN DEF FNY(X) = X ^ 2
30 IF A = 2 THEN DEF FNY(X) = 2 ^ X

....
100 FOR X = O TO 640
110 PLOT X,FNY(X)
120 NEXT

Your second example is not necessary in either GW or QB.

DEF FnA(x) = x * 2
IF x = 1 THEN x = FnA(x)

If the value was not one, then why call the function?

My second example was only to show syntax, I know that it's useless

I don't think Galleon is gonna adapt to GW Basic any time soon.

Neither I do.

[qbguy]

Why not just use LISP?

Code: [Select]

(define dx 1/10000)
(define (integrate f a b)
   (let do-my-fscking-integral ((x a) (sum 0))
      (if (> x b)
         sum
        (do-my-fscking-integral (+ x dx) (+ sum (* (f x) dx))))))

Examples:

Code: [Select]

(integrate (lambda (x) x) 0 1)
.50005

(integrate sin 0 3.14159)
1.99999

(integrate exp 0 1)
1.71828

(integrate (lambda (x) (/ x)) 1 2.71828)
1.00004

versus

Code: [Select]

integrate:
sum = 0
FOR x = a TO b STEP dx
sum = sum + FNintegratethisshit(x) * dx
NEXT

but then to call it:

Code: [Select]

dx = 1e-5
a = 0
b = 2.718281828
DEF FNintegratethisshit(x) = EXP(x)
GOSUB integrate
PRINT sum
By requiring multiple lines of code to call a function you give up any gains in clarity you got from the infix notation.

With QB64, you could make use of QBASIC's improved structure, but it would be easier to implement real function pointers in a compiled language rather than the DEF FN hack.


Hmm... not enough swearing. Maybe code differentiation.

Code: [Select]

(define (differentiate f)
  (lambda (x) (/ (- (f (+ x dx)) (f x)) dx)))

Oh well.

[angros47]

Well, if I need pointers, I can use FreeBasic (it has pointers)

Anyway, I think that many people here misunderstood my post: I am not asking for a feature! I only wanted to show a quirk of QBasic and GWBasic: since QB64 is aimed to be a perfect retrocompatible language (Galleon talked about some deprecated features, like KEY ON/ KEY OFF, or like the old OPEN syntax used in GWBasic), I tried to show another, less known one (that makes in some cases QBasic incompatible with GWBasic).

DEF FN has many other problems: in FreeBasic, for example, it hasn't been inplemented because it would have broken compatibility with all names starting with FN ("FName", for example).

[stylin]

A little off-topic, but as you may know, QuickBASIC/QBasic has support for calling procedures via their address using CALL ABSOLUTE. This has always been a painful substitute for "real" procedure pointers, as the procedures must be written in assembly or machine-code, but it can be an effective workaround nonetheless.

[angros47]

I know it, but the procedure is not written in QBasic: worse, it usually is in 16-bit assembly, so it cannot be ported to QB64 (that works in 32-bit mode), unless you add a whole 16-bit emulator (like the one used for DosBox)

[stylin]

unless you add a whole 16-bit emulator (like the one used for DosBox)

Unless I'm very mistaken, this is exactly what Galleon wants to work towards. There is already the beginnings of x86 real-mode/DOS conventional memory emulation (for string character data storage, PEEK/POKE, a few common memory-mapped I/O locations, etc.) which is 16-bit segmented addressing. There is also some (placeholder ?) code for x86 emulation as well.

[Galleon]

Code: [Select]

There is also some (placeholder ?) code for x86 emulation as well.It's more than a placeholder! Checkout '.\samples\qb64\original\cabsmous.bas'. Admittedly, there are still many more opcodes to add support for. It's just not the priority atm. It should also be noted that BYVAL is not supported in CALL ABSOLUTE yet.

[Clippy]

CALL ABSOLUTE also does not support mouse functions above 3 (reading the mouse status) in QB64 either.

As for BYVAL, I think QB64 should allow it to be used more than QB did. Additional parenthesis were never intuitive.

That might also include ANY, which also was not used much.

Ted

[codeguy]

I think functions that act predictably (namely using the FUNCTION statement) are what qb64 needs to focus on, otherwise constructs like
IF x=1 THEN FNA(x)=x^2 ELSE FNA(x)=sqr(x/2) will make for somewhat unpredictable or inexplicable code. in programming, neatness counts. Not that some people intend their code to be used in other programs, but that happens far more frequently than you might expect. So I say ditch the GW-Basic style FN's and stick to FUNCTION, perhaps using SELECT CASE to determine which function to use if there are many.

[Clippy]

Not to mention that Fn also does not allow variable names such as Fname$ for a first name.

Qbasic Help even recommends Functions over DEF Fn.

[Cyperium]

We can't just ditch it, we need it for old source. It should strive for 100% QB 4.5 compatibility and it was compatible with DEF FN so...

...we've also had questions about it, it shouldn't be up to us to decide what the user wants.

[Clippy]

I'd rather see the GW Basic OPEN statement done first. Amazing how "supposed programmers" get lost converting it to a normal QB4.5 OPEN statement. It's NOT hard even!

But if he starts adding GW stuff then PDS will be next yearning. Amazing how many of those PDS functions you can create with a little thought.

Ted