{"action":"created","issue":{"url":"https://api.github.com/repos/MicrosoftBigData/usql/issues/12","labels_url":"https://api.github.com/repos/MicrosoftBigData/usql/issues/12/labels{/name}","comments_url":"https://api.github.com/repos/MicrosoftBigData/usql/issues/12/comments","events_url":"https://api.github.com/repos/MicrosoftBigData/usql/issues/12/events","html_url":"https://github.com/MicrosoftBigData/usql/issues/12","id":116387595,"number":12,"title":"Add support for F# as a language type","user":{"login":"mwinkle","id":1649907,"avatar_url":"https://avatars.githubusercontent.com/u/1649907?v=3","gravatar_id":"","url":"https://api.github.com/users/mwinkle","html_url":"https://github.com/mwinkle","followers_url":"https://api.github.com/users/mwinkle/followers","following_url":"https://api.github.com/users/mwinkle/following{/other_user}","gists_url":"https://api.github.com/users/mwinkle/gists{/gist_id}","starred_url":"https://api.github.com/users/mwinkle/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mwinkle/subscriptions","organizations_url":"https://api.github.com/users/mwinkle/orgs","repos_url":"https://api.github.com/users/mwinkle/repos","events_url":"https://api.github.com/users/mwinkle/events{/privacy}","received_events_url":"https://api.github.com/users/mwinkle/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/MicrosoftBigData/usql/labels/Discussion","name":"Discussion","color":"207de5"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":6,"created_at":"2015-11-11T17:56:05Z","updated_at":"2015-11-12T02:37:34Z","closed_at":null,"body":"This came in as a feature request from [uservoice](https://feedback.azure.com/forums/327234-azure-data-lake/suggestions/10608288-native-support-for-f-with-usql), opening this issue to track discussion and refine the suggestion.  This is the text from uservoice\r\n\r\n> It would be great to see some F# support for USQL. I understand that you can already do UDFs in any .NET language (provided you inherit from the required base class or interface etc.) but having F# inline with USQL would be excellent. F#'s lightweight syntax and expression-based syntax would be a natural fit with the SQL section of USQL, and I think would provide a more seamless experience switching when between SQL and .NET code than SQL and C#.\r\n\r\n> Pushing this further one could envisage an F# / USQL type provider along the lines of the SQL Client one (http://fsprojects.github.io/FSharp.Data.SqlClient/) which could allow you to consume USQL from within F# directly.\r\n"},"comment":{"url":"https://api.github.com/repos/MicrosoftBigData/usql/issues/comments/155979055","html_url":"https://github.com/MicrosoftBigData/usql/issues/12#issuecomment-155979055","issue_url":"https://api.github.com/repos/MicrosoftBigData/usql/issues/12","id":155979055,"user":{"login":"isaacabraham","id":1781813,"avatar_url":"https://avatars.githubusercontent.com/u/1781813?v=3","gravatar_id":"","url":"https://api.github.com/users/isaacabraham","html_url":"https://github.com/isaacabraham","followers_url":"https://api.github.com/users/isaacabraham/followers","following_url":"https://api.github.com/users/isaacabraham/following{/other_user}","gists_url":"https://api.github.com/users/isaacabraham/gists{/gist_id}","starred_url":"https://api.github.com/users/isaacabraham/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/isaacabraham/subscriptions","organizations_url":"https://api.github.com/users/isaacabraham/orgs","repos_url":"https://api.github.com/users/isaacabraham/repos","events_url":"https://api.github.com/users/isaacabraham/events{/privacy}","received_events_url":"https://api.github.com/users/isaacabraham/received_events","type":"User","site_admin":false},"created_at":"2015-11-12T02:37:34Z","updated_at":"2015-11-12T02:37:34Z","body":"I remember seeing that Hive TP - I think someone even managed to get it working outside of the Silverlight TryFSharp website!\r\n\r\nTPs themselves are inherently \"slow\" - they simply allow you to wrap around calls that you would normally do anyway. In this case, if that TP was generated once per row, that *might* have an overhead (as it would need to parse that file every time) but if it stayed alive across calls to the UDO within the AppDomain, and it was simply being used for safe property accesses, then it shouldn't really be much slower at all than a custom class that you had defined to wrap around IRow that did that anyway.\r\n\r\nAs another example of where a TP can be used within cloud data processing, look at the Azure Storage TP (http://fsprojects.github.io/AzureStorageTypeProvider/) which does all sorts of IO when dotting into containers but at runtime it's not really slower than just raw calls to the .NET SDK (which is what the TP is a wrapper around)."}}