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