F# 2.0 语言规范详解

需积分: 3 103 浏览量更新于2024-07-31 收藏 3.07MB PDF 举报

"F# 2.0 语言规范" F#是一种高级的、多范式的编程语言，与C#有着共同的基础，它们都在.NET Framework的公共语言运行时（CLR）上运行。F#的设计旨在结合函数式、命令式和面向对象编程范式，特别强调类型推导和并行计算的能力，这使得它在处理复杂和数据密集型任务时表现出色。 F# 2.0 语言规范是一个由微软研究部门和开发者分部于2010年4月发布的文档，但它可能与实际的2.0版本实现存在差异。这些差异在文档中以注释形式指出，并鼓励用户发现更多不一致之处，通过邮件fsbugs@microsoft.com向团队反馈，以便在未来的规范版本中进行修正。F#团队对用户的反馈非常重视，无论是在规范、设计还是实现方面。该规范的最新版本可在www.fsharp.net上找到，众多F#用户社区成员的有益反馈对文档的改进起到了重要作用。规范中的一些部分会引用C# 4.0、Unicode以及IEEE的相关标准。文档的作者Don Syme，以及Anar Alimov、Jomo Fisher、Michael Hale、Luke Hoban、Dmitry Lomov、James Margetson、Brian McNamara、Joe Pamer、Penny Orwick、Daniel Quirk、Chris Smith、Matteo Taveggia和其他人，共同参与了F# 2.0语言规范的撰写。请注意，这个规范的版权属于2005年至2010年的微软公司。 F# 2.0的关键特性包括： 1. **类型推导**：F#的强类型系统能够自动推导变量和函数的类型，减少了程序员需要显式声明的代码量，同时也提高了代码的可读性。 2. **函数式编程**：F#支持高阶函数、匿名函数和模式匹配，使代码更简洁、易于测试和并行化。 3. **命令式编程**：F#允许使用命令式编程风格，可以方便地操作和修改状态，与其他.NET语言无缝集成。 4. **面向对象编程**：F#支持接口和类，能够构建面向对象的软件，兼容.NET的面向对象特性。 5. **并行和并发**：F#的并行库和异步工作流机制使得编写高效并行代码变得简单，充分利用多核处理器的性能。 6. **模块化**：F#通过模块组织代码，便于代码重用和管理。 7. **类型系统**：F#拥有丰富的类型系统，包括记录类型、联合类型和不可变数据结构，有助于防止数据错误。 8. **引用透明性**：F#强调纯函数，这在并行编程中尤为重要，因为纯函数的结果只取决于输入，不依赖外部状态。 9. **LINQ支持**：F#支持查询表达式（Query Expressions），类似于C#的LINQ，用于数据库和XML数据的查询。 10. **交互式编程**：F# Interactive（FSI）允许开发人员在实时环境中测试和调试代码，加速开发过程。 F# 2.0语言规范为开发者提供了全面的指导，帮助他们理解和利用F#的强大功能，无论是开发高性能的科学计算应用，还是构建复杂的业务系统。

Both object expressions and type definitions can implement interface types. For example, here is an object

expression that implements the interface type:

let nullEncoder =

{ new IEncoding with

member x.Encode(s) = s

member x.Decode(s) = s }

Modules are a simple way to encapsulate code during rapid prototyping when you do not want to spend the time

to design a strict object-oriented type hierarchy. In the following example, we place a portion of our original script

in a module.

module ApplicationLogic =

let numbers n = [1 .. n]

let square x = x * x

let squares n = numbers n |> List.map square

printfn "Squares up to 5 = %A" (ApplicationLogic.squares 5)

printfn "Squares up to 10 = %A" (ApplicationLogic.squares 10)

System.Console.ReadKey(true)

Modules are also used in the F# library design to associate extra functionality with types. For example, List.map

is a function in a module.

Other devices aimed at supporting software engineering include signatures, which can be used to give explicit

types to components, and namespaces, which serve as a way of organizing the name hierarchies for larger APIs.

1.2 Notational Conventions in This Specification

This specification describes the F# language through a mixture of informal and semiformal techniques. All

examples in this specification use lightweight syntax, unless otherwise specified.

Regular expressions are given in the usual notation. For example:

regexp+ one-or-more repetition

regexp* zero-or-more repetition

regexp? zero-or-one occurrences

[ char - char ] range of ASCII characters

[ ^ char - char ] exclusion of a character range or set

Unicode character classes are referred to by their abbreviation—for example, \Lu for any uppercase letter.

The following characters are referred to using the indicated notation:

\b backspace ASCII/UTF-8/UTF-16/UTF-32 code 08

\n newline ASCII/UTF-8/UTF-16/UTF-32 code 10

\r return ASCII/UTF-8/UTF-16/UTF-32 code 13

\t tab ASCII/UTF-8/UTF-16/UTF-32 code 09

