[Haskell-cafe] Standard package file format

[Edward Z. Yang]

https://github.com/ghc-proposals/ghc-proposals/ could be used for
this purpose.  There is also the Trac wiki but I find it is a bit
too hard to keep under control with comments.

Edward

Excerpts from Harendra Kumar's message of 2016-09-17 08:05:38 +0530:
> Since I triggered this discussion I feel obligated to summarize the
> important points that were presented. Is there a good place to record
> Haskell ecosystem related discussions (some wiki)?
> 
> -harendra
> 
> On 17 September 2016 at 05:57, Paolo Giarrusso <p.giarrusso at gmail.com>
> wrote:
> 
> >
> >
> > On Friday, September 16, 2016 at 3:42:48 PM UTC+2, Kosyrev Serge wrote:
> >>
> >> Chris Kahn writes:
> >> > I would like to second this thought. Using Haskell for package
> >> > descriptions needs to be thought out and executed with great care and
> >> > attention. It's really easy to go off the rails.
> >> >
> >> > Scala's build system lets you do very powerful things, but it also
> >> > makes things unnecessarily complicated and mystifying for beginners.
> >> > At my previous work where we used Scala extensively, there were many
> >> > times where the team simply resorted to external tools because
> >> > figuring out how to make some seemingly trivial change to an SBT
> >> > module was too time consuming.
> >>
> >> Let me guess (have no idea about sbt) -- unbridled Turing completeness?
> >>
> >
> >
> >> Declarativity is king for configuration, and Turing completeness ain't it
> >> --
> >> please, see my other mail about subsetting Haskell.
> >>
> >
> > That's not the main problem with SBT. How do I explain it? Take this as an
> > example of what Haskell should *not* do.
> >
> > # SBT made difficult
> >
> > Look, we all know a monad is just a monoid in the category of
> > endofunctors, right?. Now, a SBT build configuration is just a
> > heterogeneously-typed map from keys to monadic values that can be evaluated
> > to a graph of setting transformers and build actions, so what's the problem?
> > And oh, I forgot to mention keys aren't simple strings but have a
> > hierarchy themselves, and this hierarchy is used for inheritance and
> > overriding of settings (nothing as simple as OO inheritance, mind you,
> > think of something like CSS but different).
> > Isn't using Haskell supposed to require a PhD? So why would its build
> > tools use something so simple as nested records, like Cabal does?
> > </sarcasm>
> > I think I'm trolling, but the above is somewhat accurate (except for any
> > misunderstanding of SBT I might have)—I personally enjoy using SBT and its
> > power, and once you learn it can be reasonably easy, but I think Kmett's
> > lens library might be simpler to learn.
> >
> > In fairness, many SBT builds can be read without having any clue of the
> > above, because they look like imperative programs. But as soon as you need
> > to do a bit more or you make a type error, you end up facing some of the
> > above complexity—if you want, the "imperative program" abstraction is
> > extremely leaky.
> >
> > For instance, here's something "easy" (but count the amount of custom
> > symbolic operators):
> >
> > scalaVersion := "2.11.0"
> > scalacOptions += "-deprecation"
> > libraryDependencies += org.scalatest" %% "scalatest" % "2.0"
> >
> > Then you want to use one setting when defining another, and suddenly you
> > end up with:
> >
> > libraryDependencies <+= scalaVersion (ver => "org.scala-lang" %
> > "scala-compiler" % ver)
> >
> > Luckily, this can be done more easily nowadays, thanks to Scala macros O_O.
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > To (un)subscribe, modify options or view archives go to:
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > Only members subscribed via the mailman list are allowed to post.
> >