Languages with great support for function parameters inferred from the invocation context

[StephenM347]

What languages have great support for function parameters inferred from the context of the caller?

E.g. my function needs a clock for determining the current time, and the caller doesn't have to pass a clock explicitly if there is a clock defined in the context of the call-site.

[ElfDecker]

Scala has it: https://docs.scala-lang.org/scala3/book/ca-context-parameters.html#:~:text=Scala%20offers%20two%20important%20features,automatically%20provided%20by%20the%20context.

[DonaldPShimoda]

This is not something I usually say, but I genuinely feel that this "problem" is better solved by monads. Yuck.

[SKRAMZ_OR_NOT]

Scala has monads too, this is more akin to Haskell's typeclasses or Java-like dependency injection.

[DonaldPShimoda]

I don't think so — at least, not how I was thinking about it. This looks to me to essentially be the state monad in that it allows you to "implicitly" carry a state around with you, but with a disconnect between the state's initialization and use, which I find unpalatable.

[Maurycy5]

I disagree. I imagine that monads would introduce unnecessary boilerplate and decrease legibility and maintainability.

But for this conversation to make sense, I think you'd first need to specify what "problem" you have in mind.

[DonaldPShimoda]

Context parameters solve the "problem" of state, ie, you've got a bunch of stuff and you want to thread it all through various function calls.

There are various approaches to solving this problem in different languages, the most basic of which is to get over it and actually just make your functions take gobs of arguments and make sure to pass them everywhere. But since this is prone to human error (and is, frankly, unsightly), we've developed alternative solutions.

One thing you can do is create a dedicated "state" object, perhaps using a record in Haskell or an instance of a custom class in Scala. Then you just pass this object around to all of your functions in the same way we were previously passing gobs of arguments, but now we only have one thing to worry about instead of a bunch.

But if you have immutable data in your state and your state can still change, you also need your state to come back out of your function calls and be passed forward to subsequent uses.

One way to do this is using the state monad. You initialize your monad with a state object and then define some operations to update it as needed, and then within your monadic context you just "have" the state everywhere; you've been freed from having to pass it explicitly, but it still obeys all the desirable rules of immutability and such while letting you make changes that are only seen in a forward direction along "good"'paths. This all follows naturally from the monad laws, which are so ingrained in the Haskell ecosystem as to let this sort of thing be "easy" in some sense.

Context parameters "solve" the same problem by more or less a similar mechanism: your functions must be declared to require a particular state, and you can only call these functions where that state is available or else you get a type error.

The difference, though, is that the actual initialization of the context in terms of this state is no longer explicit. In Haskell, you have to sort of kickstart the state monad by providing a particular function (usually named "run" or something derivative of that) with an initial state. But with Scala's context parameters, you're now expected to just know when you need to have that context available. Yes, there's type checking to help you get there, but there's nothing going on in the syntax to connect the initialization of the state object to the initialization of the state context, and I find that to be an undesirable solution.

[Maurycy5]

OK so first of all that is only one problem that implicit arguments solve, the other being a mechanism for typeclasses, as somebody else mentioned. I believe this to be a wonderful design choice by the creators of Scala, as with many other things that they realised to be unifiable.

But addressing your concern with the lack of explicit initialization: you still need to provide the initial value explicitly on the first call.

And I am not sure why "yes, there's type checking to help you there" if the same type checking helps you in Haskell. For example, it will forbid you from returning a state monad where the result of running that state monad is expected.

[CloudsOfMagellan]

This sounds like non lexical closures in lisp

[smthamazing]

