Ben, The suggestion of erroring if the inline pragma was not there was just because I thought it would be better than silently doing something different. But that's just a subjective opinion, it's not core to what I'm proposing.
Indeed there are two other options: 1. Make levity polymorphic functions implicitly inline OR 2. Compile a version which wraps all the levity polymorphism in boxes. Either approach would mean the program would still be accepted with or without the pragma. Whether either of them are a good idea is debatable, but it shows it's not necessary to require a pragma. So if it's important that excluding a pragma doesn't result in a program being rejected, either of the above options would solve that issue. On Sat, Oct 9, 2021 at 2:06 AM Ben Gamari <b...@smart-cactus.org> wrote: > Chris Smith <cdsm...@gmail.com> writes: > > > On Fri, Oct 8, 2021 at 10:51 AM Ben Gamari <b...@smart-cactus.org> wrote: > > > >> In my mind the fundamental problem with this approach is that it means > >> that a program's acceptance by the compiler hinges upon pragmas. > >> This is a rather significant departure from the status quo, where one > >> can remove all pragmas and still end up with a well-formed program. > >> In this sense, pragmas aren't really part of the Haskell language but > >> are rather bits of interesting metadata that the compiler may or may not > >> pay heed to. > >> > > > > I don't believe this is really the status quo. In particular, the > pragmas > > relating to overlapping instances definitely do affect whether a program > > type-checks or not. > > Yes, this is a fair point. Moreover, the same can be said of > LANGUAGE pragmas more generally. I will rephrase my statement to reflect > what was in my head when I initially wrote it: > > >> In my mind the fundamental problem with this approach is that it means > >> that a program's acceptance by the compiler hinges upon INLINE pragmas. > >> This is a rather significant departure from the status quo, where one > >> can remove all INLINE, INLINEABLE, RULES, and SPECIALISE pragmas and > >> still end up with a well-formed program. > > These pragmas all share the property that they don't change program > semantics but rather merely affect operational behavior. Consequently, > they should not change whether a program should be accepted. > > Cheers, > > - Ben >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
