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 support for recording fixity in quoted literals #680

7sharp9 opened this Issue Jun 27, 2018 · 4 comments


None yet
2 participants

7sharp9 commented Jun 27, 2018

Add support for recording fixity in quoted literals

With the current quotation literal support various information is lost in the encoding process, this information can be very useful to library implementors especially when using quotations a meta language.

In an example the following literal:

<@@ 1 + 1 @@>

is encoded as:

Call (None, op_Addition, [Value (1), Value (1)])

And the following

<@@ (+) 1 1 @@>

is encoded to the same expression tree

Call (None, op_Addition, [Value (1), Value (1)])

The loss of fixity information in quoted literals is not ideal if you are using meta programming which may have parity with encoding quoted expressions from a functional point of view e.g custom operator and infix/prefix function usage.

I realise that the purpose of the quotation mechanism is to reuse alternative execution machinery unrelated to F# but in recent years with the advent of type providers quotations are used in a different fashion to the original implementation described in the paper Leveraging .NET Meta-programming Components from F# Integrated Queries and Interoperable Heterogeneous Execution.

I think a series of modifications to quotation will make them become more useful in future meta programming especially if encoding of the F# language in quoted expressions is done in a less lossy way.

Pros and Cons

The advantages of making this adjustment to F# are less information is lost during the quotation literal encoding process and this information can be very useful to library developers in an approach to meta programming. With the current implementation you have no way of knowing in the quoted expression was called in infix or prefix notation.

The disadvantages of making this adjustment to F# are added complexity, more information to encode in the quoted literal, extra meta data to encode in ReflectedDefinition

Estimated cost (S):


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

This comment has been minimized.

eugbaranov commented Jun 27, 2018

I'm just curious, do you have any concrete sample where you could benefit from having such a distinction?


This comment has been minimized.


7sharp9 commented Jun 27, 2018

@eugbaranov I’m using quotations to generate code from a quotation via splicing and external schema. The resulting code would ideally be infix notation like the quoted expression but I have no way of knowing that. I have to make a judgement call and make all such code infix. If the quotation literal was lossless then I could at least check and generatecas desired. After all line numbers are included why not fixity.


This comment has been minimized.


7sharp9 commented Jun 27, 2018

There are also other areas where there is a loss of information, I’m logging these too...


This comment has been minimized.


7sharp9 commented Jun 28, 2018

Another significant area is F# has an affinity for symbol, also symbols can be overridden so it would be nice to encode the information at the call site in the quotation. Certain symbols like (+) op_addition could be assumed to be almost always infix notation but thats not always the case.

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