I have a function that calls the OpenInsight "Field" function to parse a string. It used to work. Today I get an error "SYS1000: Error loading program FIELD". I set up a somple function to test "Field" and I get the same result when it is called.

---

FUNCTION test (void)

DECLARE FUNCTION FIELD

teststring=aaaa*bbbb*cccc*dddd"

key=Field (teststring,"*",1,1)

return key

---

The "Field" function exists in the repository so it it still there. Any ideas as to what might be wrong?

Greg,

Remove the space between the function name and the left parantheses in "Field (teststring,"*",1,1)".

- Oystein -

Greg,

I have a function that calls the OpenInsight "Field" function to parse a string.

The problem is that the "field" function is an internal operation of the BASIC+ language, just like the "+" (addition) operator or the "goto" statement. You must neither declare nor call the field function.

---

FUNCTION test (void)

teststring=aaaa*bbbb*cccc*dddd"

key=Field (teststring,"*",1,1)

return key

---

The "Field" function exists in the repository so it it still there.

The function exists in the repository because you declared it. In other words, you told the compiler that there is (or will be) a function called "Field" which you will be calling. So the compiler told the repository, "the function called test uses the function called field". The repository looks, realizes there is no "field" function, so it creates an entry for the purpose of keeping track of the relationship. That way, were you to create a function called "field", the repository would already be able to tell you where "field" was used.

After removing the "declare function field" and recompiling, you should delete that repository entity (assuming you do not actually have a function called "field").

Cameron Purdy

Revelation Software

Cameron,

I think you missed something. Function calls and internal operations look very similar. Both have the syntax F(P,P,…). But I've discovered that with a function call you can have a space between the function name and the parenthesis. With internal operations you can not.

If you have an internal operation with a space you get different results depending on if you also have a define statement. You either get a compilation error (no define statement) or a runtime error (if you have a define statement).

Your posting explains these results, of course.

- Oystein -

The reason it works like that is based on the compiler definitions. In order for a command to be imbedded into the language, the actual strucuture of the command needs to be stored in the language definition program (COMPILER.RUN). External functions and subroutines are loaded via the call opcodes and are considered statements, therefore whitespace is pretty much irrelevant. The declare function/subroutine name must just be followed by open paren, it doesn't care how far away. Internal funcitons must be imbedded exact. The compiler must be able to tell the difference between Delete and Delete(…) so the LH statement is stored as "Delete" and the MV manipulation function is loaded as "Delete(".

You can view this in the COMPILER.RUN program and see what commands are actually embedded.

akaplan@sprezzatura.com

Sprezzatura, Inc.

CamAaron@RevSprezz,

Don't get me wrong now - I really do appreciate your comprehensible explanations - but I fail to understand why this quirky syntax difference between function calls and internal operations must lead to such problems Greg had. If one accidentally puts a space after an internal operation one should get more than a "XXX has not been dimensioned or declared as a function" message. Certainly the compiler should have noe problems discovering that XXX is an internal function and issue something like "If you want to override the internal operation XXX with your own function, you must declare the function. If not, you must remove the space(s) before the left parenthesis". (Or isn't that macho enough?)

Also I think when you do want to override an internal operation, and declare your own function with the same name, you should get a compiler warning.

- Oystein -

Part of Greg's problem was that the FIELD function does not exist in his system. If you create your own FIELD function, then you get very different results.

The compiler doesn't know you want to override the function. How can it tell the difference between an accidental typo, missing a parameter or something, and an overload?

There's also the problem of handling internal functions that do not require all parameters to be filled, like FIELD and XLATE.

Again, it goes back to the compiler only recognizes the function as internal because the open parentheses directly follows. By nature of the compiler, it would have to literally check for each possible instance of white space and have it hard coded.

Part of the problem is you cant' define a rule before it's used, so there must be a specified order to what occurs when. Since it's generally not a good idea to replace an internal function, internals are defined and allocated for first.

I don't really want to get into a full explanation of the nature of the compiler. It's been a long time since I had to work with this stuff, and it's not the easist thing in the world to work with and describe when it's right in front of you, let alone after 4 years. For an example, here's a posting related to how a QBF request is converted to an OpenList statement for processing. Maybe, if Cam's in the mood, he can post a handfull of the Basic+ definitions so you can see what the structure is.

Now, some of this work could be done in the pre-compilers, but there would still be the problems of intent.

Still, if I declare a function that does not exist, I would expect to get an error at runtime.

akaplan@sprezzatura.com

Sprezzatura, Inc.

Aaron,

You know stuff about the Basic+ compiler and the compilation process that I don't. I'm just this naive person who's used to programming languages where internal and external function calls obey the exact same syntax, except for the external ones having to be declared. I always put my left parenthesis immediately after the function name, so I've never before come across these cases we now discuss. That distinction between internal and external functions is not something I'm acutely aware of when I program. After all if I use an external function without declaring it, the compiler tells me so in no uncertain terms. I just insert the missing declaration, and both the compiler and I are happy.

As I said I never put a space after a function name myself, but I have seen others do it, both in Basic+ (and I realize now they must have been external functions) and other programming languages. So even if I don't do it myself I had the impression it was valid Basic+ syntax. I had no reason to suspect internal functions were different from external ones. So if I against my habit should happen to have space after an internal function name, and the compiler told me the function wasn't declared, I'd immediately assume the function was external after all and put in a declare statement. Btw - I'd probably not think as precisely as that. I'd just put that declare statement in on pure reflex. The compilation would be successful, and I would have no idea whatsoever that the system assumed I referred to an as yet unwritten stored procedure instead of the internal function.

Until I ran the program. And perhaps not even then. The error message 'Error loading program "FIELD"' doesn't exactly tell you you have one space too many.

Now let's discuss something else.

- Oystein -

View this thread on the forum...