Re: [Haskell-cafe] what's the best environment for haskell work?
On Mon, Aug 2, 2010 at 4:12 PM, Phyx loneti...@gmail.com wrote: I've tried to use leksah but some minor annoying things make it unusable for me. I'm curious, what are those minor annoying things? Trying code completion in comments on string constants, for example. Code completion makes the text jump if you're editing near the bottom of the editor area. I like the tocandy feature but then it breaks alignment if you open the file in another editor. Something probably fixable by editing the candy file. I'am a bit lost between Workspace and Package, especially when all I want is write a quick single-source haskell program. That's all I can think of right now, I've exagerated a bit when I said unusable. Leksah is going to be an awesome editor, it's just not ready yet for me. David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Fw: Re: [Haskell-cafe] Re: Announce snm-0.0.2: The Simple Nice-Looking Manual Generator
The following message was sent to me, but was apparently intended for this thread, so I am forwarding it to the Haskell-Cafe Mailing List: On Mon, Aug. 2, 2010 at 11:44 PM, Gordon Sommers gordon.somm...@gmail.com wrote: This looks pretty neat! The website would benefit from one or two full-size examples I think. A good example is the classgen documentation -- they have a series of pages on the specific features, all with small examples, but then they also have some full examples like so: http://classgen.sourceforge.net/docs/ex1.html, which provide a great starting place. On Thu, Jul 29, 2010 at 5:45 PM, Benjamin L. Russell dekudekup...@yahoo.com wrote: Johnny Morrice sp...@killersmurf.com writes: [...] snm allows you to write clean, web-friendly reports, user guides and manuals without having to edit fickle html. Interesting project! Unlike some users, I happen to enjoy writing documentation. Perhaps you should also announce this project on the main Haskell mailing list. [...] Read the snm user guide here: http://www.killersmurf.com/static/snm_help.html 2. What snm does not do and is not [...] snm is not an adult activity. Hmm ... the term adult activity could mean many different things ... what one did you mean? Thank you for the many examples in your user guide; they help clarify usage. -- Benjamin L. Russell -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 Furuike ya, kawazu tobikomu mizu no oto. -- Matsuo Basho^ ___ 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] Re: (kein Betreff)
Stefan Holdermans wrote: The point of this discussion is that the Eval constraint needs to be on one of the functions. So I tried to specify that (x - Int) and (y - Int) are different types despite x and y being the same type, because one of them has an Eval constraint. This may be a shortcoming of Haskell (or System Fc?) types, although it may be doable with a newtype. That was kind of what my thinking out loud was getting at. If you want x - Int and y - Int to be different types even if x and y actually are the same type, then apparently you want x - Int and y - Int to be built from different function-space constructors, say - and -*, yielding x - Int and y -* Int. Replacing equals for equals again, you get x - Int and x -* Int. So, basically, we are annotating function types, what is IIRC exactly what Janis and David are doing. (I hope Janis corrects me if I'm wrong here). Wrong only in that David's name is Daniel. :-) Other than that, I agree. Best, Janis. -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:j...@iai.uni-bonn.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: (kein Betreff)
Janis, So, basically, we are annotating function types, what is IIRC exactly what Janis and David are doing. (I hope Janis corrects me if I'm wrong here). Wrong only in that David's name is Daniel. :-) Ah, I am terribly sorry. I just shouldn't type e-mails after having no more than a single cup of coffee. ;-) Cheers, Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: DSTM 0.1.1
Hi, DSTM is an implementation of a robust distributed Software Transactional Memory (STM) library for Haskell. Many real-life applications are distributed by nature. Concurrent applications may profit from robustness added by re-implementation as distributed applications. DSTM extends the STM abstraction to distributed systems and presents an implementation efficient enough to be used in soft real-time applications. Further, the implemented library is robust in itself, offering the application developer a high abstraction level to realize robustness, hence, significantly simplifying this, in general, complex task. The DSTM package consists of the DSTM library, a name server application, and three sample distributed programs using the library. Provided are a simple Dining Philosophers, a Chat, and a soft real-time Bomberman game application. Distributed communication is transparent to the application programmer. The application designer uses a very simple name server mechanism to set up the system. The DSTM library includes the management of unavailable process nodes and provides the application with abstract error information thus facilitating the implementation of robust distributed application programs. For usage please look into the documentation file: DSTMManual.pdf. The package including the documentation can be found on: http://hackage.haskell.org/package/DSTM-0.1.1 Best regards, Frank Kupke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: DSTM 0.1.1
This is very cool, thanks for writing it. I will try it when I get home tonight. On 3 August 2010 10:35, Frank Kupke f...@informatik.uni-kiel.de wrote: Hi, DSTM is an implementation of a robust distributed Software Transactional Memory (STM) library for Haskell. Many real-life applications are distributed by nature. Concurrent applications may profit from robustness added by re-implementation as distributed applications. DSTM extends the STM abstraction to distributed systems and presents an implementation efficient enough to be used in soft real-time applications. Further, the implemented library is robust in itself, offering the application developer a high abstraction level to realize robustness, hence, significantly simplifying this, in general, complex task. The DSTM package consists of the DSTM library, a name server application, and three sample distributed programs using the library. Provided are a simple Dining Philosophers, a Chat, and a soft real-time Bomberman game application. Distributed communication is transparent to the application programmer. The application designer uses a very simple name server mechanism to set up the system. The DSTM library includes the management of unavailable process nodes and provides the application with abstract error information thus facilitating the implementation of robust distributed application programs. For usage please look into the documentation file: DSTMManual.pdf. The package including the documentation can be found on: http://hackage.haskell.org/package/DSTM-0.1.1 Best regards, Frank Kupke ___ 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] Maybe to Either -- is there a better way?
Tom Davies wrote: I find it convenient sometimes to convert a Maybe value to an Either maybeToEither = flip maybe Right . Left Christopher Done wrote: It's available in MissingH While useful, I think its ubiquity to simplicity ratio is not high enough to justify either depending on MissingH just for that, or adding it to a base library. However, if your personal style makes this so ubiquitous as to override its simplicity, go ahead and upload it to Hackage, perhaps others will also benefit. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Maybe to Either -- is there a better way?
Yitzchak Gale g...@sefer.org writes: Tom Davies wrote: I find it convenient sometimes to convert a Maybe value to an Either maybeToEither = flip maybe Right . Left Remember, some people don't like flip! :p maybeToEither = (`maybe` Right) . Left While useful, I think its ubiquity to simplicity ratio is not high enough to justify either depending on MissingH just for that, or adding it to a base library. Just like the swap :: (a,b) - (b,a) function a lot of people were discussing on librar...@? In general, I agree. However, if your personal style makes this so ubiquitous as to override its simplicity, go ahead and upload it to Hackage, perhaps others will also benefit. Just give it a good name, rather than fooToolkit, barToolkit, etc. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] RE: what's the best environment for haskell work? (Rustom Mody)
On Sat, Jul 31, 2010 at 12:07 PM, Rustom Mody rustompm...@gmail.com wrote: Do most people who work with haskell use emacs/vi/eclipse or something else?? I used Emacs, as I used to in other langauages.( mainly on Linux) When switching to Mac Ox, I Re tried Leksah at 0.8 , and Now Am sticking to it. what I found of value: - In a Nutshell, increased focus. not only time, but focus. changes in my behavior , mainly : -when exploring unknown libraries, I found the one click access to libraries ( search Metadata) , then one click to read the source is easy (easier means then I do it more often). - the right click type this ... that seemlessly toogles betwwen ghi-ghci , is cool to paste types once a part of my code solidify - session saving means I find the same windows opened at the same place I left them the day before or a while ago... more focus again. ( when working in parallele on different things) ( Note : I have a 27 ' screen) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Maybe to Either -- is there a better way?
I wrote: maybeToEither = flip maybe Right . Left Ivan Lazar Miljenovic wrote: Remember, some people don't like flip! :p maybeToEither = (`maybe` Right) . Left Yes, absolutely! ...go ahead and upload it to Hackage Just give it a good name, rather than fooToolkit, barToolkit, etc. How about calling it fgl? No, please don't really. I'm just teasing Ivan. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: approximate-equality 1.0 -- Newtype wrappers for approximate equality
On 03/08/10 05:32, Gregory Crosswhite wrote: I am pleased to announce the release of the package approximate-equality, which provides newtype wrappers that allow one to effectively override the equality operator of a value so that it is/approximate/ rather than/exact/. The wrappers use type annotations to specify the tolerance; the 'Digits' type constructor has been provided for specifying the tolerance using type-level natural numbers. Instances for all of the classes in the numerical hierarchy have been provided for the wrappers, so the wrapped values can mostly be used in the same way as the original values. (In fact, most of the time one doesn't even have to wrap the starting values, since expressions such as (1+sqrt 2/3) are automatically wrapped thanks to the 'fromIntegral' method of the 'Num' typeclass.) The motivation behind this package is that there are times when working with floating point numbers that one would like the equality operator to check for approximate equality rather than exact equality. For example, in one of my own projects I have a walker that spits out a list of coordinate values that I keep track of, and since floating point arithmetic is inexact it will often arrive at the same point from two different paths and thus obtain slightly different values for the coordinates of that point. I could have just written a function to do approximate matching of the point and be done with it, but then I can't leverage pre-built data structures such as Data.Set and Data.Map which use (==) for determining whether a key is a member. This package is compatible with Haskell 2010, as it only uses the EmptyDataDecls extension, and the only package dependency is type-level-natural-numbers which itself is Haskell 2010. Any feedback from the community is, of course, very welcome. I like the look of this. Eq and Ord instances that use epsilon values look like they will be handy. I have a design question/suggestion. You have: class AbsoluteTolerance absolute_tolerance where absoluteToleranceOf :: Fractional value = AbsolutelyApproximateValue absolute_tolerance value - value Why do you need this class (and the other two)? It looks like you can just define: absoluteToleranceOf :: (NaturalNumber n, Fractional value) = AbsolutelyApproximateValue (Digits n) value - value absoluteToleranceOf = toleranceFromDigits . getAbsoluteTolerance So you can get the same function without needing to add a type-class. Or is it that you envisage other tolerance specifications besides Digit? If so, I wonder if this flexibility complicates your API unnecessarily. If you removed those type-classes and just stuck with Digits, the size of your API documentation would halve, and make the docs a lot more readable. Thanks, Neil. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: approximate-equality 1.0 -- Newtype wrappers for approximate equality
On Tue, Aug 3, 2010 at 7:27 AM, Neil Brown nc...@kent.ac.uk wrote: I like the look of this. Eq and Ord instances that use epsilon values look like they will be handy. I have a design question/suggestion. You have: What properties does Eq need to obey? Reflexivity: (a == a) Symmetry: (a == b) == (b == a) Transitivity: ((a == b) (b == c)) == (a == c) An instance using epsilon values clearly is reflexive and symmetric, but it is not transitive. I've looked [1] and appearently Eq doesn't list the laws it should satisfy, not even '(a == b) == not (a /= b)' is mentioned. [1] http://haskell.org/ghc/docs/6.12.1/html/libraries/base-4.2.0.0/Prelude.html#t%3AEq Cheers, =) -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: hierarchical-clustering and gsc-weighting
Hello! I'm pleased to announce the release of two new packages: http://hackage.haskell.org/package/hierarchical-clustering http://hackage.haskell.org/package/gsc-weighting 'hierarchical-clustering' provides a function to create a dendrogram from a list of items and a distance function between them. The most common linkage types are available: single linkage, complete linkage and UPGMA. An item can be anything, for example a DNA sequence, so this may used to create a phylogenetic tree. Or it may be used with the 'gsc-weighting' package to assign weights to the items. Weights are assigned such that close items get smaller weight than distance items, meaning that the weights try to avoid the over-representation of some closely related items. The package name come from the authors of the algorithm, Gerstein, Sonnhammer and Chothia. Again, this may be used for DNA or protein sequences. Cheers! -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: hierarchical-clustering and gsc-weighting
Felipe Lessa felipe.le...@gmail.com writes: Hello! I'm pleased to announce the release of two new packages: http://hackage.haskell.org/package/hierarchical-clustering http://hackage.haskell.org/package/gsc-weighting 'hierarchical-clustering' provides a function to create a dendrogram from a list of items and a distance function between them. The most common linkage types are available: single linkage, complete linkage and UPGMA. An item can be anything, for example a DNA sequence, so this may used to create a phylogenetic tree. What actual clustering algorithm are you using here? Also, would it be possible to have some more documentation there in general? At the very least, in your next release explain what a dendogram is and why someone would want to use your package (I had to do some quick wikipedia looking to refresh my memory on what dendogram, etc. were to get an understanding of what it does). -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: hierarchical-clustering and gsc-weighting
On Tue, Aug 3, 2010 at 8:01 AM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: Felipe Lessa felipe.le...@gmail.com writes: 'hierarchical-clustering' provides a function to create a dendrogram from a list of items and a distance function between them. The most common linkage types are available: single linkage, complete linkage and UPGMA. An item can be anything, for example a DNA sequence, so this may used to create a phylogenetic tree. What actual clustering algorithm are you using here? A naïve O(n^2) algorithm using a distance matrix. This can be improved without changing the API, however. Also, would it be possible to have some more documentation there in general? At the very least, in your next release explain what a dendogram is and why someone would want to use your package (I had to do some quick wikipedia looking to refresh my memory on what dendogram, etc. were to get an understanding of what it does). Documentation is always good, but I didn't want to take the time to explain everything from the beginning. I guess most people coming to this package will already know that they want a dendrogram. But if they don't, a quick googling is very effective. Hmm, I guess some diagrams would be nice. I've took the time only to explain why there is an UPGMA and a FakeAverageLinkage, because that distinction isn't easy to find on the web. Actually, I still haven't found someone talking about it, just people using either with the same name average linkage. =) Cheers, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Can we come out of a monad?
On 3 August 2010 01:34, Richard O'Keefe o...@cs.otago.ac.nz wrote: There's a thing I'm still finding extremely hard about monads, and that's how to get into the frame of mind where inventing things like Monad and Applicative and Arrows is something I could do myself. Functor, yes, I could have invented Functor. But not the others. Maybe looking at Sigfpe's blog post You Could Have Invented Monads! (And Maybe You Already Have.)http://blog.sigfpe.com/2006/08/you-could-have-invented-monads-and.htmlwill help. Chris. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Maybe to Either -- is there a better way?
Tom Davies tgdav...@gmail.com wrote: I find it convenient sometimes to convert a Maybe value to an Either thus (excuse the syntax, it's CAL, not Haskell): maybeToEither :: a - Maybe b - Either a b; maybeToEither errorValue = maybe (Left errorValue) (\x - Right x); As a side note, this is perfectly valid Haskell code, even though it's quite verbose. The equivalent: maybeToEither :: a - Maybe b - Either a b maybeToEither leftValue = maybe (Left leftValue) Right Honestly I find this better than the completely points-free variants posted in the other subthread. They demonstrate overusing points-free style. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife = sex) http://ertes.de/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: problem installing pivotal
On Aug 3, 10:10 am, Ivan Miljenovic ivan.miljeno...@gmail.com wrote: On 3 August 2010 15:02, rustom rustompm...@gmail.com wrote: I tried to install pivotal According to the site I must do: ghc --make Main -fglasgow-exts -package plugins I get cant satisfy package plugins Which version of GHC are you using? If you're using 6.12, then you're out of luck: plugins won't work with it yet. ?? Is 6.12 too young or too old?? I believe the more general problem is that one has to choose between 'direct' cabal installs and using debian's packages. At least this is the same situation Ive seen before in python, ruby etc. Preferably, use a distro package if there is one. If there isn't, then use cabal-install to install it to your home directory (which means you'll have to maintain it yourself). So this is really 2 questions: 1. How to remove this error and install pivotal cabal install pivotal (if you have GHC-6.10.*) I am not sure how to resolve this: use cabal install and 'preferably use a distro' In any case with cabal install pivotal I get cabal: There is no package named pivotal. Perhaps you need to run 'cabal update' first? (this was just after a cabal update) Finally: Is it better to take up these (kind of) questions on the ghc list rather than here? 2. Is it better to install haskell-platform or is it better to have a minimal install of ghc and then use hackage/cabal [Or is this a type- wrong question :-) ] In general, I recommend you stick with your distribution's packages as much as possible (assuming they're kept up to date) and only resort to cabal-install when necessary; distribution packages typically interact with the system (in terms of non-Haskell dependencies, etc.) better. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list haskell-c...@haskell.orghttp://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] Re: problem installing pivotal
rustom rustompm...@gmail.com writes: I am not sure how to resolve this: use cabal install and 'preferably use a distro' My preference is that if my distro has a package that I want and the latest such version (or a maintainer can be prompted to get latest version in there), then I use the distro package. Otherwise, I use cabal-install. This results in me using distro packages exclusively at home (since I help maintain the Haskell packages for Gentoo) and cabal-install at uni (since my machine has an old Ubuntu install on it that they're going to update any day now :@ ). In any case with cabal install pivotal I get cabal: There is no package named pivotal. Perhaps you need to run 'cabal update' first? (this was just after a cabal update) Well, where did you get pivotal from? If it isn't on Hackage but is cabalised, you can download, unpack it and then within that directory just run cabal install. Finally: Is it better to take up these (kind of) questions on the ghc list rather than here? No, the GHC mailing list is more towards development of GHC. 2. Is it better to install haskell-platform or is it better to have a minimal install of ghc and then use hackage/cabal [Or is this a type- wrong question :-) ] In general, I recommend you stick with your distribution's packages as much as possible (assuming they're kept up to date) and only resort to cabal-install when necessary; distribution packages typically interact with the system (in terms of non-Haskell dependencies, etc.) better. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list haskell-c...@haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Laziness question
On Mon, 02 Aug 2010 17:41:02 +0200, Janis Voigtländer j...@informatik.uni-bonn.de wrote: Hi, I am late to reply in this thread, but as I see Stefan has already made what (also from my view) are the main points: - Putting seq in a type class makes type signatures more verbose, which one may consider okay or not. In the past (and, as it seems, again in every iteration of the language development process since then) the majority of the language design decision makers have considered this verbosity non-okay enough, so that they decided to have a fully polymorhpic seq. - Even if putting seq in a type class, problems with parametricity do not simply vanish. The question is what instances there will be for that class. (For example, if there is not instance at all, then no seq-related problems of *any* nature can exist...) - The Haskell 1.3 solution was to, among others, have a class instance for functions. As we show in the paper Stefan mentioned, that is not a solution. Some statements claimed by parametricity will then still be wrong due to seq. I agree. Adding an instance with a polymorphic primitive vanish the whole bonus of the type class approach. - If there is no class instance for function types, then those problems go away, of course. But it is doubtful whether that would be a viable solution. Quite a few programs would be rejected as a consequence. (Say, you want to use the strict version of foldl. That will lead to a type class constraint on one of the type variables. Now suppose you actually want to fold in a higher-order fashion, like when expressing efficient reverse via foldr. That would not anymore be possible for the strict version of foldl, as it would require the type-class-constrained variable to be instantiated with a function type.) I think it would be a step forward. The old seq would still exists as unsafeSeq and such applications could continue to use it. In the mean time parametricity results would better apply to programs without unsafe functions. And this without adding extra complexity into the type system. Actually I think we can keep the old generic seq, but cutting its full polymorphism: seq :: Typeable a = a - b - b Even if this is acceptable I would still introduce a type class for seq for the following reasons: - It can be useful to have a different implementation on some specific types. - It may apply one types on which we do not want Typeable. - One could safely use the Typeable version for functions. Two more specific answers to Nicolas' comments: Actually my point is that if we do not use any polymorphic primitive to implement a family of seq functions then it cannot be flawed. Indeed if you read type classes as a way to implicitly pass and pick functions then it cannot add troubles. Completely correct. But the point is that without using any polymorphic primitive you won't be able to implement a member of that family for the case of function types (which you do not consider a big restriction, but others do). However I absolutely do not buy their argument using as example a function f :: Eval (a - Int) = (a - Int) - (a - Int) - Int. They consider as an issue the fact that the type does not tell us on which argument seq is used. I think it is fine we may want a more precise type for it to get more properties out of it but it is not flawed. As much as we don't know where (==) is used given a function of type ∀ a. Eq a = [a] - [a]. I fear you do not buy our argument since you did not fully understand what our argument is, which in all probability is our fault in not explaining it enough. The point is not that we dislike per se that one doesn't know from the type signature how/where exactly methods from a type class are used. In your example ∀ a. Eq a = [a] - [a] it's alright that we don't know more about where (==) is used. But for a function of type f :: Eval (a - Int) = (a - Int) - (a - Int) - Int, in connection with trying to find out whether uses of seq are harmful or not, it is absolutely *essential* to know on which of the two functions (a - Int) seq is used. The type class approach cannot tell that. Hence, a type class approach is unsuitable for trying to prevent seq from doing parametricity-damage while still allowing to write all the Haskell programs one could before (including ones that use seq on functions). That is the flaw of the type class approach to controlling seq. It is of course no flaw of using type classes in Haskell for other things, and we certainly did not meant to imply such a thing. OK, I better understand now where we disagree. You want to see in the type whether or not the free theorem apply, I want them to always apply when no call to unsafe function is made. Kind regards, -- Nicolas Pouillard http://nicolaspouillard.fr ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org
Re: [Haskell-cafe] Re: Laziness question
Nicolas, OK, I better understand now where we disagree. You want to see in the type whether or not the free theorem apply, I want them to always apply when no call to unsafe function is made. Implementing your suggestion would make me feel uncomfortable. Turning seq into an unsafe operations effectively places it outside the language, like unsafePerformIO isn't really part of the language (in my view, at least). But experience has made it clear that there are plenty of occasions in which we cannot really do without seq (even though its presence in the language is prominent subject of debate). Cheers, Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Laziness question
Nicolas Pouillard schrieb: - If there is no class instance for function types, then those problems go away, of course. But it is doubtful whether that would be a viable solution. Quite a few programs would be rejected as a consequence. (Say, you want to use the strict version of foldl. That will lead to a type class constraint on one of the type variables. Now suppose you actually want to fold in a higher-order fashion, like when expressing efficient reverse via foldr. That would not anymore be possible for the strict version of foldl, as it would require the type-class-constrained variable to be instantiated with a function type.) I think it would be a step forward. The old seq would still exists as unsafeSeq and such applications could continue to use it. In the mean time parametricity results would better apply to programs without unsafe functions. And this without adding extra complexity into the type system. Yes, I agree. Of course, you (and Lennart, and others advocating putting seq into a type class) could work toward that solution right away, could have done so for quite some time: write a package with an Eval type class and method safeSeq (and *no* class instance for function types), upload it on Hackage, encourage people to use it. Modulo the naming difference seq/safeSeq vs. unsafeSeq/seq, that's exactly the solution you want. I wonder why it is not happening. :-) Actually I think we can keep the old generic seq, but cutting its full polymorphism: seq :: Typeable a = a - b - b I guess I don't know enough about Typeable to appreciate that. OK, I better understand now where we disagree. You want to see in the type whether or not the free theorem apply, Oh, YES. That's the point of a free theorem, isn't it: that I only need to look at the type of the function to derive some property about it. I want them to always apply when no call to unsafe function is made. Well, the question is what you mean by no call to unsafe function is made. Where? In the function under consideration, from whose type the free theorem is derived? Are you sure that this is enough? Maybe that function f does not contain a call to unsafeSeq, but it has an argument which is itself a function. Maybe in some function application, unsafeSeq is passed to f in that argument position, directly or indirectly. Maybe f does internally apply that function argument to something. Can you be sure that this will not lead to a failure of the free theorem you derived from f's type (counting on the fact that f does not call an unsafe function)? Of course, preventing the *whole program* from calling unsafeSeq is enough to guarantee validity of the free theorems thus derived. But that's equivalent to excluding seq from Haskell altogether. Best, Janis. -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:j...@iai.uni-bonn.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Laziness question
Hi again, Maybe I should add that, maybe disappointingly, I do not even have a strong opinion about whether seq should be in Haskell or not, and in what form. Let me quote the last paragraph of an extended version of our paper referred to earlier: Finally, a natural question is whether or not selective strictness should be put under control via the type system in a future version of Haskell (or even removed completely). We have deliberately not taken a stand on this here. What was important to us is that both the costs and benefits of either way should be well understood when making such a decision. Maybe the realization that, contrary to popular opinion, a relatively simple approach like the one that was present in Haskell version 1.3 does not suffice to keep selective strictness in check, and that instead something slightly less wieldy, like our type system presented here or a similar one, would be needed, will quell the recurring calls for putting seq in a type class once and for all. Even then, while it would mean that our type system does not get adopted in practice, we would consider our effort well invested. At least, the community would then have made an informed decision, and part of the justification would be on record. That's under the assumption that the requirements we have on a solution are: 1. All Haskell programs that could be written before should still be implementable, though potentially with a different type. 2. Parametricity results derived from the (new) types should hold, even if seq is involved. The Haskell 1.3 approach achieves 1. but not 2. The approach of an Eval class without a function type instance achieves 2. but not 1. Lennart suggested that the programs one loses that (latter) way might be few in practice. I have no idea whether that is true, but it might well be. But it is actually new to me that proponents of putting seq in a type class admit that they can only do so and achieve 2. by accepting to give up 1. In the past, also in the Being lazy with class paper, the impression was given that the controversial issue about the Haskell 1.3 solution were just its practicality in terms of how cumbersome or not the additional typing artifacts become. While it was simply supposed that at least that solution achieves both 1. and 2. It does not. Best, Janis. -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:j...@iai.uni-bonn.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Handling absent maintainers
On Sun, Jul 18, 2010 at 3:02 AM, Mark Wotton mwot...@gmail.com wrote: I've uploaded haskell-src-meta-mwotton, using the development version. It seems to work fine for my applications. It's a bit of a hack, but I can't think of a better way to do it for now. mark -- A UNIX signature isn't a return address, it's the ASCII equivalent of a black velvet clown painting. It's a rectangle of carets surrounding a quote from a literary giant of weeniedom like Heinlein or Dr. Who. -- Chris Maeda ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe I've just come up against one of the drawbacks of this approach - having needed haskell-src-meta for a personal project, I downloaded the source and updated it to work with GHC 6.12, fixed various bits and bobs, and only now found out that much of that work had already been done elsewhere :) Matt Morrow has been missing for a long time and I think it's reasonable to suppose he won't suddenly spring out of the darkness to fix things for us. I propose that someone just take up maintainership of the package. I am quite willing to do this with my version, or Mark if you think you'd like to keep a closer eye on your dependencies you could do it instead. I further propose that we should write up a haskellwiki page about absent maintainers and what the community thinks is reasonable in terms of attempting contact before assuming them missing, presumed gone. This kind of depends also on how big an indignity we consider it to be if someone updates a package while the maintainer is just on holiday or something. So we need to decide on: first, who will take haskell-src-meta, and second, what we think is good as a more general policy. I would think the process would go something like: 1. email maintainer, wait 2 weeks for reply 2. email cafe and maintainers of reverse dependencies with proposed changes, wait a week or so for people who know the maintainer to show up or other people to object to your changes 3. chomp package ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Laziness question
On Tue, 3 Aug 2010 16:24:54 +0200, Stefan Holdermans ste...@vectorfabrics.com wrote: Nicolas, OK, I better understand now where we disagree. You want to see in the type whether or not the free theorem apply, I want them to always apply when no call to unsafe function is made. Implementing your suggestion would make me feel uncomfortable. Turning seq into an unsafe operations effectively places it outside the language, like unsafePerformIO isn't really part of the language (in my view, at least). But experience has made it clear that there are plenty of occasions in which we cannot really do without seq (even though its presence in the language is prominent subject of debate). If we ignore the solution using Typeable for now. The actual seq would be considered unsafe but seq would be re-introduced as a method of a type class with instances for many types but not for functions. So in this view only forcing functions would be considered out of the language. -- Nicolas Pouillard http://nicolaspouillard.fr ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: scan-0.1.0.6, a style scanner for Haskell sources
Dear Haskell friends, I like to announce a new version of the style scanner for Haskell source files at http://hackage.haskell.org/package/scan documented under http://projects.haskell.org/style-scanner/ cabal update cabal install scan A short description is also here: http://haskell.org/communities/05-2010/html/report.html#sect4.2.4 It has now many more options (one is better windows support using -w), diagnostics, and change capabilities regarding (haddock) comments. Feedback is welcome. Thanks Christian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Laziness question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/3/10 10:24 , Stefan Holdermans wrote: Implementing your suggestion would make me feel uncomfortable. Turning seq into an unsafe operations effectively places it outside the language, like unsafePerformIO isn't really part of the language (in my view, at least). But experience has made it clear that there are plenty of occasions in which we cannot really do without seq (even though its presence in the language is prominent subject of debate). ...which sounds a lot like unsafePerformIO (which *is* inside the language; it's part of the FFI addendum). The parallels are exactly why I suggested it become unsafeSeq. - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxYR/gACgkQIn7hlCsL25WE8QCgtAs+gq93pZeRsBwsis9HLSWm xeEAn2xuKLYSB4IsFlxlssL5Hf3Pxo1x =oA8A -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Installation problem with latest version of haskell platform
Hi, When I try to install haskell platform 64 bit on a x86_64 debian etch I get the following error after : make install: /usr/bin/install -c -m 755 -d /usr/local/lib/ghc-6.12.3/package.conf.d /usr/local/lib/ghc-6.12.3/ghc-pkg --force --global-conf /usr/local/lib/ghc-6.12.3/package.conf.d update libffi/package.conf.install /usr/local/lib/ghc-6.12.3/ghc-pkg: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory make[1]: *** [install_packages] Error 127 make: *** [install] Error 2 I have no good strategy to locate the needed library. A quick google search yielded ncurses, but I have already installed it, and it doesn't contain that binary. Furthermore configure doesn't yield any errors. And a dependency on ncurses does seem quite strange doesn't it ? thans in advance, Pieter -- Pieter Laeremans pie...@laeremans.org The future is here. It's just not evenly distributed yet. W. Gibson ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: approximate-equality 1.0 -- Newtype wrappers for approximate equality
On 8/3/10 3:27 AM, Neil Brown wrote: So you can get the same function without needing to add a type-class. Or is it that you envisage other tolerance specifications besides Digit? If so, I wonder if this flexibility complicates your API unnecessarily. If you removed those type-classes and just stuck with Digits, the size of your API documentation would halve, and make the docs a lot more readable. Yes, I wanted to give the user the ability to create their own tolerance specifications. I figured that it was better to make it possible to do this within this library then to force the user to roll their own library if they turned out to need this functionality. Cheers, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Installation problem with latest version of haskell platform
pieter: Hi, When I try to install haskell platform 64 bit on a x86_64 debian etch I get the following error after : make install: /usr/bin/install -c -m 755 -d /usr/local/lib/ghc-6.12.3/package.conf.d /usr/local/lib/ghc-6.12.3/ghc-pkg --force --global-conf /usr/local/lib/ ghc-6.12.3/package.conf.d update libffi/package.conf.install /usr/local/lib/ghc-6.12.3/ghc-pkg: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory make[1]: *** [install_packages] Error 127 make: *** [install] Error 2 I have no good strategy to locate the needed library. A quick google search yielded ncurses, but I have already installed it, and it doesn't contain that binary. Furthermore configure doesn't yield any errors. And a dependency on ncurses does seem quite strange doesn't it ? I think you're using the wrong pre-installed GHC. There are two provided, one for ncurses and one for libtinfo. Alternatively, you can ln -s libncurses.so.5 /usr/lib/libtinfo.so.5 -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Playing with ATs again
OK, so if you do something like class Container c where type Element c :: * then we now have a clean and concise way to discover what type of element any given container holds. (Regardless of whether it's element type is parametric, hard-coded, class-constrained or anything else.) I really like this! Now suppose that instead of a container type with an associated element type, what we want is several pairs of types having a one-to-one relationship, and we want to be able to traverse that relationship in either direction. What's the best way to do that? (I tried just having two mirror image classes like the one above. But that doesn't work; there's no guarantee that going one way and then going back the other way will definitely take you back to where you started. I tried to make that a constraint, and got an error message that basically says this feature is not implemented. Great. Still, there's probably a better way to do this.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Playing with ATs again
So I believe the final way to do this, which is not yet implemented, works something like this: type family LeftToRight a type family RightToLeft b class (LeftToRight a ~ b, RightToLeft b ~ a) = Bijection a b where ... I agree, the fact that this doesn't work is really dumb. I used a slightly devious trick to solve this for Control.Coroutine[1]: type family Dual a -- what I wanted to write: class (s ~ Dual (Dual s)) = Connect s where connect :: Session s a - Session (Dual s) b - (a,b) -- what I actually wrote class Connect s where connect :: (s ~ Dual (Dual s)) = Session s a - Session (Dual s) b - (a,b) This was good enough to give the constraints I needed to implement connect for each of the session operators. -- ryan [1] http://hackage.haskell.org/packages/archive/Coroutine/0.1.0.0/doc/html/Control-Coroutine.html On Tue, Aug 3, 2010 at 10:25 AM, Andrew Coppin andrewcop...@btinternet.com wrote: OK, so if you do something like class Container c where type Element c :: * then we now have a clean and concise way to discover what type of element any given container holds. (Regardless of whether it's element type is parametric, hard-coded, class-constrained or anything else.) I really like this! Now suppose that instead of a container type with an associated element type, what we want is several pairs of types having a one-to-one relationship, and we want to be able to traverse that relationship in either direction. What's the best way to do that? (I tried just having two mirror image classes like the one above. But that doesn't work; there's no guarantee that going one way and then going back the other way will definitely take you back to where you started. I tried to make that a constraint, and got an error message that basically says this feature is not implemented. Great. Still, there's probably a better way to do this.) ___ 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] Playing with ATs again
On 03.08.2010 21:25, Andrew Coppin wrote: Now suppose that instead of a container type with an associated element type, what we want is several pairs of types having a one-to-one relationship, and we want to be able to traverse that relationship in either direction. What's the best way to do that? (I tried just having two mirror image classes like the one above. But that doesn't work; there's no guarantee that going one way and then going back the other way will definitely take you back to where you started. I tried to make that a constraint, and got an error message that basically says this feature is not implemented. Great. Still, there's probably a better way to do this.) That's possible with multiparameter type classes and fundeps. Without any further words I'm pasting code snippet: class Relator a b | a - b, b - a where to :: a - b from :: b - a data Knight = Knight deriving Show data Dragon = Dragon deriving Show instance Relator Knight Dragon where to _ = Dragon from _ = Knight I'm not sure that it's what you want. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Maybe to Either -- is there a better way?
On 02/08/10 15:14, Tom Davies wrote:
I find it convenient sometimes to convert a Maybe value to an Either thus
(excuse the syntax, it's CAL, not Haskell):
maybeToEither :: a - Maybe b - Either a b;
maybeToEither errorValue = maybe (Left errorValue) (\x - Right x);
but that seemingly obvious function isn't in Hoogle, AFAICT, so perhaps there's
some other approach?
I just uploaded djinn-th [1], a fork of Lennart Augustsson's djinn [2]
which uses TemplateHaskell to do things like:
{-# LANGUAGE TemplateHaskell, ScopedTypeVariables #-}
import Language.Haskell.Djinn (djinnD)
$(djinnD maybeToEither [t|forall a b . a - Maybe b - Either a b|])
main = print . map (maybeToEither foo) $ [Nothing, Just bar]
and get some results, if not always the one you intended.
[1] http://hackage.haskell.org/package/djinn-th
[2] http://hackage.haskell.org/package/djinn
Thanks,
Claude
--
http://claudiusmaximus.goto10.org
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: DSTM 0.1.1
That is really nice. The architecture seems to be around a single server that bring lookup services, so there is a single point of failure. I´m thinking on cloud computing. Can be extended to have backup servers somehow ? Alberto. 2010/8/3 Christopher Done chrisd...@googlemail.com This is very cool, thanks for writing it. I will try it when I get home tonight. On 3 August 2010 10:35, Frank Kupke f...@informatik.uni-kiel.de wrote: Hi, DSTM is an implementation of a robust distributed Software Transactional Memory (STM) library for Haskell. Many real-life applications are distributed by nature. Concurrent applications may profit from robustness added by re-implementation as distributed applications. DSTM extends the STM abstraction to distributed systems and presents an implementation efficient enough to be used in soft real-time applications. Further, the implemented library is robust in itself, offering the application developer a high abstraction level to realize robustness, hence, significantly simplifying this, in general, complex task. The DSTM package consists of the DSTM library, a name server application, and three sample distributed programs using the library. Provided are a simple Dining Philosophers, a Chat, and a soft real-time Bomberman game application. Distributed communication is transparent to the application programmer. The application designer uses a very simple name server mechanism to set up the system. The DSTM library includes the management of unavailable process nodes and provides the application with abstract error information thus facilitating the implementation of robust distributed application programs. For usage please look into the documentation file: DSTMManual.pdf. The package including the documentation can be found on: http://hackage.haskell.org/package/DSTM-0.1.1 Best regards, Frank Kupke ___ 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 mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: ipatch, the interactive patch editor
Dear Haskell and Darcs community, I have written a tool to interactively edit patches, which under the hood uses the Darcs API. A more catchy introduction, including a screencast, can be found on https://www.joachim-breitner.de/blog/archives/425-ipatch,-the-interactive-patch-editor.html which ends (and this is where you come in) with „So this is an invitation to join me and make ipatch a great tool. This invitation goes especially to the Darcs developers: Please have a look how the code uses the Darcs API and help to improve the collaboration here. I think we can use the darcs-users mailing list until there is need for a dedicated mailing list.“ The code is on http://darcs.nomeata.de/ipatch/. Enjoy! Joachim -- Joachim nomeata Breitner mail: m...@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Maybe to Either -- is there a better way?
On 03/08/2010, at 10:09 PM, Ertugrul Soeylemez wrote: Tom Davies tgdav...@gmail.com wrote: I find it convenient sometimes to convert a Maybe value to an Either thus (excuse the syntax, it's CAL, not Haskell): maybeToEither :: a - Maybe b - Either a b; maybeToEither errorValue = maybe (Left errorValue) (\x - Right x); As a side note, this is perfectly valid Haskell code, even though it's quite verbose. The equivalent: maybeToEither :: a - Maybe b - Either a b maybeToEither leftValue = maybe (Left leftValue) Right I like that better, and CAL supports that, thanks. Honestly I find this better than the completely points-free variants posted in the other subthread. They demonstrate overusing points-free style. I agree -- as an inexperienced functional programmer, but not a complete beginner, I found the points free versions incomprehensible! Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: ipatch, the interactive patch editor
Joachim Breitner m...@joachim-breitner.de writes: Dear Haskell and Darcs community, I have written a tool to interactively edit patches, which under the hood uses the Darcs API. A more catchy introduction, including a screencast, can be found on https://www.joachim-breitner.de/blog/archives/425-ipatch,-the-interactive-patch-editor.html which ends (and this is where you come in) with „So this is an invitation to join me and make ipatch a great tool. This invitation goes especially to the Darcs developers: Please have a look how the code uses the Darcs API and help to improve the collaboration here. I think we can use the darcs-users mailing list until there is need for a dedicated mailing list.“ How does this differ from darcs' hunk splitter/editor? Or is this just making this functionality available to be used when you're not using darcs itself? -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: ipatch, the interactive patch editor
Hi, Am Mittwoch, den 04.08.2010, 07:42 +1000 schrieb Ivan Lazar Miljenovic: Joachim Breitner m...@joachim-breitner.de writes: Dear Haskell and Darcs community, I have written a tool to interactively edit patches, which under the hood uses the Darcs API. A more catchy introduction, including a screencast, can be found on https://www.joachim-breitner.de/blog/archives/425-ipatch,-the-interactive-patch-editor.html which ends (and this is where you come in) with „So this is an invitation to join me and make ipatch a great tool. This invitation goes especially to the Darcs developers: Please have a look how the code uses the Darcs API and help to improve the collaboration here. I think we can use the darcs-users mailing list until there is need for a dedicated mailing list.“ How does this differ from darcs' hunk splitter/editor? Or is this just making this functionality available to be used when you're not using darcs itself? It is darcs’ hunk splitter/editor, and exactly that: Using it when not using darcs. Greetings, Joachim -- Joachim nomeata Breitner mail: m...@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Suggestions For An Intro To Monads Talk.
Hi all, I am doing an Intro To Monads talk in September [1]. The audience consists of experienced non-Haskell developers but they will be familiar with basic functional concepts (closures, first-class functions etc.). I am looking for suggestions on how to introduce the concept and its implications. I'd also like to include a section on why monads exist and why we don't really see them outside of Haskell. Has anyone here done a talk like this? And if so what parts of your presentation were successful and what would you stay away from. Thanks for the feedback. -deech [1] It's in St.Louis, Missouri at the St.Louis Perl Mongers meetinghttp://St.Louis%20Perl%20Mongers%20meetingso come on by if you're around! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Why do unsafe foreign calls block other threads?
Hey everyone, Could someone explain to me the logic behind having unsafe calls block other threads from executing? It seems to me that if anything it would make more sense for safe calls to block other threads since the call can call back into the Haskell runtime, as opposed to unsafe calls which (by assertion) will never call back into Haskell and therefore should be safer to run in parallel with other threads. What am I missing here? Cheers, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why do unsafe foreign calls block other threads?
It's a matter of perspective. Either the function you're FFI'ing to is safe/unsafe or your use of it is safe/unsafe. The FFI spec seems to be using the former, so if you think that the function you're calling is unsafe (i.e., can call back into Haskell) then it blocks the world. But I do think it's unintuitive and a less ambiguous naming scheme would be nicer. Dan On Tue, Aug 3, 2010 at 11:54 PM, Gregory Crosswhite gcr...@phys.washington.edu wrote: Hey everyone, Could someone explain to me the logic behind having unsafe calls block other threads from executing? It seems to me that if anything it would make more sense for safe calls to block other threads since the call can call back into the Haskell runtime, as opposed to unsafe calls which (by assertion) will never call back into Haskell and therefore should be safer to run in parallel with other threads. What am I missing here? Cheers, Greg ___ 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] Why do unsafe foreign calls block other threads?
But you've got it backwards: if the function I am calling can call back into Haskell (i.e., is marked as safe), then GHC *doesn't* block the world, but if the function I am calling will never call back into Haskell (i.e., is marked as unsafe), then GHC *does* block the world. The reasoning behind this choice of behaviors is exactly what I do not understand. Cheers, Greg On 08/03/10 14:58, Daniel Peebles wrote: It's a matter of perspective. Either the function you're FFI'ing to is safe/unsafe or your use of it is safe/unsafe. The FFI spec seems to be using the former, so if you think that the function you're calling is unsafe (i.e., can call back into Haskell) then it blocks the world. But I do think it's unintuitive and a less ambiguous naming scheme would be nicer. Dan On Tue, Aug 3, 2010 at 11:54 PM, Gregory Crosswhite gcr...@phys.washington.edu mailto:gcr...@phys.washington.edu wrote: Hey everyone, Could someone explain to me the logic behind having unsafe calls block other threads from executing? It seems to me that if anything it would make more sense for safe calls to block other threads since the call can call back into the Haskell runtime, as opposed to unsafe calls which (by assertion) will never call back into Haskell and therefore should be safer to run in parallel with other threads. What am I missing here? Cheers, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org mailto: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] Why do unsafe foreign calls block other threads?
On Tue, Aug 3, 2010 at 3:06 PM, Gregory Crosswhite gcr...@phys.washington.edu wrote: But you've got it backwards: if the function I am calling can call back into Haskell (i.e., is marked as safe), then GHC *doesn't* block the world, but if the function I am calling will never call back into Haskell (i.e., is marked as unsafe), then GHC *does* block the world. The reasoning behind this choice of behaviors is exactly what I do not understand. unsafe calls are fast but unsafe. If they call back to haskell, or take a long time, bad things will happen. safe calls are safer: They can call back to haskell, block on IO, or just wander off and do something CPU intensive. As is often the case, you pay a little bit of efficiency for the safety, since the RTS has to line up a few ducks to allow callbacks (and presumably concurrency). Just think of unsafe in relation to unsafeIndex or something. It's faster, but you have to be sure the index is in bounds. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why do unsafe foreign calls block other threads?
On Tue, Aug 03, 2010 at 02:54:40PM -0700, Gregory Crosswhite wrote: Could someone explain to me the logic behind having unsafe calls block other threads from executing? It seems to me that if anything it would make more sense for safe calls to block other threads since the call can call back into the Haskell runtime, as opposed to unsafe calls which (by assertion) will never call back into Haskell and therefore should be safer to run in parallel with other threads. What am I missing here? It is more an accident of ghc's design than anything, the same mechanism that allowed threads to call back into the runtime also allowed them to be non blocking so the previously used 'safe' and 'unsafe' terms got re-used. personally, I really don't like those terms, they are non-descriptive in terms of what they actually mean and presuppose a RTS similar to ghcs current design. 'reentrant' and 'blocking' which could be specified independently would be better and would be more future-proof against changes in the RTS or between compilers. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why do unsafe foreign calls block other threads?
On 08/03/10 15:22, Evan Laforge wrote: On Tue, Aug 3, 2010 at 3:06 PM, Gregory Crosswhite gcr...@phys.washington.edu wrote: But you've got it backwards: if the function I am calling can call back into Haskell (i.e., is marked as safe), then GHC *doesn't* block the world, but if the function I am calling will never call back into Haskell (i.e., is marked as unsafe), then GHC *does* block the world. The reasoning behind this choice of behaviors is exactly what I do not understand. unsafe calls are fast but unsafe. If they call back to haskell, or take a long time, bad things will happen. safe calls are safer: They can call back to haskell, block on IO, or just wander off and do something CPU intensive. As is often the case, you pay a little bit of efficiency for the safety, since the RTS has to line up a few ducks to allow callbacks (and presumably concurrency). Just think of unsafe in relation to unsafeIndex or something. It's faster, but you have to be sure the index is in bounds. Yes, but the whole reason to use unsafe is to get higher performance at the cost of safety. If the result of calling an unsafe foreign function is that you *lose* performance because the other threads have to be halted first, then this seems to defeat the whole point of marking a call as unsafe in the first place. Cheers, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why do unsafe foreign calls block other threads?
Just think of unsafe in relation to unsafeIndex or something. It's faster, but you have to be sure the index is in bounds. Yes, but the whole reason to use unsafe is to get higher performance at the cost of safety. If the result of calling an unsafe foreign function is that you *lose* performance because the other threads have to be halted first, then this seems to defeat the whole point of marking a call as unsafe in the first place. That's why the function has to return soon and shouldn't do a lot of work. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why do unsafe foreign calls block other threads?
On 08/03/10 15:23, John Meacham wrote: It is more an accident of ghc's design than anything, the same mechanism that allowed threads to call back into the runtime also allowed them to be non blocking so the previously used 'safe' and 'unsafe' terms got re-used. personally, I really don't like those terms, they are non-descriptive in terms of what they actually mean and presuppose a RTS similar to ghcs current design. 'reentrant' and 'blocking' which could be specified independently would be better and would be more future-proof against changes in the RTS or between compilers. John Okay, that makes a lot more sense. So really when marking a call safe or unsafe I shouldn't be thinking in terms of whether I want to avoid the increased overhead of allowing it to call back into Haskell, but rather I should be considering whether I want to call to block other threads or not. However, it would seem that within this scheme there is no way for me to specify that a foreign call should be both blocking and also allowed to call Haskell functions, which to me would be the safeest possible alternative. Cheers, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Suggestions For An Intro To Monads Talk.
On Tue, Aug 3, 2010 at 2:51 PM, aditya siram aditya.si...@gmail.com wrote: I am doing an Intro To Monads talk in September [1]. ...what would you stay away from. Some things to stay away from: http://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/ (Though I secretly harbour a belief that there is a correct metaphor that everyone should be using. :-) -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why do unsafe foreign calls block other threads?
On 08/03/10 15:33, Evan Laforge wrote: Just think of unsafe in relation to unsafeIndex or something. It's faster, but you have to be sure the index is in bounds. Yes, but the whole reason to use unsafe is to get higher performance at the cost of safety. If the result of calling an unsafe foreign function is that you *lose* performance because the other threads have to be halted first, then this seems to defeat the whole point of marking a call as unsafe in the first place. That's why the function has to return soon and shouldn't do a lot of work. But again, then what is the point of marking it unsafe if it means that you have to pay a hefty cost of waiting for all the other threads to halt? Is the cost of halting all of the other threads really less than the cost of setting up for a safe call? Maybe it is, and that is what I am missing here. If it is not, though, then it seems to me that marking a call as unsafe will *never* gain you performance in a multi-threaded environment, so that there is never any point in using it in such an environment. (Though, of course, it could gain you performance in a single-threaded environment.) Cheers, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Suggestions For An Intro To Monads Talk.
Thanks for reminding me. Although I wonder if there is a difference between drawing metaphors (monads are burritos etc.) and drawing parallels. For example in the beginning it was useful for me to think of monads (and typeclasses really) as approximating Java interfaces. Now this parallel dies pretty quickly but it was something for me to hold onto while internalizing the concepts. Is there a danger in telling people this? -deech On Tue, Aug 3, 2010 at 5:36 PM, Dan Piponi dpip...@gmail.com wrote: On Tue, Aug 3, 2010 at 2:51 PM, aditya siram aditya.si...@gmail.com wrote: I am doing an Intro To Monads talk in September [1]. ...what would you stay away from. Some things to stay away from: http://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/ (Though I secretly harbour a belief that there is a correct metaphor that everyone should be using. :-) -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why do unsafe foreign calls block other threads?
As far as I know, it works like this: unsafe calls are just executed directly, like any other C function call; as a result, any lightweight haskell threads which were mapped onto the OS thread in which the call is made are blocked for the duration of the call; hence why it's a good idea that these calls should be short ones. So the blocking is not by intent, but -is- a direct consequence (of how unsafe calls are made and how GHC's threading system works). Other OS threads and the haskell threads mapped to them are not blocked, afaik. safe calls spawn a new OS thread (maybe reuse an existing one if available?), move the haskell threads over, (do various other housekeeping?), and then make the call. On Wed, Aug 4, 2010 at 12:41 AM, Gregory Crosswhite gcr...@phys.washington.edu wrote: On 08/03/10 15:33, Evan Laforge wrote: Just think of unsafe in relation to unsafeIndex or something. It's faster, but you have to be sure the index is in bounds. Yes, but the whole reason to use unsafe is to get higher performance at the cost of safety. If the result of calling an unsafe foreign function is that you *lose* performance because the other threads have to be halted first, then this seems to defeat the whole point of marking a call as unsafe in the first place. That's why the function has to return soon and shouldn't do a lot of work. But again, then what is the point of marking it unsafe if it means that you have to pay a hefty cost of waiting for all the other threads to halt? Is the cost of halting all of the other threads really less than the cost of setting up for a safe call? Maybe it is, and that is what I am missing here. If it is not, though, then it seems to me that marking a call as unsafe will *never* gain you performance in a multi-threaded environment, so that there is never any point in using it in such an environment. (Though, of course, it could gain you performance in a single-threaded environment.) Cheers, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Work is punishment for failing to procrastinate effectively. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why do unsafe foreign calls block other threads?
O, okay, that makes a LOT more sense! I had thought that blocking meant that *all* of the *OS* threads were halted before making the call, but if blocking really just means that the calling *OS* thread can't do any other work until the call returns (hence blocking the other *IO* threads mapped to that OS thread) then it all makes sense to me. :-) Cheers, Greg On 08/03/10 15:49, Gábor Lehel wrote: As far as I know, it works like this: unsafe calls are just executed directly, like any other C function call; as a result, any lightweight haskell threads which were mapped onto the OS thread in which the call is made are blocked for the duration of the call; hence why it's a good idea that these calls should be short ones. So the blocking is not by intent, but -is- a direct consequence (of how unsafe calls are made and how GHC's threading system works). Other OS threads and the haskell threads mapped to them are not blocked, afaik. safe calls spawn a new OS thread (maybe reuse an existing one if available?), move the haskell threads over, (do various other housekeeping?), and then make the call. On Wed, Aug 4, 2010 at 12:41 AM, Gregory Crosswhite gcr...@phys.washington.edu wrote: On 08/03/10 15:33, Evan Laforge wrote: Just think of unsafe in relation to unsafeIndex or something. It's faster, but you have to be sure the index is in bounds. Yes, but the whole reason to use unsafe is to get higher performance at the cost of safety. If the result of calling an unsafe foreign function is that you *lose* performance because the other threads have to be halted first, then this seems to defeat the whole point of marking a call as unsafe in the first place. That's why the function has to return soon and shouldn't do a lot of work. But again, then what is the point of marking it unsafe if it means that you have to pay a hefty cost of waiting for all the other threads to halt? Is the cost of halting all of the other threads really less than the cost of setting up for a safe call? Maybe it is, and that is what I am missing here. If it is not, though, then it seems to me that marking a call as unsafe will *never* gain you performance in a multi-threaded environment, so that there is never any point in using it in such an environment. (Though, of course, it could gain you performance in a single-threaded environment.) Cheers, Greg ___ 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] Suggestions For An Intro To Monads Talk.
On Aug 3, 2010, at 4:44 PM, aditya siram wrote: Thanks for reminding me. Although I wonder if there is a difference between drawing metaphors (monads are burritos etc.) and drawing parallels. Since they are experienced developers, your audience will want to know how to use monads to solve problems they can already solve in other languages. Drawing parallels is the quickest way to bootstrap this. For example in the beginning it was useful for me to think of monads (and typeclasses really) as approximating Java interfaces. Now this parallel dies pretty quickly but it was something for me to hold onto while internalizing the concepts. Is there a danger in telling people this? I believe you can draw such a parallel safely (I wrote an extended example of this [1] which received good feedback on ycombinator and bad feedback on reddit's r/haskell). Use the familiar to bootstrap the idea, then generalize from there. Certainly it would be bad to use such an example and not explain where it breaks down, but on the other hand, an example like this will get them on board much faster than a monad is anything satisfying the following axioms... As you suggested at the beginning of the thread, they will wonder why they don't see monads in other languages. I'm sure someone else has thought about this more than I have, but the absence of type classes and good syntactic support is likely the main culprit. Depending on time allotted, you might not have a chance to include any good killer examples of why monads are valuable. If you do have the time, though, I've found that people respond well to examples of parsec [2]. 1. https://intoverflow.wordpress.com/2010/07/20/i-come-from-java-and-want-to-know-what-monads-are-in-haskell/ 2. http://hackage.haskell.org/package/parsec-3.0.0 -deech On Tue, Aug 3, 2010 at 5:36 PM, Dan Piponi dpip...@gmail.commailto:dpip...@gmail.com wrote: On Tue, Aug 3, 2010 at 2:51 PM, aditya siram aditya.si...@gmail.commailto:aditya.si...@gmail.com wrote: I am doing an Intro To Monads talk in September [1]. ...what would you stay away from. Some things to stay away from: http://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/ (Though I secretly harbour a belief that there is a correct metaphor that everyone should be using. :-) -- Dan ATT1..txt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Suggestions For An Intro To Monads Talk.
Today I read this fantastic blog post: You Could Have Invented Monads! (And Maybe You Already Have.) http://blog.sigfpe.com/2006/08/you-could-have-invented-monads-and.html You most probably have seen the post by now, but I just wanted to remind it, just in case. Best, On 3 August 2010 22:51, aditya siram aditya.si...@gmail.com wrote: Hi all, I am doing an Intro To Monads talk in September [1]. The audience consists of experienced non-Haskell developers but they will be familiar with basic functional concepts (closures, first-class functions etc.). I am looking for suggestions on how to introduce the concept and its implications. I'd also like to include a section on why monads exist and why we don't really see them outside of Haskell. Has anyone here done a talk like this? And if so what parts of your presentation were successful and what would you stay away from. Thanks for the feedback. -deech [1] It's in St.Louis, Missouri at the St.Louis Perl Mongers meetinghttp://St.Louis%20Perl%20Mongers%20meetingso come on by if you're around! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Ozgur Akgun ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] can Haskell do everyting as we want?
As more I learn haskell, I am more interested in this function programming language. I am intended to more focus on haskell than other languages like python, Java, or C++. But I am still wonder whether haskell can do everyting as other languages do, such as python, perl, Java and C++. Is there anyone happen to come into any tasks that haskell is not able to achieve? Thanks. -- Qi Qi ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] can Haskell do everyting as we want?
qiqi789: As more I learn haskell, I am more interested in this function programming language. I am intended to more focus on haskell than other languages like python, Java, or C++. But I am still wonder whether haskell can do everyting as other languages do, such as python, perl, Java and C++. Is there anyone happen to come into any tasks that haskell is not able to achieve? Well, Haskell is a general purpose language, so it should be able to do pretty much anything. Here's a graphical representation of what Haskell is used for, based on the number of packages on Hackage in that category: http://donsbot.wordpress.com/2009/01/24/what-is-haskell-good-for/ Most endeavors in computer programming are available in some form or another on Hackage, so I'd say we have lived up to the goal of providing a general purpose language. One thing that is not well covered, due to the nature of the runtime, is hard real time computing. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why do unsafe foreign calls block other threads?
Quoth John Meacham j...@repetae.net, It is more an accident of ghc's design than anything, the same mechanism that allowed threads to call back into the runtime also allowed them to be non blocking so the previously used 'safe' and 'unsafe' terms got re-used. personally, I really don't like those terms, they are non-descriptive in terms of what they actually mean and presuppose a RTS similar to ghcs current design. 'reentrant' and 'blocking' which could be specified independently would be better and would be more future-proof against changes in the RTS or between compilers. Is the concurrency issue documented somewhere? What does `non blocking' mean, and why would it not just always be that way? In my situation, thread creation and dispatch happens in foreign library code, and execution in the Haskell runtime happens _only_ via callbacks. I don't need those callbacks to compute in parallel, generally, but it would be disappointing to hear that a callback strictly blocks execution of any others for its entire duration, for example even during a potentially slow I/O. (Will test for that, but not sure whether it would be conclusive since the system seems to be slightly broken at this point - need to disable RTS timer signals ( -V0 ) to survive externally generated thread dispatch events.) thanks, Donn Cave, d...@avvanta.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Error Monad and strings
On Tue, Jul 27, 2010 at 04:08:39PM -0700, Gerald Gutierrez wrote: Reading the Control.Monad.Error documentation, I see that the Error class has noMsg and strMsg as its only two functions. Now, I understand that you can define your own Error instances such as in example 1 of the documentation, so why the need to always support strings via noMsg/strMsg ? What uses these? And if in my code, I will never throw an error with a string, am I supposed to implement these functions and then ignore them? I see. So strings must be supported in the case of a bug which cannot be caught at compile time? In other words, if I get an error with a string, I'm pretty much guaranteed it is a bug, i.e. a pattern match error as the fail documentation says. Not at all, depending on the properties of your monad and intent, a pattern match failure may or may not be considered a bug, So write your instance appropriately. it is perfectly fine to make pattern match failure be 'error' if that is what is appropriate for your monad and usage. However, the instance definition for Either that mentions Error is definitely a big misfeature in the library. Non-local returns are generally useful in many contexts other than errors. Actually, the 'Error' class in general seems somewhat dubious to me. I would avoid using or depending on it. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] can Haskell do everyting as we want?
I use Haskell for everything. In fact, I will be approaching my 10 year anniversary of using Haskell as my primary development language soon. The only area I have had any trouble with Haskell is doing realtime music synthesis. And only because the garbage collector is not realtime friendly. That is not unfixable though. However, I am thinking that the best way to do realtime synthesis with Haskell is to use it to create a DSL that uses LLVM to create code at runtime so that the realtime code is outside the scope of the normal RTS and garbage collector. Aside from being a 'hack' to get around the garbage collector, this could actually provide better performance than low-level C/ASM by allowing very specialized code to be generated at runtime in response to configuration changes. This concept was explored with some success in Synthesis OS: http://c2.com/cgi/wiki?SynthesisOs (a general purpose unix-like OS, the synthesis in the name is referring to the runtime code generation for OS services, not music). The other area I have found Haskell to sometimes fall short is when I want even stronger guarantees from the type system. For those instances, I want something more like Agda or Epigram, not something weaker like Java/C++. - jeremy On Tue, Aug 3, 2010 at 6:12 PM, Qi Qi qiqi...@gmail.com wrote: As more I learn haskell, I am more interested in this function programming language. I am intended to more focus on haskell than other languages like python, Java, or C++. But I am still wonder whether haskell can do everyting as other languages do, such as python, perl, Java and C++. Is there anyone happen to come into any tasks that haskell is not able to achieve? Thanks. -- Qi Qi ___ 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] can Haskell do everyting as we want?
On Tue, Aug 3, 2010 at 4:12 PM, Qi Qi qiqi...@gmail.com wrote: Is there anyone happen to come into any tasks that haskell is not able to achieve? Haskell has very limited support for high-level Natural Language Processing (tokenization, sentence splitting, Named-entity recognition, etc...). NLTK (python), OpenNLP (java), and FleeLing (C++) all have quite a lot to offer here, but there aren't currently any bindings to those implementations from Haskell. FreeLing is the best choice from a pure languages standpoint, but it is GPL, which would infect the resulting bindings and reduce the utility of the result. I have some hope that jvm-bridge can be resurrected to bind to OpenNLP, but that's something I've only spent a few days thinking about. (I'd love to have some pointers / help / documentation on jvm-bridge, if anyone has insights :) --Rogan Thanks. -- Qi Qi ___ 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] can Haskell do everyting as we want?
On 4 August 2010 10:42, Rogan Creswick cresw...@gmail.com wrote: Haskell has very limited support for high-level Natural Language Processing [snip] This isn't a fault of the language, it just I have some hope that jvm-bridge can be resurrected to bind to OpenNLP, but that's something I've only spent a few days thinking about. (I'd love to have some pointers / help / documentation on jvm-bridge, if anyone has insights :) --Rogan Thanks. -- Qi Qi ___ 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 -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Suggestions For An Intro To Monads Talk.
On Aug 3, 2010, at 2:51 PM, aditya siram wrote:
I am looking for suggestions on how to introduce the concept and its
implications. I'd also like to include a section on why monads exist
and why we don't really see them outside of Haskell.
Start with functors (things that attach values/functions/functors to
values in an algebra). Move on to applicative functors (functors that
can interpret the thing that is getting things attached to it). Move
on to monads (applicative functors where you can explicitly control
the order of evaluation/interpretation).
Monads exist because every adjunction generates a monad, every monad
generates an adjunction, and adjunctions are everywhere. Any time you
can put things next to each other, you can create a monad that
captures the notion. A monad corresponds to putting things to the
left (at least syntactically) of the main object. A comonad
corresponds to putting things to the right of the main object
(assuming we observe the monad = left convention).
There are monads every where. They typically carry around extra
structure in other programming languages. That is, you can't quantify
over them, because they have been specialized. For example, any
language that has a map function automatically supports monadic
computation, in virtue of the fact that map accepts one argument
functions. (I.e., functions where the function's name goes on the
left, and the argument goes on the right)
sub minus_one = { $x = @_[0]; return $x * (-1); }
return map minus_one
map double
map square [1.. 10]
(I hardly remember Perl now though...) Notice that you can't change
the order of the operations without changing the semantics. This is
strictly a monadic computation, in Perl, PHP, etc. Ruby is a little
nicer than Perl, since it allows functors other than lists. If you
make a class a member of the Enumerate mixin, you can call .each on
the class's instances, give it a monadic (one argument) function, and
it returns a new functor over the relevant type of object.
funky_tree.each { node | node.value.square.double.minus_one }
(in the function composition case, or ... in the structurally
moandic case:)
funky_tree.each { node | node.value }
.each { value | square value }
.each { square' | double square' }
.each { doubled | minus_one double }
I doubt this is legal Ruby either. It's been a few years since I
touched it.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Arrays and image processing
Hi! I need to do some image processing for an algorithm. It involves two (well, three) different kinds of arrays. The result array I'm happy to leave as a Data.Array for now, since it tends to be bulk updated, and involves Either with tuples of tuples, and it's easy enough to switch to mutable without a significant impact. So far, using a mutable result array hasn't resulted in a significant speed difference, since it's not directly involved in the inner loops. But the static/immutable input arrays, the source images, are more of a present concern, since they are so directly involved with the inner loops, and are expected to be rather large. Right now, the algorithm is stable enough that it's time to move beyond black and white, which were well enough served by UArray and some ugly optimized inner functions which look rather like C loops, sigh. But now I need a fast multidimensional array which can handle a tuple of primitive types. My options, as far an I can see, are: 1) Add an instance for UArray (Int,Int) (Word16, Word16, Word16) and/or UArray (Int,Int) (Word8, Word8, Word8) 2) Add a multidimensional wrapper for Data.Vector 3) Use Data.Array.Repa. While in the currently released form, as opposed to the paper, it sadly lacks support for pairs, it's not too hard to coerce it into accepting :*:. Though, that seems to involve, for color in this case, three separate lookups. As a note, Repa is really quite lovely, but in my case/opinion, not quite there yet. I need folds/maps from one type to another unfortunately. On the one hand, I might be able to rewrite the statistical functions in a numerically stable integral and repa friendly form with a bit of thought. Though, that sort of feels like I'm programming in APL instead of Haskell, it shouldn't be so headache inducing. On the other hand, I don't really need parallelism, as my development laptop only has one cpu. Though the algorithm is eventually going to be translated to C and OpenCL for use on an embedded device. Still, this now involves even more delving into DPH. 4) Use DPH directly. While I don't really need data parallelism--for the development at least--this seems like the most accommodating option for my needs. But I worry about the stability and correctness. I really like the automatic loop fusion that Repa provides. It really goes a long way toward making the code simple and nice. I'm tempted to just start recoding the algorithm in C. It has to be done eventually, and it's kind of annoying that something which is trivial in C is such a headache here... Thanks for any help/pointers. Cheers, kirstin -- The end move in politics is always to pick up a gun. -- Buckminster Fuller ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Preview the new haddock look and take a short survey
The Haddock team has spent the last few months revamping the look of the generated output. We're pretty close to done, but we'd like to get the community's input before we put it in the main release. Please take a look, and then give us your feedback through a short survey Sample pages: http://www.ozonehouse.com/mark/snap-xhtml/index.html Frame version: http://www.ozonehouse.com/mark/snap-xhtml/frames.html Survey: http://spreadsheets.google.com/viewform?formkey=dHcwYzdMNkl5WER1aVBXdV9HX1l5U3c6MQ Short link to same survey: http://bit.ly/9Zvs9B Thanks! - Mark Mark Lentczner http://www.ozonehouse.com/mark/ irc: MtnViewMark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Suggestions For An Intro To Monads Talk.
Alexander == Alexander Solla a...@2piix.com writes: Alexander On Aug 3, 2010, at 2:51 PM, aditya siram wrote: I am looking for suggestions on how to introduce the concept and its implications. I'd also like to include a section on why monads exist and why we don't really see them outside of Haskell. Alexander Start with functors (things that attach Alexander values/functions/functors to values in an algebra). Move Alexander on to applicative functors (functors that can interpret Alexander the thing that is getting things attached to it). Move Alexander on to monads Too late! The audience has already dozed off. Alexander (applicative functors where you can Alexander explicitly control the order of Alexander evaluation/interpretation). -- Colin Adams Preston Lancashire () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Suggestions For An Intro To Monads Talk.
Hi, Please take a look at this video http://videoarch1.s-inf.de/FP.2005-SS-Giesl.(COt).HD_Videoaufzeichnung/2005-SS-FP.U09.2005-07-06.HDV.avi Here Monad's are explained as something that helps making your program modular. The teacher gives an example implementation of an expression evaluator with and without monads. It takes a complete rewrite to incorporate changes in the program without monads where as only minor tweaks are required for the implementation with monads - also, its easier to identify the location where change needs to be done and the change is isolated. And the flow is pretty nice - as in, people will not doze off :) Regards, Kashyap On Tue, Aug 3, 2010 at 10:04 PM, Colin Paul Adams co...@colina.demon.co.ukwrote: Alexander == Alexander Solla a...@2piix.com writes: Alexander On Aug 3, 2010, at 2:51 PM, aditya siram wrote: I am looking for suggestions on how to introduce the concept and its implications. I'd also like to include a section on why monads exist and why we don't really see them outside of Haskell. Alexander Start with functors (things that attach Alexander values/functions/functors to values in an algebra). Move Alexander on to applicative functors (functors that can interpret Alexander the thing that is getting things attached to it). Move Alexander on to monads Too late! The audience has already dozed off. Alexander (applicative functors where you can Alexander explicitly control the order of Alexander evaluation/interpretation). -- Colin Adams Preston Lancashire () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Regards, Kashyap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
