You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Apr 3, 2025. It is now read-only.
Copy file name to clipboardExpand all lines: _posts/2014-09-19-fsharp-libraries.md
+40-4Lines changed: 40 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,6 +9,11 @@ subtitle: Naming, Engineering and General Advice
9
9
10
10
> Naming, Engineering and General Advice
11
11
12
+
## Author
13
+
14
+
Don Syme, with advice from various contributors to F# Core Engineering discussions.
15
+
16
+
Originally drafted September 2014, with subsequent minor updates.
12
17
13
18
## Contents
14
19
{:.no_toc}
@@ -17,17 +22,16 @@ subtitle: Naming, Engineering and General Advice
17
22
18
23
## Introduction
19
24
20
-
One of the goals of F# Core Engineering is to help ensure best engineering practices in public-facing F# components and packages.
25
+
One of the historic goals of the "F# Core Engineering" group is to help ensure best engineering practices in public-facing F# components and packages.
21
26
22
-
In this post we outline some recommended guidelines for naming and engineering for F# projects, packages and namespaces.
23
-
We particularly focus on open projects such as those in the [F# Community Projects](http://fsharp.org/community/projects/) list or
27
+
In this document we capture some recommended guidelines for naming and engineering for F# projects, packages and namespaces. This is based on how things stood in 2014, and we have continued to update these with minor modifications. We particularly focus on open projects such as those in the [F# Community Projects](http://fsharp.org/community/projects/) list or
24
28
[packages in NuGet for an "FSharp" search](http://www.nuget.org/packages?q=fsharp).
25
29
26
30
These are recommendations - they are not hard-and-fast rules, and are offered for discussion amongst
27
31
F# developers. If you would like to discuss these guidelines or suggest modifications,
28
32
please [edit this file on GitHub and submit a pull request](https://github.com/fsharp/fsharp.github.io/edit/master/_posts/2014-09-19-fsharp-libraries.md).
29
33
30
-
There is agreement on the following:
34
+
In discussions, there has been agreement on the following:
31
35
32
36
1. FSharp.* projects should be high-quality or trending **rapidly** in that direction.
33
37
Ideally any packages and code under the FSharp.* namespace should be of sufficient quality to be considered
@@ -126,11 +130,17 @@ Use the following prefixes where possible, rather than inventing new ones:
126
130
127
131
-`FSharp.Control`: Functionality related to control flow, such as asynchronous programming, message passing,
128
132
event-based programming, reactive programming, and similar
133
+
129
134
-`FSharp.Data`: Types related to data access, data schema, and similar
135
+
130
136
-`FSharp.Text`: Text processing, formating, printing, or similar functionality
137
+
131
138
-`FSharp.Azure`: Types related to cloud computing on the Azure plattform.
139
+
132
140
-`FSharp.AWS`: Types related to cloud computing on the AWS plattform.
141
+
133
142
-`FSharp.Compiler`: Functionality relating to compilation of F#
143
+
134
144
-`FSharp.Core`: Use sparingly. Typically required for helper types required by incubation of compiler features
135
145
136
146
For example, a library like "FSharp.Actor" might be better renamed to "FSharp.Control.Actor". Similarly, "FSharp.Reactive"
@@ -169,6 +179,32 @@ or other community forums.
169
179
170
180
<br />
171
181
182
+
## Transpiling Guidelines
183
+
184
+
<br />
185
+
186
+
Some F# libraries are candidates for cross-compilation using F# transpiler tools such as Fable and WebSharper. Other transpilers for other targets may also be developed over time.
187
+
188
+
The following are draft guidelines for adding support for transpilation, based on information available in 2019.
189
+
190
+
* Consider supporting transpilation by one or more alternative toolchains. It is not required or obligatory.
191
+
192
+
* Do ensure that the qualities of the library are not diminished significantly, e.g. API design, documentation and performance.
193
+
194
+
* Do be positive to contributions which add support and testing for other transpilers. However there is no obligation to support any particular transpiler.
195
+
196
+
* Do add CI testing for the transpilation.
197
+
198
+
* Do use feature-specific switches `#if NO_FOO_FEATURE` rather than `#if MYTRANSPILER`.
199
+
200
+
* Do assess the quality of the transpilation tool, and the degree of support for language and library.
201
+
202
+
* Consider using an appropriate different namespace, e.g. `Fox.Collections.Rapid` for transpiled version of the (hypothetical) `FSharp.Collections.Rapid` library.
203
+
204
+
* Consider the maintenance burden of the necessary `#if` when making your decisions, including the long-term maintenance by other contributors.
205
+
206
+
As an example, as of October 2019 the `dotnet/fsharp` repository has decided not to support transpilation for the `FSharp.Compiler.Service` library component. However, some transpilers maintain separate forks of that repository.
0 commit comments