Add infix operators about fcore HOT 45 CLOSED

How about status of this issue?

from fcore.

@zonyitoo Won't be implemented any time sooner.

from fcore.

@lihuanglx So this is done?

from fcore.

There is a difference between infix operators and been anle to use prefix functions as infix functions. I believe Huang implemented the later, bit not the former.

from fcore.

Alright, so

• Using prefix functions with infix notation, e.g.,

  1 `add` 2

• Using infix functions with prefix notation, e.g.,

  (+) 1 2

from fcore.

Well, what I meant was, being able to define infix operators, such as:

(+++) :: [a] -> [a] -> [a]

in Haskell. Which then you can use as:

[1,2] +++ [3,4]

I believe this is also what @zonyitoo meant.

from fcore.

@brunocdsoliveira Yes, exactly.

from fcore.

@lihuanglx Seems it does not work with type parameters

-- ADT List
data PList[A] = Nil
              | Cons A (PList[A])
              ;

let cons[A] (v : A) (l : PList[A]) : PList[A] =
    Cons[A] v l;

1 `cons[Int]` (Nil[Int])

And it also failed to handle this case

let add (v : Int) (a : Int) (b : Int) : Int =
    v + a + b;

1 `add 2` 3
      ^~~~ Lexical Error

from fcore.

1. Define something like let conInt = cons[Int] will avoid the problem
2. Application inside backquote is not allowed, even in Haskell

BTW, cons (and length, nil ...) has been occupied as a keyword. @zonyitoo

from fcore.

@wxzh Alright. Then the second one should not be allowed.

The first case should be supported.

from fcore.

@zonyitoo Type parameters supported.

let theSecond[A,B] (a:A) (b:B) = b;

1 `theSecond[Int,String]` "abc"                             ===> "abc"

1 `theSecond[Int,String]` "abc" `theSecond[String,Int]` 6   ===> "6"

from fcore.

Sorry.. misclicked

from fcore.

@lihuanglx excellent

from fcore.

let (++) (x:String) (y:String) : String = x.concat(y);

"ab" ++ "cd" 

Or regard (++) as a normal function as below.

let (++) (x:String) (y:String) : String = x.concat(y)
and gao (f:String->String->String) (a:String) (b:String) : String = f a b;

gao (++) "ab" "cd"

(++) "ab" "cd"

from fcore.

@lihuanglx Is that work now? Here is a parse error

let (:)[A] (a : A) (l : PolyList[A]) = Cons[A] a l;

from fcore.

@lihuanglx how to call this function

let (++)[A] (a : PolyList[A]) (b : PolyList[A]) : PolyList[A] = ...

how to apply the type parameter??

from fcore.

@zonyitoo

1. Only !#$%&*+./<=>?@\^|-~ supported, please try another symbol instead :.
2. Just like a normal function, list1 ++[Int] list2.The type inference is not strong enough now, so it needs explicit type notation -_-||.

from fcore.

@lihuanglx alright, sounds reasonable. ;)

from fcore.

@lihuanglx i can't define an operator named <+> or <|>? They are in your supported list.

from fcore.

let (<+>) [A] (a : A) (b: A) = a;
1 <+> 2

Maybe you forgot the parentheses?

Like Haskell, it requires parentheses in the definition.

from fcore.

@lihuanglx Ah!!! Stupid mistake! Thanks!!!

from fcore.

@lihuanglx Do you consider this feature fully implemented?

from fcore.

@bixuanzju Yes, it should be closed now.

from fcore.

@lihuanglx Do you allow infixity declarations for the operators, as in Haskell?

from fcore.

@brunocdsoliveira

Sorry, I didn't take that into consideration. I'll improve it.

The new goal is to allow:

let a <+> b = a + b
let a `add` b = a + b

from fcore.

@lihuanglx How about associativity?

from fcore.

@zonyitoo All user defined operators have left associativity and the highest precedence.

from fcore.

@lihuanglx it would be better if operators could supports right associativity, or you will have to add brackets around them.

from fcore.

@zonyitoo Thanks, I'll consider that.

from fcore.

@zonyitoo @lihuanglx In Haskell, you can define the associativity, say

infixr 9 <+>

I don't know if it's easy to implement in our language. Since most operators are left associative, it's reasonable to use it as default.

from fcore.

@bixuanzju I agree with making left associativity as default, but some of the operators have to be right associative. Such as : in Haskell, or the magical $ operator in Haskell.

from fcore.

@lihuanglx what I suggested above was to allow infixity declarations, such as the one Jeremy has shown:

infixr 9 <+>

so that the default settings can be overriden. This may require some more work.

I didn't mean to allow this:

let a `add` b = a + b

This does not seem helpful to me.

from fcore.

@lihuanglx Should this situation be allowed in F2J?

data Doc = Text String
         | Line Int
         | String `Text` Doc;

Also, I cannot use the constructor of data in infixop.

from fcore.

@zonyitoo As to the first issue, I don't think so.

from fcore.

@zhiyuanshi Why? Seems Haskell supports that.

from fcore.

@zonyitoo You can't define a datatype like this, you have two constructors, both named Text

from fcore.

@bixuanzju @zhiyuanshi Ahhhh, alright, that's a bad example...

from fcore.

@zonyitoo Data constructors can't be used in infixop, that's true

from fcore.

I think I should invite @Demonsu to demonstrate the problem. I don't know the detail of his problem.

from fcore.

@zonyitoo Do you mean that you want something like "1 Cons Nil "? It should be valid. I think there is a missing case in the parser for it. @lihuanglx

from fcore.

@wxzh Humph.. yes, this case should be valid. But should this case be valid?

data Doc = Text String
         | Line Int
         | String `Union` Doc;

from fcore.

@zonyitoo Yes, you can do this in Haskell. But why do you want to define it in this way? I don't see any benefits it brings.

from fcore.

@wxzh I don't know, is not me... I didn't use that in F2J, but I just curious about whether it should be included in F2J.

from fcore.

Sorry guys. Yesterday, I was not sure that my pretty printer lib can be implemented without infix constructors. Then I mentioned it with Elton. It seems can be replaced by prefix. And I just finish it in f2j.

from fcore.

@Demonsu It does not matter. You help us to find a bug in the Parser :). For now, you should always define functions and constructors in prefix annotation, but you can use them in infix annotation (after @lihuanglx fixes it).

from fcore.