Caesar Cipher ElixirGolf

caesar.exs

# for an offset range of -26 to + 26
# 114 characters
[n,p]=IO.gets("")|>String.split",";IO.puts for c<-to_char_list(p),do: c<97&&c||97+rem c-71-String.to_integer(n),26

# for any offset range
# 122 characters
[n,p]=IO.gets("")|>String.split",";IO.puts for c<-to_char_list(p),do: c<97&&c||97+rem c-71-rem(String.to_integer(n),26),26

# with @MPAherns use of a binary generator in the list comprehension
# 103 characters
[n,p]=IO.gets("")|>String.split",";IO.puts for<<c<-p>>,do: c<97&&c||97+rem c-71-String.to_integer(n),26

From http://elixirgolf.com/articles/the-elixir-caesar-cipher/

I started with a basic working solution:

defmodule Caesar do
  import Stream
  @a String.codepoints "abcdefghijklmnopqrstuvwxyz"
  def encode(n, p) do
    d = @a |> cycle |> drop(String.to_integer(n)) |> take(26) |> Enum.zip(@a)
    Enum.map_join(String.codepoints(p), fn c -> d[c] || c end)
  end
end
IO.puts apply(Caesar, :encode, IO.gets("--enter your code here--\n") |> String.split(","))

• importing Stream was a clear character savings, particularly in the dictionary (d) pipeline
• the module attribute (@a) isn't really a character savings, but I thought it would be at first
• d is what used to be called a ListDict but has been removed. It's much like a Keyword list but does not insist on atom keys. It's going to create a list of 2-tuples like this: [{"d", "a"}, {"e", "b"}, {"f", "c"}, {"g", "d"}, {"h", "e"}, {"i", "f"}, {"j", "g"}, {"k", "h"}, {"l", "i"}, {"m", "j"}, {"n", "k"}, {"o", "l"}, {"p", "m"}, {"q", "n"}, {"r", "o"}, {"s", "p"}, {"t", "q"}, {"u", "r"}, {"v", "s"}, {"w", "t"}, {"x", "u"}, {"y", "v"}, {"z", "w"}, {"a", "x"}, {"b", "y"}, {"c", "z"}]. I could have used a Map here, but this saved a character or 2 in the end.
• Enum.map_join is handy for the output because we want to map and then join the results back into a string. The function passed to it is using the Access protocol to look up in the d dictionary. This returns nil if no matching element was found, so || is used in that case which preserves spaces.
• apply was a handy way to take the split string of the user's input and turn it into parameters for encode

I went through some intermediate steps, but ultimately ended up at 168 characters (wrapped for readability here):

import String;
IO.puts apply fn n,p->
  Enum.map_join(
    codepoints(p),
    &(for c<-0..25,into: [],do:{<<97+rem(c+to_integer(n),26)>>,<<97+c>>})[&1]||&1)
end
,IO.gets("")|>split","

Further golfing steps:

• No more module. apply takes an anonymous function
• No more explicit d. It gets recalculated for each character of input. Horribly inefficient! But it saves a couple of characters and that's the golfing goal.
• Anonymous function shorthand (&) saved a few more chars.
• The list comprehension is a shorter way to do the same pipeline that generated d above. That's what got me under 200 characters and where I stopped.

Last minute change:
I realized I was no longer using any Stream functions, so getting rid of that import takes me down to 168 characters.

Great, that's really helpful... Thanks Ben...

Now I'm tweet sized by doing the calculation inline instead of calculating d. 121 characters

Oh man you are the one to beat now!

115 characters

To be fair, the posted solution only works for offsets up to 26. If we want larger ones, then I can do it in 123 chars:

[n,p]=IO.gets("")|>String.split",";IO.puts for c<-to_char_list(p),do: c<97&&c||97+rem(c-71-rem(String.to_integer(n),26),26)

The posted solution in the gist is 122 characters and works for any offset. I still consider that my own work before looking at how Henrick blended our approaches. That would also let me do 114 characters for an offset of -26 to +26.

Great work... the rules don't state anything about offsets over 26 chars so, it's perfectly valid. Thanks for writing the descriptions I'll be sure to link to it.