Keyword name disambiguation


I’ working on a code which, for the sake of clarity, has long keyword names.
A simple example is:

function foo(;ABooleanKeyword=false, AnotherLooongKeyword=2)

Is there a simply way to call the foo function with abbreviated keyword names, such as foo(ABoo=true, Another=4) ?
There would be no ambiguity in this case…

Also, since the default value of the first keyword is a boolean, it would be nice and clear (IMHO) if I could use it as an on/off switch being on when the keyword is provided, off otherwise, i.e.

foo(ABoo)  ==> ON
foo()  ==> OFF

In the first case there would be an ambiguity on whether ABoo is the keyword or another symbol. However, a syntax similar to foo(/ABoo), foo(>ABoo), foo(;ABoo) etc… would remove any ambiguity.

Is there a simple way to do this already implemented in Julia ?


This mechanism reminds me of R, but AFAICT Julia has nothing similar, and implementing this would require complex macrology/introspection.

In Julia, it is common practice to wrap up bundles of repeated keyword parameters in a structure.


I believe Plots.jl does allow for various keyword argument aliases, but I’m unsure
how it does this.



Isn’t that for when you have many parameters? The problem here is the length of the names.


I created a small macro to fulfill my purpose. It is available as a package here:

To use it go from:

function Foo(; Keyword1::Int=1, AnotherKeyword::Float64=2.0, StillAnotherOne=3, KeyString::String="bar")


using AbbrvKW

function Foo(; kw...)
    @AbbrvKW(kw, Keyword1::Int=1, AnotherKeyword::Float64=2.0, StillAnotherOne=3, KeyString::String="bar")

This way I can call the Foo function with abbreviated keyword names, as long as the provided names allow complete disambiguation, i.e.:

Foo(Keyw=10, A=20.0, S=30, KeyS="baz")

I would like to see this functionality included as a native feature in future versions of Julia, but I have no idea on how to implement it, nor how much effort it requires… :frowning:

Comments/suggestions are welcome!


Lots of dictionaries: . ODEInterfaceDiffEq.jl does it similarly in order to translate DiffEq commands to ODEInterface.jl:

This idea works well en masse, but if just handling a few args it would be tedious at best.