Allow single backticks

[vasily-kirichenko]

Allow single backticks everywhere double backtickes are used

Double backticks introduce too much visual noise, which prevent people to use more self-explaining names.

Pros and Cons

The advantage of making this adjustment to F# is more readable code.

Double backticks:

[<Test>]
let ``should not create XML Doc for module-level let bounds which already have non-empty XML Docs``() =
    Set.contains (XmlDocable(79, 0, ["x"])) output.Value |> assertEqual false
    Set.contains (XmlDocable(82, 0, ["x"])) output.Value |> assertEqual false

[<Test>]
let ``should not create XML Doc for types which already have non-empty XML Docs``() =
    Set.contains (XmlDocable(89, 0, [])) output.Value |> assertEqual false

type Format =
    | ``ARC/ZIP`` = 0
    | ``ARC/CAB`` = 1
    | ``PE/EXE`` = 2
    | ``PE/DLL`` = 3

let fmt = Format.``ARC/ZIP``

let _ =
    match fmt with
    | Format.``ARC/ZIP`` -> ()
    | Format.``ARC/CAB`` -> ()
    | Format.``PE/EXE``  -> ()
    | Format.``PE/DLL``  -> ()

Single backticks:

[<Test>]
let `should not create XML Doc for module-level let bounds which already have non-empty XML Docs`() =
    Set.contains (XmlDocable(79, 0, ["x"])) output.Value |> assertEqual false
    Set.contains (XmlDocable(82, 0, ["x"])) output.Value |> assertEqual false

[<Test>]
let `should not create XML Doc for types which already have non-empty XML Docs`() =
    Set.contains (XmlDocable(89, 0, [])) output.Value |> assertEqual false

type Format =
    | `ARC/ZIP` = 0
    | `ARC/CAB` = 1
    | `PE/EXE` = 2
    | `PE/DLL` = 3

let fmt = Format.`ARC/ZIP`

let _ =
    match fmt with
    | Format.`ARC/ZIP` -> ()
    | Format.`ARC/CAB` -> ()
    | Format.`PE/EXE`  -> ()
    | Format.`PE/DLL`  -> ()

The disadvantage of making this adjustment to F# is that we will have two syntaxes for defining long symbol names. However, it's not that unusual. We have two syntaxes for defining generic types, for example (type ('k, 'v) Map = ... and type Map<'k, 'v> = ...) for "OCaml backward compatibility".

Extra information

Already implemented in https://github.com/Microsoft/visualfsharp/pull/1692

Affidavit (must be submitted)

Please tick this by placing a cross in the box:

• [x] This is not a question (e.g. like one you might ask on stackoverflow) and I have searched stackoverflow for discussions of this issue
• [x] I have searched both open and closed suggestions on this site and believe this is not a duplicate
• [x] 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:

• [x] This is not a breaking change to the F# language design
• [x] I would be willing to help implement and/or test this
• [x] I or my company would be willing to help crowdfund F# Software Foundation members to work on this

[7sharp9]

I think single ticks are clearer, Ive always thought of double ticks as extra noise.

[theprash]

This would be a breaking change for any names containing a single backtick.

[theprash]

Actually, I suppose it wouldn't be!

[dsyme]

My initial feedback:

• The use of double-back-tick is by design. The double-back-tick has advantages that it is more distinctive, and thus aids overall comprehension for people who have never seen the feature. Removing a couple of ticks for a corner-case feature is not a significant gain in brevity.
• Single-backticks have established meaning in some other contexts like shell scripting (eval) and Standard ML (a string-based quotation/anti-quotation mechanism). This means that some users may mistakenly assume that meaning for F# code, and have to unlearn that meaning in the context of learning F# and interpreting F# code. Double backticks don't have an established meaning.
• The introduction of "two-ways-to-do-the-same-thing" is a consideration.
• In general we don't revisit established design decisions unless there has been a significant change of circumstance affecting the decision. There are costs in moving from the status quo.

[smoothdeveloper]

Single backticks are used in haskell for using prefix function as an infix operator:

https://wiki.haskell.org/Infix_operator#Using_infix_functions_with_prefix_notation

That could be a place where we would like to use single backtick notation (although it would be awkward for those double-back-tick symbols).

[vasily-kirichenko]

@smoothdeveloper

1. I strongly doubt we will reach the point in F# evolution when infix function application syntax would be approved.
2. Scala uses single backticks to achieve exactly the same result as F#’s double backticks.
3. Yes, double backticks are completely unique thing. Let's think for a minute why.

[dsyme]

Single backticks are used in haskell for using prefix function as an infix operator:

Yes, this is another point of cognitive dissonance for people coming to F#. Uniqueness and distinctiveness has advantages, the use of double backticks was chosen to achieve that result.

I strongly doubt we will reach the point in F# evolution when infix function application syntax would be approved.

I know why you're saying this and it's a fair point.

However even if we never approved this for F#-on-.NET-as-it-exists-today, I can still see the potential for future deployments of variants of F# in situations where single-backticks would be used for something.

For example, if F# were ever used as the scripting language for an LCF theorem prover (e.g. HOL-lite), then it would be very natural for single-backticks to be used to delimit terms and types in the syntax of the object-language. Or that might force the use of single-backticks for infix operators like THEN in HOL-lite.

Similar considerations apply for potential future variants of F# that interoperate closely with a different host environment (e.g. on Javascript), or ones that need to interoperate closely with a language supporting infix identifiers. The single-backtick syntax is a unique syntactic card we can play at some point in the future of F# variations. Playing it just to save a couple of characters doesn't seem worth it.

There's a long history in programming languages where we regret using up syntactic wiggle-room too cheaply (e.g. I regret the way we used up :: and @ and ! and ref so easily, but am glad of the work we did to make sure x.[y] is reusable for different types)