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

Joachim Durchholz
Am 17.09.2016 um 11:35 schrieb Bardur Arantsson:
> On 2016-09-17 10:50, Joachim Durchholz wrote:
>> 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.

Pity.
Any idea how hard it would be to make it compile ghc?
_______________________________________________
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

Rahul Muttineni
In reply to this post by Joachim Durchholz
Hi Joachim,

Besides Frege, Haskell does indeed run on the JVM now via GHCVM [1] - it was my HSoC project. I'll be doing a release in a couple days once I get a couple issues sorted out and the installation is streamlined. I'm currently working with Cary Robbins on getting the HaskForce Intellij Plugin working for GHCVM. If all goes well, GHCVM 0.0.1 will ship with ghcvm, ghcvm-pkg, cabalvm (a fork of cabal-install 1.22.9.0/Cabal 1.22.8.0 that supports GHCVM), a working Intellij plugin, and will support all of GHC 7.10.3 extensions other than Template Haskell + interoperation with Java libraries. You can join us on Gitter for live updates [2].


Thanks,
Rahul

On Sat, Sep 17, 2016 at 2:20 PM, Joachim Durchholz <[hidden email]> 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.
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.



--
Rahul Muttineni

_______________________________________________
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

Daniel Trstenjak-2
In reply to this post by Bardur Arantsson-2
On Sat, Sep 17, 2016 at 09:51:25AM +0200, Bardur Arantsson wrote:
> 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.

If you're talking about more IDEs supporting Haskell, then having a
more standard package format really won't help that much.

Getting good and stable support there's a need for tools that can be called
by IDEs. Building a Haskell project IDEs won't read the cabal file
and call ghc, but they just call cabal.

The same is the case for e.g. auto completion or any other IDE operation
that needs to consider the whole project, the configuration and all of
its dependencies.

Reimplemeting cabals logic in every IDE doesn't make that much sense and
at the end it won't work that well and it will easily break.
_______________________________________________
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

amindfv
In reply to this post by Joachim Durchholz
On Sat, Sep 17, 2016 at 7:27 AM, Joachim Durchholz <[hidden email]> wrote:
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.


Read the next paragraph in hvr's email: he was very much not talking about aesthetics.

 
_______________________________________________
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

amindfv
In reply to this post by Imants Cekusins
On Fri, Sep 16, 2016 at 4:35 PM, Imants Cekusins <[hidden email]> wrote:
> 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


