Sebastián Mestre comments

Results 22 comments of


                                            Sebastián Mestre

There is no way to express the type of a function.

Tbh I don't like any of them

There is no way to express the type of a function.

more ideas (sorted roughly by expected difficulty of integrating into our hand-written parser): ```java (fn a, b, c, d); (fn a b c d); (fn a, b, c => d);...

There is no way to express the type of a function.

I kinda like the `fn: (a, b, c) d` one

There is no way to express the type of a function.

adding `->` solves some problems, but I don't want to be adding new symbols willy nilly. Same thing for the `|a, b, c| d` one: it looks really nice imo,...

There is no way to express the type of a function.

> Well you could add the => symbol instead, which already exists. `->` solves problems *because* it's a new symbol. Using `=>` is unhelpful

There is no way to express the type of a function.

> I don't think we have much of a choice, there are not many ways to express the types of functions that don't look arbitrarily weird, what are you trying...

There is no way to express the type of a function.

Ok, let's go with this for now ```rust fn:(a, b, c) => d; ```

There is no way to express the type of a function.

quick idea for implementation: parse into `CST::FunctionTypeLiteral` when converting into AST, convert into a `PolyCall` where the callee is a new `AST` node: `FunctionTypeFunc` ~(alternatively, during desugaring)~ `ct_eval`-ing a `FunctionTypeFunc`...

Add explicit polymorphism

> Instead of `newvar` it would be cooler to use `forall`. It even has the same amount of letters! Well, that was obviously my first idea. But if you think...

Add explicit polymorphism

> I don't understand, you mean that even if we declare it as a variable, it could still be unified with some type by inference? Precisely.