Foo.Bar.baz<tab> – deep tab completion

[StefanKarpinski]

We don't generally do tab completion when the thing to the left of the dot preceding the tab is more complicated than a name, since in the general case that would require evaluation of code in order to get the object to lookup names on. In the case where Foo is a module, however, evaluating Foo.Bar can't have any side-effects, so it would be safe to call names(Foo.Bar) in order to complete baz.

As a more general question, do we want to evaluate expressions to the left of dots when tab is pressed in order to do more general tab completion? It seems fairly unlikely that this would cause problems very often. This has come up a couple of times recently.

[vtjnash]

we should be able to utilize Base.effect_free to minimally compute this info. or force a call to typeinf in record mode on a function that just contains the desired code and look at the resulting return type (possibly by calling the function with the code wrapped in Expr(:static_typeof))

[StefanKarpinski]

I should point out that I now can't reproduce the first part of this issue, so it may have been due to odd REPL state. The broader question of what to do when the LHS of a tab completion requires evaluation remains. When type inference can tell us the type of the LHS, then we can compute the type without even needing to evaluate. When the expression is effect free, then we can evaluate it safely. I guess adding those two will cover a lot of cases, so we should probably start there.

[ivarne]

When a tab completion would require evaluation of unverified code, we should just give up and don't complete anything.

Inference and effect free will likely catch most situations, and if we are to go further, we'll need more analysis to ensure that the code will not print anything nor change global state (unless it is for logging purposes?). There might be a small number of cases where you can improve with more analysis, but basically I think we're back to the @pure function annotation as a way for a programmer to assert that the function will not rely on global state and will always give the same result for isequal arguments.

[nalimilan]

Also, even a pure function can take some time to compute, e.g. cor on a big matrix. Maybe we need a simple whitelist of functions from Base that can be evaluated without problems, and do not go beyond this.

[StefanKarpinski]

Or just stop at type inference, which is well bounded in time. If you can't type infer something, my impression is that it's unlikely that you can tell that it has no side-effects.

[vtjnash]

You might almost want to start with an effect-free argument evaluation pass (to handle non-const) then do a typeinf step

True though that effect-free (aka pure) doesn't fully imply fast. But currently effect-free does not accept branches, so that's ok

[dhoegh]

Can someone give me a hint on how to do type inference on an expression to get the return type? Then I would give a shot at implementing it into the REPL to close #6338. I know this is a simple example, but how can I make type interference return the return type of the following expression?

a=1
:(a+1+max(1, 2))

[timholy]

I'm only just learning my way around inference.jl, but I'd recommend starting with abstract_eval.

I put some comments about inference.jl in #10691; if there is interest, I should probably commit that separately.

[dhoegh]

I have made a little progress, by looking at return_types. Is there a way to force the inference to make assumptions about a global variable? I would like to be able to tell the return type of the following anonymous function.

a = 1
b = () -> (a + 1*10)
Core.Inference.typeinf(b.code, Tuple{}, b.env)[2]

If there is a way of obtain a list of the global variables in the anonymous function, then I could supply the variable as argument in the function as: (a) -> (a + 1*10). The type of a could then be determined and the return type obtained.

[timholy]

Presumably you need to get those into the "environment" (see variables named env) or perhaps the StaticVarInfo (see sv), but I can't yet offer any advice about how you'd go about doing that.

[dhoegh]

PR #15652 fix this issue, when it is merged.