Even just looking at the set of features which is 1:1 betw. YAML and JSON, we're essentially just talking about key-value pairs with a couple of common types for the values. This isn't all .cabal files contain (e.g. see hvr's points about conditionals), but if it were true, is it really worth changing how Cabal works for a diffferent color bikeshed?


On Sat, Sep 17, 2016 at 8:06 AM, Imants Cekusins <[hidden email]> wrote:
> 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.


Why not have .cabal files be the standard model, and anyone can write tools on top to translate to/from .cabal if users really want to use something else?

In general, though, I don't think the fragmentation is worth it.

Tom
 

_______________________________________________
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
here are some charts to highlight differences between 
  • currently used text based config and
  • suggested model based config

_______________________________________________
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 have .cabal files be the standard model, and anyone can write tools on top to translate to/from .cabal if users really want to use something else?
.cabal file is representation rather than a model. It is parsed to model. Being a distinct file type with its own AST, it needs quite a bit of attention. It  needs to be parsed, updated, validated, formatted.

Another config format emerged. More problems (distinct file type etc). More formats may follow.

Is there hope to agree on common format (as per thread title), if common content can not be agreed on? Isn't config first of all about content? Is the common format going to contain incompatible / conflicting data items?

With common content, display format will not matter at all, neither will package tool nor IDE used to work on a project.

Config being a Haskell type, it would be well formed. The options would be well known.

Users and IDE devs will not need to worry about indenting, commas, line breaks and other goodies.

_______________________________________________
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-18 17:40 GMT+02:00 Imants Cekusins <[hidden email]>:
.cabal file is representation rather than a model. It is parsed to model.

Well, that's the case for basically everything you give to a program, so I don't see the point here. A .hs file is e.g. just a textual representation of the more abstract notion of a Haskell program/module, too. A .cabal file is just a textual representation of a the abstract notion of a Haskell package description.
 
Being a distinct file type with its own AST,

Distinct from what?
 
it needs quite a bit of attention.

From whom?
 
It  needs to be parsed, updated, validated, formatted.

This will be the case for whatever is being used, so again: What's the point? It doesn't matter if it's in its own .cabal syntax, in some Haskell-like syntax, JSON, YAML, or even some graphical representation.
 
Another config format emerged.

I'm not sure what config format is meant here. If it's stack.yaml, it *must* be somehow different (even if we ignore the surface syntax), because it describes a project, not a single package.
 
More problems (distinct file type etc).

What are the actual problems here?
 
More formats may follow.

If they are for different purposes, that's OK and is to be expected.
 
Is there hope to agree on common format (as per thread title), if common content can not be agreed on? Isn't config first of all about content? Is the common format going to contain incompatible / conflicting data items?

.cabal files describe "how a package looks like" and a stack.yaml describes "how to build a project in a reproducable way", which are different (although related) things. What should "common" mean here?
 
With common content, display format will not matter at all, neither will package tool nor IDE used to work on a project.

Config being a Haskell type, it would be well formed. The options would be well known.

Users and IDE devs will not need to worry about indenting, commas, line breaks and other goodies.

Somehow you will always need a concrete representation of abstract notions (call them "models", "ASTs", etc.), otherwise you won't be able to process them. So you will always need to care about some kind of syntax etc., I can't see how using a "Haskell type" will help here. And you will need some semantics for the representation. Even if we used e.g. JSON (or whatever is en vogue at the moment), IDEs will not magically start understanding and supporting Haskell projects.

Again: What is the actual problem we're trying to solve? I still haven't seen a concrete use case which is hard/impossible with the current state of affairs. Personally, I would e.g. like to see some abstraction facilities to avoid repetition in .cabal files with lots of executables, but I don't care about the concrete syntax (and Cabal's internal model/AST wouldn't be affected, either).

_______________________________________________
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
> Well, that's the case for basically everything you give to a program, so I don't see the point here. A .hs file is e.g. just a textual representation of the more abstract notion of a Haskell program/module, too. A .cabal file is just a textual representation of a the abstract notion of a Haskell package description.

yes, .hs AST etc must be implemented. However implementing cabal in addition to that is more work.
 
> Distinct from what?
 from .hs. 
 
> [attention] From whom?
IDE devs
 
>> It  needs to be parsed, updated, validated, formatted.
> This will be the case for whatever is being used, so again: What's the point? It doesn't matter if it's in its own .cabal syntax, in some Haskell-like syntax, JSON, YAML, or even some graphical representation.

if serialized model is used, 
then parsing, update, validation, formatting are no longer necessary


I'm not sure what config format is meant here. If it's stack.yaml, it *must* be somehow different (even if we ignore the surface syntax), because it describes a project, not a single package.

What standard package format are we trying to agree then?
 
 
More problems (distinct file type etc).

What are the actual problems here?

implementing each new file type in IDE is a lot of work. That is, if IDE is trying to do anything with contents of that file. Such as support syncing renamed file to config.
 
 
More formats may follow.

If they are for different purposes, that's OK and is to be expected.

Each new format would need to be implemented. Time spent on implementing new formats is time not spent on implementing any other features. It may take nearly as long as implementing .hs support itself. Is this even thought about?

If this may be avoided, why not at least consider this as an option?
 
 .cabal files describe "how a package looks like" and a stack.yaml describes "how to build a project in a reproducable way", which are different (although related) things. What should "common" mean here?


Standard package file format (as the thread is called). Isn't it about cabal and yaml? 

Anyway, can not a common config file be used for both purposes? If not, can common file type / model be used for both purposes - sharing the common parts of the type structure?

 
Somehow you will always need a concrete representation of abstract notions (call them "models", "ASTs", etc.), otherwise you won't be able to process them. So you will always need to care about some kind of syntax etc., I can't see how using a "Haskell type" will help here. And you will need some semantics for the representation. Even if we used e.g. JSON (or whatever is en vogue at the moment), IDEs will not magically start understanding and supporting Haskell projects.


well if config is expressed in terms of Haskell syntax, implemented .hs support will be enough to support editing these config files. 
Each file type (including .cabal) takes time to implement.

 
Again: What is the actual problem we're trying to solve? I still haven't seen a concrete use case which is hard/impossible with the current state of affairs. Personally, I would e.g. like to see some abstraction facilities to avoid repetition in .cabal files with lots of executables, but I don't care about the concrete syntax (and Cabal's internal model/AST wouldn't be affected, either).

adopting standard package file format. Which could be  addressed even better by adopting typed standard config content.

the problems as I see them are:
  • users need to learn .cabal (.yaml, ...) syntax in addition to .hs syntax
  • IDE need to implement each such syntax on top of .hs. That is, if support / sync of these configs to code files is expected. 

Am I the only one who sees these as issues that need / can be solved?

Also maybe let's be more specific: what is this thread - Standard package file format - all about?

_______________________________________________
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 amindfv
Am 18.09.2016 um 14:03 schrieb Tom Murphy:
> Even just looking at the set of features which is 1:1 betw. YAML and JSON,
> we're essentially just talking about key-value pairs with a couple of
> common types for the values.

This is just as correct as saying that Haskell is about functions - i.e.
superficially correct but mostly beside the point.

For JSON, it's string-to-whatever maps, arrays, and primitive types.

For YAML, it's string-to-whatever maps, arrays, primitive types,
references (so you can have shared and circular data structures), and
arbitrary types (it will use constructors to deserialize).

 > This isn't all .cabal files contain (e.g. see
> hvr's points about conditionals), but if it were true, is it really worth
> changing how Cabal works for a diffferent color bikeshed?

It's bikeshedding if and only if interoperability is irrelevant.
However, in today's world, rejecting interoperability is insanity.
So: no bikeshedding, there are real issues.

It's still quite possible that it's simply not worth it; the cons
associated with changing the buildfile format are pretty weighty after
all, and if the Cabal people say they can fix the known problems with
that format, it's probably a better idea to see what comes of that
before pursuing alternate formats.
_______________________________________________
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 Imants Cekusins
2016-09-18 19:38 GMT+02:00 Imants Cekusins <[hidden email]>:
yes, .hs AST etc must be implemented.

If we're talking about a Haskell tool, it *is* already implemented: Just look into the Cabal project on github. If we're not talking about a Haskell tool and something outside the cabal/hackage/stackage ecosystem, writing an AST and a parser for it will be the least of your problems: The main problem will be how to map cabal's/stack's view what is a package/project to your tool's view. I don't think there's an universally agreed upon notion of what is a package or project, almost every IDE out there has its own view of what those mean, each with its pros and cons (which may be heavily influenced by the package/project programming language, not the language in which the IDE is written).
 
However implementing cabal in addition to that is more work.

Are we talking about parsing/printing here? If yes, there's already work in that direction (making the frontend, i.e. parser/printer/AST, a separate library), at least that's what I understood so far.
  
> Distinct from what?
 from .hs. 

And that's perfectly fine: A project/package description is something fundamentally different than a turing-complete general-purpose programming language. A project/package description should be a mostly static, declarative thing, perhaps with a few conditionals and/or (hygienic) macros or such for convenience/brevity, but not something which can calculate fibonacci numbers or solve differential equations.
 
> [attention] From whom?
IDE devs

Hmmm, so parsing some package/project description is a problem when writing an IDE? I highly doubt that this is relevant compared to the amount of work needed for an average IDE.
 
>> It  needs to be parsed, updated, validated, formatted.
> This will be the case for whatever is being used, so again: What's the point? It doesn't matter if it's in its own .cabal syntax, in some Haskell-like syntax, JSON, YAML, or even some graphical representation.

if serialized model is used, 
then parsing, update, validation, formatting are no longer necessary

Huh? What's a "serialized model" then? Whatever you do, you have to parse/validate/... any description. Even if you choose some subset of Haskell (which is probably a bad idea IMHO because it's either too general or not really Haskell anymore), there has to be *some* parser etc. Where should that come from? Neither Emacs nor VIM can e.g. parse/print Haskell out of the box, VS probably can't either.
 