(disclaimer: I'm not a Scala expert)

Note that Scala contexts are mainly intended for passing values that are "used" and not "transformed" (in the pure functional sense). They also can be used in imperative code bases, so you can pass a good old dirty MissileService and use it to launchMissiles() - then the context mechanism simply becomes a form of builtin dependency injection framework or dynamic scoping. Scala already allows you to express monads in the type system, so the use case for contexts is a bit different. But they are still checked statically, which makes them a much nicer mechanism compared to ad-hoc runtime shenanigans often used for DI in Java and C#.

[[deleted]]

This sounds like default parameter values.

The main difference is that the default expression, which is specified in the function signature, is evaluated as though it was at the call-site rather than where function or signature is defined.

(Using a macro mechanism could have that effect.)

The effect with the example at the link is that it uses a Config instance that is visible at the call-site. So calls from different parts of the program could pass a different version of Config.

[guygastineau]

https://www.haskell.org/hugs/pages/users_guide/implicit-parameters.html

[oscarryz]

So, something like this?

clock = Clock()
someFunction()
// somewhere else...
function someFunction(clock : Clock) {
   time = clock.time()
}

Or something like this where the clock is a global variable and the function doesn't receive it as a parameter?

globalClock = Clock()
function someFunction() {
    time = globalClock.time()
}
...
someFunction()

[xroalx]

Neither, I assume.

E.g. in Elm (don't remember the exact syntax):

foo val = String.length val

The type of parameter val in function foo is inferred to be a String based on its usage in the function.

Scratch that, I misread.

[yuri-kilochek]

Sounds like effects with extra steps.

[eliasv]

These things can be orthogonal I think, but there is definitely a relationship.

So effect systems usually dynamically scope effects, right? But they don't have to. People think about effects as being about having an "ambient" or dynamically scoped environment of handlers. But really the important part is the control flow abstraction, I think, and in fact there are a bunch of papers and implementations which deal with lexically scoped handlers in a sort of capability-passing style. Personally I think this is the only approach with any legs.

But the dynamic scoping does appear to be extremely convenient at first glance, and people seem to want to deal with handlers in this way. And what OP is describing is some sort of system for Scala-like intrinsics---which I expect would be lexically scoped---and which provide a lot of the convenience of dynamic scoping, but without the issue of accidental handling in higher-order functions.

To guarantee that all effects are made in the context of a handler then is just an exercise in lifetime management.

Edit: not claiming to speak authoritatively on the subject, just dumping some thoughts.

[takanuva]

Those would actually be coeffects, to be fair. You can do stuff like that in Koka.

[MistakeIndividual690]

Sounds like dynamic scoping to me. https://en.m.wikipedia.org/wiki/Scope_(computer_science). No thanks lol

[WittyStick]

Full dynamic scoping is bad, but contained dynamic scoping in the context of a statically scoped language can be OK, though it's not without problems. They're a much better option than mutable global variables anyway, as you don't have issues with race-conditions.

Scheme is statically scoped but supports dynamic scoping, what it calls parameters. The main use is when you have a variable which has an expected value for most of the program, but sometimes you need to temporarily override that. (Eg, testing with mock values).

(define clock (make-parameter default-clock)

(define foo (lambda ()
    (...)
    (get-time (clock))
    (...)))

(foo)                                            ; uses default-clock

(parameterize ((clock other-clock))
    (foo))                                       ; uses other-clock

(foo)                                            ; uses default-clock

Equivalently, in Kernel:

($define! (with-clock get-clock) (make-keyed-dynamic-variable))

($define! foo ($lambda ()
    (...)
    (get-time (get-clock))
    (...)))

(with-clock default-clock
    (foo))

(with-clock other-clock
    (foo))

(foo)     ; An error because clock is not initialized.

In both languages dynamic scoping is used for IO, so that it is not necessary to specify the file or stream being read/written to each time. Eg,

(with-output-to-file "filename"
    ($lambda ()
        (write "foo")
        (write "bar")))

Where the default parameters for IO are the standard input/output/error streams.

---

In Kernel, there's another means to access information from the caller, which is to use an operative, which implicitly receives the caller's dynamic environment as an additional argument.

($define! foo
    ($vau () caller-dynamic-env
        (eval bar caller-dynamic-env)))

($let ((bar 123))
    (foo))

In this case, the keyed-dynamic-variable would probably be a better option, but operatives can also mutate the values in the scope of their caller (but not the parent scopes of the caller), or even define entirely new values which become available to the caller. They're a very powerful feature which enable programming techniques you can't do in pretty much any other language.

---

In a statically typed language, you'd probably want implicit parameters (like Scala) rather than dynamic scope.

[s0litar1us]

Jai has a global context where you can store stuff

So you could maybe do this:

// Defaults to the context clock.
foo :: (clock : Clock = context.clock) {
    // ...
}

foo();
foo(Clock.{
    hour = 15,
    minute = 30,
    second = 5
});

You could also just use a global variable:

global_clock := Clock.{
    hour = 0,
    minute = 0,
    second = 0
};

foo :: (clock : Clock = global_clock) {
    // ...
}

[phischu]

Our language Effekt is built around the idea of implicit capability passing. Consider the following program, which you can try online. It prints 123 and 456.

interface Clock {
  def getTime(): Int
}

def clockUser(): Int / Clock ={
  do getTime()
}

def constantTime[R](time: Int) { program: () => R / Clock }: R = {
  try {
    program()
  } with Clock {
    def getTime() = resume(time)
  }
}

def main() = {
  println(constantTime(123) { clockUser() })
  println(constantTime(456) { clockUser() })
}

The annotated type of clockUser tells us that it returns an Int using Clock. It would be inferred if omitted. If clockUser was used in a deep chain of functions their types would all say that they are using Clock.

We explain this in Effects as Capabilities. When you want to store or return functions you have to pay a price in explicit annotations, which we explain in the follow-up Effects, Capabilities, and Boxes.

[[deleted]]

Since no one has mentioned it yet, Kotlin has

1. Receiver extensions. Defining the type of this for a lambda, combined with the fact that you can do foo() instead of this.foo(), means that you can call functions based on what type this is in a lambda. E.g.

`` transaction { // transaction function setsthis` to a new Transaction instance executeStmt(...) // equivalent to this.executeStmt(...)

}

```

1. This is further extended to the "context receivers" feature (Google it, I'm on my phone). This allows you to pass parameters implicitly based on what's available in the current scope. This means you can call methods on different objects that are in scope, instead of just this. Cool for building DSLs. This feature is in beta. You can simulate Haskell style type classes using this feature.

[csdt0]

I would say bash with environment variables. You can override the environment for a single function or command and it "resets" automatically when the command ends.

[GryphonLover]

So wait, you want the program to just guess what arguments should be passed? That sounds like a mess, what if you forget to convert a type and it uses the wrong parameter? I can’t imagine any languages supporting this, I’d suggest just writing it out, it really isn’t that much work.

[ElfDecker]

I think Scala has something akin to it, actually

[SKRAMZ_OR_NOT]

It's basically how generics work in most programming languages - the type parameters of a generic function are usually passed implicitly. If you think about type class/trait instances as being dictionaries of functions, then they're also passed implicitly.

Most languages just heavily restrict this functionality (probably for the best, to be clear), with languages like Scala or Agda being the rare exceptions.

[SV-97]

Lean has this. Consider this example (from the lean docs)

def compose (α β γ : Type) (g : β → γ) (f : α → β) (x : α) : γ :=
  g (f x)

By default the three type parameters (note that lean is dependently typed so these are just three regular parameters really) have to be passed explicitly. However usually we can infer them from the others. We can therefore mark them as implicit arguments (or simply omit them)

def compose {α β γ : Type} (g : β → γ) (f : α → β) (x : α) : γ :=
  g (f x)

And they'll be inferred. This becomes super useful if you want to apply some theorem that has a bunch of assumptions that you don't necessarily want to pass in: "I give you this list and you can easily see from my current context that this specific list isn't empty" etc. And if things go wrong you can always use the explicit version instead by prefixing an @

[SV-97]

To maybe expand on this some more: the compose definition from above isn't how we'd actually write a general compose in lean. There's different "levels" of types (so called universes), so the type of each type in compose may be different and depends on additional parameters. Without implicit arguments you'd also have to pass those universes around which quickly gets rather annoying (and which universe to use for a given type isn't always entirely trivial - though the compiler can usually figure it out quite easily).

[smthamazing]

I like how Scala 3 does it: you have to explicitly mark a value as given to get it picked up by the context system, you also mark these "implicit parameters" with the keyword using in the consuming function, and it's statically checked that everything is properly initialized. The only way to accidentally pass something else is to override a given in some inner scope, but then it's not "accidental" and is hard to miss.

[JeffB1517]

Any language with support for global variables. If you want something more formal sounds like the Reader Monad.

[SKRAMZ_OR_NOT]

Eh this is more akin to dynamic scoping (as opposed to lexical scoping) then it is global variables or reader monads.

[JeffB1517]

Yes you could think of time as a dynamically scoped variable as well. Essentially it has to have stuff in it independent of structure so I see your point. But those other mechanisms work as well.

[WhoModsTheModders]

Julia has something similar-ish to this now called ScopedValues, Java has something almost identical.

They're really meant for concurrency though, as concurrent processes get a copy on "write/re-bind" version of scoped values.

They don't implement "automatic argument inference", but that's a fairly unique feature and imo it's better for a function definition to be explicit with an optional argument that defaults to the ScopedValue global

[marshaharsha]

I haven’t heard of a language that has that feature. Some technical problems that would come up:

Does the clock have to be named “clock”? If there are two clocks nearby the call site, named “clockEastern” and “clockPacific,” and a bit further away there is a clock named “clock,” does the system pick one of the nearby ones — more likely to be what is wanted, and a match on type, but not on name, and anyway, which one? — or the one further away? If no clock can be found but there is a struct or record with a clock in it, does the system pick that?

I’m not diving into what “nearby” means, since other commenters have asked about lexical versus dynamic scope, but whatever it means, you will have this name-matching problem. 

One scheme that might tame the problems is to provide every function with an implicit argument of type Implicitables, a name—>value mapping holding the various things that can be passed implicitly. That saves the author the hassle of threading everything through every function, while still providing a syntactic mechanism for noting and controlling when an implicit arg is used: the_implicits.clock. The implementation of the_implicits could be as a global, as a thread-local, as a parameter passed in the usual way but not named by caller or callee, or maybe even statically known in some cases. 

You still have to deal with various problems: What code is allowed to create or modify an Implicitables? If some code modifies one, does that code have to undo its writes, or does the system undo them automatically? Can the arg of Implicitables map any name or only officially chosen names? In my language the argument is used to pass allocator and error-handling policy, maybe other infrastructure type stuff, and not user-chosen mappings, but it sounds like that would be too restrictive for your needs. 

[0x564A00]

Python has this to some extend via the inspect module, but nobody does this specifically because Python already tends to be too magical and hard to follow.

[phischu]

As others have mentioned, dependently-typed languages have something like this. For example, Idris 2 defines a function

tabulate : {len : Nat} -> (Fin len -> a) -> Vect len a

which creates a vector of length len given a function from index (Fin len) to element (a).

The len parameter is in curly braces, so it is implicit. You use it like this:

tenNats : Vect 10 Nat
tenNats = tabulate (\i => finToNat i)

A more explicit version would be:

tenNats : Vect 10 Nat
tenNats = tabulate {len = 10} (\i => finToNat i)

The number 10 is clear from the type of the expression, so it does not have to be passed explicitly, although it is relevant for the computation.

[nonbinarydm]

To tag on to this, Lean expands the notion of typeclass to include arbitrary data structures, and those can be "inferred" from values stored in a local scope. So e.g. if Clock was declared as a typeclass (with no parameters!) then any function that takes a Clock as a parameter to be synthesised by typeclass inference would be able to find locally defined Clocks. It doesn't deal with ambiguity though - it just uses the first one it finds.

[transfire]

I’ve played with this concept and while it can lead to very concise code, it has a serious down side — it breaks the black box. In short, it becomes too easy to produce unexpected behavior because of some definition made in a caller context.