Finding function calls in javascript source.

[John J. Barton]

I want to add a "dynamic call stack" feature to Firebug. Of course
"dynamic" and "call stack" are redundant, but Firebug's current call
stack representation is "lexical" and most developers expect it to be
lexical.

To implement a dynamic call stack I need the expression that selected
the function called. For example consider:

function foo_NFE() {
return baz_NFE(); // how should we label this call?
}
var bar_NFE = function bar_NFE(){
debugger;
};
var baz_NFE = bar_NFE;
bar_NFE = "die";

In the static case, the call stack at debugger will have
bar_NFE()
foo_NFE()
In the dynamic case we want:
baz_NFE
foo_NFE()

So I need an algorithm for finding the call expression that is
independent of the number of source lines, something like: apply a
regular expression to the calling line, eg
return baz_NFE();
I know anything short of parsing will fail, but we don't have time to
parse to we have to accept failures.

Any pointers to regexp that work well for this or alternatives would be
helpful.

jjb

[Donny Viszneki]

On Thu, Dec 31, 2009 at 4:53 PM, John J. Barton
<johnj...@johnjbarton.com> wrote:
> So I need an algorithm for finding the call expression that is independent
> of the number of source lines, something like: apply a regular expression to
> the calling line, eg

Assuming I understand you correctly, there is already some support for
this sort of thing:

js> var foo = {}
js> function bar() { return foo }
js> function baz() { bar().x() }
js> baz()
typein:4: TypeError: bar().x is not a function

As you can see, the interpreter reports the error beautifully, giving
us the exact expression that failed.

What you're asking for seems to be a little different, but this might
be a good starting point for exposing the functionality you're asking
for (assuming that I understand it correctly. Your explanation was a
little confusing. What was with the _NFE stuff anyway? Seemed totally
superfluous to me..)

--
http://codebad.com/

[John J. Barton]

Donny Viszneki wrote:
> On Thu, Dec 31, 2009 at 4:53 PM, John J. Barton
> <johnj...@johnjbarton.com> wrote:
>> So I need an algorithm for finding the call expression that is independent
>> of the number of source lines, something like: apply a regular expression to
>> the calling line, eg
>
> Assuming I understand you correctly, there is already some support for
> this sort of thing:
>
> js> var foo = {}
> js> function bar() { return foo }
> js> function baz() { bar().x() }
> js> baz()
> typein:4: TypeError: bar().x is not a function
>
> As you can see, the interpreter reports the error beautifully, giving
> us the exact expression that failed.

I failed to also tell you I need this to be pure Javascript. So I don't
know what to do with the observation above.

> What you're asking for seems to be a little different, but this might
> be a good starting point for exposing the functionality you're asking
> for (assuming that I understand it correctly. Your explanation was a
> little confusing. What was with the _NFE stuff anyway? Seemed totally
> superfluous to me..)

Sorry, the example was copied from a test case for Named Function
Expressions, hence the _NFE. But the names are arbitrary in any case.

jjb

[Donny Viszneki]

On Fri, Jan 1, 2010 at 11:46 PM, John J. Barton

<johnj...@johnjbarton.com> wrote:
> Donny Viszneki wrote:
>>
>> On Thu, Dec 31, 2009 at 4:53 PM, John J. Barton
>> <johnj...@johnjbarton.com> wrote:
>>>
>>> So I need an algorithm for finding the call expression that is
>>> independent
>>> of the number of source lines, something like: apply a regular expression
>>> to
>>> the calling line, eg
>>
>> Assuming I understand you correctly, there is already some support for
>> this sort of thing:
>>
>> js> var foo = {}
>> js> function bar() { return foo }
>> js> function baz() { bar().x() }
>> js> baz()
>> typein:4: TypeError: bar().x is not a function
>>
>> As you can see, the interpreter reports the error beautifully, giving
>> us the exact expression that failed.
>
> I failed to also tell you I need this to be pure Javascript. So I don't know
> what to do with the observation above.

Sorry for being confusing. That's no special feature of the
command-line interface to the Spidermonkey interpreter:

js> try { ({}).x() } catch (e) { print(typeof e.message, e.message) }
string ({}).x is not a function

That should work as-is in Firefox.

I'm saying that the code exists in Spidermonkey, somewhere, and
perhaps would be a good place to start exposing a Spidermonkey API for
more powerful stack inspection.

--
http://codebad.com/

[John J. Barton]

Donny Viszneki wrote:
> On Fri, Jan 1, 2010 at 11:46 PM, John J. Barton
> <johnj...@johnjbarton.com> wrote:
>> Donny Viszneki wrote:
>>> On Thu, Dec 31, 2009 at 4:53 PM, John J. Barton
>>> <johnj...@johnjbarton.com> wrote:
>>>> So I need an algorithm for finding the call expression that is
>>>> independent

>>>> of the number of source lines, ...

> I'm saying that the code exists in Spidermonkey, somewhere, and
> perhaps would be a good place to start exposing a Spidermonkey API for
> more powerful stack inspection.

Unfortunately after reading more on this I think this may be the only
path. Given
Expression(arguments);
then Expression could result in a computed intermediate value. We can't
compute it again in the debugger since the computation could have side
effects. We can't access it in the debugger because we don't have access
to the intermediate values.

jjb