Differentiating functions, methods and constructors

[Mike In Chicago]

On page 234 of Chapter 11, under the sub-heading "Subroutine Calling", it states that:

"Before calling a VM function, the caller (itself a VM function) must push the function's argument onto the stack.  If the called VM function corresponds to a Jack method, the first pushed argument must be a reference to the object on which the method is supposed to operate."

Here is my question: when calling a subroutine, how can you tell whether a particular subroutine being called is a method or a call or a function?

[cadet1620]

Mike In Chicago wrote

When calling a subroutine, how can you tell whether a particular subroutine being called is a method or a call or a function?

The two types of calls are syntactically identical, so you need to look at the category of the symbol on the left of the '.'

--Mark

[Mike In Chicago]

Thank you for the fast response, Mark.  

I understand, for example, that if you make an "OS" type call, that's going to be a function.  

And if you make a call to the subroutine from another class, that could be either a method or a constructor.

However, how can you tell whether a call made to a subroutine within the same class is a function or a method?

Thanks again for your help!

[cadet1620]

"do f(x);" always calls method f in the current class.  It is an error to make this call in a function.

"do sym.f(x);" calls method f in class ClassName if sym is a data type symbol -- field, static, var -- of type ClassName.  If sym's type is not ClassName, its an error.
If sym is not a data type symbol, assume it is a class name and call function f in class sym.

--Mark

[Mike In Chicago]

Thanks again Mark.  Your insights are very helpful. I will mull this over a bit and hopefully make sense of it all!

[cheeseburgers37]

This question seems to be relevant to this post.

I noticed that the supplied compiler makes sure that if I have:

do obj.func(...);

if checks that func exists as a member of obj's type. But the reading from chapter 11 seems to say that we don't need to do this kind of checking with our compiler.

sect 11.3.3 wrote

When compiling error-free Jack code, any identifier not found in the symbol table may be assumed to be a
subroutine name or a class name. Since the Jack language syntax rules suffice for distinguishing between
these two possibilities, and since no “linking” needs to be done by the compiler, there is no need to keep
these identifiers in the symbol table.

Don't we need to keep the names of object functions/methods somewhere to check that they exist when we want to call the from outside the class where they are defined later?

Am I right in thinking the book doesn't intend for us to check that methods being called on objects actually exist? If that's the case, any reason why we shouldn't be doing this?

Thanks

[cadet1620]

cheeseburgers37 wrote

Don't we need to keep the names of object functions/methods somewhere to check that they exist when we want to call the from outside the class where they are defined later?

Am I right in thinking the book doesn't intend for us to check that methods being called on objects actually exist? If that's the case, any reason why we shouldn't be doing this?

Thanks

As the book says, you don't need to know if an external class/function exists or what type of thing it is. You can assume that it exists, and you can infer its type from its usage syntax.  However, if it in fact doesn't exist, it can be tough to debug since the assembler assigns a RAM address to the undefined symbol. It's nice that the supplied compiler validates this.

Good error handling in a compiler can be a lot of work, which is why the book doesn't require it. At a minimum, you need to make your compiler two-pass like your assembler, so that it knows if a symbol is defined when it is forward referenced.

--Mark

[cheeseburgers37]

Sounds great, thanks for clarifying that for me!