Re: [Haskell-cafe] writing graphs with do-notation
Neat Surely there is somewhere in the haskell Twiki that something like this should live? Neil On 12 Dec 2009, at 21:00, Soenke Hahn wrote: Hi! Some time ago, i needed to write down graphs in Haskell. I wanted to be able to write them down without to much noise, to make them easily maintainable. I came up with a way to define graphs using monads and the do notation. I thought this might be interesting to someone, so i wrote a small script to illustrate the idea. Here's an example: example :: Graph String example = buildGraph $ do a - mkNode A [] b - mkNode B [a] mkNode C [a, b] In this graph there are three nodes identified by [A, B, C] and three edges ([(A, B), (A, C), (B, C)]). Think of the variables a and b as outputs of the nodes A and B. Note that each node identifier needs to be mentioned only once. Also the definition of edges (references to other nodes via the outputs) can be checked at compile time. The attachment is a little script that defines a Graph-type (nothing elaborate), the buildGraph function and an example graph that is a little more complex than the above. The main function of the script prints the example graph to stdout to be read by dot (or similar). By the way, it is possible to define cyclic graphs using mdo (RecursiveDo). I haven't come across something similar, so i thought, i'd share it. What do you think? Sönke Graph-Monads.hs___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [darcs-users] Iteratees, streams, and mmap
Jason Dagit wrote: Johann Höchtl wrote: As a beginner to Haskell, I am only 1/3 through RWH, those lines scare me in a sense to question my effort. I simply can not distinguish if this discussion is somewhat pathological in a sense that every access to the outside world imposes dangers and an additional exception handler here and there and an additional if-statement to handle error return codes will suffice. We're not talking about exception handling :) And yes, Heinrich is talking about pathological cases. Or lazy evaluation, IO monads and the whole story behind unsafePerformIO was an additional layer of self-deception and unpredictable effects from the outside world and lazy evaluation can NEVER be satisfactory handled. We're not talking about unsafePerformIO either. The discussion at hand is much simpler. Given a large stream of data, how should you style your code so that it's easy to reason about the space usage? This is an important question in every programming language I've ever used. Also, IO need not enter the discussion except that in darcs the streams of data come from the disk. I think moving the discussion to haskell-cafe was a mistake. I said what I said in a very specific context (that of the darcs developers mailing list), which is likely no longer clear. Sorry for any distress this has caused you. Ah, I didn't mean to cause distress to anyone by cross-posting to the café. I just thought that a discussion Is there a style of writing Haskell that makes it easy to ensure bounded space usage? could be of general interest. Johann, don't worry, lazy evaluation is awesome. :) See for example http://apfelmus.nfshost.com/quicksearch.html It's just that laziness not a free lunch; predicting memory (space) usage does become more difficult. Which is not really surprising since deferring the evaluation of thunks until they are demanded also means that they will store different expressions of possibly different sizes before and after they are demanded. Classic examples are ones = 1:ones taking O(1) memory instead of an infinite amount and foldl (+) 0 [1..n] taking O(n) memory as opposed to foldl' (+) 0 [1..n] which only takes O(1) memory. Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What about adding a wiki for each haskell project?
wren ng thornton w...@freegeek.org writes: Using a wiki page for each project enables anybody to add comments.[...] I think this is a great idea. Because of Duncan's concerns about imposing too much burden on authors, and because there are many mature projects which already have wikis etc, I have a counter-proposal. I don't this this is the same thing. Marc's proposal would provide a scratch pad for random users to discuss or comment on various stuff on Hackage. At least the way I see it, it is primarily *not* for use by the author, and in fact most useful when the author is not around to actively support his project. E.g. my package that was used as an example, while (arguably) useful, is way to small for me to bother with setting up a full site with web pages or bug trackers, etc. Other packages are orphaned or see little interest from their author. We already have community.haskell.org for authors to host their webpages and Darcs repos. [..] Rather than giving Hackage wikis, perhaps it would be better to point more people towards community.haskell.org and maybe increase the options offered there (in case people dislike Trac). This is great, but I view this as a different issue. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [darcs-users] Iteratees, streams, and mmap
Jason Dagit wrote: withPending :: (a - Patch - a) - IO a And withPending would start the streaming and make sure that the stream cannot be visible as a data dependency outside of withPending. [...] Heinrich Apfelmus wrote: In other words, exporting only a foldl' -like interface does not really prevent us from writing functions that have O(n) instead of O(1) space usage. But trying to rectify that with the forall s trick is a doomed idea, too. I realize it's not perfect, but the problem we have now is that it's too easy to write things that have dismal space usage. If we can't force proper space usage, how can we make it more natural to have bounded space? Or at least a good approximation. It seems that: * foldl'-style helps * rank-n can help * no approach I've seen *forces* the behavior we want * existing code and bug reports demonstrate we need to improve the situation Yep, I agree completely; except for the rank-n (rank-2) trick where I'm more pessimistic. I think rank-2 works fine for things like ensuring that file handles are closed properly. But for the purpose of ensuring O(1) space usage, I think that withPending . flip $ const (() :) demonstrates that rank-2 is not worth the complexity they bring. Still, the idea of tracking resource usage in the type system is attractive. I'm open to suggestions on how to ensure the code has the space behavior I want. I've got another, unfinished idea: Namely, withPending does not guarantee that the stream does not leak, it only makes it more natural/convenient to formulate one's code so that it doesn't leak. In particular, using (:) as argument pretty much defeats the whole purpose: Right. And the iteratee library points out that your iteratees have to be well-behaved (I think there they say bounded). I'm well aware of this issue and thanks for pointing it out for others who are reading along. How about tracking the requirement of bounded in the type system? In particular, I'm thinking of a type class class NFData a = Small a where the idea is that all types that can be stored in constant space are members of this class. For example, we have instance Small () instance Small Int instance Small Char instance (Small a, Small b) = Small (a,b) instance (Small a, Small b) = Small (Either a b) but recursive types like [a] or String are not allowed to be members. Then, withPending :: Small a = (a - Patch - a) - IO a which is based on the function foldlSmall :: Small b = (b - a - b) - b - [a] - b foldlSmall f b [] = foldlSmall f b (x:xs) = foldlSmall f b' xs where b' = rnf (f b x) is pretty much guaranteed to run in O(1) space. Well, that depends on f , but the point is it's not foldlSmall who introduces the space leak, it's the argument that takes all the blame. In other words, the human effort to make the code behave how we want is currently too high and that's the issue I want to address. I don't know how we could make it impossible to have space leaks, although that would be interesting. I opine that aiming for the latter (making space leaks impossible) while experimenting brings you closer to the actual goal (making them easy to avoid) when it comes to putting these experiments into practice. But that's just me. Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Are there standard idioms for lazy, pure error handling?
Duncan Coutts wrote:
Another approach that some people have advocated as a general purpose
solution is to use:
data Exceptional e a = Exceptional {
exception :: Maybe e
result:: a
}
However it's pretty clear from the structure of this type that it cannot
cope with lazy error handling in sequences. If you try it you'll find
you cannot do it without space leaks.
It's not all that clear. Consider this toy example (from a private
discussion with Henning Thielemann a while ago), which runs in
constant space:
import System.IO.Unsafe
import System.Environment
import Control.Monad
import Data.List
data Exceptional e a =
Exceptional { exception :: Maybe e, result :: a }
ok a = Exceptional Nothing a
fault e a = Exceptional (Just e) a
faulty :: Int - IO (Exceptional Int [Int])
faulty 0 = return (fault 0 [])
faulty 1 = return (ok [])
faulty n = unsafeInterleaveIO $ do
-- getChar
r - faulty (n-2)
return $ Exceptional (exception r) (n : result r)
main = do
n - readIO . head = getArgs
Exceptional exc res - faulty n
print $ last res
when (n `mod` 3 == 0) $ print exc
This works because ghc's garbage collector evaluates record selectors.
(There are a simpler cases where this matters, for example
last $ fst $ unzip [(a,a) | a - [1..1]]
which also runs in constant space.)
The approach is very fragile, though. For example, if we change main to
main = do
n - readIO . head = getArgs
f - faulty n
print $ last (result f)
when (n `mod` 3 == 0) $ print (exception f)
then the space leak reoccurs - doing the pattern match on the
Excpeptional constructor before using the result is essential.
Bad things also happen if ghc's optimiser turns the record selectors
into explicit pattern matches in the worker ('faulty' in the example).
Kind regards,
Bertram
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC 6.12 status and features
WIth 6.10.4 there's a major bug with Snow leopard: It doesn't work (Cannot compile 64-bit). Is this fixed in the new release? Adam On 12 Dec 2009, at 17:32, Tom Tobin wrote: On Sat, Dec 12, 2009 at 8:22 AM, Max Bolingbroke batterseapo...@hotmail.com wrote: 2009/12/12 Rafael Gustavo da Cunha Pereira Pinto rafaelgcpp.li...@gmail.com : I know I should probably be asking to the GHC list, but is there any update on 6.12 since October? Any probable release date? It looks like haskell.org just acquired this page, though it's not yet linked to from anywhere else: http://haskell.org/ghc/download_ghc_6_12_1.html Aw, no OS X package yet ... :-) ___ 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] What about adding a wiki for each haskell project?
Hello everyone, Could a new mailing list for patches and/or commentary do the work of the proposed package Wikis? Similar to the libraries list but separate so it doesn't pollute the libraries list from its important job of discussing and refining the core libs. From my perspective, mails have two useful and apparent properties - messages are authored and time stamped, and viewing the list through Gmane or whatever would allow people to keep up to date without burdening their inboxes. With a Wiki the authorship and time stamp are deep within the history - on a Wiki, one would expect people to be respectful, but you never know. Also my personal feeling is that Wiki comments would go the way of (elaborate) source code comments - vis the old chestnut Are out of date comments, better than no comments? Best wishes Stephen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What about adding a wiki for each haskell project?
Ketil Malde wrote: wren ng thornton w...@freegeek.org writes: Using a wiki page for each project enables anybody to add comments.[...] I think this is a great idea. Because of Duncan's concerns about imposing too much burden on authors, and because there are many mature projects which already have wikis etc, I have a counter-proposal. I don't this this is the same thing. Marc's proposal would provide a scratch pad for random users to discuss or comment on various stuff on Hackage. At least the way I see it, it is primarily *not* for use by the author, and in fact most useful when the author is not around to actively support his project. But if it's a wiki, wouldn't people be able to add changes themselves? Isn't that the idea behind wikis? Sure, the authors could lock down their wikis, but I don't get the feeling that many would. My interpretation of Duncan's concern ---not meaning to put words in his mouth--- is that adding a Hackage wiki could place undue burden on the authors. If authors already have a wiki, then a Hackage wiki is just an extra place to check for feedback which will be prone to duplication and being out-of-date. I understand that y'all think giving users a place for feedback is different than giving authors the tools to communicate with their users, but I don't think they're all that different. Why not push for authors to have a section of their wikis devoted to users' notes? That would have the same effect of allowing users to speak out without fracturing each project's community. Institutionalizing a place for users to make comments separate from the authors' resources can't be a good thing. It sets up a community divide between users and authors. It can confuse new users who can't figure out which to go to for official answers. It can cause users to just post their fixes rather than trying to contact the maintainers. Etc. I can't think of any way this separation could lead to good for any project's community. E.g. my package that was used as an example, while (arguably) useful, is way to small for me to bother with setting up a full site with web pages or bug trackers, etc. So someone else should set them up for you? I don't get it. Either you want ways to communicate with your users or you don't. If it's just a matter of not wanting to do the work *yourself*, then I'm back to my previous post. The community server (or similar hosts) should make it trivial to set things up. I think it only takes one command to set up Trac on community.haskell.org. The only thing I can think might need changing is if the community server only allows per-project Trac instances instead of also having per-user instances so someone can have a single one for all their little projects. If they don't offer per-user instances (I haven't checked) then I'm all for adding them. Other packages are orphaned or see little interest from their author. That's a separate issue isn't it? Why not have an adopt-a-package program where the community determines which packages are orphaned and sets up and maintains wikis and other resources for them until a new maintainer can be found? We have a long history of community-based maintenance for the main libraries that (used to) ship with GHC. It may not be the best model, but it should suffice for keeping the cobwebs off. I don't have anything against wikis, nor against Hackage having links to wikis. But I don't think Hackage is the right place for hosting the wikis themselves. This has the distinct feel of trying to legislate community into existence. But community isn't something you can legislate. Adding things to try to force community building just leads to bloated web-interfaces and trivializes the communities that do exist. There are a number of project hosts that have gone down this route, and it leads to ghettoization and abandoned projects with lots of infrastructure around their carcasses. The more forced overhead there is the more people will decide not to post their small projects, and the more quickly they'll abandon them if they do post. The thing I've liked most about Hackage is that it's like CPAN but moreso. CPAN is an excellent resource, but it has a few sticking points that make the barrier to entry and the cost of posting higher than they should be. Places like SourceForge or GoogleCode have very high barriers to entry, but they're going after a different audience. I think we want to emulate CPAN more than SF, for the sake of growing a wide collection of libraries. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What about adding a wiki for each haskell project?
Excerpts from wren ng thornton's message of Sun Dec 13 13:54:04 +0100 2009: Ketil Malde wrote: wren ng thornton w...@freegeek.org writes: Using a wiki page for each project enables anybody to add comments.[...] I think this is a great idea. Because of Duncan's concerns about imposing too much burden on authors, and because there are many mature projects which already have wikis etc, I have a counter-proposal. I don't this this is the same thing. Marc's proposal would provide a scratch pad for random users to discuss or comment on various stuff on Hackage. At least the way I see it, it is primarily *not* for use by the author, and in fact most useful when the author is not around to actively support his project. But if it's a wiki, wouldn't people be able to add changes themselves? Isn't that the idea behind wikis? Sure, the authors could lock down their wikis, but I don't get the feeling that many would. My interpretation of Duncan's concern ---not meaning to put words in his mouth--- is that adding a Hackage wiki could place undue burden on the authors. If authors already have a wiki, then a Hackage wiki is just an extra place to check for feedback which will be prone to duplication and being out-of-date. Indeed I didn't want hackage to host the wiki. I only want hackage to host the link to the wiki page. If this burden exist can we make it smaller by using a wiki which can send emails to the author (or the dev mailinglists) whenever there is a change? Then authors don't have to poll the wiki pages themselves. Anyway I feel this is going nowhere. The people which may benefit a lot are beginners. I learned that there are some maintainers who do follow Duncan's concerns. So let me start a last thread on beginn...@haskell.org. If they all say they fear outdated content more than they appreciate nice howtos or bugfixes which haven't been uploaded yet I'll forget about this idea and shut up. comparison to haskell.org/haskellwiki = Let's not forget that haskell.org is a nice source of information. It's a wiki as well. What makes haskell.org/haskellwiki (all other pages) that much different from what I propose? Let's wait and see what beginners think. Thank you very much for participating Marc Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What about adding a wiki for each haskell project?
wren ng thornton w...@freegeek.org writes: Ketil Malde wrote: At least the way I see it, it is primarily *not* for use by the author, and in fact most useful when the author is not around to actively support his project. But if it's a wiki, wouldn't people be able to add changes themselves? Isn't that the idea behind wikis? Sure, the authors could lock down their wikis, but I don't get the feeling that many would. (I'm sorry, you are correct of course, but I don't see how this applies to any of what I wrote?) his mouth--- is that adding a Hackage wiki could place undue burden on the authors. If authors already have a wiki, then a Hackage wiki is just an extra place to check for feedback which will be prone to duplication and being out-of-date. So if there's already a wiki, the author is forced to put a link on the Hackage to his own Wiki (unless it is automated from links in the .cabal file). If there isn't one, we get one. I understand that y'all think giving users a place for feedback is different than giving authors the tools to communicate with their users, but I don't think they're all that different. This is all assuming there *is* an author. I don't see your objections as very convincing - there is a ton of projects, libraries etc on Hackage. How many even have home pages? Bug trackers? That are updated? And: how many discontinued or orphaned or deprecated projects have updated home pages that point the user in a sensible direction? E.g. my package that was used as an example, while (arguably) useful, is way to small for me to bother with setting up a full site with web pages or bug trackers, etc. So someone else should set them up for you? No, someone else should set it up for *them*. You can't seriously mean that an auto-generated wiki page puts a burden on authors, while at the same time suggest that the authors have a duty to provide all kinds of supporting infrastructure. For projects they are no longer interested in? Either you want ways to communicate with your users or you don't. The problem is when I don't. Other packages are orphaned or see little interest from their author. That's a separate issue isn't it? Why not have an adopt-a-package program where the community determines which packages are orphaned and sets up and maintains wikis and other resources for them until a new maintainer can be found? You know, this is a great idea! And a great starting point would be a wiki, with a page for each library where information about it can be recorded by users as and when it is discovered. :-) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What about adding a wiki for each haskell project?
2009/12/13 Ketil Malde ke...@malde.org: wren ng thornton w...@freegeek.org writes: That's a separate issue isn't it? Why not have an adopt-a-package program where the community determines which packages are orphaned and sets up and maintains wikis and other resources for them until a new maintainer can be found? You know, this is a great idea! And a great starting point would be a wiki, with a page for each library where information about it can be recorded by users as and when it is discovered. :-) I'm sure there was a page on haskell.org before it moved to the wiki for this. Of course, now with orphan in my search string I only get references to orphan instances. Best wishes Stephen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Parallel foldl doesn't work correctly
On Sat, 2009-12-12 at 13:46 +, Ben Millwood wrote: On Sat, Dec 12, 2009 at 10:08 AM, Maciej Piechotka uzytkown...@gmail.com wrote: If operation is associative it can be done using divide et impera spliting list in half and operating on it pararerlly then split in half etc. Thank you very much for the replies. I've come to the conclusion that, yep, you can't (directly) parallelise of fold operation, as fold guarantees order of processing. With something like map the runtime is free to continue sparking function application to each element without waiting for the result. So we spark f x, force evaluation of the remainder of the xs and recurse. I'm *guessing* at a detailed level when we are creating the output list, haskell can concat each result element before f x returns due to laziness - that is, haskell doesn't need to wait for evaluation of f x, before continuing? With fold, and specifically with foldl (+), this isn't the case as (+) is strict on both arguments and thus it cannot continue until each sparked evaluation has completed and combined with the accumulator. If (+) was not strict on both arguments, I'm not sure if could solider on... assuming I've understood map correctly!? Writing it out long hand (sorry if this is tedious!), we have: using :: a - Strategy a - a using x s = s x `seq` x rwhnf :: Strategy a rwhnf x = x `seq` () parList :: Strategy a - Strategy [a] parList strat [] = () parList strat (x:xs) = strat x `par` (parList strat xs) parMap :: Strategy b - (a - b) - [a] - [b] parMap strat f = (`using` parList strat) . map f 'using' applies a strategy to an item, and then returns the item. 'parList' is a (combinator) strategy which applies an atomic strategy to each element in the list *in parallel* (for example forcing each element to WHNF). So for parMap we have xs passed into 'map f' - the result is then passed to 'using' which will force application of 'f' on each element in parallel by way of 'parList'. No forced evaluation is dependant on a previous evaluation. Now for parFoldl - a crude and wrong representation for my purposes could be: parFoldl :: Num b = Strategy b - (a - b) - [a] - b parFoldl strat f = sum . (`using` parList strat) . map f This isn't really a fold of course, but it is doing roughly the same thing, it's summing the results of applying function 'f' to each element in a list. The problem here is that sum will only allow one spark at a time, because sum [] = 0 sum (x:xs) = x + sum xs So we get something like: 0 + (x4 + (x3 + (x2 + (x1 For example the result for (x4 + previous) can only be evaluated after x3, x2 and x1 have been evaluated. This means it won't spark evaluation on x4 until (x3 + ) has been evaluated, thus only one core is ever used. I believe fold is just the general case of sum and the same logic applies. I suppose my questions are: Have I got this right, if not very succinct!? Is it purely the strictness of (+) that causes this situation? Ignoring DPH, is it possible to write a parallel fold avoiding something like the technique below? Anyhow, a workaround similar to those suggested I came up with is to divide the folds up across the cores and then sum the sub-folds - this produces approximately double the performance across two cores: import Control.Parallel.Strategies (parMap,rwhnf) import Data.List (foldl') import Data.List.Split (chunk) import GHC.Conc (numCapabilities) -- Prepare to share work to be -- done across available cores chunkOnCpu :: [a] - [[a]] chunkOnCpu xs = chunk (length xs `div` numCapabilities) xs -- Spark a fold of each chunk and -- sum the results. Only works because -- for associative folds. foldChunks :: ([a] - a) - (a - b - a) - a - [[b]] - a foldChunks combineFunc foldFunc acc = combineFunc . (parMap rwhnf $ foldl' foldFunc acc) -- Some pointless work to keep thread busy workFunc :: Int - Int workFunc 1 = 1 workFunc x = workFunc $ x - 1 -- Do some work on element x and append foldFunc :: Int - Int - Int foldFunc acc x = acc + workFunc x testList = repeat 10 answer = foldChunks sum foldFunc 0 $ chunkOnCpu (take 50 testList) main :: IO() main = print answer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC 6.12 status and features
On Sun, Dec 13, 2009 at 6:00 AM, Adam Cimarosti cimaro...@gmail.com wrote: WIth 6.10.4 there's a major bug with Snow leopard: It doesn't work (Cannot compile 64-bit). Well, it works as long as you apply a workaround and have universal (combo 32/64-bit) libraries available — albeit it would be much nicer to have 64-bit support. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
I too thought of using NBSP as a word separator. Unicode is replete with spaces of various widths and usages. I suggest, however, that Haskell code does tend to require careful reading, and that ambiguities (like the word boundaries that baStudlyCapsMakesSoHardToLocateQuickly) that we might tolerate in contexts where the text is fairly predictable are far less tolerable in stuff that requires a close reading. One of the problems with baStudlyCaps is that it can give Stress to the wrong words. Take takeWhile as an example. The while bit is humanly recoverable because a function follows it. The thing that you most need to see is take. But it's the least informative part of the name (While) that is stressed. The visible blank U+2423 (Unicode calls it an Open Box, but its function is to visibly indicate a blank) might␣just␣do, but you might as well use underscores (or hyphens). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
On Dec 11, 2009, at 11:37 PM, Johannes Laire wrote: On Thu, Dec 10, 2009 at 12:54 AM, Richard O'Keefe o...@cs.otago.ac.nz wrote: Given the amazinglyUglyAndUnreadably baStudlyCaps namingStyle that went into Haskell forNoApparentReasonThatIHaveEverHeardOf Compare: someCoolFunc fstParam sndParam fooBarBazQuux some_cool_func fst_param snd_param foo_bar_baz_quux In the first one, it's easy to see that there are 4 identifiers. But, at least for me, the second one is significantly harder to read; spaces and underscored are too similar. To me the gaps in the second one were clear and distinct. In any case, it's not clear that you *need* to see that there are 4 identifiers. You need to see the *first* identifier, and then you need to see the second, c, but let's face it, how often do you need to count the words in a sentence at a glance? And what good does it do to know there are four identifiers if you have to go back with a magnifying class to tell what the identifiers mean? I wrote a little program to search for runs of identifiers without intervening newlines or other tokens. I fed it 56,322 lines of Haskell from various sources. Here's the distribution: Len Tally iCap iCap is the average number of internal 1 84,474 0.21 capital letters in all of the words in 2 27,092 0.32 a run. 3 9,273 0.44 4 3,176 0.45 5866 0.49 6165 0.47 7 87 0.36 8 98 0.73 9 42 0.36 10 9 0.22 11 5 0.20 12 7 0.71 13 1 0.00 The longest run was j then Q i xs ys j else Q j ys xs i which would be the same under any word separation variant. We see from the iCap column that on the whole, the average number of internalCapitals per run is less than one. Looking in some detail at the runs with 4 words, I found that the typical pattern is someHairyGreatFunctionName i x xs with a touch of if okToProceedWith x then In fact, out of 3,176 runs with four words, 2,144 of them didn't have any internal capitals in the first place, so would not be at all affected by a change in word separation style. Having examined the remaining 1032 cases with some care, I honestly couldn't find any cases whose readability was worsened by by underscore separation. Don't forget, some of the arguments are constructors, and using underscore (or hyphen) separation makes it *easier* to see them, because they no longer look like parts of identifiers. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell Weekly News: Issue 142 - December 13, 2009
---
Haskell Weekly News
http://sequence.complete.org/hwn/20091213
Issue 142 - December 13, 2009
---
Welcome to issue 142 of HWN, a newsletter covering developments in the
[1]Haskell community.
First of all, apologies for the late edition, I've only one set of
finals left, and then everything should return to a normal schedule (at
least, that's the plan). This week brings lots of development on the
various usb utilities, an edition of the Haskell Web News (which
covers, in summary, the events of the previous month in the Haskell
online community), and some really great discussion about why Haskell
is Pure. Until next week, Haskeller's, your Haskell Weekly News!
Announcements
Next meeting: December 17th at MIT (32-G882). Ravi Nanavati
[2]announced the next meeting of the Boston Area Haskell User Group.
Ryan Newton will be talking about Intel Concurrent Collections for
Haskell.
PCLT-0.1 and PCLT-DB-0.1. Andrey Sisoyev [3]announced his first two
packages he's developed in Haskell. Both of his new packages relate to
localization of packages.
Announcing a summer internship for a NASA-sponsored project. Lee Pike
[4]announced a new summer internship sponsored by NASA and Galois, Inc.
unicode-symbols-0.1.1. Roel van Dijk [5]announced the release of his
package 'unicode-symbols'. This packages offers alternative symbols for
a number of common function and operators from the base and container
packages.
ls-usb-0.1.0.2. Roel van Dijk [6]announced a minor update of ls-usb,
his package for listing USB devices connected to your system.
usb-safe-0.1. Bas van Dijk [7]announced the release of his package
usb-safe, which provides an abstract interface to the bindings-libusb
library.
usb-0.3. Bas van Dijk [8]announced a new release of his 'usb' library
for high-level communication with usb devices from Haskell.
bindings-libusb-1.4.2. Bas van Dijk [9]announced a new version of
bindings-libusb, a DSL based, low level binding to libusb
The Haskell Web News: December 2009 Edition. Don Stewart [10]announced
the Haskell Web News for December.
new installment of failure framework. Michael Snoyman [11]announced the
next installment of the Failure Framework.
PortAudio Windows Tutorial and Binaries. M Xyz [12]announced a tutorial
for setting up PortAudio on Windows
readline-statevar-1.0.1.0. Krzysztof Skrzetnicki [13]announced a small
wrapper for readline.
hakyll-0.1. Jasper van der Jeugt [14]announced Hakyll, a simple static
site generator written in Haskell.
Discussion
Why? John D. Earle [15]asked about what benefits of purity in Haskell.
Type system speculation. Andrew Coppin [16]asked about why we
Haskeller's (including himself) are so obsessed with the type system.
To Hackage or not to Hackage. John Van Enk [17]asked about whether it
was worth putting a package on Hackage.
Hayoo and Hoogle (beginner question). drostin77 [18]asked our
'Hopefully Helpful Haskell Community' about the differences between
Hoogle and Hayoo.
Blog noise
[19]Haskell news from the [20]blogosphere. Blog posts from people new
to the Haskell community are marked with , be sure to welcome them!
* Manuel M T Chakravarty: [21]Using DTrace to track scheduler events
of GHC's runtime.
* Darcs: [22]darcs weekly news #47.
* Brent Yorgey: [23]Mgu's and universal properties.
* Philip Wadler: [24]Computer Science Education Week.
* Bryan O'Sullivan: [25]The performance of Data.Text.
* Neil Brown: [26]Solving the Santa Claus Problem with Conjunction.
* Douglas M. Auclair (geophf): [27]Don't know; don't care: Whatever.
* Ivan Lazar Miljenovic: [28]Command Input/Output and blocking.
* Galois, Inc: [29]Tech Talk: John Launchbury presents Conal
Elliottâs âBeautiful Differentiationâ.
* Well-Typed.Com: [30]Talk at the Functional Programming eXchange.
* Neil Brown: [31]The Problem with Parallel Participants Professing
Priority.
* Sean Leather: [32]Draft: Pull-Ups, Push-Downs, and Passing It
Around: Exercises in Functional Incrementalization.
* Mikael Vejdemo Johansson (Syzygy-): [33]Coordinatization with hom
complexes.
* Haskell Web News: [34]What's new in Haskell? December 2009.
* Dan Piponi (sigfpe): [35]Where do monads come from?.
* Michael Snoyman: [36]Two language extensions.
Quotes of the Week
* sproingie: | {-# LANGUAGE NoTypeChecking #-}
* kmc: the usual structure for a Haskell program is a crunchy IO
shell with a gooey chocolate pure function center
* sproingie: if it makes Cale's brane asplode, i think there's no
hope for me understanding it
* Wikipedia: In topology, the long line (or Alexandroff line
Re: [Haskell-cafe] Haskell Weekly News: Issue 142 - December 13, 2009
Hi, First and foremost; thanks for your work on the HWN. It is greatly appreciated. :) Just a quick tip: On Monday 14. December 2009 00.45.29 jfred...@gmail.com wrote: Until next week, Haskeller's, […] why we Haskeller's […] Both of these refer to many “haskellers” – no apostrophe should be put before the ‘s’ as that would mean *one* haskeller having something. (“A haskeller's best friend”.) -- Erlend Hamberg Everything will be ok in the end. If its not ok, its not the end. GPG/PGP: 0xAD3BCF19 45C3 E2E7 86CA ADB7 8DAD 51E7 3A1A F085 AD3B CF19 signature.asc Description: This is a digitally signed message part. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Weekly News: Issue 142 - December 13, 2009
English, while my first language (and in fact, only language...) is also my worst language... Thanks for catching the grammar snafu. While I'm here, please note that the issue number is off as well, it's fixed in the version on sequence.complete.org, but not in the email version. /Joe On Dec 13, 2009, at 7:03 PM, Erlend Hamberg wrote: Hi, First and foremost; thanks for your work on the HWN. It is greatly appreciated. :) Just a quick tip: On Monday 14. December 2009 00.45.29 jfred...@gmail.com wrote: Until next week, Haskeller's, […] why we Haskeller's […] Both of these refer to many “haskellers” – no apostrophe should be put before the ‘s’ as that would mean *one* haskeller having something. (“A haskeller's best friend”.) -- Erlend Hamberg Everything will be ok in the end. If its not ok, its not the end. GPG/PGP: 0xAD3BCF19 45C3 E2E7 86CA ADB7 8DAD 51E7 3A1A F085 AD3B CF19 ___ 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] Re: Allowing hyphens in identifiers
On Dec 13, 2009, at 3:44 AM, Daniel Fischer wrote: Am Freitag 11 Dezember 2009 01:20:55 schrieb Richard O'Keefe: On Dec 11, 2009, at 3:00 AM, Daniel Fischer wrote: Am Mittwoch 09 Dezember 2009 23:54:22 schrieb Richard O'Keefe: Given the amazinglyUglyAndUnreadably baStudlyCaps namingStyle that went into Haskell forNoApparentReasonThatIHaveEverHeardOf, mb_t's_bcs the ndrscr_stl is considered far uglier and less readable by others Come ON. Argue honestly! Thanks, but I have to return that compliment. Not a bit of it. mb_t's_bcs the ndrscr_stl was NOT playing fair and you knew it. I claim that the part not using insanely abbreviated words (isConsidered, farUglier, byOthers) *is* readable. Also that moderately abbreviated words are readable in camelCase as well as under_score. I guess we must mean different things by readable then. I've approached my head of department about running an experiment. (granted, underscore-style with nonabbreviated words is not unreadable, but still extremely ugly)? Who grants that underscore separation with fully written words is still extremely ugly? Not me! Is that remark really unclear, Yes, it is really unclear. It read as x (granted that y). For clarity, it should have been (still extremely ugly, granted that underscore-style with nonabbreviated words is not unreadable). Nobody *grants* anything is ugly or not, that is an aesthetic judgment, as such entirely a matter of personal preference - you can agree with it or not. Where is it written that aesthetic judgements are _entirely_ a matter of personal preference? As a student I was in the Archaeological society. One of the things I learned was this: - many ancient cultures would ritually kill grave goods - some grave goods would be smashed up, others would just have a chip out of them - as a rule, the ones that were least damaged were the ones the archaeologists considered to be the most beautiful (after repair). If an aesthetic sense about pots can be shared by modern archaeologists and people living five thousand years ago, it's hardly entirely personal. What you may not appreciate is that I have been a Smalltalk programmer for a long time. I've read and written a lot of code like printSolutions (self sendSolutionsUsing: Empty and: Empty to: [:p :n | Transcript nextPutAll: 'p = '; print: p; nextPutAll: ', n = '; print: n; nextPut: $.; cr. true stop after reporting first solution] ) ifFalse: [ Transcript nextPutAll: 'No solutions.'; cr]. If it were just a matter of experience, then this experience should surely have taught me to love baStudlyCaps. I have not been able to discover an experimental study of word separation style effect on readability in programming. I've been wondering about running a small one myself, next year. But there is enough experimentally determined about reading in general to be certain that visible gaps between words materially improves readability, and internal capital letters harm it. Now that applies to ordinary text, but until there's evidence to show that it doesn't apply to program sources, it's a reasonable working assumption that it does. I doubt that. Until the evidence is in, what other reasonable working assumption is there? Sourcecode is so different from ordinary text (a line of sourcecode rarely contains more than four or five words), OK, let's try it. Shakespeare sonnet number 1, first four lines, but split into shorter chunks With spaces: From fairest creatures we desire increase, That thereby beauty's rose might never die, But as the riper should by time decease, His tender heir might bear his memory: With underscores: From fairest_creatures we desire_increase, That thereby beauty's_rose might_never_die, But as the_riper should by_time decease, His tender_heir might_bear his_memory: With baStudlyCaps: From fairestCreatures we desireIncrease, That thereby beauty'sRose mightNeverDie, But as theRiper should byTime decease, His tenderHeir mightBear hisMemory: baStudlyCaps doesn't read any better with short lines. that I'd be very wary to transfer the findings for one to the other. It's not uncommon for style guides to explicitly recommend that program code should be spaced like text. Apple notoriously violate this in Objective C. Where Smalltalk would have this sendSolutionsUsing: Empty and: Empty to: that Objective C practice is to write [this sendSolutionsUsing:Empty and:Empty to:that] If somebody claimed that of x - take_while some_condition some_list and x - takeWhile someCondition someList either was objectively more readable than the other, I wouldn't believe it without lots and lots of hard evidence. Persaude a man against his will, he's of the same opinion still. How _much_ evidence? That's an artificial example. Haskell code doesn't tend to look like that. It's much more
[Haskell-cafe] Re: Pure extremism (was: Re: Why?)
2009/12/12 Luke Palmer lrpal...@gmail.com: On Fri, Dec 11, 2009 at 7:07 PM, Jason Dusek jason.du...@gmail.com wrote: Where do we draw the line between machinery and packages? The types don't tell us what libraries we need. ...you might mean what *haskell* libraries does a piece of code depend on? Yes, that's what I mean. To address that, note that I consider a statement like: import Control.Monad.State As a form of impurity in a sense... It's not referentially transparent, that's for sure. I have brainstormed solutions to this problem while thinking about my (currently on hold or dead) Udon project... I remember reading about that. As regards the object identity problem, say we just talk about uniquely naming bytestrings. Well, different bytestrings are different so they are their own name; if we don't want to compare them via substring matching, though, then we need a consensus algorithm to name them identically across nodes on the WAN. I wonder if a solipsistic internal namespace is not a workable solution? My repo knows objects (patches) I created as having unqualified names; objects from your computer are labelled as Luke's repo/... and vice versa. The repo can be garbage collected for patches that are actually the same by background string equality checks. As someone -- I think it was you? -- suggested on the list a little while ago, the chance of hash collision is not zero. -- Jason Dusek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] getting data through foreign layer without marshalling
I'm working with a C++ application library, of the sort where you instantiate a subclass of the library object and it dispatches your functions on receipt of various events. With multiple OS threads, by the way. This works all right so far, with some C++ boilerplate and Haskell FunPtrs created via the foreign wrapper option, but I am not crazy about marshalling the application data, to get it to the C++ object and back to my application functions. So, I'm wondering if the way I'm trying to thread application data through the C++ layer is reasonably fool-proof - I mean, empirically it works in a simple test, but are there going to be storage issues, etc.? Is there a better way to do it? Briefly, - my callbacks AppData - CPlusObjectPtr - P0 ... - IO Pn - the FunPtr inserted into C++ object FunPtr (CPlusObjectPtr - P0 ... - IO Pn) ... i.e, I apply the AppData parameter first - I rewrite the C++ object's FunPtrs every time I update the application data (freeHaskellFunPtr prior values.) I'm just not sure where AppData lives while it's referenced in a FunPtr via partial application, if there might be multiple copies, etc. thanks! Donn Cave, d...@avvanta.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: How Can Haskell Be Saved?
On Dec 14, 2009, at 6:16 AM, John D. Earle wrote: I am already familiar with SUA and it doesn't make Windows POSIX complaint in a way that I would call genuine. I grant you that certain aspects of Windows POSIX support have earned it the DeathStation 9000 label, but it's genuine enough to have earned this claim in the Wikipedia entry for POSIX: Microsoft Windows Services for UNIX 3.5 – enables full POSIX compliance for certain Microsoft Windows products. I also grant you that the Microsoft POSIX subsystem only supported the 1990 version of POSIX and has been described as close to useless. But of SUA it has been said As of 2004, server versions of Windows have a POSIX subsystem that supports threads, signals, sockets, and shared memory, less than twenty years after the standard was finalized, and only a little over a decade after Microsoft began advertising POSIX compliance. It was something I evaluated. There was no point in your mentioning that it exists unless you had ulterior motives. ulterior: being intentionally concealed so as to deceive. Nope. You said that Apple and Microsoft hadn't gone down the POSIX line. I pointed out that current MacOS _is_ a Unix; until today I've relied on Single Unix Specification version 3 documents to guide my Mac programming which makes it close enough for me. Today I downloaded the SUSv4 spec (POSIX 2008). I also pointed out that Windows NT had a fully compliant POSIX subsystem, by design, and that Microsoft cared at least enough about POSIX support to buy the company that made what is now SUA. For that matter, no version of Linux, no version of BSD, and no version of OpenSolaris is certified POSIX-compliant (open source projects change too fast for certification to be cheap). Microsoft can't go the POSIX route exclusively without killing their cash cow. VMS was the first POSIX-certified system, but that didn't mean DEC or VMS users abandoning VMS. zOS is POSIX-compliant, but I expect most sites running zOS have no intention of switching, and IBM have no intention of making them. It isn't what they are telling you that matters; it is what they are not telling you. It is called a half truth. If Haskell wants to be saved, it has got to give up the lying. What on earth is Haskell lying about? What does Haskell need to be saved from? (Its growing popularity and mushrooming library?) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: How Can Haskell Be Saved?
Richard O'Keefe wrote: I also pointed out that Windows NT had a fully compliant POSIX subsystem, by design, and that Microsoft cared at least enough about POSIX support to buy the company that made what is now SUA. How does that explain things like fstat() and stat() returning different values for the same file: http://www.mega-nerd.com/erikd/Blog/Windiots/posix.html That bug exists in windows XP, Vista and 7. For that matter, no version of Linux, no version of BSD, and no version of OpenSolaris is certified POSIX-compliant (open source projects change too fast for certification to be cheap). For the last decade I have been the main author of libsndfile: http://www.mega-nerd.com/libsndfile/ a library that requires nothing of POSIX other than file I/O but needs to run on windows and *nix. You would think that Microsoft's much touted POSIX support would mean that the POSIX calls I used on *nix would JustWork(tm) on windows. Unfortunately, due to bugs in Microsoft's POSIX implementation this is not the case. Bugs include: - fstat() (64 bit file length aware version) returning the wrong file length after a write (win9x). - lseek() (64 bit file length aware version) to SEEK_END not actually going to the end of the file (win2000 and win2003). - fstat() and stat() returning different results on the same file (XP, Vista and 7). Because testing for and working around these bugs is simply too difficult, I have been forced to maintain tow versions of the file I/O code, one POSIX (that works on *nix including Mac OS X) and for windows, the native windows file I/O API. I suspect that authors of other open source projects that started on Linux and were then ported to windows would have similar stories of egregious unfixed bugs in Microsoft's POSIX implementation. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Parallel foldl doesn't work correctly
-- Prepare to share work to be -- done across available cores chunkOnCpu :: [a] - [[a]] chunkOnCpu xs = chunk (length xs `div` numCapabilities) xs -- Spark a fold of each chunk and -- sum the results. Only works because -- for associative folds. foldChunks :: ([a] - a) - (a - b - a) - a - [[b]] - a foldChunks combineFunc foldFunc acc = combineFunc . (parMap rwhnf $ foldl' foldFunc acc) I should probably point out that use of chunk above isn't a good idea in anything beyond a toy example. If you have used a list comprehension to create your input then splitting it like the above results in thunks that grow with list size as chunk forces generation of the list. This rapidly negates any advantage gained from processing across 1 core! This is easily solved - just alter the generating function to create a *list* of list comprehensions equal in length to the number of cores you wish to process across, rather than create one list that is split across the cores later. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [darcs-users] Iteratees, streams, and mmap
On Sun, Dec 13, 2009 at 3:47 AM, Heinrich Apfelmus apfel...@quantentunnel.de wrote: How about tracking the requirement of bounded in the type system? In particular, I'm thinking of a type class class NFData a = Small a where the idea is that all types that can be stored in constant space are members of this class. For example, we have instance Small () instance Small Int instance Small Char instance (Small a, Small b) = Small (a,b) instance (Small a, Small b) = Small (Either a b) but recursive types like [a] or String are not allowed to be members. I like this. It's easy to audit for weird instances of Small. It seems like we also need: instance Small (IO ()) Which is not necessarily bounded due to things like IORefs. See below for why I think it would be a useful instance. Then, withPending :: Small a = (a - Patch - a) - IO a which is based on the function foldlSmall :: Small b = (b - a - b) - b - [a] - b foldlSmall f b [] = foldlSmall f b (x:xs) = foldlSmall f b' xs where b' = rnf (f b x) is pretty much guaranteed to run in O(1) space. Well, that depends on f , but the point is it's not foldlSmall who introduces the space leak, it's the argument that takes all the blame. I could also see, us needing this: bracketSmall :: (Small c) = IO a - (a - IO b) - (a - IO c) - IO c I'm not sure if b needs to be Small, since it's just supposed to be the return value of the deallocation step. Actually, since we didn't (yet) make functions an instance of Small, we may need to say this type: bracketFoldSmall :: (Small c) = IO a - (a - IO b) - ((c - a - c) - c - a - c) - IO c Here I'm imagining 'a', being something like a list of patches. It's a big stream we want to process. Furthermore, it seems like we probably want c = IO (). This would be useful if we wanted to do some output for each patch in the sequence. But, as I think about it, it seems like if we allow ST or IO in these small functions or as instances of Small then we lose our guarantees. Yet, it seems that having functions like bracketSmall are necessary if we want to hide the stream itself from being exposed outside of the traversal function. For example, your foldlSmall doesn't leak, but something at the same level of scope as it could leak the list. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Allowing hyphens in identifiers
Am Montag 14 Dezember 2009 01:44:16 schrieb Richard O'Keefe: On Dec 13, 2009, at 3:44 AM, Daniel Fischer wrote: Am Freitag 11 Dezember 2009 01:20:55 schrieb Richard O'Keefe: On Dec 11, 2009, at 3:00 AM, Daniel Fischer wrote: Am Mittwoch 09 Dezember 2009 23:54:22 schrieb Richard O'Keefe: Given the amazinglyUglyAndUnreadably baStudlyCaps namingStyle that went into Haskell forNoApparentReasonThatIHaveEverHeardOf, mb_t's_bcs the ndrscr_stl is considered far uglier and less readable by others Come ON. Argue honestly! Thanks, but I have to return that compliment. Not a bit of it. mb_t's_bcs the ndrscr_stl was NOT playing fair and you knew it. 1. I wasn't playing in the under_score vs. camelCase game, just proposing a possible reason why the camelCase may have been chosen for Haskell's standard libraries. For that, I deliberately used an unrealistically exaggerated example of unreadable underscores. Even more unrealistic than your camelCase parody. The very next thing, I said that full_word_underscores is *not* unreadable, making clear (apparently not to you, sorry about that) that the example is not to be taken at face value. 2. Below, you say that it was an honest misunderstanding, so it's okay then. I didn't expect that to be the case but suspected intentional misinterpretation. I claim that the part not using insanely abbreviated words (isConsidered, farUglier, byOthers) *is* readable. Also that moderately abbreviated words are readable in camelCase as well as under_score. I guess we must mean different things by readable then. By readable, I mean (broadly) easy to read. Of course, some find is_considered far_uglier by_others easier to read, others harder, and yet others find both equally easy to read. I have no difficulty believing that some find either of the styles hard to read, but I don't expect experienced programmers to be in that group. I've approached my head of department about running an experiment. (granted, underscore-style with nonabbreviated words is not unreadable, but still extremely ugly)? Who grants that underscore separation with fully written words is still extremely ugly? Not me! Is that remark really unclear, Yes, it is really unclear. It read as x (granted that y). Aha. English more fragile than thought. Sorry. For clarity, it should have been (still extremely ugly, granted that underscore-style with nonabbreviated words is not unreadable). No, that is not what I meant. [Granted,] Underscore-style with nonabbreviated words is not unreadable. Even with written-out words, underscore-style is still extremely[1] ugly. [1] This, however, is an exaggeration as far as I'm concerned. I find the underscore-style ugly, but not extremly so. It was your amazinglyUgly which caused it to appear in that sentence. Nobody *grants* anything is ugly or not, that is an aesthetic judgment, as such entirely a matter of personal preference - you can agree with it or not. Where is it written that aesthetic judgements are _entirely_ a matter of personal preference? I think you could find that written in many texts on aesthetic relativism. Doesn't matter, though. Of course, one's personal preferences aren't developed in a vacuum, they are strongly influenced by genes and society. So a lot of preferences are shared within a culture and even across cultures and aesthetic judgments aren't entirely *individual*. Nevertheless, I'm convinced that there is no Platonic idea Beauty (or Ugliness) and that if A says that van Gogh's Sunflowers is a beautiful picture while B says it's ugly, it's not the case that one is objectively right, the other wrong. Both are judgments based on their respective preferences and nothing else (unless: lying, acting, succumbing to social pressure, other reasons to not express one's actual opinion). As a student I was in the Archaeological society. One of the things I learned was this: - many ancient cultures would ritually kill grave goods - some grave goods would be smashed up, others would just have a chip out of them - as a rule, the ones that were least damaged were the ones the archaeologists considered to be the most beautiful (after repair). If an aesthetic sense about pots can be shared by modern archaeologists and people living five thousand years ago, it's hardly entirely personal. Depends on what you mean by entirely personal. All I'm saying is that one can find a thing beautiful which another finds ugly. What you may not appreciate is that I have been a Smalltalk programmer for a long time. I've read and written a lot of code like printSolutions (self sendSolutionsUsing: Empty and: Empty to: [:p :n | Transcript nextPutAll: 'p = '; print: p; nextPutAll: ', n = '; print: n; nextPut: $.; cr. true stop after reporting first solution] ) ifFalse: [
[Haskell-cafe] platform configure fails to find freeglut
I'm trying to install haskell-platform-2009.2.0.2 on OpenSuse 11.2 Gnu/Linux 2.6.27.39-0.2-default #1 SMP x86_64 My currently installed packages include ghc-6.10.4-5.7 freeglut-080721-20.2.1 ghc-GLUT-doc-2.1.2.0-1.13 ghc-GLUT-devel-2.1.2.0-1.13 ghc-GLUT-prof-2.1.2.0-1.13 When I try to ./configure I get checking GL/glut.h usability... no checking GL/glut.h presence... no checking for GL/glut.h... no configure: error: The GLUT C library is required One would think that with all of this good glut stuff I have installed the configure script would be satisfied, but it's not. Searching for answers only turned up other people with the same problem. Can someone assist me in fixing the problem? BTW - is there an official bug repository for the Haskell Platoform? I couldn't find that either, and I think it's very important! Thanks, _Greg P.S. In case it matters, here are most of my installed haskell packages: ghc-6.10.4-5.7 ghc-binary-devel-0.5.0.1-1.12 ghc-binary-doc-0.5.0.1-1.12 ghc-cairo-devel-0.10.1-1.4 ghc-data-accessor-devel-0.2.0.2-1.7 ghc-data-accessor-doc-0.2.0.2-1.7 ghc-data-accessor-monads-fd-devel-0.2-1.7 ghc-data-accessor-monads-fd-doc-0.2-1.7 ghc-data-accessor-template-devel-0.2.1.1-1.7 ghc-data-accessor-template-doc-0.2.1.1-1.7 ghc-derive-devel-0.1.4-2.55 ghc-derive-doc-0.1.4-2.55 ghc-Diff-devel-0.1.2-1.13 ghc-Diff-doc-0.1.2-1.13 ghc-doc-6.10.4-5.7 ghc-fingertree-devel-0.0-1.12 ghc-fingertree-doc-0.0-1.12 ghc-glib-devel-0.10.1-1.4 ghc-GLUT-devel-2.1.2.0-1.13 ghc-GLUT-doc-2.1.2.0-1.13 ghc-GLUT-prof-2.1.2.0-1.13 ghc-gtk2hs-common-0.10.1-1.4 ghc-gtk2hs-doc-0.10.1-1.4 ghc-gtk-devel-0.10.1-1.4 ghc-monads-fd-devel-0.0.0.1-1.9 ghc-monads-fd-doc-0.0.0.1-1.9 ghc-OpenGL-devel-2.2.2.0-1.15 ghc-OpenGL-doc-2.2.2.0-1.15 ghc-OpenGL-prof-2.2.2.0-1.15 ghc-paths-devel-0.1.0.5-19.14 ghc-paths-doc-0.1.0.5-19.14 ghc-pointedlist-devel-0.3.1-2.6 ghc-pointedlist-doc-0.3.1-2.6 ghc-prof-6.10.4-5.7 ghc-pureMD5-devel-0.2.4-1.7 ghc-pureMD5-doc-0.2.4-1.7 ghc-regex-tdfa-devel-1.1.1-1.10 ghc-regex-tdfa-doc-1.1.1-1.10 ghc-rosezipper-devel-0.1-1.7 ghc-rosezipper-doc-0.1-1.7 ghc-split-devel-0.1.1-1.12 ghc-split-doc-0.1.1-1.12 ghc-terminfo-devel-0.3.0.2-1.14 ghc-terminfo-doc-0.3.0.2-1.14 ghc-transformers-devel-0.1.4.0-1.12 ghc-transformers-doc-0.1.4.0-1.12 ghc-uniplate-devel-1.2.0.3-1.7 ghc-uniplate-doc-1.2.0.3-1.7 ghc-unix-compat-devel-0.1.2.1-1.14 ghc-unix-compat-doc-0.1.2.1-1.14 ghc-utf8-string-devel-0.3.4-1.14 ghc-utf8-string-doc-0.3.4-1.14 ghc-utility-ht-devel-0.0.4-1.7 ghc-utility-ht-doc-0.0.4-1.7 ghc-vty-devel-3.1.8.4-1.11 ghc-vty-doc-3.1.8.4-1.11 ghc-X11-devel-1.4.5-5.16 ghc-X11-doc-1.4.5-5.16 ghc-xmonad-contrib-devel-0.8.1-1.8 ghc-xmonad-contrib-doc-0.8.1-1.8 ghc-xmonad-devel-0.8.1-8.9 ghc-xmonad-doc-0.8.1-8.9 ghc-yi-devel-0.6.0-4.7 ghc-yi-doc-0.6.0-4.7 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] platform configure fails to find freeglut
jgd: BTW - is there an official bug repository for the Haskell Platoform? I couldn't find that either, and I think it's very important! Yes, of course there's a bug tracker, linked from: http://hackage.haskell.org/platform/ http://trac.haskell.org/haskell-platform/report/1 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] writing graphs with do-notation
Hi! This technique has been used to define netlists in hardware description languages. The original Lava [1] used a monad, but later switched to using observable sharing [2]. Wired [3] uses a monad similar to yours (but more complicated). I think it would be nice to have a single library for defining such graphs (or maybe there is one already?). The graph structure in Wired could probably be divided into a purely structural part and a hardware-specific part. [1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.46.5221 [2] http://www.cs.chalmers.se/~dave/papers/observable-sharing.pdf [3] http://hackage.haskell.org/package/Wired / Emil Soenke Hahn skrev: Hi! Some time ago, i needed to write down graphs in Haskell. I wanted to be able to write them down without to much noise, to make them easily maintainable. I came up with a way to define graphs using monads and the do notation. I thought this might be interesting to someone, so i wrote a small script to illustrate the idea. Here's an example: example :: Graph String example = buildGraph $ do a - mkNode A [] b - mkNode B [a] mkNode C [a, b] In this graph there are three nodes identified by [A, B, C] and three edges ([(A, B), (A, C), (B, C)]). Think of the variables a and b as outputs of the nodes A and B. Note that each node identifier needs to be mentioned only once. Also the definition of edges (references to other nodes via the outputs) can be checked at compile time. The attachment is a little script that defines a Graph-type (nothing elaborate), the buildGraph function and an example graph that is a little more complex than the above. The main function of the script prints the example graph to stdout to be read by dot (or similar). By the way, it is possible to define cyclic graphs using mdo (RecursiveDo). I haven't come across something similar, so i thought, i'd share it. What do you think? Sönke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: How Can Haskell Be Saved?
What does Haskell need to be saved from? (Its growing popularity and mushrooming library?) Arguably John Earle's emails suggest that the answer to this is Yes. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] getting data through foreign layer without marshalling
2009/12/14 Donn Cave d...@avvanta.com: I'm working with a C++ application library, of the sort where you instantiate a subclass of the library object and it dispatches your functions on receipt of various events. With multiple OS threads, by the way. This works all right so far, with some C++ boilerplate and Haskell FunPtrs created via the foreign wrapper option, but I am not crazy about marshalling the application data, to get it to the C++ object and back to my application functions. So, I'm wondering if the way I'm trying to thread application data through the C++ layer is reasonably fool-proof - I mean, empirically it works in a simple test, but are there going to be storage issues, etc.? Is there a better way to do it? Briefly, - my callbacks AppData - CPlusObjectPtr - P0 ... - IO Pn - the FunPtr inserted into C++ object FunPtr (CPlusObjectPtr - P0 ... - IO Pn) ... i.e, I apply the AppData parameter first - I rewrite the C++ object's FunPtrs every time I update the application data (freeHaskellFunPtr prior values.) I'm just not sure where AppData lives while it's referenced in a FunPtr via partial application, if there might be multiple copies, etc. I don't fully understand what you want to do, but perhaps you can use a StablePtr: http://www.haskell.org/ghc/docs/latest/html/libraries/base/Foreign-StablePtr.html Cheers, Bernie. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
