Hello,
In case you interested to target your F#/OCaml code to JVM, you can study followed projects:
Ja.NET - JDK for .NET
OCaml-Java - your OCaml programs will be compiled to JVM bytecode
Have you looked at Scala [1]? I think this is currently the most advance functional programming language for the JVM.
F# has been designed to be a functional programming language for the CLI, so I can't help thinking that a port will not be completely straight forward. Not least of the is problems is that F# is currently written in F#, so even if you were just change the back end to output java byte codes then you still need a version of the CLI to be installed to be able to run the "F# for JVM" compiler.
Cheers,
Rob
Wuuldn't it be a standard compiler bootstrapping technique to then compile the F# compiler using the F# to JVM compiler. Presto, a "native" F# to JVM compiler, running on the JVM.There may be interesting info on [link:flyingfrogblog.blogspot.com] especially on the comments to the entry of 25th of december 2008, where some issues with the JVM are discussed for porting F#/Ocaml like languages.Kurt
It's a good point, but doesn't bootstrapping involve quite a bit more work than simply changing the byte code generation? To bootstrap you also have to ensure your not using any libraries in the CLR that aren't also available in JVM. I have no idea how difficult this would be, but it doesn't sound easy to me.
Rob
Also I guess the points I'm trying to make in around about sort of way is that there might be easier starting points, like how about adding more F# like features to scalar? or bootstrapping from ocaml like F# did originally?
Robert,Yes, this is un undertaking that shouldn't be taken lightly, and I'd agree that you'd need some very specific goals to warrant the effort. I don't really see much point either, as you say, scala is an option for functional/OO programming, if it's platform independence you're after there's mono, I don't see a compelling reason in the Java library space (on the contrary...), seems like the JVM is not really up to it, and so on.On the other hand, you could do it for fun, not for profit. In that case, go for it :) and my comment was more targeted to that sort of scenario.Kurt
Thanks for your responses so far. I try to reply to all at once...
Robert: "Have you looked at Scala"
Yes, I did. And so did others. There are several aspects of Scala I don't like. Starting with syntax issues (e.g. no toplevel functions), to type checking and other things (cf. [link:groups.google.com]
Robert: "To bootstrap you also have to ensure your not using any libraries in the CLR that aren't also available in JVM."
True. I would expect a partial rewrite of the runtime support to use classes available on the JVM. There are nice functional collections classes based on "Purely
functional data structures"
([link:www.cs.cmu.edu] and used in Clojure
(cf.
[link:code.google.com] which can be used for the implementation on lists, sets maps and so on. Initially though the compiler can be hosted on .NET producing JVM bytecode which is executed on the JVM, so only client code must be aware of not using .NET classes, but Java classes. Long term goal would be to change the internal compiler dependencies on .NET to use Java classes instead. I am not sure how much of .NET is used by the compiler alone, hence this forum post.
Kurt: "I don't really see much point either, as you say, scala is an option for functional/OO programming, if it's platform independence you're after there's mono, I don't see a compelling reason in the Java library space (on the contrary...), seems like the JVM is not really up to it, and so on."
Well this would be no commercial endeavour so I don't need a business case or anything like this. Second I don't think Scala is the answer to the need of statically typed functional languages on the JVM. Mono is not an option because of its relatively weak implementation. F# doesn't even run properly on mono (cf. [link:bugzilla.novell.com] Also TCO is weak in mono too (cf. [link:flyingfrogblog.blogspot.com] Finally the JVM and .NET share more similarities than differences. They have the same object model and there are many good libraries available for it. And its ubiquitous with top performance and nice tool support. So if the JVm is not an attractive target to host languages, nothing is. If Microsoft would open source the CLR, then things might change but this is less likely than the JVM getting proper TCO support. Also an F# running on the JVM wouldn't be the first functional language there. Clojure is very well done (but dynamically typed) and in fact there is a CLR port of Clojure underway. Don't underestimate the value of languages streching multiple platforms.
Regardless, I didn't want to defend my motives but rather I was hoping for some guidance in how to approach this porting effort.
Finally the JVM and .NET share more similarities than differences. They have the same object model
Ah, but they do not. And that is a problem, because quite a bit of F#-the-language (and not the particular compiler & implementation) is centered around the .NET object model.
At best, you could design a new language that would be to JVM what F# is to .NET. Probably with mostly the same ML-like language core, but the object model would have to be reworked, and I'd expect that implementation techniques would have to be different in many cases (given that JVM doesn't have value types, for example).
I agree, having something similar to F# will be fantastic! I asked about F# on the JVM on these forums long before the productization announcement, but received an enthusiastic response. It makes sense since Don works for MS.
I have also looked at Scala. Despite my attempts to like it (I bought the book!), it just doesn't sit well. It is too verbose, seems to have unnecessary complexity, etc.
Again, it is probably not a good idea to try "port" F# to the JVM. Rather, like clojure, there should be an *ML for the JVM. Pragmatically designed and implemented with a view towards programmers in the industry rather than academic researchers. Obviously this ML-JVM should have computational expressions, first class events, etc. :)
Again, it is probably not a good idea to try "port" F# to the JVM. Rather, like clojure, there should be an *ML for the JVM. Pragmatically designed and implemented with a view towards programmers in the industry rather than academic researchers. Obviously this ML-JVM should have computational expressions, first class events, etc. :)
Yes, probably. In the meantime I have settled on Clojure which is just fantastic. W.r.t static typing I would like to see something like dialyzer which is a static analysis tool for Erlang. Otherwise I am fine with the dynamic typing and do not actually miss an ML anymore.
Mono is not an option because of its relatively weak implementation. F#
doesn't even run properly on mono (cf.
[link:bugzilla.novell.com] Also TCO is weak
in mono too (cf.
No offense, but saying that F# doesn't run properly on Mono is a bit
harsh. The bug in your report does not happen if you compile it with
fsc instead of running it with fsi. So far that has been my experience with
F# and Mono. Compiled programs run fine, but fsi is buggy on Mono. It
seems that fsi's use of reflection does not always go well on Mono.
Mono has a similar runtime interpreter for C# so it is able to do those
things.
Mono is not an option because of its relatively weak implementation. F#
doesn't even run properly on mono (cf.
[link:bugzilla.novell.com] Also TCO is weak
in mono too (cf.
No offense, but saying that F# doesn't run properly on Mono is a bit
harsh...
On the contrary, I think it is a gross understatement. I have tried to get F# running on Mono on several occasions, firstly because it would be very useful to me and secondly because our customers have complained about F# not working correctly only when they are using it under Mono.
FSI has never worked and FSC rarely works correctly. I've seen correct F# programs leak heap space until all available memory is exhausted within seconds. I've seen correct F# programs leak stack space so they die with a stack overflow within a millisecond. Most programs cannot be run because the required libraries are not available under Mono, e.g. they never even aspired to provide .NET 3 compatibility. Some bugs in F# were showstoppers only on Mono, e.g. you cannot even derive from WinForms text box in F# on Mono. And so on.
Moreover, I even demonstrated the problems to the Mono developers only to receive a series of incorrect descriptions and lame excuses in response. IMHO, the situation with the current Mono developers is so dire that, when I was asked if it would be worth Novell throwing another million dollars at Mono development, I said "no". When you've got a code base that rotten your only viable option is to rewrite it. If you want it rewritten well, you need a new development team. If you want a decent new development team then you need to replace management as well, preferably with people who won't just employ their friends called lupus and zoltan.
Suffice to say, I do not have much faith in the future of the Mono project...
Another option might be to create a F# grammar first (possibly with ANTLR) and doing naive bytecode generation (with the help of ASM). Finally maybe the typechecker can be integrated then. I.e. only type checking would be reused.
Topic tags
- f# × 3705
- websharper × 1897
- compiler × 286
- functional × 201
- ui next × 139
- c# × 121
- classes × 97
- web × 97
- .net × 84
- book × 84
- async × 76
- ui.next × 67
- bug × 54
- core × 49
- website × 49
- server × 45
- parallel × 43
- ui × 43
- enhancement × 41
- parsing × 41
- testing × 41
- trywebsharper × 41
- typescript × 37
- html × 35
- javascript × 35
- owin × 35
- asynchronous × 30
- monad × 28
- ocaml × 28
- tutorial × 27
- warp × 27
- haskell × 26
- sitelet × 25
- linq × 22
- workflows × 22
- wpf × 20
- fpish × 19
- introduction × 19
- silverlight × 19
- sitelets × 19
- monodevelop × 17
- rpc × 17
- suave × 17
- piglets × 16
- collections × 15
- feature request × 15
- jquery × 15
- templates × 15
- getting started × 14
- pipeline × 14
- kendoui × 13
- reactive × 12
- 4.1.0.171 × 11
- monads × 11
- opinion × 10
- 4.0.190.100-rc × 9
- deployment × 9
- fixed × 9
- formlets × 9
- in × 9
- json × 9
- plugin × 9
- proposal × 9
- scheme × 9
- solid × 9
- basics × 8
- concurrent × 8
- highcharts × 8
- how-to × 8
- python × 8
- 4.1.1.175 × 7
- complexity × 7
- documentation × 7
- visual studio × 7
- 4.1.2.178 × 6
- lisp × 6
- real-world × 6
- released in 4.0.192.103-rc × 6
- remoting × 6
- resources × 6
- scala × 6
- websharper ui.next × 6
- workshop × 6
- xaml × 6
- 4.0.193.110 × 5
- 4.2.3.236 × 5
- aspnetmvc × 5
- authentication × 5
- azure × 5
- bootstrap × 5
- conference × 5
- dsl × 5
- formlet × 5
- java × 5
- list × 5
- metaprogramming × 5
- ml × 5
- released in Zafir.4.0.188.91-beta10 × 5
- sql × 5
- visualstudio × 5
- websharper.forms × 5
- zafir × 5
- 4.0.192.106 × 4
- 4.0.195.127 × 4
- 4.1.0.38 × 4
- 4.2.1.86 × 4
- 4.2.6.118 × 4
- css × 4
- example × 4
- extensions × 4
- fsi × 4
- fsx × 4
- html5 × 4
- jqueryui × 4
- lift × 4
- reflection × 4
- remote × 4
- rest × 4
- spa × 4
- teaching × 4
- template × 4
- websocket × 4
- wontfix × 4
- 4.0.196.147 × 3
- 4.1.0.34 × 3
- 4.1.6.207 × 3
- 4.2.1.223-beta × 3
- 4.2.11.258 × 3
- 4.2.4.114 × 3
- 4.2.4.247 × 3
- 4.2.5.115 × 3
- 4.2.6.253 × 3
- 4.2.9.256 × 3
- ajax × 3
- alt.net × 3
- aml × 3
- asp.net mvc × 3
- canvas × 3
- cloudsharper × 3
- compilation × 3
- database × 3
- erlang × 3
- events × 3
- extension × 3
- file upload × 3
- forums × 3
- inline × 3
- issue × 3
- kendo × 3
- macro × 3
- mono × 3
- msbuild × 3
- mvc × 3
- pattern × 3
- piglet × 3
- released in Zafir.4.0.187.90-beta10 × 3
- svg × 3
- type provider × 3
- view × 3
- 4.1.1.64 × 2
- 4.1.5.203 × 2
- 4.1.7.232 × 2
- 4.2.10.257 × 2
- 4.2.3.111 × 2
- 4.2.5.249 × 2
- android × 2
- asp.net × 2
- beginner × 2
- blog × 2
- chart × 2
- client × 2
- client server app × 2
- clojure × 2
- computation expressions × 2
- constructor × 2
- corporate × 2
- courses × 2
- cufp × 2
- d3 × 2
- debugging × 2
- direct × 2
- discriminated union × 2
- docs × 2
- elm × 2
- endpoint × 2
- endpoints × 2
- enterprise × 2
- entity framework × 2
- event × 2
- f# interactive × 2
- fable × 2
- flowlet × 2
- formdata × 2
- forms × 2
- fsc × 2
- google maps × 2
- hosting × 2
- http × 2
- https × 2
- iis 8.0 × 2
- install × 2
- interactive × 2
- interface × 2
- iphone × 2
- iteratee × 2
- jobs × 2
- jquery mobile × 2
- keynote × 2
- lens × 2
- lenses × 2
- linux × 2
- listmodel × 2
- mac × 2
- numeric × 2
- oauth × 2
- obfuscation × 2
- offline × 2
- oop × 2
- osx × 2
- packaging × 2
- pattern matching × 2
- performance × 2
- pipelines × 2
- q&a × 2
- quotation × 2
- reference × 2
- released in Zafir.4.0.185.88-beta10 × 2
- rx × 2
- script × 2
- security × 2
- self host × 2
- seq × 2
- sockets × 2
- stm × 2
- tcp × 2
- trie × 2
- tutorials × 2
- type × 2
- url × 2
- var × 2
- websharper.charting × 2
- websharper4 × 2
- websockets × 2
- wig × 2
- xna × 2
- zh × 2
- .net interop × 1
- 2012 × 1
- 4.0.194.126 × 1
- 4.1.3.184 × 1
- 4.1.4.189 × 1
- 4.2.0.214-beta × 1
- 4.2.12.259 × 1
- 4.2.2.231-beta × 1
- 4.2.8.255 × 1
- Canvas Sample Example × 1
- DynamicStyle Animated Style × 1
- Fixed in 4.0.190.100-rc × 1
- Released in Zafir.UI.Next.4.0.169.79-beta10 × 1
- SvgDynamicAttribute × 1
- WebComponent × 1
- abstract class × 1
- accumulator × 1
- active pattern × 1
- actor × 1
- addin × 1
- agents × 1
- aggregation × 1
- agile × 1
- alter session × 1
- animation × 1
- anonymous object × 1
- apache × 1
- api × 1
- appcelerator × 1
- architecture × 1
- array × 1
- arrays × 1
- asp.net 4.5 × 1
- asp.net core × 1
- asp.net integration × 1
- asp.net mvc 4 × 1
- asp.net web api × 1
- aspnet × 1
- ast × 1
- attributes × 1
- authorization × 1
- b-tree × 1
- back button × 1
- badimageformatexception × 1
- bash script × 1
- batching × 1
- binding-vars × 1
- bistro × 1
- body × 1
- bundle × 1
- camtasia studio × 1
- cas protocol × 1
- charts × 1
- clarity × 1
- class × 1
- cli × 1
- clipboard × 1
- clojurescript × 1
- closures × 1
- cloud × 1
- cms × 1
- coding diacritics × 1
- color highlighting × 1
- color zones × 1
- combinator × 1
- combinators × 1
- compile × 1
- compile code on server × 1
- config × 1
- confirm × 1
- content × 1
- context × 1
- context.usersession × 1
- continuation-passing style × 1
- coords × 1
- cordova × 1
- cors × 1
- coursera × 1
- cross-domain × 1
- csla × 1
- current_schema × 1
- custom content × 1
- data × 1
- data grid × 1
- datetime × 1
- debug × 1
- declarative × 1
- delete × 1
- devexpress × 1
- dhtmlx × 1
- dictionary × 1
- directattribute × 1
- disqus × 1
- distance × 1
- do binding × 1
- doc elt ui.next upgrade × 1
- docker × 1
- dojo × 1
- dol × 1
- dom × 1
- domain × 1
- du × 1
- duf-101 × 1
- dynamic × 1
- eastern language × 1
- eclipse × 1
- edsl × 1
- em algorithm × 1
- emacs × 1
- emotion × 1
- enums × 1
- error × 1
- etw × 1
- euclidean × 1
- eventhandlerlist × 1
- examples × 1
- ext js × 1
- extension methods × 1
- extra × 1
- facet pattern × 1
- failed to translate × 1
- fake × 1
- fantomas × 1
- fear × 1
- float × 1
- form × 1
- form-data × 1
- forum × 1
- fp × 1
- frank × 1
- fsdoc × 1
- fsharp × 1
- fsharp.core × 1
- fsharp.powerpack × 1
- fsharpx × 1
- fsunit × 1
- function × 1
- functional style × 1
- game × 1
- games × 1
- gc × 1
- generic × 1
- geometry × 1
- getlastwin32error × 1
- getting-started × 1
- google × 1
- google.maps × 1
- grid × 1
- group × 1
- guide × 1
- hash × 1
- headers × 1
- hello world example × 1
- heroku × 1
- highchart × 1
- history × 1
- how to × 1
- html-templating × 1
- http405 × 1
- httpcontext × 1
- hubfs × 1
- i18n × 1
- ie 8 × 1
- if-doc × 1
- iis × 1
- image × 1
- images × 1
- inheritance × 1
- initialize × 1
- input × 1
- install "visual studio" × 1
- installer × 1
- int64 × 1
- interfaces × 1
- internet explorer × 1
- interop × 1
- interpreter × 1
- io × 1
- iobservable × 1
- ios × 1
- iot × 1
- ipad × 1
- isomorphic × 1
- javascript optimization × 1
- javascript semanticui resources × 1
- jquery-plugin × 1
- jquery-ui × 1
- jquery-ui-datepicker × 1
- js × 1
- kendo datasource × 1
- kendochart × 1
- kendoui compiler × 1
- knockout × 1
- l10n × 1
- learning × 1
- library × 1
- libs × 1
- license × 1
- licensing × 1
- lineserieszonescfg × 1
- local setting × 1
- localization × 1
- logging × 1
- loop × 1
- macros × 1
- mailboxprocessor × 1
- mapping × 1
- maps × 1
- markerclusterer × 1
- markup × 1
- marshal × 1
- math × 1
- mathjax × 1
- message × 1
- message passing × 1
- message-passing × 1
- meta × 1
- metro style × 1
- micro orm × 1
- minimum-requirements × 1
- mix × 1
- mobile installation × 1
- mod_mono × 1
- modal × 1
- module × 1
- mouseevent × 1
- mouseposition × 1
- multidimensional × 1
- multiline × 1
- multithreading × 1
- mysql × 1
- mysqlclient × 1
- nancy × 1
- native × 1
- nested × 1
- nested loops × 1
- node × 1
- nunit × 1
- object relation mapper × 1
- object-oriented × 1
- om × 1
- onboarding × 1
- onclick × 1
- optimization × 1
- option × 1
- orm × 1
- os x × 1
- output-path × 1
- override × 1
- paper × 1
- parameter × 1
- persistence × 1
- persistent data structure × 1
- phonegap × 1
- pola × 1
- post × 1
- powerpack × 1
- prefix tree × 1
- principle of least authority × 1
- privacy × 1
- private × 1
- profile × 1
- programming × 1
- project × 1
- project euler × 1
- projekt_feladat × 1
- protected × 1
- provider × 1
- proxy × 1
- ptvs × 1
- public × 1
- pure f# × 1
- purescript × 1
- qna × 1
- quant × 1
- query sitelet × 1
- question × 1
- quotations × 1
- range × 1
- raphael × 1
- razor × 1
- rc × 1
- reactjs × 1
- real-time × 1
- ref × 1
- region × 1
- released in 4.0.190.100-rc × 1
- reporting × 1
- responsive design × 1
- rest api × 1
- rest sitelet × 1
- restful × 1
- round table × 1
- router × 1
- routing × 1
- rpc reverseproxy × 1
- runtime × 1
- sales × 1
- sample × 1
- sampleapp × 1
- scriptcs × 1
- scripting × 1
- search × 1
- self hosted × 1
- semanticui × 1
- sequence × 1
- serialisation × 1
- service × 1
- session-state × 1
- sharepoint × 1
- signals × 1
- sitelet website × 1
- sitelet.protect × 1
- sitlets × 1
- slickgrid × 1
- source code × 1
- sqlentityconnection × 1
- ssl × 1
- standards × 1
- static content × 1
- stickynotes × 1
- streamreader × 1
- stress × 1
- strong name × 1
- structures × 1
- submitbutton × 1
- subscribe × 1
- svg example html5 websharper.ui.next × 1
- sweetalert × 1
- system.datetime × 1
- system.reflection.targetinvocationexception × 1
- table storage × 1
- targets × 1
- tdd × 1
- templates ui.next × 1
- templating × 1
- text parsing × 1
- three.js × 1
- time travel × 1
- tls × 1
- tooltip × 1
- tracing × 1
- tsunamiide × 1
- turkish × 1
- twitter-bootstrap × 1
- type erasure × 1
- type inference × 1
- type providers × 1
- type-providers × 1
- typeprovider × 1
- ui next forms × 1
- ui-next × 1
- ui.next jqueryui × 1
- ui.next charting × 1
- ui.next formlets × 1
- ui.next forms × 1
- ui.next suave visualstudio × 1
- ui.next templating × 1
- unicode × 1
- unittest client × 1
- upload × 1
- usersession × 1
- validation × 1
- vb × 1
- vb.net × 1
- vector × 1
- view.map × 1
- visal studio × 1
- visual f# × 1
- visual studio 11 × 1
- visual studio 2012 × 1
- visual studio shell × 1
- vs2017 compiler zafir × 1
- vsix × 1
- web api × 1
- web-scraping × 1
- webapi × 1
- webcomponents × 1
- webforms × 1
- webgl × 1
- webrtc × 1
- webshaper × 1
- websharper async × 1
- websharper codemirror × 1
- websharper f# google × 1
- websharper forms × 1
- websharper reactive × 1
- websharper rpc × 1
- websharper sitelets routing × 1
- websharper warp × 1
- websharper-interface-generator × 1
- websharper.chartsjs × 1
- websharper.com × 1
- websharper.exe × 1
- websharper.owin × 1
- websharper.ui.next × 1
- websharper.ui.next jquery × 1
- websockets iis × 1
- why-websharper × 1
- windows 7 × 1
- windows 8 × 1
- windows-phone × 1
- winrt × 1
- www.grabbitmedia.com × 1
- xamarin × 1
- xml × 1
- yeoman × 1
- yield × 1
- zafir beta × 1
- zafir websharper4 × 1
- zarovizsga × 1
|
Copyright (c) 2011-2012 IntelliFactory. All rights reserved. Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy |
Built with WebSharper |
I think it would be cool to be able to program in F# on the JVM. Currently there is no decent statically typed functional language for the JVM (but a very nice dynamically typed one: [link:clojure.org).] While many will point out that this is due the JVMs weak support for functional languages (e.g. no tail call optimization), this is likely to change in the foreseeable future (cf. [link:openjdk.java.net]<wbr>).
Now I would like to get some advice how a port should be approached. Prima facie it is "only" the byte code emission that would need to be changed, right? Is there some overview documentation about the current implementation? I would welcome any hints or tips on how to do this.
Many thanks,
Levi