F# porting questions

I am contemplating porting a project(already supported by Java, Kotlin, Swift, C#, VB.net, Python and C++) to F#.

1 on visual studio I can’t figure out how to add classes, in files separate than the main class.

the problem is once I add a: .fs file to an F# console app project, it shows an error under: EntryPoint

2 my main interest currently in F# is to figure out what is this
functional programming it has, that lots of people talk about,
and how does it differ than OOP.

I guess you’re trying to add files below the initial Program.fs. You need to add files above Program.fs. To learn more about F#, I recommend F# for fun an profit.

I am struggling to understand you. what do you mean add above? how?

okay looks like I figured it out. there is an add above option in the solution explorer window.

open lg_core
[<EntryPoint>]

let main argv = 
    printfn "%A" argv
    let myObject = MyClass()
    myObject.MyMethod()
    // Add a read line to keep the console open
    System.Console.ReadLine() |> ignore
    0 // return an integer exit code

Yes, you can use “Add above”. Alternatively, if you are in the Solution Window and the file is in the wrong spot, you can use Alt+Up/Down to move a file up or down the current level. To move it into a folder, you’ll need to use the mouse (drag & drop).

Yet another way is doubleclicking the project itself and simply editing the fsproj file, which will then have the project be reloaded in Visual Studio.

An important part of functional programming and F# in particular is that code can be reasoned about. This is why the order of files and functions is important (you need a function or type? It must be defined before the current one). In the beginning this can be frustrating, but after a while you’ll appreciate how easy this makes it to follow a function’s dependencies (“just look up”).

This section discusses how F# projects are organized: Namespaces in F# | Microsoft Learn

Welcome to the forums mr.meeseeks.

If I can add one extra thing to what has been said above it would be to, in general, not implement classes in F# unless you find that you can’t do what you want to do any other way and really need to have classes.

If you are going to implement everything in classes then you’re probably missing out on the best things about F# and you might as well use an object oriented language, such as C#, where class implementation is easier.

If you port a project to F# without taking advantage of what functional programming gives you then there may be no point to porting it over in the first place, or you might be better-off using C# instead.

@GarryP
my goal is to port the LivinGrimoire AGI software design pattern to F#.

github link

I am in the process of learning F# and figuring out the charm of functional programming the F# community raves about, and see what merits it could add to the project.

I don’t know what LivinGrimoire AGI is, and looking at the link you gave and searching the web makes me none the wiser, so it’s probably best if I drop out of this discussion at this point.

Hi, I’m a drop-in! Oh, this is an easy one. It doesn’t matter which software design pattern we’re talking about. We don’t need them in F#. Or rather, in functional programming the answer is always - functions! Functions, functions, functions. Just look at this slide: https://youtu.be/srQt1NAHYC0?t=242

Then watch the video from the start. It’s fun. …ctions. You will be assimilated!

@btran

the LG design pattern adds skills using 1 line of code.
I don’t see how this can be done without classes.
video demonstration of the LG design pattern

I would guess the only dif would be some nested methods be replaced with the pipe operator.

IDK maybe in a few days of studying F# I will see the code flow you guys are seeing, but I don’t see it ATM.

Seems to me that C# source should be pretty easy to translate to F#, in a one-to-one style. That is, keep it as classes in F#. The first goal is just to make it work in F#. There are some tests in text files that seems to be C# or C#-like snippets, so these can perhaps be used as basis for unit tests. The process of translating will give you an excellent opportunity to learn object oriented programming in F#.

When the translation is done, you can start to replace classes and other things with functional alternatives. Classes are typically replaced with records, and with functions that modify these records by taking in one record and giving out another that is a modification. F# for fun and profit is the best source I know of for grokking the functional in F#. It’s like an entire book worth of material there, and it’s free. Do take advantage.

1 Like

When I’m learning a new language I often try and implement a previous example from one of my familiar languages in the style I’m used to. I first try and get it to work correctly. Then, as I learn about the new language, I try and make it follow the idioms/techniques. Invariably, if I try to do things “properly” straight away I just get lost! :grinning:

When I started out with F# there was too much emphasis on functional programming. I wish online resources would have started with showing how to build classes and do object oriented programming in F# first, and use functional programming in the methods. That would have made the transition easier. I actually think F# adoption would be higher if this was the case. Just take a look in fssnip and you’ll find an insane level of functional programming in many samples. No one coming straight from C# is helped by that. It seems many resources are made for expert functional programmers. So much can be made in simple F# instead of the crazy advanced stuff coming over from Haskell.
No: Object oriented shell, functional inside. Straight from BDFL himself.

F# has excellent interoperability with C#, so if you just want your codebase available to F# users, then a C# package is enough. If you want to make the API to be “FSharpy”, or seize the chance to practice F# programming, then you shouldn’t stick to C# practices such as classes, mutability and mutual reference. FSharpers tend to use modules and high-order functions where OOP programmers use classes and inheritance.

dlidstrom, that is indeed the advantage of F# - it is a multi paradigm language, and you can draw on the strengths of the various paradigms. As soon as the functional stuff clicked in place in my head, thanks to Wlaschin, I did unfortunately put too much emphasis on expressing everything in functional terms. That was a bummer that I’m still waiting to correct in my design of my huge project. Don Syme and others have talked about Object Programming in F#, as opposed to Object Oriented Programming. I only have time to find this particular video, and jumping in straight to time OP vs OOP, but watch the whole video for complete context: https://www.youtube.com/watch?v=aw2BAxG3bdM&t=2339s