Standard package file format

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
79 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: Standard package file format

Harendra Kumar


On 17 September 2016 at 03:43, Herbert Valerio Riedel <[hidden email]> wrote:

I'm not sure if this has been pointed out already, but beyond turning a
proper grammar into a stringly-typed one, shoehorning some features of
.cabal files into YAML syntax really appear like a case of the "Genius
Tailor"[1], e.g. consider the `hpack` example

   when:
     - condition: flag(fast)
       then:
         ghc-options: -O2
       else:
         ghc-options: -O0


I agree. Supporting conditionals with YAML looks hacky!

-harendra

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Standard package file format

Paolo Giarrusso
In reply to this post by Kosyrev Serge-2


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.
Reply | Threaded
Open this post in threaded view
|

Re: Standard package file format

Harendra Kumar
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 <[hidden email]> 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.


_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Standard package file format

Bardur Arantsson-2
In reply to this post by Herbert Valerio Riedel
On 2016-09-16 23:57, Herbert Valerio Riedel wrote:

> Besides, many YAML (& JSON) parsers silently drop duplicate keys, so if
> by accident you place a 2nd `else:` branch somewhere, you end up with an
> ambiguous .yaml file which may either result in an error, in the first
> key getting dropped (most likely variant), or in the 2nd key getting
> dropped. Which one you get depends on the YAML parser implementation.

I was actually curious about this, and it's interesting to note that
even JSON which was supposed to have *ONE STANDARD* now apparently has
two, an ECMA one and and IETF RFC (seems to be more recent).

So I'd say JSON technically _allows_ duplicate keys, but that you cannot
reasonably any type of sane behavior in practice if you do
that.

Source: http://stackoverflow.com/a/23195243

(Didn't check up on what the situation is in YAML. YAML is too awful to
contemplate regardless.)

Regards,

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Standard package file format

Joachim Durchholz
In reply to this post by Harendra Kumar
Am 17.09.2016 um 01:53 schrieb Harendra Kumar:
> I agree. Supporting conditionals with YAML looks hacky!

All I have seen was direct translation and conclusion that it doesn't work.
I haven't seen any attempts at making it look well.

Also, while aesthetics isn't irrelevant, it's a pretty weak argument.
_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Standard package file format

Herbert Valerio Riedel-3
In reply to this post by Bardur Arantsson-2
On 2016-09-17 at 06:47:52 +0200, Bardur Arantsson wrote:

[...]

> I was actually curious about this, and it's interesting to note that
> even JSON which was supposed to have *ONE STANDARD* now apparently has
> two, an ECMA one and and IETF RFC (seems to be more recent).

Btw, that's partly because ECMA and IETF weren't able to agree who
"owns" JSON, for more details see

  https://www.tbray.org/ongoing/When/201x/2014/03/05/RFC7159-JSON

-- hvr
_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Standard package file format

Joachim Durchholz
In reply to this post by Herbert Valerio Riedel-3
Am 17.09.2016 um 00:13 schrieb Herbert Valerio Riedel:
> the prospect that a standard
> format like YAML would allow to reuse standard tooling/libraries for
> YAML seems quite weak to me;

It's not about standard tooling, it's about tools written by third
parties. Tools that you didn't have the time or interest to write
yourself, but which still help make your ecosystem more useful to others.

 > if, for instance, you run the above through

> a YAML pretty-printer, you easily end up with something like
>
>    when:
>    - else:
>        ghc-options: -O0
>      then:
>        ghc-options: -O2
>      condition: flag(fast)
>
> or any other ordering depending on how the keys are sorted/hashed.

Only if you use a bad pretty-printer that parses the YAML, then writes
it in prettified form.
Such a pretty-printer would also lose comments.

In other words: I'd be surprised to find a pretty-printer in actual use
that works that way.

> Besides, many YAML (& JSON) parsers silently drop duplicate keys,

That's indeed a common bug/misfeature due to historical accidents.
It's easy to fix though, and libraries have started to acquire options
to get that reported as an error.

> I really don't understand the appeal of applying the golden hammer of
> YAML, if `.cabal`'s grammar is already self-evident and concise with its
> syntax:
>
>   if flag(fast)
>     ghc-options: -O2
>   else
>     ghc-options: -O0
>
> where this if/then/else construct is encoded in the grammar proper
> rather than being merely a semantic interpretation after decoding a
> general grammar designed for simpler typed data-representations which
> isn't even accurate enough (since it has additional symmetries/freedoms)
> to capture the desired grammar faithfully, which make YAML quite
> error-prone for this specific application.

Yeah it isn't nice.
Changing the grammar always produces that kind of awkwardnesses.
However, for a fair comparison, you need to actively look for things
that work better with the alternate grammar before you conclude it's worse.
_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Standard package file format

