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
|

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

Tobias Dammers

Another factor in favor of YAML is that it is a superset of JSON, which eases the learning curve even more (with JSON being a de facto lingua franca for cross-platform untyped data structures), and offers some extra possibilities, although I admit that I can't think of any practical uses. The fact that both Yaml and JSON can be represented as Aeson Values would also make things (arguably) easier for tool writers.


On Sep 16, 2016 8:20 AM, "Harendra Kumar" <[hidden email]> wrote:
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-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

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

This would simplify parsing config files as well as syncing code and config files in IDEs.


To draw an analogy, JSON derives from JavaScript. Isn't this a precedent?


_______________________________________________
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 16.09.2016 um 08:20 schrieb Harendra Kumar:
> * 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.

TOML is limited in its data types: numbers, dates, strings for
primitives, arrays and string-to-object maps.
I'd consider that too limited to ever become a universal configuration
format.
_______________________________________________
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
In reply to this post by Imants Cekusins
On 16 September 2016 at 12:35, Imants Cekusins <[hidden email]> 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-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

Alan & Kim Zimmerman
The more power you put into the package file description, the harder it is for the surrounding ecosystem to reason about it.

So if you can execute arbitrary code in a new-gen cabal file, apart from the security aspects, it becomes difficult to be sure what is actually being specified, if you do not reproduce the original environment when evaluating the file.

Alan

On Fri, Sep 16, 2016 at 9:18 AM, Harendra Kumar <[hidden email]> wrote:
On 16 September 2016 at 12:35, Imants Cekusins <[hidden email]> 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-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

MigMit
Sbt seems to be doing rather well, using full Scala in configurations.

I think package descriptions should be limited, but not syntactically. Using some specific monad might work OK.

> On 16 Sep 2016, at 09:22, Alan & Kim Zimmerman <[hidden email]> wrote:
>
> The more power you put into the package file description, the harder it is for the surrounding ecosystem to reason about it.
>
> So if you can execute arbitrary code in a new-gen cabal file, apart from the security aspects, it becomes difficult to be sure what is actually being specified, if you do not reproduce the original environment when evaluating the file.
>
> Alan
>
> On Fri, Sep 16, 2016 at 9:18 AM, Harendra Kumar <[hidden email]> wrote:
> On 16 September 2016 at 12:35, Imants Cekusins <[hidden email]> 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-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.

_______________________________________________
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
> So if you can execute arbitrary code in a new-gen cabal file, apart from the security aspects, ...
well config files could use different (not .hs) extensions. They could use their own Prelude and not allow importing other modules.

The main benefit is to reuse existing parsers and simplify code-config sync.

_______________________________________________
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

Chris Smith-31
In reply to this post by Harendra Kumar
I guess the overriding question I have here is: what is the PROBLEM being solved?  I know of basically no beginners who were confused or intimidated by the syntax of Cabal's file format.  It's fairly commonplace for beginners to be confused by the *semantics*: which fields are needed and what they mean, how package version bounds work, what flags are and how they interact with dependencies, the relationship between libraries and executables defined in the same file, etc.  But the syntax?  It's just not an issue.  I'm not sure what it means to say that people have to "learn" it, because in introducing dozens of people to building things in Haskell, I've never seen that learning process even be noticeable, much less an impediment.

With this in mind, a lot of the statements about these various languages are not entirely convincing.  That it's a superset of JSON?  It's not clear why this matters.  A psychological impression of complexity?  Just not anything I've seen evidence of.  Indeed, aside from the rather painful many-years-long migration, the *cost* (though certainly not a prohibitive one) of moving to something like YAML or TOML is that they have a bit louder syntax, that demands more attention and feels more complex.

There is one substantial disadvantage I'd point out to the Cabal file format as it stands, and that's that it's pretty non-obvious how to parse it, so we will always struggle to interact with it from automated tools, unless those tools are also written in Haskell and can use the Cabal library.  That's a real concern; pragmatic large-scale build environments are not tied to specific languages, and include a variety of ad-hoc third-party tooling that needs to be integrated, and Cabal remains opaque to them.  But that doesn't seem to be what's motivating this conversation.

On Thu, Sep 15, 2016 at 11:20 PM, Harendra Kumar <[hidden email]> wrote:
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-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

