On 15/08/13 23:07, jabolo...@google.com wrote:
> Hi,
>
> I cannot find a similar ticket, so it seems that no one has filed this
> issue before. As a general comment, I think this issue is a good
> example that perhaps docstrings should go in the AST.
>
> In any case, I would ask someone with a tra
On 16/08/13 08:16, Mateusz Kowalczyk wrote:
> In the future, please try with more recent version of GHC.
>
> This is no longer a parse error with HEAD or 7.6.3. Instead, given
>
> -- | 'y' and 'x' are here
> (x, y) = (1, 2)
>
> you get documentation generated for ‘x’ and Haddock doesn't seem to
>
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
wrote:
>
Hello guys,
I'm pretty sure the answer is "no", but I was hoping to get some extra
insight / best practices. The problem can be summarised by this SO question
(not the OP, but I have the same problem):
http://stackoverflow.com/questions/15731170/cabal-how-to-add-text-file-as-a-build-dependency
A
* Mateusz Kowalczyk [2013-08-16 08:16:35+0100]
> In the future, please try with more recent version of GHC.
>
> This is no longer a parse error with HEAD or 7.6.3.
Uhm, actually there is, with 7.6.3.
% cat haddock.hs
-- Main
-- | Blah blah blah
(x, y, z) = (1, 2, 3)
% haddock ha
What I have always done to solve this is to create a custom Setup.hs.
Something like:
Setup.hs
-
import Distribution.Simple
main :: IO ()
main = doThisBeforeInstall >> defaultMain
-
Then you specify in your .cabal file that the Build-Type is Custom.
Best regards,
Daniel
Hi Daniel,
It's the path I've eventually took as well.
Many thanks,
Sent from my iPad
On 16/ago/2013, at 11:13, Daniel Díaz Casanueva wrote:
> What I have always done to solve this is to create a custom Setup.hs.
> Something like:
>
> Setup.hs
> -
> import Distribution.Simple
>
You want extra-source-files. They'll be included in the tarball, and cabal
always builds from the root of the package, so you can safely use relative
paths.
On Fri, Aug 16, 2013 at 11:58 AM, Alfredo Di Napoli <
alfredo.dinap...@gmail.com> wrote:
> Hello guys,
>
> I'm pretty sure the answer is "n
Thanks Dag, I'll give it a spin. Btw, I've successfully solved my problem
with the following Setup.hs, I'm posting it here in case someone will find
this useful in the future:
#!/usr/bin/env runhaskell
> import Distribution.Simple
> import Distribution.PackageDescription
> import Distribution.Pack
I just stumbled upon the Applicative term.
Arrows are quite difficult for me to understand at the moment.
I guess it needs time to digest.
But, as I understand so far, Applicative and Arrows looks like the same
thing.
Please, enlight me.
___
Haskell-Caf
Whenever I am confused I refer to this article
http://www.haskell.org/haskellwiki/Typeclassopedia#Arrow
-Satvik
On Fri, Aug 16, 2013 at 7:34 PM, Thiago Negri wrote:
> I just stumbled upon the Applicative term.
> Arrows are quite difficult for me to understand at the moment.
> I guess it needs
On Fri, Aug 16, 2013 at 10:04 AM, Thiago Negri wrote:
> I just stumbled upon the Applicative term.
> Arrows are quite difficult for me to understand at the moment.
> I guess it needs time to digest.
>
> But, as I understand so far, Applicative and Arrows looks like the same
> thing.
>
Practicall
On Fri, Aug 16, 2013 at 10:26:42AM -0400, Brandon Allbery wrote:
> My understanding is that there's a rework of Arrow in progress that may
> change this in the future, since *theoretical* Arrows are more distinct,
> flexible and useful than the current implementation.
I'd like to know more about t
On Fri, Aug 16, 2013 at 10:49 AM, Tom Ellis <
tom-lists-haskell-cafe-2...@jaguarpaw.co.uk> wrote:
> On Fri, Aug 16, 2013 at 10:26:42AM -0400, Brandon Allbery wrote:
> > My understanding is that there's a rework of Arrow in progress that may
> > change this in the future, since *theoretical* Arrows
On Fri, Aug 16, 2013 at 01:35:22AM +, AntC wrote:
> There's an annoying inconsistency:
>
> (CustId 47, CustName "Fred", Gender Male) -- threeple
> (CustId 47, CustName "Fred)-- twople
> -- (CustId 47)-- oneple not!
> ()
CALL FOR PARTICIPATION
25th SYMPOSIUM ON IMPLEMENTATION AND APPLICATION OF FUNCTIONAL LANGUAGES - IFL
2013
RADBOUD UNIVERSITY NIJMEGEN, THE NETHERLANDS
ACM In-Cooperation / ACM SIGPLAN
AUGUST 28 - 30 2013
"Landgoed Holthurnsche Hof"
http://ifl2013.cs.ru.nl
[program available - late registrat
On 16/08/13 11:08, Roman Cheplyaka wrote:
> * Mateusz Kowalczyk [2013-08-16 08:16:35+0100]
>> In the future, please try with more recent version of GHC.
>>
>> This is no longer a parse error with HEAD or 7.6.3.
>
> Uhm, actually there is, with 7.6.3.
>
> % cat haddock.hs
> -- Main
>
> -- | B
You may be interested in this paper:
Idioms are oblivious, arrows are meticulous, monads are promiscuous
http://homepages.inf.ed.ac.uk/wadler/papers/arrows-and-idioms/arrows-and-idioms.pdf
"Idioms" refers to the Applicative class.
To put it briefly, if you have an instance of Arrow, you also hav
Thiago Negri writes:
> I just stumbled upon the Applicative term.
> Arrows are quite difficult for me to understand at the moment.
> I guess it needs time to digest.
>
> But, as I understand so far, Applicative and Arrows looks like the same
> thing.
>
> Please, enlight me.
I would like to point
You just made my day.
I was trying to understand these things so hard and couldn't get it.
Your analogies were brilliant.
I'll read all links/papers posted here to get a deeper understanding of
these things.
I'll just skip dependently typed stuff for now, heh.
Thank you,
Thiago.
2013/8/16 Math
On 13-08-16 03:29 PM, Dan Burton wrote:
Idioms are oblivious, arrows are meticulous, monads are promiscuous
http://homepages.inf.ed.ac.uk/wadler/papers/arrows-and-idioms/arrows-and-idioms.pdf
I much recommend this paper. Underrated, underknown, pinpointing, unifying.
__
Reading that blog post Mathijs linked, I had a big "ah-hah" moment when I
read this:
This is why arrow-notation creates two scopes. Between the <- -< symbols,
> only values that were in scope before execution of the Arrow are in scope.
> Outside the <- -<, values that appear during the execution o
Thanks for this nice analogy and explanation. This brings "monad
transformers" to my mind.
"without" monad transformers, the monads are bit crippled in their
applicability (please correct me if I am wrong)
and
"with" monad transformers the code becomes to some extent ugly (again,
please correct me
23 matches
Mail list logo
