F # Specification Symbolic operator VS Symbolic keyword

I read in the F # spec - the most recent I could find I found here - for the purpose of learning a language in which is arguably difficult. Section "3.6 Symbolic keywords" in the specification states that:

The following symbolic or partially symbolic character sequences are considered keywords:

token symbolic-keyword =
    let! use! do! yield! return!
    | -> <- . : ( ) [ ] [< >] [| |] { }
    ' # :?> :? :> .. :: := ;; ; =
    _ ? ?? (*) <@ @> <@@ @@>

      

The next section "3.7 Character Operators" states that:

User-defined and library-defined symbolic operators are sequences of symbols as shown below, except when the sequence of symbols is a symbolic keyword (ยง3.6).

regexp first-op-char = !%&*+-./<=>@^|~
regexp op-char = first-op-char | ?
token quote-op-left =
    | <@ <@@
token quote-op-right =
    | @> @@>
token symbolic-op =
    | ?
    | ?<-
    | first-op-char op-char*
    | quote-op-left
    | quote-op-right

      

Perhaps I'm missing something obvious, but it seems to me that in the specification indicated that the operators / keywords ?

, @>

, @@>

, <@

and <@@

are symbolic key words and symbolic operators. So ... who are they? How do I know if the weather is using a symbolic key token or an operator symbolic token?

Thanks in advance, Brandon

EDIT To be clear, I want to know why the spec states that symbolic operators can be these characters right after they said they can't.

+3


source to share


1 answer


A concept that helps answer this question is keyword . Keyword is a reserved word . Also check your Dragon book.

A reserved word is basically a word that cannot be used by a programmer as an identifier, in this case it is a word like if , or an operator such as โ†’ . In other words, if you try to use "let ( if ) =" or "let ( โ†’ ) =", you will get an error message because you are using a reserved word,

For this question, interpret section 3.6 as these are keywords reserved for F # use. In section 3.7 as, you can create your own operators if they follow these rules and do not match one of the reserved keywords in section 3.6.

So, if you want to create an operator โ†’ , you can create operator โ†’

To answer your question "So ... who are they?" They are keywords and they are system defined operators, they cannot be used as custom operators.



EDIT

Let's look at it in a different direction. All lexer rules call parser rules. It is easy to find the use of the symbolic-op rule, that is, op-name, but look for the symbolic keyword and you will find that "eg 34 .. are post-filtered into two tokens: one int and one character keyword, .. โ€– ". Helpful, but it doesn't answer your question and you are now wondering why there is a lexer rule that is not called by a parser rule. I don't know, this is a specification, not a formal definition of grammar. If you look at the F # source , you may find that the spec and grammar are not the same as you would like. In other words, the specification is meant to help you understand the language; I would not use it as the ultimate set of rules for building a compiler.

Putting a specification in terms of or car, the spec tells you what you can expect from the car, how the car should perform, or the limits for a parameter, it doesn't tell you how to build the car.

If I were writing a compiler, I would interpret case 34 .. so as not to create markers for symbolic keywords in the first pass, but use post-processing to filter them into the appropriate tokens. In other words, rewrite the stream token in the second pass. If it were me, I would make sure the spec is a complete grammar before using it to build a compiler. If you want to push, then I would probably skip the search for symbolic keywords on the first pass and use stream rewriting after creating the token stream on the first pass.

If you want to know more about filtering tokens in F #, see section 15 of the Lexical Filtering spec; this gives an explanation of descent, how lightweight syntax is converted to regular syntax by rewriting the token.

+3


source







All Articles