Re: [Haskell-cafe] Executables got bigger using dynamic link.
Sorry, I left the profiling option on, which seems to suppress the dynamic options. On Mon, Oct 29, 2012 at 1:29 PM, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: Hi, I set shared: True in ~/.cabal/config, and using ghc 7.6.1. Then clear user space hackages and reinstall them. First of all, I think comparing to static link, dynamic linked executables file should be smaller. And the libraries (.so) could benefits from caching to save memory usage. Well, I installed cabal-install and alex. I got this: cabal 9.9M - 24M alex 2.7M - 5.1M Is this correct? -- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com. -- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] non-uniform recursive Trie
Hello cafe,
I'm now studying Trie in Okasaki's Purely Functional Data Structure.
Attached is the program in its appendix. I cannot understand how to
use empty, look and bind. For instance, if I type 'look empty',
I got an error:
look empty
interactive:2:1:
No instance for (FiniteMap m0 [Char])
arising from a use of `look'
Possible fix: add an instance declaration for (FiniteMap m0 [Char])
In the expression: look empty
In an equation for `it': it = look empty
I have no idea how to determine the parameter 'm'. Suggestions would
be appreciated.
--Kazu
{-# LANGUAGE MultiParamTypeClasses, FlexibleInstances #-}
class FiniteMap m k where
empty :: m k v
look :: k - m k v - Maybe v
bind :: k - v - m k v - m k v
data Trie m ks v = Trie (Maybe v) (m (Trie m ks v))
instance FiniteMap m k = FiniteMap (Trie (m k)) [k] where
empty = Trie Nothing empty
look [] (Trie b _) = b
look (k:ks) (Trie _ m) = look k m = look ks
bind [] x (Trie _ m) = Trie (Just x) m
bind (k:ks) x (Trie b m) = Trie b (bind k t' m)
where
t = case look k m of
Just a - a
Nothing - empty
t' = bind ks x t
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC maintenance on Arch
I believe your main question (how do I do my work without wasting time) has already been answered: use IgnorePkg. I would like to add, in case you missed it, that there is a mailing list and community specifically for Haskell on Arch. Here is the webpage: https://wiki.archlinux.org/index.php/ArchHaskell The [haskell] repository is currently in sync with Hackage and builds with the latest ghc. (It does not yet include all of Hackage; your help would be welcome.) (The [haskell-web] and [haskell-extra] repos include more packages, with more or less in-sync-ness and omissions due to ghc 7.6 failures.) Ultimately we do want Arch packages for Haskell packages, because cabal is not a package manager (see https://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal-is-not-a-package-manager/ ). On Sun, Oct 28, 2012 at 8:49 PM, timothyho...@seznam.cz wrote: Hello, Who is in charge of the ghc and haskell packages on Arch linux? The current system isn't working. Arch linux tends to update packages very quickly. For ghc, always having the latest ghc isn't a good thing. At least if you actually want to get some work done. A majority of the time the latest GHC is unusable. This is because the packages in hackage simply don't keep up. With the current ghc version(7.6.1) even some basic packages in hackage are not upgraded yet. Right now, a large number of other haskell related packages are in the arch repos. Other than gtk2hs, I think these packages are pointless duplications. In the other cases, it has been my experience that it is simpler to maintain these packages through cabal rather than through pacman. Support for these packages in Arch should probably be dropped. If you want to get work done in Arch with haskell, you should only install ghc and cabal-install(right now, you'll have to search the Internet for the old binaries, because the arch repos usually don't keep the old versions around). Then you should add these packages to IgnorePkg = in pacman.conf this way things won't break every couple of months. You can then choose to upgrade when you wish. I hope that someone who is involved with the haskell Arch stuff reads this. The current model needs to be rethought. Linux should be sane by default, but I've lost many many hours learning that arch's relationship with haskell is not so :( Probably the best solution would be to make Arch automatically keep two versions of ghc around at any given time. Thank you for your time, Timothy Hobbs ___ 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] non-uniform recursive Trie
Hi Kazu. I'm now studying Trie in Okasaki's Purely Functional Data Structure. Attached is the program in its appendix. I cannot understand how to use empty, look and bind. For instance, if I type 'look empty', I got an error: look empty interactive:2:1: No instance for (FiniteMap m0 [Char]) arising from a use of `look' Possible fix: add an instance declaration for (FiniteMap m0 [Char]) In the expression: look empty In an equation for `it': it = look empty I have no idea how to determine the parameter 'm'. Suggestions would be appreciated. The code you've listed shows how to go from an already existing instance of class FiniteMap to an instance for the same class that adds a trie structure on top of the underlying finite map implementation. You have to add a base instance to the code so that it can work. For example, by importing Data.Map and adding an instance FiniteMap Data.Map.Map Char with the appropriate definitions. You'll also need to add extra type information to empty in your example expression so that GHC can know which instance you actually want. Cheers, Andres ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Segment Tree based Set
If you searched hackage, you'd find http://hackage.haskell.org/package/SegmentTree Roman * Tony Morris tonymor...@gmail.com [2012-10-29 15:38:07+1000] Er, oops. ...can be implemented as: \a rs - let s = Set.fromList (rs = \(a, b) - [a..b]) in a `member` s Something like that! On Mon, Oct 29, 2012 at 2:48 PM, Tony Morris tonymor...@gmail.com wrote: Hi, I was wondering if anyone knows of a package implementing a fast lookup for an element in ranges. For example, this operation: Ord a = a - [(a, a)] - Bool ...can be implemented: \a rs - let s = Set.fromList rs in a `member` s This is not particularly efficient. A segment tree seems like a more appropriate data structure to store the ranges. Does such a library exist? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Segment Tree based Set
It is not a Set, but a Map. Of course, I could use it to implement the function I need with something like: type SSet a = STree [()] a, but then I'd have to unnecessarily go beyond Haskell98. Hoping there might be an interval tree or segment tree specifically for this task. On 29/10/12 18:36, Roman Cheplyaka wrote: If you searched hackage, you'd find http://hackage.haskell.org/package/SegmentTree Roman * Tony Morris tonymor...@gmail.com [2012-10-29 15:38:07+1000] Er, oops. ...can be implemented as: \a rs - let s = Set.fromList (rs = \(a, b) - [a..b]) in a `member` s Something like that! On Mon, Oct 29, 2012 at 2:48 PM, Tony Morris tonymor...@gmail.com wrote: Hi, I was wondering if anyone knows of a package implementing a fast lookup for an element in ranges. For example, this operation: Ord a = a - [(a, a)] - Bool ...can be implemented: \a rs - let s = Set.fromList rs in a `member` s This is not particularly efficient. A segment tree seems like a more appropriate data structure to store the ranges. Does such a library exist? -- Tony Morris http://tmorris.net/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] non-uniform recursive Trie
Andres, The code you've listed shows how to go from an already existing instance of class FiniteMap to an instance for the same class that adds a trie structure on top of the underlying finite map implementation. You have to add a base instance to the code so that it can work. For example, by importing Data.Map and adding an instance FiniteMap Data.Map.Map Char with the appropriate definitions. Thank you. I added the following: instance FiniteMap Map Char where empty = M.empty look = M.lookup bind = M.insert You'll also need to add extra type information to empty in your example expression so that GHC can know which instance you actually want. Is the follwing what you mean? look bar $ bind bar 1 $ (empty :: Trie (Map Char) String Int) Just 1 P.S. FiniteMap uses another finite map, Data.Map in this case. I wonder why we can call it bootstrapping... --Kazu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Maximum bipartite matching: 24 lines
I didn't analyze it but anytime I see M.insertWith I am just in doubt - do you know about a strict version M.insertWith' ? 2012/10/24 Stefan Klinger all-li...@stefan-klinger.de On 2012-Oct-22 14:23 (-0700), Eugene Kirpichov wrote with possible deletions: fwd = foldr (\(x,y) - M.insertWith (++) x [y]) M.empty $ S.toList g Use foldl' here, foldr is absolutely useless here and it only consumes the stack space as your operation is strict. Thank you very much for that. I'll review the code under strictness aspects. As for the actual code: I'd prefer the code itself to be more readable, rather than have a lot of literate comments around it; I like comments documenting why something's done, complementing the code which tells what's done. currently, IMO all the uncurry's, flips, eithers, maybes and point-free style hurt readability heavily. I agree. Between babbling bloated and incomprehensible terse, my code is certainly towards the terse extreme. For me, that's a balancing act that I find hard to do right. I'll probably try to write my own version as an exercise :) Cool! I'd like to see that... Cheers! Stefan -- Stefan Klinger o/klettern /\/ bis zum send plaintext only - max size 32kB - no spam \ Abfallen http://stefan-klinger.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC maintenance on Arch
Hello Timothy, Now I'm going to run the risk of upsetting you quite a bit by being completely blunt. You come across in your mail like someone who has thought through your own situation, but fail to see the larger picture. You do know *your* Haskell needs, and you know what *you* would want from a project like ArchHaskell. Then however you completely fail to realise that these are *your needs*, not anyone else's, but still you suggest that ArchHaskelll is broken because it doesn't provide a system that solves *your* problems. I suggest you take your insights of your situation and try to find a solution that works for you, and it sounds like you're on the way already with cabal-install. If you have suggestions on how to improve ArchHaskell *within the goals of the project* (which includes the general goals of ArchLinux) that would make ArchHaskell more usable to you, then you are more than welcome. However, if all you do is suggest that we completely change the goals of ArchHaskell because they don't align with your needs, then we thank you for your input, but ask you to not hold your breath for any changes. /M On Sun, Oct 28, 2012 at 9:49 PM, timothyho...@seznam.cz wrote: Hello, Who is in charge of the ghc and haskell packages on Arch linux? The current system isn't working. Arch linux tends to update packages very quickly. For ghc, always having the latest ghc isn't a good thing. At least if you actually want to get some work done. A majority of the time the latest GHC is unusable. This is because the packages in hackage simply don't keep up. With the current ghc version(7.6.1) even some basic packages in hackage are not upgraded yet. Right now, a large number of other haskell related packages are in the arch repos. Other than gtk2hs, I think these packages are pointless duplications. In the other cases, it has been my experience that it is simpler to maintain these packages through cabal rather than through pacman. Support for these packages in Arch should probably be dropped. If you want to get work done in Arch with haskell, you should only install ghc and cabal-install(right now, you'll have to search the Internet for the old binaries, because the arch repos usually don't keep the old versions around). Then you should add these packages to IgnorePkg = in pacman.conf this way things won't break every couple of months. You can then choose to upgrade when you wish. I hope that someone who is involved with the haskell Arch stuff reads this. The current model needs to be rethought. Linux should be sane by default, but I've lost many many hours learning that arch's relationship with haskell is not so :( Probably the best solution would be to make Arch automatically keep two versions of ghc around at any given time. Thank you for your time, Timothy Hobbs ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Segment Tree based Set
On Mon, Oct 29, 2012 at 9:43 AM, Tony Morris tonymor...@gmail.com wrote: It is not a Set, but a Map. Of course, I could use it to implement the function I need with something like: type SSet a = STree [()] a, but then I'd have to unnecessarily go beyond Haskell98. Couldn't you just use : instance Measured (Interval a) Bool where measure _ = True Then the normal functions of SegmentTree would do what you wish for, no ? You don't need much beyond Haskell 98 (MPTC is used everywhere already). -- Jedaï ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC maintenance on Arch
In his defense, from the perspective of a more or less newbie in the subject matter, I had quite a bit of trouble using Haskell under Arch. Not that it is so much better in other systems, I wouldn't know. I often was in the position to decide whether to use cabal-install, arch-haskell repositories or official repositories and many times the thing that worked for me was a mix of everything, which is quite sub-optimal, although more or less working for me at the moment. I'm not saying that this is because the way Arch works or the way Cabal is designed is wrong. Maybe it is because I'm not figuring it out. Some people say you should not use cabal-install as a package manager, because it is not supposed to be one. Again, other people say arch-haskell repositories are very buggy at the moment and one should install only cabal-install and ghc from the official repositories and only use cabal-install for the rest. Just telling my experience so far: I often have had to struggle between cabal dependency hell and non-working packages in the repositories. Either something is very wrong with the way things are right now or I'm doing everything wrong (which is more likely). I am still not in the condition of proposing things myself, but I don't think this is fair treatment so far to someone that is proposing a compromise solution to a problem he found. Anyway, hopefully this would be better clarified in the arch-haskell mailing list. 2012/10/29 Magnus Therning mag...@therning.org: Hello Timothy, Now I'm going to run the risk of upsetting you quite a bit by being completely blunt. You come across in your mail like someone who has thought through your own situation, but fail to see the larger picture. You do know *your* Haskell needs, and you know what *you* would want from a project like ArchHaskell. Then however you completely fail to realise that these are *your needs*, not anyone else's, but still you suggest that ArchHaskelll is broken because it doesn't provide a system that solves *your* problems. I suggest you take your insights of your situation and try to find a solution that works for you, and it sounds like you're on the way already with cabal-install. If you have suggestions on how to improve ArchHaskell *within the goals of the project* (which includes the general goals of ArchLinux) that would make ArchHaskell more usable to you, then you are more than welcome. However, if all you do is suggest that we completely change the goals of ArchHaskell because they don't align with your needs, then we thank you for your input, but ask you to not hold your breath for any changes. /M On Sun, Oct 28, 2012 at 9:49 PM, timothyho...@seznam.cz wrote: Hello, Who is in charge of the ghc and haskell packages on Arch linux? The current system isn't working. Arch linux tends to update packages very quickly. For ghc, always having the latest ghc isn't a good thing. At least if you actually want to get some work done. A majority of the time the latest GHC is unusable. This is because the packages in hackage simply don't keep up. With the current ghc version(7.6.1) even some basic packages in hackage are not upgraded yet. Right now, a large number of other haskell related packages are in the arch repos. Other than gtk2hs, I think these packages are pointless duplications. In the other cases, it has been my experience that it is simpler to maintain these packages through cabal rather than through pacman. Support for these packages in Arch should probably be dropped. If you want to get work done in Arch with haskell, you should only install ghc and cabal-install(right now, you'll have to search the Internet for the old binaries, because the arch repos usually don't keep the old versions around). Then you should add these packages to IgnorePkg = in pacman.conf this way things won't break every couple of months. You can then choose to upgrade when you wish. I hope that someone who is involved with the haskell Arch stuff reads this. The current model needs to be rethought. Linux should be sane by default, but I've lost many many hours learning that arch's relationship with haskell is not so :( Probably the best solution would be to make Arch automatically keep two versions of ghc around at any given time. Thank you for your time, Timothy Hobbs ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org
[Haskell-cafe] Optimal line length for haskell
There was a recent discussion on the python list regarding maximum line length. It occured to me that beautiful haskell programs tend to be plump (ie have long lines) compared to other languages whose programs are 'skinnier'. My thoughts on this are at http://blog.languager.org/2012/10/layout-imperative-in-functional.html. Are there more striking examples than the lexer from the standard prelude? [Or any other thoughts/opinions :-) ] Thanks, Rusi ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimal line length for haskell
On Mon, Oct 29, 2012 at 05:20:20PM +0530, Rustom Mody wrote: There was a recent discussion on the python list regarding maximum line length. It occured to me that beautiful haskell programs tend to be plump (ie have long lines) compared to other languages whose programs are 'skinnier'. My thoughts on this are at http://blog.languager.org/2012/10/layout-imperative-in-functional.html. Are there more striking examples than the lexer from the standard prelude? [Or any other thoughts/opinions :-) ] For what is worth, in our project (Ganeti) which has a mixed Python/Haskell codebase, we're using the same maximum length (80-but-really-79) in both languages, without any (real) issues. regards, iustin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimal line length for haskell
On Mon, Oct 29, 2012 at 5:29 PM, Iustin Pop ius...@google.com wrote: On Mon, Oct 29, 2012 at 05:20:20PM +0530, Rustom Mody wrote: There was a recent discussion on the python list regarding maximum line length. It occured to me that beautiful haskell programs tend to be plump (ie have long lines) compared to other languages whose programs are 'skinnier'. My thoughts on this are at http://blog.languager.org/2012/10/layout-imperative-in-functional.html. Are there more striking examples than the lexer from the standard prelude? [Or any other thoughts/opinions :-) ] For what is worth, in our project (Ganeti) which has a mixed Python/Haskell codebase, we're using the same maximum length (80-but-really-79) in both languages, without any (real) issues. regards, iustin Sure! There can hardly be a case that 80 causes any issues. Just that a bit more than 80 can sometimes lead to distinctly more elegant programs. Too much more than 80 can cause issues with readability and/or other tools. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimal line length for haskell
It is kind of ironic that the wide code examples in the blog post are wrapped at 65 chars by the blog formatting. Regards, Malcolm On 29 Oct 2012, at 11:50, Rustom Mody wrote: There was a recent discussion on the python list regarding maximum line length. It occured to me that beautiful haskell programs tend to be plump (ie have long lines) compared to other languages whose programs are 'skinnier'. My thoughts on this are at http://blog.languager.org/2012/10/layout-imperative-in-functional.html. Are there more striking examples than the lexer from the standard prelude? [Or any other thoughts/opinions :-) ] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimal line length for haskell
* Rustom Mody rustompm...@gmail.com [2012-10-29 17:20:20+0530] There was a recent discussion on the python list regarding maximum line length. It occured to me that beautiful haskell programs tend to be plump (ie have long lines) compared to other languages whose programs are 'skinnier'. My thoughts on this are at http://blog.languager.org/2012/10/layout-imperative-in-functional.html. Are there more striking examples than the lexer from the standard prelude? [Or any other thoughts/opinions :-) ] Indeed, I've seen quite a few Haskell projects with long lines. Personally, I find it hard to read and very irritating. I always use 80-chars lines in my projects. It seems that people who write long lines mostly come from academic background, where there's less emphasis on maintainability (no offense; also, I haven't conducted a proper statistical research — this is just an impression). Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimal line length for haskell
On Mon, Oct 29, 2012 at 5:40 PM, Malcolm Wallace malcolm.wall...@me.comwrote: It is kind of ironic that the wide code examples in the blog post are wrapped at 65 chars by the blog formatting. Regards, Malcolm Well that goes to underscore a couple of points: 1. The fixed 80 char width that was inviolable decades ago breaks today on both sides: it may be too low or too high! 2. I guess I dont know how to use blogger very well :-) 3. Are you viewing on a narrow device? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimal line length for haskell
I'm not viewing on a narrow device, and I see the wrapped (and the whole post confined to the centre of the screen). I certainly don't use an 80-column limit any more. I use the rule: A function must be completely visible in my editor on my screen. (but this is only a good rule if most people who will be reading the code will also have a similar sized viewport. After all, code is far more often read than written.) And I balance line length with function length. On 29 October 2012 12:18, Rustom Mody rustompm...@gmail.com wrote: On Mon, Oct 29, 2012 at 5:40 PM, Malcolm Wallace malcolm.wall...@me.comwrote: It is kind of ironic that the wide code examples in the blog post are wrapped at 65 chars by the blog formatting. Regards, Malcolm Well that goes to underscore a couple of points: 1. The fixed 80 char width that was inviolable decades ago breaks today on both sides: it may be too low or too high! 2. I guess I dont know how to use blogger very well :-) 3. Are you viewing on a narrow device? ___ 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] Optimal line length for haskell
Colin Adams colinpaulad...@gmail.com wrote: I'm not viewing on a narrow device, and I see the wrapped (and the whole post confined to the centre of the screen). I certainly don't use an 80-column limit any more. I use the rule: A function must be completely visible in my editor on my screen. (but this is only a good rule if most people who will be reading the code will also have a similar sized viewport. After all, code is far more often read than written.) I don't think similar sized viewport begins to cover it. If the editor wraps long lines, then the lines will always be visible, no matter how long they are. Of course, lines wrapped around to the beginning of the next line in indented code are really, really ugly, so I'd prefer to avoid that. This is one of the cases where it's more important that there be a standard than what the actual value is. Personally, I like roughly 80 columns, but I've been dong this long enough to have used the things that the 80-column console format was copied from. That screens are now bigger isn't really relevant. They are also windowed - no matter how hard Windows, Linux and Mac apps try and pretend they own the entire screen - and multitasking, so it's unreasonable to format code as if the editor were going to be the only visible window. On the other hand, readable cross-platform text formatting always seems to be a lost cause, as this mail and the referenced blog posting demonstrate. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimal line length for haskell
On Mon, Oct 29, 2012 at 5:55 PM, Colin Adams colinpaulad...@gmail.comwrote: I'm not viewing on a narrow device, and I see the wrapped (and the whole post confined to the centre of the screen). I certainly don't use an 80-column limit any more. I use the rule: A function must be completely visible in my editor on my screen. (but this is only a good rule if most people who will be reading the code will also have a similar sized viewport. After all, code is far more often read than written.) And I balance line length with function length. Very good point: getting the line to fit in one screen-line is of comparable importance to getting a function into one screen. And especially when one is teaching, (as Roman easily figured out!) having to scroll up and down in the midst of explanations is a certain show-spoiler. On Mon, Oct 29, 2012 at 6:40 PM, Mike Meyer m...@mired.org wrote: On the other hand, readable cross-platform text formatting always seems to be a lost cause, as this mail and the referenced blog posting demonstrate. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. As for the wraparound problems, hopefully they are now solved (for normal computers!) I'd appreciate hearing if they are not. And Thanks Colin for the debugging support! Clearly prettifying code and prettifying a blog are different issues and putting them together makes a harder constraint-solving problem (especially for a blogger noob!) Rusi ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimal line length for haskell
On 10/29/2012 07:50 AM, Rustom Mody wrote: There was a recent discussion on the python list regarding maximum line length. It occured to me that beautiful haskell programs tend to be plump (ie have long lines) compared to other languages whose programs are 'skinnier'. My thoughts on this are at http://blog.languager.org/2012/10/layout-imperative-in-functional.html. Are there more striking examples than the lexer from the standard prelude? [Or any other thoughts/opinions :-) ] In any language, a line longer than 80 characters usually (but not always) suggests that you might want to stop and rethink your design. In many cases a refactoring or two will greatly simplify the code and reduce your line length as a result. I think the lexer is an example of refactoring-needed rather than long-lines-needed. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC maintenance on Arch
On Mon, Oct 29, 2012 at 5:56 AM, Magnus Therning mag...@therning.orgwrote: Now I'm going to run the risk of upsetting you quite a bit by being completely blunt. Indeed. You come across in your mail like someone who has thought through your own situation, but fail to see the larger picture. You do know *your* May I ask you a question, then? Does the Haskell Platform have any reason to exist? Supposedly, the Haskell community backs the Haskell Platform as the way that most users should be using the Platform. Yet we have here a vendor platform which does not support it, and newcomers who notice this and question it are chastised for not thinking about the needs of other people. This suggests that the Haskell Platform is unimportant and perhaps disruptive to some significant group of people... is this so? And then, looking at your own message, I must ask: have you considered that the Platform is aimed at the great many people who do not have large amounts of expertise maintaining their own personal Haskell ecosystem. Or are your needs so important that these people must in fact be told to deal? Or, to phrase in your own words: You come across in your mail like someone who has thought through your own situation, but fail to see the larger picture. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix/linux, openafs, kerberos, infrastructure http://sinenomine.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimal line length for haskell
If I find my line is longer than 80 characters, I just shorten my function and variable names! It's perfectly idio(ma)tic! On Mon, Oct 29, 2012 at 9:52 PM, Michael Orlitzky mich...@orlitzky.com wrote: On 10/29/2012 07:50 AM, Rustom Mody wrote: There was a recent discussion on the python list regarding maximum line length. It occured to me that beautiful haskell programs tend to be plump (ie have long lines) compared to other languages whose programs are 'skinnier'. My thoughts on this are at http://blog.languager.org/2012/10/layout-imperative-in-functional.html. Are there more striking examples than the lexer from the standard prelude? [Or any other thoughts/opinions :-) ] In any language, a line longer than 80 characters usually (but not always) suggests that you might want to stop and rethink your design. In many cases a refactoring or two will greatly simplify the code and reduce your line length as a result. I think the lexer is an example of refactoring-needed rather than long-lines-needed. ___ 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] Optimal line length for haskell
On Mon, Oct 29, 2012 at 6:52 AM, Michael Orlitzky mich...@orlitzky.comwrote: On 10/29/2012 07:50 AM, Rustom Mody wrote: There was a recent discussion on the python list regarding maximum line length. It occured to me that beautiful haskell programs tend to be plump (ie have long lines) compared to other languages whose programs are 'skinnier'. My thoughts on this are at http://blog.languager.org/2012/10/layout-imperative-in-functional.html. Are there more striking examples than the lexer from the standard prelude? [Or any other thoughts/opinions :-) ] In any language, a line longer than 80 characters usually (but not always) suggests that you might want to stop and rethink your design. In many cases a refactoring or two will greatly simplify the code and reduce your line length as a result. I disagree. That might be true for imperative languages, where width is indicative of deep nesting and its associated problems. But it is not true for a functional language, where it is merely indicative of a wide normal form. Yes, the normal form can sometimes be refactored, but to what end? You might easily end up refactoring out of the level of abstraction you actually want. Or the wide form might have useful properties, like the ability to sort the lines of source code alphanumerically (which would be lost if you switched to a stanza-based format) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimal line length for haskell
I stick to 80 columns fairly rigidly. This is not only so that it fits into narrow windows, but also so that any two subexpressions in the same expression tend to be close together on my screen, which makes it easier for me to reason about it. If only it was easy for me to read and write code on a Hilbert curve... :) I don't think long lines indicate a design problem; it's solely a formatting thing. On Mon, Oct 29, 2012 at 7:50 AM, Rustom Mody rustompm...@gmail.com wrote: There was a recent discussion on the python list regarding maximum line length. It occured to me that beautiful haskell programs tend to be plump (ie have long lines) compared to other languages whose programs are 'skinnier'. My thoughts on this are at http://blog.languager.org/2012/10/layout-imperative-in-functional.html. Are there more striking examples than the lexer from the standard prelude? [Or any other thoughts/opinions :-) ] Thanks, Rusi ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC maintenance on Arch
If all you want is the Haskell Platform, I believe the Arch policy is to provide all those packages in the official [extra] repository. (If those are broken because of the new ghc, just use IgnorePkg to avoid the ghc update.) The [haskell] and other ArchHaskell repos are for the rest of Hackage that's not in the Platform. On Mon, Oct 29, 2012 at 1:53 PM, Brandon Allbery allber...@gmail.comwrote: On Mon, Oct 29, 2012 at 5:56 AM, Magnus Therning mag...@therning.orgwrote: Now I'm going to run the risk of upsetting you quite a bit by being completely blunt. Indeed. You come across in your mail like someone who has thought through your own situation, but fail to see the larger picture. You do know *your* May I ask you a question, then? Does the Haskell Platform have any reason to exist? Supposedly, the Haskell community backs the Haskell Platform as the way that most users should be using the Platform. Yet we have here a vendor platform which does not support it, and newcomers who notice this and question it are chastised for not thinking about the needs of other people. This suggests that the Haskell Platform is unimportant and perhaps disruptive to some significant group of people... is this so? And then, looking at your own message, I must ask: have you considered that the Platform is aimed at the great many people who do not have large amounts of expertise maintaining their own personal Haskell ecosystem. Or are your needs so important that these people must in fact be told to deal? Or, to phrase in your own words: You come across in your mail like someone who has thought through your own situation, but fail to see the larger picture. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix/linux, openafs, kerberos, infrastructure http://sinenomine.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC maintenance on Arch
Please stay on topic, this is *not* a discussion about Haskell Platform[1], it's a discussion on ArchHaskell[2]. Please read up on the mailing list archives first, and then, if you still feel there's a need to discuss HP in ArchHaskell (which isn't the same thing as Arch itself) then please start a new thread. /M [1]: http://www.haskell.org/platform/ [2]: https://wiki.archlinux.org/index.php/ArchHaskell On Mon, Oct 29, 2012 at 2:53 PM, Brandon Allbery allber...@gmail.com wrote: On Mon, Oct 29, 2012 at 5:56 AM, Magnus Therning mag...@therning.org wrote: Now I'm going to run the risk of upsetting you quite a bit by being completely blunt. Indeed. You come across in your mail like someone who has thought through your own situation, but fail to see the larger picture. You do know *your* May I ask you a question, then? Does the Haskell Platform have any reason to exist? Supposedly, the Haskell community backs the Haskell Platform as the way that most users should be using the Platform. Yet we have here a vendor platform which does not support it, and newcomers who notice this and question it are chastised for not thinking about the needs of other people. This suggests that the Haskell Platform is unimportant and perhaps disruptive to some significant group of people... is this so? And then, looking at your own message, I must ask: have you considered that the Platform is aimed at the great many people who do not have large amounts of expertise maintaining their own personal Haskell ecosystem. Or are your needs so important that these people must in fact be told to deal? Or, to phrase in your own words: You come across in your mail like someone who has thought through your own situation, but fail to see the larger picture. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix/linux, openafs, kerberos, infrastructure http://sinenomine.net -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC maintenance on Arch
I think you will find that the Original Poster did not ask about ArchHaskell, but rather about Haskell on the Arch platform. He was completely unaware of ArchHaskell as a project. This might be a source of some confusion, and help to explain divergent attitudes. Regards, Malcolm On 29 Oct 2012, at 14:41, Magnus Therning wrote: Please stay on topic, this is *not* a discussion about Haskell Platform[1], it's a discussion on ArchHaskell[2]. Please read up on the mailing list archives first, and then, if you still feel there's a need to discuss HP in ArchHaskell (which isn't the same thing as Arch itself) then please start a new thread. /M [1]: http://www.haskell.org/platform/ [2]: https://wiki.archlinux.org/index.php/ArchHaskell On Mon, Oct 29, 2012 at 2:53 PM, Brandon Allbery allber...@gmail.com wrote: On Mon, Oct 29, 2012 at 5:56 AM, Magnus Therning mag...@therning.org wrote: Now I'm going to run the risk of upsetting you quite a bit by being completely blunt. Indeed. You come across in your mail like someone who has thought through your own situation, but fail to see the larger picture. You do know *your* May I ask you a question, then? Does the Haskell Platform have any reason to exist? Supposedly, the Haskell community backs the Haskell Platform as the way that most users should be using the Platform. Yet we have here a vendor platform which does not support it, and newcomers who notice this and question it are chastised for not thinking about the needs of other people. This suggests that the Haskell Platform is unimportant and perhaps disruptive to some significant group of people... is this so? And then, looking at your own message, I must ask: have you considered that the Platform is aimed at the great many people who do not have large amounts of expertise maintaining their own personal Haskell ecosystem. Or are your needs so important that these people must in fact be told to deal? Or, to phrase in your own words: You come across in your mail like someone who has thought through your own situation, but fail to see the larger picture. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix/linux, openafs, kerberos, infrastructure http://sinenomine.net -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus ___ 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] Optimal line length for haskell
On 10/29/2012 10:28 AM, Alexander Solla wrote: In any language, a line longer than 80 characters usually (but not always) suggests that you might want to stop and rethink your design. In many cases a refactoring or two will greatly simplify the code and reduce your line length as a result. I disagree. That might be true for imperative languages, where width is indicative of deep nesting and its associated problems. But it is not true for a functional language, where it is merely indicative of a wide normal form. Yes, the normal form can sometimes be refactored, but to what end? You might easily end up refactoring out of the level of abstraction you actually want. Or the wide form might have useful properties, like the ability to sort the lines of source code alphanumerically (which would be lost if you switched to a stanza-based format) Well, I did leave the door open for special cases with usually (but not always). I know I've had to go over 80 chars before with huge constants or long test names. If you're willing to sacrifice maintain/readability for some other property (e.g. source code sortability), then I don't think my point applies. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC maintenance on Arch
To be clear, the project ArchHaskell has little or no relation to my original post. If I understand correctly, ArchHaskell is a set of Arch uses who attempted to repackage the packages in hackage in the AUR. This addresses issues of package management that are unrelated to my complaint. My complaint is that Arch currently does not support having two versions of GHC installed and GHC does not support backwards compatibility. The current method of always updating GHC to the latest version, discarding the old version is useful to the most hard core bleeding edge types. An alternative model for those of us that need a consistently usable system is not well supported. Currently updating ghc the normal way always breaks your build system. Arch has addressed this issue with a number of other packages. Perhaps the best comparison would be ghchttps://www.archlinux.org/packages/ extra/x86_64/ghc/ verse linuxhttps://www.archlinux.org/packages/core/i686/ linux/. With linux, we have a linux package and a linux-ltshttps:// www.archlinux.org/packages/core/x86_64/linux-lts/ package. These are the same, but linux-lts gets updated slightly less often and with less expedition. This problem has been had in Arch, it's been solved, and we should take the example of these other cases I have provided and make two ghc packages, so that there is a standard supported sane way to use ghc on arch linux. This isn't a problem that affects me personally these days. As an advanced user I don't really have any trouble working around the issue. But I'd like Arch to be inviting to newbies and to have what most of us more experienced users implement manually by default. Timothy -- Původní zpráva -- Od: Malcolm Wallace malcolm.wall...@me.com Datum: 29. 10. 2012 Předmět: Re: [Haskell-cafe] GHC maintenance on Arch I think you will find that the Original Poster did not ask about ArchHaskell, but rather about Haskell on the Arch platform. He was completely unaware of ArchHaskell as a project. This might be a source of some confusion, and help to explain divergent attitudes. Regards, Malcolm On 29 Oct 2012, at 14:41, Magnus Therning wrote: Please stay on topic, this is *not* a discussion about Haskell Platform[1], it's a discussion on ArchHaskell[2]. Please read up on the mailing list archives first, and then, if you still feel there's a need to discuss HP in ArchHaskell (which isn't the same thing as Arch itself) then please start a new thread. /M [1]: http://www.haskell.org/platform/(http://www.haskell.org/platform/) [2]: https://wiki.archlinux.org/index.php/ArchHaskell (https://wiki.archlinux.org/index.php/ArchHaskell) On Mon, Oct 29, 2012 at 2:53 PM, Brandon Allbery allber...@gmail.com wrote: On Mon, Oct 29, 2012 at 5:56 AM, Magnus Therning mag...@therning.org wrote: Now I'm going to run the risk of upsetting you quite a bit by being completely blunt. Indeed. You come across in your mail like someone who has thought through your own situation, but fail to see the larger picture. You do know *your* May I ask you a question, then? Does the Haskell Platform have any reason to exist? Supposedly, the Haskell community backs the Haskell Platform as the way that most users should be using the Platform. Yet we have here a vendor platform which does not support it, and newcomers who notice this and question it are chastised for not thinking about the needs of other people. This suggests that the Haskell Platform is unimportant and perhaps disruptive to some significant group of people... is this so? And then, looking at your own message, I must ask: have you considered that the Platform is aimed at the great many people who do not have large amounts of expertise maintaining their own personal Haskell ecosystem. Or are your needs so important that these people must in fact be told to deal? Or, to phrase in your own words: You come across in your mail like someone who has thought through your own situation, but fail to see the larger picture. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix/linux, openafs, kerberos, infrastructure http://sinenomine.net (http://sinenomine.net) -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus(http://therning.org/magnus) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe (http://www.haskell.org/mailman/listinfo/haskell-cafe) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe (http://www.haskell.org/mailman/listinfo/haskell-cafe)___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org
Re: [Haskell-cafe] Optimal line length for haskell
I also stick to a pretty rigid 78 characters. Doing so actually helps me fit more code onto my screen at a time because I usually have two or three columns of open files side by side. I find that I need this more often than I need to see a single function on a page (thanks to Haskell's traditionally small functions). But this works for single functions as well because I can open the same file in multiple columns at different locations in the file. The ideal line length for text layout is based on the physiology of the human eye… At normal reading distance the arc of the visual field is only a few inches – about the width of a well-designed column of text, or about 12 words per line. Research shows that reading slows and retention rates fall as line length begins to exceed the ideal width, because the reader then needs to use the muscles of the eye and neck to track from the end of one line to the beginning of the next line. If the eye must traverse great distances on the page, the reader is easily lost and must hunt for the beginning of the next line. Quantitative studies show that moderate line lengths significantly increase the legibility of text. Web Style Guide – Basic Design Principles for Creating Website Patrick J. Lynch and Sarah Horton 2nd edition, page 97. On Mon, Oct 29, 2012 at 10:37 AM, Jake McArthur jake.mcart...@gmail.com wrote: I stick to 80 columns fairly rigidly. This is not only so that it fits into narrow windows, but also so that any two subexpressions in the same expression tend to be close together on my screen, which makes it easier for me to reason about it. If only it was easy for me to read and write code on a Hilbert curve... :) I don't think long lines indicate a design problem; it's solely a formatting thing. On Mon, Oct 29, 2012 at 7:50 AM, Rustom Mody rustompm...@gmail.com wrote: There was a recent discussion on the python list regarding maximum line length. It occured to me that beautiful haskell programs tend to be plump (ie have long lines) compared to other languages whose programs are 'skinnier'. My thoughts on this are at http://blog.languager.org/2012/10/layout-imperative-in-functional.html. Are there more striking examples than the lexer from the standard prelude? [Or any other thoughts/opinions :-) ] Thanks, Rusi ___ 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
Re: [Haskell-cafe] Optimal line length for haskell
I would prefer to completely ignore line lengths when writing Haskell. In general, giving good names to things in where-clauses automatically keeps my code short enough. My opinion is that different people like different code layouts, and when formatting code in certain ways, we will always have to make compromises. I would like if there was a layout normal form for storing Haskell code - all code presented to humans should be shown just as that human likes it best. In the future, I would like to work on a personalizable real-time formatter that editors can hook into, using haskell-src-exts. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimal line length for haskell
On Mon, Oct 29, 2012 at 03:50:57PM +, Niklas Hambüchen wrote: I would prefer to completely ignore line lengths when writing Haskell. In general, giving good names to things in where-clauses automatically keeps my code short enough. My opinion is that different people like different code layouts, and when formatting code in certain ways, we will always have to make compromises. I would like if there was a layout normal form for storing Haskell code - all code presented to humans should be shown just as that human likes it best. In the future, I would like to work on a personalizable real-time formatter that editors can hook into, using haskell-src-exts. +1 to that; I know that it would indeed increase my productivity… iustin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC maintenance on Arch
Hi Timothy, the Haskell community is not the right audience to be addressing these complaints to. Instead, you should be talking to the ArchLinux developers, who are responsible for packaging Haskell-related software in the [core] and [extra] repositories. I am no expert in these matters, but my guess is that the mailing list https://mailman.archlinux.org/mailman/listinfo/arch-dev-public is more appropriate than haskell-cafe for this thread. Take care, Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimal line length for haskell
On Mon, Oct 29, 2012 at 7:58 PM, Alexander Solla alex.so...@gmail.comwrote: On Mon, Oct 29, 2012 at 6:52 AM, Michael Orlitzky mich...@orlitzky.comwrote: On 10/29/2012 07:50 AM, Rustom Mody wrote: There was a recent discussion on the python list regarding maximum line length. It occured to me that beautiful haskell programs tend to be plump (ie have long lines) compared to other languages whose programs are 'skinnier'. My thoughts on this are at http://blog.languager.org/2012/10/layout-imperative-in-functional.html. Are there more striking examples than the lexer from the standard prelude? [Or any other thoughts/opinions :-) ] In any language, a line longer than 80 characters usually (but not always) suggests that you might want to stop and rethink your design. In many cases a refactoring or two will greatly simplify the code and reduce your line length as a result. I disagree. That might be true for imperative languages, where width is indicative of deep nesting and its associated problems. But it is not true for a functional language, where it is merely indicative of a wide normal form. Yes, the normal form can sometimes be refactored, but to what end? You might easily end up refactoring out of the level of abstraction you actually want. Or the wide form might have useful properties, like the ability to sort the lines of source code alphanumerically (which would be lost if you switched to a stanza-based format) Interesting points. In fact my wish for using (when appropriate) a wide form is related to some hunch about this 'wide normal form' Can you throw some light on how one may understand that phraset? Also BTW Ive cleaned up the post again. Since my ineptitude with blogger was looking like an ineptitude with haskell (which may well be there and more :-) ) Ive moved the wide code to gist. I believe the code examples speak differently in this new format Rusi -- http://blog.languager.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Safe lens?
Why are getters from the 'lens' package unsafe? Is there a subset
like Data.Label.Pure from 'fclabels' that can be imported safely?
$ cat a.hs
{-# LANGUAGE Safe #-}
import Control.Lens.Getter
main = print 123
$ runghc a.hs
a.hs:3:1:
Control.Lens.Getter: Can't be safely imported!
The module itself isn't safe.
Thanks,
Greg
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Safe lens?
Hi
I believe the reason is that it uses TemplateHaskell for automatic
derivation of labels. And TemplateHaskell is of course unsafe, since
it could convert your code into something entirely different.
Best regards,
Petr Pudlak
2012/10/29 Greg Fitzgerald gari...@gmail.com:
Why are getters from the 'lens' package unsafe? Is there a subset
like Data.Label.Pure from 'fclabels' that can be imported safely?
$ cat a.hs
{-# LANGUAGE Safe #-}
import Control.Lens.Getter
main = print 123
$ runghc a.hs
a.hs:3:1:
Control.Lens.Getter: Can't be safely imported!
The module itself isn't safe.
Thanks,
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] GHC maintenance on Arch
I fail to see how a fringe bleeding edge linux distro undermines a haskell platform. Arch is bleeding edge. Haskell Platform is not. It is logical for a bleeding edge distro to include latest packages. If you want a good support, use distros that provide such support and stability. Last i checked Ubuntu ships haskell platform and not the latest ghc. Having said that, Arch DOES provide easy solution to this problem. Just put IgnorePkg in your pacman.conf. You are complaining on the wrong forum, to the wrong people about the behavior natural for a bleeding edge distro. On Monday, October 29, 2012 6:54:59 AM UTC-7, Brandon Allbery wrote: On Mon, Oct 29, 2012 at 5:56 AM, Magnus Therning mag...@therning.orgjavascript: wrote: Now I'm going to run the risk of upsetting you quite a bit by being completely blunt. Indeed. You come across in your mail like someone who has thought through your own situation, but fail to see the larger picture. You do know *your* May I ask you a question, then? Does the Haskell Platform have any reason to exist? Supposedly, the Haskell community backs the Haskell Platform as the way that most users should be using the Platform. Yet we have here a vendor platform which does not support it, and newcomers who notice this and question it are chastised for not thinking about the needs of other people. This suggests that the Haskell Platform is unimportant and perhaps disruptive to some significant group of people... is this so? And then, looking at your own message, I must ask: have you considered that the Platform is aimed at the great many people who do not have large amounts of expertise maintaining their own personal Haskell ecosystem. Or are your needs so important that these people must in fact be told to deal? Or, to phrase in your own words: You come across in your mail like someone who has thought through your own situation, but fail to see the larger picture. -- brandon s allbery kf8nh sine nomine associates allb...@gmail.com javascript: ball...@sinenomine.net javascript: unix/linux, openafs, kerberos, infrastructure http://sinenomine.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Segment Tree based Set
Are Martin Erwig's diets anything close? http://web.engr.oregonstate.edu/~erwig/diet/ On 29 October 2012 04:48, Tony Morris tonymor...@gmail.com wrote: Hi, I was wondering if anyone knows of a package implementing a fast lookup for an element in ranges. For example, this operation: Ord a = a - [(a, a)] - Bool ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Safe lens?
I've never understood this restriction. Template Haskell cannot
convert your code to something entirely different, only generate code
at splice points. It seems to me like Safe Haskell should already
have the necessary mechanisms for Safe Template Haskell to be
implemented.
The Safe Haskell docs say TemplateHaskell — Is particularly
dangerous, as it can cause side effects even at compilation time and
can be used to access constructors of abstract data types.
Also:
Module boundary control — Haskell code compiled using the safe
language is guaranteed to only access symbols that are publicly
available to it through other modules export lists. An important part
of this is that safe compiled code is not able to examine or create
data values using data constructors that it cannot import. If a module
M establishes some invariants through careful use of its export list
then code compiled using the safe language that imports M is
guaranteed to respect those invariants. Because of this, Template
Haskell and GeneralizedNewtypeDeriving are disabled in the safe
language as they can be used to violate this property.
This seems like something that could be readily fixed - just make
reify throw an error when attempting to inspect non-exported things
when compiling with -XSafe. We'd also need to check that the
generated code does not reference things from unsafe modules (as it
can reference things that aren't imported).
I'm not sure why it can cause side effects even at compile time. If
the module with the Template Haskell code is -XSafe or -XTrustworthy,
then presumably it does not cause side effects. One side effect that
could be troublesome is divergence / bottom. This seems OK to me, as
the user already has to deal with this in runtime code and the errors
aren't very cryptic.
-Michael
On Mon, Oct 29, 2012 at 10:14 AM, Petr P petr@gmail.com wrote:
Hi
I believe the reason is that it uses TemplateHaskell for automatic
derivation of labels. And TemplateHaskell is of course unsafe, since
it could convert your code into something entirely different.
Best regards,
Petr Pudlak
2012/10/29 Greg Fitzgerald gari...@gmail.com:
Why are getters from the 'lens' package unsafe? Is there a subset
like Data.Label.Pure from 'fclabels' that can be imported safely?
$ cat a.hs
{-# LANGUAGE Safe #-}
import Control.Lens.Getter
main = print 123
$ runghc a.hs
a.hs:3:1:
Control.Lens.Getter: Can't be safely imported!
The module itself isn't safe.
Thanks,
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
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] foldr (.) id
(.)/compose is consistent with (+)/sum, (*)/product, ()/and, etc. (to) compose is a verb. composition would be consistent with sum and product. and doesn't fit, though. Sebastian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Safe lens?
There's no dependency on TH here. I'm hoping to do the same thing as
I have done with fclabels, which is to have a Trustworthy module that
imports Control.Lens.TH, derive lenses, and then allow all users of
that data type to Safely import only the Getter/Setter modules. So,
I'm curious:
* Could Control.Lens.Getter have a LANGUAGE dependency it doesn't need?
* Is there something fundamental in the design of lens (compared to
fclabels), that its getters require unsafe language features?
* Maybe the Internal module should be marked Trustworthy?
Thanks,
Greg
On Mon, Oct 29, 2012 at 10:14 AM, Petr P petr@gmail.com wrote:
Hi
I believe the reason is that it uses TemplateHaskell for automatic
derivation of labels. And TemplateHaskell is of course unsafe, since
it could convert your code into something entirely different.
Best regards,
Petr Pudlak
2012/10/29 Greg Fitzgerald gari...@gmail.com:
Why are getters from the 'lens' package unsafe? Is there a subset
like Data.Label.Pure from 'fclabels' that can be imported safely?
$ cat a.hs
{-# LANGUAGE Safe #-}
import Control.Lens.Getter
main = print 123
$ runghc a.hs
a.hs:3:1:
Control.Lens.Getter: Can't be safely imported!
The module itself isn't safe.
Thanks,
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] foldr (.) id
sum can be a verb, but yeah, product can't really, so it probably makes sense to follow the noun pattern if we're wanting to be consistent more than brief. and as a noun is unusual, but fwiw dictionary.com says that there's a noun sense that means conjunction in the logical sense, which is exactly what we're doing here. On Mon, Oct 29, 2012 at 1:12 PM, Sebastian Fischer m...@sebfisch.de wrote: (.)/compose is consistent with (+)/sum, (*)/product, ()/and, etc. (to) compose is a verb. composition would be consistent with sum and product. and doesn't fit, though. Sebastian ___ 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] Optimal line length for haskell
O_o Those are damn strange reasons to restrict oneself to 80 chars, iMho. I tend to look at ONE file at a time, on one fullscreen widescreen. 100 chars per line is more or less normal; I have my vertical line limit marker set to 100, but only for layout-zen. My lines have sometimes 200 chars length, which causes the less important (long) code not to clutter my overview on the 50 neighbouring lines (~10 functions overview on the left half of the screen). Otherwise, I'd use a browser/Haddock on one part of the screen just to see an overview of the code I'm writing. I'm now wondering, whether this could have sth to do with my ADD, which I had the first 3 decades of my life (and without whiteboard). I think, I should try to code in a small narrow window of 1/4 of my screen, just to test whether that would (still) be a handicap. Roman: academic background... Funny; my impression about this matter was from the other point of view: Short lines are good for diff/patch files. Are there more people here with ADD (or ADD-history) and long-lines-disorder? Or is that just me? - marc Original-Nachricht Datum: Mon, 29 Oct 2012 11:32:29 -0400 Von: MightyByte mightyb...@gmail.com An: Jake McArthur jake.mcart...@gmail.com CC: Haskell Cafe haskell-cafe@haskell.org Betreff: Re: [Haskell-cafe] Optimal line length for haskell I also stick to a pretty rigid 78 characters. Doing so actually helps me fit more code onto my screen at a time because I usually have two or three columns of open files side by side. I find that I need this more often than I need to see a single function on a page (thanks to Haskell's traditionally small functions). But this works for single functions as well because I can open the same file in multiple columns at different locations in the file. The ideal line length for text layout is based on the physiology of the human eye… At normal reading distance the arc of the visual field is only a few inches – about the width of a well-designed column of text, or about 12 words per line. Research shows that reading slows and retention rates fall as line length begins to exceed the ideal width, because the reader then needs to use the muscles of the eye and neck to track from the end of one line to the beginning of the next line. If the eye must traverse great distances on the page, the reader is easily lost and must hunt for the beginning of the next line. Quantitative studies show that moderate line lengths significantly increase the legibility of text. Web Style Guide – Basic Design Principles for Creating Website Patrick J. Lynch and Sarah Horton 2nd edition, page 97. On Mon, Oct 29, 2012 at 10:37 AM, Jake McArthur jake.mcart...@gmail.com wrote: I stick to 80 columns fairly rigidly. This is not only so that it fits into narrow windows, but also so that any two subexpressions in the same expression tend to be close together on my screen, which makes it easier for me to reason about it. If only it was easy for me to read and write code on a Hilbert curve... :) I don't think long lines indicate a design problem; it's solely a formatting thing. On Mon, Oct 29, 2012 at 7:50 AM, Rustom Mody rustompm...@gmail.com wrote: There was a recent discussion on the python list regarding maximum line length. It occured to me that beautiful haskell programs tend to be plump (ie have long lines) compared to other languages whose programs are 'skinnier'. My thoughts on this are at http://blog.languager.org/2012/10/layout-imperative-in-functional.html. Are there more striking examples than the lexer from the standard prelude? [Or any other thoughts/opinions :-) ] Thanks, Rusi ___ 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 -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments (in deutsch: http://www.gerstbach.at/2004/ascii/) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hsql-mysql encoding issues
Hi, what DB binding should I rather be using? mongoDB [1] works well (also for data with umlauts) for my feed aggregator [2]. Best regards, Alex [1] http://hackage.haskell.org/package/mongoDB [2] http://hackage.haskell.org/package/lucienne signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimal line length for haskell
I frequently find myself wanting to look at one file while coding in another file so I can see type signatures, data type definitions, etc. If I only have one file fullscreen, then I would have to switch back and forth to refresh my mind with API information. If your max lines are sometimes 200 chars, then you're going to have tons of wasted screen space from all the other lines that aren't 200 characters wide. On Mon, Oct 29, 2012 at 4:44 PM, Marc Ziegert co...@gmx.de wrote: O_o Those are damn strange reasons to restrict oneself to 80 chars, iMho. I tend to look at ONE file at a time, on one fullscreen widescreen. 100 chars per line is more or less normal; I have my vertical line limit marker set to 100, but only for layout-zen. My lines have sometimes 200 chars length, which causes the less important (long) code not to clutter my overview on the 50 neighbouring lines (~10 functions overview on the left half of the screen). Otherwise, I'd use a browser/Haddock on one part of the screen just to see an overview of the code I'm writing. I'm now wondering, whether this could have sth to do with my ADD, which I had the first 3 decades of my life (and without whiteboard). I think, I should try to code in a small narrow window of 1/4 of my screen, just to test whether that would (still) be a handicap. Roman: academic background... Funny; my impression about this matter was from the other point of view: Short lines are good for diff/patch files. Are there more people here with ADD (or ADD-history) and long-lines-disorder? Or is that just me? - marc Original-Nachricht Datum: Mon, 29 Oct 2012 11:32:29 -0400 Von: MightyByte mightyb...@gmail.com An: Jake McArthur jake.mcart...@gmail.com CC: Haskell Cafe haskell-cafe@haskell.org Betreff: Re: [Haskell-cafe] Optimal line length for haskell I also stick to a pretty rigid 78 characters. Doing so actually helps me fit more code onto my screen at a time because I usually have two or three columns of open files side by side. I find that I need this more often than I need to see a single function on a page (thanks to Haskell's traditionally small functions). But this works for single functions as well because I can open the same file in multiple columns at different locations in the file. The ideal line length for text layout is based on the physiology of the human eye… At normal reading distance the arc of the visual field is only a few inches – about the width of a well-designed column of text, or about 12 words per line. Research shows that reading slows and retention rates fall as line length begins to exceed the ideal width, because the reader then needs to use the muscles of the eye and neck to track from the end of one line to the beginning of the next line. If the eye must traverse great distances on the page, the reader is easily lost and must hunt for the beginning of the next line. Quantitative studies show that moderate line lengths significantly increase the legibility of text. Web Style Guide – Basic Design Principles for Creating Website Patrick J. Lynch and Sarah Horton 2nd edition, page 97. On Mon, Oct 29, 2012 at 10:37 AM, Jake McArthur jake.mcart...@gmail.com wrote: I stick to 80 columns fairly rigidly. This is not only so that it fits into narrow windows, but also so that any two subexpressions in the same expression tend to be close together on my screen, which makes it easier for me to reason about it. If only it was easy for me to read and write code on a Hilbert curve... :) I don't think long lines indicate a design problem; it's solely a formatting thing. On Mon, Oct 29, 2012 at 7:50 AM, Rustom Mody rustompm...@gmail.com wrote: There was a recent discussion on the python list regarding maximum line length. It occured to me that beautiful haskell programs tend to be plump (ie have long lines) compared to other languages whose programs are 'skinnier'. My thoughts on this are at http://blog.languager.org/2012/10/layout-imperative-in-functional.html. Are there more striking examples than the lexer from the standard prelude? [Or any other thoughts/opinions :-) ] Thanks, Rusi ___ 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 -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments (in deutsch: http://www.gerstbach.at/2004/ascii/) ___ Haskell-Cafe mailing list
Re: [Haskell-cafe] Safe lens?
Actually Control.Lens.Getter doesn't use TH. The issue is more that it
depends on some modules I didn't flag as Trustworthy and which require some
more high-falutin type system extensions that GHC isn't happy about
treating as Safe. I'll try adding a few Trustworthy flags.
It previously was treated as Trustworthy or SafeInfered throughout.
Somewhere along the way I must have toggled on an extension and broken that
property.
-Edward
On Mon, Oct 29, 2012 at 1:14 PM, Petr P petr@gmail.com wrote:
Hi
I believe the reason is that it uses TemplateHaskell for automatic
derivation of labels. And TemplateHaskell is of course unsafe, since
it could convert your code into something entirely different.
Best regards,
Petr Pudlak
2012/10/29 Greg Fitzgerald gari...@gmail.com:
Why are getters from the 'lens' package unsafe? Is there a subset
like Data.Label.Pure from 'fclabels' that can be imported safely?
$ cat a.hs
{-# LANGUAGE Safe #-}
import Control.Lens.Getter
main = print 123
$ runghc a.hs
a.hs:3:1:
Control.Lens.Getter: Can't be safely imported!
The module itself isn't safe.
Thanks,
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
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Safe lens?
It happened somewhere between 2.6 and 2.7:
http://hackage.haskell.org/packages/archive/lens/2.6.1/doc/html/Control-Lens-Internal.html
http://hackage.haskell.org/packages/archive/lens/2.7.0.1/doc/html/Control-Lens-Internal.html
The strange thing is that the only internal dependency of 2.7.0.1,
Control.Lens.Isomorphic, is still Safe-Infered (this spelling error
should probably be fixed)
http://hackage.haskell.org/packages/archive/lens/2.7.0.1/doc/html/Control-Lens-Isomorphic.html
It'd be pretty fancy if Safe Haskell could give reasons for None /
tell what would have made it unsafe in the event of Trustworthy.
Particularly fancy if integrated into the haddocks.
-mgsloan
On Mon, Oct 29, 2012 at 2:33 PM, Edward Kmett ekm...@gmail.com wrote:
Actually Control.Lens.Getter doesn't use TH. The issue is more that it
depends on some modules I didn't flag as Trustworthy and which require some
more high-falutin type system extensions that GHC isn't happy about treating
as Safe. I'll try adding a few Trustworthy flags.
It previously was treated as Trustworthy or SafeInfered throughout.
Somewhere along the way I must have toggled on an extension and broken that
property.
-Edward
On Mon, Oct 29, 2012 at 1:14 PM, Petr P petr@gmail.com wrote:
Hi
I believe the reason is that it uses TemplateHaskell for automatic
derivation of labels. And TemplateHaskell is of course unsafe, since
it could convert your code into something entirely different.
Best regards,
Petr Pudlak
2012/10/29 Greg Fitzgerald gari...@gmail.com:
Why are getters from the 'lens' package unsafe? Is there a subset
like Data.Label.Pure from 'fclabels' that can be imported safely?
$ cat a.hs
{-# LANGUAGE Safe #-}
import Control.Lens.Getter
main = print 123
$ runghc a.hs
a.hs:3:1:
Control.Lens.Getter: Can't be safely imported!
The module itself isn't safe.
Thanks,
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
___
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] Safe lens?
I fixed it. Version 3.0.6 was just uploaded to hackage and is appropriately
Trustworthy where needed.
Please let me know if I missed flagged anything you need flagged, or
mis-flagged anything you think shouldn't be. ;)
On Mon, Oct 29, 2012 at 5:42 PM, Michael Sloan mgsl...@gmail.com wrote:
It happened somewhere between 2.6 and 2.7:
http://hackage.haskell.org/packages/archive/lens/2.6.1/doc/html/Control-Lens-Internal.html
http://hackage.haskell.org/packages/archive/lens/2.7.0.1/doc/html/Control-Lens-Internal.html
The strange thing is that the only internal dependency of 2.7.0.1,
Control.Lens.Isomorphic, is still Safe-Infered (this spelling error
should probably be fixed)
http://hackage.haskell.org/packages/archive/lens/2.7.0.1/doc/html/Control-Lens-Isomorphic.html
It'd be pretty fancy if Safe Haskell could give reasons for None /
tell what would have made it unsafe in the event of Trustworthy.
Particularly fancy if integrated into the haddocks.
-mgsloan
On Mon, Oct 29, 2012 at 2:33 PM, Edward Kmett ekm...@gmail.com wrote:
Actually Control.Lens.Getter doesn't use TH. The issue is more that it
depends on some modules I didn't flag as Trustworthy and which require
some
more high-falutin type system extensions that GHC isn't happy about
treating
as Safe. I'll try adding a few Trustworthy flags.
It previously was treated as Trustworthy or SafeInfered throughout.
Somewhere along the way I must have toggled on an extension and broken
that
property.
-Edward
On Mon, Oct 29, 2012 at 1:14 PM, Petr P petr@gmail.com wrote:
Hi
I believe the reason is that it uses TemplateHaskell for automatic
derivation of labels. And TemplateHaskell is of course unsafe, since
it could convert your code into something entirely different.
Best regards,
Petr Pudlak
2012/10/29 Greg Fitzgerald gari...@gmail.com:
Why are getters from the 'lens' package unsafe? Is there a subset
like Data.Label.Pure from 'fclabels' that can be imported safely?
$ cat a.hs
{-# LANGUAGE Safe #-}
import Control.Lens.Getter
main = print 123
$ runghc a.hs
a.hs:3:1:
Control.Lens.Getter: Can't be safely imported!
The module itself isn't safe.
Thanks,
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
___
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] Safe lens?
I guess that's a good way to safeguard against future accidental
toggleage. Still, it's puzzling that the status of Safe-Infered was
lost.
On Mon, Oct 29, 2012 at 2:46 PM, Edward Kmett ekm...@gmail.com wrote:
I fixed it. Version 3.0.6 was just uploaded to hackage and is appropriately
Trustworthy where needed.
Please let me know if I missed flagged anything you need flagged, or
mis-flagged anything you think shouldn't be. ;)
On Mon, Oct 29, 2012 at 5:42 PM, Michael Sloan mgsl...@gmail.com wrote:
It happened somewhere between 2.6 and 2.7:
http://hackage.haskell.org/packages/archive/lens/2.6.1/doc/html/Control-Lens-Internal.html
http://hackage.haskell.org/packages/archive/lens/2.7.0.1/doc/html/Control-Lens-Internal.html
The strange thing is that the only internal dependency of 2.7.0.1,
Control.Lens.Isomorphic, is still Safe-Infered (this spelling error
should probably be fixed)
http://hackage.haskell.org/packages/archive/lens/2.7.0.1/doc/html/Control-Lens-Isomorphic.html
It'd be pretty fancy if Safe Haskell could give reasons for None /
tell what would have made it unsafe in the event of Trustworthy.
Particularly fancy if integrated into the haddocks.
-mgsloan
On Mon, Oct 29, 2012 at 2:33 PM, Edward Kmett ekm...@gmail.com wrote:
Actually Control.Lens.Getter doesn't use TH. The issue is more that it
depends on some modules I didn't flag as Trustworthy and which require
some
more high-falutin type system extensions that GHC isn't happy about
treating
as Safe. I'll try adding a few Trustworthy flags.
It previously was treated as Trustworthy or SafeInfered throughout.
Somewhere along the way I must have toggled on an extension and broken
that
property.
-Edward
On Mon, Oct 29, 2012 at 1:14 PM, Petr P petr@gmail.com wrote:
Hi
I believe the reason is that it uses TemplateHaskell for automatic
derivation of labels. And TemplateHaskell is of course unsafe, since
it could convert your code into something entirely different.
Best regards,
Petr Pudlak
2012/10/29 Greg Fitzgerald gari...@gmail.com:
Why are getters from the 'lens' package unsafe? Is there a subset
like Data.Label.Pure from 'fclabels' that can be imported safely?
$ cat a.hs
{-# LANGUAGE Safe #-}
import Control.Lens.Getter
main = print 123
$ runghc a.hs
a.hs:3:1:
Control.Lens.Getter: Can't be safely imported!
The module itself isn't safe.
Thanks,
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
___
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] Safe lens?
We picked up some extensions along the way in the dependency, so that went
to None, then the things that depended on it devolved from SafeInferred to
None as well.
-Edward
On Mon, Oct 29, 2012 at 5:54 PM, Michael Sloan mgsl...@gmail.com wrote:
I guess that's a good way to safeguard against future accidental
toggleage. Still, it's puzzling that the status of Safe-Infered was
lost.
On Mon, Oct 29, 2012 at 2:46 PM, Edward Kmett ekm...@gmail.com wrote:
I fixed it. Version 3.0.6 was just uploaded to hackage and is
appropriately
Trustworthy where needed.
Please let me know if I missed flagged anything you need flagged, or
mis-flagged anything you think shouldn't be. ;)
On Mon, Oct 29, 2012 at 5:42 PM, Michael Sloan mgsl...@gmail.com
wrote:
It happened somewhere between 2.6 and 2.7:
http://hackage.haskell.org/packages/archive/lens/2.6.1/doc/html/Control-Lens-Internal.html
http://hackage.haskell.org/packages/archive/lens/2.7.0.1/doc/html/Control-Lens-Internal.html
The strange thing is that the only internal dependency of 2.7.0.1,
Control.Lens.Isomorphic, is still Safe-Infered (this spelling error
should probably be fixed)
http://hackage.haskell.org/packages/archive/lens/2.7.0.1/doc/html/Control-Lens-Isomorphic.html
It'd be pretty fancy if Safe Haskell could give reasons for None /
tell what would have made it unsafe in the event of Trustworthy.
Particularly fancy if integrated into the haddocks.
-mgsloan
On Mon, Oct 29, 2012 at 2:33 PM, Edward Kmett ekm...@gmail.com wrote:
Actually Control.Lens.Getter doesn't use TH. The issue is more that it
depends on some modules I didn't flag as Trustworthy and which require
some
more high-falutin type system extensions that GHC isn't happy about
treating
as Safe. I'll try adding a few Trustworthy flags.
It previously was treated as Trustworthy or SafeInfered throughout.
Somewhere along the way I must have toggled on an extension and broken
that
property.
-Edward
On Mon, Oct 29, 2012 at 1:14 PM, Petr P petr@gmail.com wrote:
Hi
I believe the reason is that it uses TemplateHaskell for automatic
derivation of labels. And TemplateHaskell is of course unsafe, since
it could convert your code into something entirely different.
Best regards,
Petr Pudlak
2012/10/29 Greg Fitzgerald gari...@gmail.com:
Why are getters from the 'lens' package unsafe? Is there a subset
like Data.Label.Pure from 'fclabels' that can be imported safely?
$ cat a.hs
{-# LANGUAGE Safe #-}
import Control.Lens.Getter
main = print 123
$ runghc a.hs
a.hs:3:1:
Control.Lens.Getter: Can't be safely imported!
The module itself isn't safe.
Thanks,
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
___
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] ICFP 2013: Call for workshops and co-located events
CALL FOR WORKSHOP AND CO-LOCATED EVENT PROPOSALS ICFP 2013 18th ACM SIGPLAN International Conference on Functional Programming September 22 - 28, 2013 Boston, Massachusetts, USA http://icfpconference.org/icfp2013/ The 18th ACM SIGPLAN International Conference on Functional Programming will be held in Boston, Massachusetts on September 22-28, 2013. ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. Proposals are invited for workshops (and other co-located events, such as tutorials) to be affiliated with ICFP 2013 and sponsored by SIGPLAN. These events should be more informal and focused than ICFP itself, include sessions that enable interaction among the attendees, and foster the exchange of new ideas. The preference is for one-day events, but other schedules can also be considered. The workshops are scheduled to occur on September 22-24 (the three days before ICFP) and September 28 (the day after ICFP). -- Submission details Deadline for submission: December 7, 2012 Notification of acceptance: January 7, 2013 Prospective organizers of workshops or other co-located events are invited to submit a completed workshop proposal form in plain text format to the ICFP 2013 workshop co-chairs (Patrik Jansson and Sam Tobin-Hochstadt), via email to icfp13-worksh...@ccs.neu.edu by December 7, 2012. (For proposals of co-located events other than workshops, please fill in the workshop proposal form and just leave blank any sections that do not apply.) Please note that this is a firm deadline. Organizers will be notified if their event proposal is accepted by January 7, 2013, and if successful, depending on the event, they will be asked to produce a final report after the event has taken place that is suitable for publication in SIGPLAN Notices. The proposal form is available at: http://www.icfpconference.org/icfp2013/icfp13-workshops-form.txt Further information about SIGPLAN sponsorship is available at: http://acm.org/sigplan/sigplan_workshop_proposal.htm -- Selection committee The proposals will be evaluated by a committee comprising the following members of the ICFP 2013 organizing committee, together with the members of the SIGPLAN executive committee. Workshop Co-Chair: Patrik Jansson (Chalmers University of Technology) Workshop Co-Chair: Sam Tobin-Hochstadt (Northeastern University) General Chair :Greg Morrisset (Harvard University) Program Chair: Tarmo Uustalu(Tallinn University of Technology) -- Further information Any queries should be addressed to the workshop co-chairs (Patrik Jansson and Sam Tobin-Hochstadt), via email to icfp13-worksh...@ccs.neu.edu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Empirically comparing strict vs. lazy evaluation
Hello Haskellers! I wonder if you know of benchmarks that attempt to compare, empirically, lazy vs. eager evaluation. Pointers to papers and/or code would be most appreciated. Our group (at UMD) is working on a paper that develops some technology for lazy programs, and we would like to choose benchmarks for evaluating it that span the gamut of computations that perform well when done lazily, vs. those that do not perform as well when evaluated lazily. Then we want to look at the best case and worst case for our technology WRT laziness, and see how it stacks up. Thanks in advance for any ideas you have! Kris Micinski ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimal line length for haskell
On 30/10/2012, at 3:28 AM, Alexander Solla wrote: On Mon, Oct 29, 2012 at 6:52 AM, Michael Orlitzky mich...@orlitzky.com wrote: In any language, a line longer than 80 characters usually (but not always) suggests that you might want to stop and rethink your design. In many cases a refactoring or two will greatly simplify the code and reduce your line length as a result. I disagree. That might be true for imperative languages, where width is indicative of deep nesting and its associated problems. But it is not true for a functional language, where it is merely indicative of a wide normal form. Yes, the normal form can sometimes be refactored, but to what end? Better code? I have no idea of what a wide normal form might be, and less idea of why that would imply that a narrower and better form does not also exist. We can argue till everyone is sick and tired and still not reach any kind of consensus. Let's have some *examples*. (For the record, the longest line lengths I've ever seen have been in C++ and Java. I know someone who, and I am not kidding, thinks a 390- column line in code intended to be read by other people is OK.) My own perspective is that if I can't fit it onto one slide in large type for my students to see it is too big. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC maintenance on Arch
2012/10/29 timothyho...@seznam.cz: To be clear, the project ArchHaskell has little or no relation to my original post. If I understand correctly, ArchHaskell is a set of Arch uses who attempted to repackage the packages in hackage in the AUR. Not exactly. ArchHaskell try to keep an ArchLinux repository of Haskell package without the dependency mess that pop out from using cabal install. addresses issues of package management that are unrelated to my complaint. My complaint is that Arch currently does not support having two versions of GHC installed and GHC does not support backwards compatibility. The current method of always updating GHC to the latest version, discarding the old version is useful to the most hard core bleeding edge types. An alternative model for those of us that need a consistently usable system is not well supported. Currently updating ghc the normal way always breaks your build system. Arch has addressed this issue with a number of other packages. Perhaps the best comparison would be ghchttps://www.archlinux.org/packages/extra/x86_64/ghc/ verse linuxhttps://www.archlinux.org/packages/core/i686/linux/. With linux, we have a linux package and a linux-ltshttps://www.archlinux.org/packages/core/x86_64/linux-lts/ package. These are the same, but linux-lts gets updated slightly less often and with less expedition. This problem has been had in Arch, it's been solved, and we should take the example of these other cases I have provided and make two ghc packages, so that there is a standard supported sane way to use ghc on arch linux. This isn't a problem that affects me personally these days. As an advanced user I don't really have any trouble working around the issue. But I'd like Arch to be inviting to newbies and to have what most of us more experienced users implement manually by default. I think ArchLinux is about bleeding edge types. It is normal for Arch to have the latest stable version available in repository. And ghc is not the kernel. For example Arch has ruby-1.9, while many other distros still use 1.8. But if you do need ghc-7.4 and you don't want to deal with upgrades of every Haskell library you use, you can always install haskell-platform and use cabal for the needed libraries. But when you'll want to update to the next haskell-platform version (or whatever you define as stable), you'll have to remove and reinstall everything. Having Arch packages makes this process smoother. Fabio ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Segment Tree based Set
Yeah that looks useful indeed. I am surprised there isn't a DIET on hackage. On Tue, Oct 30, 2012 at 3:55 AM, Stephen Tetley stephen.tet...@gmail.comwrote: Are Martin Erwig's diets anything close? http://web.engr.oregonstate.edu/~erwig/diet/ On 29 October 2012 04:48, Tony Morris tonymor...@gmail.com wrote: Hi, I was wondering if anyone knows of a package implementing a fast lookup for an element in ranges. For example, this operation: Ord a = a - [(a, a)] - Bool ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Safe lens?
Works great. Thanks for the quick work!
-Greg
On Mon, Oct 29, 2012 at 2:46 PM, Edward Kmett ekm...@gmail.com wrote:
I fixed it. Version 3.0.6 was just uploaded to hackage and is appropriately
Trustworthy where needed.
Please let me know if I missed flagged anything you need flagged, or
mis-flagged anything you think shouldn't be. ;)
On Mon, Oct 29, 2012 at 5:42 PM, Michael Sloan mgsl...@gmail.com wrote:
It happened somewhere between 2.6 and 2.7:
http://hackage.haskell.org/packages/archive/lens/2.6.1/doc/html/Control-Lens-Internal.html
http://hackage.haskell.org/packages/archive/lens/2.7.0.1/doc/html/Control-Lens-Internal.html
The strange thing is that the only internal dependency of 2.7.0.1,
Control.Lens.Isomorphic, is still Safe-Infered (this spelling error
should probably be fixed)
http://hackage.haskell.org/packages/archive/lens/2.7.0.1/doc/html/Control-Lens-Isomorphic.html
It'd be pretty fancy if Safe Haskell could give reasons for None /
tell what would have made it unsafe in the event of Trustworthy.
Particularly fancy if integrated into the haddocks.
-mgsloan
On Mon, Oct 29, 2012 at 2:33 PM, Edward Kmett ekm...@gmail.com wrote:
Actually Control.Lens.Getter doesn't use TH. The issue is more that it
depends on some modules I didn't flag as Trustworthy and which require
some
more high-falutin type system extensions that GHC isn't happy about
treating
as Safe. I'll try adding a few Trustworthy flags.
It previously was treated as Trustworthy or SafeInfered throughout.
Somewhere along the way I must have toggled on an extension and broken
that
property.
-Edward
On Mon, Oct 29, 2012 at 1:14 PM, Petr P petr@gmail.com wrote:
Hi
I believe the reason is that it uses TemplateHaskell for automatic
derivation of labels. And TemplateHaskell is of course unsafe, since
it could convert your code into something entirely different.
Best regards,
Petr Pudlak
2012/10/29 Greg Fitzgerald gari...@gmail.com:
Why are getters from the 'lens' package unsafe? Is there a subset
like Data.Label.Pure from 'fclabels' that can be imported safely?
$ cat a.hs
{-# LANGUAGE Safe #-}
import Control.Lens.Getter
main = print 123
$ runghc a.hs
a.hs:3:1:
Control.Lens.Getter: Can't be safely imported!
The module itself isn't safe.
Thanks,
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
___
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
Re: [Haskell-cafe] Teaching Haskell @ MOOCs like Coursera or Udacity
Hi Kris, You have highlighted a very important point by talking about real life projects and the way they differ from core haskell. When I got inspired by Martin Odersky's Coursera Scala course and wished the same for Haskell, I meant the following: 1. Great and in depth set of exercises and feedback/evaluation platform. 2. Real life haskell extensions and relevant exercises. 3. Structured and organized course. The current list of things on wiki is wonderful but are they helping newcomers? Frankly speaking, it didn't help me. How can we stop putting newcomers like me on crossroads of haskell learning? Thanks, Niket On Fri, Oct 26, 2012 at 2:46 AM, Kristopher Micinski krismicin...@gmail.com wrote: On Thu, Oct 25, 2012 at 4:57 PM, Gregg Lebovitz gr...@fpcomplete.com wrote: I am trying to get a learning center started in the Haskell community. As pointed out below, MOOCs are hard to put together, however training and videos straight forward. There is a lot of teaching material available in the community. It is a matter of finding, organizing and curating it. At the same time the Haskell wiki and Oleg's site taken together constitute a good amount of learning material in a semi organized fashion. These aren't replacements or implementations of your idea but they come pretty close (to the point that I could spend quite a while on the combinations of those and still feel unfinished..). I think the Haskell wikibook also does a good amount to address further concepts in Haskell. There have been tons of great FP books written over the years, many of which aren't even frequently mentioned by people, but at the same time nothing helps like actually using it in your own personal projects, I haven't seen so much elaboration on *this* point. (For example, doing this would probably mean talking about a set of parser combinators, some script-y haskell libraries, a web framework, etc...) Interesting quote: After all, if we didn’t need teachers, then we could earn our undergraduate degrees by spending four years in the library. Is this not what most people do? I know that was certainly my experience :-). One problem with Haskell: the language moves fast. Core Haskell isn't all that hard, but if you open any real Haskell project, it's going to use advanced (sometimes unstable) extensions that aren't going to be in your book or web guide, making some people feel stuck. These concepts aren't necessarily difficult, but if you actually want to use Haskell you need to face the more popular language extensions. Off the top of my head, existential types, arrows, higher kinds, all stick out to me as being things you see in most code, along with (of course) monad transformer stacks that will scare off newcomers and aren't explained in any cohesive context other than the Haskell wiki... kris ___ 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] Optimal line length for haskell
On Mon, Oct 29, 2012 at 4:09 PM, Richard O'Keefe o...@cs.otago.ac.nz wrote: On 30/10/2012, at 3:28 AM, Alexander Solla wrote: On Mon, Oct 29, 2012 at 6:52 AM, Michael Orlitzky mich...@orlitzky.com wrote: In any language, a line longer than 80 characters usually (but not always) suggests that you might want to stop and rethink your design. In many cases a refactoring or two will greatly simplify the code and reduce your line length as a result. I disagree. That might be true for imperative languages, where width is indicative of deep nesting and its associated problems. But it is not true for a functional language, where it is merely indicative of a wide normal form. Yes, the normal form can sometimes be refactored, but to what end? Better code? I have no idea of what a wide normal form might be, and less idea of why that would imply that a narrower and better form does not also exist. I made no implication that narrower forms are not useful, or even better, given that the structure is not incompatible with the syntax used to implement it. (For example, I would much rather [1,2,3,4,5] over [1 ,2 ,3 ,4 ,5 ] but would likely prefer [ alpha , beta .. , omega ] over the alternative. For example, I generally prefer using the combinators directly when dealing with functors, applicatives, and monads. This can be written wide, but it can also be written in the style of: f' = f $ (a = g) * (b = h) * (c = i = k) That is perfectly sensible. But if I had to repeat this syntactic construct, I would probably do it wide: f' = f $ (a = g) * (b = h) * (c = i = k) g' = g $ (d = g) * (e = h) * (f = i = k) The new row exposes a sort of tabular structure. This code is easy to edit, all at once, highlights differences, and exposes similarities that might be hidden if written in stanza format and have enough rows in that format. Of course, a normal form merely a combinator, or rather, its definiens. So one might ask, why not factor this out into a combinator? That might well be appropriate, or it might not. Either way, your program end up with a table for values which may vary (since, presumably, the definitions of f' and g' witness that you want to define f' and g'.), as in: f' = comb f a b c g' = comb g d e f This cannot be made any narrower (up to naming). We can call a normal form n-wide if its combinator requires n arguments. How many combinators do we really want? A combinator is what it will take to factor the wideness out of a tabular form, and all you get is a maybe narrower tabular form. My own perspective is that if I can't fit it onto one slide in large type for my students to see it is too big. This is fair enough, but there are some types of extremely uninteresting code that don't go on slides and are naturally expressed as extremely wide tables. Typically, it is data for use by the program -- the stuff the program traverses to output its answer. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
