Can we try reporting a more relevant error if autoscope constructor meets missing type annotation?

[radeusgd]

Repro showing the problem/context:

from Standard.Base import all

type My_Type
    A 
    B

    do_something self = case self of
        My_Type.A -> 'astronaut'
        My_Type.B -> 'bicycle'

foo (x : My_Type) = IO.println x.do_something
bar x = IO.println x.do_something

main =
    foo (..A)
    p = Panic.recover Any <| bar (..A)
    IO.println p.to_text

Currently yields:

astronaut
(Error: (No_Such_Method.Error ..A UnresolvedSymbol<do_something>))

What I can see from this is that the No_Such_Method instance seems to 'see' that this is not any function but that this is in fact an instance of an autoscoped constructor. Thus it seems likely that we could report a more relevant error for it.

We could for example report something along the lines of 'Calling a method on an autoscoped constructor that was not resolved. Probably missing a type annotation. Please add the annotation or use the qualified name.'. This would tell the user much more clearly what happened and what they can do to fix it.

---

Of course this is not a made up problem - I've been encountering it in several places in std-lib. We are slowly moving towards using autoscoping, especially for on_problems. I've tried using ..Report_Error as an argument, but some of our older functions were not yet updated to contain the on_problems : Problem_Behavior type annotation - thus the autoscoping was not kicking in and I was getting errors like:

An unexpected panic was thrown: (No_Such_Method.Error ..Report_Error UnresolvedSymbol<attach_problems_after>)
        at <enso> Java_Problems.with_problem_aggregator(C:\NBO\enso\built-distribution\enso-engine-0.0.0-dev-windows-amd64\enso-0.0.0-dev\lib\Standard\Table\0.0.0-dev\src\Internal\Java_Problems.enso:98:5-90)

Of course we also need to 'just' update our stdlib with missing annotations to make it work. But I think it is useful to still improve the error reporting as we may always miss some places. It will also help with places where autoscoping was not expected (places expecting Any, like fill_missing etc.) but the user did not know and used it anyway. Or in user-made libraries.

[JaroslavTulach]

If I modify the main method to:

main =
    foo (..A)
    bar (..A)

and execute the program, the error is:

Execution finished with an error: Method `do_something` of type Function could not be found.
        at <enso> t.bar<arg-1>(t.enso:12:20-33)
        at <enso> t.bar(t.enso:12:9-33)
        at <enso> t.main(t.enso:16:5-13)

which is far more verbose than the error message provided by you @radeusgd. From that I'd conclude the problem isn't in the error, but in the way

    p = Panic.recover Any <| some_action
    IO.println p.to_text

formats it. I don't think the problem has much to do with compiler. Passing to libraries.

[radeusgd]

Execution finished with an error: Method `do_something` of type Function could not be found.

which is far more verbose than the error message provided by you @radeusgd. From that I'd conclude the problem isn't in the error, but in the way (the code) formats it. I don't think the problem has much to do with compiler. Passing to libraries.

We have a misunderstanding here.

I'm aware that to_text on the error has a shorter more internal representation and only to_display_text has a longer explanation. This is mostly by design and surely not the scope of this issue.

My issue was: the error No_Such_Method with the message "Method do_something of type Function could not be found." is not that relevant to the underlying issue we have here. The underlying issue here is: trying to use an autoscoped constructor as a regular value (calling methods on it) before we gave it a chance (by adding type annotation) to materialize to an actual value. My point was - we should give the user a clearer error - one that knows that in this case it is not a regular Function but a special object - and in that specific context the error can be more informative - with the content I suggested above.

To do so we need to distinguish an unresolved method call on an UnresolvedConstructor from any other object. We could do it that it's still No_Such_Method error and the to_display_text changes - but to do so we need a way in libs to distinguish UnresolvedConstructor instances from regular values. As far as I know there is no such way currently. Maybe we need to extend the Meta functionality to be able to handle these??

Either way we need either:

• a more specific behaviour in engine when instantiating No_Such_Method,
• or a way to tell UnresolvedConstructor from other values - to be able to customize the message on libs side.

[JaroslavTulach]

Either way we need either:

• a more specific behaviour in engine when instantiating No_Such_Method,
• or a way to tell UnresolvedConstructor from other values - to be able to customize the message on libs side.

I guess it is enough to just change No_Such_Method message for Function-like objects as #10328 shows. No changes in the engine are needed.

[enso-bot]

Jaroslav Tulach reports a new STANDUP for yesterday (2024-06-25):

Progress: - #10147 fixed by merging: #10328

• Run whole Standard.Base in Native Image ./runner #10126 fixed by merging: Verify ./runner executable on all supported OSes #10329
• enabling conversion method return type check: Comparable.from doesn't return Comparable #10355 (comment)
• debugging AbstractLanguageLauncher
• able to parse --polyglot and --insight: 283f7b5
• investigating Truffle launcher: Integrate our launcher with Truffle launcher #5298 (comment)
• planning meeting, standup It should be finished by 2024-06-26.