What exactly is the difference between F#'s type augmentation and type extension, and do we really need both?
Are there situations where one is better than the other, and vice-versa?
I'm asking because I recently had a lecture in F# where the lecturer talked about both, and afterwards commented that he couldn't see the reason why both were included in the F# language.
Update:
Ok, so Vladislav Zorov links to a page with examples of using type augmentation both when defining your own types, and extending (or augmenting?) an external type.
pad links to an MSDN page where they call it intrinsic and optional type extension.
Both seem to illustrate the same thing. Can someone come with a concrete example of type extension and another concrete example of type augmentation perhaps, in order to explicitly clarify what the two things are exactly?
The following bits from MSDN's Type Extensions page are relevant (emphasis mine):
There are two forms of type extensions that have slightly different
syntax and behavior. An intrinsic extension is an extension that
appears in the same namespace or module, in the same source file, and
in the same assembly (DLL or executable file) as the type being
extended. An optional extension is an extension that appears outside
the original module, namespace, or assembly of the type being
extended. Intrinsic extensions appear on the type when the type is
examined by reflection, but optional extensions do not. Optional
extensions must be in modules, and they are only in scope when the
module that contains the extension is open.
The purpose of optional extension is clear. It helps you inject new functionalities to types not belonging to your assemblies. For examples, FSharpx uses it to create various helpers for parsing primitive types:
open System
type Boolean with
static member parse x =
match bool.TryParse(x) with
| true,v -> Some v
| _ -> None
Why do you need intrinsic extension then? The answer is its convenience. I find it useful to break down type definitions to multiple sections with clear purposes.
In many F# libraries, I saw the use of the following pattern: type definition -> utility functions -> intrinsic extension. In this way, you can define sophisticated utility functions on your types, make them available in modules and still can use them directly in your member definitions. You can look at Complex type in F# PowerPack to see the pattern.
EDIT:
To be honest, I often use type extension and type augmentation interchangeably. The thing that matters is whether they are intrinsic or optional.
They are different things. Type augmentations, when defined in the same namespace, module and source file, actually become part of the type when compiled. Type extensions (a.k.a. type augmentations for types outside of the module and source file) are implemented with .NET extension methods.
They both use the same syntax, the only difference is whether the type you mention is in the same namespace and assembly, i.e. you're augmenting your own code and the additional methods can be added to your type before compilation.
Source: http://tomasp.net/blog/fsharp-iii-oop.aspx
Edit:
This is a terminology mix-up, they are both referring to the same thing - intrinsic extensions are type augmentations of the first kind (i.e. same namespace and assembly), optional extensions are type augmentations of the second kind (i.e. 3rd party assembly, in the blog post this is the List<T> augmentation example).
I assume when your lecturer is talking about type augmentations, he's referring to intrinsic extensions, i.e. first kind type augmentations, and when he's talking about type extensions, he's talking about optional extensions, or second kind type augmentations.
Related
Should I give type when creating variable?
Any downside for just declaring the keyword "var"?
Any difference between these two?
var a = 0;
int a = 0;
Pros/Cons
ONGOING WORK
Best Practices
It's recommended to use var or final keyword, without specifying type annotation, and implicitly infer type for known local variables. Otherwise it's recommended to specify type annotations. As for dynamic keyword, it should be used very sparingly in specific use-cases, when you're doing manual type checking. For example print(myVariable is SomeType).
omit_local_variable_types Dart linter rule encourages omitting type annotation for known local variables. always_specify_types encourages specifying type annotations for cases that don't fall into the scope of the former linter rule.
1. Style guide for Flutter repo
1.1 avoid using var
All variables and arguments are typed; avoid "dynamic" or "Object" in
any case where you could figure out the actual type. Always specialize
generic types where possible. Explicitly type all list and map
literals.
This achieves two purposes: it verifies that the type that the
compiler would infer matches the type you expect, and it makes the
code self-documenting in the case where the type is not obvious (e.g.
when calling anything other than a constructor).
Always avoid "var". Use "dynamic" if you are being explicit that the
type is unknown, but prefer "Object" and casting, as using dynamic
disables all static checking.
2. Dart Lint Rules
2.1 omit_local_variable_types
CONSIDER omitting type annotations for local variables.
Usually, the types of local variables can be easily inferred, so it
isn't necessary to annotate them.
2.2 always_specify_types
DO specify type annotations.
Avoid var when specifying that a type is unknown and short-hands that
elide type annotations. Use dynamic if you are being explicit that the
type is unknown. Use Object if you are being explicit that you want an
object that implements == and hashCode.
References
You can refer to Style guide for Flutter repo, full list of Dart's Linter Supported Lint Rules, and Effective Dart's Style Guide.
Note, Style guide for Flutter repo is used among flutter community and takes precedence over LinterRules and Effective Dart's Style Guide especially within repo contributions. From what I've seen, Style guide for Flutter repo is more of a superset Style Guide that should honor Dart Linter rules.
There isn't any difference between the two statements you gave.
And I don't see any downside to only declare the keyword "var", unless that your code might become a bit more difficult to read. On the other side, specifying the type might become a bit redundant sometimes.
But this is really just a question of taste 😄
I advise you to pick between those two, and be consistent in your code.
If you choose to always specify the type, you can use always_specify_types in your file analysis_options.yaml :
https://dart-lang.github.io/linter/lints/always_specify_types.html
See for example Data.Maybe.Base in the stdlib — all Maybe, Any, and All have a just constructor.
Agda allows these definitions. How can one specify which one to use?
Each data type comes with its own module. So Maybe, All and Any are all type constructors and modules simultaneously. Thus you can write Maybe.just, All.just or Any.just to disambiguate the constructor. Or it can be disambiguated by type inference (unification is a more appropriate term) or an explicit type signature like Thilo said in their comment. (It's not true however that you'll get an error if there some ambiguity -- you'll get an unsolved meta).
How can I access the typed abstract syntaxe tree for all source files in a f# project in order as descibed in "analysing a whole project". So, what I need is the specific Microsoft.FSharp.Compiler.Tast of all files in a project.
Accessing the untyped syntax tree is quite simple, as described in walking an untyped ast. So, I expect there to be a corresponding interface to the tast.
The purpose is to transpile code from F# to another typed language, in this case scala, which need type annotations. A whole project should be translated at once.
The first URL you link shows how to get an FSharpAssemblySignature, but doesn't explain much of what to do with such a value. That type, and the immediate types it contains, FSharpEntity & FSharpMemberOrFunctionOrValue, are defined in Symbols.fs. The typed AST itself is defined in tast.fs. I don't know of any docs explaining the various types, except the comments in these two files.
Is there any way to open a namespace of types provided by a type provider implementation? I ask, because some of the generated type name paths are very long and ugly in code. I have used type abbreviations to alleviate this, but obviously this is a manual process. The F# open keyword does not support this. Is there another way? Update: as pointed out in the answer and comments this is wrong. You can open a type provided namespace. I had not realised I was looking at deeply nested types, not a namespace.
This is tricky - parameterized type providers (like the standard SQL providers or the F# Data providers for XML and JSON) need to put all types that they generate (representing tables, XML nodes, etc) inside the main generated type. So all types that you might want to use are hidden somewhere as nested types of the main type (with parameters specified).
This makes sense - if you use the type provider with multiple parameters, the types generated for each configuration have to be separate.
As #kvb points out, you cannot open a nested type, but you can use type aliases to make this a bit less painful. For example, using F# Data, I can define an alias R that lets me access all the generated domain types with just two additional characters:
#r #"..\packages\FSharp.Data.1.1.10\lib\net40\FSharp.Data.dll"
open FSharp.Data
type RssFeed = XmlProvider<"http://rss.nytimes.com/services/xml/rss/nyt/HomePage.xml">
type R = RssFeed.DomainTypes
let printTitle (itm:R.Item) = printfn "%A" itm.Title
I'm having problems using any types created in an assembly for an F# Generative Type Provider. I created a YouTube video that demonstrates this.
The error messages I get are:
The module/namespace 'tutorial' from compilation unit 'Addressbook1' did not contain the namespace, module or type 'Person'
A reference to the type 'tutorial.Person' in assembly 'Addressbook1' was found, but the type could not be found in that assembly
I don't understand because the type is definitely in the assembly. For troubleshooting this, the assembly is a very basic C# dll. The code in the video is available via git:
git url: https://code.google.com/p/froto/
git branch: help
Any troubleshooting ideas would be appreciated. I'm hoping to make more progress on an F# Type Provider for .proto files, but I'm stuck on this.
I've taken a quick look at your code - as I mentioned in a comment I think you would be much better served by using the ProvidedTypes API that is defined by the F# 3.0 Sample Pack and documented (a bit) on MSDN.
Basically, the raw type provider API has a lot of assumptions baked in which will be hard for you to maintain by hand. I think that the specific problem you have is that the compiler expects to see a type named tutorial.Person in your assembly (since it's the return type of a method on tutorial.AddressbookProto, which you are exposing as a generated type), but it isn't ever embedded into your assembly.
However, this is really only one of several problems - as you've probably realized, your will see additional errors if the type that you're defining is called anything other than tutorial.AddressbookProto. That's because you're using a concrete type as the return from ApplyStaticArguments, but you would typically want to use a synthetic System.Type instance that accurately reflects the namespace and type name that the user used (e.g. in the ProvidedTypes API the ProvidedTypeDefinition class inherits from System.Type and handles this bookkeeping).