It's true that making modifiers type-based may be wrong. I wanted to have some way to e.g. import names, etc., for use in modifiers. But maybe that makes them less useful. Despite this potential flaw, I really think that keeping modifiers around in some form is the right idea. Indeed, perhaps modifiers allow us to have a way forward toward new ideas in the language: new ideas are born as modifiers, and the popular ones get reified with better syntax once we discover usage patterns.
One strong argument in favor of modifiers is their success in other languages. I know Java has annotations (which are quite similar -- and type-based) but OCaml also has "attributes", which are quite like modifiers. OCaml attributes are not type-based: they're just strings attached to a parsed payload (such as an expression or a few other syntactic categories). This extra room in the syntax allows for a rich ecosystem of so-called ppxes (the plural of ppx), which Haskellers would call source plugins. Some attributes are interpreted by the OCaml compiler itself, but the rest are just for consumption and manipulation by ppxes -- including OCaml's entire "deriving" mechanism. Yes, the concrete syntax is pretty ugly, but the syntactic space has allowed for a wealth of growth and creativity that would not otherwise be possible. I conjecture modifiers can offer a similar wellspring for GHC.
Richard
Hi,it’s not “in the light of experience”, and there is nothing in herethat I couldn’t have brought up when it was originally discussed, andwhen I should have (but didn’t for reasons I don’t quite remember; Ithink it was a time of limited bandwidth on my side, and I had theimpression that there was a lot of enthusiasm). So I’d feel bad toactively suggest to unaccept it now – at least not unless it happensthat my worries are more widely shared.Cheers,JoachimAm Montag, dem 12.12.2022 um 16:04 +0000 schrieb Simon Peyton Jones:Joachim
Are you arguing to un-accept the modifiers proposal? I think that's
a legitimate thing to do but, well, it needs a proposal. (A kind of
drastic modification to an existing proposal, namely withdrawing it.)
We should feel free to change our view in the light of experience --
and it is much easier to do so before the feature is implemented and
in use. But I think it is not good to have a proposal that is
accepted-but-with-doubt-cast-upon-it.
Simon
On Fri, 9 Dec 2022 at 18:47, Joachim Breitner
<mail@joachim-breitner.de> wrote:
Hi,
Am Freitag, dem 09.12.2022 um 12:38 +0000 schrieb Simon Peyton
Jones:
We can always re-open an accepted proposal, especially if it is
not
yet implemented!
The motivations for modifiers I see are:
* We have modifiers for linear types
* It seem wrong to use pragmas (in {-# #-} comments) for things
that
are semantically meaningful like overlapping instances.
We definitely want modifiers in some form. We currently use them
a
lot for {-# OVERLAPPABLE #-} etc. We could stick with the {-#
prag
#-} syntax. But it's a bit noisy, and it really isn't a
comment.
And (unlike the modifier) the pragma stuff doesn't have internal
structure -- we could not use it for linear annotations.
But I think we should decide what syntax we want for modifier-
like
things, and get it implemented, else it'll keep blocking other
proposals, like this one from Matthew.
I was more quiet during the modifier discussion than I should have,
but
if we are opening this box again, I can share why I don’t feel to
confident about it:
* Tying modifiers to types rules out their use for every feature
that
is relevant before type-checking (parsing, renaming…)
For example, imagine we only had unqualified imports, and now
want
to add qualified imports. This feels like a “modification” to
me,
and a good “modifier syntax” scheme should be able to
accommodate
it. But it affects renaming, and thus wouldn’t work with a type-
based thing.
* The syntax might be too clumsy. Consider, again, adding
qualified
imports to the syntax: We’d have to specify an optional
parameter
(for the `qualified as Foo` part). How would that look like in
Type
syntax? Would the qualifier be
data Quantified = Quantified (Maybe String)
and you need to write Nothing or Just? And quote the name?
Even linear types, listed as one of the motivations, really
wants to
have a nice syntax for the linear arrow, doesn’t it?
I expect that many future modifiers on syntax benefit from
custom
syntax to be ergonomic and preserve the aesthetics of Haskell
code.
TL;DR: I doubt that a one-scheme-fits all, type-based modifier
syntax
covers enough use-cases to pay its weight, and am leaning towards
“just” coming up with custom syntax for new features (likely with
new
context-dependent keywords where possible – as in deriving via).
Cheers,
Joachim
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- Joachim Breitnermail@joachim-breitner.dehttp://www.joachim-breitner.de/_______________________________________________ghc-steering-committee mailing listghc-steering-committee@haskell.orghttps://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee