Will FP ever have a great Stack Trace story in JS?
Okay, let's break this down. Your example stack trace is really not a bad story.
Error: Invariant Violation: createClass(...): Class specification must implement a
rendermethod.
at invariant (/Users/jasonkuhrt/code/test/node_modules/react/lib/invariant.js:42:15)
at ReactClass.createClass (/Users/jasonkuhrt/code/test/node_modules/react/lib/ReactClass.js:898:46)
at /Users/jasonkuhrt/code/test/component-factory.js:4:41
at Object.<anonymous> (/Users/jasonkuhrt/code/test/test.js:4:1)
at Module._compile (module.js:434:26)
at normalLoader (/usr/local/lib/node_modules/babel/node_modules/babel-core/lib/api/register/node.js:199:5)
at Object.require.extensions.(anonymous function) [as .js] (/usr/local/lib/node_modules/babel/node_modules/babel-core/lib/api/register/node.js:216:7)
at Module.load (module.js:355:32)
at Function.Module._load (module.js:310:12)
at Function.Module.runMain (module.js:475:10)
First off, you need to remove all the module loading-related stuff:
Error: Invariant Violation: createClass(...): Class specification must implement a
rendermethod.
at invariant (/Users/jasonkuhrt/code/test/node_modules/react/lib/invariant.js:42:15)
at ReactClass.createClass (/Users/jasonkuhrt/code/test/node_modules/react/lib/ReactClass.js:898:46)
at /Users/jasonkuhrt/code/test/component-factory.js:4:41
at Object.<anonymous> (/Users/jasonkuhrt/code/test/test.js:4:1)
Now, You're left with test code and the internal stack trace of React. Remove the React stuff and you have:
Error: Invariant Violation: createClass(...): Class specification must implement a
rendermethod.
at /Users/jasonkuhrt/code/test/component-factory.js:4:41
at Object.<anonymous> (/Users/jasonkuhrt/code/test/test.js:4:1)
I'm assuming that 2nd item is just the test itself so let's kill that too.
Error: Invariant Violation: createClass(...): Class specification must implement a
rendermethod.
at /Users/jasonkuhrt/code/test/component-factory.js:4:41
So your error is around line 4 of /code/test/component-factory.js, and the error is that you created a React class without a render method.
I don't see what was bad about that, you certainly wouldn't want remove any of that stack trace as it's all real operations that might need debugging.
I also don't see what this has to do with your FP example of:
let compose = (b, a) => (...as) => b(a(...as))
As that's clearly not the issue in your stack trace.
Also, if you want these stack traces to be more meaningful, you should be talking to the JavaScript engine implementor. In your case v8 (since you're using Node).
— This email brought to you by the letters T, J, and K.
For some reason the email I wrote was cut off. In practice the stack trace gets worse, my test was just too easy. The last stack trace was based around using compose from ramda. The stack trace result was:
Error: Invariant Violation: createClass(...): Class specification must implement a `render` method.
at invariant (/Users/jasonkuhrt/code/test/node_modules/react/lib/invariant.js:42:15)
at ReactClass.createClass (/Users/jasonkuhrt/code/test/node_modules/react/lib/ReactClass.js:898:46)
at /Users/jasonkuhrt/code/test/node_modules/ramda/dist/ramda.js:384:35
at f1 (/Users/jasonkuhrt/code/test/node_modules/ramda/dist/ramda.js:156:27)
at Object.<anonymous> (/Users/jasonkuhrt/code/test/test.js:4:1)
Also I disagree with your assessment that I should go talk to the vendors. For example Axel R.’s recent post on Function names www.2ality.com/2015/09/function-names-es6.html, www.2ality.com/2015/09/function-names-es6.html states in Section 2 the case where there is no name. I clarified on Twitter with him just now twitter.com/JasonKuhrt/status/644312567012323328, twitter.com/JasonKuhrt/status/644312567012323328 that indeed the first ident assignment to an anon function will set its name. This is all thanks to JS 2015 not vendors (of course we need their compliance next).
So given the above in the future a compose function such as
let compose = (b, a) => (...as) => b(a(...as))
that is used like so:
const componentFactory = compose(React.createFactory, React.createClass)
Should have great stack trace support e.g.:
at componentFactory (/Users/jasonkuhrt/code/test/component-factory.js:1:36)
So the reason I wrote this email is partially negated by Axel’s helpful information. However I’m still curious in any other thoughts trotting around for near or future about how to make the situation better around naming functions?
Not quite, the mechanism which does this in the spec is SetFunctionName (www.ecma-international.org/ecma-262/6.0/#sec-setfunctionname, www.ecma-international.org/ecma-262/6.0/#sec-setfunctionname), and it only works for specific syntactic constructs (eg, foo = function() {} -> anonymous function is named “foo”, let x = () => {} -> anonymous arrow is named “x”, etc).
It does not apply to things like compose(thingA, thingB), which is not an anonymous function definition.These function names aren’t set at runtime, it’s a parse-time operation, and depends on the productions that are parsed.
Oh shoot, that’s my misunderstanding of his response I guess.
So back to square zero.
Not quite, the mechanism which does this in the spec is SetFunctionName (www.ecma-international.org/ecma-262/6.0/#sec-setfunctionname, www.ecma-international.org/ecma-262/6.0/#sec-setfunctionname), and it only works for specific syntactic constructs (eg,
foo = function() {}-> anonymous function is named “foo”, let x = () => {} -> anonymous arrow is named “x”, etc).It does not apply to things like
compose(thingA, thingB), which is not an anonymous function definition.These function names aren’t set at runtime, it’s a parse-time operation, and depends on the productions that are parsed.
Ah, fascinating! That’s something that I overlooked. It is an odd mix of static and dynamic, though.
For example: www.ecma-international.org/ecma-262/6.0/#sec-assignment-operators-runtime-semantics-evaluation, www.ecma-international.org/ecma-262/6.0/#sec-assignment-operators-runtime-semantics-evaluation
My understanding:
– The actions themselves happen at runtime, not at compile time. – (1.e) IsAnonymousFunctionDefinition() is a static check that only holds if AssignmentExpression is an anonymous function expression (syntactically). – (1.e.i) is a dynamic check, SetFunctionName() happens dynamically, too.
Wouldn’t it make sense to turn IsAnonymousFunctionDefinition() into a dynamic check, too? A check whether rval is a function should suffice (given the check whether property name exists, later).
Personally I'm already slightly weirded by the static behaviour - doing
this dynamically would result in cases where a function which is otherwise
anonymous would happen to claim the first name of many that it's assigned
to throughout its lifetime. This would actually be observable at runtime as
name changing. Or maybe I'm overlooking something.
Better IMO is if the stack trace would always include the name of the
function as it was called, in addition to the function's own name,
assuming its presence. That, assuming thoughtfully named variables,
might give a little extra immediate insight into the call stack. Obviously
if the function call had no name, i.e. it was an arbitrary expression, we'd
have to skip this.
Alex
Note that making this behavior dynamic means that every assignment operation would have to explicitly check whether or not its RHS dynamically evaluated to a function object, and if so whether the function already had a name property. That's real, measurable runtime cost being added to every assignment.
Realistically, that's just not going to happen.
For example, today, a stone from the bedrock of FP:
will cause a JS Stack Trace to go from something useful (space around useful line) like:
To something much less useful like this:
And ultimately being in a real-life scenario/library/etc. (e.g. Ramda compose) leading to something almost useless: