Function as struct & implicit / explicit export of locals

[Xyncgas]

Say you got a function

let myAct () =
    let myObj = 5
    System.Console.WriteLine(myObj)

you want to access myObj
often as a first step towards alternative methods :

1. myObj moved to out of myAct

let myObj = 5
let myAct () =
    System.Console.WriteLine(myObj)

2. myObj is returned

let myAct () =
    let myObj = 5
    System.Console.WriteLine(myObj)
    struct (myObj)

3. a new structure

type [<Struct>] myClass (_myObj :int) =
    member _.myObj = _myObj
    member _.myAct () =
        System.Console.WriteLine(myObj)
        //I am not returning myObj now because I was simply doing whatever I can to let it be accessable

let myAct =
    let myClass = myClass(5)
    myClass.myAct()
    myClass

As a programming language, we wanna provide a nice experience for people who wants to do it, now I propose how to provide this experience in my opinion by analysing these three cases

1. moving variable out of their scope might be putting it together with variables that belongs to 'other groups' of data, whether this classification has been expressed in code yet
2. you can access the locals only when you call the function, which is the way if they weren't static, but I want being able to mark local as static and access myObj via myAct.myObj
3. classes can't be nested for now in F#, writing classes for enclosure of data has been the way but I find it redundent, imagine you are building an UI window that has this button and that navigation bar these objects adds up it's a lot to write we can do it better

I propose we return locals in functions without people having to write it

1. People can use functions the way they are using, no breaking change
2. accessing locals in function is like 'peaking' what's inside, which should include variables they captured too
   (An operator can support accessing what's in a function, for example myAct()~.myObj)
3. either implicitly export every local + capture or let people declare what locals are exported
   (I say, ~let myObj = 5 for explicit export, once opt in implicit export is disabled, ~let static myObj = 5 makes myAct~.myObj possible : see how I didn't execute the function)

Sample :

let myAct () =
    let static value = 5
    let static myobj = Factory.Generate()
    exe*(myobj)

let anotherFunction () =
    let useful = myAct.myobj
    do_my_stuff (useful)

as you can see functions are now structured, you can confuse them with classes, but the exported context in these functions aren't available as a data structure in the function's return rather it's available as a language feature when you access the function and its return, of course the exports are stored in some data structure ultimately I say it's stored in immutable struct

I say it makes a good case for Haskell's approach of something safe to something safe & useful
how are you feeling after reading

[Happypig375]

moving variable out of their scope might be putting it together with variables that belongs to 'other groups' of data, whether this classification has been expressed in code yet

Use a module.

[Xyncgas]

Using module you can access stuffs inside modules, stuffs inside modules are static
Accessing variables in the function from outside of the function, can be accessing stuffs that belongs to the context it captured, so for example

let myAct () =
    let variables = 0
    doStuff()

let capture = myAct()~.variables

you get immutable variables after executing the function, or you use static mutable to mutate it

let myAct() =
    let static mutable variables = 0
    System.Console.WriteLine(variables)

myAct() //Writes 0
myAct.variables <- 1
myAct() //Writes 1

[Xyncgas]

Use a module

The approach described allows a developer to write 'static methods' in the module together with member methods in object

Imagine having a module called Banana and a struct called Banana in the same file not nested, people can now use whichever(without having to write the module or the struct), it's appealing