5

According to Hoogle, the fixity of <=< (Kleisli monad composition, or "left fish") and =<< (reverse monad bind) is infixr 1. If I'm looking at them correctly, an expression like, say

print <=< return =<< return "foo"

should be invalid, since it would've been equivalent to the equally invalid

print <=< (return =<< return "foo")

But for some reason, though the first expression seems to be invalid in Haskell, as expected, Frege seems to have no complaints, and evaluates <=< before the =<<.

I discovered this when I was messing around on pointfree.io to figure out how to make something like

foo >>= (bar <=< baz)

point-free, and it gave me

bar <=< baz =<< foo

which doesn't look quite right, considering the fixities.

Mona the Monad
  • 2,265
  • 3
  • 19
  • 30

1 Answers1

6

Frege is like Haskell, but Frege is not Haskell. And in Frege, the fixities of those operators are different: =<< is infixr 2 and <=< is infixr 3. So since <=< has lower precedence, bar <=< baz =<< foo is naturally parsed as (bar <=< baz) =<< foo.

(In fact, =<< and <=< have different types in Frege than they do in Haskell: instead of a Monad constraint, they have a Bind constraint, where Bind is like Monad without pure/return.)

Yes, Frege describes itself as "a Haskell for the JVM", but they mean "a Haskell" in the sense that Common Lisp is a Lisp, and Scheme is a Lisp, and Clojure is a Lisp. It's odd to see "Haskell" used in that way; it would be more normal to see "a Haskell-like language for the JVM", or something stronger. But Frege is so similar that I can see why.

Also, you're right: that does appear to be a bug in pointfree (the program that backs pointfree.io)! pointfree is supposed to generate Haskell code, not Frege, so the fact that that transformation is invalid means it's doing the wrong thing.

Antal Spector-Zabusky
  • 36,191
  • 7
  • 77
  • 140
  • 2
    The type diffeence in Frege is probably because the AMP (or an even more radical Monad class hierarchy) was implemented right from the start there, years before it was done in GHC. I ask you kindly to consider whether it is fair to deny Frege the "Haskell property" on this ground. In this strong sense, no post-AMP Haskell program is actually written in Haskell. This makes no sense, IMHO. (To be sure, I'm aware that there are other reasons to deny Frege the full Haskell-ship.) – Ingo Oct 06 '16 at 17:14
  • @Ingo: I was attempting to say "Frege is not Haskell, therefore it is unsurprising that it would be different; and indeed, it is different in these ways." In other words, I would put the causality the other way around :-) The "Haskell property" comment was a comment about English-language usage: Frege is the only language I've seen described as "a Haskell", so that's an unusual way to describe it, and I thought that was important to call out as a potential source of confusion. – Antal Spector-Zabusky Oct 06 '16 at 18:14
  • 1
    I have to admit that I'm not 100% happy with the "Haskell for JVM" slogan either, that is one reason why I choose a different name in the first place. But it was actually SPJ himself who encouraged us to be more offensive in this regard, dismissing the (still existing) differences as negligible. I also agree that the "a" may be a bit disturbing. – Ingo Oct 06 '16 at 18:30
  • @Ingo: I'm sorry, I didn't realize that *you* were the author of Frege! To be super clear about what I was saying: I don't *object* to the naming *per se* – I don't know enough to have an opinion – I just thought that it was perhaps confusing, particularly in the context of this question. I don't know enough to decide whether or not Frege has "the full Haskell-ship"; you're rather more of an expert than I am :-) – Antal Spector-Zabusky Oct 06 '16 at 19:46
  • 1
    Hey, no need to be sorry, I didn't take any offence! As I said, I know very well that Frege is not there yet. For the record, I initially came up with "Frege, a pure functional language for the JVM in the spirit of Haskell" but this was dismissed later on the ground that it might indicate a rivalry towards Haskell. But to the contrary! My objective was, of course, to be as "haskellish" as possible. OTOH, this wouldn't imply copying already exposed shortcomings in Haskell, like Monad not being an Applicative, etc. – Ingo Oct 06 '16 at 20:04