Re: [Haskell-cafe] Haddock multiple definitions
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 trac account in Haddock to
submit this ticket for me. I apologize for the inconvenience, but,
for privacy concerns, I don't want an account in Haddock trac and it
does not seem possible to submit a ticket without first creating one.
Thanks,
Jose
On Fri, Aug 16, 2013 at 12:51:35AM +0300, Roman Cheplyaka wrote:
In any case, it shouldn't fail with a parse error, since this is valid
Haskell.
Please file a ticket at http://trac.haskell.org/haddock (but first see
if it hasn't been reported before).
Roman
* jabolo...@google.com jabolo...@google.com [2013-08-15 15:24:23-0400]
Hi,
I am using
GHC: 6.12.1
Haddock: 2.6.0
and the following does not work with Haddock (GHC is fine!):
-- Main
-- | Blah blah blah
(x, y, z) = (1, 2, 3)
$ haddock ...
/tmp/Main.hs:2:0: parse error on input `('
Is this a bug? Or it's just not part of Haddock?
This seems like an interesting feature to document several definitions
together, for example, error codes:
-- | Syscall error codes for blah...
--
-- errA when blah
-- ...
(errA, errB, errC) = ...
Cheers,
Jose
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
have any idea where to link ‘y’ (but it does know it's in scope c). I
think this behaviour is understandable considering that ‘x’ is the
first ‘function’ after Haddock comments so the comment belongs to ’x’.
If you want a different behaviour, please file an enhancement request
against a recent version to have it considered.
I don't understand your concern over privacy in this case: you're
getting a lot more exposure just posting on café than you ever would
by posting directly on the low-traffic Haddock Trac. You're free to
register with a temporary e-mail.
http://trac.haskell.org/haddock
--
Mateusz K.
0x2ADA9A97.asc
Description: application/pgp-keys
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haddock multiple definitions
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 have any idea where to link ‘y’ (but it does know it's in scope c). I think this behaviour is understandable considering that ‘x’ is the first ‘function’ after Haddock comments so the comment belongs to ’x’. If you want a different behaviour, please file an enhancement request against a recent version to have it considered. I would like to add onto this that we can actually get the Haddock documentation generated for ‘y’ by exporting it in the module and then we can easily link to it, you're simply not getting the Haddock comment along. I don't understand your concern over privacy in this case: you're getting a lot more exposure just posting on café than you ever would by posting directly on the low-traffic Haddock Trac. You're free to register with a temporary e-mail. http://trac.haskell.org/haddock Apologies for consecutive posts. -- Mateusz K. 0x2ADA9A97.asc Description: application/pgp-keys ___ 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
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
[Haskell-cafe] Does exist something like data-files in Cabal, which works at compile time?
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 As someone states, data-files in for run-time, whereas I need to tell cabal please copy these files in place before trying to compile, so at compile-time. Does something similar exist? I think the best solution, unless someone prove me wrong, is to create a small startup script which copies the files for me (I *think* yesod is using something similar, namely a script called EmbeddedFiles.hs) and then triggers cabal install the usual way. Can you come up with a better way? Thanks in advance! Alfredo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haddock multiple definitions
* Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk [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 haddock.hs
haddock.hs:4:1: parse error on input `('
% haddock --version
Haddock version 2.13.2, (c) Simon Marlow 2006
Ported to use the GHC API by David Waern 2006-2008
It's great that it's fixed in HEAD.
Roman
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Does exist something like data-files in Cabal, which works at compile time?
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 Díaz. 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 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 As someone states, data-files in for run-time, whereas I need to tell cabal please copy these files in place before trying to compile, so at compile-time. Does something similar exist? I think the best solution, unless someone prove me wrong, is to create a small startup script which copies the files for me (I *think* yesod is using something similar, namely a script called EmbeddedFiles.hs) and then triggers cabal install the usual way. Can you come up with a better way? Thanks in advance! Alfredo ___ 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] Does exist something like data-files in Cabal, which works at compile time?
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 dhelta.d...@gmail.com wrote: 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 Díaz. 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 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 As someone states, data-files in for run-time, whereas I need to tell cabal please copy these files in place before trying to compile, so at compile-time. Does something similar exist? I think the best solution, unless someone prove me wrong, is to create a small startup script which copies the files for me (I *think* yesod is using something similar, namely a script called EmbeddedFiles.hs) and then triggers cabal install the usual way. Can you come up with a better way? Thanks in advance! Alfredo ___ 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] Does exist something like data-files in Cabal, which works at compile time?
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 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 As someone states, data-files in for run-time, whereas I need to tell cabal please copy these files in place before trying to compile, so at compile-time. Does something similar exist? I think the best solution, unless someone prove me wrong, is to create a small startup script which copies the files for me (I *think* yesod is using something similar, namely a script called EmbeddedFiles.hs) and then triggers cabal install the usual way. Can you come up with a better way? Thanks in advance! Alfredo ___ 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] Does exist something like data-files in Cabal, which works at compile time?
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.Package
import Distribution.Simple
import Distribution.Simple.LocalBuildInfo
import Distribution.Simple.Setup
import Distribution.Verbosity
import Distribution.Simple.Utils
import Paths_myproject
main :: IO ()
main = defaultMainWithHooks myHooks
where myHooks = simpleUserHooks { preBuild = copyResources }
copyResources :: Args
- BuildFlags
- IO HookedBuildInfo
copyResources args flags = do
installDir - getDataDir
installDirectoryContents verbose resources (installDir ++ /resources)
return emptyHookedBuildInfo
where myproject should be the name of your project, as in myproject.cabal.
On 16 August 2013 13:11, Dag Odenhall dag.odenh...@gmail.com wrote:
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 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
As someone states, data-files in for run-time, whereas I need to tell
cabal please copy these files in place before trying to compile, so at
compile-time.
Does something similar exist?
I think the best solution, unless someone prove me wrong, is to create a
small startup script which copies the files for me (I *think* yesod is
using something similar, namely a script called EmbeddedFiles.hs) and then
triggers cabal install the usual way. Can you come up with a better way?
Thanks in advance!
Alfredo
___
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-cafe] Applicative is like an Arrow
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-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Applicative is like an Arrow
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 evoh...@gmail.com 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. Please, enlight me. ___ 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] Applicative is like an Arrow
On Fri, Aug 16, 2013 at 10:04 AM, Thiago Negri evoh...@gmail.com 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. Practically, that's not too far off. Arrows, at least as implemented currently, have a number of significant restrictions based on the need for the `arr` combinator to accomplish much of anything; Applicative has, as a result, largely taken over the spot in the Haskell ecosystem that Arrow was originally intended to fill. 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. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Applicative is like an Arrow
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 that if you can provide any references. I am using arrows very heavily. Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Applicative is like an Arrow
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 are more distinct, flexible and useful than the current implementation. I'd like to know more about that if you can provide any references. I am using arrows very heavily. It's been mentioned (but not much more) in #haskell IRC, so I don't know details. I also expect it's not going to simply replace the current one, at least not initially; and I think it's supposed to maintain compatibility with the current Arrow because that's just a specialization to the function arrow. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] One-element tuple
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! () -- nople (That is, it's annoying if you're trying to make typeclass instances for extensible/contractable tuples. Yes, I know I could use HLists.) I'm not happy with either approach I've tried: data Oneple a = Oneple a -- (or newtype) (Oneple $ CustId 47) -- too verbose type Oneple a = [a] [CustId 47] -- at least looks bracket-y What do you do? This is what the OneTuple package is for: http://hackage.haskell.org/package/OneTuple -Brent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Call for participation IFL 2013
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 registration still open] We are proud to announce that the 25th edition of the IFL series returns to its roots at the Radboud University Nijmegen in the Netherlands. The symposium is held from 28th to 30th of August 2013. Scope - The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2013 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. Following the IFL tradition, IFL 2013 will use a post-symposium review process to produce the formal proceedings which will be published in the ACM Digital Library. All participants of IFL 2013 are invited to submit either a draft paper or an extended abstract describing work to be presented at the symposium. At no time may work submitted to IFL be simultaneously submitted to other venues; submissions must adhere to ACM SIGPLAN's republication policy: http://www.sigplan.org/Resources/Policies/Republication The submissions will be screened by the program committee chair to make sure they are within the scope of IFL, and will appear in the draft proceedings distributed at the symposium. Submissions appearing in the draft proceedings are not peer-reviewed publications. Hence, publications that appear only in the draft proceedings do not count as publication for the ACM SIGPLAN republication policy. After the symposium, authors will be given the opportunity to incorporate the feedback from discussions at the symposium and will be invited to submit a revised full article for the formal review process. From the revised submissions, the program committee will select papers for the formal proceedings considering their correctness, novelty, originality, relevance, significance, and clarity. Invited Speaker --- Lennart Augustsson, currently employed by the Standard Chartered Bank, well-known for his work on Haskell, parallel Haskell, Cayenne, and Bluespec, is the invited speaker of IFL 2013. The title and abstract of his talk is: Implementation and Application of Functional Languages - A personal perspective It is now over 30 years ago since I implemented my first functional language, and over 15 years ago since I wrote my first commercial application. In this talk I will look back to those bygone days and remind you of things that you might have forgotten or never known. The talk will be absolutely free of anything new. Peter Landin Prize -- The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honoured article is selected by the program committee based on the submissions received for the formal review process. The prize carries a cash award equivalent to 150 Euros. Programme committee --- Thomas Arts, Quviq, Gothenburg, Sweden Andrew Butterfield, Trinity College, Dublin, Ireland Edwin Brady, University of St. Andrews, UK Clemens Grelck, University of Amsterdam, Netherlands Adam Granicz, IntelliFactory, Budapest, Hungary Jeremy Gibbons, University of Oxford, UK Fritz Henglein, University of Copenhagen, Denmark Stephan Herhut, Intel Labs, Santa Clara, US Ralf Hinze (co-chair), University of Oxford, UK Zoltán Horváth, Eötvös Loránd University, Budapest, Hungary Zhenjiang Hu, University of Tokyo, Japan Mauro Jaskelioff, Universidad Nacional de Rosario, Argentina Johan Jeuring, University of Utrecht, Netherlands Rita Loogen, University of Marburg, Germany Marco T. Morazán, Seton Hall University, New Jersey, US Dominic Orchard, University of Cambridge, UK Rinus Plasmeijer (chair), Radboud University Nijmegen, Netherlands Tim Sheard, Portland State University, US Sam Tobin-Hochstadt, Northeastern University / Indiana University, US Peter Thiemann, University of Freiburg, Germany Simon Thompson, University of Kent, UK Venue - The 25th IFL is organized by the Radboud University Nijmegen, Model Based Software Development Department at the Nijmegen Institute for Computing and Information Sciences. The event is held in the Landgoed Holthurnsche Hof, a rural estate in the woodlands surrounding Nijmegen. It can be reached quickly and easily by public transport. Program --- Wednesday August 28 --- 8:15 registration 8:50 opening 9:00 Marcos Viera First Class Syntax, Semantics, and Their Composition Doaitse Swierstra 9:25
Re: [Haskell-cafe] Haddock multiple definitions
On 16/08/13 11:08, Roman Cheplyaka wrote:
* Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk [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 haddock.hs
haddock.hs:4:1: parse error on input `('
% haddock --version
Haddock version 2.13.2, (c) Simon Marlow 2006
Ported to use the GHC API by David Waern 2006-2008
It's great that it's fixed in HEAD.
Roman
Strange.
/tmp $ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.6.3
/tmp $ cat Test.hs
module Main (main, y, x) where
-- | this is a main 123 function
main :: IO ()
main = return ()
-- | Haddock likes 'y' and 'x', 'foobar'
(x, y) = (1, 2)
/tmp $ ghc Test.hs
[1 of 1] Compiling Main ( Test.hs, Test.o )
Linking Test ...
/tmp $ haddock --version
Haddock version 2.13.2, (c) Simon Marlow 2006
Ported to use the GHC API by David Waern 2006-2008
/tmp $ haddock Test.hs --html
Haddock coverage:
Warning: Couldn't find .haddock for export Main.y
50% ( 2 / 4) in 'Main'
Warning: Main: could not find link destinations for:
GHC.Types.IO GHC.Integer.Type.Integer
/tmp $
Well, it's a high possibility that my Haddock version isn't the stock
one that comes with 7.6.3. In any case, I'm glad that you say it's
fixed in HEAD. Thanks for checking.
--
Mateusz K.
0x2ADA9A97.asc
Description: application/pgp-keys
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Applicative is like an Arrow
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 have an automatic instance for Applicative, which I brought up about a month ago on reddit: http://www.reddit.com/r/haskell/comments/1ivd23/default_functor_and_applicative_instances_for/ -- Dan Burton On Fri, Aug 16, 2013 at 7:52 AM, Brandon Allbery allber...@gmail.comwrote: 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 are more distinct, flexible and useful than the current implementation. I'd like to know more about that if you can provide any references. I am using arrows very heavily. It's been mentioned (but not much more) in #haskell IRC, so I don't know details. I also expect it's not going to simply replace the current one, at least not initially; and I think it's supposed to maintain compatibility with the current Arrow because that's just a specialization to the function arrow. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net ___ 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] Applicative is like an Arrow
Thiago Negri evoh...@gmail.com 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 out this paper: http://homepages.inf.ed.ac.uk/slindley/papers/idioms-arrows-monads.pdf In short: arrows are a bit more powerful than idioms (applicative) but a bit less than monads. However, power sometimes comes at a price. All 3 have to do with combining / sequencing effects, but they differ in subtle but important ways. Every idiom is an arrow and every arrow is a monad, but not the other way around. I will first give an overview of the differences, then try to explain what I mean... (my terminology might be a bit awkward/wrong) Idiom: Basic combining strategy: i (a - b) - i a - i b Sequencing: effects are applied in sequence values (stuff inside) are isolated Shape depends on values: no Arrow: Basic combining strategy: a b c - a c d - a b d Sequencing: effects are applied in sequence values are sequenced too values can see upstream results Shape depends on values: static choices only Monad: Basic combining strategy: m a - (a - m b) - m b Sequencing: effects are applied in sequence values are sequenced too values can see upstream results Shape depends on values: yes, fully dynamic Now, what do I mean by all this? Basically these 3 abstractions consist of 3 things: - effects - values - shape Effects can be things like carries state around(State), can fail(Maybe), multiple answers(List) and more. Values are the pure stuff inside, and what I call 'shape' is the general control flow of a computation. Furthermore, I visualize these abstractions by thinking of a factory hall with boxes (values), people (effects) and an assembly line (shape). Idioms are fully static: values cannot see/depend on each other or on the result of effects. Basically the computation is split into 2 phases: - effects+gather - apply gathered results example: pure (+) * Just 3 * Just 5 The first phase just works through the parts (in sequence) and collects the (pure) contents. In this case (Maybe) this means looking for the Just constructor to continue, or halting on Nothing. The content inside is being treated like a black box. It is not made aware of the effects (whether or not Nothing was found somewhere) and it is not being examined to choose a different codepath. Then if everything worked out (no Nothings were found), the collected results are taken out of their black boxes and applied. In this phase these results (the +, the 3 and the 5) don't know anything about the effects that happened. In factory visualization: every part of the computation (stuff between *) is a person that will need to perform some task(effect) and deliver some result in a box. They will only start performing their task when they see a box passing by from the person upstream. They cannot look in that box or make decisions based on it or take it off. At the end of the line, some manager receives all the boxes and opens them to combine the results. This is fine for a whole lot of applications and has the advantage that the shape of the entire assembly line is clear even before starting it. This means (static) optimization can be performed and it's easy to reason about the program/costs. Garbage collection (sending workers home) is easier, because it's very clear what data is needed where and when. I will talk a bit more about these optimizations a bit further down. Of course this assembly line is not flexible enough for more advanced cases. Let's see an example of that(State): pure const * get * put 8 This is a perfectly fine idiom, albeit not very useful. When run (with initial state 4) the first worker will package up a box with const and send it downstream. The second worker gets the seeded state from the state cupboard and put it in a box (4). When that box passes by worker 3, he will walk to the state cupboard and put 8 in it. Then to signal he's ready, he packs a box with (). At the end of the line, someone opens the boxes const 4 and (), which computes to just 4. So we end up with the answer 4 and an updated cupboard containing 8. Why is this not very useful? Well we would probably want to be able to put state in that depends on certain stuff we got out earlier, instead of just supplying a hard coded 8 that was known before starting the line. Unfortunately, this is not possible with idioms as workers cannot open each other's boxes. Now, let's skip Arrows for a minute and move straight to Monads: get = \x - put (x + 1) return x As you can see, monads tackle this issue by putting everything in sequence. Not just the effects, but values too. Like this, they can see upstream values and upstream effects and influence the effects and shape of things to come further downstream.
Re: [Haskell-cafe] Applicative is like an Arrow
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 Mathijs Kwik math...@bluescreen303.nl Thiago Negri evoh...@gmail.com 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 out this paper: http://homepages.inf.ed.ac.uk/slindley/papers/idioms-arrows-monads.pdf In short: arrows are a bit more powerful than idioms (applicative) but a bit less than monads. However, power sometimes comes at a price. All 3 have to do with combining / sequencing effects, but they differ in subtle but important ways. Every idiom is an arrow and every arrow is a monad, but not the other way around. I will first give an overview of the differences, then try to explain what I mean... (my terminology might be a bit awkward/wrong) Idiom: Basic combining strategy: i (a - b) - i a - i b Sequencing: effects are applied in sequence values (stuff inside) are isolated Shape depends on values: no Arrow: Basic combining strategy: a b c - a c d - a b d Sequencing: effects are applied in sequence values are sequenced too values can see upstream results Shape depends on values: static choices only Monad: Basic combining strategy: m a - (a - m b) - m b Sequencing: effects are applied in sequence values are sequenced too values can see upstream results Shape depends on values: yes, fully dynamic Now, what do I mean by all this? Basically these 3 abstractions consist of 3 things: - effects - values - shape Effects can be things like carries state around(State), can fail(Maybe), multiple answers(List) and more. Values are the pure stuff inside, and what I call 'shape' is the general control flow of a computation. Furthermore, I visualize these abstractions by thinking of a factory hall with boxes (values), people (effects) and an assembly line (shape). Idioms are fully static: values cannot see/depend on each other or on the result of effects. Basically the computation is split into 2 phases: - effects+gather - apply gathered results example: pure (+) * Just 3 * Just 5 The first phase just works through the parts (in sequence) and collects the (pure) contents. In this case (Maybe) this means looking for the Just constructor to continue, or halting on Nothing. The content inside is being treated like a black box. It is not made aware of the effects (whether or not Nothing was found somewhere) and it is not being examined to choose a different codepath. Then if everything worked out (no Nothings were found), the collected results are taken out of their black boxes and applied. In this phase these results (the +, the 3 and the 5) don't know anything about the effects that happened. In factory visualization: every part of the computation (stuff between *) is a person that will need to perform some task(effect) and deliver some result in a box. They will only start performing their task when they see a box passing by from the person upstream. They cannot look in that box or make decisions based on it or take it off. At the end of the line, some manager receives all the boxes and opens them to combine the results. This is fine for a whole lot of applications and has the advantage that the shape of the entire assembly line is clear even before starting it. This means (static) optimization can be performed and it's easy to reason about the program/costs. Garbage collection (sending workers home) is easier, because it's very clear what data is needed where and when. I will talk a bit more about these optimizations a bit further down. Of course this assembly line is not flexible enough for more advanced cases. Let's see an example of that(State): pure const * get * put 8 This is a perfectly fine idiom, albeit not very useful. When run (with initial state 4) the first worker will package up a box with const and send it downstream. The second worker gets the seeded state from the state cupboard and put it in a box (4). When that box passes by worker 3, he will walk to the state cupboard and put 8 in it. Then to signal he's ready, he packs a box with (). At the end of the line, someone opens the boxes const 4 and (), which computes to just 4. So we end up with the answer 4 and an updated cupboard containing 8. Why is this not very useful? Well we would probably want to be able to put state in that depends on certain stuff we got out earlier, instead of just supplying a hard coded 8 that was known before starting the line. Unfortunately,
Re: [Haskell-cafe] Applicative is like an Arrow
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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Applicative is like an Arrow
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 of the Arrow are also in scope. This really helped solidify the idea in my head that the shape of the factory only makes static choices, because all of the Arrow-y processing happens between - and - -- Dan Burton On Fri, Aug 16, 2013 at 12:37 PM, Mathijs Kwik math...@bluescreen303.nlwrote: Thiago Negri evoh...@gmail.com 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 out this paper: http://homepages.inf.ed.ac.uk/slindley/papers/idioms-arrows-monads.pdf In short: arrows are a bit more powerful than idioms (applicative) but a bit less than monads. However, power sometimes comes at a price. All 3 have to do with combining / sequencing effects, but they differ in subtle but important ways. Every idiom is an arrow and every arrow is a monad, but not the other way around. I will first give an overview of the differences, then try to explain what I mean... (my terminology might be a bit awkward/wrong) Idiom: Basic combining strategy: i (a - b) - i a - i b Sequencing: effects are applied in sequence values (stuff inside) are isolated Shape depends on values: no Arrow: Basic combining strategy: a b c - a c d - a b d Sequencing: effects are applied in sequence values are sequenced too values can see upstream results Shape depends on values: static choices only Monad: Basic combining strategy: m a - (a - m b) - m b Sequencing: effects are applied in sequence values are sequenced too values can see upstream results Shape depends on values: yes, fully dynamic Now, what do I mean by all this? Basically these 3 abstractions consist of 3 things: - effects - values - shape Effects can be things like carries state around(State), can fail(Maybe), multiple answers(List) and more. Values are the pure stuff inside, and what I call 'shape' is the general control flow of a computation. Furthermore, I visualize these abstractions by thinking of a factory hall with boxes (values), people (effects) and an assembly line (shape). Idioms are fully static: values cannot see/depend on each other or on the result of effects. Basically the computation is split into 2 phases: - effects+gather - apply gathered results example: pure (+) * Just 3 * Just 5 The first phase just works through the parts (in sequence) and collects the (pure) contents. In this case (Maybe) this means looking for the Just constructor to continue, or halting on Nothing. The content inside is being treated like a black box. It is not made aware of the effects (whether or not Nothing was found somewhere) and it is not being examined to choose a different codepath. Then if everything worked out (no Nothings were found), the collected results are taken out of their black boxes and applied. In this phase these results (the +, the 3 and the 5) don't know anything about the effects that happened. In factory visualization: every part of the computation (stuff between *) is a person that will need to perform some task(effect) and deliver some result in a box. They will only start performing their task when they see a box passing by from the person upstream. They cannot look in that box or make decisions based on it or take it off. At the end of the line, some manager receives all the boxes and opens them to combine the results. This is fine for a whole lot of applications and has the advantage that the shape of the entire assembly line is clear even before starting it. This means (static) optimization can be performed and it's easy to reason about the program/costs. Garbage collection (sending workers home) is easier, because it's very clear what data is needed where and when. I will talk a bit more about these optimizations a bit further down. Of course this assembly line is not flexible enough for more advanced cases. Let's see an example of that(State): pure const * get * put 8 This is a perfectly fine idiom, albeit not very useful. When run (with initial state 4) the first worker will package up a box with const and send it downstream. The second worker gets the seeded state from the state cupboard and put it in a box (4). When that box passes by worker 3, he will walk to the state cupboard and put 8 in it. Then to signal he's ready, he packs a box with (). At the end of the line, someone opens the boxes const 4 and (), which computes to just 4. So we end up with the answer 4 and an updated
Re: [Haskell-cafe] Applicative is like an Arrow
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 if I am wrong) I wonder, where and how the Monad transformers fit in here? Thanks and regards, -Damodar Kulkarni On Sat, Aug 17, 2013 at 1:07 AM, Mathijs Kwik math...@bluescreen303.nlwrote: Thiago Negri evoh...@gmail.com 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 out this paper: http://homepages.inf.ed.ac.uk/slindley/papers/idioms-arrows-monads.pdf In short: arrows are a bit more powerful than idioms (applicative) but a bit less than monads. However, power sometimes comes at a price. All 3 have to do with combining / sequencing effects, but they differ in subtle but important ways. Every idiom is an arrow and every arrow is a monad, but not the other way around. I will first give an overview of the differences, then try to explain what I mean... (my terminology might be a bit awkward/wrong) Idiom: Basic combining strategy: i (a - b) - i a - i b Sequencing: effects are applied in sequence values (stuff inside) are isolated Shape depends on values: no Arrow: Basic combining strategy: a b c - a c d - a b d Sequencing: effects are applied in sequence values are sequenced too values can see upstream results Shape depends on values: static choices only Monad: Basic combining strategy: m a - (a - m b) - m b Sequencing: effects are applied in sequence values are sequenced too values can see upstream results Shape depends on values: yes, fully dynamic Now, what do I mean by all this? Basically these 3 abstractions consist of 3 things: - effects - values - shape Effects can be things like carries state around(State), can fail(Maybe), multiple answers(List) and more. Values are the pure stuff inside, and what I call 'shape' is the general control flow of a computation. Furthermore, I visualize these abstractions by thinking of a factory hall with boxes (values), people (effects) and an assembly line (shape). Idioms are fully static: values cannot see/depend on each other or on the result of effects. Basically the computation is split into 2 phases: - effects+gather - apply gathered results example: pure (+) * Just 3 * Just 5 The first phase just works through the parts (in sequence) and collects the (pure) contents. In this case (Maybe) this means looking for the Just constructor to continue, or halting on Nothing. The content inside is being treated like a black box. It is not made aware of the effects (whether or not Nothing was found somewhere) and it is not being examined to choose a different codepath. Then if everything worked out (no Nothings were found), the collected results are taken out of their black boxes and applied. In this phase these results (the +, the 3 and the 5) don't know anything about the effects that happened. In factory visualization: every part of the computation (stuff between *) is a person that will need to perform some task(effect) and deliver some result in a box. They will only start performing their task when they see a box passing by from the person upstream. They cannot look in that box or make decisions based on it or take it off. At the end of the line, some manager receives all the boxes and opens them to combine the results. This is fine for a whole lot of applications and has the advantage that the shape of the entire assembly line is clear even before starting it. This means (static) optimization can be performed and it's easy to reason about the program/costs. Garbage collection (sending workers home) is easier, because it's very clear what data is needed where and when. I will talk a bit more about these optimizations a bit further down. Of course this assembly line is not flexible enough for more advanced cases. Let's see an example of that(State): pure const * get * put 8 This is a perfectly fine idiom, albeit not very useful. When run (with initial state 4) the first worker will package up a box with const and send it downstream. The second worker gets the seeded state from the state cupboard and put it in a box (4). When that box passes by worker 3, he will walk to the state cupboard and put 8 in it. Then to signal he's ready, he packs a box with (). At the end of the line, someone opens the boxes const 4 and (), which computes to just 4. So we end up with the answer 4 and an updated cupboard containing 8. Why is this not very useful? Well we would probably want to be able to put state
