Playing around with Functor/Applicative-like operators

[Rehno Lindeque]

Elm's operator conventions are slightly different from Haskell - for example $ becomes <| (which I really like!). Keeping this in mind I quickly defined some operators inline for helping me out with List and Maybe in my project (since Elm doesn't have Applicative or Functor for these)

Here they are (http://share-elm.com/sprout/532c2736e4b0f7cc0dd4edf8):

-- Shorthand map over List-like

f <$ lx = map f lx                        -- <$> in Haskell

lx $> f = map f lx

infixr 2 <$

infixr 2 $>

-- Shorthand sequential application

lf <$$ lx = zipWith (\f x -> f x) lf lx   -- <*> in Haskell

lx $$> lf = zipWith (\f x -> f x) lf lx   -- <**> in Haskell

infixr 1 <$$

infixr 1 $$>

--Shorthand map over Maybe

f <? mx = case mx of                      -- <$> in Haskell

  (Just x) -> Just (f x)

  Nothing  -> Nothing

mx ?> f = case mx of 

  Just x  -> Just (f x)

  Nothing -> Nothing

infixr 2 <?

infixr 2 ?>

-- Shorthand sequential application

mf <?? mx = if isJust mx && isJust mf     -- <*> in Haskell

              then Just <| (\(Just f) (Just x) -> f x) mf mx

              else Nothing

mx ??> mf = if isJust mx && isJust mf     -- <**> in Haskell

              then Just <| (\(Just f) (Just x) -> f x) mf mx

              else Nothing

infixr 1 <??

infixr 1 ??>

This is pretty nice when dealing with javascript nulls for example. E.g. (all shape dimensions are Maybes to account for JavaScript nulls)

toShape : Obj -> Maybe Shape

toShape obj = case (obj.shape, obj.shapeDimensions) of

  ("circle", {radius})                -> Circle <? radius

  ("rectangle", {extents})            -> Rectangle <? extents

  ("oblong", {extents, cornerRadius}) -> Oblong <? extents <?? cornerRadius

and lists of paths 

onePxOutlined black <$ [ {- ....bunch of paths to stroke.... -} ]

Obviously this is just a quick subjective hack, but I love the reading the direction of the operators. Out of curiosity, would you do this? Change anything? I notice that ~ doesn't have a visual direction, but it feels a bit strange to define ? and $ (especially because $ would coincide with Haskell's <$>). Could have gone for <$> and <?> but then that also doesn't really look similar to the ~ operator anyway.

[Max New]

