New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add F# code generator to the compiler #607

Closed
realvictorprm opened this Issue Sep 22, 2017 · 4 comments

Comments

Projects
None yet
3 participants
@realvictorprm
Member

realvictorprm commented Sep 22, 2017

I propose we add to the compiler services the feature to generate F# code from an existing TAST.

Such a feature is used for either Code-Injection or simple code generation for cases where additional dependencies are preferred to be minimum. Moreover it also suits for cases where Type-Providers would just be like taking a sledgehammer to crack a nut.

An article about what I'm talking is here.

Pros

Of course a simple generator could be placed into a community driven repository fully unattached to the compiler. However, I think as it would be part of the compiler it would most likely have a better quality and better stability. Moreover it would integrate very fine with the existing constructs and prevent introducing similar ones which already exist in the compiler (which might be not usable from outside of the compiler). As Roslyn supports a similar feature I would consider it to be fundamental. Finally, I think that implementing this would converge with the two running PR's to the repository.
The signature file generation and the service formatting. Both should use a merged base for generating F# code from an AST / TAST just as this proposal (and I already signalled in the service formatting PR that I want a merged base for both PR's).

In short:

  • As compiler component likely to be more stable and better
  • Prevent's multiple constructs of the same structure (TAST)
  • Keeping up with Roslyn features.
  • Solution for cases where Type-Providers would be like taking a sledgehammer to crack a nut.
  • Converges with two other existing PR's to Visual F# / F# compiler (merged base constructs).

Cons

The disadvantages of making this adjustment is just that it's more code in the compiler and work to do.

Extra information

Estimated cost (XS, S, M, L, XL, XXL): S/M

Related suggestions: Don't know one. Ping me if I'm wrong.

Affidavit (please submit!)

Please tick this by placing a cross in the box:

  • This is not a question (e.g. like one you might ask on stackoverflow) and I have searched stackoverflow for discussions of this issue
  • I have searched both open and closed suggestions on this site and believe this is not a duplicate
  • This is not something which has obviously "already been decided" in previous versions of F#. If you're questioning a fundamental design decision that has obviously already been taken (e.g. "Make F# untyped") then please don't submit it.

Please tick all that apply:

  • This is not a breaking change to the F# language design
  • I or my company would be willing to help implement and/or test this
@realvictorprm

This comment has been minimized.

Show comment
Hide comment
@realvictorprm

realvictorprm Sep 22, 2017

Member

Side note, I already started a small generator which works for small simple stuff but came to conclusion it's better to integrate it into the compiler. See this repository.

Member

realvictorprm commented Sep 22, 2017

Side note, I already started a small generator which works for small simple stuff but came to conclusion it's better to integrate it into the compiler. See this repository.

@cmeeren

This comment has been minimized.

Show comment
Hide comment
@cmeeren

cmeeren Oct 14, 2017

This sounds great, and it seems like it would make it much easier to implement things like Microsoft/visualfsharp#3748. I hope the relevant people can sign off on it so you can move forward with this!

cmeeren commented Oct 14, 2017

This sounds great, and it seems like it would make it much easier to implement things like Microsoft/visualfsharp#3748. I hope the relevant people can sign off on it so you can move forward with this!

@dsyme

This comment has been minimized.

Show comment
Hide comment
@dsyme

dsyme Nov 16, 2017

Collaborator

@realvictorprm I definitely approve of adding this to FCS (though I don't plan to do it myself - it's just approved-in-principle for that).

It's not a language issue though, so I will close it in this repo.

Collaborator

dsyme commented Nov 16, 2017

@realvictorprm I definitely approve of adding this to FCS (though I don't plan to do it myself - it's just approved-in-principle for that).

It's not a language issue though, so I will close it in this repo.

@dsyme dsyme closed this Nov 16, 2017

@realvictorprm

This comment has been minimized.

Show comment
Hide comment
@realvictorprm

realvictorprm Nov 16, 2017

Member

Many thanks @dsyme!
I'll try to do it as soon as possible, personally preferred after interpolated strings are added to F# :-)

Member

realvictorprm commented Nov 16, 2017

Many thanks @dsyme!
I'll try to do it as soon as possible, personally preferred after interpolated strings are added to F# :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment