Instead of importing a whole module, is there a way to open specific functions in another module? Something like:
open TestFuncs with [myTestFuncInOtherModule]
As you can see in the docs, the open keyword doesn't actually load a module or namespace. It just allows you to refer to elements in that module/namespace without refering to their fully qualified name.
Being so, when you use open you're just making it easier to call the functions in that module, not actually importing/loading them in memory, so the short answer for this question is that using the open keyword you can't do this to only one function.
You can achieve the same thing easily with a let binding, though:
let f = TestFuncs.myTestFuncInOtherModule
It's not currently possible, but I've actually put in a request for this to be added to the language. If you want to see this added in F# 4.0, one thing you could do is go vote for that request.
Another good workaround, that hasn't been mentioned yet by other answers, is to "pseudo-open" modules: assign a short name to modules whose contents you want to use. Like so:
module TP = Microsoft.FSharp.Data.TypeProviders
type mySchema = TP.SqlDataConnection<"...">
let db = mySchema.GetDataContext()
This gives you the convenience of not having to type the whole module name every time you want to reference its contents, but you maintain control of your namespace: this way there's no chance of accidental name collisions when you update a module to a new version and it adds new names.
You can refer to particular functions in another module using full function name ModuleName.funcName:
module One =
let square x = x * x
module Two =
let anothersquare x = One.square x
Related
open System
open System.Runtime.CompilerServices
open Mono.Cecil
open Mono.Cecil.Rocks
type SpiralType =
| IntT
| StringT
| TupleT of SpiralType list
let module_ = ModuleDefinition.CreateModule("TypeTokenFactory",ModuleKind.Console)
let r1 = module_.ImportReference(typeof<obj>)
let r2 = module_.ImportReference(typeof<obj>)
let table = ConditionalWeakTable()
table.Add(r1,IntT)
table.Add(r2,StringT)
let mscorlib_path = #"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\mscorlib.dll"
let mscorlib = AssemblyDefinition.ReadAssembly(mscorlib_path)
let dictionary_type =
mscorlib.Modules.[0].Types
|> Seq.find (fun x -> x.Name = "Dictionary`2")
let dict_ins = dictionary_type.MakeGenericInstanceType([|r1;r2|])
// Lacks the Methods field...
I've long been trying to figure out how make the above work with System.Type, but now I am trying to do it with Mono.Cecil. For a bit of history on what I am trying to do, take a look at my last two questions here on SO and the issue I opened on the F# repo that goes into it in great depth.
Let me summarize it shortly here: For the sake of integration with the language I am making, I need to be able to query the .NET assemblies for their types and do substitution of generic parameters for both classes and the methods.
Now, I do not need exact types to be substituted. As the example above shows, attaching metadata to a dummy type would be quite enough for my purposes, but now I have the problem in that unlike with System.Type, once I substitute the generic parameters I am no longer able to query the methods on the type.
So close. Is there any way to make this work with Mono.Cecil? Alternatively, I'd appreciate knowing if it would be possible with some other library. I do not need Cecil's assembly editing abilities at all for my purposes.
Cecil provides you with a relatively low level view of the metadata.
Cecil will provide you with ways to represent the different metadata constructs in an assembly, but not with the runtime representation of the types.
To answer your question, it won't tell you the methods of an instantiated generic type as this is a runtime construction, not something available from the metadata.
Higher level APIs like System.Reflection or IKVM.Reflection will do that.
According to the GTK API reference, the "license-type" property of GtkAboutDialog is only present in GTK >= 3.0. For compatibility, my code currently checks the GTK version before setting the "license-type" property:
-- This is Lua code binding to GTK via lgi
local dialog = Gtk.AboutDialog {
title = "About Me",
-- ...,
}
if Gtk.check_version(3,0,0) == nil then
dialog.license_type = Gtk.License.MIT_X11
end
Instead of doing this, is there a way to directly ask GTK if a widget supports a certain property? I think the code would be more self-documenting and less bug prone if I could write something that looks like
if supports_property(dialog, "license-type") then
dialog.license_type = Gtk.License.MIT_X11
end
Since this question is really about the GTK API, I'm OK with answers in any programming language. Although the examples are in Lua, I assume a similar problem should show up in other dynamic-language bindings or even in C, assuming that there is a way to set properties by name without going through the set_license_type accessor function.
You don't need to use the _property field like you are doing in your currently accepted answer since lgi finds all names in the type categories tables directly. Additionally, it is also possible to get type of an instance using _type accessor. So I'd recommend following solution:
if dialog._type.license_type then
dialog.license_type = Gtk.License.MIT_X11
end
You can use the g_object_class_find_property() function to see if a property exists.
Note that this function takes a GObjectClass, not the GObject instance. All GObject classes come in these class-instance pairs, with the class structure used for shared things like vtable methods. To get the GObjectClass associated with an object instance, in C, you can use the G_OBJECT_GET_CLASS() macro. (If you want to do this in Lua, and if Lua can't call C macros like that, you'll have to trace the definition of G_OBJECT_GET_CLASS().)
In lgi, a class's properties are present in its _property field:
if Gtk.AboutDialog._property.license_type then
dialog.license_type = Gtk.License.MIT_X11
end
If for some reasons you need to know if a property is present without instantiating it, you can go with #andlabs idea in this way:
local lgi = require'lgi'
local Gtk = lgi.require'Gtk'
local class = Gtk.AboutDialogClass()
-- Prints yes
if class:find_property('license') then print('yes') end
-- Does not print anything
if class:find_property('unknown') then print('yes') end
I'm trying to create a connection to open a database over ODBC. I cannot figure out how to execute an objects member functions. The code:
let DbConnection = new System.Data.Odbc.OdbcConnection()
DbConnection.open
The errors I get are: Missing qualification after '.'
or sometimes: unexpected identifier in implementation file
Does anybody know what is wrong with my syntax?
I suppose you wanted something like this:
let dbConnection = new System.Data.Odbc.OdbcConnection()
dbConnection.Open()
The problems are:
F# is case sensitive so you need Open rather than open (also open is a language keyword, so if you wanted to use it as a name, you'd have to write ``open`` - the double back-tick is a way to refer to reserved names)
Open is a function, so if you want to call it you need to give it an argument. You can treat it as a function value too and write, say, let f = dbConnection.Open
I also changed your naming to use camelCase for variables, which is the standard F# way
For recursion in F#, existing documentation is clear about how to do it in the special case where it's just one function calling itself, or a group of physically adjacent functions calling each other.
But in the general case where a group of functions in different modules need to call each other, how do you do it?
I don't think there is a way to achieve this in F#. It is usually possible to structure the application in a way that doesn't require this, so perhaps if you described your scenario, you may get some useful comments.
Anyway, there are various ways to workaround the issue - you can declare a record or an interface to hold the functions that you need to export from the module. Interfaces allow you to export polymorphic functions too, so they are probably a better choice:
// Before the declaration of modules
type Module1Funcs =
abstract Foo : int -> int
type Module2Funcs =
abstract Bar : int -> int
The modules can then export a value that implements one of the interfaces and functions that require the other module can take it as an argument (or you can store it in a mutable value).
module Module1 =
// Import functions from Module2 (needs to be initialized before using!)
let mutable module2 = Unchecked.defaultof<Module2Funcs>
// Sample function that references Module2
let foo a = module2.Bar(a)
// Export functions of the module
let impl =
{ new Module1Funcs with
member x.Foo(a) = foo a }
// Somewhere in the main function
Module1.module2 <- Module2.impl
Module2.module1 <- Module1.impl
The initializationcould be also done automatically using Reflection, but that's a bit ugly, however if you really need it frequently, I could imagine developing some reusable library for this.
In many cases, this feels a bit ugly and restructuring the application to avoid recursive references is a better approach (in fact, I find recursive references between classes in object-oriented programming often quite confusing). However, if you really need something like this, then exporting functions using interfaces/records is probably the only option.
This is not supported. One evidence is that, in visual stuido, you need to order the project files correctly for F#.
It would be really rare to recursively call two functions in two different modules.
If this case does happen, you'd better factor the common part of the two functions out.
I don't think that there's any way for functions in different modules to directly refer to functions in other modules. Is there a reason that functions whose behavior is so tightly intertwined need to be in separate modules?
If you need to keep them separated, one possible workaround is to make your functions higher order so that they take a parameter representing the recursive call, so that you can manually "tie the knot" later.
If you were talking about C#, and methods in two different assemblies needed to mutually recursively call each other, I'd pull out the type signatures they both needed to know into a third, shared, assembly. I don't know however how well those concepts map to F#.
Definetely solution here would use module signatures. A signature file contains information about the public signatures of a set of F# program elements, such as types, namespaces, and modules.
For each F# code file, you can have a signature file, which is a file that has the same name as the code file but with the extension .fsi instead of .fs.
I've recently been trying to learn the Object-Oriented aspects of F#, and have become curious about how to restrict access to types/modules in the language.
More specifically, I want to know the difference between writing this:
Example.fsi
module Stack =
val foo : string
Example.fs
module Stack =
let foo = "foo"
let bar = "bar"
and alternatively this:
module Stack =
let foo = "foo"
let private bar = "bar"
Do they not accomplish exactly the same thing in the end? Coming from a C# background, I'm much inclined just to use the access modifiers over signature (FSI) files. They seem to be more versatile (can apply to modules/types in namespaces, for example), whereas I don't any situation in which signature files offer something that access modifiers don't.
They accomplish almost the same thing. (Note that you can use an .fsi file for types in namespaces too, was unsure what your comment about that meant.)
A signature file has a couple advantages:
You can make entities public for the duration of the file, but then private to the subsequent files of the project.
You can have just your short summary in the signature file, so the public interface is easy to read without having to scan tons of code.
The first bullet is not to be trifled with - within-assembly encapsulation like this is actually a pretty huge feature for very large projects. Being able to define a few types which are public to one another within File1.fs, but then only have a subset of those types/methods be public to the rest (File2.fs, File3.fs, etc.) is quite useful (a little bit like 'friend' in C++).