from:"Niklas"

On Fri 06 Sep 2013 22:13:58 JST, Yuri de Wit wrote:
 The right solution, imho, is to review these dependencies and move
 the low level ones out into a separate package that is shared by both
 ghc and cabal and that will rarely change. The direct side effect of
 this is that ghc would not be tied directly to a specific cabal
 version and you would not have to deal with this issue.

This sounds very right to me.

There should be something that describes what a GHC package database 
is, as minimally as possible (perhaps even only the data types).

In the end, ghc is the defining side here - cabal is only a tool that 
builds on top of these definitions.

Then ghc could finally be decoupled from Cabal.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] GHC API + Cabal API + Cabal version checks: is there a way out?

On Fri 06 Sep 2013 22:52:40 JST, Roman Cheplyaka wrote:
 The right solution for Cabal would be not to know anything about the
 GHC's database format at all.

 GHC and cabal communicate via a command line interface (`ghc-pkg dump`
 in our direction; `ghc-pkg update` in the other). So it would suffice to
 have a library which implements parsing and printing of the package
 description, and have that library shared between GHC and Cabal.

You are right. This is better.

GHC's dependency on cabal seems to actually be quite minimal!

I did a quick grep:

% grep -rI import Distribution --include *.hs --include *.lhs* . 
| grep -v libraries/ | grep -v Setup.hs | grep -v Setup.lhs | grep -v 
utils/haddock
./utils/ghc-cabal/Main.hs:import Distribution.PackageDescription
./utils/ghc-cabal/Main.hs:import Distribution.PackageDescription.Check 
hiding (doesFileExist)
./utils/ghc-cabal/Main.hs:import 
Distribution.PackageDescription.Configuration
./utils/ghc-cabal/Main.hs:import Distribution.PackageDescription.Parse
./utils/ghc-cabal/Main.hs:import Distribution.System
./utils/ghc-cabal/Main.hs:import Distribution.Simple
./utils/ghc-cabal/Main.hs:import Distribution.Simple.Configure
./utils/ghc-cabal/Main.hs:import Distribution.Simple.LocalBuildInfo
./utils/ghc-cabal/Main.hs:import Distribution.Simple.Program
./utils/ghc-cabal/Main.hs:import Distribution.Simple.Program.HcPkg
./utils/ghc-cabal/Main.hs:import Distribution.Simple.Utils 
(defaultPackageDesc, writeFileAtomic, toUTF8)
./utils/ghc-cabal/Main.hs:import Distribution.Simple.Build 
(writeAutogenFiles)
./utils/ghc-cabal/Main.hs:import Distribution.Simple.Register
./utils/ghc-cabal/Main.hs:import Distribution.Text
./utils/ghc-cabal/Main.hs:import Distribution.Verbosity
./utils/ghctags/Main.hs:import Distribution.Simple.GHC ( 
componentGhcOptions )
./utils/ghctags/Main.hs:import Distribution.Simple.Configure ( 
getPersistBuildConfig )
./utils/ghctags/Main.hs:import Distribution.Simple.Compiler ( 
compilerVersion )
./utils/ghctags/Main.hs:import Distribution.Simple.Program.GHC ( 
renderGhcOptions )
./utils/ghctags/Main.hs:import Distribution.PackageDescription ( 
library, libBuildInfo )
./utils/ghctags/Main.hs:import Distribution.Simple.LocalBuildInfo
./utils/ghc-pkg/Main.hs:import 
Distribution.InstalledPackageInfo.Binary()
./utils/ghc-pkg/Main.hs:import Distribution.ModuleName hiding (main)
./utils/ghc-pkg/Main.hs:import Distribution.InstalledPackageInfo
./utils/ghc-pkg/Main.hs:import Distribution.Compat.ReadP
./utils/ghc-pkg/Main.hs:import Distribution.ParseUtils
./utils/ghc-pkg/Main.hs:import Distribution.Package hiding (depends)
./utils/ghc-pkg/Main.hs:import Distribution.Text
./utils/ghc-pkg/Main.hs:import Distribution.Version
./compiler/ghci/Linker.lhs:import Distribution.Package hiding (depends, 
PackageId)
./compiler/main/Packages.lhs:import Distribution.InstalledPackageInfo
./compiler/main/Packages.lhs:import 
Distribution.InstalledPackageInfo.Binary
./compiler/main/Packages.lhs:import Distribution.Package hiding 
(PackageId,depends)
./compiler/main/PackageConfig.hs:import 
Distribution.InstalledPackageInfo
./compiler/main/PackageConfig.hs:import Distribution.ModuleName
./compiler/main/PackageConfig.hs:import Distribution.Package hiding 
(PackageId)
./compiler/main/PackageConfig.hs:import Distribution.Text
./compiler/main/PackageConfig.hs:import Distribution.Version
./compiler/main/Finder.lhs:import Distribution.Text
./compiler/main/Finder.lhs:import Distribution.Package hiding 
(PackageId)

As you can see, there are only 4 files in ghc itself that depend on 
Cabal:

./compiler/ghci/Linker.lhs
./compiler/main/Packages.lhs
./compiler/main/PackageConfig.hs
./compiler/main/Finder.lhs

(plus 1 file for ghc-pkg: ./utils/ghc-pkg/Main.hs)

The ones in GHC core seem to rely only on quite basic data types.

 From this, I would boldly claim that people have spent more time making 
the GHC build system work with this Cabal dependency than it would take 
stripping it off!

(In fact, I would try to do this right now if the GHC build system 
wouldn't take so long to compile even the smallest changes ...)

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] GHC API + Cabal API + Cabal version checks: is there a way out?

It looks to me that technically it should be easy to split off the part
required by GHC.

Maybe somebody could just try that (currently it does not seem to take
longer than a few hours) so that we have some basic proposal and momentum.

On 07/09/13 00:04, JP Moresmau wrote:
 Oh, I'm happy to help as well if somebody is needed to do the change

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] GHC API + Cabal API + Cabal version checks: is there a way out?

We just had a short discussion on #ghc, I copy-paste:

http://lpaste.net/92639

