"Why isn't there an LSP for Crystal?"

Crystal Contrib Tooling
6

I think I was originally approaching this of requiring types to get autocomplete, but I think you bring up a really great point I haven’t thought of, and a potentially different way of looking at this problem.

In the case of this:

def foo(a)
  b = a.|
end

I think all possible methods should be autocompleted, regardless of what foo is called with, if at all. Then whatever methods are called on a, not only restrict the type of b based on the return type of the methods, but also restrict the type of a based on what objects have those methods. So:

def foo(a)
  b = a.abs
  # Let's pretend this restricts `a` to `Number`
  a.|
  # ^ autocomplete only methods on `Number`
  a.bar
  # ^^^ error: method `bar` doesn't exist on `Number`
end

I may go with the more strict need-to-type-things approach to start with, but this does provide a lot of promise for larimar and ameba to do partial / lossy semantic analysis (I intend to re-use the same visitor for both).

I wonder if it’d also be possible to bubble up parameter types from their bodies? Like in the same example:


def foo(a)
  b = a.abs
  # Let's pretend this restricts `a` to `Number`
end

foo("bar")
  # ^^^^^ error: parameter `a` should be `Number`, not `String`
  # or
  # ^^^^^ error: String does not have method `abs`

Something to explore once more a framework is laid out.

2 Likes