Why do we need Functions?
#11
Sometimes to chose a solution rather then an other could be a philosofical issue, but sometimes is not.
I think that one of the most important differences between SUBs and FUNCTIONs, is the way they can be "called", as to say a SUB must formally CALLed, FUNCTIONs are more likely used as a kind of command.

For example:

FUNCTION Arrotonda! (num!)
    Arrotonda! = _ROUND(num! * 100) / 100
END FUNCTION

This function takes a number, for example 453.326789, it multiplies it by 100 = 45332.6789, it rounds it to 45333 and it divides it by 100 = 453.33. Eventually, it simply rounds 453.326789 to 453.33.

If "Arrotonda!" were a SUB, I should have called it by someting like that:

CALL Arrotonda(N!)

so, I should had this SUB:

SUB Arrotonda (num!)
    num! = _ROUND(num! * 100) / 100
END SUB

And that's ok: this SUB makes almost the same thing of the FUNCTION.

But, let's take this line:

_PRINTSTRING (x% + 4, y% - 16), "(" + _TRIM$(STR$(Arrotonda!(X!))) + ";" + _TRIM$(STR$(Arrotonda!(Y!))) + ")"

If "Arronda" is a SUB, it's not possible to use it like that: it doesn't work.

I could do this:

CALL Arrotonda (X!)
CALL Arrotonda (Y!)
_PRINTSTRING (x% + 4, y% - 16), "(" + _TRIM$(STR$(X!)) + ";" + _TRIM$(STR$(Y!)) + ")"

But I have the variable X! and Y! changed.
The SUB can't be equal to the FUNCTION like that:

SUB Arrotonda! (num!)
    Arrotonda! = _ROUND(num! * 100) / 100
END SUB

because the "!" is not admited and, without the "!", we will have:

SUB Arrotonda (num!)
    Arrotonda = _ROUND(num! * 100) / 100
END SUB

but in that case we have a "variable" named "Arrotonda" which is effective only in the SUB. Even with SHARED, the line:
_PRINTSTRING (x% + 4, y% - 16), "(" + _TRIM$(STR$(Arrotonda(X!))) + ";" + _TRIM$(STR$(Arrotonda(Y!))) + ")"
doesn't works, just because "Arrotonda" in that case, even if effective also in the main code, it is, as said, a variable itself, not a function that does something with a varabile.

Furthermore, in order to avoid the changing of the variables X! and Y!, it would be necessary to make some modifications, as to introduce SHARED variables. And it will be always impossibile to use the SUB into a line as it were a FUNCTION. Eventually, in order to make with a SUB the same thing that with a FUNCTION, it would be necessary, before the line, to CALL the SUB first (as said) many times and then, by means of SHARED variables, use the line changing the "Arrotonda!" function with those variables. But it would be all much much more complicated, with an useless use of memory for useless variables. We can easily think about the importance of FUNCTIONs even in this very simple example, not to notice if lines like the above, which uses "Arrotonda!" many times itself, have to be used a lot of times in similar ways.

"Arrotonda", as a SUB "does someting" that could return a value. "Arrotonda!" (just with the "!"), as a FUNCTION it takes the value itself.

So, for what I can say, FUNCTIONs return a value. Also SUBs can return a value, but in the first case you have a kind of usable command, on the contrary in the second one you have a kind of "function" that must be CALLed alone, and not inside something more complex. In other words, generally when you call a SUB you are interested to have done only what the SUB is intended to do. For that reason, SUBs are often true programs inside the program.
Reply
#12
If you want to complicate your life further but absolutely hate the type sigils, especially for a string "function" then a "SUB" with "side-effects" could work. Have to declare variables "AS STRING" to keep avoiding that dollar sign...

Code: (Select All)
''Example:

DIM SA AS STRING
SA = ""
PRINT SA
CALLME "Hello!", SA
PRINT SA
END

SUB CALLME (SVAL AS STRING, SINP AS STRING)
  SINP = SVAL
END SUB

''as opposed to:

DIM SA AS STRING
SA = ""
PRINT SA
SA = CALLME$("Hello!")
PRINT SA
END


FUNCTION CALLME$ (SVAL AS STRING)
  CALLME$ = SVAL
END FUNCTION

I like to put "SUB" parameters at the end, those that will have the "side-effects".
Reply
#13
(08-19-2022, 01:36 PM)bartok Wrote: SUB Arrotonda! (num!)
    Arrotonda! = _ROUND(num! * 100) / 100
END SUB

because the "!" is not admited and, without the "!", we will have:

SUB Arrotonda (num!)
    Arrotonda = _ROUND(num! * 100) / 100
END SUB
This is incorrect syntax either way because the name of the "SUB" cannot be used in assignment. Must be a "FUNCTION" instead.
Reply
#14
(08-20-2022, 11:59 AM)mnrvovrfc Wrote:
(08-19-2022, 01:36 PM)bartok Wrote: SUB Arrotonda! (num!)
    Arrotonda! = _ROUND(num! * 100) / 100
END SUB

because the "!" is not admited and, without the "!", we will have:

SUB Arrotonda (num!)
    Arrotonda = _ROUND(num! * 100) / 100
END SUB
This is incorrect syntax either way because the name of the "SUB" cannot be used in assignment. Must be a "FUNCTION" instead.

For the first, it was just a demostration about that fact that it didn't work.
For the second, do you like better like this:

SUB Arrotonda (num!)
    num! = _ROUND(num! * 100) / 100
END SUB

I don't have changed "Arrotonda" with "num!"
This doesn't change nothing about what I said. I know that it must be a FUNCTION. In fact I use a FUNCTION and this is the reason why when I made the example as a SUB I forgot the changing. But all the reasoning made, was just to explain in what cases it is better a FUNCTION then a SUB and how avoiding FUNCTIONs in favor of SUBs leads, in these cases, to do things that can be made in a simple way, in a very complicated one. But thank's you for the correction.
Reply
#15
@PhilofPerth
I am with the affirmation of funny Pyton people..t shared by Bplus at #3

SUB cannot  work like a FUNCTION, while a FUNCTION can work like a SUB (just you let return a dummy value to it, as you can do in C/C++ or make a Void function).... with the exception that you need a variable in which you put the result of function

you can use the dummy value to know if Function runs well or no setting the result False at beginning of Function  and True on natural exiting from it.
Yes I must admit that it is boring typewrite  dummy$ = MakeSquare$(X1,Y1, X2,Y2,Colors)  at place of  MakeSquare X1,Y2,X2,Y2,Colors
Reply
#16
We may not "need" Functions but they are very handy to avoid declaring another variable for an intermediate calculation or printing:

If f(x) > 0 then doThis else doThat ' can't do this in one line with Sub
b = b + ...
Reply




Users browsing this thread: 1 Guest(s)