I'm not sure what config format is meant here. If it's stack.yaml, it *must* be somehow different (even if we ignore the surface syntax), because it describes a project, not a single package.

What standard package format are we trying to agree then?

stack.yaml is not a "package format", so there is nothing to agree on.
  
More problems (distinct file type etc).

What are the actual problems here?

implementing each new file type in IDE is a lot of work. That is, if IDE is trying to do anything with contents of that file. Such as support syncing renamed file to config.
 
 
More formats may follow.

If they are for different purposes, that's OK and is to be expected.

Each new format would need to be implemented. Time spent on implementing new formats is time not spent on implementing any other features. It may take nearly as long as implementing .hs support itself. Is this even thought about?

stack.yaml is not .cabal in a new syntax, there is new functionality. Even if both were e.g. written in YAML, your shiny hypothetical IDE wouldn't suddenly support reproducible multi-package builds out of the box if it couldn't do so before.
 

If this may be avoided, why not at least consider this as an option?
 
 .cabal files describe "how a package looks like" and a stack.yaml describes "how to build a project in a reproducable way", which are different (although related) things. What should "common" mean here?


Standard package file format (as the thread is called). Isn't it about cabal and yaml?

If we are really only talking about a *package* format, there is currently only .cabal and a single format is by definition "standard". :-)
  
