[Haskell-community] [Haskell-cafe] Standard package file format

[Harendra Kumar]

This seems to have gone into a different direction. The original point was
about the package specification format and not expressing a full fledged
build system. That is an entirely different ballgame. The main point of the
thread was whether it makes sense to use a single specification format for
both stack and cabal install (YAML vs .cabal and then TOML came into
picture). Haskell does not seem to be a choice for a package specification
format unless we have a very different goal in mind.

-harendra

On 16 September 2016 at 16:08, Paolo Giarrusso <p.giarrusso at gmail.com>
wrote:

> On 16 September 2016 at 12:13, Patrick Pelletier
> <ppelleti at funwithsoftware.org> wrote:
> > On 9/16/16 2:36 AM, Paolo Giarrusso wrote:
> >>
> >> (Resending from right address)
> >>
> >> We're talking about *three* options:
> >> 1. syntax for pure Haskell values, which I'll call HSON (Haskell
> >> jSON). That's just an alternative to YAML/TOML/... That would need
> >> extensions to allow omitting optional fields entirely.
> >> 2. a pure Haskell embedded domain-specific language (EDSL) that simply
> >> generates cabal description records (GenericPackageDescription
> >> values). That would allow abstraction over some patterns but not much
> >> more. But that alone is already an argument for EDSLs—the one Harendra
> >> already presented.
> >> 3. a Haskell embedded domain-specific language (EDSL) designed for an
> >> extensible build tool, like Clojure's (apparently), SBT for Scala or
> >> many others. That would potentially be a rabbit hole leading to a
> >> rather *different* tool—with a different package format to boot. That
> >> can't work as long as all libraries have to be built using the same
> >> tool. But stack and cabal are really about how to manage package
> >> databases/GHC/external environments, while extensible build tools are
> >> about (a more powerful form) of writing custom setup scripts. I
> >> suspect some extensions might be easier if more of the actual building
> >> was done by the setup script, but I'm not sure.
> >
> >
> > Options 2 and 3 both require running Haskell code at build time.
>
> > But if all packages had to use the new EDSL, then cross-compilation
> would essentially become impossible.
>
> "All packages migrate to new format" doesn't seem really a plausible
> option, as I already hinted in the text you quote.
> There are multiple JVM build tools because they're interoperable (like
> cabal-install and Stack): each library picks its own build tool, but
> they can still be linked together.
> Hpack generates cabal files, stack reuses cabal or hpack files.
>
> In principle, option 2 just needs a non-cross-compiled program to
> produce a package description—say by producing a cabal file. You just
> need to runghc it, either via ghci or by compiling and running a
> binary. Option 3 can be trickier depending on details, but the as long
> as you account for cross-compilation in the design it should be
> doable. For Template Haskell the problem is deeper (see
> http://blog.ezyang.com/2016/07/what-template-haskell-gets-
> wrong-and-racket-gets-right/),
> so let's *not* use it here.
> --
> Paolo G. Giarrusso - Ph.D. Student, Tübingen University
> http://ps.informatik.uni-tuebingen.de/team/giarrusso/
> _______________________________________________
> Haskell-community mailing list
> Haskell-community at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-community/attachments/20160916/58b490c9/attachment.html>