Imants Cekusins
> Give users and packager devs a choice of config file formats / representations.
> Why is this even a goal? On the contrary, I see this as an anti-goal, because it leads to useless creativity and fragmentation.
such creativity and fragmentation may actually give benefits.

can MVC [1] be relevant here?

currently both config content (let's call it a model) and representation (view: specific config file type) are bundled.

if a common model is agreed on, package tool and IDE devs could pick any view (format) that best suits their / users needs.

such fragmentation would not break the workflow. If someone thinks of a convenient format and believe it worth their time to write a controller for it, why not?

[1] mvc

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Standard package file format

Brandon Allbery
In reply to this post by Joachim Durchholz

On Sat, Sep 17, 2016 at 2:41 AM, Joachim Durchholz <[hidden email]> wrote:
Changing the grammar always produces that kind of awkwardnesses.
However, for a fair comparison, you need to actively look for things that work better with the alternate grammar before you conclude it's worse.

The burden is on you to prove that the massive upheaval of a switch is justified, not on others to prove that your preference won't work.

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Standard package file format

Brandon Allbery
In reply to this post by Imants Cekusins

On Sat, Sep 17, 2016 at 2:54 AM, Imants Cekusins <[hidden email]> wrote:
currently both config content (let's call it a model) and representation (view: specific config file type) are bundled.

if a common model is agreed on, package tool and IDE devs could pick any view (format) that best suits their / users needs.

such fragmentation would not break the workflow. If someone thinks of a convenient format and believe it worth their time to write a controller for it, why not?

Do I have to obtain whatever whizzy new controller you've come up with in order to work with your packages?
Do I have to do this when everyone has come up with their own whizzy new controller and I need to fit their packages into whatever I am trying to write?

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Standard package file format

Imants Cekusins
> Do I have to obtain whatever whizzy new controller you've come up with in order to work with your packages?
> Do I have to do this when everyone has come up with their own whizzy new controller and I need to fit their packages into whatever I am trying to write?
that's the while point. If we could agree on a standard serializeable model, each controller would ensure the link between the view and the model.

user could open a package in any IDE / environment. The environment's controller would display the model in its own / user preferred view.

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Standard package file format

Imants Cekusins
.. the model would be shipped with packages.

pretty printing the config model to formatted yet non-editable config view (like the docs) may be made part of build process.



_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Standard package file format

Brandon Allbery
In reply to this post by Imants Cekusins

On Sat, Sep 17, 2016 at 3:06 AM, Imants Cekusins <[hidden email]> wrote:
that's the while point. If we could agree on a standard serializeable model,

That seems like a big "if". Especially since many dev tools exist to extend the model, and quite aside from "so where's the 'standard' now", conflicts you can currently control (mostly) suddenly become problematic. (I'm tempted to point to how gtk2hs's configuration phase works. pTk may be an even more severe example, although non-Haskell.)

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Standard package file format

Joachim Durchholz
In reply to this post by Brandon Allbery
Am 17.09.2016 um 08:57 schrieb Brandon Allbery:
> On Sat, Sep 17, 2016 at 2:41 AM, Joachim Durchholz <[hidden email]> wrote:
>
>> Changing the grammar always produces that kind of awkwardnesses.
>> However, for a fair comparison, you need to actively look for things that
>> work better with the alternate grammar before you conclude it's worse.
>
> The burden is on you to prove that the massive upheaval of a switch is
> justified, not on others to prove that your preference won't work.

I do like YAML, but I know far too little about the various use cases to
justify any preference; it's quite possible that it's not a good fit,
but I can't really decide it.

All I can do is provide knowledge about YAML, which in some cases was
really necessary, and pointing out one-sided arguments such as
Herbert's; doing a review of Cabal config usecases and see how well they
map to YAML is, sadly, beyond my capabilities.
Contributing the best I can and all that.
_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Standard package file format

Imants Cekusins
In reply to this post by Brandon Allbery
That seems like a big "if". 

the model may be versioned. it may include "tool T only section" which the other tools skip over or simply display with show

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Standard package file format

Herbert Valerio Riedel-3
In reply to this post by Joachim Durchholz
Hello,

On 2016-09-17 at 08:41:37 +0200, Joachim Durchholz wrote:
> Am 17.09.2016 um 00:13 schrieb Herbert Valerio Riedel:
>> the prospect that a standard format like YAML would allow to reuse
>> standard tooling/libraries for YAML seems quite weak to me;
>
> It's not about standard tooling, it's about tools written by third
> parties. Tools that you didn't have the time or interest to write
> yourself, but which still help make your ecosystem more useful to
> others.

Sure, but we don't need to throw out the baby with the bathwater to
accomplish that!

Oleg is currently working on a new parser for cabal.config,
cabal.project & ${pkg}.cabal grammar (NB: cabal already uses one
standard unified syntax for all its configuration/description files)
which lends itself better to provide equivalent of ghc-exactprint
(i.e. perfect roundtripping, allowing for faithful refactoring
tooling). Then 3rd parties can then use this new parser as a library.

[..]

>> I really don't understand the appeal of applying the golden hammer of
>> YAML, if `.cabal`'s grammar is already self-evident and concise with its
>> syntax:
>>
>>   if flag(fast)
>>     ghc-options: -O2
>>   else
>>     ghc-options: -O0
>>
>> where this if/then/else construct is encoded in the grammar proper
>> rather than being merely a semantic interpretation after decoding a
>> general grammar designed for simpler typed data-representations which
>> isn't even accurate enough (since it has additional symmetries/freedoms)
>> to capture the desired grammar faithfully, which make YAML quite
>> error-prone for this specific application.
>
> Yeah it isn't nice.
> Changing the grammar always produces that kind of awkwardnesses.
> However, for a fair comparison, you need to actively look for things
> that work better with the alternate grammar before you conclude it's
> worse.

Well, that burden of proof lies with those who argue YAML to be
superior to .cabal syntax, doesn't it?

The if/then/else awkwardness is just one aspect I pointed out
explicitly. I hinted at other issues which result from first parsing
into an inappropriate data-model just for the sake of using YAML, and
then having to re-parse that interim lossy data-model for real into the
actual data-model we're interested in (and hoping we didn't loose some
of the essential information).

But I see no need to invest time to spell those problems out until I see
a compelling argument that e.g. YAML syntax is really preferable (to
justify the costs incurred) to the status quo in the first place.


-- hvr
_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Standard package file format

Bardur Arantsson-2
On 2016-09-17 09:25, Herbert Valerio Riedel wrote:

> Hello,
>
> On 2016-09-17 at 08:41:37 +0200, Joachim Durchholz wrote:
>> Am 17.09.2016 um 00:13 schrieb Herbert Valerio Riedel:
>>> the prospect that a standard format like YAML would allow to reuse
>>> standard tooling/libraries for YAML seems quite weak to me;
>>
>> It's not about standard tooling, it's about tools written by third
>> parties. Tools that you didn't have the time or interest to write
>> yourself, but which still help make your ecosystem more useful to
>> others.
>
> Sure, but we don't need to throw out the baby with the bathwater to
> accomplish that!
>
> Oleg is currently working on a new parser for cabal.config,
> cabal.project & ${pkg}.cabal grammar (NB: cabal already uses one
> standard unified syntax for all its configuration/description files)
> which lends itself better to provide equivalent of ghc-exactprint
> (i.e. perfect roundtripping, allowing for faithful refactoring
> tooling). Then 3rd parties can then use this new parser as a library.

I didn't see anything in the PR about exporting that parser as a
library. Do you have a reference for that?

Regardless: It will only help third party code written in Haskell. Much
as I like most userland software to be written in Haskell it won't help
e.g. IntelliJ IDEA one whit.

Regards,

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Standard package file format

Joachim Durchholz
Am 17.09.2016 um 09:51 schrieb Bardur Arantsson:
> Regardless: It will only help third party code written in Haskell. Much
> as I like most userland software to be written in Haskell it won't help
> e.g. IntelliJ IDEA one whit.

Unless Haskell runs on the JVM.
Do you know whether Frege (https://github.com/Frege) is a viable option
for that? At least at the surface, it qualifies, but I don't know
whether the details (performance, Java library interoperability,
stability, availability of Haskell language extensions) work out well
enough for that.
_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Standard package file format

Bardur Arantsson-2
On 2016-09-17 10:50, Joachim Durchholz wrote:
> Am 17.09.2016 um 09:51 schrieb Bardur Arantsson:
>> Regardless: It will only help third party code written in Haskell. Much
>> as I like most userland software to be written in Haskell it won't help
>> e.g. IntelliJ IDEA one whit.
>
> Unless Haskell runs on the JVM.

I think people have been wishing for that for a while... some people
even worked on it, but so far nothing's come of it AFAIK.

> Do you know whether Frege (https://github.com/Frege) is a viable option
> for that?

Not in the least last time I checked. It's missing far too many of the
extensions that almost everybody uses as a matter of course.

Maybe given a few more years, but I'm not holding my breath.

Regards,

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Standard package file format

Edward Z. Yang
In reply to this post by Harendra Kumar
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 <[hidden email]>
> 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.
> >
_______________________________________________
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.
1234