I have a function that looks vaguely like this
let decodeData<'a> (encodedData: string) = Decode.Auto.fromString<'a>(encodedData)
If I do decodeData<String[]>, then while the code compiles, at runtime I get a Javascript error of Cannot read properties of null (reading 'generics')
If I remove the generic, and just have Decode.Auto.fromString<String[]>(encodedData) it works as expected.
The issue is that the JS runtime doesn't have access to type reflection information from F#. The Fable compiler gets around this in some places by using inline and resolving the type reflection at compile time.
Some more discussion on adding reflection information here.
Related
(previously "using type provider from C#")
This should be easy to answer, and the underlying issue has be asked before, but I'm slightly confused about it, having dug into it, there's something I'm missing.
The Xml type provider in
https://fsharp.github.io/FSharp.Data/library/XmlProvider.html
is erased?
so the types in it can't be used from another assembly?
"Erasing Type Providers produce types that can only be consumed in the assembly or project they are generated from" (says the MS docs).
but if I define in one assembly this
module Xml
type Xml = FSharp.Data.XmlProvider<"""
<note>
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
</note>""">
let foo () = Xml.Parse ("")
and in another assembly, reference the above assembly and go...
let x = Xml.foo ()
let s = x.From
this compiles...so if the MS docs are correct, the provider must be generative?
if I implement the same code in C#,
var x = Xml.foo();
var y = x.From;
then this code doesnt compiler
'XmlElement' does not contain a definition for 'From' and no accessible extension method 'From' accepting a first argument of type 'XmlElement'
which seems to imply its erased...or I need to do something else (I've included the same dependencies).
My hunch is its erased, but then how does the F# assembly compile?
(I want it to be generative to use from C# and VB).
As far as I can tell by looking at the source code, all the types provided by FSharp.Data are erased.
The XmlProvider type is defined by this line at https://github.com/fsharp/FSharp.Data/blob/master/src/Xml/XmlProvider.fs#L26
let xmlProvTy = ProvidedTypeDefinition(asm, ns, "XmlProvider", None, hideObjectMethods=true, nonNullable=true)
As you can see, the instantiation of the ProvidedTypeDefinition type does not include isErased=false.
The ProvidedTypeDefinition type has two constructors. See the signatures at https://github.com/fsprojects/FSharp.TypeProviders.SDK/blob/master/src/ProvidedTypes.fsi#L268-L275
Both constructors have an implementation including this line, which means that the provide type is erased by default:
let isErased = defaultArg isErased true
Without redesigning the XmlProvider, the only way you can consume it from C# is to wrap it in an F# class that exposes C#-friendly types. Not sure if that would result in a better design than just avoiding the type provider altogether.
Assuming by "erased" you mean being removed from the FSharp.Data Library? then XMLProvider its probably not removed from it because I just tried your code and it works in F# project (as you have also noticed).
Now about the C# project the thing is TypeProviders are a Fsharp specific thing, whatever magic F# compiler is doing to type check xml and access the From xml-node here is probably only exclusive to F#.
The type of you variable x here is FSharp.Data.Runtime.BaseTypes.XmlElement, looking at the documentation here and the source code here.
There doesn't seem to be any way of accessing the xml nodes in an OOP way. Its probably not meant to be accessed that way either. If you want to parse xml and read its nodes in C# there are plenty of other ways for that. One being XmlReader in System.Xml
I have a union type that has a single, empty case.
type Default =
| Default
This type has a purpose, but it's not meant to be visible or usable.
Unfortunately, I have to use it in an inline function that does need to be visible. This prevents me from making the type or the case private.
The solution I came up with is using the CompilerMessageAttribute on it to signal an error whenever it's used. This would be fine, but now I can't compile my own assembly because IT uses it.
Is there a way to signal an error only when it's used by an assembly that references my assembly?
Let me reiterate the requirements to make sure I understand them:
The type needs to be public, so that that other assemblies can reference it implicitly via inline.
But if other assemblies reference it explicitly, then that is an error.
I don't know of any way of doing this using standard tooling.
I can see two possible solutions.
If only one calling assembly needs to use the inline function, what about making the type internal and then have the calling assembly be a friend assembly, using the InternalsVisibleToAttribute.
The only other alternative I can think of is security by obscurity. Hide the type in some awkwardly named module and require module qualification. This will stop accidental use of the type, if nothing else.
You could even add a build step to check that no source code references the module name.
[<RequireQualifiedAccessAttribute>]
module ``Dont Use This`` =
type Default =
| Default
let x = ``Dont Use This``.Default
And yes, it's very kludgy.
Seth Ladd's Polymer.dart examples are awesome and really helpful. The observable_list example appends DateTime instances to an ObservableList timestamps. Although DateTime does not extend Observable, modifying my_element.html to access a field on
{{ts in timestamps}}
works when running in the Dart VM. For example, changing
<li>{{ts}}</li>
to
<li>{{ts.second}}</li>
will access the DateTime.seconds field when on the Dart VM. However, when dart2js compiles the app to javascript, access to fields in the Polymer expression is broken. An exception Uncaught Error: RangeError: value 0 is thrown in this case, or more generally NoSuchMethodError : method not found: 'Symbol(...)' for the fieldname is thrown (see example here)
If a class extends Observable then access to #observable fields works inside of Polymer expressions after compiling to Javascript (changing the class MyRow in this example to extends Observable does not throw an exception in javascript).
What can I do when I am unable to add annotations to external classes like DateTime? Is this just a current bug in dart2js generation, or will the Polymer.dart spec forbid reading fields out of non-observable classes? Previously, web_ui successfully accessed fields from our dart-protobuf generated classes after compiling to javascript, so I'm hoping this use-case will gain support in Polymer.dart too.
In general, dart2js tries to tree-shake and minify code, and it doesn't know that some of the code is used from a polymer expression (which uses mirrors internally to interpret the expressions). Very likely what happened here is that dart2js is either deleting the non-observable fields or minifying them in a way that they are not reflectable.
To fix this, you can indicate that these fields need to be preserved and used via mirrors. In polymer we provide the #reflectable annotation for this purpose. (#observable also implies #reflectable, that's why it works when you have #observable). So you can use that in the MyRow case.
Fields from types in the core libraries can work also if they become reflectable. In this case it is a bit harder to express because you can't modify the original code to add this annotation. Instead you can use the #MirrorsUsed annotation to override the default behavior on these core types, or avoid using these fields inside polymer-expressions by hiding them inside #reflectable getters or in filters that are written directly in Dart code.
Do F# type providers work by using the DLR under the hood? That is to say, do they work in the way that the dynamic keyword in C# does? How is this related to expando objects?
How does codegen fit in?
Type providers are plugin to the compilation process. Internally a type provider may use DLR or anything but when the compiler ask it for a type it needs to return a type that is statically resolved at compile time. Think of it like rather than a human creating a type (class in C#) you have a assembly (type provider) which the compiler can ask to create a new type at compile time.
Ex: In case of SQL type provider the type representing the tables will be generated at compile time and put in the assembly as static types.
Type providers solve similar problem as the dynamic keyword in C# - both of them were designed to make it easier to access data that have some structure that is not described in your programming langauge and so you need to somehow infer it later.
The dynamic keyword just lets you access any member (i.e. data filed) or method at compile time and then decides how to handle the operation at runtime. If you're using it to access .NET object, then it will use DLR, but if you're accessing some other object (like JSON data) then it will perform some simple dictionary lookup.
F# type providers are quite different - they infer the structure at compile time and pass it to the F# compiler. The compiler will then check all your code. The type provider also decides how the access to a field or method should be compiled. Typically, it will either replace it with an ordinary .NET type (so it will be compiled as normal .NET invocation) or it will replace the object with some dictionary lookup. A type provider may use DLR under the cover, but I don't think it is very common case.
I encountered a strange compiler error in Delphi Prism 2010 that I am unable to resolve. The error is calling a method on an object defined in a third-party assembly that manipulates a specialized image format. The assembly itself was compiled against the .Net 2.0 Runtime.
Despite providing the correct list of parameters, I consistently get an error and series of warning messages indicating the parameter list is incorrect. The VS 2008 IDE also refuses to perform parameter completion, yet correctly shows the method prototype and allows the method to be added using Ctrl-Space. Below is an abbreviated version of the compiler errors to illustrate the problem:
Error 1 (PE19) There is no overloaded method "GetTempMapOfIRSensor" with these parameters
Warning 2 (PH2) Best matching "Image.GetTempMapOfIRSensor(var rectOnSensor: System.Drawing.Rectangle; out average: System.Double; out minTempArrayIndex: System.Int32; out maxTempArrayIndex: System.Int32; desiredTempUnits: Image.TEMP_UNIT): array of System.Double" doesn't match on parameter 1, parameter is "System.Drawing.Rectangle" should be "System.Drawing.Rectangle"
Warning 3 (PH2) Best matching "Image.GetTempMapOfIRSensor(var rectOnSensor: System.Drawing.Rectangle; out average: System.Double; out minTempArrayIndex: System.Int32; out maxTempArrayIndex: System.Int32; desiredTempUnits: Fluke.Thermography.TEMP_UNIT): array of System.Double" doesn't match on parameter 2, parameter is "System.Double" should be "System.Double"
....a list of similar warnings for each remaining parameter
The strange part is that the compiler complains about a type mismatch for each and every parameter, yet the error message shows the parameter type names are the same (e.g. parameter is "System.Double" should be "System.Double").
Any suggestions on how to troubleshoot and resolve this issue would be welcome. The class in question, other than this one method, seems to work fine in every other respect. I am also able to create a method on the local class with the same signature and call it without error.
Update:
Invoking the method using reflection and the same parameter list works properly. This is looking to be a compiler bug/limitation of some sort.
If this library has overloads for non-var/out & var or out parameters with the rest of the signature the same, turn off the option for implicit out/var parameters and add out & var in the places they're needed. That should fix, else a QC entry generally is fixed quite fast, if it's a bug.