Why putting a function argument first

Usage
#1

Although it appears #1 convention on style guide of the docs to write functions for a long time till Julia 1.6 now, it brings difficulty on some user cases like manipulating data and piping. I was wondering if it would make life a little easier to withdraw the restriction and let users decide a function argument position at their convenience.

  • If the only reason to put a function argument first were using do-block, I think there should be many better solutions out there. My two cents: to implement few more keywords like
sdo/do2/ddo, tdo/do3

and keep backwards compatibility. Eg. calling a function
f(x, g::Function, y) with a function argument at the second place could be called by sdo-block

f(x, y) sdo
    ...
end

The sdo-block would put the anonymous function into the second position.

#2

You can also create two methods for your function, one that takes a Function first and another that takes a Dataframe (or similar) first.

2 Likes
#3

When do block get large, I factor them out to a function anyway. You can do the same and use the result in any position, eg

_f(x) = ...

g(x, _f, y)
2 Likes
#4

It’s no restriction. That’s a style guide: “only suggestions to help familiarize you with the language and to help you choose among alternative designs”, as stated in the first paragraph. If you have reasons to depart from that style for your use case, you are free to do it.

And if the issue is that the style used in Base or in others’ code is inconvenient for your use case, the joy of multiple dispatch is that it allows you to make alternative custom methods with the order of arguments that fits your needs very quickly, without having to increase the complexity of the source.

1 Like
#5

By “restriction” I mean the long-time convention, which people follows along.
Eg. filter in DataFrame.jl follows the guide and keep consistent with Base.filter, which is a little uncomfortable to most people I met.

In the case of map(f, args...) the function argument should be put first, while in some other cases it would be more natural to put it on other place.

I don’t know many program languages but is it the case for those that support high-order functions having a style to put a function argument first?

I guess this post is about challenging the reasonableness of this convention, but maybe it is too small…

#6

You’ve told it: there is no absolute better convention. But I think that this doesn’t make the current one less reasonable, specially since adapting the interface to more convenient workflows with new methods is easy. In fact, for this use case others have already done it, with a full-featured package to manipulate data:

#7

There are two — related — issues here:

  1. putting function arguments first,
  2. having special syntactic sugar for it.

(1) is just a suggestion, you are free to do otherwise. Also, some Base functions with multiple function arguments (eg mapreduce) have functions in other positions out of necessity. It is not a big deal, just do what you prefer.

(2) is syntactic sugar for the most common case. It can be argued that not everything needs its own special syntax, just covering 90% is fine.

That said, putting your function arguments first is quite common in the Lisp family.

3 Likes
#8

I think its good that functions with the same name as base functions follow the same style but packages. Whether this is familiar or not depends on everyone’s prior experience. But in this specific example you’ll be happy to see your suggestion coming to dataframes soon

https://dataframes.juliadata.org/dev/lib/functions/#DataFrames.subset