Greetings Stephan,
This is actually a very interesting example. Well, interesting to me anyway (which I guess explains the length of this post).
I can repeat what you are showing, but its not that 9.2.2 is incorrect...its just that 10.0.0 has new type reconstruction capability that allows it to know exactly the types involved.
When I do the following in 9.2.2
Float emax = Float em<code completion request>
what I see are a listing of entries...some with precedence arrows...Some without.
I see 2 entries for emax. Look near the bottom and you will see the one without the precedence arrow. That is the one that applies to the Float receiver. The other one applies to the (Float emax = Float) expression receiver.
When I do this in 10.0.0, I only see a single #emax entry for the Float receiver.
Why?
The answer starts all the way back at the first instance of 'Float emax'.
In 9.2.2, the type of the expression 'Float emax' is unresolved...so its going to show you all possible suggestions.
The reason the type is unresolved is that there isn't any logic that would tell it how to look inside the method Float>>emax and then attempt to figure out what the return type is.
In 10.0.0...there is. Its using bytecode analysis.
10.0.0 has 2 additional type reconstruction/analysis features. Bytecode analysis and Type annotations.
Bytecode Analysis
If you look inside Float>>emax you see a very simple ^308.
Therefore, the return type of Float>>emax is <SmallInteger>.
This seems like a pretty easy method to type using the existing machinery which uses a combination of token and parse-tree analysis.
However, these types of analysis require source code. It turns out that its not a great idea to have the tooling go around loading up CompiledMethod source from ENVY in a recursive manner as it tries to type expressions.
Therefore, if we branch out and start peering inside compiled methods...its better to analyze the already loaded bytecodes rather than make ENVY requests for source code.
As of 10.0.0, we introduced a bytecode analyzer that can identify patterns of bytecodes and, if required, type analyze arguments encoded in the bytecodes or as literals which the bytecode indirectly refer to.
So in 10.0.0, if you request code completion for the 'Float emax' expression, you will see that it is resolved as the type <SmallInteger>.
Since it knows 'Float emax' is of type <SmallInteger>, it then goes on to type the expression 'Float emax = Float'.
And it knows this means it must bytecode analyze the method SmallInteger>>=.
By doing so it sees a primitive call to <VMprSmallIntegerEqual> inside that method which it knows is of return type <Boolean>.
Now back to our original example
Float emax = Float <code completion request>.
Instead of resolving it to the aggregate type <Unresolved, Float> that was in 9.2.2
10.0.0 considers that expression to be the aggregate type <Boolean, Float>.
And emax is only implemented (normally) in Float and not Boolean...so the choice is obvious because there is only one.
The bottom line is that typing information flows through the expressions in a method. Typing things successfully as early as possible
can give great information later that almost seems like magic (as some have put it to me). Well its not magic...its just a lot of analysis that
is all connected. Its great for code completion but its also great for analyzers that are looking to see if the types are still flowing feasibly as
you refactor your methods. I've been saved many times earlier by such refactorings that would have gone out the door as DoNotUnderstand errors.
Most I might have caught thought SUnit tests...but its questionable for some and the goal is always to fail early.
Type Annotations
EsAsynchronousSupport is a new application that has type annotations for EsFuture and EsPromise.
Type Annotations describe return types and argument types. This is connected to both code completion and type analysis
and will help the type resolver out if it knows which method(s) are involved because it knows how to peer
inside and extract that type information.
Hope that this explanation helps.
- Seth
On Wednesday, March 17, 2021 at 10:56:21 AM UTC-4
[hidden email] wrote:
Hey Seth,
sorry for the late reply, but now I have a concrete example of the problem for reproduction.
I am talking about auto completion here and I also think that the problem of the thread creator also is with auto completion and not formatting.
If you enter by hand:
Float emax = Float emax
and if you use autocompletion for the last method it turns into
(Float emax = Float) emax
This happens within a hierarchy browser on 9.2.2 but I also checked on 10.0.0 ecap and there I do not see this.
Maybe it got fixed but maybe the settings are just different. But I would prefer to not get brackets at all instead of wrong ones.
Stephan
Seth Berman schrieb am Mittwoch, 19. Februar 2020 um 16:22:11 UTC+1:
Greetings Stephan,
Are we talking about the autocompletion behavior, or the original formatting issue?
The simple answer is the expression that you show is highly ambiguous in terms of what is meant by 'self exportFileExtension, ';', self' followed by a completion request.
Its simply can't possibly know what part of the expression you are referring to. This makes the smalltalk syntax tougher than any C language with regards to code completion.
There are settings to change how precedence is presented if the way your "brain" works differs from that of the author "me".
Those settings should be described on that same page in the documentation as well.
- Seth
On Wednesday, February 19, 2020 at 4:10:45 AM UTC-5, Stephan Henke wrote:
I just observed:
^(self exportFileExtension, ';', self) exportFileExtension64
I think I used the autocompletion for the last method.
--
You received this message because you are subscribed to the Google Groups "VAST Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
[hidden email].
To view this discussion on the web visit
https://groups.google.com/d/msgid/va-smalltalk/bb38aaf2-db4e-447d-b0c1-9d818ee2358bn%40googlegroups.com.
Locked
Screen Shot 2020-01-23 at 12.45.38 PM.png (177K)