User defined function, recursion and passing self along

Questions / Help
,
1

Hey everyone!

This is a multi-layered question and I’ll try my best to try and phrase it cleanly.

As an abstract use case I want to have a function that is adjustable in its behaviour by a caller by passing in an optional function (think Map.merge/3). This function is used to determine what my function does - but it’s not all, it is wrapped and calls a Protocol function on a specific return value. This protocol function might want to call the previous method, hence it requires me to pass along the initially user supplied function… I’d much prefer to be able to create an anonymous function that already is the “wrapped” version of the user supplied function but can’t seem to do it because of recursion…

in code:

  # in the module MyModule
  def original_method(argument, user_function) do
    val = user_function.(argument)
    case val do
       @continue_symbol ->
        MyProtocol.continue(argument, user_function)
      _anything ->
        val
    end
  end

  # MyProtocol
  def continue(argument, fun) do
    resolver = fn(argument) -> original_method(argument, fun) end
    Stdlib.function(argument, resolver)
  end

I’d love the whole of original_method to be an anonymous function by itself (built from my code + the user supplied function), but it seems impossible as it would have to pass itself along to the function it calls on the protocol.

It just feels strange overall. I can’t have it as a nice already wrapped anonymous function and even in the protocol I seem to always have to build my own resolver function calling back to original_method.

Does anyone know of a better way to do this? The concrete code can be found here and the two methods are basically DeepMerge.Integration.do_deep_merge (still working on naming…) and the implementations for DeepMerge.Resolver.resolve. The use case is basically that normally the protocols for each data type know how to resolve the deep_merge, but the user has a shot at changing that behaviour should she choose to (e.g. don’t merge lists).

Thanks a lot for reading this far and helping out, any feedback appreciated :slight_smile: !
Tobi

2

Hmm, can you give an example of the code as you want it to look and what error you get and on what line so we can see what is happening? :slight_smile:

3

This is a known problem in functional languages. How to make a recursive anonymous function?
Even something as simple as factorial is hard to write:

fac = fn(0) -> 1
            (n) -> fac.(n-1) * n end
** (CompileError) iex:2: undefined function fac/1

There are topics abou it on Erlang mailing list and there is this in particular:
http://erlang.org/pipermail/erlang-questions/2003-January/006639.html
and it shows a trick to get around that limitation:

fac = fn(0, _f) -> 1
            (n, f) -> f.(n-1) * n end
factorial = fn(n) -> fac.(n, fac) end
factorial.(5)

The good news is this workaround is easy. The bad news is that you would have to teach it to every single user of your library (or just use named functions).

2 Likes
4

Thanks for sharing this great trick! On the one hand, wished I could have come up with it myself (as I did something like it) but at the same time it’s genius. Had to adapt it a bit as Map.merge/3 expects a function with arity 3.

If anyone is interested, this is the commit.

Thanks a ton once again!

5

That style is called the Y-Combinator. There are many kinds of combinators, should look them up. :slight_smile:

2 Likes
6

Thanks! Definitely still need to brush up my FP (only dabbled in Clojure, LISP and Scala a bit before) which is why Elixir is so great to pick up and learn as I can expand my mind on FP, distributed systems/OTP and many other great concepts.

To my shame, before I mistook “Y combinator” for the general “we derive the whole of computation from just functions” which I think is rather called lambda calculus :sweat_smile:

A bit OT, but if you have some good resource to share (book or web) for learning about “ALL THE COMBINATORS” I’d appreciate it. Maybe I should dig out Land of LISP again…

7

No need for lisp, just normal functional stuff. :slight_smile:

I usually just point people to the wikipedia article, short, to the point for each combinator: Fixed-point combinator - Wikipedia

For Elixir there are libraries that simplify the combinators as well, such as quark, where the Y-Combinator is named fix for being a fixed-point combinator, but it shows a lot of other non-fixed point combinators as well (that same author makes a lot of awesome libraries like that, especially for functional design, click their name on the lower-right of that page too, especially as a lot of their libs are designed to be used together). :slight_smile:

1 Like
8

Here’s a great resource to learn about combinators in general, if Ruby as a sample language works for you: Kestrels, Quirky Birds, and Hopeless Egocentricity

2 Likes
9

That is fascinating. Ruby uses combinators everywhere.

Also, wtf?!?

[1,2,3,3,4,5].uniq!
  => [1,2,3,4,5]

[1,2,3,4,5].uniq!
  => nil

Uh… wtf?! A prime example of why I like statically typed languages, this oddness would be encoded in the type instead of being, just… wtf…?

10

I’m not sure what static typing has to do with this situation. I think of that wtf as a mutability issue. If you use the non-bang version of uniq you’ll find the result less confusing. I’ve found myself avoiding bang methods in Ruby more and more as my experience grows.

irb(main):001:0> a = [1,2,3,3,4,5]
=> [1, 2, 3, 3, 4, 5]
irb(main):002:0> b = [1,2,3,4,5]
=> [1, 2, 3, 4, 5]
irb(main):003:0> a.uniq
=> [1, 2, 3, 4, 5]
irb(main):004:0> b.uniq
=> [1, 2, 3, 4, 5]
irb(main):005:0> a.uniq!
=> [1, 2, 3, 4, 5]
irb(main):006:0> b.uniq!
=> nil
irb(main):007:0> a
=> [1, 2, 3, 4, 5]
irb(main):008:0> b
=> [1, 2, 3, 4, 5]
irb(main):009:0>

uniq! modifies the array in place and returns the modified version or else it’s already unique and it returns nil to indicate that. It’s a horribly confusing method. uniq just returns a new array with unique elements.

11

I noticed the non-bang was consistent yep, but mutating methods or not, returning a value should be fairly consistent, after all ‘why’ did it return nil in the case it did not make changes, yet it returned self when it did, why not always return self so you can chain?

That really really badly should have had a new name indeed, that seems so counter-intuitive and internally inconsistent compared to the surrounding methods (Principle of Least Surprise is violated! :astonished:). If anything it should have returned true or false, not self or nil. o.O

1 Like
12

haha yeah the return values of bang methods in ruby are a bad surprise indeed… this also leads to the fact that you can not safely chain them. I mean, you can chain them if they always modify something and return something but once when they don’t… BOOM.

One of the very unintuitive parts. I hope they change it in 3.0 but guess they won’t :’(

1 Like
13

It’s actually intentional. It allows for code of this style (borrow from Perl):

>> s = "cows"
=> "cows"
>> if s.sub!(/s\z/, "")
>>   puts "You now have a #{s}"
>> end
You now have a cow
=> nil
14

That again brings up 'Wouldn’t it be better to return true/false instead of a potentially usable value from death?`. :slight_smile:

Since it ‘sometimes’ returns self it seems like you could do myArray.uniq!.sort, but that will die at times, seemingly very randomly too. ^.^

With proper typing that would be impossible, either you’d always have to return self, so .sort would always work, or you’d have to return some variant of self | nil, meaning you’d have to match on it or default it out or so. true | false makes so much more sense in that context. :slight_smile:

15

Yeah, I’m totally explaining and not defending this design choice. :smile:

2 Likes
17

Ah, the link seems broken …

18

Fixed.

Kestrels, Quirky Birds, and Hopeless Egocentricity
by Reg Braithwaite

Also Reginald Braithwaite - JavaScript Combinators (2016)

2 Likes