Method not found when type checking Table stemming from incomplete set of methods in global provides

[robertDurst]

Consider the following code:

tbl = table: name
  row: "Rob"
end

tbl.row("Foo")

When I execute without type checker all is well.

With type checker, .row is not found.

I did quite a bit of digging and printing and I noticed that the fields on the Table data-type obeject resulting from instantiate-data-type(obj-type, context) were surprisingly limited:

t-data(Table, [list: ], [list: ], [string-dict: length, ( -> Number)], builtin(dummy location))

I expect many more methods than just this on Table. Eventually I landed on the global provides and noticed this:

"Table": ["data", "Table", [], [], {
    "length": ["arrow", [], "Number"]
}],

I reproduced locally by modifying tests/type-check/good/table.arr, then added the type signature for row to the global provides and it passed the type checker.

I noticed String-Dict and Reactor both "provide" their own data-types. Should Table do the same?

60 seconds of ctrl-f made me realize just moving the data-type from global provides to table provides isn't as simple as it might seem... it seems it will require resolving some dependency/module loading. Wanted to confirm the desired behavior before venturing further :)

[shriram]

I think the issue is that table type-checking has not really been touched in general. What is the return type of some of these methods? This is in some sense the entire research problem that inspired B2T2.

[robertDurst]

This is in some sense the entire research problem that inspired B2T2.

Ahh, yes. Well I have now just about gone full circle. B2T2 was my starting point.

What is the return type of some of these methods?

That is a good question. I was looking at some of the type signatures for Table methods in the docs that didn't quite line up with my understanding and, unironically, discussing this with @bennn last night.

While the one hardcoded method (length) is valid, is it worth moving this datatype to the Table module preceding the table type work or as a follow up?

My opinion is maybe 🤷 . However, we don't really get much until we make progress on the table type work.

[shriram]

My understanding is that Ben and you plan to tackle this, which would be great. I'm not sure a half-baked solution is worth much; we can't use a "half typed" program. I'd say take it on and do it thoroughly. But maybe @jpolitz @blerner want to weigh in.

(Btw, coincidence, not irony.)

[jpolitz]

Yeah, there needs to be design of types for Table<... very interesting stuff ...> and Row<... very interesting stuff ...> before this will make much sense statically. Excited to work on it!

[bennn]

Really what we're looking for now is a "good first issue" for Rob to build some familiarity with the Pyret typechecker. Rounding out the boring types (Table, Row) to match the Pyret docs seemed like a good plan to me.

Can you suggest another issue to try? Maybe #1662 ?

[jpolitz]

I see! That context is helpful.

Certainly it's probably better for this program to succeed and have some kind of any-ish Row type, so that's a good place to poke around to do some learning, good idea.

I suspect that the type used for Table here won't resemble the type you end up with, but that's fine.

[robertDurst]

On a related note, linking #1422 (linked to #1662) since it looks like it's the same issue described above.

First I fixed the checkWrapTable error by adding its type default to type-defaults.arr (just like checkWrapBoolean). This resulted in a net new error:

  Values not equal "./tests/type-check/good/reactor.arr should not have compilation errors: " "The type checker rejected your program because the object type  \"Table\"  at  tc-test://reactor.arr:5:11-10:3  does not have a field named  `_column-index`  as indicated by the access of that field at  <builtin dummy location>"

which ultimately points back to the global provides.

[bennn]

Interesting! I sure hope work on this issue helps the others.

Reactor sounds like a good example to follow for moving types from global provides to Table provides.

@jpolitz @blerner any tips for adding types to table provides?