Arc Forumnew | comments | leaders | submitlogin
3 points by rocketnia 4971 days ago | link | parent

I don't know if you're suggesting "prescriptive trait inference ... [is] an interesting way to replace compiler error messages with a dialogue," but while I think that's a valid connection to make, I don't think it really tells the right stories.

What Sean McDirmid has in mind with the "crazy PL idea: prescriptive trait inference" thread is to have a language whose scope system is integrated with the IDE. As you autocomplete a name, you also choose exactly which meaning of the name you intend. The "inference" part is mainly for selecting which meanings appear in the autocomplete list. It involves the more abstract task of inferring something's static type given the field names the programmer is using on it, but Sean McDirmid is choosing a very weak type system that makes certain LtUers concerned that he'll miss out on certain easy features and encounter gotchas in his inference system.

This one idea falls within the range of ideas put forward in the "Programming as collaborative reference" thread: To indicate parts of the program interactively, with the human specifying things in broad terms until the computer asks for more specific information.

The "Programming as collaborative reference" snippet on LtU talks about this in the specific sense of a compiler that takes a source fragment as input and sometimes gives a request for more information as output. This compiler could be used to replace error messages with a command line disambiguation interface, or for instance it could be used to compile small, incomplete pieces of programs in order to populate autocomplete lists and place squiggly underlines. In the extended abstract, the authors also link to a video that demonstrates COREF, a chat-window-like interface for resolving ambiguity in a small-world system using natural language.

The extended abstract finishes off with the reassurance that even if a language take this kind of interaction to heart, its programs don't necessarily have to be disambiguated over and over each time you open them or use them in new projects:

"For example, instead of insisting that all overloading be unambiguous, a programming language can resolve overloading interactively if there is enough doubt as to which referent the programmer intends. The referent that results from this collaboration would then become part of the program text (in particular, part of the indexical content that any copy-and-paste operation would operate on), so meta-theorems such as type safety would still hold."



1 point by akkartik 4971 days ago | link

Yeah I wasn't trying to conflate the ideas, just didn't want to add yet another topic on what was such a busy day for the arc forum :)

Though I've started dreaming about using dialogue to fix all errors, not just those of name ambiguation..

-----