well if config is expressed in terms of Haskell syntax, implemented .hs support will be enough to support editing these config files. 
Each file type (including .cabal) takes time to implement.

Again: Where is that ominous ".hs support" coming from?
 
the problems as I see them are:
  • users need to learn .cabal (.yaml, ...) syntax in addition to .hs syntax
As has already been mentioned by others, I *highly* doubt that the .cabal syntax itself poses the slightest problem for anyone. The semantics are a different story, but you have to learn them anyway.
  • IDE need to implement each such syntax on top of .hs. That is, if support / sync of these configs to code files is expected. 
You just update your internal view of the package/project and write out the changed part. With library support for .cabal and YAML files that's trivial.

Am I the only one who sees these as issues that need / can be solved?

Also maybe let's be more specific: what is this thread - Standard package file format - all about?

That's the central question IMHO. :-) The current discussion seems to drift towards: Do we need the current package/project dichotomy or can we throw everything together? (Note that e.g. Visual Studio distinguishes projects and solutions, too, perhaps there's a reason 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

Richard A. O'Keefe
In reply to this post by Harendra Kumar
YAML and TOML are not, strictly speaking, package file formats.
They are *meta-formats*.
There is, by design, nothing about them that ties them in any
way to any kind of package system.
That means that other, even more popular, meta-formats
should be considered.
In particular, while XML and JSON are not by any means
*wonderful*, they are far better known than TOML or even YAML.

On 16/09/16 6:20 PM, Harendra Kumar wrote:
> 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.

If we are talking about *meta-formats*, this is only half
true.  No amount of knowledge about YAML per se will tell
you how to use YAML to describe Haskell packages.  Nor will
it let you choose tools freely if what you want is tools
that understand your *package file format* specifically.
(For example, editors that can drop in handy templates,
or validate a description.)

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

It's not clear what "standard" means in this context.
yaml.org *calls* it "standard", but as the joke puts it,
"CALLING a tail a leg doesn't MAKE it a leg."
XML is a standard: it's managed by a well-known body.
JSON is both an ECMA standard and an Internet RFC.

There are other complaints:
  - that there is no *other* reason for most Haskell programmers
    to be aware of YAML,
  - that stack and hpack do not use "YAML" but an underspecified
    subset of YAML, and that
  - that due to YAML's complexity different implementations tend to
    implement different subsets, meaning less interoperability than
    you'd expect,
  - that the Ruby documentation for its YAML module
    http://ruby-doc.org/stdlib-1.9.3/libdoc/yaml/rdoc/YAML.html
    says "Do not use YAML to load untrusted data.  Doing so is
    unsafe and could allow malicious input to execute arbitrary
    code inside your application."  I must admit I'm surprised.
  - ...

Could I respectfully suggest that the first step in a project
like this is to describe the *semantics* of your package management
information in a language-neutral way?  I know a great language for
describing abstract data types and giving them semantics.  It's
named for some logician, I think his surname was Curry.  (:-)

Seriously, there seems to be an endemic problem with programmers
racing to syntax without thinking over-much about semantics.  It
happened with XML.  It happened again with RDF.  Eventually the
semantics gets patched up, after pointless pain and suffering.

Having nutted out exactly what the issues are with the semantics,
then you can experiment with 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

Richard A. O'Keefe
In reply to this post by Tobias Dammers


On 16/09/16 6:37 PM, Tobias Dammers wrote:
> Another factor in favor of YAML is that it is a superset of JSON,

Here is a simple string in JSON:

"Where's the Golden Fleece?"

Here is the same string in YAML:

--- Where's the Golden Fleece?
...

Superset?  I understand "language X is a superset of language Y"
to mean that if I have a document in language Y it can be correctly
processed by a language X processor.

If you mean that any data value that can be represented in JSON
can be represented (differently!) in YAML, fine, but that's not
the same thing.  There are many textual formats that generalise
JSON.  Heck, even GNUSTEP Property List format does *that*.
(And no, I do not recommend adopting that for anything.)

