A neat thing you can do with Intermodal + functional Ruby

some_api.rb

require 'rlet/functional'

module SomeApi
  module API
    class V1_0 < Intermodal::API
      using RLet::Functional

      self.default_per_page = 25

      map_data do
        attribute = ->(field) { ->(r) { r.send(field) } }
        helper    = ->(_method) { ActionController::Base.helpers.method(_method) }

        presentation_for :book do
          presents :id
          presents :price,    with: attribute.(:price) | helper.(:number_to_currency)
        end
      end
    end
  end
end

hmm, that is kind of interesting...

I keep expecting to see some general-purpose FP framework to be touted as a rails-killer by using patterns like this, but I think the issue with FP adoption is that it's quite terse and mentally taxing to comprehend everything that's happening. I had to re-read this a few times to realize everything that's going on here, since I'm used to seeing lines of code that are closer to the english that describes their purpose.

That said, if it can be sort of abstracted away or exposed as more of a DSL, I could see this type of pattern becoming a killer mini-framework.

I tend to use FP in places like make sense, like here. I haven't written a full, useable program in Haskell yet, but whenever I see something that understand, it blows my mind.

But that's why I used a refinement for the '|' applicator -- there's no good consensus on what operators to use for functional Ruby. At least this way, it makes it explicit when I'm using something weird.

Yeah it has been my understanding (without having looked myself yet) that elixir is basically ruby but re-designed for FP first, so maybe that's what we should be dabbling with.

My personal taste has always preferred the english word rather than an operator (or instead of ||, and instead of &&, unless rather than if !(), etc.) so maybe that's an option in this case, somehow, but the verb is elusive if we want to avoid stomping on pre-defined concepts like filtering, presenting, transforming, etc. Perhaps something along the lines of presents :price, taken_from attribute.(:price), via helper.(:number_to_currency)

I think it's harder to map many of the logical concepts of FP to english grammar, though, since like I was saying, it gets pretty terse and a lot of implicit knowledge about what complex functional concepts mean is required. Writing out an "english descriptive" version of each thing might turn into pretty lengthy prose and spoil half the fun.

I don't always like having English-like DSL for everything. Data transformation tends to be one of them.

presents :price, taken_from attribute.(:price), via helper.(:number_to_currency)

is just too wordy for what is essentially a data transformation. More importantly, it's not likely to be as flexible.

Elixir is a syntax that takes what made Ruby look good and built it on top of the Erlang BEAM VM. So it's functional in that sense, but Elixir's sweet spot is that it has better metaprogramming than Erlang itself while retaining what makes Erlang capable for the problems it solves well. Many of Elixir's basic syntax and sugar are actually Lisp-style macro expansions, so it's a bit different from Ruby-style metaprogramming.

@brandondees to expand further on what I mean by "flexible", the | is an applicative operator. That means you can chain functions along the lines of:

presents :price, with: attribute.(:price) | locale.(:fr) | helper.(:number_to_currency)

as an example.