I'm trying to implement a settings module in my app which should contain information about current state of application. For example, if the user opens some file I need to store the file name. Since I'm still learning F# I want to do it as functional a possible.
I know I should create a new value everytime I change something, but where do I store this value? It should be a singleton and since it's immutable I struggle with the solution.
How do I implement such "global variable"? Does it even play well within functional approach?
This works just as it would within a function, with let mutable (used inside a module):
let mutable a = 4
a // gets a
a <- 6 // sets a
Or, you could use a mutable object as a static member (this example uses a mutable reference cell):
type Settings =
static member Filename = ref ""
Settings.Filename := "OpenMe.txt"
Global variables may be necessary sometimes, and this could be a viable use case, but they are considered dangerous. Values that change and influence a large portion of the program can make things rather unpredictable.
That said, in cases like yours, a single global variable can be a good solution. It could hold a record with the individual settings. I'd pay attention that any operations changing the global variable happen only when the program is in a well-defined state (i.e. not in the middle of a complicated operation) and guarantee that the variable's new value is sound.
Example:
type StateVariables =
{ Filename : string
Opened : int }
module State =
let mutable private cur = { Filename = ""; Opened = 0 }
let get () = cur
let openFile name =
// ...
cur <- { cur with Filename = name; Opened = cur.Opened + 1 }
You can store a global variable in a module:
module Settings =
let mutable FileName = ""
open Settings
FileName <- "foo"
Related
I am an absolute newbie to coding, but I need to modify a F# script. It always gives me the error "Method or object constructor 'x' is not static". I read that this might be due to the fact that I try to call a non-static method within a module, which is by default static. For example 'x' = Get.Axis():
module Primitives =
let axis1 = Zaber.Motion.Ascii.Device.GetAxis(1)
The manual only provides code in C#: var axis1 = device.GetAxis(1);
If I use static member instead of let, I'll get a 'unexpected keyword static in definition' error, although I checked the indentation as suggested in another question.
Assuming you're using the Zaber Motion Library, I think what you need to do is get an instance of a device first, instead of trying to access the class in a static context.
Their documentation includes an example of how to get a list of devices by opening a serial port:
open Zaber.Motion.Ascii
use connection = Connection.OpenSerialPort("COM3")
let deviceList = connection.DetectDevices()
match deviceList |> Seq.tryHead with // See if we got at least one device
| Some device ->
let axis = device.GetAxis(1)
// TODO: Do whatever you want with the axis here
| None ->
failwith "No Devices Found on COM3"
Say:
let x = // some operation
type t = SomeTypeProvider<x>
Is this valid?
No.
Since the types must be generated at compile-time, the parameter to the type provider needs to be a constant.
In other words, the code you marked // some operation can evaluate to a literal, but cannot be a value returned by a runnable function:
let arg = "foo"
type t = SomeTypeProvider<arg> // okay
let [<Literal>] arg = """{"name":"foo","value":42}"""
type t = SomeTypeProvider<arg> // okay
let arg = x.ToString()
type t = SomeTypeProvider<arg> // Boom! arg is not a Literal
It depends on your application, but one of the most common cases is the following:
You have a database-related Type Provider, and the connection string needs to be retrieved in runtime, from some sort of config file or something. So a developer mistakenly thinks they need a runnable code to retrieve the connection string first and then pass it to the Type Provider.
The correct approach is the following:
Keep two databases: one locally stored in a constant location (just for schema), and another one for the runtime purposes.
Pass the first one (a constant!) to your Type Provider. Don't worry about the hardcoded paths; it is only used for schema retrieval.
// Use a fixed sample file for schema generation only
type MyCSVData = CsvProvider<"dummy.csv">
// Load the actual data at runtime
let data = MyCSVData.Load(RetrieveFileNameFromConfig())
The Error Handling chapter of the Rust Book contains an example on how to use the combinators of Option and Result. A file is read and through application of a series of combinators the contents are parsed as an i32 and returned in a Result<i32, String>.
Now, I got confused when I looked at the code. There, in one closure to an and_then a local String value is created an subsequently passed as a return value to another combinator.
Here is the code example:
use std::fs::File;
use std::io::Read;
use std::path::Path;
fn file_double<P: AsRef<Path>>(file_path: P) -> Result<i32, String> {
File::open(file_path)
.map_err(|err| err.to_string())
.and_then(|mut file| {
let mut contents = String::new(); // local value
file.read_to_string(&mut contents)
.map_err(|err| err.to_string())
.map(|_| contents) // moved without 'move'
})
.and_then(|contents| {
contents.trim().parse::<i32>()
.map_err(|err| err.to_string())
})
.map(|n| 2 * n)
}
fn main() {
match file_double("foobar") {
Ok(n) => println!("{}", n),
Err(err) => println!("Error: {}", err),
}
}
The value I am referring to is contents. It is created and later referenced in the map combinator applied to the std::io::Result<usize> return value of Read::read_to_string.
The question: I thought that not marking the closure with move would borrow any referenced value by default, which would result in the borrow checker complaining, that contents does not live long enough. However, this code compiles just fine. That means, the String contents is moved into, and subequently out of, the closure. Why is this done without the explicit move?
I thought that not marking the closure with move would borrow any referenced value by default,
Not quite. The compiler does a bit of inspection on the code within the closure body and tracks how the closed-over variables are used.
When the compiler sees that a method is called on a variable, then it looks to see what type the receiver is (self, &self, &mut self). When a variable is used as a parameter, the compiler also tracks if it is by value, reference, or mutable reference. Whatever the most restrictive requirement is will be what is used by default.
Occasionally, this analysis is not complete enough — even though the variable is only used as a reference, we intend for the closure to own the variable. This usually occurs when returning a closure or handing it off to another thread.
In this case, the variable is returned from the closure, which must mean that it is used by value. Thus the variable will be moved into the closure automatically.
Occasionally the move keyword is too big of a hammer as it moves all of the referenced variables in. Sometimes you may want to just force one variable to be moved in but not others. In that case, the best solution I know of is to make an explicit reference and move the reference in:
fn main() {
let a = 1;
let b = 2;
{
let b = &b;
needs_to_own_a(move || a_function(a, b));
}
}
If I write the following F# code, the compiler issues an error.
let a = 123
let a = 123
The error produced is:
error FS0037: Duplicate definition of value 'a'
If I write the same code in a function like this:
let fctn =
let a =123
let a =123
a
it doesn't produce any error.
I don't understand the difference. Can anyone please explain?
Edit : first code I write in module level.
I agree this is confusing. The problem is that let behaves differently when it is used as a local variable (within a function) and when it is used as a global definition (within a module).
Global definitions (in a module) are compiled as static members of a static class and so a name can be used only once. This means that top-level use of:
let a = 10
let a = 11
... is an error, because F# would have to produce two static members of the same name.
Local definitions (inside a function or some other nested scope) are compiled to Common IL and the variable name essentially disappears (the IL uses the stack instead). In this case, F# allows you to shadow variables, that is, you can hide a previous variable by re-using an existing name. This can be inside a function, or even just a do block inside a module, type or other function:
do
let a = 10
let a = 11
()
This is a bit confusing, because variable shadowing only works inside local scopes but not at the top level. It makes sense when you know how things are compiled though.
As an aside, while IL allows overloads of members by the same name, such overloads cannot be defined at module level in F#. Instead, you'd need to define them specifically as static member on a class (type in F#).
on scope and shadowing
as CaringDev mentioned (but not explained) you will probably see what the shadowing is about when you make the scope a bit more obvious (using the let ... in ... construct #light let you shorten a bit - but you still can use it even without #light off)
Try this:
> let a = 233 in let a = 555 in a;;
val it : int = 555
as you can see the expression evaluates to the shadowed value of a - but the original is not lost:
> let a = 233 in (let a = 555 in a), a;;
val it : int * int = (555, 233)
it's just not in scope in the inner let ... in ...
btw: you can rewrite your example to:
let fctn =
let a = 123 in
(let a =123 in a)
(I added the parentheses just to make this more obvious)
the other on the module level really defines a value for the scope of the module and is not really an expression but a definition
The first snippet defines two public values with the same name.
The second hides (shadows) a value.
With the first you would have externally visible change of state (a behaves like mutable) whereas with the second you can't (you have two as in different scopes).
If you write your statements in #light off ML syntax it becomes obvious immediately.
Just curious why F# has:
member val Foo = ... with get, set
While omitting the self identifier (e.g. this.).
This is still an instance property. Maybe I am the only one confused when using it. But just bothered me enough to query whoever knows how the language was defined.
With this syntax, the property is almost totally auto-implemented -- all you provide is the initialization code, which essentially runs as part of the constructor.
One of the best-practice guard rails F# puts in place is that it does not let you access instance members before the instance is fully initialized. (wow, crazy idea, right?).
So you would have no use for a self-identifier in auto-props, anyways, since the only code you get to write is init code that can't touch instance members.
Per the MSDN docs (emphasis mine):
Automatically implemented properties are part of the initialization of
a type, so they must be included before any other member definitions,
just like let bindings and do bindings in a type definition. Note that
the expression that initializes an automatically implemented property
is only evaluated upon initialization, and not every time the property
is accessed. This behavior is in contrast to the behavior of an
explicitly implemented property. What this effectively means is that
the code to initialize these properties is added to the constructor of
a class.
Btw, if you try to be a smartass and use the class-level self-identifier to get around this, you'll still blow up at runtime:
type A() as this =
member val X =
this.Y + 10
with get, set
member this.Y = 42
let a = A()
System.InvalidOperationException: The initialization of an object or value resulted in an object or value being accessed recursively before it was fully initialized.
at Microsoft.FSharp.Core.LanguagePrimitives.IntrinsicFunctions.FailInit()
at FSI_0013.A.get_Y()
at FSI_0013.A..ctor()
at <StartupCode$FSI_0014>.$FSI_0014.main#()
Edit: Worth noting that in upcoming C# 6, they also now allow auto-props with initializers (more F# features stolen for C#, shocker :-P), and there is a similar restriction that you can't use the self-identifier:
class A
{
// error CS0027: Keyword 'this' is not available in the current context
public int X { get; set; } = this.Y + 10;
public int Y = 42;
public A() { }
}