dcoutts_: nh2: Cabal does not depend on the ghc-pkg format. Cabal
specifies a compiler-independent package registration format. GHC uses
it in its external interface (and internally too). It uses the Cabal lib
for the parser+printer because it's easier than making its own and
keeping up with spec changes..
dcoutts_: type+parser+printer
nh2: dcoutts_: would it still not be easier to make this package
database specification a separate thing that both ghc and cabal can
depend on? It seems to me that this would be much less a moving target
than Cabal-the-build-system is
dcoutts_: nh2: what does make sense is to split the Cabal lib into the
Distribution.* bits and the Distribution.Simple.* bits
dcoutts_: nh2: it's not a natural split
hvr: nh2: btw, a related thread:
http://www.haskell.org/pipermail/ghc-devs/2013-March/000800.html
dcoutts_: nh2: there's a lot of types shared between the .cabal format
and the InstalledPackageInfo type
dcoutts_: as well as parser + printer infrastructure
dcoutts_: nh2: it makes sense to keep that all together, that's the
Distribution.* stuff
dcoutts_: as I said, what does make sense to split (it's been
deliberately kept mostly-separate) is the Distribution.Simple.* part
dcoutts_: nh2: and we need a parser for that part, that's the dependency
that's annoying
thoughtpolice: so yes, i'm going to look into it today if at all possible
nh2: dcoutts_: that makes sense. ghc does not depend on
Distribution.PackageDescription either, right?
dcoutts_: nh2: right, it doesn't need the source package type
(PackageDescription), just the installed package type (InstalledPackageInfo)
dcoutts_: nh2: but splitting these into different packages would not buy
us much and it's not a natural split
nh2: leaving away Distribution.Simple.*, the remaining part is already
so small that it indeed looks like a small enough interface
dcoutts_: nh2: it'd only help JP M if the remaining part (lets call it
cabal-build-simple) could build with an earlier core part (lets call it
cabal-lib) (in his request in
http://www.haskell.org/pipermail/haskell-cafe/2013-September/108746.html)
dcoutts_: nh2: and doesn't help me with my parser problems, we still
cannot depend on a decent parser combinator lib
dcoutts_: still have to use the crappy ReadP
nh2: dcoutts_: Distribution.PackageDescription is the .cabal file format
itself, right? Not sure if that should be part of the package DB spec,
it changes more often and ghc can't make use of it
nh2: why is it that you cannot depend on something better?
dcoutts_: nh2: because ghc cannot depend on parsec easily
dcoutts_: because it pulls in too many other things
dcoutts_: the ghc devs objected to my suggestion
dcoutts_: nh2: that's true but what does it really buy us if they're in
separate packages? We still cannot guarantee to support JP M's request
dcoutts_: e.g. in the switch to 1.18, there have been enough changes
that we'd need the latest version of the InstalledPackageInfo
hvr: dcoutts_: ...seems you have to explain that again everytime
somebody brings it up =)
nh2: dcoutts_: but do I not understand it right that if you put
PackageDescription not into cabal-lib and only in Cabal, Cabal could
actually depend on a proper parser since GHC doesn't depend on it any more?
dcoutts_: nh2: it's not a monolithic parser
dcoutts_: nh2: we have that Text class
dcoutts_: with the combinator parsers for all the various types used in
.cabal and installed package files
dcoutts_: these types + parser/printer infrastructure are shared between
the source and installed package files
dcoutts_: so even if we split it, we still have the problem of needing a
parser lib
lemao: dcoutts_: I hear you wrt to the difficulties and mixed results of
splitting Distribution.Simple at the same time that this GHC dependency
on cabal is really problematic for all the reasons already discussed
dcoutts_: lemao: I don't think splitting it would fix that
lemao: dcoutts_: yes, I hear you. Maybe the right solution here is to
have GHC own their own internal package info impl so Cabal and GHC can
go their separate ways
dcoutts_: you'd still have ghc depending on this smaller part, and
Cabal/cabal-install would still depend on (usually) the latest version
of that
dcoutts_: lemao: but that's also not satisfactory (for cabal-lib to be a
private dep of ghc) because ghc api exposes the InstalledPackageInfo type
dcoutts_: it's not a private dependency of the ghc api package, it's a
public dependency
lemao: dcoutts_: I guess what I meant is that ghc-pkg package
format/parser/etc would be a complete fork
dcoutts_: which then means you cannot pass the InstalledPackageInfo from
ghc api functions to anything else
lemao: dcoutts_: at the same time that there are issues with the split
there are real issues witht he current status quo
dcoutts_: as well as meaning it'd get out of sync
nh2: dcoutts_: InstalledPackageInfo looks like a very

Re: [Haskell-cafe] GHC API + Cabal API + Cabal version checks: is there a way out?

I have filed a GHC ticket under

http://ghc.haskell.org/trac/ghc/ticket/8244

I hope this way we can find a solution soon.

On 07/09/13 00:04, JP Moresmau wrote:
 Oh, I'm happy to help as well if somebody is needed to do the change,
 since I have much to win in the future if EclipseFP can take advantage
 of a new version of Cabal without having to wait for a new GHC. The
 split in two libraries that Duncan mentions seems the best approach to
 me, having InstalledPackageInfo and related classes + parsers + pretty
 printers available as one reasonably stable library, while having
 another one for the real Cabal functionality...

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Strange IO sequence behaviour (Was: sequence causing stack overflow on pretty small lists)

Ah, that's enlightening, and a good addition to 
http://ghc.haskell.org/trac/ghc/ticket/8189

On Sat 07 Sep 2013 04:31:31 JST, Tom Ellis wrote:
 FYI, rwbarton on Reddit produced a nice answer:

 
 http://www.reddit.com/r/haskell/comments/1luan1/strange_io_sequence_behaviour/cc32ec4


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Tutorial on JS with Haskell: Fay or GHCJS?

2013-09-04 Thread Niklas Hambüchen

Hi, I'm also interested in that.

Have you already evaluated haste?

It does not seem to have any of your cons, but maybe others.

What I particularly miss from all solutions is the ability to simply 
call parts written in Haskell from Javascript, e.g. to write `fib` and 
then integrate it into an existing Javascript application (they are all 
more interested in doing the other direction).

On Wed 04 Sep 2013 17:14:55 JST, Alejandro Serrano Mena wrote:
 Hi,
 I'm currently writing a tutorial on web applications using Haskell. I
 know the pros and cons of each server-side library (Yesod, Snap,
 Scotty, Warp, Happstack), but I'm looking for the right choice for
 client-side programming that converts Haskell to JavaScript. I've
 finally come to Fay vs. GHCJS, and would like your opinion on what's
 the best to tackle. My current list of pros and cons is:

 Fay
 ===
 Pros:
 - Does not need GHC 7.8
 - Easy FFI with JS
 - Has libraries for integration with Yesod and Snap

 Cons:
 - Only supports a subset of GHC (in particular, no type classes)


 GHCJS
 ==
 Pros:
 - Supports full GHC
 - Easy FFI with JS
 - Highly opinionated point: will stay longer than Fay (but it's very
 important for not having a tutorial that is old in few months)

 Cons:
 - Needs GHC 7.8 (but provides a Vagrant image)


 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] On Markdown in Haddock and why it's not going to happen

2013-09-03 Thread Niklas Hambüchen

On 30/08/13 10:30, Mateusz Kowalczyk wrote:
 I would also like to remind you that if there's something that you'd
 like to see in Haddock or something that you feel is broken, a good way
 express this is to make a ticket on the Haddock Trac[2].

I made one:

http://trac.haskell.org/haddock/ticket/257

This is very useful for us because haddock is broken by some TH issue.
This way, we can have most of our docs anyway.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] On Markdown in Haddock and why it's not going to happen

2013-09-01 Thread Niklas Hambüchen

On 01/09/13 04:27, Mateusz Kowalczyk wrote:
 It doesn't have to be 1-to-1 but the features have to be expressible in
 both: it's useless if we have different features with one syntax but not
 the other.

I don't find that useless. Markdown does not have definition lists, but
we use a normal list to achieve the same documentation goals.

Already being able to simply write basic markdown would bring me big
practical benefits, and I would prefer minor theoretical misalignments
not to outweigh them.

 If Markdown can do
 something new, that something can be added; if something doesn't make
 sense in Haddock (like horizontal rules), we ignore them.
 This is precisely what I have been doing and why my post went over every
 point from the original Markdown documentation, talking about why each
 of these does or doesn't make sense. In the end, Markdown offers us
 nothing new feature wise

If the features are the same, I would prefer to write them in markdown.

 and either forces us to make up new syntax for
 things it doesn't know about (definition lists) or makes us remove
 existing features all together.

