Re: Move util functions from DefaultParametersTransformer.js to src/semantics/util.js (issue 7509043)

2 views
Skip to first unread message

a...@chromium.org

unread,
Mar 26, 2013, 3:18:38 PM3/26/13
to usrb...@yahoo.com, edy....@gmail.com, traceur-comp...@googlegroups.com, re...@codereview-hr.appspotmail.com

https://codereview.appspot.com/7509043/diff/1/src/semantics/util.js
File src/semantics/util.js (right):

https://codereview.appspot.com/7509043/diff/1/src/semantics/util.js#newcode65
src/semantics/util.js:65: return tree.type === UNARY_EXPRESSION &&
tree.operator.type === VOID &&
On 2013/03/26 18:52:35, edy.burt wrote:
> VOID is not imported

Fixed in
https://code.google.com/p/traceur-compiler/source/detail?r=4b95bde73a18eb815e6c4bd22fe560677cef7208

https://codereview.appspot.com/7509043/

usrb...@yahoo.com

unread,
Mar 26, 2013, 3:41:29 PM3/26/13
to a...@chromium.org, edy....@gmail.com, traceur-comp...@googlegroups.com, re...@codereview-hr.appspotmail.com
> VOID is not imported

Thanks for the bug fix. One thing I found interesting was that running

./traceur --free-variable-checker --out bin/traceur.js -- \
src/traceur.js src/runtime/runtime.js

uncovered the error easily (though there are also some false positives).

Here is the full list of errors (pre-patch).

../src/WebPageProject.js:49:19: XMLHttpRequest is not defined
../src/semantics/util.js:65:67: VOID is not defined
../src/syntax/LiteralToken.js:94:45: next is not defined
../src/outputgeneration/SourceMapIntegration.js:64:18: require is not
defined
../src/outputgeneration/SourceMapIntegration.js:64:38: module is not
defined
../src/WebPageProject.js:128:25: document is not defined

Most of these indicate that we eventually need to have an external var
declaration system, and some of these ('require' and 'module' dependent
on the existence of 'define') might even require some sort of scripting
ability of that declaration system.

And there's definitely a bug in LiteralToken.js

----

I wonder if it might be a good idea to turn on freeVariableChecker once
we do get an external var declaration system (TypeScript has a better
name for it, but I forget right now) -- and once I can figure out how to
selectively disable freeVariableChecker using nolint.

The trouble is making sure the information makes it all the way down the
transformation chain. I think the easiest way is to add a 'tag'
attribute that would be a catch-all for this kind of meta-information.

Can't type much more right now (lucky for you), but something like that.


https://codereview.appspot.com/7509043/

a...@chromium.org

unread,
Mar 26, 2013, 3:55:30 PM3/26/13
to usrb...@yahoo.com, edy....@gmail.com, traceur-comp...@googlegroups.com, re...@codereview-hr.appspotmail.com
At one point I hacked up a version of free variable checker that took a
list of free variable names instead of (as well as) inspecting the
global object. Maybe this is worth doing again?

https://codereview.appspot.com/7509043/

usrb...@yahoo.com

unread,
Mar 26, 2013, 5:14:44 PM3/26/13
to a...@chromium.org, edy....@gmail.com, traceur-comp...@googlegroups.com, re...@codereview-hr.appspotmail.com
> At one point I hacked up a version of free variable checker that took
> a list of free variable names instead of (as well as) inspecting the
> global object. Maybe this is worth doing again?

I think it's definitely worth doing. Not that I wasn't before, but this
recent bug fix has left no doubt. It's one less thing to think about,
which leaves more brain cells free for tasks that computers aren't good
at -- writing programs, as opposed to running them.

Oddly enough, I have no use for IDEs. There are certain things you
just have to know cold. Humans are actually good at that, if the
number of things isn't too much. And if they have backup. Because
everyone messes up every once in awhile.

I guess the only question is how we're going to interface with it --
through magic comments, some kind of syntax, or just programmatically
through some sort of plugin or scripting system?

Typescript uses these things called "typings" or definition files.


http://typescript.codeplex.com/SourceControl/changeset/view/ac38ce9e29b3#typings/jquery.d.ts

They also have something called "ambient declarations".


http://www.typescriptlang.org/Content/TypeScript%20Language%20Specification.pdf

declare var document;
document.title = "Hello"; // Ok because document has been declared

I think adding syntax is a little too heavyweight, especially since it's
not even part of the spec.

Magic comments? Maybe. Though that's a slippery slope, and you might end
up with closure-compiler all over again. And I don't think Peter would
approve of that.

I think scripting is probably the easiest, and the most powerful. I
know, with great power comes great... yada yada. Just give me the power
already!

Well, maybe some simple magic comments, as long as we keep it dead
simple. I don't think it's worth trying to declare what members of an
object are valid. Though I guess we could just generate these
complicated magic comments, which wouldn't be that bad.

At that point, maybe just syntax, in a dedicated file that doesn't
participate at all in the compilation at all except during the
checking phase.

Wait. That's 'typings' all over again.

But if you're going to do that, you might as well just use JS
scripting. That way you have a much more expressive language, plus you
don't even have to write or modify the parser.

I'm thinking in addition to a simple list, the ability to pass in a
function that takes the current scope chain and the current var name
being checked as arguments, and returns true if it's "on the list" and
false if it should get back in line and wait for the normal checking
procedure to go through all the vars.

butabi = 42; // what do you mean, I'm not on the list!


https://codereview.appspot.com/7509043/
Reply all
Reply to author
Forward
0 new messages