String of characters that are clearly not a regular expression are written verbatim. Therefore, the regular

expression

abstract

matches precisely the characters abstract.

Where appropriate, apostrophes and quotation marks enclose symbols that are used in the specification of the

grammar itself, such as '<' and '|'. For example, the following regular expression matches (+) or (-):

'(' (+|-) ')'

2 Program Structure

The inputs to the F# compiler or the F# Interactive dynamic compiler consist of:

 Source code files, with extensions .fs, .fsi, .fsx, or .fsscript.

o Files with extension .fs must conform to grammar element implementation-file in §12.1.

o Files with extension .fsi must conform to grammar element signature-file in §12.2.

o Files with extension .fsx or .fsscript must conform to grammar element script-file in

§12.3.

 Script fragments (for F# Interactive). These must conform to grammar element script-fragment.

Script fragments can be separated by ;; tokens.

 Assembly references (via command line arguments or interactive directives).

 Compilation parameters (via command line arguments or interactive directives).

 Compiler directives such as #time.

Inputs processed by the F# compiler have the COMPILED compilation symbol defined. Inputs processed by F#

Interactive have INTERACTIVE defined.

Processing the source code portions of these inputs consists of the following steps:

 Decoding. Each file and source code fragment is decoded into a stream of Unicode characters, as

described in the C# specification, sections 2.3 and 2.4. The command-line options may specify a codepage

for this process.

 Tokenization. The stream of Unicode characters is tokenized into a token stream through the lexical

analysis described in §3.

 Lexical Filtering. The token stream is filtered by a state machine that implements the rules described

in §15. Those rules describe how additional (artificial) tokens are inserted into the token stream and how

some existing tokens are replaced with others.

 Parsing. The augmented token stream is parsed according to the grammar specification in this document.

 Importing. The specified imported assembly references are resolved to F# or CLI assembly specifications,

which are then imported. From the F# perspective, this results in the pre-definition of numerous namespace

declaration groups (§12.1) and types. These namespace declaration groups are then combined to form an

initial name resolution environment (§14.1).

 Checking. The results of parsing are checked one by one. Checking includes invoking such procedures as

Name Resolution (§14.1), Constraint Solving (§14.5) and Generalization (§14.6.8), as well as other specific

rules described in this specification.

 Type inference uses variables that represent unknowns in the type inference problem. The various

checking processes maintain tables of information including an environment and a set of current

inference constraints. After the processing of a file or program fragment is complete, all such

variables have been either generalized or resolved and the type inference context is discarded.

3 Lexical Analysis

Lexical analysis converts an input stream of Unicode characters into a stream of tokens. This conversion is done

by repeatedly processing the input character stream using a longest-match interpretation of a collection of regular

expressions that specify different possible tokens. Some tokens, such as block-comment-start, are discarded

after processing as described later in this section.

3.1 Whitespace

Whitespace is made up of spaces and newline characters.

regexp whitespace = ' '+

regexp newline = '\n' | '\r' '\n'

token whitespace-or-newline = whitespace | newline

Whitespace tokens whitespace-or-newline are discarded from the returned token stream.

3.2 Comments

Block comments are delimited by (* and *) and may be nested. Single-line comments begin with // and extend

to the end of a line.

token block-comment-start = "(*"

token block-comment-end = "*)"

token end-of-line-comment = "//" [^'\n' '\r']*

When a block-comment-start token is matched, the subsequent text is tokenized recursively using the

tokenizations defined in this section until a block-comment-end token is matched. The intermediate tokens are

discarded. For example, comments can be nested, and strings embedded within comments are tokenized by the

rules for string and verbatim-string.

Note: In particular, strings that are embedded in comments are tokenized without looking for closing *)

marks. This makes (* Here's a code snippet: let s = "*)" *) a valid comment.

For the purposes of this specification, comment tokens are discarded from the returned lexical stream. In

practice, XML documentation tokens are end-of-line-comments beginning with /// and are kept and

associated with subsequent declaration elements.

3.3 Conditional Compilation

#if ident/#else/#endif are preprocessing directives that delimit conditional compilation sections. The

following describes the grammar for such sections:

token if-directive = "#if" whitespace ident-text

token else-directive = "#else"

token endif-directive = "#endif"

A preprocessing directive always occupies a separate line of source code and always begins with a # character

and a preprocessing directive name. Whitespace can appear before the # character. A source line that contains

剩余249页未读，继续阅读

夏添

粉丝: 1
资源: 4

F# 2.0 语言规范详解

F#2.0.Code

PROFESSIONAL F# 2.0

The F# 4.0 Language Specification

F# Language Overview

C# Language Specification 2.0

C# Language Specification 2.0.doc

C# Language Specification 2.0.pdf

C# Language Specification 1.2+2.0

The Objective-C 2.0 Programming Language

The Java Language Specification

最新资源