As I said, I think it doesn't matter. The basic functionality that
people use is all there. I have not seen a haddock definition list in my
life, the first one is encountered is the single one in attoparsec
because I grepped for [@ after reading your post.

 As for which markdown implementation to use: I think it really doesn't
 matter that much in practice. Github and pandoc can both render
 documentation to my pleasing; I have yet to find a difference between
 them that would be a practical problem for my documentation efforts.
 Unfortunately it _does_ matter in practice because each flavour solves
 Markdown quirks differently. On top of this, we have to accomodate for
 Haddock specific features. We're effectively creating our own flavour of
 Markdown + extra syntax. This sounds like… Haddock markup!

Once we have picked one of the flavours, I do not care about the others.
These quirks have little practical relevance: I have put the markdown
from my main github projects into the tool you mentioned, and into
pandoc, and there were no bad surprises for me.

Given that, even if I were to step into a pathologic case, after I write
the documentation, a quick look at it immediately tells me whether
everything is to my liking or not.

 Regarding module and type links: They are links, so probably just
 representing them as Markdown links would be cleanest. [SomeThing]()
 with an empty reference could make haddock automatically figure out what
 is wanted or default to a type, and you could be explicit with
 [SomeThing](module), [SomeThing](type) and [SomeThing](class).

 For headings, why is CPP a problem? CPP ignores haddock comments,
 haddock should ignore CPP. There is no reason to put CPP macros into
 comments.
 I have to admit that I did not explore this very carefully but you we
 can't simply guarantee that no one every will run CPP on their files by
 hand. Better safe than sorry.

This is unreasonable. You also can't guarantee that nobody will run the
Handlebars templating language either, or any other tool.

You cannot even tell what the user wants to achieve: Should

-- | You can use `#if SHELL a #else b #endif`

go into the documentation unexpanded or template processed?

The only sane way is to make haddock agnostic of all those tools in the
world, save the Haskell compiler which it addresses by being inside
comments.

If somebody wanted to run their custom tool by hand before running
haddock by hand, sure they would write

#if ...
-- | Some haddock
#else
-- | Some other haddock
# endif

if they wished to conditionally generate different haddock.

 Regarding emphasis, **foo** would simply not be a heading in an export
 list. Using markdown haddock, we will have markdown headings for that.
 But what if I want it to be a heading? Are we picking rules arbitrarily now?

I do not understand what you mean. If you want it to be a heading, you
write:

# My heading

I don't find that worse than

* My heading

 Markdown being claimed to be for editing documents for the Web doesn't
 make our efforts impossible. Pandoc can easily create latex output from
 it, and Github can use it as a documentation language for programming
 perfectly fine. So can we.
 That's because you can use LaTeX to render everything that HTML can (but
 not the other way around!).

Yes, so what is the problem? You write markdown and it can be compiled
to your target languages. Why is it a problem that you cannot go the
other way around?

My point here was saying that markdown can be compiled to the three
targets you mentioned.

 GitHub can use it because they don't have the burden of having to
 accommodate for an existing feature set of a different markup language.
 Note how GitHub Markdown doesn't have all the features of Haddock,
 therefore it is _not_ compatible with it. We can't just use their
 Markdown because

Re: [Haskell-cafe] On Markdown in Haddock and why it's not going to happen

2013-08-31 Thread Niklas Hambüchen

Hello,

I disagree.

While none of your detail points are wrong, they mainly focus on the
fact that there is no 1-to-1 mapping between the existing haddock markup
and Markdown. I don't think there needs to be. If Markdown can do
something new, that something can be added; if something doesn't make
sense in Haddock (like horizontal rules), we ignore them.

I don't think original and markdown syntax should be mixed in the same
file. That would make everything impossible to parse and difficult to write.

As for which markdown implementation to use: I think it really doesn't
matter that much in practice. Github and pandoc can both render
documentation to my pleasing; I have yet to find a difference between
them that would be a practical problem for my documentation efforts.

Regarding module and type links: They are links, so probably just
representing them as Markdown links would be cleanest. [SomeThing]()
with an empty reference could make haddock automatically figure out what
is wanted or default to a type, and you could be explicit with
[SomeThing](module), [SomeThing](type) and [SomeThing](class).

For headings, why is CPP a problem? CPP ignores haddock comments,
haddock should ignore CPP. There is no reason to put CPP macros into
comments.

Regarding emphasis, **foo** would simply not be a heading in an export
list. Using markdown haddock, we will have markdown headings for that.

Markdown being claimed to be for editing documents for the Web doesn't
make our efforts impossible. Pandoc can easily create latex output from
it, and Github can use it as a documentation language for programming
perfectly fine. So can we.

Did I address all your points?

Niklas


On Fri 30 Aug 2013 10:30:51 JST, Mateusz Kowalczyk wrote:
 Greetings café,

 Perhaps some saddening news for Markdown fans out there. As you might
 remember, there was a fair amount of push for having Markdown as an
 alternate syntax for Haddock.

 Unfortunately, this is probably not going to happen for reasons listed
 on the post I just published at [1].

 This thread is meant to be for discussion about the post as many people,
 myself included, felt that Markdown would be a nice thing to have.

 I feel like I covered the topic fairly well on the post but feel free to
 give suggestions or ask questions.

 I would also like to remind you that if there's something that you'd
 like to see in Haddock or something that you feel is broken, a good way
 express this is to make a ticket on the Haddock Trac[2].

 I will close the relevant Markdown ticket on the Trac[3] in about 3
 days, unless someone can come up with a reasonable solution that meets
 the initial intent of this part of the project: a widely known markup
 format that could be used as an alternate syntax for Haddock so that
 it's possible to write the documentation without learning the vanilla
 syntax itself.

 [1]:
 http://fuuzetsu.co.uk/blog/posts/2013-08-30-why-Markdown-in-Haddock-can't-happen.html

 [2]: http://trac.haskell.org/haddock

 [3]: http://trac.haskell.org/haddock/ticket/244

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] cpphs calls error when it finds an #error declaration

2013-08-28 Thread Niklas Hambüchen

On 29/08/13 00:43, Malcolm Wallace wrote:
 Have you tried simply wrapping the call to runCpphs in a catch?  Something 
 like
 
 safeRunCpphs :: ... - IO (Either String String)
 safeRunCpphs foo = fmap Right (runCpphs foo) `catch` (\(UserError s)- 
 Left s

Yes, that is what I'm doing at the moment. The problem with this is that
it does not allow me to distinguish between a programmer error (error)
on the caller or implementation side, and an #error in the input file.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] sequence causing stack overflow on pretty small lists

Thanks for your examples.

On 27/08/13 13:59, Albert Y. C. Lai wrote:
 The correct fix is to raise the stack cap, not to avoid using the stack.
 
 Indeed, ghci raises the stack cap so high I still haven't fathomed where
 it is. This is why you haven't seen a stack overflow in ghci for a long
 time. See, ghci agrees: the correct thing to do is to raise the stack cap.

If I understand this correctly, you agree that the stack size should be
unlimited by default?

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] cpphs calls error when it finds an #error declaration

Hi,

after some debugging of a higher-level tool I found out that when I use
cpphs as a library and the `runCpphs` function that is to produce the
preprocessed output, when it comes across the #error directive it will
terminate my program.

This is because handling #error is implemented with Haskell's `error`.

I find that slightly unfortunate since it means I cannot distinguish
betwen an #error written in the input file and a programming error
inside cpphs.

@Malcolm, would you mind a change towards throwing an exception that is
different from error so that it can be easily caught, or even better, a
change from

runCpphs :: ... - IO String

to

runCpphs :: ... - IO (Either String String)

or similar?

If an exception based interface is kept, it would be nice to add some
haddock to `runCpphs`; not knowing about the existence of #error, it is
easy to assume that the IO is only used for accessing the FilePath
passed in.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Template Haskell

Hi Jose,

Template Haskell doesn't parse code.

haskell-src-exts and the GHC API can do that.

Have a look at:

* ghc-mod browse (using ghc api)
* hscope (using haskell-src-exts)

On 27/08/13 15:45, Jose A. Lopes wrote:
 Hi,
 
 Is it possible to retrieve all definitions contained in a module using
 Template Haskell ?
 
 Thanks,
 Jose
 

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] sequence causing stack overflow on pretty small lists

On 27/08/13 20:37, Patrick Palka wrote:
 You can use ContT to force the function to use heap instead of stack
 space, e.g. runContT (replicateM 100 (lift randomIO)) return

That is interesting, and works.

Unfortunately its pure existence will not fix sequence, mapM etc. in base.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] sequence causing stack overflow on pretty small lists

On #haskell we recently had a discussion about the following:

   import System.Random

   list - replicateM 100 randomIO :: IO [Int]

