<div dir="auto">Peanut gallery:<div dir="auto"><br></div><div dir="auto">Agreed strongly support non-change and, thank you everyone for this incredibly useful discussion.</div><div dir="auto"><br></div><div dir="auto">Given that, I think I can still briefly extend the initial question without changing it by asking,</div><div dir="auto"><br></div><div dir="auto">What actually happens in simplest clear terms, when one fidgets a compiler flag?</div><div dir="auto"><br></div><div dir="auto">Thank you. Hoping not to re-unlurk.</div><div dir="auto"><br></div><div dir="auto">Btw each off-list is me just to clarify.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Dec 10, 2020, 7:46 PM MarLinn <<a href="mailto:monkleyon@gmail.com">monkleyon@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<p>While I do get many of the points mentioned in this thread, I
don't see a reason to change a default.</p>
<p>Because</p>
<p> A) you can set your own default with magic .ghci files, and</p>
<p> B) there's so much more to a well-set-up development $HOME
than just a -Wall and a big (editor) window.<br>
</p>
<p>In fact quite a few of the different problems mentioned in this
thread can be solved with a bit of tinkering.<br>
Here is my setup as an example:</p>
<p>My main companion .ghci file lives with me in my $HOME. When I
take it for walkies it runs a few others (~/.ghc/macros) to set
prompts and default editor, to import lambdabot and hoogle, and to
setup a few other niceties, but it also contains these two key
lines:</p>
<pre> :set -Wall -fdefer-typed-holes -fwarn-tabs -fwarn-incomplete-uni-patterns -fwarn-incomplete-record-updates -fwarn-identities -fwarn-hi-shadowing -Wredundant-constraints
:seti -XTemplateHaskell -XQuasiQuotes -XUnicodeSyntax -XTupleSections
</pre>
<p>There's that -Wall. I have forgotten what half of the others
mean, but they sort of accumulated over time. <br>
</p>
<p>Now you might say those are too many warnings. Yes. I want all of
these warnings when I'm finalizing a module, but not while I'm
still working on a new one.<br>
And what's with those extensions?<br>
</p>
<p>Well, I also have a default set of language extensions I almost
always want, both in ghci and my files. And I was tired of
re-typing the same old imports, too. So I made several templates.
A tiny bit of Haskell scripting magic turns them into a fresh new
module whenever I want to start a new one.</p>
<p>Here's one of those templates:</p>
<hr width="100%" size="2">
<pre> #! /usr/bin/env runghc
{-# OPTIONS_GHC -fno-warn-unused-imports #-}
{-# LANGUAGE
UnicodeSyntax
, OverloadedStrings
, TupleSections
, RecordWildCards
, MultiWayIf
, LambdaCase
#-}
module §name§
where
import Control.Applicative
import Control.Arrow
import Control.Monad
import Data.Monoid
import Data.Either
import Data.Function
import Data.List
import Data.Maybe
import Data.Foldable
import Data.Traversable
import Data.Map.Strict ( Map )
import qualified Data.Map.Strict as Map
import Data.Set ( Set )
import qualified Data.Set as Set
</pre>
<hr width="100%" size="2">
<p>In fact when I say "Haskell scripting magic", I mean "Haskell
scripting magic that's got its own ghci command, defined in the
.ghci file".</p>
<p>So when I want a new module, I simply say</p>
<pre> :create Example
:l Example.hs
:e
</pre>
<p>And off I go.<br>
</p>
<p>When I'm done with the module I remove that one -fno-warn and
start cleaning up.<br>
I said those where <i>too</i> many warnings for me, not <i>way</i>
too many warnings, right?<br>
</p>
<p>Is this a set of warnings or extension everyone wants? Absolutely
not. Is it time to prune this to adapt to changed GHC defaults?
Probably. Should I rework this some day to use an actual
templating library like ginger instead of my own
quickly-cobbled-together mess? Maybe. And it should probably also
adapt to the project structure by looking into .cabal files. But
for now, it works great for my use cases and coding style.<br>
</p>
<p>Don't get me wrong, changing the default might still be a good
idea. But I also don't see a reason to be bothered by it.<br>
</p>
<p>Cheers.<br>
</p>
<p><br>
</p>
</div>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div>