Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/tools/go/types: Eval scope is insufficient #9980

Closed
rsc opened this issue Feb 24, 2015 · 2 comments
Closed

x/tools/go/types: Eval scope is insufficient #9980

rsc opened this issue Feb 24, 2015 · 2 comments

Comments

@rsc
Copy link
Contributor

rsc commented Feb 24, 2015

types.Eval claims to let you evaluate an expression in a given scope, but it's much more restricted than it appears.

In particular, in the terminology of the spec, it appears that there is a *types.Scope for each block, and it represents the scope at the end of that block. If you want to use a scope in the middle of that block, I don't see any easy way to pass it in. For example, suppose I have this program:

{
    const x = 1
    {
        const y = 2
        /* MARK */
        const x = 3
        use(x)
        use(y)
    }
    use(x)
}

I would like to evaluate "x" at the mark. If I walk the AST and the scope tree I can find out that the ** is in the inner block, but evaluating "x" in types.Scopes[that block] will give me 3. Since x has not yet been defined, the inner block's *Scope is not the right one. Maybe I could figure out a way to use an outer block to get the right "x".

But then suppose I want to evaluate "x + y" at the mark. I think that's impossible with the current API. My choices are to evaluate "x+y" at any closing brace of my choice. No closing brace gives me the value of x+y at the mark.

I think there's a simple fix. If there were an EvalPos that got both a *Scope and a token.Pos, then it could use the token.Pos of the identifiers it finds to filter out the ones that appear later in the scope than that position (in that case the search would walk outer scopes).

Similarly it might be nice to have a Scope.LookupPos that let you do the lookup at a given Pos within the scope.

@griesemer

@griesemer
Copy link
Contributor

The Eval* functionality was an afterthought - it indeed does only provide the state of scopes at the end of a block. I agree that providing position information as well should make it possible to use it as suggested.

@rsc rsc modified the milestones: Unplanned, Unreleased Apr 10, 2015
@rsc rsc removed the repo-tools label Apr 14, 2015
@gopherbot
Copy link

CL https://golang.org/cl/11122 mentions this issue.

@golang golang locked and limited conversation to collaborators Jun 25, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants