Move util functions from DefaultParametersTransformer.js to src/semantics/util.js

Move util functions from DefaultParametersTransformer.js to src/semantics/util.js

BUG=None
TEST=None

[usrbincc, 2013-03-06 16:05:27]

I realized (kind of late) that I should probably break out
the semantics/util.js re-org from

  https://codereview.appspot.com/7447045/

into its own patch.

In the future, how should I handle this kind of patch
splitting? It does kind of break the flow of code review,
but it makes for a cleaner history.

#--cut--
git checkout 4bb5709e44bba2ea   # last merge with branch master

git checkout -b
issue7509043-yield-expr-6-return-value-3pre-move-to-semantics-util

test -e issue7509043_1.diff || curl -sO \
  https://codereview.appspot.com/download/issue7509043_1.diff
openssl sha1 < issue7509043_1.diff \
  | { grep -q '96e5c091dc3c74205a121282ffcfd2d3857dd4cc$' &&
      git apply issue7509043_1.diff
    } || echo sha1 mismatch!

make test
#--cut--

[arv, 2013-03-06 17:38:53]

LGTM

Committed as f1c6f630de05bf3d9a1fe4a41323b0d31bd2da06

[arv, 2013-03-06 17:40:39]

On 2013/03/06 16:05:27, usrbincc wrote:
> In the future, how should I handle this kind of patch
> splitting? It does kind of break the flow of code review,
> but it makes for a cleaner history.

I think it is up to you. Of course it is better to split things up but it does
take more time and effort to do it and that time and effort might be better
spent elsewhere.

From a reviewer's perspective it makes things easier.

[usrbincc, 2013-03-07 15:07:53]

> I think it is up to you. Of course it is better to split
> things up but it does take more time and effort to do it
> and that time and effort might be better spent elsewhere.

I'll probably keep with it then (within reason).

I've gotten pretty good lately at making lots of small
commits (or using 'git add --patch' if I forget) so it's
actually not too bad. Create a new branch, 'git cherry-pick'
or 'git rebase --interactive', and it's done.

I never really appreciated the flexibility git gives you to
shape and merge branches until working with traceur
(Normally, I tend to keep things pretty much linear).

  And just as important, the ability to undo just about any
  mistake you make while doing these manipulations.

[eddyb, 2013-03-26 18:52:35]

There is a small bug with this patch, VOID is not imported from ParseTreeType,
and isVoidExpression causes a ReferenceError to be thrown.

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 &&
VOID is not imported

[arv, 2013-03-26 19:18:38]

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=4b95bde73a18eb815e...

[usrbincc, 2013-03-26 19:41:29]

> 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.

[arv, 2013-03-26 19:55:30]

On 2013/03/26 19:41:29, usrbincc wrote:
> > 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.

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?

[usrbincc, 2013-03-26 21:14:43]

> 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#typi...

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!