Re: [Haskell-community] Standard package file format

[Harendra Kumar]

On 17 September 2016 at 03:43, Herbert Valerio Riedel 
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-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

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

[Harendra Kumar]

On 16 September 2016 at 16:51, Paolo Giarrusso 
wrote:

>
> I agree "full-fledged build system" is not a possible immediate goal.
> But an EDSL for expressing cabal projects (as they are today) would
> still be in scope of your proposal—and I thought you liked the idea
> (see quote below). Using the earlier options: option 3 is not in scope
> of this thread, but option 2 is, with the only danger that the design
> space is so big to present a challenge.
>

Yeah I like the idea of using Haskell for configs but perhaps in a
different problem space e.g. in a build spec. See the quote from my earlier
quote below, sorry for the confusion :-) Yes, maybe option 2 might work for
package specifications but sounds pretty hairy to explore for this use case
alone, unless we have other motivations.


> Quoting from Harendra Kumar's earlier mail:
>
>  If we have to express not just a package specification but a
> sophisticated build configuration, we need a real language. Expressing
> conditionals, reuse etc becomes a compromise in a purely declarative
> language.
>

-harendra
___
Haskell-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

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

[Harendra Kumar]

On 16 September 2016 at 12:35, Imants Cekusins  wrote:

> Why not adopt (a subset of) .hs AST file format to structure both project
> and package files?
>

Aha, that's my preferred choice. If there is a way to restrict features and
we can allow just a subset we can have a nice configuration language which
is a real language. In fact, I have been toying around this. If we have to
express not just a package specification but a sophisticated build
configuration, we need a real language. Expressing conditionals, reuse etc
becomes a compromise in a purely declarative language.

For example make has so many built-in functions in it that it has become a
full fledged language by itself. The google bazel build uses python as the
build config language. Haskell will make a much better choice for such use
cases. Pure declarative is a pain for such use cases.

-harendra
___
Haskell-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

[Haskell-community] Standard package file format

[Harendra Kumar]

I am starting a new thread for the package file format related discussion.

>From a developer's perspective, the major benefit of a standard and widely
adopted format and is that people can utilize their knowledge acquired from
elsewhere, they do not have to go through and learn differently looking and
incomplete documentation of different tools. The benefit of a common config
specification is that developers can choose tools freely without worrying
about learning the same concepts presented in different ways.

Multiple formats flying around also create a psychological impression of
complexity in the ecosystem for newcomers. If we have consistency there are
better chances of attracting more people to the language ecosystem.

I gather the following from the discussion till now:

* We have cabal, YAML and TOML as potential candidates for a common package
format which can additionally incorporate the concept of snapshots/package
collections and potentially more extensions useful across build tools.

* cabal has the benefit of incumbency and backward compatibility, it has
shortcomings which are being addressed but it is still a format which is
very specific to Haskell ecosystem. It is not a standard and not going to
become one. We have to always deal with it ourselves and everyone coming to
Haskell will have to learn it.

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

* TOML (https://github.com/toml-lang/toml) is promising, simpler than YAML
and is being used by a few important projects but is still evolving and is
not completely stable. On a first glance it looks pretty simple and a lot
of other tools use a similar config format. It is aiming to become a
standard and aiming for a wider adoption.

As a next step we can perhaps do an hpack like experiment using the TOML
format. That way we will have some experience with that as well and get to
know if there are any potential problems expressing the existing cabal
files.

More thoughts, opinions on the topic will help create a better
understanding about it.

-harendra
___
Haskell-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Harendra Kumar]

There are multiple ways to achieve this:

1) The env command being discussed is actually "stack exec env". Though it
includes the full environment rather than stack exclusive. You can use
"stack path" to print the stack exclusive environment. You can also use
"stack path --" to pick specific items from that env.

2) Using "stack exec bash" is a very convenient way as suggested by
Christopher Allen.

3) But I prefer to just use "export PATH=$(stack path --bin-path)" instead
which only sets the PATH. The full environment (when using env or bash)
also includes GHC_PACKAGE_PATH which cabal does not like. So if you want to
use cabal on stack installed ghc just setting PATH works fine.

I think stack has a lot of flexibility and features, in fact too many.
Usually there is already a way to achieve something that you want. Though
there are areas where the user experience can be made better including
cosmetic stuff like not throwing confusing or unnecessary warnings.

-harendra


On 14 September 2016 at 01:32, Christopher Allen  wrote:

> I almost never (maybe twice in the last year) do this, but when I need
> an environment that has Stack provided GHC-stuff in the path, I use
> `stack exec my-shell`.
>
>
>
> On Tue, Sep 13, 2016 at 2:55 PM, Brandon Allbery 
> wrote:
> >
> > On Tue, Sep 13, 2016 at 3:47 PM, Richard Eisenberg 
> > wrote:
> >>
> >> Other minor points:
> >> `stack env` does not work for me: my version of stack does not know how
> to
> >> `env`
> >
> >
> > I think they said that was an add-in. IIRC stack is extensible with
> external
> > commands, in roughly the same way git is.
> >
> > (I am also not fond of stack, and even less fond of the politics that go
> > with it, but will stick to the technical here.)
> >
> > --
> > brandon s allbery kf8nh   sine nomine
> associates
> > allber...@gmail.com
> ballb...@sinenomine.net
> > 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.
>
>
>
> --
> Chris Allen
> Currently working on http://haskellbook.com
> ___
> 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-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community