For that matter, any JSON document can be transcoded with no
loss of structural information into XML and vice versa.  That
doesn't mean that JSON is a superset of XML!

Familiarity with JSON semantics and syntax did not help me AT ALL
when faced with YAML.

Here's another meta-format worthy of consideration.
A *package* is a collection of resources with relationships
between them and relationships linking them to other things
like authors (think Dublin Core).
Is there a standard (genuinely standard) notation specifically
for describing resources and their relationships, with quite a
few tools for not just reading it and writing it but actually
reasoning with it?

Why yes.  It's called RDF.
http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/
   The design of RDF is intended to meet the following goals:

   * having a simple data model
   * having formal semantics and provable inference
   * using an extensible URI-based vocabulary
   * using an XML-based syntax
   * supporting use of XML schema datatypes
   * allowing anyone to make statements about any resource

There is a human-friendly syntax interconvertible with the XML
one, Turtle.
http://www.w3.org/TR/turtle/

Now RDF (whether XML or Turtle) is *not* designed for presenting
single data values.  But that's not really what a package format
wants to do anyway.

Am I seriously recommending RDF (or possibly OWL-DL) as a good
way to describe packages?  I am certainly serious that it should
be CONSIDERED.  And I'm particularly serious about that for two
reasons.

(1) JSON, XML, TOML, and YAML are all about serialising *data values*.
     That's all they do.  Anything beyond that is up to you.
     RDF and OWL are all about describing *relationships* between
     *resources*.  It's worth considering carefully what you want to
     say in a package file format.  If you want to describe
     *relationships*, then something that deals with data values may
     not be the right *kind* of "language".

     Simply jarring people loose from the idea that a "single possibly
     structured data value" language is the ONLY kind of language is
     of value in itself.

(2) JSON, XML, TOML, and YAML are all about serialising *data values*.
     *Single* possibly structured data values.
     That's all they do.  There is no sense in which there is any
     standard way to *combine* data in these forms.
     In contrast, RDF was *invented* to have a way of patching together
     multiple sets of facts from multiple sources.  Given a collection
     of package descriptions in YAML, all you have is a bunch of text
     files; what you do with them is *entirely* up to you.  Given a
     bunch of RDF/XML or RDF/Turtle files, there is a *standard* way
     to write a query (SPARQL) which integrates them.  It becomes
     possible to write consistency-checking queries that can be processed
     by multiple tools.  It becomes possible to ask "if I need these,
     what else do I need?" in a standard way.

     Again, the idea here is to get people thinking that having a
     documented semantics that can be processed by existing description
     logic tools has value, so that something at a higher semantic level
     than YAML or XML might be worth thinking about.

_______________________________________________
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

Richard A. O'Keefe
In reply to this post by Bardur Arantsson-2


On 17/09/16 4:47 PM, 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).

It's a long sad story.  The ECMA standard exists for largely politcal
reasons.  The RFC is the "active" one.

JSON is a textbook example of "syntax-first".

_______________________________________________
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

Haskell - Haskell-Cafe mailing list
In reply to this post by Richard A. O'Keefe
Here's another meta-format worthy of consideration.
A *package* is a collection of resources with relationships
between them and relationships linking them to other things
like authors (think Dublin Core).

I really like this approach of thinking about packages. Apart from the obvious benefits of some concrete format like RDF (e.g. mixing with OpenDocument files), this way of thinking could open the door to some interesting ways to see existing problems. As an extension, those perspectives might lead to fruitful experiments. (After all Haskell was originally created as an language to be experimented with - so why not expand that to packaging?) Just two ideas off the top of my head:

  • One could proclaim that part of the orphan-instances-/forced-imports-ugliness stems from the fact that instances formulate a kind of relationship between declarations and are thus fundamentally different from these other declarations. So one might want to experiment with separating both by adapting the package format and see what benefits or drawbacks that brings.

  • Similarly one could proclaim that one of the things that makes the dependency purgatory difficult to navigate is that version numbers alone do not encode enough information - but a finer grained analysis might. E.g. imagine you could say "I have tested with package X in version 0.3.4. But feel free to substitute any other version as long as functions A and B haven't changed, because these are the only ones I use." There are obvious problems with such an approach, but I propose that we can only find a way forward by experimenting - including experimenting with such details of the relationship.

