JeremyNicoll wrote: ↑Sat 04 Mar 2023, 10:48
I would have expected the code inside however it is that you implement MID$ to validity check the values of 'start' and 'length'...
Of course it does. Anyway it's irrelevant to the question under discussion, nobody has suggested that any of the parameters is 'out of range'.
Also as the formal parms for MID$ are local to that function...
What do you mean by "local to that function"? Any or all of the parameters could be 'non-local' if they include user-defined functions:
Code: Select all
result$ = MID$(FNsource, FNstart, FNcount)
Of course the interpreter would be made much simpler if one were to require that user-defined functions may not be used as the parameters to other functions, but then it would neither be BBC BASIC, nor any dialect of BASIC that I've ever encountered.
I'd welcome an example of an edge case where this could happen.
Here's a little program I wrote to check whether it misbehaves in other versions of BBC BASIC, including the original 6502 version from 1981. It doesn't, because they have all been coded with that possibility in mind:
Code: Select all
10 global$ = "AAAAAAAA"
20 PRINT MID$(global$, FNstart, FNcount)
30 END
40
50 DEF FNstart
60 global$ = "BBBBBBBB"
70 = 2
80
90 DEF FNcount
100 global$ = "CCCCCCCC"
110 = 4
You can't tell me that in any sane programming language the correct result would be anything other than "AAAA".
When you say "If /you/ do it naively" ... do you mean "you" as in the implementer of the language?
I'm using "you" in the normal sense of "one", or "anybody" or "the programmer". What else could I have meant?
It's completely irrelevant that - lexically - the names of the formal parameters happen to match any of those used,...
It's relevant to the
implementation of the interpreter, that's the whole point. A naïve implementation will copy the first 'actual' parameter into the first 'formal' parameter, then the second 'actual' parameter into the second 'formal' parameter and so on. That will fail in the example I gave.
If you are suggesting that all programmers of interpreters are so familiar with the issue that they would never make such a mistake, then it's you who is being naïve!
I don't see how this theoretical example (of how not to implement parameter passing) has any bearing on the reason that MID$ was slow in the programming challenge.
The connection is this:
both the MID$() example
and the parameter-passing example require the source string(s) to be temporarily copied, typically onto the stack. It is the time taken for this copy or copies that can be significant.
In general I think I'd expect a programmer [to be] aware that the A$ that will be passed to MID$ isn't necessarily the same as A$ was prior to the statement containing the call.
Really? Can you name
any programming language which has such a requirement? BASIC, which is supposedly a language for 'beginners' and is expected to behave in a common-sense way, does not place any such expectation on the programmer. If he passes a string as a parameter to a built-in function, he should (and can) expect that to be the string on which the function ultimately operates.
Is there anywhere in the BBC BASIC manual where you describe this potential problem?
It
isn't a problem in BBC BASIC!! It's
you who are arguing that the extra work that the interpreter does to avoid the problem isn't necessary, and that the programmer should be aware of, and if necessary work around, the resulting misbehaviour himself. Then there
would be a need to document it!