Changing string variable value within Sub

[SMcNeill]

@dplus - I'm passing an integer to a function that expects a double - that's an error. I was just wondering why there's no error message.
If one did something like that in a real program, the result would be incorrect.

In an important program, it could be a disaster.

Why would that be an error?  Even moreso, why would it be a disaster?

PRINT COS(10%)

Now, the above is a function that expects a DOUBLE.  Yet we're deliberately passing it an integer.  For what reason would COS explode and toss an error message for you?  Why would it be a disaster?

Sure, it's not going to RETURN a value back to you -- how can it?  That's a constant that we're passing to it, so there's no variable for it to pass any value back to us, but why wouldn't it be able to ACCEPT that value as being valid?  Functions and Subs don't always have to pass values through the parameters in a two-way street.

To go back to the original post here, let's examine how and why this works and doesn't work.

Code: (Select All)

Sub abc (g$)
    Print "value within the sub="; g$
    g$ = g$ + " world"
End Sub

Now, we have the following and it works:

Code: (Select All)

abc foo$

And the following doesn't pass a value back:

Code: (Select All)

abc foo$ + " "

The first works because it matches this basic criteria for passing values back and forth between Subs/Functions:
1) Does the type passed match the type in the Sub/Function?
2) Are we ONLY passing a matching variable and nothing more?
3) Are we free of any interposing syntax which might prevent value sharing, such as parenthesis?

foo$ in the first set of code:
1) Does match the g$ in the SUB abc
2) Is the only thing we're passing to the SUB
3) Isn't in the midst of any other syntax
The value there passes back and forth freely.

foo$ in the second set of code:
1) Does match the g$ in the SUB abc
2) Isn NOT the only thing we're passing to the SUB.  We're also passing a trailing space.
3) Has extra syntax -- in this case the plus sign between the foo$ and space.
That value there does NOT pass back and forth freely.

---

So what happens when it DOESN'T pass back and forth freely???

It only passes TO the function and not BACK from it.

No error.  No exploding of code.  No vast destruction.  It just sends it the value directly to the SUB and runs with it.

Code: (Select All)

SUB abc (foo AS INTEGER)

Now, if we had the above, what would the following do?

Code: (Select All)

DIM x AS DOUBLE.
x = 3.14
abc x
x = 3.68
abc x

For the first call to abc, we'd pass the DOUBLE value of 3.14 to foo.  Foo, however is an integer.  Integers don't have fractions.  How is this handled without exploding a program??   It just rounds it to 3.

For the second call to abc, we pass the DOUBLE value of 3.68 to foo.  Again, foo is an integer.  Here it rounds that value to 4.

---

This is the way BASIC has always been.  Go back as far into the roots as you want and you'll see this behavior.  It doesn't error.  It doesn't explode.  It's non-destructive.

It just passes the value to the sub and then the type does whatever it needs to to accommodate it.  Pass that integer to your double.  Pass a double to your integer.  It'll work just fine.  It's *always* worked just fine.

Just don't expect to get that value back unless:
1) Does the type passed match the type in the Sub/Function?
2) Are we ONLY passing a matching variable and nothing more?
3) Are we free of any interposing syntax which might prevent value sharing, such as parenthesis?