Calling local bindings from GHCi

[JakobBruenker]

Imagine a function like

foo a b = process (localBinding1 a) (localBinding2 b)
  where localBinding1 x = ...
        localBinding2 x = ...

One feature that I've often wished existed is being able to call local bindings like localBinding1 from GHCi. Too often I've written a function with some local bindings, only to find out that it doesn't work, and that if I want to debug these bindings, I have to convert them into top-level bindings, debug and fix the them, and then convert them back into local bindings.

A somewhat similar feature exists in GHCi: For interpreted modules, it's possible to use names that weren't exported.

So it'd be nice if, at least in interpreted modules (I strongly suspect it's impossible for compiled modules), you could call foo.localBinding1 as long as localBinding1 is a binding that could, in principle, be floated to the top level (i.e. as long as localBinding1 doesn't have any free variables referencing bindings which are declared in a local scope). Except the obvious syntax with . is already taken by record dot syntax, so for the sake of this discussion I'll be using foo$localBinding1 for now.

There are five questions I have about this:

Is there interest in this?

I know I've wanted this feature quite a few times, but I'm curious how others feel.

What kinds of local bindings should be callable?

My intuition would be to count anything in a where block. Others might feel that let should count as well, but this comes with some issues (see next section), and I would be happy to just use where. Is there anything else besides these?

How to deal with ambiguities?

Examples:

function1 bool = case bool of
  True -> Just (f 42)
    where f = (+1)
  False -> fmap f Nothing
    where f = id

function2 a b = (let f = (+1) in f) a + (let f = id in f) b

Should function1$f refer to id or (+1)? The lets in function2 look even murkier to me from that perspective, which is why I'd be happy to ignore let.

The obvious solution would be to only allow where blocks that are directly attached to a function definition, rather than to an expression inside of it, though it'd be nice if there was an elegant way to handle those bindings as well.

(Edit) Especially when we consider that this is mainly a UI limitation, and other downstream applications such as haskell-language-server might have better ways to let the user disambiguate these definitions, it seems like a very good idea to at least have the functionality in place to address any declaration, even if it ends up being the case that we cannot think of a good way to invoke some of them from GHCi.

Should bindings that can't be floated to the top level be allowed as well?

Example:

function f a b = f localBinding
  where localBinding = a + b

You could imagine calling localBinding like (function undefined 42 53)$localBinding, whereupon GHCi would tell you that it's 95.

I imagine this'd be quite useful, if perhaps a bit confusing to look at (but since the main purpose is debugging I'm not too concerned about that).

Is there a good reason not to allow this?

Would the design of GHCi make this unreasonably difficult to implement?

I am, as yet, not familiar with the intricacies of GHCi interpretation.

[cdsmith]

You'll also want to have a story for what to do with cases like this:

f a = go 42
  where go x = x + a

What should f$go refer to now?

[tomjaguarpaw]

I don't see what that's not covered by the section "Should bindings that can't be floated to the top level be allowed as well?". Presumably you could call (function a)$go x and it would evaluate to x + a.

[JakobBruenker]

Something I hadn't really considered before:

f a = ...
  where withFree x = a + x
        withoutFree x = x

withFree would be callable with (f 42)$withFree 53, but I suppose withoutFree would be callable both with f$withoutFree 53 and with (f 42)$withoutFree 53.

[cdsmith]

I don't see what that's not covered by the section "Should bindings that can't be floated to the top level be allowed as well?". Presumably you could call (function a)$go x and it would evaluate to x + a.

Yeah, I just spaced out that section entirely. Sorry for the noise.

[cdsmith]

Should function1$f refer to id or (+1)? The lets in function2 look even murkier to me from that perspective, which is why I'd be happy to ignore let.

The obvious solution would be to only allow where blocks that are directly attached to a function definition, rather than to an expression inside of it, though it'd be nice if there was an elegant way to handle those bindings as well.

I don't agree with the obvious solution. Particularly with regard to syntactic challenges like ambiguous names, I think it's useful to consider this in two layers:

1. What is the core functionality? Ultimately, it's taking declarations that occur, possibly not at the top level, and making them accessible from a debugging UI. There are lots of ways you can point to a declaration besides using its name. For example, you can select it from a list, click on a source location in your editor, or select it from a call stack dumped from a crashed program.
2. What is the user interface in GHCi? Here's where concerns like ambiguous names come in. But my point, I guess, is that this isn't a deep issue. It's just surface syntax, and you'd presumably not want to make fundamental design decisions based on the limitations of GHCi as a user interface. I'd foresee many users of a feature like this going through other user interfaces, such as haskell-language-server, and pretty much any old way to shoehorn it into GHCi would be fine to enable downstream users.

[JakobBruenker]

Yes, this is a good point

[JakobBruenker]

I don't know if people get notifications for edits but I added:

(Edit) Especially when we consider that this is mainly a UI limitation, and other downstream applications such as haskell-language-server might have better ways to let the user disambiguate these definitions, it seems like a very good idea to at least have the functionality in place to address any declaration, even if it ends up being the case that we cannot think of a good way to invoke some of them from GHCi.

[Ericson2314]

I've wanted this before. @cdsmith mentions stack traces and indeed IIRC one can do this with the GHCi debugger. I would love to keep the connection and unify the features as much as possible if we do this. I guess that means snooping the environment of arbitrary bytecode thunks?

[cdsmith]

I've wanted this before. @cdsmith mentions stack traces and indeed IIRC one can do this with the GHCi debugger. I would love to keep the connection and unify the features as much as possible if we do this. I guess that means snooping the environment of arbitrary bytecode thunks?

Good callout about maintaining consistency with the GHCi debugger. Indeed, one way to look at this request is to essentially add a one-use breakpoint at some expression, and then evaluate it.

Except... not really. GHCi breakpoints just wait for an expression to be evaluated on its own. I am really interested in a more denotational mode of debugging, where one wants to go about finding failed assumptions by inspecting the values of various expressions in the context of a counterexample, in order to understand what's going on and why it doesn't match expectations. One doesn't necessarily care when those expressions are evaluated on their own. But it's very close; it's just that instead of waiting for the breakpoint to hit on its own as a consequence of normal evaluation, one wants to systematically force all of the containing lexical scopes so as to reach the intended textual location in the source code.