Joachim Durchholz
In reply to this post by Alan & Kim Zimmerman
Am 16.09.2016 um 09:22 schrieb Alan & Kim Zimmerman:
> The more power you put into the package file description, the harder it is
> for the surrounding ecosystem to reason about it.
>
> So if you can execute arbitrary code in a new-gen cabal file, apart from
> the security aspects, it becomes difficult to be sure what is actually
> being specified, if you do not reproduce the original environment when
> evaluating the file.

A little-hyped aspect of Gradle is that it has two strictly divided
phases: Phase 1 builds the dependency model, phase 2 executes it.
Once phase 1 finishes, the dependency model becomes read-only, phase 2
is not allowed to modify it.

On the plus side, this makes it easy for tools to reason about the
model: it's static and easy to reproduce (just run phase 1 on the config
file, or even better, ask the Gradle daemon that's caching the model).

On the minus side, it's hard to make out which code in the config is
phase-1 and which is phase-2: Same syntax, no static types to guide the
intuition; essentially, you have to know which parameters of what
phase-1 library functions are closures to be executed in phase 2.
Haskell might be able to do better in this area, though I'm in no
position to make any proposals 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: [Haskell-community] Standard package file format

Imants Cekusins
In reply to this post by Chris Smith-31
>  what is the PROBLEM being solved? 

by making config files follow .hs syntax, cabal file structure may be defined as a data record. This would make it clear, which fields are compulsory, which are optional.

Enums may be used.

_______________________________________________
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: [Haskell-community] Standard package file format

Harendra Kumar
In reply to this post by Chris Smith-31
The discussion originated in an earlier thread from a question about the possibility of using the same format across different tools, cabal and stack which currently use different file formats. If they have to use the same format what that format should be.

On 16 September 2016 at 13:54, Chris Smith <[hidden email]> wrote:
I guess the overriding question I have here is: what is the PROBLEM being solved?  I know of basically no beginners who were confused or intimidated by the syntax of Cabal's file format.  It's fairly commonplace for beginners to be confused by the *semantics*: which fields are needed and what they mean, how package version bounds work, what flags are and how they interact with dependencies, the relationship between libraries and executables defined in the same file, etc.  But the syntax?  It's just not an issue.  I'm not sure what it means to say that people have to "learn" it, because in introducing dozens of people to building things in Haskell, I've never seen that learning process even be noticeable, much less an impediment.

With this in mind, a lot of the statements about these various languages are not entirely convincing.  That it's a superset of JSON?  It's not clear why this matters.  A psychological impression of complexity?  Just not anything I've seen evidence of.  Indeed, aside from the rather painful many-years-long migration, the *cost* (though certainly not a prohibitive one) of moving to something like YAML or TOML is that they have a bit louder syntax, that demands more attention and feels more complex.

There is one substantial disadvantage I'd point out to the Cabal file format as it stands, and that's that it's pretty non-obvious how to parse it, so we will always struggle to interact with it from automated tools, unless those tools are also written in Haskell and can use the Cabal library.  That's a real concern; pragmatic large-scale build environments are not tied to specific languages, and include a variety of ad-hoc third-party tooling that needs to be integrated, and Cabal remains opaque to them.  But that doesn't seem to be what's motivating this conversation.

On Thu, Sep 15, 2016 at 11:20 PM, Harendra Kumar <[hidden email]> wrote:
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-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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community



_______________________________________________
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 Chris Smith-31
Am 16.09.2016 um 10:24 schrieb Chris Smith:
> With this in mind, a lot of the statements about these various languages
> are not entirely convincing.  That it's a superset of JSON?  It's not clear
> why this matters.

It does matter for people who already know JSON: They can skip over the
config file syntax and dive right into the semantics.
Given that a substantial fraction of programmers knows JSON, using that
syntax would create a lower entry barrier.

The same argument can be made for YAML.

This argument cannot be made for TOML at this time, maybe never if
TOML's limitations prevent widespread adoption.

 > A psychological impression of complexity?  Just not
> anything I've seen evidence of.  Indeed, aside from the rather painful
> many-years-long migration, the *cost* (though certainly not a prohibitive
> one) of moving to something like YAML or TOML is that they have a bit
> louder syntax, that demands more attention and feels more complex.