I have been thinking about this as well since I tend to use F/A/M a lot in my elm code. My original idea was to use <~ and ~ (https://github.com/maxsnew/Generic/blob/master/Generic/Apply/Maybe.elm) but this is actually pretty unusable in elm right now because you can't qualified import symbols so you can only use one <~ and ~ per module.

The problem with the other approach is that you need to come up with a new symbol for every F/A/M you find. I tend to use the State monad a lot, so what should that get? #? <#, <##, #>>=? It's definitely getting difficult to understand.

In the mean-time, I'm going to go the `elmo` way and try to minimize my use of operators since they're so hard to use with modules, but I don't buy in to the operator-hate that people have here.

Oh and as a side-note, your <$$ and $$> don't correspond to the default applicative instance for [] in Haskell, they correspond to the one for http://hackage.haskell.org/package/base-4.6.0.1/docs/Control-Applicative.html#t:ZipList and in Elm that instance is technically not an Applicative because there's no way to define `pure` without infinite lists (you need a lazy data structure for that).

[Rehno Lindeque]

On Friday, March 21, 2014 3:53:31 PM UTC+2, Max New wrote:

I have been thinking about this as well since I tend to use F/A/M a lot in my elm code. My original idea was to use <~ and ~ (https://github.com/maxsnew/Generic/blob/master/Generic/Apply/Maybe.elm) but this is actually pretty unusable in elm right now because you can't qualified import symbols so you can only use one <~ and ~ per module.

The problem with the other approach is that you need to come up with a new symbol for every F/A/M you find. I tend to use the State monad a lot, so what should that get? #? <#, <##, #>>=? It's definitely getting difficult to understand.

Oh no I agree completely. This is a temporary hack at best, I'd love to get more generic map/bind/apply operators eventually... Fortunately right now I'm only coding up a small self-contained widgets so it's pretty easy to grok - I'm sure it'll get hairy with a bigger project.

 

In the mean-time, I'm going to go the `elmo` way and try to minimize my use of operators since they're so hard to use with modules, but I don't buy in to the operator-hate that people have here.

I'm sure any operator-hate is just about trying to keep the language approachable for beginners :) (I can definitely understand that)

 

Oh and as a side-note, your <$$ and $$> don't correspond to the default applicative instance for [] in Haskell, they correspond to the one for http://hackage.haskell.org/package/base-4.6.0.1/docs/Control-Applicative.html#t:ZipList and in Elm that instance is technically not an Applicative because there's no way to define `pure` without infinite lists (you need a lazy data structure for that).

Oh right! Thank you! I knew that at some point - my Haskell is rusty...

[Jeff Smits]

I wouldn't call it "hate", but as Rehno said, it keeps the language approachable when you limit the amount of operators.

I remember learning a little bit of functional programming for the first time. Our teacher was using Scala and very enthusiastically used operators. One in particular that goes too far for me is (/:) which if I remember correctly is an alias of foldLeft (if not then foldRight).

When I first learned Haskell and read about Functors / Applicative Functors / Monads, and then started using them, I used the general operators. When I looked back at my code after two weeks I couldn't read it. In general my problem with operators for these general concepts is that they can mean very different practical (if perhaps not conceptual) things for different types. That combined with the fact that there can be multiple implementations of F/A/M for the same type makes me wary of (read: dislike) these (too) general operators. But I have to note that I'm not a very experienced Haskell user so maybe it's something to get used to.

What are your experiences in this?

With particular implementations (instances) of F/A/M a specific operator for a much used function or an operator looking like one used in domain literature would be totally ok. Who would want to write `1 + 1 == 2` as `equals (plus 1 1) 2` or even `(1 `plus` 1) `equals` 2` because the verbosity will get to you when you have to read or write many equations.

But I would much rather see Unicode characters for set union (∪) and intersection (∩) signs than | and & even though the OR / AND relation is clear in this case. And I think ideally an operator should only be definable as an alias and there should be a tool that can parenthesise any formula in your code and swap the operators for `in-line` functions. Then non-domain experts can always fall back on that to refactor any equation into something they can also read.

Anyway, that's my opinion on operators. Got a little carried away there :P Please do share your look on general operators for F/A/M and the difficulties I've had with those if it's not too off-topic. I'd really like to know.

--
You received this message because you are subscribed to the Google Groups "Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Max Goldstein]

If we're complaining about the lack of improper unicode symbols, even more obvious that set operations are arrows. Too long and too often have programmers written ->, =>, <- and their ilk. And single-equals assignment, and ! for not instead of ≠. Sub- and super scripts would be nice as well, but pretty soon we're writing LaTeX. Agda went the rich unicode route with its emacs-only IDE. It seems pretty abstract and impractical - when Ulf presented at ICFP last year, he implemented the calculus of constructions, which means exactly nothing to the web developers Elm wants to appeal to eventually.

But to your idea of IDEs switching between operators - perhaps one could display `Set.union` into ∪ without being too bothersome about it? The official encoding would still be ASCII. The IDE would have to be smart enough to understand import qualification, which vim certainly doesn't, it just does string matching. (If there's a more sophisticated plugin, please let me know.) OTOH, visually replacing ASCII arrows could be pretty easy to do.

If it could be done unintrusively, this might be an area in which Elm can take the lead. "Join us in the backwards-compatible Unicode future, whether in the online editor or these emacs, vim, sublime, and lighttable plugins." One day...

See also Bret Victor, The Future of Programming, something about still coding in text files after 40 years.

[John Mayer]

Real Programmers (TM) use meaningfulCamelCaseIdentifiers.

--

[Zsombor Nagy]

:)

