I suggest we ...

Implement Syntactic Macros

At least give it a try in a private branch, and upon success, enable them publicly with a compiler switch initially.

453 votes
Sign in
Sign in with: facebook google
Signed in as (Sign out)
You have left! (?) (thinking…)
Bryan Edds shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Sign in with: facebook google
Signed in as (Sign out)
  • Yemi Bedu commented  ·   ·  Flag as inappropriate


    So I would recommend that the above be extended to work with general methods (functions)

    The definition of it could look like:
    def nameof (q:'T) = match q with
    | Quotations.Patterns.ValueWithName(o, ty, n) -> n
    | Quotations.Patterns.Let(v, e1,e2) -> v.Name | expr -> expr.ToString()

    which is shorthand for writing:
    let nameof ([<ReflectedDefinition>] q:Quotations.Expr<'T>) : string = match q with
    | Quotations.Patterns.ValueWithName(o, ty, n) -> n
    | Quotations.Patterns.Let(v, e1,e2) -> v.Name | expr -> expr.ToString()

    let y = 1

    printfn "%s" (nameof y)

    Thank you. Good day.

  • Anonymous commented  ·   ·  Flag as inappropriate

    Having a proper macro system would probably make type providers obsolete, the current mechanism (putting it politely) is a crap fest.

  • Yaar Hever commented  ·   ·  Flag as inappropriate

    I think macros would make it much easier to implement the missing functionalities of type providers (like creating F# specific types) and to have a functional way of writing type providers.

  • Suminda Sirinath Salpitikorala Dharmasena commented  ·   ·  Flag as inappropriate

    There are 3 ways to do this
    1) Quasi Quotes (QQ)
    2) Macros
    3) GADT

    Why not have all 3. F# is very well capable of doing this. If you use QQ you are dealing with concrete syntax. In other ways you can deal with it at the AST level also.

  • mavnn commented  ·   ·  Flag as inappropriate

    @Bryan sorry for the slow response. Type providers that could take a type would allow you to generate things like lenses on the fly. Having said that...

    ... I actually very much like the idea of syntactic macros and have voted for this idea. So I'm not going to spend too long disagreeing with you!

    It does have to said that a lot of very similar functionality could be provided by better support for evaluating quotations and that may be the more practical solution in the short term.

  • Bryan Edds commented  ·   ·  Flag as inappropriate

    Hi mavnn!

    It would be interesting to see some explanation of what the semantics of better / expanded type providers and quotations would entail, along with a couple of examples demonstrating how they would obviate macros.

    Would you or Dave mind writing something like that up as an F# user voice suggestion so we can study upon and vote for it?

  • mavnn commented  ·   ·  Flag as inappropriate

    @Bryan I don't know if this is what Dave was thinking, but a lot of type kind like functionality could be implemented by type providers that could be parameterized by type or by quotation.

    Combined with better quotation evaluation out of the box, it would cover most of the use cases I've seen so far, especially Mauricio's lens et al.

  • Bryan Edds commented  ·   ·  Flag as inappropriate

    Dave and all,

    Here's a super nice macro use case; Making FSCL more syntactically elegant. FSCL is amazing, but the amount of attributes and <@code quotation symbols@> flying around in its usage code makes it much harder to read and write than it should be, as well as error prone -

    "Ah, why doesn't this work?! Did I leave out an attribute or parameter again?"

    Imagine all that encapsulated behind a DSL that looks like first-class F# syntax - all just by opening the appropriate module.

    Could expanded code quotations and / or type providers really obviate macros in cases like this?

  • Bryan Edds commented  ·   ·  Flag as inappropriate

    Hi Dave!

    Could you elaborate on what you mean by 'expanded' in these cases, and perhaps give examples where they would obviate macros?

  • Dave Thomas commented  ·   ·  Flag as inappropriate

    I think I would prefer expanded quotation and Type Provider support. The language is at a very stable base and Im not sure you could convince me that macros are necessary.

  • Bryan Edds commented  ·   ·  Flag as inappropriate

    I'm starting to wonder if there is a bit of confusion between textual macros (like those found in C and C++) and my suggestion of syntactic macros.

    For surefire clarification, here are links describing each -

    Textual Macros - http://en.wikipedia.org/wiki/Macro_%28computer_science%29#Text_substitution_macros

    Syntactic Macros - http://en.wikipedia.org/wiki/Macro_%28computer_science%29#Syntactic_macros

    The difference between the two is very big, and I too would object to any suggestion of putting textual macros in F#! :)

  • Mauricio Scheffer commented  ·   ·  Flag as inappropriate

    Will, a lot of use cases have been mentioned in this thread that are not about syntactic sugar: lenses, serialization, derivation of functor/applicative/monad. Also derive curried constructors for records, which would help a lot with applicative functors.

    All of these are about reducing boilerplate by generating code at compile-time.

← Previous 1

F# Language

Feedback and Knowledge Base