YAML's complexity is partly because it tries to cover everything, partly
because it is pushing hard to be both human-readable and machine-readable.
It's pretty good at this actually, though I guess 20/20 hindsight could
lead to improvements - but not enough to make a new YAML version worth
the effort.

> There is one substantial disadvantage I'd point out to the Cabal file
> format as it stands, and that's that it's pretty non-obvious how to parse
> it, so we will always struggle to interact with it from automated tools,
> unless those tools are also written in Haskell and can use the Cabal
> library.  That's a real concern; pragmatic large-scale build environments
> are not tied to specific languages, and include a variety of ad-hoc
> third-party tooling that needs to be integrated, and Cabal remains opaque
> to them.  But that doesn't seem to be what's motivating this conversation.

That's implicit in the "it would be nice to have a standard format"
argument, even if it hasn't been explicitly voiced yet.

_______________________________________________
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

Yann Esposito
In reply to this post by Chris Smith-31

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

Re: Standard package file format

Andrew Butterfield-2
In reply to this post by Chris Smith-31

> On 16 Sep 2016, at 09:24, Chris Smith <[hidden email]> wrote:
>
> I guess the overriding question I have here is: what is the PROBLEM being solved?  I know of basically no beginners who were confused or intimidated by the syntax of Cabal's file format.

As a "beginner"(*), I fully agree.
However having more than one language in the mix can be confusing and complicating...

> It's fairly commonplace for beginners to be confused by the *semantics*: which fields are needed and what they mean, how package version bounds work, what flags are and how they interact with dependencies, the relationship between libraries and executables defined in the same file, etc.

It's all about the semantics - it should preferably be formalised, and ideally the relevant library/package system should be able to check/enforce rules.

> But the syntax?  It's just not an issue.  I'm not sure what it means to say that people have to "learn" it, because in introducing dozens of people to building things in Haskell, I've never seen that learning process even be noticeable, much less an impediment.

I quite agree
>

Andrew Butterfield
School of Computer Science & Statistics
Trinity College
Dublin 2, Ireland

(*) I've only started to use cabal recently, because a TA of mine built a cabal-based coursework grading system for me - I generally do application devpt in Haskell
and the only build command I need is ghc --make.... Currently moving quickly onto stack this year....

_______________________________________________
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 Yann Esposito
.. for interop with other packagers / builders, .hs compatible config content could be transformed / exported to other formats.

.hs -> YAML, JSON, ... is likely to be possible and easier than the other way around.

_______________________________________________
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

David McBride
In reply to this post by Yann Esposito
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 <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Standard package file format

Chris Kahn
In reply to this post by Harendra Kumar
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 <[hidden email]> 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 <[hidden email]> 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:
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:
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

Kosyrev Serge-2
In reply to this post by David McBride
David McBride writes:
> While I would personally love having a package description in haskell,
> I don't think it is a good idea.

I think we all can agree, that using the fully-fledged language for
configuration is an extremely bad idea from many perspectives.

The worst of all, IMO, is that it makes reasoning about the
configuration equivalent to the halting problem.

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.

However.

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.

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

The wins are obvious to me:

 - the syntax is immediately obvious to the target audience

 - minimum effort to get existent Haskell tools to work with the "new"
   format at the source level -- syntax highlighting, checking, etc.
   The only required additions would be restriction enforcement

 - no third-party libraries need to be used as dependencies for our
   core tooling

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

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

That is because they committed to the sin of employing the whole of
Scala for the thing.  Bad for them.

But also.. let's not commit the mistake of conflating the surface syntax
and the semantics.

The semantics are dictated by need -- whose sharpening effect on the
learning curve is unavoidable.  I'm willing to argue that a large part
of your confusion came from the /semantics/ of sbt, not the syntax.

The syntax differences, OTOH, can and ought to be trivialized.

--
с уважени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

Imants Cekusins
In reply to this post by Chris Kahn
my experience with Gradle was frustrating too. Even with some experience with Java.

a lot of what is often called "complexity" stems from lack of types and gaps in comments / documentation.

language needs to be learnt anyway. If config syntax needs to be learnt in addition to language syntax, this is always extra work.


for 1st timers to be able to write hello world, sample config files and a few tutorials would go a long way.


_______________________________________________
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