Hi Manuel,
don't know if I'm allowed to post to this mailing list. So would
appreciate if you could forward the following experience report.
Facundo and I worked on the -XStaticPointers extension. It has gone
through various improvements/generalizations for each new GHC release.
Eg originally, (static e) evaluated to something of type StaticPtr a,
whereas now it has type IsStatic s => s a, to allow for overloading
(static e) literals similarly to string literals. A corresponding
change was made to base. In the future there might be other changes,
in particular to finally make pointer lookup type safe (it's not,
currently), or to generalize IsStatic to a multi-param type class
(based on real-world experience). Should we have -XStaticPointers1,
-XStaticPointers2, etc for each new variant of this extension any time
we make any improvement to it (which have all been backwards
compatible so far)? That would be pretty onerous.
Now, -XStaticPointers was added as an "experimental" extension, and so
in a strong sense we still have license to make all manner of changes
to that extension. But aren't they all? Isn't the very reason for
adding things as extensions first (rather than as part of the base
language) so that we can introduce new ideas and experiment with them
in the wild? And if the extension passes the test of widespread
usefulness then we etch in one of the Haskell Report stone tablets?
Writing modern Haskell already entails a fair amount of bureaucracy
(among which language extension bureaucracy). Many different
variations of the same basic extension may well add to that
bureaucracy a fair bit. And what's more, be intimidating to beginners.
Best,
--
Mathieu Boespflug
Founder at
http://tweag.io.
On 17 October 2017 at 12:30, Manuel M T Chakravarty
<
chak@justtesting.org> wrote:
I completely agree with Simon: this is an important question.
I think, it would be good to have at least (1), but better (2).
Why? Because Haskell’ really doesn’t get anywhere and in its absence the
guarantees provided by GHC are the only language stability there is. Maybe
it is unfair to put this burden on the compiler, instead of on a separate
language specification, but that is how it is.
Now, I reckon the main obstacle to (1) and (2) is that LANGUAGE extensions,
when they appear first, are in flux, because they are often parts of
experiments. Hence, I’d like to suggest that we might be able to lessen the
tension between experimentation and stability by formally associating a
”stability” of one of ”alpha”, ”beta”, or ”stable” with each extension.
As we all know, these stability annotations don’t work at all on Hackage as
nobody ever moves their packages away from ”experimental”. Hence, I suggest
that we do not make this the choice of the person who proposes an extension,
but part of our process. There are a few options, which might be worth
considering.
For example, when a LANGUAGE extension is first proposed, it starts at
”alpha”. When latter a proposal is submitted to amend the extension, that
amendment is approved by us only if it successfully argues that it improves
the maturity of the extension such that it warrants ”beta” stability. And
then, the same with ”stable” on the second amendment. Finally, ”stable”
language extensions cannot be changed unless it is to fix a grave semantic
error or similar.
Instead (or in addition) of bumping stability on every new proposal
involving the extension, we could also adopt a time (or release) based
scheme.
Cheers,
Manuel
PS: BTW, we are pushing for getting to 6 monthly release of GHC. This means
that without any guarantees across versions, we would potentially increase
variability, which would be bad.
Simon Marlow <marlowsd@gmail.com>:
The main reason I took a position on the issue of extension flags is to
force the question: what should LANGUAGE mean? I think it's important to
resolve this, to inform future decisions. Here are some options:
1. LANGUAGE fully specifies the grammar of the source file
2. LANGUAGE fully specifies the grammar and semantics of the source file
3. LANGUAGE tells the compiler what extensions are required, but otherwise
provides no guarantees. The source file might not compile with a given
version of GHC even if it supports all the extensions listed. In other
words, LANGUAGE together with a GHC version range specifies the grammar and
semantics of the source file.
I think what we have right now is 3, because we change the meaning of
extensions from version to version of GHC. There are advantages to 1 and 2:
for example, if we had 1, then we could parse all of Hackage with
haskell-src-exts (or at least identify the subset of source files that can
be parsed via their LANGUAGE pragmas). If we had 2, then we could parse,
rename and typecheck all of Hackage using haskell-src-exts, haskel-names,
and haskell-type-exts.
Perhaps we want to say that we can only *add* syntax to an existing
extension, not change or remove it. This is a variant of 3 that requires
only a lower bound on the GHC version required, not an upper bound, and it
provides some of the benefits of 1 and 2: you just need a sufficiently
recent version of haskell-src-exts et. al.
Anyway, I mainly wanted to ensure that we're clear about what LANGUAGE
means. If we believe the implications of 1 and 2 are too onerous (never
changing extensions), so what we want is 3, so be it.
Cheers
Simon
On 10 October 2017 at 03:54, Iavor Diatchki <iavor.diatchki@gmail.com>
wrote:
Hello,
my preference would be to add this to one of the existing extensions
(either "explicit namespaces", or "type level operators").
Iavor
On Sat, Oct 7, 2017 at 11:26 AM Joachim Breitner
<mail@joachim-breitner.de> wrote:
Hi Committee,
the discussion has ebbed down again. I observe that a clear majority is
in favor. I don’t think there is a need for a formal vote, so I will
proceed with this decision.
Simon M brought up the next issue: Shall we require a separate language
extension for this, or can it go under the hood of
`ExplicitNamespaces`?
So far Simon M expressed a strong preference for the former, while I am
inclined to prefer the latter, and would like to hear a few more
opinions on this detail (which certainly would set precedence for
future decisions).
Richard brought up the idea of versioned language extensions; that idea
can certainly be investigated, but better independently. We have to
deal with this proposal with the tools we have.
Greetings,
Joachim
Am Mittwoch, den 20.09.2017, 12:23 -0400 schrieb Joachim Breitner:
Hi,
the type fixity proposal
(https://github.com/ghc-proposals/ghc-proposals/pull/65)
was met with mixed reactions.
* I recommended rejection and Manuel strongly agrees with me.
* SPJ does not have strong opinions either way.
* Richard is in favor, and Iavor agrees.
Our process says “If consensus is elusive, then we vote, with the
Simons retaining veto power.” It looks like this might be such a case.
Should we go ahead and vote, or is more discussion likely to sway some
of us?
(I guess I can be swayed towards acceptance, especially if this
proposal re-uses existing syntactic idioms from export lists with
ExplicitNamespaces on.)
Greetings,
Joachim
Am Sonntag, den 27.08.2017, 20:16 +0200 schrieb Joachim Breitner:
Dear Committee,
Ryan Scott’s proposal to allow fixity declaration to explicitly
target
values or types has been brought before us:
https://github.com/RyanGlScott/ghc-proposals/blob/type-infix/0000-type-infix.rst
https://github.com/ghc-proposals/ghc-proposals/pull/65
I (the secretary) nominates myself as the shepherd, so I can right
away
continue giving a recommendation.
I propose to reject this proposal. The main reasons are:
* it is not clear if there is a real use case for this. Has anyone
ever complained about the status quo?
The proposal does not motivate the need for a change well enough.
(There is a related bug in TH, but that bug can probably simply be
fixed.)
* The status quo can be sold as a feature, rather than a
short-coming.
Namely that an operator has a fixed fixity, no matter what
namespace
it lives in.
This matches morally what other languages do: In Gallina, fixity
is assigned to names independent of their definition, AFAIK.
* There is a non-trivial implementation and education overhead, a
weight that is not pulled by the gains.
If we’d design Haskell from scratch, my verdict might possibly be
different (but maybe we wouldn’t even allow types and values to share
names then…)
Please contradict me or indicate consensus by staying silent.
Greetings,
Joachim
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
--
Joachim Breitner
mail@joachim-breitner.de
http://www.joachim-breitner.de/
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
--
Joachim Breitner
mail@joachim-breitner.de
http://www.joachim-breitner.de/
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee