[Haskell-cafe] Standard package file format

[Chris Kahn]

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.




On September 16, 2016 8:39:15 AM EDT, David McBride <toad3k at gmail.com> wrote:
> While I would personally love having a package description in haskell,
> I don't think it is a good idea.
>
> If you can't start or modify a package without already knowing
> haskell, it is a huge barrier to entry.  I remember trying to get
> started in scala and having a lot of trouble with sbt because I didn't
> know their operators for lists and arrays or hash tables or whatever
> it is that they use in their files.
>
> On Fri, Sep 16, 2016 at 4:57 AM, yogsototh
> <yann.esposito at gmail.com> wrote:
>>
>>> I guess the overriding question I have here is: what is the PROBLEM
>>> being solved?
>>
>> Let me share my experience with Clojure and lein. They use a clojure
>> hash-map for their configuration. So yes arbitrary code could be
>> executed and I believe this is a _very good thing_.
>>
>> Why? Because it makes it very easy to add sub-configuration that can
>> be used by third party plugin. For example:
>>
>> - a plugin that help the use of environment variables (lein-environ)
>>   which is really helpful for application development (not so much
>>   for library development)
>> - a plugin that use S3 for our private dependencies (not supported by
>>   default by lein)
>>
>>
>> For deployment: we were able to add request to our API server that
>> provide not only the written version but also the git commit hash. So
>> we could be certain of the version of the server. Too much time there
>> were sys/admin deployment errors. And that could only be achieved
>> because we were able to run arbitrary command in the project
>> description file.
>>
>> I certainly forget many other advantages of having a package
>> description format which is simply a data structure in the hosted
>> language. But this has by far my preference.
>>
>> - cabal is ok, but very imperfect, I generally need to have a lot of
>>   copy/paste, I need to change it very often while writing
>>   application with many dependencies
>> - JSON/YAML/TOML are simply not powerful enough to match all
>>   semantics we might need to configure a project. For example we
>>   might want to have Set instead of List for some properties. Or I
>>   don't know maybe ternary tree structures.
>>
>> The point is: we pay a price by adding a step between the semantic
>> and the syntax.
>> While if our configuration format was in Haskell we could express the
>> semantic more directly.
>>
>> _______________________________________________
>>  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.
>
>
>
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160916/8f095dfb/attachment.html>