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

Kosyrev Serge-2
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.


--
с уважениeм / respectfully,
Косырев Сергей
_______________________________________________
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 Kosyrev Serge-2
Am 16.09.2016 um 15:37 schrieb Kosyrev Serge:
> The worst of all, IMO, is that it makes reasoning about the
> configuration equivalent to the halting problem.

That's a solved problem: Generate an execution plan, which would need to
be fully evaluated in Haskell; then execute it and don't feed anything
back into it.
It's easy to reason about the plan in that scenario.

This is what Gradle does.

> And god, does it hurt in practice! -- speaking as someone who had spent
> a non-trivial amount of time on doing exactly this stuff in another age
> and for another language.

Which language?

> This does not mean that we cannot find a subset of the language that
> would be a point of balance between the needs of expressivity,
> learnability and decidability.

Subsettings makes it hard to know what works and what doesn't.
A Haskell subset would have to be strict - which begs the question
what's the point in calling this a subset of Haskell (and even if there
is a point, it will draw ridicule along the lines of "Haskell is
unsuitable for describing its own configurations").

> After all JSON was born in roughly this spirit, wasn't it?

JSON was/is a serialization format, first and foremost.

>> If you can't start or modify a package without already knowing
>> haskell, it is a huge barrier to entry.
>
> I'm unconvinced that this problem cannot be resolved within the subsetting approach.

Actually subsetting is making this worse: Things freshly learned for
Haskell won't work in the config language, restrictions encountered in
the config language will be unthinkingly transferred to Haskell.

Having two subtly but fundamentally different languages is about the
worst thing you can expose a learner to.
_______________________________________________
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 Kosyrev Serge-2
.. if this helps the discussion, here is cabal file "spec"
(see also other files in the same directory)

these types are used to parse .cabal.

one benefit from using these types in reverse (to generate .cabal from .hs) would be:

it is possible to write a few libs which generate well-formed cabal files from a simplified API. It is possible this was done already.

_______________________________________________
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 Imants Cekusins
Am 16.09.2016 um 15:38 schrieb Imants Cekusins:
> a lot of what is often called "complexity" stems from lack of types and
> gaps in comments / documentation.

That's a big issue with Gradle.

The third problem I know Gradle for is that it makes it surprisingly
difficult to inspect the execution plan.
_______________________________________________
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

Geraldus
> Actually subsetting is making this worse: Things freshly learned for
> Haskell won't work in the config language, restrictions encountered in
> the config language will be unthinkingly transferred to Haskell.

I agree.  This is exactly what I felt when I tried to use Fay language, which is a «proper subset» of Haskell (in the end I switched to GHCJS).

пт, 16 сент. 2016 г. в 19:00, Joachim Durchholz <[hidden email]>:
Am 16.09.2016 um 15:38 schrieb Imants Cekusins:
> a lot of what is often called "complexity" stems from lack of types and
> gaps in comments / documentation.

That's a big issue with Gradle.

The third problem I know Gradle for is that it makes it surprisingly
difficult to inspect the execution plan.
_______________________________________________
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

Mario Blažević
In reply to this post by Joachim Durchholz
On 2016-09-16 09:51 AM, Joachim Durchholz wrote:

>
>> This does not mean that we cannot find a subset of the language that
>> would be a point of balance between the needs of expressivity,
>> learnability and decidability.
>
> Subsettings makes it hard to know what works and what doesn't.
> A Haskell subset would have to be strict - which begs the question
> what's the point in calling this a subset of Haskell (and even if there
> is a point, it will draw ridicule along the lines of "Haskell is
> unsuitable for describing its own configurations").

        Haskell is indeed unsuitable for describing the package configuration,
IMO, but not because it's lazy. It's because it lacks any syntax for
long and human-readable string literals (package description, anyone?).
That also condemns every subset of Haskell.


>> After all JSON was born in roughly this spirit, wasn't it?

        Yes, and JSON (and JavaScript) would suck for the very same reason.
This deficiency of JSON was a major incentive for creating YAML.

        I'm mildly in favour of supporting another package format in addition
to .cabal, as long as compatibility is kept, and as long as the new
format is actually superior. I think any subset of Haskell would be a
setback from usability perspective.

        One major benefit of YAML that I haven't seen mentioned is that it
