- Haskell-Cafe - Haskell.org

help wanted: hledger
by Simon Michael 17 Sep '16

17 Sep '16

Hey all, I believe hledger (http://hledger.org) is a useful project, with potential to be much better. I have more ideas and know-how than free time. By now the project has a fairly large surface area, such that I'm often avoiding it when I have only small chunks of time to work on something. So I'm putting out the call for help! I'm grateful for the occasional contributions over the last 9 years, and I would welcome more collaborators to share the work. That sounds appealing, right ? Really, this is a fun project, since you can use it to save money and time and build your wealth-accumulation skills. And as an active contributor, you will have access to free tutoring from a 9y haskeller, 20y consultant and FOSS developer, and 30y coder (that's me). Here are some particular areas needing help: - Release 0.28 (or should it be 1.0 ?) has been pending for a long time, partly because hledger, hledger-ui, hledger-web & hledger-api are released together. This is the number one priority at the moment. Also: - Integrate John Wiegley's ledger4 code as an additional parser, increasing our compatibility with Ledger, making hledger features more easily accessible to Ledger users. - Website beautification and marketing in general. - Contribute, solicit or raise funding, so we can sponsor developers/designers/minions, set meaningful issue bounties, etc. - UIs/integration for mobile/small-screen devices. - More import/export formats, easier migration to and from other tools. I hope you'll check out hledger and get involved. http://hledger.org -> Contribute Best! -Simon

1 0

Re: [Haskell-cafe] Very _very_ slow compiles on Windows 10
by Nicu Ionita 17 Sep '16

17 Sep '16

Sorry, I forgot to answer to all... ------ Originalnachricht ------ Von: "Nicu Ionita" <nicu.ionita(a)acons.at> An: "Malcolm Wallace" <malcolm.wallace(a)me.com> Gesendet: 17.09.2016 09:12:30 Betreff: Re[2]: [Haskell-cafe] Very _very_ slow compiles on Windows 10 >Oh, this could be a good hint! I don't have other protection except >windows defender, which is own Windows AV. (Reviews suggest that this >should be enough, altough on other PC - not with Windows 10 - I use >different AVs) But maybe the Windows own AV exhibits the same >behaviour. I will check this, thanks! >Nicu > >------ Originalnachricht ------ >Von: "Malcolm Wallace" <malcolm.wallace(a)me.com> >An: "Nicu Ionita" <nicu.ionita(a)acons.at> >Cc: "haskell-cafe(a)haskell.org" <haskell-cafe(a)haskell.org> >Gesendet: 17.09.2016 08:44:30 >Betreff: Re: [Haskell-cafe] Very _very_ slow compiles on Windows 10 > >>Do you have Symantec Endpoint Protection or similar antivirus? We >>found that under certain paranoid settings, even "ghc --version" >>took upwards of seven seconds, and compilation was slowed by a couple >>of orders of magnitude. We think the AV was scanning the (large) >>compiler binary, plus any DLLs it loads, plus the source, interface, >>and object files read and generated, On every invocation. Linking was >>absolutely dog slow. We also think the AV was deliberately throttled >>to never use more than 10% of CPU time, to avoid being noticeable to >>the user. >> >>It is possible that there are AV settings you can tweak to avoid the >>paranoia, and trust the compiler, and any other file that has already >>been scanned once. >> >> Regards, >> Malcolm (iPhone) >> >>On 17 Sep 2016, at 07:04, Nicu Ionita <nicu.ionita(a)acons.at> wrote: >> >>No virtualisation, it is a dual boot maschine. >>1 CPU would be good :-) In my case it is a very small fraction of it. >>Nicu >> >>------ Originalnachricht ------ >>Von: "A.M." <agentm(a)themactionfaction.com> >>An: haskell-cafe(a)haskell.org >>Gesendet: 17.09.2016 03:20:38 >>Betreff: Re: [Haskell-cafe] Very _very_ slow compiles on Windows 10 >> >>>On 09/16/2016 06:10 PM, Nicu Ionita wrote: >>>> Is anybody else experiencing really slow compilations with GHC >>>>7.10.2 on >>>> Windows 10? >>>> >>>> I use stack to compile the project and run it under a mingw64 >>>> environment provided by Github bash. The CPU usage is very low all >>>>the >>>> time (meaning: GHC does barely use the CPU). On same computer with >>>> Ubuntu 16.04 it just compiles normally, but under Windows it is for >>>>sure >>>> 10x slower, maybe even more. >>> >>>Are you using virtualization? I see the same thing under virtualbox >>>on >>>Ubuntu. Specifically, even after allocating 12 real CPUs to the VM, I >>>never see stack-invoked ghc use more than one CPU. On rare occasions, >>>the linker phase hangs. I have confirmed that ghc reports 12 >>>capabilities. >>> >>>I'm just glad that Windows is not my primary development platform; >>>it's >>>entirely possible that virtualization is the cause. VirtualBox is not >>>known for being a speed demon, but the compilation speed is indeed >>>embarrassing. >>> >>>Cheers, >>>M >>> >>> >>_______________________________________________ >>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.

1 1

Looking for a source level debugger
by Nikita Karetnikov 17 Sep '16

17 Sep '16

Originally sent this to /r/haskell, but it doesn't show up there for some reason, so re-sending here. Is anyone aware of a source level debugger that can be used with GHC? That is, something integrated into an editor (as a plugin, perhaps) that can highlight the line being executed, show locals, etc. (Think of WinDbg without the registers window.) I'm mostly interested in something that can work on a Linux-based system, but solutions for other platforms are welcome, too! I've heard that Sublime can run on 3 OSes, is there a solution for it, for instance? P.S. I'm not looking for opinions on whether you think a debugger is necessary or not when programming in Haskell.

3 2

ANN: stack-1.2.0
by Emanuel Borsboom 17 Sep '16

17 Sep '16

See https://haskellstack.org for installation and upgrade instructions. Release notes: * On many Un*x systems, Stack can now be installed with a simple one-liner: wget -qO- https://get.haskellstack.org/ | sh * The fix for [#2175](https://github.com/commercialhaskell/stack/issues/2175) entails that stack must perform a full clone of a large Git repo of Hackage meta-information. The total download size is about 200 MB. Please be aware of this when upgrading your stack installation. * If you use Mac OS X, you may want to delay upgrading to macOS Sierra as there are reports of GHC panics when building some packages (including Stack itself). See [#2577]( https://github.com/commercialhaskell/stack/issues/2577) * This version of Stack does not build on ARM or PowerPC systems (see [store#37](https://github.com/fpco/store/issues/37)) Please stay with version 1.1.2 for now on those architectures. This will be rectified soon! * We are now releasing a [statically linked Stack binary for 64-bit Linux]( https://www.stackage.org/stack/linux-x86_64-static) Please try it and let us know if you run into any trouble on your platform. * We are planning some changes to our Linux releases, including dropping our Ubuntu, Debian, CentOS, and Fedora package repositories and switching to statically linked binaries. We would value your feedback in [#2534](https://github.com/commercialhaskell/stack/issues/2534). Major changes: * Add `stack hoogle` command. [#55](https://github.com/commercialhaskell/stack/issues/55) * Support for absolute file path in `url` field of `setup-info` or `--ghc-bindist` * Add support for rendering GHCi scripts targeting different GHCi like applications [#2457](https://github.com/commercialhaskell/stack/pull/2457) Behavior changes: * Remove `stack ide start` and `stack ide load-targets` commands. [#2178](https://github.com/commercialhaskell/stack/issues/2178) * Support .buildinfo files in `stack ghci`. [#2242](https://github.com/commercialhaskell/stack/pull/2242) * Support -ferror-spans syntax in GHC error messages. * Avoid unpacking ghc to `/tmp` [#996](https://github.com/commercialhaskell/stack/issues/996) * The Linux `gmp4` GHC bindist is no longer considered a full-fledged GHC variant and can no longer be specified using the `ghc-variant` option, and instead is treated more like a slightly different platform. Other enhancements: * Use the `store` package for binary serialization of most caches. * Only require minor version match for Docker stack exe. This way, we can make patch releases for version bounds and similar build issues without needing to upload new binaries for Docker. * Stack/Nix: Passes the right ghc derivation as an argument to the `shell.nix` when a custom `shell.nix` is used See [#2243](https://github.com/commercialhaskell/stack/issues/2243) * Stack/Nix: Sets `LD_LIBRARY_PATH` so packages using C libs for Template Haskell can work (See _e.g._ [this HaskellR issue]( https://github.com/tweag/HaskellR/issues/253)) * Parse CLI arguments and configuration files into less permissive types, improving error messages for bad inputs. [#2267](https://github.com/commercialhaskell/stack/issues/2267) * Add the ability to explictly specify a gcc executable. [#593](https://github.com/commercialhaskell/stack/issues/593) * Nix: No longer uses LTS mirroring in nixpkgs. Gives to nix-shell a derivation like `haskell.compiler.ghc801` See [#2259](https://github.com/commercialhaskell/stack/issues/2259) * Perform some subprocesses during setup concurrently, slightly speeding up most commands. [#2346](https://github.com/commercialhaskell/stack/pull/2346) * `stack setup` no longer unpacks to the system temp dir on posix systems. [#996](https://github.com/commercialhaskell/stack/issues/996) * `stack setup` detects libtinfo6 and ncurses6 and can download alternate GHC bindists [#257](https://github.com/commercialhaskell/stack/issues/257) [#2302](https://github.com/commercialhaskell/stack/issues/2302). * `stack setup` detects Linux ARMv7 downloads appropriate GHC bindist [#2103](https://github.com/commercialhaskell/stack/issues/2103) * Custom `stack` binaries list dependency versions in output for `--version`. See [#2222](https://github.com/commercialhaskell/stack/issues/2222) and [#2450](https://github.com/commercialhaskell/stack/issues/2450). * Use a pretty printer to output dependency resolution errors. [#1912](https://github.com/commercialhaskell/stack/issues/1912) * Remove the `--os` flag [#2227](https://github.com/commercialhaskell/stack/issues/2227) * Add 'netbase' and 'ca-certificates' as dependency for .deb packages. [#2293](https://github.com/commercialhaskell/stack/issues/2293). * Add `stack ide targets` command. * Enhance debug logging with subprocess timings. * Pretty-print YAML parse errors [#2374](https://github.com/commercialhaskell/stack/issues/2374) * Clarify confusing `stack setup` output [#2314](https://github.com/commercialhaskell/stack/issues/2314) * Delete `Stack.Types` multimodule to improve build times [#2405](https://github.com/commercialhaskell/stack/issues/2405) * Remove spurious newlines in build logs [#2418](https://github.com/commercialhaskell/stack/issues/2418) * Interpreter: Provide a way to hide implicit packages [#1208](https://github.com/commercialhaskell/stack/issues/1208) * Check executability in exec lookup [#2489](https://github.com/commercialhaskell/stack/issues/2489) Bug fixes: * Fix cabal warning about use of a deprecated cabal flag [#2350](https://github.com/commercialhaskell/stack/issues/2350) * Support most executable extensions on Windows [#2225](https://github.com/commercialhaskell/stack/issues/2225) * Detect resolver change in `stack solver` [#2252](https://github.com/commercialhaskell/stack/issues/2252) * Fix a bug in docker image creation where the wrong base image was selected [#2376](https://github.com/commercialhaskell/stack/issues/2376) * Ignore special entries when unpacking tarballs [#2361](https://github.com/commercialhaskell/stack/issues/2361) * Fixes src directory pollution of `style.css` and `highlight.js` with GHC 8's haddock [#2429](https://github.com/commercialhaskell/stack/issues/2429) * Handle filepaths with spaces in `stack ghci` [#2266](https://github.com/commercialhaskell/stack/issues/2266) * Apply ghc-options to snapshot packages [#2289](https://github.com/commercialhaskell/stack/issues/2289) * stack sdist: Fix timestamp in tarball [#2394](https://github.com/commercialhaskell/stack/pull/2394) * Allow global Stack arguments with a script [#2316](https://github.com/commercialhaskell/stack/issues/2316) * Inconsistency between ToJSON and FromJSON instances of PackageLocation [#2412](https://github.com/commercialhaskell/stack/pull/2412) * Perform Unicode normalization on filepaths [#1810](https://github.com/commercialhaskell/stack/issues/1810) * Solver: always keep ghc wired-in as hard constraints [#2453](https://github.com/commercialhaskell/stack/issues/2453) * Support OpenBSD's tar where possible, require GNU tar for xz support [#2283](https://github.com/commercialhaskell/stack/issues/2283) * Fix using --coverage with Cabal-1.24 [#2424](https://github.com/commercialhaskell/stack/issues/2424) * When marking exe installed, remove old version [#2373](https://github.com/commercialhaskell/stack/issues/2373) * Stop truncating all-cabal-hashes git repo [#2175](https://github.com/commercialhaskell/stack/issues/2175) * Handle non-ASCII filenames on Windows [#2491](https://github.com/commercialhaskell/stack/issues/2491) * Avoid using multiple versions of a package in script interpreter by passing package-id to ghc/runghc [#1957](https://github.com/commercialhaskell/stack/issues/1957) * Only pre-load compiler version when using nix integration [#2459](https://github.com/commercialhaskell/stack/issues/2459) * Solver: parse cabal errors also on Windows [#2502](https://github.com/commercialhaskell/stack/issues/2502) * Allow exec and ghci commands in interpreter mode. Scripts can now automatically open in the repl by using `exec ghci` instead of `runghc` in the shebang command. [#2510](https://github.com/commercialhaskell/stack/issues/2510) * Now consider a package to be dirty when an extra-source-file is changed. See [#2040](https://github.com/commercialhaskell/stack/issues/2040) Thanks to all our contributors for this release: * Aaron Friel * Andrew Cowie * AndrewRademacher * Anton Felix Lorenzen * Brian McKenna * Chris Done * Dan Aloni * danald * Daniel Casanueva * Denis * Denis Kasak * Emanuel Borsboom * erewok * Gabor Greif * Gurkenglas * Harendra Kumar * hesiod * Judah Jacobson * Khan Thompson * Mathieu Boespflug * Michael Sloan * Michael Snoyman * Mohit Agarwal * Moritz Angermann * Oleg Grenrus * Paolo G. Giarrusso * Philipp Kant * Ryan Desfosses * Sid Kapur * Sidharth Kapur * Simon Jakobi * Tim Dysinger * Tim Düsterhus * Tobias Markus * YPares * Yuriy Syrovetskiy * Yves Parès (Ywen) * ___

2 2

Re: [Haskell-cafe] Standard package file format
by Chris Kahn 17 Sep '16

17 Sep '16

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 <toad3k(a)gmail.com> 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 > <yann.esposito(a)gmail.com> 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. >

8 8

Issue with building executables using Cabal on Travis
by Geraldus 17 Sep '16

17 Sep '16

Hi Café! Recently we added an executable section to our Transient-Universe package and now Travis cabal builds always failing. The error message is: In-place registering transient-universe-0.3.4... Preprocessing executable 'monitorService' for transient-universe-0.3.4... [1 of 1] Compiling Main ( src/server/Transient/Monitor/Services/MonitorService.hs, dist/build/monitorService/monitorService-tmp/Main.o ) Linking dist/build/monitorService/monitorService ... No errors or warnings could be found in the package. Re-configuring with test suites enabled. If this fails, please run configure manually. Resolving dependencies... Configuring transient-universe-0.3.4... Package has no buildable test suites. Building source dist for transient-universe-0.3.4... Preprocessing library transient-universe-0.3.4... Preprocessing executable 'monitorService' for transient-universe-0.3.4... cabal: src/client/Transient/Move/Services/MonitorService.hs: does not exist Installing library in /home/travis/.cabal/lib/x86_64-linux-ghc-7.10.2/transient-universe-0.3.4-2OztnD6ZM7W2H3eixltaJX Installing executable(s) in /home/travis/.cabal/bin Warning: The directory /home/travis/.cabal/bin is not in the system search path. cabal: The file does not exist 'transient-universe-0.3.4.tar.gz'. (Full log — https://travis-ci.org/agocorona/transient-universe/jobs/160441018, you can see that other Cabal builds fail with same error, however all Stack builds are fine). This is a chunk of cabal file: extra-source-files: src/client/Transient/Move/Services/MonitorService.hs src/server/Transient/Move/Services/MonitorService.hs executable monitorService build-depends: base >4 && <5 if !impl(ghcjs >=0.1) hs-source-dirs: src/server/Transient/Monitor/Services build-depends: transformers , transient >=0.4.4 , transient-universe else hs-source-dirs: src/client/Transient/Monitor/Services main-is: MonitorService.hs default-language: Haskell2010 ghc-options: -threaded -rtsopts Have anyone faced similar issue?

2 2

Re: [Haskell-cafe] Very _very_ slow compiles on Windows 10
by Phyx 17 Sep '16

17 Sep '16

> Is anybody else experiencing really slow compilations with GHC 7.10.2 on > Windows 10? The problem comes down to these lines https://github.com/ghc/ghc/blob/e5ecb2010514405ac1b9b1285a8a65c00a5fd4e0/li… The issue is that the entire Windows support in GHC Is mostly provided through POSIX support. Windows however isn't a POSIX system, and these APIs were implemented for compatibility and not performance. This is the reason why any I/O operation on GHC Windows will be significantly slower. This is the same reason why Console I/O is also much slower. Why Unicode support is a bit wonky etc. GHC Is currently just not using native Windows syscalls, because by large most developers of GHC don't use Windows. There are other issues (but I won't go in detail on the user list). We are trying to fix this, there are multiple tickets open such as https://ghc.haskell.org/trac/ghc/ticket/11394 but it's a big task and there are very limited resources so priority is given to things currently broken rather than just slow.

1 0

Very _very_ slow compiles on Windows 10
by Nicu Ionita 17 Sep '16

17 Sep '16

Is anybody else experiencing really slow compilations with GHC 7.10.2 on Windows 10? I use stack to compile the project and run it under a mingw64 environment provided by Github bash. The CPU usage is very low all the time (meaning: GHC does barely use the CPU). On same computer with Ubuntu 16.04 it just compiles normally, but under Windows it is for sure 10x slower, maybe even more. Nicu

3 3

Re: [Haskell-cafe] [Haskell-community] Standard package file format
by Paolo Giarrusso 16 Sep '16

16 Sep '16

On 16 September 2016 at 12:13, Patrick Pelletier <ppelleti(a)funwithsoftware.org> wrote: > On 9/16/16 2:36 AM, Paolo Giarrusso wrote: >> >> (Resending from right address) >> >> We're talking about *three* options: >> 1. syntax for pure Haskell values, which I'll call HSON (Haskell >> jSON). That's just an alternative to YAML/TOML/... That would need >> extensions to allow omitting optional fields entirely. >> 2. a pure Haskell embedded domain-specific language (EDSL) that simply >> generates cabal description records (GenericPackageDescription >> values). That would allow abstraction over some patterns but not much >> more. But that alone is already an argument for EDSLs—the one Harendra >> already presented. >> 3. a Haskell embedded domain-specific language (EDSL) designed for an >> extensible build tool, like Clojure's (apparently), SBT for Scala or >> many others. That would potentially be a rabbit hole leading to a >> rather *different* tool—with a different package format to boot. That >> can't work as long as all libraries have to be built using the same >> tool. But stack and cabal are really about how to manage package >> databases/GHC/external environments, while extensible build tools are >> about (a more powerful form) of writing custom setup scripts. I >> suspect some extensions might be easier if more of the actual building >> was done by the setup script, but I'm not sure. > > > Options 2 and 3 both require running Haskell code at build time. > But if all packages had to use the new EDSL, then cross-compilation would essentially become impossible. "All packages migrate to new format" doesn't seem really a plausible option, as I already hinted in the text you quote. There are multiple JVM build tools because they're interoperable (like cabal-install and Stack): each library picks its own build tool, but they can still be linked together. Hpack generates cabal files, stack reuses cabal or hpack files. In principle, option 2 just needs a non-cross-compiled program to produce a package description—say by producing a cabal file. You just need to runghc it, either via ghci or by compiling and running a binary. Option 3 can be trickier depending on details, but the as long as you account for cross-compilation in the design it should be doable. For Template Haskell the problem is deeper (see http://blog.ezyang.com/2016/07/what-template-haskell-gets-wrong-and-racket-…) so let's *not* use it here. -- Paolo G. Giarrusso - Ph.D. Student, Tübingen University http://ps.informatik.uni-tuebingen.de/team/giarrusso/

2 3

[Haskell-community] Standard package file format
by Paolo Giarrusso 16 Sep '16

16 Sep '16

(Resending from right address) We're talking about *three* options: 1. syntax for pure Haskell values, which I'll call HSON (Haskell jSON). That's just an alternative to YAML/TOML/... That would need extensions to allow omitting optional fields entirely. 2. a pure Haskell embedded domain-specific language (EDSL) that simply generates cabal description records (GenericPackageDescription values). That would allow abstraction over some patterns but not much more. But that alone is already an argument for EDSLs—the one Harendra already presented. 3. a Haskell embedded domain-specific language (EDSL) designed for an extensible build tool, like Clojure's (apparently), SBT for Scala or many others. That would potentially be a rabbit hole leading to a rather *different* tool—with a different package format to boot. That can't work as long as all libraries have to be built using the same tool. But stack and cabal are really about how to manage package databases/GHC/external environments, while extensible build tools are about (a more powerful form) of writing custom setup scripts. I suspect some extensions might be easier if more of the actual building was done by the setup script, but I'm not sure. On 16 September 2016 at 10:57, yogsototh <yann.esposito(a)gmail.com> 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-community mailing list > Haskell-community(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community > -- Paolo G. Giarrusso - Ph.D. Student, Tübingen University http://ps.informatik.uni-tuebingen.de/team/giarrusso/

2 1