NSString *veryCleverComment = [@"Tell me about it!" stringByInsertingLameJoke];

[Dandandan]

I think operators can certainly help in some domains.

People often forget that you can define operator precedence for functions with infix notation, like infix 4 `equals` and infixl 6 `plus`.
That makes it possible to write 1 `plus` 1 `equals` 2.

Op zaterdag 22 maart 2014 07:41:33 UTC+1 schreef Zsombor Nagy:

[Max Goldstein]

On the old docs site, there was a table of infix operator precedence and associativity built from those declarations. That would be a good thing to bring back.

[Joey Eremondi]

I personally am very in favour of infix operators, for a few reasons.

Part of why functional programming is beautiful is that it's descriptive and declarative. Instead of expressing instructions, you express relationships. These relationships ultimately are logical and mathematical. So for me, the more that writing a program feels like math, the more natural and descriptive it is to express those relationships which define my program.

For functors in particular, I think having something like <$> is very useful. In Haskell, it's easy to see the relationship between $ and <$>: one is function application, and one is application of a function while lifting into the Functor. So in elm, having <| for application and <|| or <<| or something similar would be useful, because now the programmer can think of fmap as just a special kind of funciton application.
(I realize this probably isn't possible until we can get higher-kinded polymorphism working).

I have similar feelings about operators on vectors. I want to be able to use + on a vector or matrix, and to be able to use * for vectors and matrix products. This makes it feel more like math, which makes it easier to understand the program as relationships between entities, rather than as a complicated chain of function calls.

[Sean Corfield]

On Mar 22, 2014, at 12:22 PM, Joey Eremondi <jmit...@gmail.com> wrote:
> For functors in particular, I think having something like <$> is very useful. In Haskell, it's easy to see the relationship between $ and <$>: one is function application, and one is application of a function while lifting into the Functor.

And who is the audience for Elm? Is it just Haskell programmers wanting to write web apps? Or is it intended to appeal to a broader audience of web app developers?

I know a lot of Elm is rooted (deeply) in Haskell but I think Elm can - and should - make sure it will appeal to a much broader range of developers. Frankly I think <$> is ridiculously cryptic and hearing your explanation just makes it sound worse (no offense - I totally understand that if you're familiar with Haskell this seems like second nature).

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

[Brian Slesinsky]

Some concurring thoughts from very part-time functional programmer. (My background is that I learned ML in school 20 years ago and have dabbled with Haskell, but for my day job I use Java, Go, and JavaScript.)

I think if you want to appeal to non-functional programmers, it is useful to have a syntax that encodes dataflow. I'll make an analogy to Forth. An expression like this is fairly understandable once you've learned postfix:

  1 2 + 3 *

We know that 1, 2, and 3 put an item on the stack, and + and * replace two items with one.

However, if you don't know the definition of the words, you can't deduce anything about dataflow:

  foo bar baz quux

To understand such an expression, Forth programmers document words using stack comments telling you what happens to the stack. You have to look up every definition or you're lost. Forth seemed very powerful at the time, since it's very compact and you can define your own control statements, but in the end this wasn't popular.

Lisp goes the opposite way. Putting special forms and macros aside, the dataflow is clear even when you don't know any definitions:

 (foo (bar baz) quux)

Of course Lisp is not that popular with mainstream programmers, but function calls in mainstream languages are similarly clear.

Currying in functional languages strikes me as similar to Forth in that you must know the type of every symbol to understand dataflow. Perhaps mathematicians are used to needing to memorize the definition of every symbol, but mainstream programmers generally need to dive into code we've never seen before and look up definitions as needed. (The hints at elm-lang.org/try are very useful, though perhaps they should be more prominent and also be available for your own definitions.)

The special operators that functional programmers like so much seem to me roughly like the stack manipulation words in Forth, which juggle the stack in preparation for the next operation, without doing anything "real". They can be powerful but defining more notation leads to mathematical obscurity, not accessibility.

At the other extreme, we could have a fully graphical representation which would represent dataflow visually as nodes in a graph. Here we have the dream of the programming language that non-programmers can understand.

Non-curried function calls in mainstream languages seem like a useful compromise, where at least the nodes are clear even if the overall graph takes a bit of deciphering. The syntax in data languages like XML and JSON is also quite accessible, and the various HTML template languages are popular for similar reasons.

- Brian

[John Nilsson]

For what it's worth. A function like CombineLatest[1] in Rx feels rather straight forward to me. A more abstract interpretation would be to just add overloads to Select[2] which is the Linq name for fmap. At least in C# this is better than Lift due to the difference in syntax (no partial application) and limited type inference.

Translated to haskell/elm I guess it would mean adding overloading, probably not an option, or just stick with something like lift (even rename map to lift for consistency?)

BR,

John

[1] http://msdn.microsoft.com/en-us/library/hh211991(v=vs.103).aspx

[2] http://msdn.microsoft.com/en-us/library/system.linq.enumerable.select.aspx

[Max Goldstein]

Even if we get general functors, I think signals should be special. They are the only impure (at runtime) components, and so lifting a function onto a signal feels very different from mapping it over a list (even though foldp makes excellent use of this parallelism).

For what it's worth, I really like how the |> operator lets you write code like circle 20 |> filled blue |> move (20,30). In my earliest experiences with Elm, I could immediately tell that these commands were associated, even without knowing the formal semantics. But having those semantics is very important.

Type classes and higher-kinded polymorphism both look like they could allow a small set of familiar operators to have many meanings, avoiding ||> and such, though they don't quite feel right. Evan linked to these two articles on GitHub recently. The other alternative is what R does, which is map functions implicitly. For example, c(1,2,-3) creates a vector with those numbers, and abs(c(1,2,-3)) == c(1,2,3). I find this very difficult to reason about and would likely make type checking much more difficult.

(The hints at elm-lang.org/try are very useful, though perhaps they should be more prominent and also be available for your own definitions.)

There's an idea ... Python has docstrings, and Elm has {-| documentation -} that could be co-opted into definitions for the live hints. I'm always in favor of more intelligent IDEs. 

[Alex Neslusan]

I was recently having a discussion on a programmer forum about operators. Everyone ended up making fun of this. Operators have a place, but you don't want to end up like that or you'll drive most people away. I think there's probably more cognitive overhead in (%~) compared to `over`

[Antti Rasinen]

On 21.3.2014, at 22.15, Max Goldstein wrote:

If we're complaining about the lack of improper unicode symbols, even more obvious that set operations are arrows. Too long and too often have programmers written ->, =>, <- and their ilk. And single-equals assignment, and ! for not instead of ≠. Sub- and super scripts would be nice as well, but pretty soon we're writing LaTeX. Agda went the rich unicode route with its emacs-only IDE. It seems pretty abstract and impractical - when Ulf presented at ICFP last year, he implemented the calculus of constructions, which means exactly nothing to the web developers Elm wants to appeal to eventually.

But to your idea of IDEs switching between operators - perhaps one could display `Set.union` into ∪ without being too bothersome about it? The official encoding would still be ASCII. The IDE would have to be smart enough to understand import qualification, which vim certainly doesn't, it just does string matching. (If there's a more sophisticated plugin, please let me know.) OTOH, visually replacing ASCII arrows could be pretty easy to do.

That sounds a lot like what Fortress tried to do, except more sophisticated. The big idea in Fortress, as far as I've understood it, was to allow user to input Unicode as ASCII with conventional editors and as symbols with advanced editors. 

It wasn't always the prettiest mapping. This is from the language spec, page 119: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.135.6026&rep=rep1&type=pdf

(GREEK_SMALL_LETTER_PHI GREEK_SMALL_LETTER_PSI + GREEK_SMALL_LETTER_OMEGA GREEK_SMALL_LETTER_LAMBDA)
is converted to:
(φ ψ + ω λ)

(They had aliases for more common operations, though.)

It's sad Fortress didn't survive in the end. Many good ideas, including units. The tutorial (http://stephane.ducasse.free.fr/Teaching/CoursAnnecy/0506-Master/ForPresentations/Fortress-PLDITutorialSlides9Jun2006.pdf) still makes my heart race at places. Slide 63 has the title "But Wasn’t Operator Overloading a Disaster in C++ ?", which might be relevant for this thread as well :-)

—Antti

[Alex Neslusan]

I'm pretty sure you can already do this in Haskell. You can write stuff like:

λx -> x + 10
x ≫ return y
if x ≠ 3 then ...

It might be a language extension. I forgot.

[Alexander Noriega]

Sean Corfield:

You cut Joey Eremondi's explanation short in your quoting of it, and then said that it only "makes it worse", but your "ridiculously cryptic" accusation carries zero information or utility whatsoever, whereas Eremondi's point was valid and perfectly sensible, namely: there's a semantic relationship between `$` and `<$>` in Haskell, so it'd be useful to have an equivalent relationship in Elm (where it'd be `<|` and something).

And calling unfamiliar things "ridiculously cryptic". Seriously? Where are we, the Javascript IRC channel?

--Alexander

[Max New]

Honestly, Lens has so many functions exported that it's a lot easier for me to remember the operators (since they have a consistent naming scheme) than what `over` means.

[Jeff Smits]

Maybe I'm reading this wrong and if so I apologise, but you sound a little offended Alexander. Just take it easy, Sean meant no offence as he explicitly wrote.

This is a topic where opinions vary, and I don't think we should be looking for a universal answer.

I've been reading everyone's responses with a lot of interest.

I like Joey's view of using operators to make a program more like a set of equations, thereby making it look more declarative.

I think Sean is right that too many operators make things cryptic, that why I mentioned Scala's operators for variants of fold. I think "going too far" with this is different for everyone, as I think Alexander meant to point out. Alex Nesulan's example of the operators for Lenses is a nice example of something I would find cryptic. Then again I understand that the different symbols in the operators have distinct meaning and if I knew how to pronounce them I would probably be able to figure it out.

I really like that Brain mentioned seeing the function application operator as equivalent to stack manipulation. I've always seen flip : (a -> b -> c) -> b -> a -> c as the functional programming equivalent of swap and sometimes you can see always : a -> (b -> a) as equivalent to pop, but I would not have thought of function application like that.

Antti, I always like reading through Fortress documentation. There were lots and lots of great ideas there. But I think in the end they wanted too much.

I still have an open question for experienced Haskell users: How do you wrap your head around the use of say mappend or <*>? Such an operation can have multiple (rather different) meanings for the same type depending on the instance of the type class you use...

[Dylan Sale]

Here's my 2 cents.

I'm a newbie FPer and have just read a few Haskell tutorials. I much prefer elm due to its lack of a million operators.

I have seen <$> used in a lot of Haskell code but I never knew what it meant because it is impossible to Google. I still don't really know but from this discussion it seems like it's the same as $ but lifts the functions as well or something?

This gets much worse when reading code that uses these operators all over the place.

Not to mention I have no name for the operators so I can't "read" the code so much as try to look at it and give names to things myself. It makes learning hard and I come from a math background!

(Another great thing about try elm is the hints on how to read the few operators there are.)

I think brevity shouldn't be at the expense of maintainability.

[Sean Corfield]

On Mar 23, 2014, at 5:09 AM, Alexander Noriega <lambd...@gmail.com> wrote:

And calling unfamiliar things "ridiculously cryptic". Seriously? Where are we, the Javascript IRC channel?

Calm down! :)

I've been designing and implementing programming languages on and off for about 30 years (and spent nearly a decade working on X3J16, the ANSI C++ Standards Committee). When I say that "I think <$> is ridiculously cryptic" (which, by the way is an _opinion_), I'm speaking from the viewpoint of dozens of languages over several decades.

I know there are a lot of Haskell fans in the Elm community but you really need to consider a _broader_ audience, if you want Elm to be anything more than a niche curiosity. Haskell has failed to gain popularity in large part because of "ridiculously cryptic" syntax - and the morbid attachment to monads, without which you can't get anything useful done in Haskell! And, yes, I happen to like Haskell - a lot. When it appeared 20+ years ago, I hoped it would become really popular - I'd spent most of the 80's doing functional programming but designing and building compilers in C and C++ so I was certainly ready for a "better" language... but successful languages have to be pragmatic about their syntax.

[Dylan Sale]

I also want to add that if Elm is to become popular, then yes, people in the Javascript IRC channel are exactly the people you want to design the language for.

Anything that you literally can't search for on Google (<$> gives: "Your search - <$> - did not match any documents"), is by definition cryptic. It ceases to even be an opinion at that point (though I guess the ridiculous part still is).

[Quildreen Motta]

Operators are as inherently cryptic as unfamiliar names. If you don't know what a `fold` is, then it doesn't matter whether the operation is called `foldl` or `./`, as you would still need to go through the process of learning the concepts behind that operation (relying on English or any other natural language only gets you so far, and in most cases they lead you in the wrong direction — specially in English since some words are quite overloaded). The overuse of operators (as well as the overuse of unfamiliar words) may lead to programs that are difficult to read, however. I like Evan's guidelines on the naming of operations (http://library.elm-lang.org/DesignGuidelines.html#naming), although I would not be so extreme as to say "avoid operators at all costs".

As for searching for such functionality, we would hope that Elm gets something like Hoogle (http://www.haskell.org/hoogle/) or Hayoo!, these will help you much more than google for whatever operation you happen to find in a program. Smart text editors/IDEs could also provide you with relevant information about any unfamiliar construct right away in the directly on the point they are used, which IMHO would make for a much better tool to understanding how something works/what something is than having to drop to google everytime you see something unfamiliar.

On the subject of popularity, I wouldn't say that "cryptic" is entirely related. Just look at how the most popular languages used (JavaScript, Java, C#, ...) not only feature cryptic syntax (specially if you compare with Smalltalk or Ruby), but also provide complex semantics and constructs that are extremely difficult to reason about, such as for-loops. They do have marketing and (arguably) good tooling going for them, however. I think Elm would benefit much more in terms of popularity by providing a really healthy tooling environment, and given the semantics of the language, it's much easier to derive amazing tooling for it than, say, for JavaScript.

[Brian Slesinsky]

On Sun, Mar 23, 2014 at 4:59 PM, Quildreen Motta <quil...@gmail.com> wrote:

Operators are as inherently cryptic as unfamiliar names. If you don't know what a `fold` is, then it doesn't matter whether the operation is called `foldl` or `./`, as you would still need to go through the process of learning the concepts behind that operation (relying on English or any other natural language only gets you so far, and in most cases they lead you in the wrong direction — specially in English since some words are quite overloaded). The overuse of operators (as well as the overuse of unfamiliar words) may lead to programs that are difficult to read, however. I like Evan's guidelines on the naming of operations (http://library.elm-lang.org/DesignGuidelines.html#naming), although I would not be so extreme as to say "avoid operators at all costs".

These guidelines are good but I think I'd go further and make custom operators non-importable. If someone really wants to use them, they can define them at the top of each file and that will help the reader.

Similarly, symbols without type annotations should be non-importable. If it's worth sharing in a module, it's worth documenting the type.

- Brian

[Max Goldstein]

I think there was some edge case where the compiler would not accept a correct annotation for certain types (tuples?). Assuming that was fixed, I would make unannotated symbols non-exportable, enforced by elm-get if not the compiler. What we don't want is a package of unannotated symbols in the third-party library that can't be imported through no fault of the client.

Quildreen's comment on names being cryptic reminds me of the other thread about bind and flatMap. Clearly, names that describe their function are better than those that do not, and operators typically do badly there. But at least with <| I know the arrow points towards the function, unlike $.