Re: Passing function parameters by reference

From your description, do I correctly infer that you allow
user-declared functions to be overloaded? Otherwise you could just
make a single pass over the actuals and formals lists in parallel. If
so, I presume the actual parameters can contain overloaded function
calls as well. Does the expected result type of the function
contribute to overload resolution, in addition to the types of the
parameters, as in Ada?


If your language semantics are anything like this, you will probably
have to and undoubtedly will find it easiest to make two passes over
an entire expression (or whatever is the largest possible context of
overload resolution), not just one function call at a time. During
the first, just do identifier resolution, overload resolution, and
type analysis. Store attribute values on the AST nodes with whatever
info is needed later. Then do code generation on the whole expression
in another pass.


If result types figure into overload resolution, you will need to
further split the semantic pass into a bottom-up pass and a top-down
pass. You may even have to sashay up and down. That is what I did in
an Ada 83 semantic analyzer. Eventually, I decided it could be done
in just two complete passes, only because of fortuitious interactions
among several of the special case builtin and non-overloadable
operators which have less than the fully general flow of overload
information in all directions. I can't believe it was by design,
since it was several years after the language was initially defined
that people began to get a thorough understanding of how to analyze.


One alternative to two passes of semantic analysis is to have only
one, bottom-up pass which makes copies of AST subtrees with different
type analyses, then at the top, simply abandons as garbage, all those
but the (hopefully) one which fits the topmost expected type rules.


Then again, maybe your overload semantics are such that you can
completely resolve a single function call in isolation. If so, you
can probably do semantics in one pass, but I think even in that case,
you need a semantics and a code-generation pass over an entire
expression.


Emmanuel Boutin wrote:
>
>> The problem I'm facing is a chicken & egg one :
> - in the AST, I have a function_call node that basically contains an
> identifier and a list of expressions nodes
> - when I translate this node into code nodes, I first traverse the list of
> expressions for the parameters which gives me a list of translated
> expressions. It also gives me a list of types. I use the list of types +
> identifier to find a matching function. I then use the function's exact
> signature to determine the way I should pass the parameters to the function.
> - but it's too late. I've already translated all the arguments into code.
> Even l-values have been translated into values. The distinction I make
> between l-values and values is that l-values are only an address on the
> stack whereas values are entirely stored on the stack.
--
Rodney M. Bates

Return to the comp.compilers page.
Search the comp.compilers archives again.