Higher Kinded Types

[svenalex]

Will there ever be an effort to implement higher kinded types in V like F[_] ? It would not be great, it would be greater :-)
and you would attract functional programmers to the language.

[JalonSolov]

Can you provide a link to describe what you're talking about? I have no idea what you mean by "higher kinded". If I search for F[_] with Google, I get results pointing to Facebook, Ford Motor Company, etc. I don't think that's what you mean...

V does not want to be a functional programming language, though it does have some things in it.

[svenalex]

Hi,

certainly not Facebook or Ford :-)

Vlang already captures most features of a function programming language: immutability, higher order functions, first class functions, closures, lamdas, recursion. Not quit sure of composition - haven't looked at it in detail.

HIgher kinded types allow for definition of a type which takes another type which can be any - so adds another level of abstraction, hence F[] . Type F takes another type _ . When implemented F[] could be Option[Int] or List[String] or Either[(Error,String)].

Now why would this be meaningful, very short answer: There are several ways to write a programm without having to implement anything in FP with F[_] . You would first write some kind of skeleton, what the programm should do and when you implemented it for one type write the implementation part. Free monad and tagless final are both very popular in FP and both need the higher kinded Type.

Programming in FP style with V works already pretty good but for big projects this would be essential.

Cheers

[JalonSolov]

Generics (which V already supports) and sum types won't do what you want?

[svenalex]

sum types are a nice feature of ADT but has nothing to do with it. And the other answer yes but not "effectful" :-)

In Scala, the Tagless Final pattern is typically used with an abstract type constructor F[_] to represent computations within a context, such as a monad. This allows you to write abstract code that can later be interpreted as different effects (e.g., IO, Future, etc.).

If you omit the F[_] and use only a concrete type (or the type _ without a context), then you're effectively giving up the ability to abstract over the computational context, which is one of the core benefits of the Tagless Final pattern. However, you can still implement a similar pattern without relying on monads, focusing purely on abstracting over operations instead of their effects. Sidenote: look at the effect as exception/error/etc. so either you have the value or you have the effect - to all FP programmers I know this is not right but just for explanation. And there are very nice ways traversing over effectful functions in FP.

So this is the reason why I am asking, knowing that this "idea" if ever being implemented will be miles away... but I read that the inventor(s) are very strict on what to implement and when this is done there won't be a 2.0 very soon afterwards if at all. So if the answer would be No - thats fine with me but I really like the syntax and if they will get around the issue with the autofree problems, then V has a very great future - and maybe get a grip on the FP community as well. Pure FP is for academic topics and dreamers. Haskell never made it to the industry and Scala is full blown - you have everything but can be hard especially for beginners. And in Scala you still have the damn NPE.

So the slim V language with FP aspects would be great :-)

Cheers

[svenalex]

I did a little testing and was playing around with vlang last night to find out that there is no support for polymorphism. As the above concepts rely heavily on polymorphism this F[_] request has become obsolete. Just implementing higher types wouldn't do the trick. I think the whole approach must be implemented differently, maybe with Sum type feature an a basic implementation on the Sum type.

However this approach would always have "special" implementations for each use case and no general functions or library could be created.

Thanks
Sven