I would think that this gives us a list of a million random Ints. In
fact, this is what happens in ghci. But with ghc we get:

   Stack space overflow: current size 8388608 bytes.
   Use `+RTS -Ksize -RTS' to increase it.

This is because sequence is implemented as

 sequence (m:ms) = do x - m
  xs - sequence ms
  return (x:xs)

and uses stack space when used on some [IO a].

From a theoretical side, this is an implementation detail. From the
software engineering side this disastrous because the code is

  * obviously correct by itself
  * the first thing people would come up with
  * not exaggerating: a million elements is not much
  * used a lot of places: mapM, replicateM are *everywhere*

and yet it will kill our programs, crash our airplanes, and give no
helpful information where the problem occurred.

Effectively, sequence is a partial function.

(Note: We are not trying to obtain a lazy list of random numbers, use
any kind of streaming or the likes. We want the list in memory and use it.)

We noticed that this problem did not happen if sequence were implemented
with a difference list.

What do you think about this? Should we fix functions like this,
probably trading off a small performance hit, or accept that idiomatic
Haskell code can crash at any time?

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] sequence causing stack overflow on pretty small lists

As an example that this actually makes problems in production code, I
found this in the wildlife:

https://github.com/ndmitchell/shake/blob/e0e0a43/Development/Shake/Database.hs#L394

-- Do not use a forM here as you use too much stack space
bad - (\f - foldM f [] (Map.toList status)) $ \seen (i,v) - ...

I could bet that there is a lot of code around on which we rely, which
has the same problem but does not go that far in customisation.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ordNub

On 14/07/13 20:20, Niklas Hambüchen wrote:
 As you might not know, almost *all* practical Haskell projects use it,
 and that in places where an Ord instance is given, e.g. happy, Xmonad,
 ghc-mod, Agda, darcs, QuickCheck, yesod, shake, Cabal, haddock, and 600
 more (see https://github.com/nh2/haskell-ordnub).

GHC uses nub.

Also let me stress again that the n² case happens even if there are no
duplicates.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] sequence causing stack overflow on pretty small lists

Maybe an unlimited stack size should be the default?

As far as I understand, the only negative effect would be that some
programming mistakes would not result in a stack overflow. However, I
doubt the usefulness of that:

* It already depends a lot on the optimisation level
* If you do the same thing in a slightly different way, and you allocate
on the heap instead of on the stack you will not get it either

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Renumbered mailing list posts

2013-08-25 Thread Niklas Hambüchen

Austin: Do you have any update on this?

On 11/08/13 04:48, Austin Seipp wrote:
 Henning,
 
 Thanks for the report. I'm currently investigating this, and think it
 should be possible to keep all of the old URLs intact.
 
 On Sat, Aug 10, 2013 at 11:01 AM, Niklas Hambüchen m...@nh2.me wrote:
 On 11/08/13 00:50, Brandon Allbery wrote:
 Those at least are recoverable, just replace hpaste.org
 http://hpaste.org with lpaste.net http://lpaste.net (content is
 still there). But still.

 Unfortunately I cannot amend emails that I have sent.

 Could we not just have kept the domain and set a CNAME entry to the new one?


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell] ANNOUNCE: haskell-src-exts 1.14.0

Fellow Haskelleers,

I'm pleased to announce the release of haskell-src-exts-1.14.0!

* On hackage: http://hackage.haskell.org/package/haskell-src-exts
* Via cabal: cabal install haskell-src-exts
* git repo: 
https://github.com/haskell-suite/haskell-src-extshttp://code.haskell.org/haskell-src-exts

There are two primary reasons for this release, and a number of smaller
ones.

The first primary reason is technical: haskell-src-exts 1.14 revamps the
Extension datatype, among other things to allow turning extensions on and
off (similar to what Cabal allows). We also introduce the concept of a
Language, separate from a set of extensions. This is the only
backwards-incompatible change in this release.

The second reason is structural: haskell-src-exts is now part of a larger
context -- the Haskell Suite. The package has a new home on github (see
above), alongside its new cool friends: haskell-names and haskell-packages.
There is also a really nice issue tracker there - please help me fill it,
or better yet, empty it!

What this release does *not* cover is support for the extensions added to
GHC in recent time (with the exceptions of CApiFFI and InterruptibleFFI).
Work is in progress on many of these, and there will be another major
release not far off in the future.


This release owes many thanks to Roman Cheplyaka in particular, as well as
Erik Hesselink, Simon Meier and David Fox. Thanks a lot!


Complete changelog:

1.13.6 -- 1.14.0
===

* Modernize the Extension datatype in L.H.E.Extension, following the lead
  of Cabal, to allow negative and positive extension modifiers (turning
  features on and off). You need to worry about backwards-incompatible
  changes if any of the following pertains to you:
  1) If you use the Extension datatype programmatically - it has changed
 significantly (see documentation).
  2) The ParseMode record now has one more field
 (baseLanguage :: Language), which might give you a type error.
  3) The behavior of the (extensions :: [Extension]) field has changed,
 which could bite you if you pass custom extensions in the ParseMode.
 Previously, the ParseMode defaulted to the list of extensions accepted
 by Haskell2010, and if you set the list explicitly you would override
 this. Now, the defaults are { baseLanguage = Haskell2010, extensions =
[] },
 and explicitly setting a list of extensions will be interpreted on top
of
 Haskell2010. See further the documentation for L.H.E.Extension.

* Add support for the 'capi' calling convention. It is enabled with the
CApiFFI
  extension. It's been included since GHC 7.4, and advertised since 7.6.

* Add support for the 'interruptible' FFI safety annotation, enabled with
  the InterruptibleFFI extension.

* Give better error message when lexing newline fails. In particular, fix
the bug
  when the parser would crash if the file didn't end with a newline.

* Support unboxed tuple expressions and patterns.

* Fix bug in lexing of primitive integer literals in hex or octal notation.

* Disallow negative primitive word literals
  (such as W# (-0x8000##)).

* Allow phase control for SPECIALIZE pragma.

* Derive Foldable and Traversable instances for all annotated AST types.

* Fix bug with pretty-printing WARNING and DEPRECATED pragmas.


Cheers, Niklas
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] ANNOUNCE: haskell-src-exts 1.14.0

Nice!

I hope that haskell-suite will eventually become awesome and solve most
of our automation-on-Haskell-code needs.

Two questions:

1) My most desired feature would be a syntax tree that does not pluck
pluck comments out and make me treat them separately. It looks much
easier to me to have a fully descriptive tree and (filter . concatMap) /
traverse them out in some way than getting a list of comments and having
to insert them back in the right places myself.
Is that possible?

2) Have you considered downloading the all-of-Hackage tarball and
running haskell-src-exts over it to get a benchmark of how much HSE can
already parse of the Haskell code out there?

Thanks!

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] ANNOUNCE: haskell-src-exts 1.14.0

Hi Niklas,

1) My most desired feature would be a syntax tree that does not pluck
 pluck comments out and make me treat them separately. It looks much
 easier to me to have a fully descriptive tree and (filter . concatMap) /
 traverse them out in some way than getting a list of comments and having
 to insert them back in the right places myself.
 Is that possible?


Sadly not - it's theoretically impossible. The fact that you can put
comments literally wherever, means that it's impossible to treat them as
nodes of the AST. E.g.

  f {- WHERE -} x = -- WOULD
  -- THESE
  do -- COMMENTS
 a {- END -} - g x -- UP
 return {- ? -} a

What would be theoretically possible is to define a restricted language
that allows comments only in certain well-defined places (cf haddock), and
ignores any others. That's a lot of work though, and it's not clear how big
the gain is. :-\

A different solution could be to improve the support, through better helper
functions, for handling a syntax tree and a list of comments together.
That's something I think could be worthwhile.


 2) Have you considered downloading the all-of-Hackage tarball and
 running haskell-src-exts over it to get a benchmark of how much HSE can
 already parse of the Haskell code out there?


Considered, yes. Done, no. Would love to see the results :-). The crew at
OdHac (Roman, Erik, Simon) ensured that the current version handles all of
'base', which is a good start.

Cheers, Niklas
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] ANNOUNCE: haskell-src-exts 1.14.0

On 20/08/13 18:19, Niklas Broberg wrote:
 Sadly not - it's theoretically impossible. The fact that you can put
 comments literally wherever, means that it's impossible to treat them as
 nodes of the AST. E.g.
 
   f {- WHERE -} x = -- WOULD
   -- THESE
   do -- COMMENTS
  a {- END -} - g x -- UP
  return {- ? -} a

Oh, I see what you mean.

I guess what I mean instead is:

* A lex list that contains *everything*, including comments and white space

* A full syntax tree of which each node points to (indexes) a position
in the lex list to get the precise original position; comments in
between two nodes can then be determined and more easily played with
because they are between their positions in the lex list

* An abstract syntax tree that has whitespace and comments discarded
(what HSE has now)

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] ANNOUNCE: haskell-src-exts 1.14.0

HSE parses based on pragmas by default. This can be configured through the
ParseMode [1].

But your question regards HSP, Haskell Server Pages, which indeed just
enables most extensions by default. Right now there's no way to configure
that, but it shouldn't be hard for a skilled programmer to fix. Patches
most welcome. :-)

Cheers, Niklas

[1]
http://hackage.haskell.org/packages/archive/haskell-src-exts/1.13.5/doc/html/Language-Haskell-Exts-Parser.html#t:ParseMode
On 20 Aug 2013 12:57, Dag Odenhall dag.odenh...@gmail.com wrote:

Good stuff!

Is there any way, or plans for a way, to parse a file based on its
LANGUAGE pragmas? Last I checked e.g. HSP simply enabled all extensions
when parsing, which can cause code to be parsed incorrectly in some cases.

On Tue, Aug 20, 2013 at 10:15 AM, Niklas Broberg niklas.brob...@gmail.com
wrote:

Fellow Haskelleers,

I'm pleased to announce the release of haskell-src-exts-1.14.0!

* On hackage: http://hackage.haskell.org/package/haskell-src-exts
* Via cabal: cabal install haskell-src-exts
* git repo:
https://github.com/haskell-suite/haskell-src-extshttp://code.haskell.org/haskell-src-exts

There are two primary reasons for this release, and a number of smaller
ones.

The first primary reason is technical: haskell-src-exts 1.14 revamps the
Extension datatype, among other things to allow turning extensions on and
off (similar to what Cabal allows). We also introduce the concept of a
Language, separate from a set of extensions. This is the only
backwards-incompatible change in this release.

The second reason is structural: haskell-src-exts is now part of a larger
context -- the Haskell Suite. The package has a new home on github (see
above), alongside its new cool friends: haskell-names and haskell-packages.
There is also a really nice issue tracker there - please help me fill it,
or better yet, empty it!

What this release does *not* cover is support for the extensions added to
GHC in recent time (with the exceptions of CApiFFI and InterruptibleFFI).
Work is in progress on many of these, and there will be another major
release not far off in the future.

This release owes many thanks to Roman Cheplyaka in particular, as well
as Erik Hesselink, Simon Meier and David Fox. Thanks a lot!

Complete changelog:

1.13.6 -- 1.14.0
===

* Modernize the Extension datatype in L.H.E.Extension, following the lead
of Cabal, to allow negative and positive extension modifiers (turning
features on and off). You need to worry about backwards-incompatible
changes if any of the following pertains to you:
1) If you use the Extension datatype programmatically - it has changed
significantly (see documentation).
2) The ParseMode record now has one more field
(baseLanguage :: Language), which might give you a type error.
3) The behavior of the (extensions :: [Extension]) field has changed,
which could bite you if you pass custom extensions in the ParseMode.
Previously, the ParseMode defaulted to the list of extensions
accepted
by Haskell2010, and if you set the list explicitly you would
override
this. Now, the defaults are { baseLanguage = Haskell2010, extensions
= [] },
and explicitly setting a list of extensions will be interpreted on
top of
Haskell2010. See further the documentation for L.H.E.Extension.

* Add support for the 'capi' calling convention. It is enabled with the
CApiFFI
extension. It's been included since GHC 7.4, and advertised since 7.6.

* Add support for the 'interruptible' FFI safety annotation, enabled with
the InterruptibleFFI extension.

* Give better error message when lexing newline fails. In particular, fix
the bug
when the parser would crash if the file didn't end with a newline.

* Support unboxed tuple expressions and patterns.

* Fix bug in lexing of primitive integer literals in hex or octal
notation.

* Disallow negative primitive word literals
(such as W# (-0x8000##)).

* Allow phase control for SPECIALIZE pragma.

* Derive Foldable and Traversable instances for all annotated AST types.

* Fix bug with pretty-printing WARNING and DEPRECATED pragmas.

Cheers, Niklas

--
You received this message because you are subscribed to the Google Groups
Haskell Server Pages group.
To unsubscribe from this group and stop receiving emails from it, send an
email to haskell-server-pages+unsubscr...@googlegroups.com.
To post to this group, send email to
haskell-server-pa...@googlegroups.com.
Visit this group at http://groups.google.com/group/haskell-server-pages.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Haskell] ANNOUNCE: haskell-src-exts 1.14.0

 The first primary reason is
 technical: haskell-src-exts
 1.14 revamps the Extension
 datatype, among other things
 to allow turning extensions on
 and off (similar to what Cabal
 allows). We also introduce the
 concept of a Language,
 separate from a set of
 extensions. This is the only
 backwards-incompatible
 change in this release.

Heads-up: as was pointed out to me, the above is not true. The constructors
of the Tuple type have also changed, which means greater risks for
breakage. Proceed with this in mind.

Cheers, Niklas
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] ANNOUNCE: posix-paths, for faster file system operations

John Lato and I would like to announce our posix-paths package.

https://github.com/JohnLato/posix-paths

It implements a large portion of System.Posix.FilePath using ByteString
based RawFilePaths instead of String based FilePaths, and on top of that
provides a Traversal module with a fast replacement for
`getDirectoryContents` and a recursive `allDirectoryContents`.

`getDirectoryContents` is (unsurprisingly?) really slow.
Our replacement is 11 times faster in the recursive use case [1], and
only 20% slower than `find`.

Benchmarks are at [2], code is at [3].

We hope that these improvements will eventually make it into base some day.

Until then, we propose our package as a base for discussion and further
improvements.

Contributions are welcome:
Some FilePath operations are not in it yet (especially the Windows /
drive related ones), and our traversals might not work on Windows.
We would also appreciate some thorough looks at their low level
implementations.
If you find our benchmarks against getDirectoryContents unfair or would
like to add another one, please send a pull request.

We have been running this on Linux production machines for a few months
now, and are pleased by the speed-up.

[1] For the recursive version of the original `getDirectoryContents`, we
used the implementation given in Real World Haskell:
http://book.realworldhaskell.org/read/io-case-study-a-library-for-searching-the-filesystem.html

[2] Benchmarks:
On a real file system: http://johnlato.github.io/posix-paths/usrLocal.html
On tmpfs: http://johnlato.github.io/posix-paths/tmpfs.html (note that
here find is slow because of process starting overhead)

[3] Code:
Github: https://github.com/JohnLato/posix-paths
RawFilePath operations:
https://github.com/JohnLato/posix-paths/blob/master/src/System/Posix/FilePath.hs
Traversals:
https://github.com/JohnLato/posix-paths/blob/master/src/System/Posix/Directory/Traversals.hs
Benchmarks:
https://github.com/JohnLato/posix-paths/blob/master/benchmarks/Bench.hs

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell-cafe] ANNOUNCE: haskell-src-exts 1.14.0

Fellow Haskelleers,

I'm pleased to announce the release of haskell-src-exts-1.14.0!

* On hackage: http://hackage.haskell.org/package/haskell-src-exts
* Via cabal: cabal install haskell-src-exts
* git repo: 
https://github.com/haskell-suite/haskell-src-extshttp://code.haskell.org/haskell-src-exts

There are two primary reasons for this release, and a number of smaller
ones.

The first primary reason is technical: haskell-src-exts 1.14 revamps the
Extension datatype, among other things to allow turning extensions on and
off (similar to what Cabal allows). We also introduce the concept of a
Language, separate from a set of extensions. This is the only
backwards-incompatible change in this release.

The second reason is structural: haskell-src-exts is now part of a larger
context -- the Haskell Suite. The package has a new home on github (see
above), alongside its new cool friends: haskell-names and haskell-packages.
There is also a really nice issue tracker there - please help me fill it,
or better yet, empty it!

What this release does *not* cover is support for the extensions added to
GHC in recent time (with the exceptions of CApiFFI and InterruptibleFFI).
Work is in progress on many of these, and there will be another major
release not far off in the future.


This release owes many thanks to Roman Cheplyaka in particular, as well as
Erik Hesselink, Simon Meier and David Fox. Thanks a lot!


Complete changelog:

1.13.6 -- 1.14.0
===

* Modernize the Extension datatype in L.H.E.Extension, following the lead
  of Cabal, to allow negative and positive extension modifiers (turning
  features on and off). You need to worry about backwards-incompatible
  changes if any of the following pertains to you:
  1) If you use the Extension datatype programmatically - it has changed
 significantly (see documentation).
  2) The ParseMode record now has one more field
 (baseLanguage :: Language), which might give you a type error.
  3) The behavior of the (extensions :: [Extension]) field has changed,
 which could bite you if you pass custom extensions in the ParseMode.
 Previously, the ParseMode defaulted to the list of extensions accepted
 by Haskell2010, and if you set the list explicitly you would override
 this. Now, the defaults are { baseLanguage = Haskell2010, extensions =
[] },
 and explicitly setting a list of extensions will be interpreted on top
of
 Haskell2010. See further the documentation for L.H.E.Extension.

* Add support for the 'capi' calling convention. It is enabled with the
CApiFFI
  extension. It's been included since GHC 7.4, and advertised since 7.6.

* Add support for the 'interruptible' FFI safety annotation, enabled with
  the InterruptibleFFI extension.

* Give better error message when lexing newline fails. In particular, fix
the bug
  when the parser would crash if the file didn't end with a newline.

* Support unboxed tuple expressions and patterns.

* Fix bug in lexing of primitive integer literals in hex or octal notation.

* Disallow negative primitive word literals
  (such as W# (-0x8000##)).

* Allow phase control for SPECIALIZE pragma.

* Derive Foldable and Traversable instances for all annotated AST types.

* Fix bug with pretty-printing WARNING and DEPRECATED pragmas.


Cheers, Niklas
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] [Haskell] ANNOUNCE: haskell-src-exts 1.14.0

Nice!

I hope that haskell-suite will eventually become awesome and solve most
of our automation-on-Haskell-code needs.

Two questions:

1) My most desired feature would be a syntax tree that does not pluck
pluck comments out and make me treat them separately. It looks much
easier to me to have a fully descriptive tree and (filter . concatMap) /
traverse them out in some way than getting a list of comments and having
to insert them back in the right places myself.
Is that possible?

2) Have you considered downloading the all-of-Hackage tarball and
running haskell-src-exts over it to get a benchmark of how much HSE can
already parse of the Haskell code out there?

Thanks!

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] [Haskell] ANNOUNCE: haskell-src-exts 1.14.0

Hi Niklas,

1) My most desired feature would be a syntax tree that does not pluck
 pluck comments out and make me treat them separately. It looks much
 easier to me to have a fully descriptive tree and (filter . concatMap) /
 traverse them out in some way than getting a list of comments and having
 to insert them back in the right places myself.
 Is that possible?


Sadly not - it's theoretically impossible. The fact that you can put
comments literally wherever, means that it's impossible to treat them as
nodes of the AST. E.g.

  f {- WHERE -} x = -- WOULD
  -- THESE
  do -- COMMENTS
 a {- END -} - g x -- UP
 return {- ? -} a

What would be theoretically possible is to define a restricted language
that allows comments only in certain well-defined places (cf haddock), and
ignores any others. That's a lot of work though, and it's not clear how big
the gain is. :-\

A different solution could be to improve the support, through better helper
functions, for handling a syntax tree and a list of comments together.
That's something I think could be worthwhile.


 2) Have you considered downloading the all-of-Hackage tarball and
 running haskell-src-exts over it to get a benchmark of how much HSE can
 already parse of the Haskell code out there?


Considered, yes. Done, no. Would love to see the results :-). The crew at
OdHac (Roman, Erik, Simon) ensured that the current version handles all of
'base', which is a good start.

Cheers, Niklas
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] [Haskell] ANNOUNCE: haskell-src-exts 1.14.0

On 20/08/13 18:19, Niklas Broberg wrote:
 Sadly not - it's theoretically impossible. The fact that you can put
 comments literally wherever, means that it's impossible to treat them as
 nodes of the AST. E.g.
 
   f {- WHERE -} x = -- WOULD
   -- THESE
   do -- COMMENTS
  a {- END -} - g x -- UP
  return {- ? -} a

Oh, I see what you mean.

I guess what I mean instead is:

* A lex list that contains *everything*, including comments and white space

* A full syntax tree of which each node points to (indexes) a position
in the lex list to get the precise original position; comments in
between two nodes can then be determined and more easily played with
because they are between their positions in the lex list

* An abstract syntax tree that has whitespace and comments discarded
(what HSE has now)

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANNOUNCE: haskell-src-exts 1.14.0

HSE parses based on pragmas by default. This can be configured through the
ParseMode [1].

Cheers, Niklas

[1]
http://hackage.haskell.org/packages/archive/haskell-src-exts/1.13.5/doc/html/Language-Haskell-Exts-Parser.html#t:ParseMode
On 20 Aug 2013 12:57, Dag Odenhall dag.odenh...@gmail.com wrote:

Good stuff!

On Tue, Aug 20, 2013 at 10:15 AM, Niklas Broberg niklas.brob...@gmail.com
wrote:

Fellow Haskelleers,

I'm pleased to announce the release of haskell-src-exts-1.14.0!

There are two primary reasons for this release, and a number of smaller
ones.

This release owes many thanks to Roman Cheplyaka in particular, as well
as Erik Hesselink, Simon Meier and David Fox. Thanks a lot!

Complete changelog:

1.13.6 -- 1.14.0
===

* Add support for the 'capi' calling convention. It is enabled with the
CApiFFI
extension. It's been included since GHC 7.4, and advertised since 7.6.

* Add support for the 'interruptible' FFI safety annotation, enabled with
the InterruptibleFFI extension.

* Give better error message when lexing newline fails. In particular, fix
the bug
when the parser would crash if the file didn't end with a newline.

* Support unboxed tuple expressions and patterns.

* Fix bug in lexing of primitive integer literals in hex or octal
notation.

* Disallow negative primitive word literals
(such as W# (-0x8000##)).

* Allow phase control for SPECIALIZE pragma.

* Derive Foldable and Traversable instances for all annotated AST types.

* Fix bug with pretty-printing WARNING and DEPRECATED pragmas.

Cheers, Niklas

Re: [Haskell-cafe] ANNOUNCE: haskell-src-exts 1.14.0

 The first primary reason is
 technical: haskell-src-exts
 1.14 revamps the Extension
 datatype, among other things
 to allow turning extensions on
 and off (similar to what Cabal
 allows). We also introduce the
 concept of a Language,
 separate from a set of
 extensions. This is the only
 backwards-incompatible
 change in this release.

Heads-up: as was pointed out to me, the above is not true. The constructors
of the Tuple type have also changed, which means greater risks for
breakage. Proceed with this in mind.

Cheers, Niklas
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] ANNOUNCE: posix-paths, for faster file system operations

John Lato and I would like to announce our posix-paths package.

https://github.com/JohnLato/posix-paths

`getDirectoryContents` is (unsurprisingly?) really slow.
Our replacement is 11 times faster in the recursive use case [1], and
only 20% slower than `find`.

Benchmarks are at [2], code is at [3].

We hope that these improvements will eventually make it into base some day.

Until then, we propose our package as a base for discussion and further
improvements.

We have been running this on Linux production machines for a few months
now, and are pleased by the speed-up.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Retrieving Haddock comments with haskell-src-exts

2013-08-16 Thread Niklas Broberg

Hi again,

Hmm. I see the difficulty here, and eventually I would want to have support
for this, but alas, not yet. If you come up with any solution that doesn't
involve GHC (or only marginally so), I'd love to hear it.

Cheers, Niklas


On Wed, Aug 14, 2013 at 8:57 PM, Mateusz Kowalczyk
fuuze...@fuuzetsu.co.ukwrote:

 On 14/08/13 19:02, Niklas Broberg wrote:
  Hi Mateusz,
 
  haskell-src-exts is not haddock-aware I'm afraid, so I don't have any
 real
  solution for you. The one you mention, i.e. going through the whole parse
  result and stiching things together manually seems like the best bet if
 you
  want to use haskell-src-exts throughout.
 The main problem with this approach is that we get comments (and their
 SrcLoc) as a separate list. While it's trivial to check whether the
 comment starts with a ‘|’ or ‘^’ and it's not even hard to find any lines
 immediately following it, Haddock comments can appear in weird
 positions and trail until a line of code is encountered. Right now,
 it's rather hard to tell

   -- | Foo

   -- bar
 and

   -- | Foo
   someCode = undefined
   -- bar

 apart. I think this is the only option at the moment if I'm to use
 haskell-src-exts.
 
  In the longer run, it would be nice to have haddock support in
  haskell-src-exts, so ideas regarding what kind of interface you would
 like
  to see are most welcome. :-)
 For my use, I do not care about anything but Haddock comments. I don't
 care where or why they appear, what they are attached to c. With my
 current method, I just throw all this information away (it's given by
 GHC).

 For general use, I imagine that it'd be useful for the program to
 combine multi-line Haddock comments into a single one and attach it to
 whatever it is documenting. I'm not sure how haskell-src-exts is
 implemented but I don't think it's plausible to do this without going
 out to GHC and asking it for the information. Incidentally, this is
 precisely the problem I'm trying to solve with help of haskell-src-exts.

 
  Cheers, Niklas
 
 Thanks!

 --
 Mateusz K.

 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Retrieving Haddock comments with haskell-src-exts

2013-08-14 Thread Niklas Broberg

Hi Mateusz,

haskell-src-exts is not haddock-aware I'm afraid, so I don't have any real
solution for you. The one you mention, i.e. going through the whole parse
result and stiching things together manually seems like the best bet if you
want to use haskell-src-exts throughout.

In the longer run, it would be nice to have haddock support in
haskell-src-exts, so ideas regarding what kind of interface you would like
to see are most welcome. :-)

Cheers, Niklas


On Wed, Aug 14, 2013 at 4:57 PM, Mateusz Kowalczyk
fuuze...@fuuzetsu.co.ukwrote:

 I'm writing a small tool to help to analyse Haddock comments in
 Haskell source files to help me to indicate any potential breakage to
 documentation in existing source files.

 Currently I'm doing the parsing with the GHC's ‘parser’ function with
 Opt_Haddock set and I filter out everything I don't need. There are
 problems with this approach: determining any extensions and options
 used is vital for valid parsing of the files and a large amount of
 source files outright fails to parse without this information.

 Fortunately, haskell-src-exts exists and it can deal with all (or
 most) of this for me. Unfortunately, there doesn't seem to be any way
 to get it to recognise Haddock comments and the only option available
 is all comments or no comments at all. It's not easily possible to
 stitch these together without analysing the whole parse result.

 Currently I'm thinking of parsing out extensions and pragmas used
 using haskell-src-exts and then feeding those to GHC, effectively
 parsing the second time. Is there a way to avoid this?

 There's ‘lexTokenStream’ but I believe it has similar problems to
 ‘parser’, that is, needing to know the extensions beforehand.
 --
 Mateusz K.

 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Renumbered mailing list posts

2013-08-10 Thread Niklas Hambüchen

Yes, I also found that links from Google to archives don't work any 
more.

(Also fact that hpaste just went away, invalidating all my links to 
hpastes, is similarly bad.)

On Sat 10 Aug 2013 17:49:35 JST, Henning Thielemann wrote:
 Recently I found that links from Google search results to archive
 Haskell-Cafe messages are invalid. The messages are still there, but
 got a different number. E.g. the search result says:
   http://www.haskell.org/pipermail/haskell-cafe/2011-February/089455.html

 But the message is at
   http://www.haskell.org/pipermail/haskell-cafe/2011-February/088146.html

 Also links from Haskell-Wiki articles to the Haskell-Cafe archive are
 invalid now. This is very very very bad, since I used tons of such
 URLs in Wiki articles and it is very hard to find the message I
 referred to, if the URL does not work anymore.

 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Renumbered mailing list posts

2013-08-10 Thread Niklas Hambüchen

On 11/08/13 00:50, Brandon Allbery wrote:
 Those at least are recoverable, just replace hpaste.org
 http://hpaste.org with lpaste.net http://lpaste.net (content is
 still there). But still.

Unfortunately I cannot amend emails that I have sent.

Could we not just have kept the domain and set a CNAME entry to the new one?

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] casting a into Maybe a

2013-07-27 Thread Niklas Hambüchen

Put a Just around it?

transMit s now key (Just newmsgs) q m

On Sat 27 Jul 2013 20:05:43 JST, Joerg Fritsch wrote:
 If I have the following type signature
 transMit :: Serialize a = Socket - POSIXTime - KEY - Maybe a - TPSQ - 
 TMap a - IO ()


 And the function is called with
 transMit s now key newmsgs q m
 where newmsgs is whatever type a I get but _not_ a Maybe a

 then I get the error
 Could not deduce (a ~ Maybe a)
 from the context (Serialize a)

 Can I somehow when I call transmit cast newmsgs into a Maybe newmsgs or so so 
 that the function call fits the type signature?

 --Joerg


 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ghc and jump table generation

2013-07-18 Thread Niklas Larsson

Hi!


2013/7/18 Erik Rantapaa eranta...@yahoo.com



 I've been looking at the assembly code that ghc generates for simple
 pattern matching for situations like:

 foo :: Int - Int
 foo 1 = 3
 foo 2 = 10
 foo 3 = 2
 foo 4 = 42
 -- ... other random assignments

 and I noticed that it doesn't seem to generate a jump table (or even a
 table lookup)  like, for instance, gcc would for this switch statement:

 int foo(int x) {
   switch (c) {
 case 1: return 3;
 case 2: return 10;
 case 3: return 2;
 case 4: return 42;
 // ... etc.
   }
 }

 Under -O3 ghc seems to produce a binary-search of the cases.

 Questions: Would generating a jump/lookup table for pattern matches like
 this (i.e. with a suitable density of cases) be beneficial? And, if so,
 would it be difficult to add to ghc? And would it be a good first project
 for someone who wants to get into the ghc code base (perhaps with some
 mentoring from the community?)


I was just digging around in the native code generator so I have a few
leads for you.

GHC can already generate jump tables, look at genSwitch in
compiler/nativeGen/X86/CodeGen.hs, and it is what a CmmSwitch gets compiled
into. Follow that into the codeGen and you see CmmSwitch is only created in
emitSwitch in StgCmmExpr.hs. You can follow that farther and see when that
is invoked.

I have no clue if it's a worthwhile thing to do. Try it and measure the
impact.

Niklas


 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Monad Transformer Space Leak

2013-07-18 Thread Niklas Hambüchen

Did you file this as a bug?

On Tue 23 Apr 2013 23:16:03 JST, Clark Gaebel wrote:
 I'm on 7.6.2, and it does. Oh no.

   - Clark

 On Tuesday, April 23, 2013, Tom Ellis wrote:

 On Tue, Apr 23, 2013 at 09:36:04AM +0200, Petr Pudlák wrote:
  I tested it on GHC 6.12.1, which wasn't affected by the recent
 ackermann
  bug, but still it leaks memory.

 I tested it on GHC 7.4.1 and I don't see any space leak.

 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org javascript:;
 http://www.haskell.org/mailman/listinfo/haskell-cafe



 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Monad Transformer Space Leak

2013-07-18 Thread Niklas Hambüchen

Sounds like a Real Good Thing to do :)

On Fri 19 Jul 2013 11:10:25 JST, Clark Gaebel wrote:
 No I haven't.

   - Clark

 On Thu, Jul 18, 2013 at 10:07 PM, Niklas Hambüchen m...@nh2.me wrote:
 Did you file this as a bug?

 On Tue 23 Apr 2013 23:16:03 JST, Clark Gaebel wrote:
 I'm on 7.6.2, and it does. Oh no.

   - Clark

 On Tuesday, April 23, 2013, Tom Ellis wrote:

 On Tue, Apr 23, 2013 at 09:36:04AM +0200, Petr Pudlák wrote:
  I tested it on GHC 6.12.1, which wasn't affected by the recent
 ackermann
  bug, but still it leaks memory.

 I tested it on GHC 7.4.1 and I don't see any space leak.

 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org javascript:;
 http://www.haskell.org/mailman/listinfo/haskell-cafe



 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ordNub

2013-07-15 Thread Niklas Hambüchen

Hey Jason,

would you mind giving a short idea of what the point of Bird's
implementation is / from what properties it is derived?

Also, running the QuickCheck tests you added, it doesn't give the same
output (order) as nub.

On 15/07/13 13:26, Jason Dagit wrote:
 Richard Bird has a book, Pearls of Functional Algorithm Design that
 is meant to teach a form of deriving algorithms from the properties we
 ask of them. In this book, he gives a possible derivation of ordNub,
 simply called nub in the book, following the methodology he is
 teaching. He notes in the text that this derivation feels more
 complicated than it ought.
 
 Here is his version: http://lpaste.net/87625
 
 I just sent you a pull request to add that one and S.toList .
 S.fromList that was suggested in this thread. I don't think those two
 implementations are faster than the others but it's nice to have them
 for completeness.
 
 Jason
 

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Hoogle problems?

2013-07-15 Thread Niklas Hambüchen

OK, but why does it need to go down for migration?

On Mon 15 Jul 2013 23:52:02 SGT, Daniel F wrote:
 The web site is migrating.
 IRC says: Topic for #haskell: haskell.org in the middle of migration;
 expect turbulence; use  www.haskell.org


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] ordNub

2013-07-14 Thread Niklas Hambüchen

tldr: nub is abnormally slow, we shouldn't use it, but we do.


As you might know, Data.List.nub is O(n²). (*)

As you might not know, almost *all* practical Haskell projects use it,
and that in places where an Ord instance is given, e.g. happy, Xmonad,
ghc-mod, Agda, darcs, QuickCheck, yesod, shake, Cabal, haddock, and 600
more (see https://github.com/nh2/haskell-ordnub).

I've taken the Ord-based O(n * log n) implementation from yi using a Set:

  ordNub :: (Ord a) = [a] - [a]
  ordNub l = go empty l
where
  go _ [] = []
  go s (x:xs) = if x `member` s then go s xs
else x : go (insert x s) xs


and put benchmarks on
http://htmlpreview.github.io/?https://github.com/nh2/haskell-ordnub/blob/1f0a2c94a/report.html
(compare `nub` vs `ordNub`).

`ordNub` is not only in a different complexity class, but even seems to
perform better than nub for very small numbers of actually different
list elements (that's the numbers before the benchmark names).

(The benchmark also shows some other potential problem: Using a state
monad to keep the set instead of a function argument can be up to 20
times slower. Should that happen?)

What do you think about ordNub?

I've seen a proposal from 5 years ago about adding a *sort*Nub function
started by Neil, but it just died.


(*) The mentioned complexity is for the (very common) worst case, in
which the number of different elements in the list grows with the list
(alias you don't have an N element list with always only 5 different
things inside).

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ordNub

2013-07-14 Thread Niklas Hambüchen

One of my main points is:

Should we not add such a function (ord-based, same output as nub, 
stable, no sorting) to base?

As the package counting shows, if we don't offer an alternative, people 
obviously use it, and not to our benefit.

(Not to say it this way:
We could make the Haskell world fast with smarter fusion, strictness 
analysis and LLVM backends.
Or we could stop using quadratic algorithms.)

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANN: custom-hackage

2013-06-16 Thread Niklas Hambüchen

Hello Albert,

thanks for this! Please don't be reluctant with this, it is very
appreciated.

I have updated the script to use the paths as you described, and it
seems to work quite well. The fact that all tars land under package/
even makes is easier to use.

It would be great if you could give it another try.

Niklas

On 17/06/13 02:42, Albert Y. C. Lai wrote:
 On 13-06-13 11:09 AM, Niklas Hambüchen wrote:
 https://github.com/nh2/custom-hackage

 An (almost trivial) script to generate 00-index.tar.gz which is
 necessary to run your own `remote-repo`.
 
 I write the following critique with much reluctance, since I will be
 saying a lot of this cannot possibly work, here is why, but I would
 also like to think that it had worked for you before you published it.
 
 Assume the remote-repo line goes like
 
 remote-repo: custom:http://127.0.0.1:8080/packages/archive
 
 And assume it has just one package, formula-1.1
 
 Then your scheme uses this layout:
 
   http://127.0.0.1:8080/00-index.tar.gz
   http://127.0.0.1:8080/packages/archive/formula/1.1/formula-1.1.tar.gz
 
 However, cabal-install expects this layout:
 
   http://127.0.0.1:8080/packages/archive/00-index.tar.gz
   http://127.0.0.1:8080/packages/archive/package/formula-1.1.tar.gz
 
 I know this by both reading cabal-install source code and empirical
 tests, both 0.14 and 1.16.
 
 I have a working example at
 http://www.vex.net/~trebla/haskell/conrepo
 
 Lastly, I want to emphasize these points:
 
 The layout is different from Hackage's; cabal-install source code
 hardcodes treating Hackage differently. Yes, it goes out of its way to
 detect http://hackage.haskell.org/packages/archive; and do a different
 thing. Mimicking Hackage is futile, unless you go out of your way to
 also mimic the host name hackage.haskell.org.
 
 And the layout is different from local-repo's; local-repo's is in fact
 close to Hackage's.
 
 See my
 http://www.vex.net/~trebla/haskell/cabal-cabal.xhtml#remote-repo
 
 
 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell] ANN: custom-hackage

https://github.com/nh2/custom-hackage

An (almost trivial) script to generate 00-index.tar.gz which is
necessary to run your own `remote-repo`.

If you are a company that has to rely on that not everybody with a
Hackage account can run arbitrary code on your computer at your next
cabal install, and you want to make available only select versions of
packages (as opposed to a full hackage mirror), this is for you.

Just drop your tars into the directory structure, run the script and
serve it over HTTP.

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell-cafe] Testing invasive proposals with Hackager

On 13/06/13 10:06, Conrad Parker wrote:
 How do we add packages to the list; do you have a github repo for it?

I've put it on haskell-pkg-janitors:

https://github.com/haskell-pkg-janitors/hackage-build-deps/blob/master/ubuntu-13.04.txt

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Testing invasive proposals with Hackager

On 13/06/13 18:36, Vo Minh Thu wrote:
 For example, here is a run with GHC, no special options and using 4
 threads (note that this generally takes a long time, i.e. a few days):

My builds finished in  10 hours on an i7.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Automating Hackage accounts

 As for the user account creation and uploading packages you don't own,
 Hackage 2 (any day now) has fixes for both.

Does Hackage 2 have SSL at least for the web interface?

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] ANN: custom-hackage

https://github.com/nh2/custom-hackage

An (almost trivial) script to generate 00-index.tar.gz which is
necessary to run your own `remote-repo`.

If you are a company that has to rely on that not everybody with a
Hackage account can run arbitrary code on your computer at your next
cabal install, and you want to make available only select versions of
packages (as opposed to a full hackage mirror), this is for you.

Just drop your tars into the directory structure, run the script and
serve it over HTTP.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Automating Hackage accounts