-
Notifications
You must be signed in to change notification settings - Fork 232
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider dropping requirement that F* code has to be valid F# #1737
Comments
This is fairly easy to fix, most of the package issues regarding FSharp.Core etc. can be solved by using a tool like paket to handle dependencies. I'd be happy to contribute this myself, I wasn't aware that this was such a bothersome issue.
The build system is somewhat arcane either way - I don't have a good enough understanding of it to be able to contribute something alone, but F# has sophisticated tooling for build automation (eg. FAKE(https://fake.build/), ProjectScaffold(http://fsprojects.github.io/ProjectScaffold/), which might be worth migrating to, considering the current complexity of the build process.
It probably wouldn't be too much effort to create a tool that could warn about this, and have it run as part of the build process. I'm skeptical of how much of a bother this part really is though - it's common for larger projects to have a strict code style, and it's not much trouble to get used to working in this subset, even without a specification of the subset.
It's unfortunate to have to take language design decisions to retain compatibility with F#'s syntax - especially regarding things like namespaces, which F* generally handles a lot better IMO. For example, F# can't handle Regarding F# compatibility, we depend heavily on being able to extract F# code and using the parser & prettyprinting components directly from F#. That said, having the sources written in the intersection of F#/F* isn't so important to us as long as we end up with dlls and a cross-platform executable. It is important that we are able to modify and test things quickly though, which includes changes to syntax, so even a bootstrapped approach might not be suitable. |
In developing #1742, I encountered many nasty corners — the subset of F# that I was supposed to be writing is not documented at all! I had to edit Incidentally, many of @aseemr's woes from the Slack discussion will be over when the long tail of #1742 is finished — working with zero editor support can lead to many wasted cycles during development; that's the motivation to develop
|
The relevant lines from fsharp-build-and-test:
+$(MAKE) fstar-in-fsharp
+$(MAKE) fsharp-unit-tests
# The first tests have to be performed sequentially (but each one may use some parallelism)
# Adding the F# build and F# tests also here
# since in the uregressions target it may not be a good idea to override the fstar.exe binary?
utest-prelude: fsharp-build-and-test
+$(MAKE) boot-ocaml #build the ocaml-snapshot
+$(MAKE) clean_extracted #ensures that there is no leftover from previous extraction
+$(MAKE) fstar-ocaml #extract the compiler again and build the result
+$(MAKE) ocaml-unit-tests #run the unit tests
+$(MAKE) fstarlib |
Ping. I implemented support for typechecking F* source files in emacs (using makefiles) and have been exclusively using it for past 3 months. It provides symbol lookup etc. and is good enough for me. With incremental bootstrapping support, I also don't rely on F# builds for quick testing anymore. Happy to revive this discussion (and see if we want to decide either ways for v1). |
I remember there was a conclusion reached during one of the F* meetings. Can an update be posted here? |
Transcribing a slack discussion here: @aseemr wrote:
@nikswamy wrote: I think there are people who use F* today without any dependence on OCaml, e.g., just by building the sources in F#. If we still want to support that, then we need a way to produce an fsharp-snapshot of the compiler @aseemr: @protz @nikswamy @catalin-hritcu @nikswamy Separately, I recall us discussing that we should post prominently here, on the mailing list, on zulip and slack, indicating that we are considering leaving behind the ability to build the F* sources in F# and to see if there are any users out there who are relying on this feature in some way that we have not anticipated. For starters, @A-Manning, what do you think about this? |
I wouldn't want to lose the ability to compile the F* sources as F#. It's really helpful for projects that use F* from F* - for example, I often use
There are quite a few of us using the F# build on Linux/OSX, and a binary would not be well-suited to those that have F* as a dependency. |
Done as part of #2512. |
We recently had a Slack discussion on the pros and cons of dropping the current requirement that the code of F* has to be valid F#. Fortunately, I saved this right before it went dodo.
@nikswamy @aseemr @protz @tahina-pro @mtzguido: Let's continue any discussions on this by commenting on this issue!
The text was updated successfully, but these errors were encountered: