This might be interesting! I’m looking for libraries with solid functor, applicative, etc. implementation, to see how this can be combined with my disc_union library. I’ve created a library for discriminated unions (product and sum types) with compile-time warnings, that is basically a bunch of macros that will throw an error at compile time when you miss to cover one of the defined cases.
It would be uber cool if this could be automatically combined with some of your protocols.
X4lldux
1
globalkeith
Interesting stuff QQwy.
I’m a huge fan of FantasyLand and I’ve been trying hard to learn this stuff.
Is it just me, or does Elixir have its map arguments the wrong way round, much like the underscore.js library did, which Brian Lonsdorf gently pointed out in his talk http://functionaltalks.org/2013/05/27/brian-lonsdorf-hey-underscore-youre-doing-it-wrong/
Edit: Sorry OvermindDL1, looks like you already made that point!
2
benwilson512
Author of Craft GraphQL APIs in Elixir with Absinthe
Approaches that make sense in contexts with first class currying don’t necessarily apply to those contexts without.
1
OvermindDL1
Yeah I would love if Elixir put it back to the end in a major version change, like 2.0 or so. I’d also think it would be awesome if you were highly encouraged by the elixir compiler (like it warninged at you if you did not) put a function spec right before the function with the types, and the compiler would check the types (dialyzer-like) at compile-time, maybe even throw in when checks based on those checks (unless explicitly requested not to some how if efficiency was important, or if it verified all paths in the final ‘production’ release were safe).
I want a type system in Erlang so badly, been wanting it since I first started using Erlang over a decade ago… 
I think Elm does a type system pretty well, though it has a few warts that need fixing very very badly, however it is easy to use and the compiler gives awesome messages, even telling you how to fix your code. Haskell’s is awesome, though that may be too extreme for most.
1
benwilson512
Author of Craft GraphQL APIs in Elixir with Absinthe
I think currying can be very cool, but there isn’t a plan here for how to deal with the massive overhead incurred by layering anonymous function on anonymous function for every argument ever. Until someone writes the BEAM to have proper currying support there’s nothing Elixir itself can do.
1
benwilson512
Author of Craft GraphQL APIs in Elixir with Absinthe
To be clear, I’m not trying to say that the work Qqwy has done here isn’t cool, it definitely is. I also see how it can be useful for the library he’s making.
The point I’m trying to make is that proper currying requires support goes far deeper than even Elixir the language can provide, and that without such support I see little value in Elixir 2.0 trying to fake it or go with |> to last argument and so forth.
1
Qqwy
TypeCheck Core Team
I completely agree with @benwilson512 on this. Elixir has made the choice of taking the first parameter as ‘most important’ parameter for its functions. The BEAM does not have built-in support for currying. The library I made here is indeed slower than not using currying, as anonymous functions are being built in intermediate steps.
Elixir is Elixir because of the design choices that were made (Both in itself, and also partially the things that the BEAM or Erlang decided for it). Elixir is awesome because of its ability to build on top of what’s already built in the past on the BEAM.
Elixir is a dynamically typed language with awesome ideas on macro-creation, improving documentation and testing, and promoting explicitness in general (basically, the dynamic types are the only things that aren’t explicit in Elixir).
I really like Elixir because of these things. There are other languages which I like for different reasons. I like Haskell because of its built-in currying capabilities, and its purity which allows for clearer pattern-matching/guards than in Elixir. I dislike Haskell for the ease at which one can write intelligible programs, and for its high learning curve because of some other design decisions (many of which exist for historical reasons).
I like Ruby because it lets you quickly prototype things. I dislike Ruby for its implicitness and approach to monkey-patching.
I like Prolog because it uses the concept of unification and logic programming. I dislike Prolog because it is very hard to wrap your mind around this difference, and because it is very hard to write non-trivial programs with it.
I like Idris because it is a dependently-typed functional language that lets you reason about your code, instead of testing it. I dislike Idris because it still is very new and badly documented and also has a very high learning curve for newcomers.
I like Inform 7 because it lets you write programs in the English language, like they are books. I dislike Inform 7 because you can only use it to write Interactive Fiction with it.
These are just some languages I’ve experienced over the years. There are many more. I would love a language that would perfectly fit my own needs, but the only way to get such a language is to create it myself. Also, these needs will change over time.
And finally, there is no single language that is best for all tasks. It is easier to formulate some tasks in some languages, but there is no one-language-beats-all.
I’m not entirely sure how I ended up here, but anyway, that was my rant for the day, or something 
8
Qqwy
TypeCheck Core Team
Just a little note: Currying has been updated to version 1.0.3 which is a minor change that does not change anything, but cleans up some of the code behind the scenes, possibly making the code slightly faster and at least more readable 
.
2