Note that I'm not saying that experiments like these are impossible with a format like cabal or yaml. All I'm saying is that thinking of packages as resources in relationships makes it easier to think in these ways. An appropriate representation could be both a tool to shape our thoughts and a tool that, being specialized for the representation of relationships, makes it easier to incorporate experimental features without breaking the ecosystem. It will probably be unavoidable to "inject" some code into the solver for a specific package for such experiments, but I hope that understanding the details will make it possible to see ways how to do that in safe and portable ways.


MarLinn


_______________________________________________
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

Christopher Allen
While y'all are going 'round about this, an argument parser in Rust
has its own blog, api docs, twitter account, github, and tutorial
videos.

https://clap.rs/


And it supports YAML in addition to plain old Rust code.
_______________________________________________
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

Richard A. O'Keefe
> While y'all are going 'round about this, an argument parser in Rust
> has its own blog, api docs, twitter account, github, and tutorial
> videos.
>
> https://clap.rs/

An *argument parser*?
Visits web page incredulously.
Great balls of fire, it's true.

I really don't want to use an argument parser that requires that
much documentation.  Life is too short.






_______________________________________________
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 Richard A. O'Keefe
Am 19.09.2016 um 02:12 schrieb Richard A. O'Keefe:

>
>
> On 16/09/16 6:37 PM, Tobias Dammers wrote:
>> Another factor in favor of YAML is that it is a superset of JSON,
>
> Here is a simple string in JSON:
>
> "Where's the Golden Fleece?"
>
> Here is the same string in YAML:
>
> --- Where's the Golden Fleece?
> ...
>
> Superset?

Yes. The original string is also valid in YAML if used in the position
where JSON allows a string.

> If you mean that any data value that can be represented in JSON
> can be represented (differently!) in YAML, fine, but that's not
> the same thing.

Sure, but any valid JSON is also valid YAML.
Modulo some exotic exceptions for valid-but-useless and
valid-but-probably-not-what-the-sender-intended JSON.

> Familiarity with JSON semantics and syntax did not help me AT ALL
> when faced with YAML.

Sure, YAML is a massive superset.
The advantage is more in interoperability - you can hook a YAML parser
to JSON-outputting processes and expect that it will "just work", so you
don't have to worry about syntax, so you don't need separate frontends
for YAML and JSON for your webservice.

> Am I seriously recommending RDF (or possibly OWL-DL) as a good
> way to describe packages?  I am certainly serious that it should
> be CONSIDERED.

+1

> (1) JSON, XML, TOML, and YAML are all about serialising *data values*.
>     That's all they do.  Anything beyond that is up to you.
>     RDF and OWL are all about describing *relationships* between
>     *resources*.  It's worth considering carefully what you want to
>     say in a package file format.  If you want to describe
>     *relationships*, then something that deals with data values may
>     not be the right *kind* of "language".
>
>     Simply jarring people loose from the idea that a "single possibly
>     structured data value" language is the ONLY kind of language is
>     of value in itself.

It does have its advantages.
That's why everybody is using XML these days, after all. Even though XML
does have some pretty horrible properties (too much noise being the most
prominent).

> (2) JSON, XML, TOML, and YAML are all about serialising *data values*.
>     *Single* possibly structured data values.
>     That's all they do.  There is no sense in which there is any
>     standard way to *combine* data in these forms.

Yes, that's supposed to live at the semantic level, i.e. in the types.
For JSON and TOML that's a serious restriction.
In XML and YAML, you can keep type information (better standardization
for that in YAML than in XML), so you can stick user-defined semantics
into the serialization format if you want to.

I.e. you can achieve RDF in XML or YAML by writing types that handle
combinability or anything else that you want, these things aren't tied
into the language.

It is still possible that RDF is more convenient :-)
_______________________________________________
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

Evan Laforge
In reply to this post by Harendra Kumar
I haven't totally followed this whole thread, so apologies if this
isn't entirely relevant, but I use shake for building, and cabal for
dependencies.  The shakefile has the list of packages and required
versions, and generates the .cabal file, which is used with
--only-dependencies to get dependencies.

I think it works well.  I can't do builds in cabal anyway since it
can't handle anything complicated, but even if I had a simple build
I'd prefer shake since it's so much nicer.  Since it's in haskell,
it's flexible but can't be analyzed, though I can't think of why you'd
want to analyze it.

Meanwhile, cabal is just fine at expressing packages and versions, and
is basically just a way to tell cabal-install what to download and
install.  Since I generate it, I don't care much about the format, but
the existing one seems perfectly adequate.
_______________________________________________
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