[MonoDevelop] GSoC 2010, F# language binding

[Michael Hutchinson]

On Mon, Apr 5, 2010 at 9:18 AM, lost <lostfreeman at gmail.com> wrote:
> Thank you, Piotr!
>
>> On Fri, Apr 2, 2010 at 06:10, lost <lostfreeman at gmail.com> wrote:
>>> This year I've decided to take part in Google Summer of Code. I've
>>> checked Mono's StudentProjects page and found a note about F# binding.
>>> There was a suggestion to write to mailing list, mhutch or lluis specifically.
>>
>> First of all you should know that Vasili Glachin has spent a lot of
>> time and effort working on an F# binding recently.
>> You can find his code here: http://github.com/vasili/FSharpBinding/
>> I'm pretty sure Vasili won't mind somebody helping out, but since a
>> GSoC project should be a well defined and measurable unit of work,
>> maybe you could work on a specific feature like code completion or the
>> refactoring engine? Or both of them depending on how much work is
>> involved. Micheal is probably the best person to talk about that.
>> One project that would be extremely cool, in opinion of course, is
>> getting Stetic to produce F# code for the UI. That would be first ever
>> since even VS will not have a graphical designer for F#.
>
> I've checked github, and found only 1 commit with project system
> support only (did not tested it). I will probably use these code, but
> currently it is almost ground level. So focusing on UI is impossible
> as almost nothing works. I think I need to work on syntax highlighting
> and completion support first.

The GTK GUI designer works for any language that has CodeDOM support
and a couple of refactoring operations: insert member and rename.
These may be viable for SoC.

You should look at some of the past emails on this list where I
replied to Vasili explaining the various parts of a language binding,
and form a plan and objectives from some subset of these, and other
possible useful features such as an fsi REPL pad. At the very least
I'd expect a parser and resolver, which are a prerequisite for code
completion, refactoring, navigation etc. That said, if/when fsc is
open-sourced then its parser and resolver could be used...

>>> Before writting an application I should be aware of the following:
>>>
>>> Do you need your own compiler or using existing fsc from Microsoft is ok?
>>> Can I use CodeDom library, provided with Microsoft F#?

There is no F/OSS compiler for F# yet, but IIRC Don Syme mentioned
that that MS would be open-sourcing fsc in the future. For now, it can
be downloaded a s zip file from MS and used on Linux and Mac, though I
don't think it can be redistributed, so end users would have to
install it manually. That's fine for now.

>>> These two questions are about licensing. I've also asked in F# forum (
>>> http://cs.hubfs.net/forums/thread/13591.aspx ), but still have no
>>> answer.
>>
>> I'm pretty sure using fsc should be OK, especially if Microsoft keep
>> their promise of releasing it under Ms-PL. We should know that soon
>> after they release VS2010.
>
> It seems CodeDom from PowerPack is capable of compilation for ASP.NET only.

That might be sufficient for the ASP.NET designer generation, the MD
templates, and the GUI designer. CodeDOM is usually only ever used for
code generation - the CodeDom parser interfaces are very rarely
implemented.

>>> Can I write binding in F# itself, specifically, is it ok to have
>>> reference to FSharp.Core and FSharp.PowerPack libraries from Microsoft
>>> build?
>>
>> The less external dependencies the better. I would recommend getting
>> as far as possible without using any external code.
>> Of course if you decide to work on the source code completion or
>> refactoring engine, using CodeDom probably be acceptable, especially
>> if it is created as an optional feature of the binding.
>>
>
> I've found that PowerPack is published under MS-PL. So it is ok to be used?

Yes, it's fine to write it in F# and to depend on the Core and
PowerPack libraries. This will of course make it harder to build, but
given that *using* it requires fsc, I don't think a build-time
dependency is a big problem. The other downside is that it will be
harder for the core MD team (and other people who don't yet use F#) to
help maintain it, but the corresponding upside is that F# users will
find it easier to contribute.

> P.S. It would be nice to hear a word from any mentors.

What do you want to hear? :)

-- 
Michael Hutchinson
http://mjhutchinson.com