Codea Type Annotations

General
1

Hey everyone

One of the things I’ve been focusing on in Codea is adding some level of type inference, as well as type annotations, to the editor

This is coming in Codea 3.7 (360) so you can try it out on the beta, but basically it means that Codea tries to figure out the type of the object you are referring to in order to provide better autocomplete. In practice, this looks like:

local myVec = vec2(4, 5)

myVec: ... -- here you now get completions appropriate to vec2 methods

Better Completions
Better Completions2388×576 48.9 KB

Another example is:

--- objc.app: objc.UIApplication

objc.app. ... -- here you get completions for UIApplication

In the second example you can see that we now have a new comment type (---). Typing this above a variable definition or assignment will pre-fill the comment with what Codea thinks the type of that variable is. Then you can override the type by changing it to something else. The comment effects the variable in the scope it is written

Variable Annotations

For now, we are pulling type information from the documentation, as well as from the Objective-C runtime (for objc. types). We hope to soon pull the same data for your custom types

Basically, this is all to make Lua a little more friendly and allow some level of control over its dynamic behaviour

Finally, typing --- above a function definition will auto-complete a new function documentation template, allowing you to define the types, return type, name, and so on. We’re going to try and use this information too (at the moment it is unused)

Function Annotations

2 Likes
2

@sim This looks interesting, but will take some time to play with it. Not one of those changes that either works or doesn’t. Have to write some code and see what all the differences are or pull up some existing code and type the three -‘s to see what shows.

3

Thanks for taking a look! The idea is that they can be used to tell Codea what the type of a variable or function is. Codea tries to make a guess, but with a language like Lua that is sometimes impossible. So this lets you say “I know x is definitely a vec2”. Then in the future we will be able to warn if it’s used as something else, and provide completions where appropriate

4

@sim Playing with this some more. I ran across this for multiple variables on the same line, a,b.

function setup()
— b: any
a,b=10,20
— c: number
c=30
end

5

Hah nice find. The parser doesn’t handle multiple assignments but that’s a possibility. Do you use that syntax often?

6

@sim I use multiple assignments all the time. I found one of my projects that had 9 on one line and 8 on the next line.

3 Likes
7

The code completion for objc would have helped a lot when I wrote some code for bluetooth.

I saw that writing ”NSData():” doesnt give any suggestions, but when writing ”x = NSData()” and then ”x:” I get suggestions.

1 Like
8

yes i use multi assigment frequently

1 Like
9

Yeah it’s not that smart (yet), for now it uses an assignment to determine the type. The ObjC completions are very handy given how long some of them are!

10

That’s good to know! Will look at how to handle multi-assignment

11
  1. Is there a way to set the type of return from functions?
    If not, here is my proposal:
--- myFunc <description> return: <type> <description>
function myFunc() return 123 end
  1. Is there a way to set alternative type?
    If not, here is my proposal:
--- tableMaybe: table|nil <description>
local tableMaybe
  1. Is there a way to set annotation for function stored in variable?
    If not, here is my proposal:
--- (table, value): <type>, <type>
local ti=table.insert

This can work with multiple assignement too:

--- a, b: <type>, <type>
local a,b=123,345
12

These type annotations are very much in development, so it’s great to get your feedback!

  1. Not at the moment, but I think syntax wise, this works (though it means you can’t have a parameter named “returns”):
--- Flapper:init <description>
--- x: <type>
--- y: <type>
--- speed: <type>
--- returns: <type>
  1. What do you think of optional syntax like table?, we could use the question mark. I don’t mind table|nil, but it implies other mixed-types are possible (eg table|number), and I don’t know about going down that path.

Realistically, we might ignore optionals all together for now (everything is optional). Then we could look into how to check that in a later release.

  1. In this case it would be:
--- ti: function
local ti = table.insert

Function signatures are, once again, something for later. We could treat function as “any function type” for now

1 Like