What was the story with the boot library again? Can we eliminate the special casing of it in dune if we introduce per_file flags?
Likely, boot is a bit like ocaml stdlib
there are two cases:
Init.Prelude.vo
has to be addedSecond case is harder to handle
What's the problem with the boot library?
It's a bit tougher to handle some sanity checks when the boot library is composed. One must make sure there's only a single boot library in every single compilation closure.
Yes, it is the same tho that having two conflict public libs
with the same name
Alright, it wasn't a huge problem after all to make it work with composition
Boot is quite useful as it allow us to compose with Coq itself
and we have plans to run the CI incrementally, where the full CI is composed, tho we need to solve vendoring better, but we can do a lot
What do you think about compiling everything in coq with -noinit and making people depend on the boot library explicitly? I wish we had that in OCaml at least
do you mean people would have to opt in to use the prelude? If we want wide adoption of Dune for building Coq projects, that's in my view a no-go (the support issues would be huge)
I think a lot of people want the option to get Coq with -noinit
via Dune, though (e.g., UniMath, HoTT)
Why would the support issues be huge?
because regular users would not be able to figure out what they need to do to add the prelude, they have no idea what the prelude even is
A regular user is someone that will use dune but will have no idea that coq consists of libraries?
the regular Coq user may be able to distinguish between Coq's stdlib and something like MathComp, but not more fine-grained than that
there is a still minority of users that actually need -noinit
, like UniMath users, but since they are the minority by far, better to get prelude by default in Dune
How does a regular user not know to add the prelude but know to add the Stdlib or mathcomp?
a regular user has a vague idea what stdlib is, and will be annoyed and get stuck when they can't use it (due to prelude not being loaded)
they may know they have to add some extra magic Require Import
command to get some MathComp. But even that will not work without the prelude.
I don’t see it. The regular user is informed enough to use dune and external libraries, but just barely not informed enough to ask for the Stdlib explicitly. Sounds like too fine of a distinction.
If they know how to pull mathcomp, and mathcomp pulls the prelude, they don’t need to pull it explicitly
they (may) know the Coq-level incantation for libraries like MathComp, since people put this in tutorials
but even getting people to the point of a multi-file Coq project can be a struggle
I can say that I would personally never recommend using Dune to a beginner if -no-init
is the default.
but sure, "production grade" Coq projects won't have a problem, and may even appreciate barebones approach. But this is far from the support burden in community forums.
I think that using dune and coq will require reading an introduction to both dune and its coq stanzas. You would think that this is already enough that such a small addition isn’t going to matter much.
Indeed @Rudi Grinberg there are a couple of open (and accepted) issues to make the stdlib a regular library
so yes that's a good idea, but there is quite a few things to do first
maybe in 2.0 version we can enforce that
but the first todo is to require users to qualify the imports
so Require Lists
becomes From Coq Require Lists
etc...
and that's tricky due to some horrible horrible (legacy) code in Coq that manages that
Sometimes I look at Coq's source code and I wonder how it can work at all XD
I've seen few projects like it
Actually a big blocker to do this is indeed our lack of Coq packages
So making people write (theories stdlib) today isn’t going to work?
It would work if we had proper packages
What is improper about the packages today?
in my view, for Dune 1.0, it's a really bad idea with (theories stdlib)
Rudi Grinberg said:
What is improper about the packages today?
once installed, they are all stashed together in user-contrib
and you have no way to identify the package a file comes from
unless of course you drop compat with coq_makefile
Oh this thing again
yes
...
it is a big constraint
but maybe we can get rid of it sooner than we think
Can’t we just install in both locations and live with the wasted disk space for now?
please don't drop user-contrib
installation for 1.0
but IMHO it is good that we support for a big the use case where a user can build a Coq theory with Dune and still depend on a non-dunerized theory
Yes, I’m not proposing to drop support
Rudi Grinberg said:
Can’t we just install in both locations and live with the wasted disk space for now?
yes we can do that, but I'm not sure we gain a lot unless we drop "dune theories can depend on non-dune theories"
installation in two places is fine by me
but YMMV
I’m saying that dune will use the dune-package stuff while a fallback exists for makefiles
I think we agree we want to do what you propose, the question is how to bootstrap the whole business
So maybe using two fields is a good compromise
but more work for us than having the current semantics in 1.0, and moving to the new semantics in 2.0
I suppose. But it’s not straightforward, as the boot hacks were quite a time sink for both of us I think. And the work we’re talking about is useful long term
Remind me why we need two fields though
You mean theories and legacy_theories?
As far as I understand, there’s work on a new stdlib right? Seems like another reason to stop special casing
the "new stdlib" project is considered stalled. The largest potential for -noinit
is in my view: UniMath, HoTT, and perhaps in the longer run, MathComp-based projects
Yes, I was trying to locate the issue, but yes, we don't want special casing
but actually yes we don't need a new field
it should be coq lang version that controls it
so at some point, for example, in (using coq 1.1)
@Karl Palmskog if you don’t want your students to know about libraries, why do you want them to use dune anyway? IMO that’s basically dune’s main advantage
users have to explicitly require the stdlib
still we need two changes upstream which are tricky, and I thought they had issues, but they have not:
From Coq
for stdlibFrom Coq Require Prelude
explicit too@Rudi Grinberg we want people to use Dune in all high-profile projects to get benefits of composition and automation in opam packaging, etc. Regular users will get benefits from this as better automation trickles down. They can then follow simple recipes for using Dune in their own projects based on a bigger library. While remaining mostly ignorant of how Coq and libraries are organized.
Actually already in 2015, when I release jsCoq, users where forced to write From Coq
and import the prelude explicitly.
But I got so much backslash due to lack of compat that I had to backtrack
wrong choice
(myself backtracking)
The way I see the theories field look up working:
Does that sound reasonable?
What's the input on theories?
The name of theories as defined in the dune files for 1.
For 2. Some sort of a reverse engineering scheme from the file structure I suppose
I mean what's the syntax of (theories ...)
the syntax for a theory name
To start working today in porting project, the idea was that 2 was enough
but at some point we want to do 1 obviously
https://github.com/coq/coq/issues/16091
Warnings seem necessary anyway for at least one release (and probably more), before possibly breaking every single Coq development in existence… but we’d still be allowed to Export the Coq prelude, right? So part of this could be absorbed by downstream preludes
Yes, the breakage may not be so bad
We need to stop Require
without From
IMHO
that only leaves every single Require
going into the stdlib
that will break a lot of code, but I don't see any other way
we could keep the status quo tho, I dunno
Can you write a convincing argument for the entirety of the Coq userbase?
Paolo Giarrusso said:
Can you write a convincing argument for the entirety of the Coq userbase?
I don't know
why I need that?
Require
without From
should mean: "import from current package"
There are already a few alternatives libraries that don't use stdlib, seems obvious for it to lose special status
and in fact, it is much clear to read From Coq Require Lists
than Require Lists
where you got no idea where it comes from
I don’t know the exact general practice, but I’m not sure everybody would be happy with that attitude. An alternative might be that breaking code is rude, so you need to convince people there’s a good reason
to be sure, those [Emilio's] are arguments in favor of recommending From X ...
, but they don't really reach the level of "we must mandate it right now".
of course, in the usual kind of “you have to”: there’s nothing you have to do, but if you want to have users (and happy users), there are things you probably want to do.
Yes breaking code is not good
but this time there is a good justification for it in many fronts
Many people may not be happy with that attitude, however, I'm unsure what can I tell to them
I can have meaningful discussion with build system experts, I've been myself working Coq builds since 2015 and I've learned a lot
but discussion with non experts is just not very productive
they'll have to trust the experts I'm afraid
I see this often with math-comp, people love to bash math-comp
then when I try to get meaningful discussion, it turns out they never even used it
?!?!?!?
who said anything about discussion?
That part of human nature will never ever cease to amaze me
I’m afraid your users are human beings and you don’t get to change them :-)
Well your question was "can you write a convincing argument for the entirety of Coq userbase"
let me answer differently
no I can't
it is impossible
I can only provide a convincing argument for people that are knowleable, for the rest, I have no idea
I don't get or want to change them
yes
I get to make Coq work better and more maintanable tho
and implement a faster more modular and easier build setup
If Makarious had listened to what (non-expert) Isabelle users were saying
they would still be using proof general
in sequential mode
that's a problem with "open" development
eveyone is entitled to an opinion
I think this is ultimately the domain of @Théo Zimmermann — I think major breaking changes usually get more explanations, but I haven’t investigated exactly to which extent
regardless of what their actual expertise is
here the motivation is very easy: special and hardcoded cases bring lots of problems
and in Coq's case they bring zero benefit and whole lot of special options and flags
and considerable custom code
we already have a mechanism for handling basic namespaces, let's use ti
dunno, peer review works reasonably well even if the reviewers are by definition less experts than the authors — the authors just have to make their case compelling
in any case, I am aware I am not an expert, and I most certainly don’t get a vote :-)
you may think that peer review works well, but for many that's not the case, see for example https://twitter.com/neuralreckoning/status/1529767585990029312 which I fully share. Moreover peer review requires the reviewer to be assigned an expertise level, which doesn't happen here
The current system of journals and peer review is not serving science. I have therefore resigned from all editorial roles and will no longer do pre-publication peer review. I explain why in this article and in the thread below. Please consider joining me. http://neural-reckoning.org/reviewing.html
- Dan Goodman (@neuralreckoning)I consider you an expert @Paolo Giarrusso and of course I heard all you say, and if we vote you have a vote
your question was about "the entirety of Coq's user base"
that's very different
if your question is can you provide a good argument for Paolo and the dev team, for sure I can
I am shocked by how many times I have been for example "proof explained"
by people, that sorry for them, don't know very well what they are talking about
or told how to program in OCaml by people that don't actually know how to program in OCaml
etc,etc...
as said: dunno how much convincing will be needed for users, but I expect there will be some text in the changelog (and probably before that), and the better it is, the fewer protests you will see, and the more quickly users will migrate to the new version
more importantly, some migration help would be great — either a warning, or an option to enable/disable the special cases if that’s easier
Yes that's a very good point
Emilio Jesús Gallego Arias said:
the syntax for a theory name
The same one as today (theories foo ..)
. Perhaps I didn't underdstand the question?
Then why you need 1 at all
?
The advantage would be that if we resolve something with 1, we don't need to allow the user to peek into the junk yard that is user-contrib
. Where they can accidentally use all kinds of stuff they didn't explicit depend on
@Rudi Grinberg unfortunately Coq already puts in scope everything in user-contrib :/
So for the "1.0" version of Coq + dune we have no way to forbid stuff in user-contrib, but we should be able to do so once we bump
supporting user-contrib
for 1.0 is to me essential for Coq people to get hooked on using Dune. If we can reach OCaml level prevalence of Dune, then a lot of options open up for ecosystem improvements.
Yes @Karl Palmskog , it is clear we need to support that
Rudi and I are planning to support user-contrib first, we don't have any plans to revolutionize Coq package installation structure AFAIK
@Emilio Jesús Gallego Arias I realized Coq already has a process for such discussions — CEPs. Would it be appropriate here?
not sure in Coq, but that's how we'd use Scala Enhancement Proposals in Scala.
Yes, for the 2.0 library model we need something like a CEP
no question
We didn't start such document because it makes sense first to try to port the full CI to Dune and see what we discover
Last updated: Oct 13 2024 at 01:02 UTC