could be used to replace the README.md file at the same time. Right now
a package description consists of both .cabal and (optionally) Markdown.
I suspect the latter language is actually harder for complete beginners.

_______________________________________________
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
> it lacks any syntax for long and human-readable string literals (package description, anyone?).
can  {- comments -} be used for package description?


_______________________________________________
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

Mario Blažević
On 2016-09-16 10:29 AM, Imants Cekusins wrote:
>> it lacks any syntax for long and human-readable string literals (package description, anyone?).
> ​
> can  {- comments -} be used for package description?
>

        I suppose they could, but that would rather defeat the purpose of using
a Haskell subset in the first place. Haskell ignores comments, package
descriptions should not be ignored.


_______________________________________________
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
ok how about a pragma:

7.13.6.3. Annotating modules

You can annotate modules with the ANN pragma by using the module keyword. For example:

{-# ANN module (Just "A `Maybe String' annotation") #-}


if the topic is Standard package file format, why not agree on e.g. adopting GenericPackageDescription or another similar haskell type (rather than a text-based file) as the standard?

then any format (cabal, yaml, json, ...) may be used as long as a library exists and is maintained for each such format,  which parses / produces the format from / to the standard type?


how about this?

_______________________________________________
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

Mario Blažević
On 2016-09-16 10:48 AM, Imants Cekusins wrote:
> ok how about a pragma:
>
>         7.13.6.3. Annotating modules
>
> You can annotate modules with the |ANN| pragma by using
> the |module| keyword. For example:
>
> {-# ANN module (Just "A `Maybe String' annotation") #-}

I suppose this could do, but there are some downsides:
   - somewhat cumbersome syntax,
   - reliance on a GHC extension, and worst of all,
   - not a Haskell value.

        The last point implies that the package.hs with this kind of module
annotation could not produce a proper GenericPackageDescription when
executed as a Haskell program.


> if the topic is _Standard package file format_, why not agree on e.g.
> adopting *GenericPackageDescription* or another similar haskell type
> (rather than a text-based file) as the standard?
>
> then any format (cabal, yaml, json, ...) may be used as long as a
> library exists and is maintained for each such format,  which parses /
> produces the format from / to the standard type?

        This makes perfect sense to me. The devil may be in the details. Would
cabal-install need to link in all these maintained libraries statically?
Or would there be some plug-in mechanism to load them on demand?

_______________________________________________
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
> Would cabal-install need to link in all these maintained libraries statically? Or would there be some plug-in mechanism to load them on demand?

well the libraries would need to be official and some with the packager.​

the formats would be perfectly interchangeable i.e.
cabal -> standard_type -> yaml -> standard_type -> json -> standard_type -> cabal
would produce the same cabal file 

only 1 config file per package to avoid confusion

however if the user prefers working with format F, they can always convert the format which came with the package, to F

the file can always be validated by virtue of parsing and reproducing the original file without errors.


it comes at a price of duplicated efforts however it would give every choice one can wish for. If one must use yaml, they use yaml etc.

_______________________________________________
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 libraries would need to be official and come with the packager.​

_______________________________________________
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 MigMit
On 2016-09-16 09:30, MigMit wrote:
> Sbt seems to be doing rather well, using full Scala in configurations.
>

Sbt is a *build* description, *NOT* a package description format. Sbt
uses ivy.xml files for the latter. (With interop for consuming Maven
pom.xml files such that it can leverage the already-huge Maven
repositories.)


_______________________________________________
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 Mario Blažević
On 2016-09-16 16:10, Mario Blažević wrote:

>>> After all JSON was born in roughly this spirit, wasn't it?
>
>     Yes, and JSON (and JavaScript) would suck for the very same reason.
> This deficiency of JSON was a major incentive for creating YAML.
>
>     I'm mildly in favour of supporting another package format in
> addition to .cabal, as long as compatibility is kept, and as long as the
> new format is actually superior. I think any subset of Haskell would be
> a setback from usability perspective.
>

This may be somewhat heretical, but I don't actually think we need to
have a human-editable format. (Of course it should probably be
*reasonably* human-readable/editable just for debugging and such.)

Just provide simple commands to view/manipulate whatever package
settings there are. Helpfully said commands could also sanity check
whatever you're trying to do and perhaps provide better error messages
than a tool which only has the "final" package description to work with.

For beginners a simple GUI could be provided and IDEs could do their own
thing.

Problem solves.


_______________________________________________
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
 I don't actually think we need to have a human-editable format.

.. store settings as serialized Haskell type, and use custom (non-official) viewers / editors to display them formatted to user preferences?
sounds good.

_______________________________________________
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

Sven Panne-2
In reply to this post by Bardur Arantsson-2
2016-09-16 19:14 GMT+02:00 Bardur Arantsson <[hidden email]>:
This may be somewhat heretical, but I don't actually think we need to
have a human-editable format. [...]

Coming back to the central question (see Chris' mail): What problem do we solve by doing that? Replacing a relatively easy to read format by something unreadable by humans? That's probably the opposite of what we want...
 
[...] For beginners a simple GUI could be provided and IDEs could do their own
thing.

If somebody thinks a GUI is a good idea, we don't need to change something at all: Just write a GUI for reading/editing .cabal files.
 
Problem solves.

Which problem? :-) Unless we really define what we want to improve and why, the whole discussion is pointless. Is it readability by humans? Being "standard" (whatever that means)? Being easily parsable, probably by a separate library? Being more flexible by what one can express? Having more abstraction facilities in the description? I have the impression that different people in this discussion try to solve different problems.

Cheers,
    S.

_______________________________________________
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
> what we want to improve and why

how about these:
  1. Adopt common standard for different package tools.
  2. Give users and packager devs a choice of config file formats / representations.
  3. Explore ways to simplify manual package configuration.
?

_______________________________________________
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

Sven Panne-2
2016-09-16 22:02 GMT+02:00 Imants Cekusins <[hidden email]>:
[...]
  1. Adopt common standard for different package tools.
What are these tools? AFAICT we are talking about cabal and stack only, and from the recent discussion it seems that stack has slightly different goals: One stack.yaml can reference vaious cabal package descriptions, something I've never use until now, because I wasn''t even aware that it is possible. :-). So apart from the different surface syntax, there seems to be more fundamental differences.
  1. 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.
  1. Explore ways to simplify manual package configuration.
This is a worthwhile goal IMHO, but we need to be more concrete, e.g. how can repetitive stuff like the tons of almost-copy-n-paste in https://github.com/haskell-opengl/GLUT/blob/master/GLUT.cabal be avoided? This has nothing to do with syntax, more with abstraction facilities and semantics: If we just switch to JSON or YAML, GLUT.cabal would as repetitive as before, only in a different surface syntax.

_______________________________________________
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
In reply to this post by Harendra Kumar
On 2016-09-16 at 08:20:15 +0200, Harendra Kumar wrote:

[...]

> * YAML (http://yaml.org/spec/1.2/spec.html) is standard and popular. A
> significant chunk of developer community is already familiar with it. It is
> being used by stack and by hpack as an alternative to cabal format. The
> complaint against it is that the specification/implementation is overly
> complex.

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

besides looking quite awkward IMHO (just as an exercise, try inserting a
nested if/then/else in that example above), the prospect that a standard
format like YAML would allow to reuse standard tooling/libraries for
YAML seems quite weak to me; 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.

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 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.



 [1]: The "Genius Tailor" was mentioned recently in a related discussion here:
      https://mail.haskell.org/pipermail/haskell-cafe/2016-September/124868.html

-- 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

Herbert Valerio Riedel-3
In reply to this post by Harendra Kumar

(resent from different account, sorry if dupe)

On 2016-09-16 at 08:20:15 +0200, Harendra Kumar wrote:

[...]

> * YAML (http://yaml.org/spec/1.2/spec.html) is standard and popular. A
> significant chunk of developer community is already familiar with it. It is
> being used by stack and by hpack as an alternative to cabal format. The
> complaint against it is that the specification/implementation is overly
> complex.

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

besides looking quite awkward IMHO (just as an exercise, try inserting a
nested if/then/else in that example above), the prospect that a standard
format like YAML would allow to reuse standard tooling/libraries for
YAML seems quite weak to me; 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.

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 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.



 [1]: The "Genius Tailor" was mentioned recently in a related discussion here:
      https://mail.haskell.org/pipermail/haskell-cafe/2016-September/124868.html

-- 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.
1234