Re: Multiple imports on a single line
You can already write this, with only a tiny bit of syntax: module MyApp where import Data.Text; import Data.Foldable; import Control.Concurrent Whether it is good style is another matter, but all compilers will certainly accept it. Regards, Malcolm On 1 Feb 2017, at 14:18, Vassil Ognyanov Keremidchiev wrote: > Hello! > > What do you think about an idea to have multiple imports on a single line, > like: > > module MyApp where > import Data.Text, Data.Foldable, Control.Concurrent > ... > > That way we could write more concise and short code as Haskell promises. This > will be useful for small programs like scripts, small tools, tutorials, > examples, etc. > > Best regards, > Vassil Keremidchiev > ___ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: type error formatting
On 24 Oct 2015, at 09:17, Joachim Breitner wrote: > For example in > >>Relevant bindings include >> syllables :: [(a1, Syllable)] >> (bound at Derive/Call/India/Pakhawaj.hs:141:16) >> best_match :: [(a1, Syllable)] >> -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) >> (bound at Derive/Call/India/Pakhawaj.hs:141:5) > > Also, unless the programmer is doing weird things with shadowing, is > the "bound at" information really valuable? I’d say no: Usually, the > programmer knows his bindings, and even if not, she will not have any > problems finding the right binding. As someone who spends a lot of time maintaining code that I did not write, I have to say that it is not enough that the "programmer knows his bindings". She might, but I do not. This kind of helpful signposting of exactly what file + linenumber + character position to look at, is really useful for someone who is not familiar with the code. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP
On 6 Oct 2015, at 17:47, Herbert Valerio Riedel wrote: > >> The problem by discussions is that they are done between two groups with >> quite a difference in experience. On one hand you have people like Bryan, >> who have considerable contributions to the Haskell ecosystem and much >> experience in large scale software development (e.g. from Facebook). On the >> other hand you have people who don't. That's okay. We've all been at the >> latter group at some point of our career. > [...] > > At the risk of stating the obvious: I don't think it matters from which > group a given argument comes from as its validity doesn't depend on the > messenger. In that case, I think you are misunderstanding the relevance of Johan's argument here. Let me try to phrase it differently. Some people who can reasonably claim to have experience with million-line plus codebases are warning that this change is too disruptive, and makes maintenance harder than it ought to be. On the other hand, of the people who say the change is not really disruptive, none of them have (yet?) made claims to have experience of the maintenance of extremely large-scale codebases. The authority of the speaker does matter in technical arguments of this nature: people without the relevant experience are simply unqualified to make guesses about the impact. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`
On other social media forums, I am seeing educators who use Haskell as a vehicle for their main work, but would not consider themselves Haskell researchers, and certainly do not have the time to follow Haskell mailing lists, who are beginning to say that these kinds of annoying breakages to the language, affecting their research and teaching materials, are beginning to disincline them to continue using Haskell. They are feeling like they would be less well disposed to reviewing papers that use Haskell, and less well disposed to collaborating on writing papers that involve Haskell. Please can the Haskell Prime Committee take into account the views of such "peripheral" users of the language, who after all, form some measure of its recent "success". Haskell is a real-world tool for many people, and breakage of their code, and their sources of information about Haskell, is a powerful disincentive to continue with it. Regards, Malcolm > On 5 Oct 2015, at 10:05, Malcolm Wallace wrote: > >> I am also a strong -1 on small changes that break huge numbers of things for >> somewhat trivial benefits. >> >> Regards, >> Malcolm >> >> On 2 Oct 2015, at 11:09, Henrik Nilsson wrote: >> >>> Hi all, >>> >>> I have discussed the monad of no return proposal with >>> my colleague Graham Hutton: a long-standing member of >>> the Haskell community, well-known researcher, some 20 >>> years of experience of teaching Haskell to >>> undergraduate students, and author of one of the most >>> successful introductory Haskell textbooks there are. >>> >>> The upshot of this e-mail is a strong collective -2 >>> from us both on particular proposal, and a general call >>> for much more caution when it comes to breaking changes >>> that are not critically important. >>> >>> First, on a general note, there has recently been a >>> flurry of breaking changes to the (de facto) Haskell >>> standards. In many cases for very good reasons, but >>> sometimes it seems more in a quest for perfection >>> without due consideration for the consequences. It used >>> to be the case that breaking changes were very rare >>> indeed. And for good reason. >>> >>> Right now, the main "measure of breakage" in the >>> on-line discussions seems to be how many packages that >>> break in Hackage. Which of course makes sense: the >>> Hackage repository is very important and such a measure >>> is objective, as far as it goes. >>> >>> But we should not forget that breakage can go far >>> beyond Hackage. For starters, there is *lots* of code >>> that is not in Hackage, yet critically important to its >>> users, however many or few they are. There are more >>> than hundreds of thousands of copies of books out there >>> where that may break in that examples may no longer >>> work. And they cannot be changed. There are countless >>> research papers that may break in the same way. Every >>> single institution that use Haskell in their teaching >>> may have to update their teaching materials (slides, >>> code, lab instructions) for every module that teaches >>> or uses Haskell. And last but not the least, what >>> countless of programmers and students have learned >>> about Haskell over decades, most of whom are *not* >>> power users who can take these changes in their stride, >>> may also break. >>> >>> Now, of course a language has to evolve, and sometimes >>> breaking backwards compatibility is more or less >>> essential for the long-term benefit of the language. >>> But we should not let perfection be the enemy of the >>> good. >>> >>> As to this particular proposal, the monad of no return, >>> it does not seem essential to us, but mostly motivated >>> by a quest for "perfection" as defined by a very >>> knowledgeable but in relative terms small group of >>> people. >>> >>> One argument put forward was that applicative code that >>> uses "return" instead of "pure" should get a less >>> constrained type. But such code is relatively new. The >>> methods of the Monad class have been return and bind >>> for some 25 years. So indeed, as Henning Thielemann >>> wrote: why should not the newer code be adapted and use >>> "pure" instead? In fact, the use of "pure" in such code >>> could serve as a quite useful cue that the co
Re: [Haskell-cafe] RFC: Native -XCPP Proposal
Exactly. My post was an attempt to elicit response from anyone to whom it matters. There is no point in worrying about hypothetical licensing problems - let's hear about the real ones. Regards, Malcolm On 7 May 2015, at 22:15, Tomas Carnecky wrote: That doesn't mean those people don't exist. Maybe they do but are too afraid to speak up (due to corporate policy or whatever). On Thu, May 7, 2015 at 10:41 PM, Malcolm Wallace malcolm.wall...@me.com wrote: I also note that in this discussion, so far not a single person has said that the cpphs licence would actually be a problem for them. Regards, Malcolm On 7 May 2015, at 20:54, Herbert Valerio Riedel wrote: On 2015-05-06 at 13:38:16 +0200, Jan Stolarek wrote: [...] Regarding licensing issues: perhaps we should simply ask Malcolm Wallace if he would consider changing the license for the sake of GHC? Or perhaps he could grant a custom-tailored license to the GHC project? After all, the project page [1] says: If that's a problem for you, contact me to make other arrangements. Fyi, Neil talked to him[1]: | I talked to Malcolm. His contention is that it doesn't actually change | the license of the ghc package. As such, it's just a single extra | license to add to a directory full of licenses, which is no big deal. [1]: http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_proposal/cr1e5n3 ___ Haskell-Cafe mailing list haskell-c...@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] RFC: Native -XCPP Proposal
On 8 May 2015, at 00:06, Richard A. O'Keefe wrote: I think it's important that there be *one* cpp used by Haskell. fpp is under 4 kSLOC of C, and surely Haskell can do a lot better. FWIW, cpphs is about 1600 LoC today. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: RFC: Native -XCPP Proposal
I also note that in this discussion, so far not a single person has said that the cpphs licence would actually be a problem for them. Regards, Malcolm On 7 May 2015, at 20:54, Herbert Valerio Riedel wrote: On 2015-05-06 at 13:38:16 +0200, Jan Stolarek wrote: [...] Regarding licensing issues: perhaps we should simply ask Malcolm Wallace if he would consider changing the license for the sake of GHC? Or perhaps he could grant a custom-tailored license to the GHC project? After all, the project page [1] says: If that's a problem for you, contact me to make other arrangements. Fyi, Neil talked to him[1]: | I talked to Malcolm. His contention is that it doesn't actually change | the license of the ghc package. As such, it's just a single extra | license to add to a directory full of licenses, which is no big deal. [1]: http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_proposal/cr1e5n3 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.10 regression when using foldr
On 20 Jan 2015, at 11:20, Björn Peemöller wrote: The reason is the usage of foldr, which changed its type from foldr :: (a - b - b) - b - [a] - b -- GHC 7.8.4 to foldr :: Foldable t = (a - b - b) - b - t a - b -- GHC 7.10.1 Thus, the use of foldr is now ambiguous. I can fix this by providing a type signature convert :: ([a], String) - (List a, String) However, is this breaking change intended? I believe this kind of breakage was predicted by those opposed to the change of signature. That is not quite the same thing as being intended or desired. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.10.1 Release Candidate 1 - feedback on Mac OS
On 1 Jan 2015, at 13:58, George Colpitts wrote: Configuring cpphs-1.13... Building cpphs-1.13... Warning: cpphs.cabal: Unknown fields: build-depends (line 5) Could not find module ‘Prelude’ It is a member of the hidden package ‘base-4.8.0.0’. Perhaps you need to add ‘base’ to the build-depends in your .cabal file. The two statements unknown field build-depends and add package to build-depends seem rather contradictory. How can this be fixed? Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: The future of the haskell2010/haskell98 packages - AKA Trac #9590
How about doing the honest thing, and withdrawing both packages in ghc-7.10? Haskell'98 is now 15 years old, and the 2010 standard was never really popular anyway. Regards, Malcolm On 30 Sep 2014, at 21:21, Austin Seipp aus...@well-typed.com wrote: Hello developers, users, friends, I'd like you all to weigh in on something - a GHC bug report, that has happened as a result of making Applicative a superclass of Monad: https://ghc.haskell.org/trac/ghc/ticket/9590 The very condensed version is this: because haskell2010/haskell98 packages try to be fairly strictly conforming, they do not have modules like Control.Applicative. Unfortunately, due to the way these packages are structured, many things are simply re-exported from base, like `Monad`. But `Applicative` is not, and cannot be imported if you use -XHaskell2010 and the haskell2010 package. The net result here is that haskell98/haskell2010 are hopelessly broken in the current state: it's impossible to define an instance of `Monad`, because you cannot define an instance of `Applicative`, because you can't import it in the first place! This leaves us in quite a pickle. So I ask: Friends, what do you think we should do? I am particularly interested in users/developers of current Haskell2010 packages - not just code that may *be* standard Haskell - code that implies a dependency on it. There was a short discussion between me and Simon Marlow about this in the morning, and again on IRC this morning between me, Duncan, Edward K, and Herbert. Basically, I only see one of two options: - We could make GHC support both: a version of `Monad` without `Applicative`, and one with it. This creates some complication in the desugarer, where GHC takes care of `do` syntax (and thus needs to be aware of `Monad`'s definition and location). But it is, perhaps, quite doable. - We change both packages to export `Applicative` and follow the API changes in `base` accordingly. Note that #1 above is contingent on three things: 1) There is interest in this actually happening, and these separate APIs being supported. If there is not significant interest in maintaining this, it's unclear if we should go for it. 2) It's not overly monstrously complex (I don't think it necessarily will be, but it might be.) 3) You can't like `haskell2010` packages and `base` packages together in the general case, but, AFAIK, this wasn't the case before either. I'd really appreciate your thoughts. This must be sorted out for 7.10 somehow; the current situation is hopelessly busted. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: changes to -i flag for finding source files
On 25 Apr 2014, at 14:17, Simon Marlow wrote: The problem we often have is that when you're writing code for a library that lives deep in the module hierarchy, you end up needing a deep directory structure, where the top few layers are all empty. I don't see how this is a problem at all. Navigating the vacuous structure is as simple as pressing the tab key a few times. But if you change the mapping convention between files and module names, you need to do it for all tools, not just the compiler. I imagine all of the following tools would need to know about it: cabal, hoogle, haddock, happy, alex, hat, hsc2hs and probably a few more. The feature seems like a very low power-to-weight ratio, so -1 from me. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Mac CPP problem with ghc-clang-wrapper
Yes, this is a known problem. I intend to put out a fresh version of HaXml soon to fix it. Regards, Malcolm On 18 Mar 2014, at 15:17, Christian Maeder wrote: Hi, under mavericks using the ghc-clang-wrapper (ghc-7.6) or using ghc-7.8.20140130 I can no longer install the HaXml package. The source line: putStrLn $ part of HaXml-++show MAJOR.MINOR seems to put spaces around the decimal point between MAJOR and MINOR and fails as shown below. Is this already a known problem? Cheers Christian [14 of 42] Compiling Text.XML.HaXml.Wrappers ( src/Text/XML/HaXml/Wrappers.hs, dist/build/Text/XML/HaXml/Wrappers.o ) src/Text/XML/HaXml/Wrappers.hs:34:36: Couldn't match type ‛[Char]’ with ‛b0 - c0’ Expected type: b0 - c0 Actual type: String Possible cause: ‛show’ is applied to too many arguments In the first argument of ‛(.)’, namely ‛show 1’ In the second argument of ‛(++)’, namely ‛show 1 . 24’ src/Text/XML/HaXml/Wrappers.hs:34:36: Couldn't match expected type ‛[Char]’ with actual type ‛a0 - c0’ In the second argument of ‛(++)’, namely ‛show 1 . 24’ In the second argument of ‛($)’, namely ‛part of HaXml- ++ show 1 . 24’ In a stmt of a 'do' block: putStrLn $ part of HaXml- ++ show 1 . 24 Failed to install HaXml-1.24 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] A question regarding reading CPP definitions from a C header
If you use cpphs as a library, there is an API called runCpphsReturningSymTab. Thence you can throw away the actual pre-preprocessed result text, keep only the symbol table, and lookup whatever macros you wish to find their values. I suggest you make this into a little code-generator, to produce a Haskell module containing the values you need. On 5 Oct 2013, at 21:37, Ömer Sinan Ağacan wrote: Hi all, Let's say I want to #include a C header file in my Haskell library just to read some macro definitions. The C header file also contains some C code. Is there a way to load only macro definitions and not C code in #include declarations in Haskell? What I'm trying to do is I'm linking my library against this C library but I want to support different versions of this C library, so I want to read it's version from one of it's header files. The problem is the header file contains some C code and makes my Haskell source code mixed with C source before compilation. Any suggestions would be appreciated, ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cpphs calls error when it finds an #error declaration
On 27 Aug 2013, at 08:33, Niklas Hambüchen wrote: @Malcolm, would you mind a change towards throwing an exception that is different from error so that it can be easily caught, or even better, a change from runCpphs :: ... - IO String to runCpphs :: ... - IO (Either String String) or similar? Have you tried simply wrapping the call to runCpphs in a catch? Something like safeRunCpphs :: ... - IO (Either String String) safeRunCpphs foo = fmap Right (runCpphs foo) `catch` (\(UserError s)- Left s If an exception based interface is kept, it would be nice to add some haddock to `runCpphs`; not knowing about the existence of #error, it is easy to assume that the IO is only used for accessing the FilePath passed in. The IO is used also for reading #include'd files, of course. I'd be happy to add some extra documentation making the behaviour on #error clearer, if you can suggest some text that would have helped you. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: cascading type errors in ghc
On 6 Aug 2013, at 20:03, Evan Laforge wrote: I don't know how others like to work, but I like when a compiler bails early, because I fix errors one at a time, and I search for the easiest looking ones before worrying about the complicated looking ones. With C compilers, it is often the case that only the first error is real, and the subsequent errors are consequences of not being able to recover from the first one. However, one of the really nice things about GHC is that the list of type errors is complete and coherent. I often start at the bottom of the list and work my way up fixing them in a single pass (upwards, in order to give myself the best chance that the line numbers are still correct after I have fixed the later errors). There are not many compilers you can do that with, and I like it when I can. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Why GHC is written in Happy and not a monadic parser library?
On 3 Aug 2013, at 21:03, Jason Dagit wrote: Another con of using parsec that I forgot to mention in my previous email is that with Parsec you need to be explicit about backtracking (use of try). Reasoning about the correct places to put try is not always easy and parsec doesn't help you with the task. In my experience, this is the main bug that people run into when using parsec. Although the original question did not mention parsec explicitly, I find it disappointing that many people immediately think of it as the epitome of monadic combinator parsing. The power of good marketing, eh? There are so many other good parsing libraries out there. Parsec happened to cure some known space-leaks in rival libraries about the time of its release (2000 or so), but the main reason it is popular is simply because it was distributed alongside ghc for a long time. Curiously enough, the complaint you make about parsec is exactly the same as the observation that drove the development of my own set of combinators - polyparse. But the concept of commitment to a partial parse (to prevent backtracking) was already present somewhat in Röjemo's applicative parsers way back in 1994. He had both `ap` and `apCut` (the naming of cut borrowed from Prolog I suppose). Space performance and the elimination of space leaks was totally his focus: he mentions being able to recompile the compiler itself in just 3Mb of RAM. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why GHC is written in Happy and not a monadic parser library?
On 3 Aug 2013, at 02:20, Jason Dagit wrote: Hi! Is there any specific reason why GHC is written in a parser GENERATOR (Happy) and not in MONADIC PARSER COMBINATOR (like parsec)? Is Happy faster / handles better errors / hase some great features or anything else? One reason is that it predates monadic parser libraries. I'm not entirely sure this is true. I reckon the development of applicative parser combinators (used in the implementation of the nhc12 compiler, way back in 1995 or so), is roughly contemporaneous with the development of Happy, and its use inside ghc. (I found a release note from Sept 1997 that said ghc had just converted its interface-file parser to use Happy.) Certainly table-driven parsers in non-functional languages go back a lot further, and functional combinator-based parsing was then the relative newcomer. As to why ghc switched to Happy, the literature of the time suggests that generated table-driven parsers were faster than combinator-based parsers. I'm not sure I have ever seen any performance figures to back that up however. And with the general improvement in performance of idiomatic Haskell over the last twenty years, I'd be interested to see a modern comparison. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Casting newtype to base type?
On 1 Jul 2013, at 16:07, Vlatko Basic wrote:
I had a (simplified) record
data P = P {
a :: String,
b :: String,
c :: IO String
} deriving (Show, Eq)
but to get automatic deriving of 'Show' and 'Eq' for 'data P' I have created
'newtype IOS' and its 'Show' and 'Eq' instances
newtype IOS = IO String
Not quite! That is a newtype'd String, not a newtype's (IO String). Try this:
newtype IOS = IOS (IO String)
but now when I try to set 'c' field in
return $ p {c = readFile path}
I get error
Couldn't match expected type `IOS' with actual type `IO String'
Use the newtype constructor to convert an IO String - IOS.
return $ p {c = IOS $ readFile path}
Regards,
Malcolm
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Overloaded record fields
On 28 Jun 2013, at 12:16, AntC wrote:
Thanks Simon, I'm a little puzzled what your worry is.
f r b = r.foo b
With dot-notation baked in (non-orthogonally), f would get the type
f :: (r { foo::Bool }) = r - Bool - Bool
With the orthogonal proposal, f is equivalent to
f r b = foo r b
I believe Simon's point is that, if dot is special, we can infer the Has type
above, even if the compiler is not currently aware of any actual record types
that contain a foo field. If dot is not special, then there *must* be some
record containing foo already in scope, otherwise you cannot infer that type
- you would get a name not in scope error instead.
The former case, where you can use a selector for a record that is not even
defined yet, leads to good library separation. The latter case couples
somewhat-polymorphic record selectors to actual definitions.
Unless you require the type signature to be explicit, instead of inferred.
(For the record, I deeply dislike making dot special, so I would personally go
for requiring the explicit type signature in this situation.)
Regards,
Malcolm
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] code to HTML
On 3 Jun 2013, at 20:38, Corentin Dupont wrote: I'd like to transform a .hs file into a .html file. The objective is that the .html file, when rendered, looks exactly the same that the .hs, with the exeption that every function in the code is a link to its haddock documentation. Is that possible? Programatica could do this ten years ago. But it sort-of fell by the wayside. Maybe there is some code still available that could be dusted off and revived: http://ogi.altocumulus.org/~hallgren/h2h.html Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GSoC proposal: Haskell AST-based refactoring and API upgrading tool
On 29 Apr 2013, at 07:00, Niklas Hambüchen wrote: I would like to propose the development of source code refactoring tool that operates on Haskell source code ASTs and lets you formulate rewrite rules written in Haskell. Seen this? http://www.haskell.org/haskellwiki/HaRe Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Prolog-style patterns
On 9 Apr 2013, at 14:46, Sturdy, Ian wrote: As far as the use of Eq goes, Eq is already enshrined in pattern matching by pattern matching against literals. Not true. Pattern-matching literals explicitly avoids any use of Eq. Demonstration: data Foo = Foo | Bar instance Eq Foo where _ == _ = True isFoo Foo = True isFoo Bar = False main = do print (isFoo Bar) print (Foo==Bar) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GSoC Project Proposal: Markdown support for Haddock
And cpphs strips C comments too. :-)
But seriously, John's use-case is the exact opposite of what you suggest. John
wants to keep the # inside the comment block. You suggest to remove the
comment-block altogether?
When I checked the example with cpphs, it turns out that the # line is
retained, generating a warning but not an error. I expect Gnu cpp is the
software that throws an error.
In my opinion, it is perfectly valid to have intentional preprocessor
directives inside Haskell comments.
Regards,
Malcolm
On 7 Apr 2013, at 22:12, Roman Cheplyaka wrote:
Looks like a bug in cpphs to me (CC'ing Malcolm). It should respect
comments. E.g. GNU cpp strips C comments.
Roman
* John MacFarlane j...@berkeley.edu [2013-04-05 16:04:32-0700]
I like markdown and use it all the time. While I acknowledge the
problems that have been pointed out, markdown has the advantage of being
easily readable as it is in the source document, and not looking like
markup.
But I do want to point out one problem with markdown as a format for
documentation in Haskell files. Consider:
module MyModule
{-
# Introduction
This is my module
-}
where
import System.Environment
main = getArgs = print
Now try to compile with -cpp, and you'll get an error because of the '#'
in column 1. '#' in column 1 is common in markdown (and even
indispensible for level 3+ headers).
One could work around this by disallowing level 3+ headers, by allowing
the headers to be indented, or by introducing new setext-like syntax for
level 3+ headers, but it is a problem for the idea of using a markdown
SUPERset.
John
+++ dag.odenh...@gmail.com [Apr 05 13 21:59 ]:
I forgot the mention the craziness with the *significant trailing
whitespace*.
On Fri, Apr 5, 2013 at 9:49 PM, [1]dag.odenh...@gmail.com
[2]dag.odenh...@gmail.com wrote:
Personally I think Markdown sucks, although perhaps less than Haddock
markup.
Still:
* No document meta data
* No code block meta data like language for syntax highlighting
* No tables
* No footnotes
* HTML fallback is insecure
* Confusing syntax (is it []() or ()[] for links?)
* Syntax that gets in the way (maybe I don't want *stars* emphasized)
* Above point leads to non-standard dialects like GitHub Markdown
(no, GitHub doesn't use markdown)
* Not extensible, leading to even more non-standard hacks and
work-arounds (GitHub Markdown, Pandoc Markdown, other Markdown
libraries have their own incompatible extensions)
* Not well suited for web input (e.g. four-space indentation for code
blocks), although not that important for Haddock
An important thing to note here is that no, Markdown has *not* won
because no one is actually using *Markdown*. They're using their own,
custom and incompatible dialects.
Only two of the above points apply to reStructuredText (web input and
syntax getting in the way), and those particular points don't apply to
Creole. Therefore I tend to advocate Creole for web applications and
reStructuredText for documents.
On Thu, Apr 4, 2013 at 6:49 PM, Johan Tibell
[3]johan.tib...@gmail.com wrote:
Hi all,
Haddock's current markup language leaves something to be desired
once
you want to write more serious documentation (e.g. several
paragraphs
of introductory text at the top of the module doc). Several features
are lacking (bold text, links that render as text instead of URLs,
inline HTML).
I suggest that we implement an alternative haddock syntax that's a
superset of Markdown. It's a superset in the sense that we still
want
to support linkifying Haskell identifiers, etc. Modules that want to
use the new syntax (which will probably be incompatible with the
current syntax) can set:
{-# HADDOCK Markdown #-}
on top of the source file.
Ticket: [4]http://trac.haskell.org/haddock/ticket/244
-- Johan
___
Haskell-Cafe mailing list
[5]Haskell-Cafe@haskell.org
[6]http://www.haskell.org/mailman/listinfo/haskell-cafe
References
1. mailto:dag.odenh...@gmail.com
2. mailto:dag.odenh...@gmail.com
3. mailto:johan.tib...@gmail.com
4. http://trac.haskell.org/haddock/ticket/244
5. mailto:Haskell-Cafe@haskell.org
6. 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
Re: [Haskell-cafe] GSoC Project Proposal: Markdown support for Haddock
On 8 Apr 2013, at 14:52, Roman Cheplyaka wrote:
In my opinion, it is perfectly valid to have intentional preprocessor
directives inside Haskell comments.
Could you give an example where this is useful?
... macro expansions inside the comments are rather exotic.
{- | Some module documentation.
#define WEBSITE
http://some.really.rather.long/and/tedious/URL/that_I_dont_want_to_type_too_often
You can find more information about Foo at WEBSITE/Foo and Bar at WEBSITE/Bar
-}
As you say, the #define could equally live outside the comment, but I don't see
why we should have an arbitrary restriction that it _must_ live outside the
comment. As you also say, the liberty to write whatever one wants inside a
comment feels important, and if that includes the intentional use of CPP, why
not?
Regards,
Malcolm
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Layout section of Haskell 2010 Language Report -- Notes 12
On 1 Apr 2013, at 01:21, Seth Lastname wrote:
Note 2 says, If the first token after a 'where' (say) is not indented more
than the enclosing layout context, then the block must be empty, so empty
braces are inserted.
It seems that, in Note 2, the first token necessarily refers to a lexeme
other than '{' (else it would not make sense),
Correct.
in which case a '{n}' token will have been inserted after 'where' (in the
example given in the note), yielding a nested context which is not indented
more than the enclosing layout context,
Yes, a {n} token has been inserted after the where.
No, it does not yield an incorrectly nested context, because L is the function
that decides whether to add to the context.
Looking only at the three equations for L that deal with the pseudo-token
{n}, including their side conditions, we see:
L ({n} : ts) (m : ms) = { : (L ts (n : m : ms)) if n m (Note 1)
L ({n} : ts) [] = { : (L ts [n]) if n 0 (Note 1)
L ({n} : ts) ms = { : } : (L ( n : ts) ms) (Note 2)
So, the third clause is triggered either when the nested-context stack (ms) is
empty and n is zero or negative; or when the context stack is non-empty and
nm. That is, we avoid creating a context stack that would be incorrect
(according to Note 1).
Regards,
Malcolm
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cabal install ghc-mod installs 3 years old version
Doesn't Cabal tend to install library packages under the .cabal folder? So blowing it away gets rid of the problematic ones. (And everything else.) On 25 Feb 2013, at 16:56, Brent Yorgey wrote: On Sun, Feb 24, 2013 at 02:33:55PM +, Niklas Hambüchen wrote: You are right, my ghc-7.4.2 was broken in ghc-pkg list; I fixed the problem by killing my .cabal folder (as so often). Surely you mean by killing your .ghc folder? I do not see what effect killing your .cabal folder could possibly have on broken packages. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: lazy-csv - the fastest and most space-efficient parser for CSV
There are lots of Haskell CSV parsers out there. Most have poor error-reporting, and do not scale to large inputs. I am pleased to announce an industrial-strength library that is robust, fast, space-efficient, lazy, and scales to gigantic inputs with no loss of performance. http://code.haskell.org/lazy-csv/ Downloads from Hackage: http://hackage.haskell.org/package/lazy-csv This library has been in industrial use for several years now, but this is the first public release. No doubt the API is not as general as it could be, but it already serves many purposes very well. I'm happy to receive bug reports and suggestions for improvements. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: lazy-csv - the fastest and most space-efficient parser for CSV
On 25 Feb 2013, at 11:14, Oliver Charles wrote: Obvious question: How does this compare to cassava? Especially cassava's Data.CSV.Incremental module? I specifically ask because you mention that it's It is lazier, faster, more space-efficient, and more flexible in its treatment of errors, than any other extant Haskell CSV library on Hackage but there is no mention of cassava in the website. Simple answer - I have never heard of cassava, and suspect it did not exist when I first did the benchmarking. I'd be happy to re-do my performance comparison, including cassava and any other recent-ish CSV libraries, if I can find them. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell] Call for Nominations: Haskell Prime language committee
Dear Haskell lovers, The Haskell Prime process for standardisation of new versions of the Haskell language is at something of an impasse. Since the Haskell 2010 Report was issued (at the end of 2009), there has been very little momentum to formalise existing extensions and generalisations, nor appetite to decide on whether any such extensions should be adopted as part of the core language standard. We therefore seek nominations for new members of the Haskell Prime language committee; people who have the enthusiasm to take this forward, as well as some relevant experience. If you think you would like to contribute, please nominate yourself by sending a email to haskell-2011-commit...@haskell.org describing who you are, and what you think the committee might hope to achieve. The address above is populated by the existing committee members, but is now (temporarily) open to all during the nomination period. Nominations close in 3 weeks time, i.e. to be received by end of Sunday 24th February 2013. The process for deciding a new language committee is described at http://hackage.haskell.org/trac/haskell-prime/wiki/Committee Regards, Malcolm ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Call for Nominations: Haskell Prime language committee
Dear Haskell lovers, The Haskell Prime process for standardisation of new versions of the Haskell language is at something of an impasse. Since the Haskell 2010 Report was issued (at the end of 2009), there has been very little momentum to formalise existing extensions and generalisations, nor appetite to decide on whether any such extensions should be adopted as part of the core language standard. We therefore seek nominations for new members of the Haskell Prime language committee; people who have the enthusiasm to take this forward, as well as some relevant experience. If you think you would like to contribute, please nominate yourself by sending a email to haskell-2011-commit...@haskell.org describing who you are, and what you think the committee might hope to achieve. The address above is populated by the existing committee members, but is now (temporarily) open to all during the nomination period. Nominations close in 3 weeks time, i.e. to be received by end of Sunday 24th February 2013. The process for deciding a new language committee is described at http://hackage.haskell.org/trac/haskell-prime/wiki/Committee Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
[Haskell-cafe] Call for Nominations: Haskell Prime language committee
Dear Haskell lovers, The Haskell Prime process for standardisation of new versions of the Haskell language is at something of an impasse. Since the Haskell 2010 Report was issued (at the end of 2009), there has been very little momentum to formalise existing extensions and generalisations, nor appetite to decide on whether any such extensions should be adopted as part of the core language standard. We therefore seek nominations for new members of the Haskell Prime language committee; people who have the enthusiasm to take this forward, as well as some relevant experience. If you think you would like to contribute, please nominate yourself by sending a email to haskell-2011-commit...@haskell.org describing who you are, and what you think the committee might hope to achieve. The address above is populated by the existing committee members, but is now (temporarily) open to all during the nomination period. Nominations close in 3 weeks time, i.e. to be received by end of Sunday 24th February 2013. The process for deciding a new language committee is described at http://hackage.haskell.org/trac/haskell-prime/wiki/Committee Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Status of Haskell'?
On 28/12/2012, at 1:01, Ramana Kumar ram...@member.fsf.org wrote: On Wed, Dec 12, 2012 at 6:40 PM, Malcolm Wallace malcolm.wall...@me.com wrote: There is a mailing list for the members of the language committee: haskell-2011-commit...@haskell.org. Hi Malcolm, could you (or someone) help me out with a link to the archives (if any) for this list, and the listinfo page? http://www.haskell.org/mailman/listinfo/haskell-2011-committee But of course, those list archives are private. All substantive discussion is supposed to take place on the Haskell-prime list. The private committee list is only for administration, voting, choice of new committee members, etc. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: [Haskell-cafe] Hackage suggestion: Gather the list of the licenses of all dependencies of a package
On 13 Dec 2012, at 18:40, Michael Snoyman wrote: I'm not quite certain what to make of: If you have a commercial use for cpphs, and feel the terms of the (L)GPL are too onerous, you have the option of distributing unmodified binaries (only, not sources) under the terms of a different licence (see LICENCE-commercial). It seems like that's saying if you really want to, use the BSD license instead. But I'm not sure what the legal meaning of If you have a commercial use is. Malcolm: could you clarify what the meaning is? No, the LICENCE-commercial is not BSD. Read it more carefully. :-) So, I dual-licensed cpphs (which was originally only LGPL as a library, GPL as a binary), in response to a request from a developer (working for a company) who wished to use it as a library linked into their own software (rather than a standalone executable), but who was unable to convince his boss that LGPL would be acceptable. IIRC, the software was going to end up in some gadget to be sold (and therefore the code was being distributed, indirectly). The commercial licence I provided for him was intended to uphold the spirit of the LGPL, without going as far as BSD in laxity. So, if you simply want to use cpphs in a distributed product (but not modify it), it is very easy. The moment you want to distribute a modified version, you must abide by the LGPL, which to me essentially means that you contribute back your changes to the community. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage suggestion: Gather the list of the licenses of all dependencies of a package
On 13 Dec 2012, at 10:41, Petr P wrote: In particular, we can have a BSD package that depends on a LGPL package, and this is fine for FOSS developers. But for a commercial developer, this can be a serious issue that is not apparent until one examines *every* transitive dependency. This might a good time to remind everyone that every single program compiled by a standard GHC is linked against an LGPL library (the Gnu multi-precision integer library) - unless you take care first to build your own copy of the compiler against the integer-simple package instead of integer-gmp. As far as I know, there are no ready-packaged binary installers for GHC that avoid this LGPL'd dependency. http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes Just saying. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage suggestion: Gather the list of the licenses of all dependencies of a package
On 15 Dec 2012, at 16:54, Michael Snoyman wrote: I would strongly recommend reconsidering the licensing decision of cpphs. Even if the LICENSE-commercial is sufficient for non-source releases of software to be protected[1], it introduces a very high overhead for companies to need to analyze a brand new license. Many companies have already decided BSD3, MIT, and a number of other licenses are acceptable. Well, if a company is concerned enough to make an internal policy on open source licences at all, one might hope that they would perform due diligence on them too. For instance, the FSF have lawyers, and have done enough legal work to be able to classify 48 licences as both free and GPL-compatible, a further 39 licences as free but non-GPL-compatible, and 27 open source licences that are neither free nor GPL-compatible. This kind of understanding is what lawyers are supposed to be for. Making them look at another (short) licence is not really a big deal, especially when it closely resembles BSD, which they have already supposedly decided is good. My suspicion, though, is that most of the companies who even think about this question are small, do not have their own lawyers, and are making policy on the hoof, motivated purely by fear. I also suspect that they do not even have the resources to read the licence for each library in its entirety, to determine whether it is in fact BSD3 or MIT, as claimed, or whether someone has subtly altered it. Also, I think I could be pretty confident that there are many shipping products that contain genuine BSD-licensed code, but which do not comply with its terms. It could be very difficult to explain to a company, Yes, we use this software which says it's LGPL, but it has this special extra license which, if I'm reading it correctly, means you can't be sued, but since the author of the package wrote it himself, I can't really guarantee what its meaning would be in a court of law. Like I say, if someone claims the software to be BSD-licensed, someone has to read the licence text itself anyway, to determine whether the claim is true. Pretty much every copy of the BSD licence text differs anyway, at least by the insertion of the authors' names in various places, and sometimes there are varying numbers of clauses. Looking at the list of reverse dependencies[2], I see some pretty heavy hitters. Via haskell-src-exts[3] we end up with 75 more reverse dependencies. I'd also like to point out that cpphs is the only non-permissively-licensed dependency for a large number of packages. I'm glad that cpphs is widely used. I'm also glad that it remains free, and I disagree with you that its dual-licence model is non-permissive. I would like to encourage more Haskell developers to adopt free licensing. Don't be bullied by BSD evangelists! BSD is not the only way to a good citizen of the community! Your libraries can be delivered to clients as products, without you having to give up all rights in them! It's not like I'm saying to companies if you make money out of my code, you have to pay me a fee. All I'm saying, to everyone, is if you notice a bug in my code and fix it, tell me. This is fully compatible with allowing people to release my code to their clients inside products. I can give you more detailed information about my commercial experience privately. But I can tell you that, in the currently situation, I have created projects for clients for which Fay[4] would not be an option due to the cpphs licensing issue. If you are complaining about the crazy policies that many companies adopt about the use of free software within their business, then I have plenty of sympathy for that too. I know of one which has a policy of no use of open source code whatsoever, but runs thousands of linux servers. :-) Also, many companies with large numbers of software engineers on staff apparently prefer to buy crappy commercial products and pay handsomely for non-existent support, instead of running high-quality open-source software with neither initial nor ongoing costs, and where bugfixes are often available the same day as you report the bug. But hey ho. Corporate policy is usually made by people with neither technical nor legal expertise. As regards cpphs, if you don't want to use it because of its licences, that is your choice. You can always use some other implementation of the C pre-processor if you wish. GHC has always refused to distribute cpphs, on the basis of its GPL licence, and instead chose to distribute GNU's gcc on Windows. :-) (I hope you see the irony!) Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Status of Haskell'?
I confess that I have not had enough free time in the last two years to have been a good chair for the language committee. (Using Haskell in the real world is just too absorbing!) I think the next chair should probably be an academic, who may have more incentive to spend effort on formalisation of the language design process than us industrial types. (At work, if we want a language extension, we just go ahead and implement it - job done.) There is a mailing list for the members of the language committee: haskell-2011-commit...@haskell.org. It has not seen any activity since 3 messages in October 2011, and prior to that, a thread of 13 messages in Nov/December 2010. Both of those threads were largely about the vanishingly small number of proposals to be decided upon, and whether to issue a new Report (the answer being no on both occasions). So, given that there are a few people who have expressed interest in reviving the language formalisation process, perhaps we should hold nominations for a new committee, in the spirit of the method outlined on the wiki page: http://hackage.haskell.org/trac/haskell-prime/wiki/Committee Please send nominations to haskell-2011-commit...@haskell.org, summarising your interest and experience. The existing committee will (I hope) make some decision on how to proceed, in early January 2013. Regards, Malcolm On 12 Dec 2012, at 02:42, Ramana Kumar wrote: Dear Malcolm, What is the current status of Haskell Prime, as far as you know? (Is there a better way to reach the Haskell Prime committee than just emailing the chair?) We have a few volunteers here looking to keep Haskell Prime moving forward, and Simon suggested following the tracks of earlier pioneers and resuming/joining where they left off. Cheers, Ramana ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: [Haskell-cafe] Is it possible to have constant-space JSON decoding?
See also the incremental XML parser in HaXml, described in Partial parsing: combining choice with commitment, IFL 2006. It has constant space usage (for some patterns of usage), even with extremely large inputs. http://www.google.co.uk/url?sa=trct=jq=malcolm+wallace+partial+parsingsource=webcd=2ved=0CEEQFjABurl=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.135.7512%26rep%3Drep1%26type%3Dpdfei=Db3BUNmiOsfS4QTAkoDYAwusg=AFQjCNHHywUCvaFv8eBoQ-x9jj4GOMHo2w On 5 Dec 2012, at 05:37, Johan Tibell wrote: Hi Oleg, On Tue, Dec 4, 2012 at 9:13 PM, o...@okmij.org wrote: I am doing, for several months, constant-space processing of large XML files using iteratees. The file contains many XML elements (which are a bit complex than a number). An element can be processed independently. After the parser finished with one element, and dumped the related data, the processing of the next element starts anew, so to speak. No significant state is accumulated for the overall parsing sans the counters of processed and bad elements, for statistics. XML is somewhat like JSON, only more complex: an XML parser has to deal with namespaces, parsed entities, CDATA sections and the other interesting stuff. Therefore, I'm quite sure there should not be fundamental problems in constant-space parsing of JSON. BTW, the parser itself is described there http://okmij.org/ftp/Streams.html#xml It certainly is possible (using a SAX style parser). What you can't have (I think) is a function: decode :: FromJSON a = ByteString - Maybe a and constant-memory parsing at the same time. The return type here says that we will return Nothing if parsing fails. We can only do so after looking at the whole input (otherwise how would we know if it's malformed). The use cases aeson was designed for (which I bet is the majority use case) is parsing smaller messages sent over the network (i.e. in web service APIs) so this is the only mode of parsing it supplies. -- Johan ___ 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: [GHC] #7473: getModificationTime gives only second-level resolution
Replying by email, since my account on the trac is blocked. Open Shake implements the finer resolution timestamps needed using the Win32 API. You may want to copy/adapt the code from there: http://hackage.haskell.org/packages/archive/shake/0.3.7/doc/html/src/Development-Shake-FileTime.html#line-69 Regards, Malcolm On 3 Dec 2012, at 13:01, GHC wrote: #7473: getModificationTime gives only second-level resolution -+-- The `System.Directory.getModificationTime` function only returns time with second-level granularity. This is no good for applications like `ghc --make` where we need to compare file timestamps. The fix should be simple, here's a patch (compiles but not tested) that should fix it for Unix, for Windows we will need a different fix, probably using the Win32 API directly, rather than the mingw C api. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [Haskell-cafe] tplot (out of memory)
For the record, it turned out that the key difference between the linux machines was the fonts packages installed via RPM. The strace utility told me that the crash happened shortly after cairo/pango attempted (and failed) to open some font configuration files. After installing some of the X11 font packages (and some others too), the crash went away. On 18 Oct 2012, at 09:55, malcolm.wallace wrote: Did you ever solve this? I have a similar message ( user error (out of memory) ) arising from a different app (not tplot) that uses the Haskell Chart library (and cairo underneath). On some linux machines, it crashes, on others it works fine. I can find no environment differences between the machines. The app does not use a lot of memory, and the machine is not running out of physical or swap. Regards, Malcolm On 04 Sep, 2012,at 04:01 PM, Eugene Kirpichov ekirpic...@gmail.com wrote: Hi Manish, Please provide the input file, I'll debug this. On Mon, Sep 3, 2012 at 1:06 PM, Manish Trivedi trivman...@gmail.com wrote: Hi, I am running into a weird out of memory issue. While running timeplot over an input file having ~800 rows. From below provided info, seems like machine has enough ram (1849MB). Please let me know if anyone has pointers. # free -m total used free shared buffers cached Mem: 3825 1975 1849 0 13 71 -/+ buffers/cache: 1891 1934 Swap: 4031 111 3920 #time tplot -o out.png -or 1024x768 -k 'CurrentPerHour' 'lines' -k 'RequiredPerHour' 'lines' -if adgroup_delivery_chart.input -tf 'date %Y-%m-%d %H:%M:%OS' tplot: user error (out of memory) real 0m0.026s user 0m0.018s sys 0m0.008s -Manish ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Eugene Kirpichov http://www.linkedin.com/in/eugenekirpichov ___ 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] Survey: What are the more common Haskell IDEs in use ?
At my workplace, most people who code in Haskell use MS Visual Studio as their Haskell IDE. :-) But they don't read Haskell-cafe... Regards, Malcolm On 24 Nov 2012, at 07:28, Dan wrote: Because I see there are many preferences on what IDE to use for Haskell I've created a quick survey on this topic. (if any is missing, etc) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] HaXml
On 9 Nov 2012, at 23:04, Michael Mossey wrote: Couldn't match expected type Text.XML.HaXml.Types.QName with actual type String. Poking around, I found this webpage describing an issue with a change to HaXml that happened after version 1.20.2: http://stackoverflow.com/questions/7501037/how-to-make-haxml-and-drift-work-with-ghc-7-0-3 This web page suggests that I need to install HaXml-1.20.2 to use it with the current version of the DtdToHaskell utility. For the record (and future web searches), this issue with HaXml (DtdToHaskell generating non-compilable code) was fixed in version 1.23 onwards, from around April 2012. Regards, Malcolm ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
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] 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] Either Monad and Laziness
On 12 Sep 2012, at 16:04, Eric Velten de Melo wrote: The behaviour I want to achieve is like this: I want the program when compiled to read from a file, parsing the PGM and at the same time apply transformations to the entries as they are read and write them back to another PGM file. Such problems are the main motivation for iteratees, conduits, pipes, etc. Every such library contains procedures for doing exactly what you want. It would be really awesome, though, if it were possible to use a parser written in Parsec with this, in the spirit of avoiding code rewriting and enhancing expressivity and abstraction. The polyparse library on Hackage is another parser combinator framework that allows lazy incremental parsing. http://hackage.haskell.org/package/polyparse A PDF paper/tutorial is here: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.118.1754rep=rep1type=pdf Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] COBOL-85 parser, anyone?
Ralf Laemmel would probably be the world's foremost expert in parsing and analysing Cobol using functional languages. Try contacting him directly at uni-koblenz.de Some of his relevant papers: http://homepages.cwi.nl/~ralf/padl03/ http://homepages.cwi.nl/~ralf/ctp/ On 20 Jul 2012, at 10:08, Richard O'Keefe wrote: Does anyone have a parser for COBOL-85 written in Haskell, or written using some freely available tool that communicates easily with Haskell? I don't need it _yet_, but I'm talking with someone who is trying to get access to a real legacy site with a bunch of, well, basically COBOL 85, but there are extensions... We're not talking about transformation at this stage, just analysis. I could probably hack up the extensions given a place to start. I've found some papers and more dead links than I care for and lots of mention of ASF+SDF which is apparently superseded by Rascal. ___ 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] Performance with do notation, mwc-random and unboxed vector
On 11 Jun 2012, at 10:38, Dmitry Dzhus wrote: main = do g - create e' - VU.replicateM count $ standard g return () In all likelhood, ghc is spotting that the value e' is not used, and that there are no side-effects, so it does not do anything at runtime. If you expand the action argument to replicateM, such that it uses do-notation instead, perhaps ghc can no longer prove the lack of side-effects, and so actually runs the computation before throwing away its result. When writing toy benchmarks in a lazy language, it is always important to understand to what extent your program _uses_ the data from a generator, or you are bound to get misleading performance measurements. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Strange behavior in GHC-compiled code
Unless you show us the code, any answers will be guesses in the dark. Does your program use unsafePerformIO unsafely perhaps? Or a version of a library that happens to have a known bug? On 25/05/2012, at 14:33, Mark Conway Wirt markcw...@gmail.com wrote: I have a piece of Haskell code that's been laying around on my computer for about a year, and I recently decided to dust it off. The problem is that it used to work fine, but in the interim (in which I both upgraded OS versions/GHC versions and went from 32 bit to 64 bit) the code stopped working reliably. [...] Any guidance/pointers would be very much appreciated. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Generalizing (++) for monoids instead of using ()
On 4 May 2012, at 10:02, Alberto G. Corona wrote: Restrict (++) String - String - String that locally would restrict the type within the module. import qualified Prelude import Prelude hiding ((++)) (++) :: String - String - String (++) = Prelude.(++) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: What is a punctuation character?
no purpose to a completely overlapping category unless it is intended to relate to an earlier standard (say Haskell 1.4). I believe all Haskell Reports, even since 1.0, have specified that the language uses Unicode. If it helps to bring perspective to this discussion, it is my impression that the initial designers of Haskell did not know very much about Unicode, but wanted to avoid the trap of being stuck with ASCII-only, and so decided to reference whatever Unicode does, as the most obvious and unambiguous way of not having to think about (or specify) these lexical issues themselves. One of the underlying questions is: what is the concrete syntax of a Unicode character in a Haskell program? Note that Chapter 2 goes to a great pain to specify the ASCII concrete syntax. In my view, the Haskell Report is deliberately agnostic on concrete syntax for Unicode, believing that to be outside the scope of a programming language standard, whilst entirely within the scope of the Unicode standards body. Seeing as there are (in practice) numerous concrete representations of Unicode (UTF-8 and other encodings), it is largely up to individual compiler implementations which encodings they support for (a) source text, and (b) input/output at runtime. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: [Haskell-cafe] Impact of try on Parsec performance
On 3 Mar 2012, at 04:30, Omari Norman wrote: On the other hand, I notice that attoparsec and polyparse backtrack by default, and attoparsec claims to be faster than Parsec (I can't remember if polyparse makes this claim). In my benchmarks, polyparse has about the same performance as Parsec, when using the monadic style (possibly a very tiny bit faster). But polyparse is hugely, asymptotically, faster than Parsec when your parser is written in applicative style, your input text is large, and you consume the parse results lazily. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Error while installing new packages with GHC 7.4.1
On 29 Feb 2012, at 09:53, Antoras wrote: I updated my GHC version from 7.0.3 to 7.4.1. But after that GHC is unable to install some required packages. containers-0.4.2.1 (reinstall) changes: array-0.4.0.0 - 0.3.0.3 binary-0.5.1.0 (reinstall) changes: array-0.4.0.0 - 0.3.0.3 I believe you can't rebuild packages that shipped as part of your install of ghc, including containers and binary. The downgrade of the array package looks worrying too. I think array-0.4.0.0 is shipped with ghc-7.4.1, so where did the dependency on array-0.3.0.3 come from? Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Proposal: require spaces around the dot operator
-1. I agree with John. There is no point in fiddling with the dots, until we have real experience with a new records proposal (which can be implemented entirely without using dot, at least initially). Regards, Malcolm On 10 Feb 2012, at 03:14, John Meacham wrote: I mean, it is not worth worrying about the syntax until the extension has been implemented, used, and proven useful to begin with. Monads were in use well before the 'do' notation. Shaking out what the base primitives that make up a monad took a while to figure out. Even discussing syntax feels a little like a garage band discussing what the lighting of their stage show will look like before they learned to play their instruments. If we can implement it and test it without breaking existing code, why wouldn't we? It would mean more people can experiment with the feature because they wouldn't have to modify existing code much. So we will have more feedback and experience with how it interacts with other aspects of the language. John On Thu, Feb 9, 2012 at 6:41 PM, Greg Weber g...@gregweber.info wrote: There are 2 compelling reasons I know of to prefer dot for record access 1) follows an almost universal convention in modern programming languages 2) is consistent with using the dot to select functions from module name-spaces We can have a lot of fun bike-shedding about what operator we would prefer were these constraints not present. Personally I wouldn't care. However, I find either one of these 2 points reason enough to use the dot for record field access, and even without a better record system the second point is reason enough to not use dot for function composition. It is somewhat convenient to argue that it is too much work and discussion for something one is discussing against. The only point that should matter is how existing Haskell code is effected. On Thu, Feb 9, 2012 at 8:27 PM, Daniel Peebles pumpkin...@gmail.com wrote: I'm very happy to see all the work you're putting into the record discussion, but I'm struggling to see why people are fighting so hard to get the dot character in particular for field access. It seems like a huge amount of work and discussion for a tiny bit of syntactic convenience that we've only come to expect because of exposure to other very different languages. Is there some fundamental reason we couldn't settle for something like # (a valid operator, but we've already shown we're willing to throw that away in the MagicHash extension) or @ (only allowed in patterns for now)? Or we could even keep (#) as a valid operator and just have it mean category/lens composition. Thanks, Dan On Thu, Feb 9, 2012 at 9:11 PM, Greg Weber g...@gregweber.info wrote: Similar to proposal #20, which wants to remove it, but immediately less drastic, even though the long-term goal is the same. This helps clear the way for the usage of the unspaced dot as a record field selector as shown in proposal #129. After this proposal shows clear signs of moving forward I will add a proposal to support a unicode dot for function composition. After that we can all have a lively discussion about how to fully replace the ascii dot with an ascii alternative such as ~ or After that we can make the dot operator illegal by default. This has already been discussed as part of a records solution on the ghc-users mail list and documented here: http://hackage.haskell.org/trac/ghc/wiki/Records/DotOperator ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution
On 8/02/2012, at 14:16, Steve Horne sh006d3...@blueyonder.co.uk wrote: I haven't given a lot of thought to updates. I very much fail to see the point of replacing prefix function application with postfix dots, merely for field selection. There are already some imperfect, but adequate, solutions to the problem of global uniqueness of field names. But you now have mentioned what is really bothering me about this discussion: record updates are simply the most painful and least beautiful part of the Haskell syntax. Their verbosity is astonishing compared to the careful tenseness of every other language construct. If we could spend some effort on designing a decent notation for field updates, I think it would be altogether more likely to garner support than fiddling with dots. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FP activities and researchers in Warwickshire
Fun in the afternoon, a termly gathering of UK FP people, will be in Oxford on 28th Feb. http://sneezy.cs.nott.ac.uk/fun/ On 7/02/2012, at 18:32, Ivan Perez ivanperezdoming...@gmail.com wrote: Hello, I recently moved to Kenilworth, Warwickshire, UK, and I'd like to know if there are meetings, talks, or any FP-related activities going on around here. I contacted somebody at Warwick University but, from what I understood, their Formal Methods group doesn't exist as such any longer and they don't carry out any coordinated, regular events regarding FP anymore. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] strict version of Haskell - does it exist?
On 29 Jan 2012, at 22:25, Ertugrul Söylemez wrote: A strict-by-default Haskell comes with the implication that you can throw away most of the libraries, including the base library. So yes, a strict-by-default Haskell is very well possible, but the question is whether you actually want that. I wouldn't, because a lot of my code relies on the standard semantics. At work, we have a strict version of Haskell, and indeed we do not use the standard libraries, but have built up our own versions of the ones we use. However, our compiler is smart enough to transform and optimise the source code *as if* it were non-strict: it is only at runtime that things are evaluated strictly. This means that, in general, you can rely on the standard semantics to a surprisingly large extent. For instance, maybe (error foo) lines (Just hello\nworld) will succeed without calling error, just like in Haskell. Even if the final argument is supplied only at runtime, not statically, it will still do the right thing. However, the downside of being strict at runtime is frequently poorer performance. Stack overflows are common if you use explicit recursion: it is better to use higher-order functions (map, fold, until) that are implemented at a lower level in C (i.e. not directly using explicit recursion themselves). This is a good thing of course - thinking of data structures in the aggregate, rather than piecemeal. However, bulk operations do transform the entire data structure, not merely the fragments that are needed for the onward computation, so it can often be a net performance loss. The standard lazy computational paradigm of generate-and-test is therefore hideously expensive, on occasion. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [C][enums][newbie] What is natural Haskell representation of such enum?
2012/1/22 Данило Глинський abcz2.upr...@gmail.com
What is natural Haskell representation of such enum?
enum TypeMask
{
UNIT,
GAMEOBJECT,
CREATURE_OR_GAMEOBJECT = UNIT | GAMEOBJECT
};
I don't think that definition makes any sense in C, because UNIT is 0, so UNIT
| GAMEOBJECT == GAMEOBJECT == 1
Nevertheless, in Haskell something vaguely similar might be:
data TypeMask = UNIT | GAMEOBJECT | CREATURE_OR_GAMEOBJECT
// 1-byte flaged enum
enum TypeMask
{
// ...
UNIT= 0x0004,
GAMEOBJECT = 0x0008,
// ...
CREATURE_OR_GAMEOBJECT = UNIT | GAMEOBJECT
WORLDOBJECT = UNIT | PLAYER | GAMEOBJECT | DYNAMICOBJECT | CORPSE
// ... even more enum combos ...
};
import Data.Bits
data TypeMask = UNIT | GAMEOBJECT | CREATURE_OR_GAMEOBJECT | WORLDOBJECT
instance Enum TypeMask where
fromEnum UNIT = 0x4
fromEnum GAMEOBJECT = 0x8
fromEnum CREATURE_OR_GAMEOBJECT = fromEnum UNIT .|. fromEnum GAMEOBJECT
fromEnum WORLDOBJECT = fromEnum UNIT .|. fromEnum PLAYER .|. fromEnum
GAMEOBJECT
.|. fromEnum DYNAMICOBJECT .|. fromEnum CORPSE
toEnum 0x4 = UNIT
toEnum 0x8 = GAMEOBJECT
toEnum _ = error unspecified enumeration value of type TypeMask
isCreatureOrGameObject :: Int - Bool
isCreatureOrGameObject x = (x .|. fromEnum CREATURE_OR_GAMEOBJECT) /= 0
isWorldObject :: Int - Bool
isWorldObject x = (x .|. fromEnum WORLDOBJECT) /= 0
-- But fundamentally, this is not an idiomatic Haskell way of doing things.
-- The other posts in this thread have shown more Haskell-ish translations.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't install hspec
On 23 Jan 2012, at 07:01, Erik de Castro Lopo wrote: /tmp/hspec-0.9.04062/hspec-0.9.0/Setup.lhs:2:10: Could not find module `System' It is a member of the hidden package `haskell98-2.0.0.0'. In ghc-7.2, you cannot use the haskell98 package in conjunction with the base package. The simplest solution is the replace the import System with the appropriate replacement module in base: most probably System.Environment, System.Exit, or similar. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Posting etiquette, was Re: Records in Haskell
Sorry to pick on your post in particular Matthew, but I have been seeing a lot
of this on the Haskell lists lately.
I find it completely unreasonable for a reply to a very long post to quote the
entire text, only to add a single line at the bottom (or worse, embedded in the
middle somewhere). In this case, there are 7 pages of quotation before your
one-sentence contribution. (That is on my laptop. I dread to think how many
pages it represents on a smartphone screen...) Usually, if I need to scroll
even to the second page-worth of quotation and have still not found any new
text, I now just delete the post without reading it.
It is a failure to communicate well, on the part of the writer who values their
own time more highly than that of their intended readers. Even the
much-maligned top-posting style, as forced upon Outlook users (and as I am
doing right here), is preferable to the failure to trim, or to get to the point
quickly. My inbox has 1600 unread messages in it, and life is just too short.
So I offer this plea as a constructive social suggestion - if you want your
ideas to reach their intended audience, don't annoy them before they have even
seen what you want to say.
Regards,
Malcolm
On 15 Jan 2012, at 20:33, Matthew Farkas-Dyck wrote:
On 13/01/2012, Simon Peyton-Jones simo...@microsoft.com wrote:
Thanks to Greg for leading the records debate. I apologise that I
don't have enough bandwidth to make more than an occasional
contribution. Greg's new wiki page, and the discussion so far has
clarified my thinking, and this message tries to express that new
clarity. I put a conclusion at the end.
Simon
Overview
It has become clear that there are two elements to pretty much all the
proposals we have on the table. Suppose we have two types, 'S' and 'T',
both with a field 'f', and you want to select field 'f' from a record 'r'.
Somehow you have to disambiguate which 'f' you mean.
(Plan A) Disambiguate using qualified names. To select field f, say
(S.f r) or (T.f r) respectively.
(Plan B) Disambiguate using types. This approach usually implies
dot-notation.
If (r::S), then (r.f) uses the 'f' from 'S', and similarly if
(r::T).
Note that
* The Frege-derived records proposal (FDR), uses both (A) and (B)
http://hackage.haskell.org/trac/ghc/wiki/Records/NameSpacing
* The Simple Overloaded Record Fields (SORF) proposal uses only (B)
http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields
* The Type Directed Name Resolution proposal (TDNR) uses only (B)
http://hackage.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResolution
I know of no proposal that advocates only (A). It seems that we are agreed
that we must make use of types to disambigute common cases.
Complexities of (Plan B)
Proposal (Plan B) sounds innocent enough. But I promise you, it isn't.
There has ben some mention of the left-to-right bias of Frege type
inference engine; indeed the wohle explanation of which programs are
accepted and which are rejected, inherently involves an understanding
of the type inference algorithm. This is a Very Bad Thing when the
type inference algorithm gets complicated, and GHC's is certainly
complicated.
Here's an example:
type family F a b
data instance F Int [a] = Mk { f :: Int }
g :: F Int b - ()
h :: F a [Bool] - ()
k x = (g x, x.f, h x)
Consider type inference on k. Initially we know nothing about the
type of x.
* From the application (g x) we learn that x's type has
shape (F Int something).
* From the application (h x) we learn that x's type has
shape (F something else [Bool])
* Hence x's type must be (F Int [Bool])
* And hence, using the data family we can see which field
f is intended.
Notice that
a) Neither left to right nor right to left would suffice
b) There is significant interaction with type/data families
(and I can give you more examples with classes and GADTs)
c) In passing we note that it is totally unclear how (Plan A)
would deal with data families
This looks like a swamp. In a simple Hindley-Milner typed language
you might get away with some informal heuristics, but Haskell is far
too complicated.
Fortunately we know exactly what to do; it is described in some detail
in our paper Modular type inference with local assumptions
http://www.haskell.org/haskellwiki/Simonpj/Talk:OutsideIn
The trick is to *defer* all these decisions by generating *type constraints*
and solving them later. We express it like this:
G, r:t1 |- r.f : t2, (Has t1 f t2)
This says that if r is in scope with type t1, then (r.f) has type t2,
plus the constraint (Has t1 f t2), which we read as saying
Type t1 must have a field f of type t2
We gather up all the constraints and solve them. In solving them
we may figure out t1 from some *other* constraint (to the left or
right,
Re: Composition operator [was: Re: Records in Haskell]
On 12 Jan 2012, at 18:41, Evan Laforge wrote: Unicode dot (∘) would be optimal, since that's what it's for. Is ∘ (U+2218 RING OPERATOR)* in Prelude yet? We should propose that.** However, changing the composition operator from (.) will involve huge amounts of changes to source code. Indeed. It strikes me that it should be the _new_ feature that takes the new syntax, rather than stealing the old syntax and disrupting all the existing code that happily uses . for function composition. So, who is up for proposing centred dot as the new record-field syntax? Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] HaXml 1.13 - 1.22 upgrade
The extra parameter i is for information attached to each node of the tree. As you have correctly guessed, the parser fills in this field with positional information relating to the original source document, which is useful for instance if you are validating or checking the original document. When building new parts of a document, it is perfectly fine to attach noPos. You can alternatively replace all of the informational items in the tree, with for instance fmap (const ()) if you don't care about them. The information fields are useful for other purposes though, e.g. to hold the relevant xmlns namespace for subtrees; or to distinguish added/removed/modified subtrees in a diff-like viewer. Regards, Malcolm On 11/12/2011, at 14:56, Michael Orlitzky mich...@orlitzky.com wrote: On 12/11/2011 01:36 AM, Antoine Latter wrote: It looks like the function 'xmlParse' returns a value of type 'Document Posn', according to the API docs. I'm guessing the 'Posn' value is used to annotate the position in the source document a particular piece of XML came from, so you can report errors better. Since the pretty-printing functions ignore it, you can replace it with whatever you want, even with a value of a different type if you have a need to annotate the tree. Thanks, I was able to get it working after a little sleep/coffee. The migration guide says to replace all of the 'i' with () if you don't care about them, so I tried that, but it doesn't work in this case: the two 'i' in (CElem (Element i) i) have to match. The only way I see to construct a Posn is with noPos, so I stuck that in there. It's probably not correct, but it compiles and runs, so it's correct =) ___ 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] Tracing Prelude.read exceptions
I suggest switching from 'read' to a real parser that can give you proper error messages. I use Text.Parse from the polyparse package, which is designed to parse back exactly the format produced by derived Show instances. To derive the Parse class from your datatypes, the tool DRiFT is handy. 'runParser parse' will give you Either String a, where the string contains any error message. Regards, Malcolm On 11/12/2011, at 18:19, dokondr doko...@gmail.com wrote: Hi, I got quite used to a sequence providing simple data persistence : 1) Store my data to a file: writeFile fileName (show someData) 2) Some time later read this data back: line - readFile fileName let someData = read line :: SomeDataType Having this done hundreds of times I now got stuck with step 2) trying to read moderately complex structure back. I get read exception in run-time: fromList *** Exception: Prelude.read: no parse I have checked and rechecked my types, data files, etc. - and still no idea. So my question: Is there any way to trace Prelude.read exceptions to see exactly on what data element read fails in run-time? Thanks! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Does anyone maintain trac.haskell.org?
The community Trac hosting server isn't sending email, which Trac requires. I've submitted several tickets to supp...@community.haskell.org but gotten no response. Does anyone maintain that server anymore? Had the same problem in July. Raised a ticket etc. I don't think there is anyone actually responsible for the trac server. Indeed, the community server (including trac) is administered on a volunteer best-effort basis. Unfortunately, we do not have sufficient trac-admin expertise on the volunteer team in order to know what is wrong here, or to fix it. If there is a trac expert out there who could help us diagnose and fix the problem, we would be glad of their aid. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHCi and Cairo on Windows
On Windows, it is necessary to add to your PATH variable the bin directory where the gtk+ DLL lives. Note, this is the C DLL, not the Haskell one produced by gtk2hs. For instance, on my machine the relevant directory is C:\workspace\ext\gtk+-2.20\bin. It is quite likely different on yours. On 5/12/2011, at 8:23, smelt...@eecs.oregonstate.edu wrote: In effort to keep my work cross-platform, I am trying to get GHCi and Cairo working together nicely on Windows (as a back-end to Diagrams, if it matters.) When loading the library in GHCi I get the following error: Loading package cairo-0.12.2 ... linking ... ghc: unable to load package `cairo-0.12.2' I am able to build, link, and execute successfully using 'ghc --make' so I know the libraries are installed correctly. I'm using GHC as packaged in the most recent version of the Haskell Platform and the most recent all-in-one Windows bundle of GTK. I've seen quite similar errors reported months ago with no apparent solution. Any help would be appreciated! --Karl ___ 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] Hackage down!
And, amusingly, http://downforeveryoneorjustme.com/ is also down, having exceeded its Google App Engine quota. [ But the similarly named .org site still works, and confirms that hackage is down. ] Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Superset of Haddock and Markdown
On 20 Nov 2011, at 22:20, Ivan Lazar Miljenovic wrote: On 21 November 2011 03:19, David Fox dds...@gmail.com wrote: On Fri, Nov 18, 2011 at 1:10 AM, Ertugrul Soeylemez e...@ertes.de wrote: Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: Wasn't there talk at one stage of integrating pandoc into haddock? I wouldn't mind Haddock depending on Pandoc, at least optionally (-fmarkdown-comments). Taking this to its conclusion you could easily have syntax-highlighted code examples in Haddock documentations and allow alternative output formats. I'm not sure the pandoc license (GPL) is compatible with the GHC license. Do you mean because GHC ships with a Haddock binary? GHC also ships with a GPL'd gcc binary, on at least some platforms. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Package documentation complaints -- and a suggestion
The problem isn't social pressure to be stable, it's the ambiguity of what stable means. If Hackage 2 institutes a policy whereby things claiming to be stable are treated better, then stable is likely to become the new experimental. I'd say, rather than rely on social agreement on what terms mean, let's just collect lots of automated metrics, and present them as extra information on the hackage pages. At work, we have all modules scored by hlint metrics, and doclint metrics. (Doclint complains about modules without a module header comment, and type signatures without haddock comments.) We count infractions and have a top ten hall-of-shame, as well as placing the scores in the module documentation itself. We also have a fingerprint for every release (basically the API type signatures), and the size of fingerprint-diffs between releases is a rough measure of API-churn. Some of these measures are designed to place social pressure on authors to improve their code/documentation, but they have a dual role in allowing users to get a feel for the quality of the code they are using, without imposing any external hierarchy on which metrics are more important in any given situation. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fwd: how to increase the stack size
when I am running the program in my terminal on ubuntu its showing me GHC stack-space overflow: current limit is 536870912 bytes. Use the `-Ksize' option to increase it. how can i increase the stack sizePlz help me out Others have explained how to Use the `-Ksize' option, However, those explanations did not take account of the fact that ghc now ignores +RTS options by default at runtime. You need to compile the program with an extra option -rtsopts, if you want the +RTS options to work at runtime. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is it possible to represent such polymorphism?
Although I still wonder why something so simple in C++ is actually more verbose and requires less known features in Haskell...What was the design intent to disallow simple overloading? The simple C++ overloading you want to add to Haskell, is in fact rather semantically complex, and it leads to undecidability of the type system. The inherent formal complexity here suggests that this form of overloading is highly unlikely to be the correct solution in practice to the problem you are trying to solve. And even if it were a technically correct solution, it is likely to be unmaintainable and fragile to code changes. There is a high probability that a more-formally-tractable solution exists, and that using it will improve your understanding of the problem at hand, and make your code more regular and robust to change. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [GHC] #5509: quotes pretty-printer not working as comments specify
From compiler/utils/Outputable.lhs
{{{
-- quotes encloses something in single quotes...
-- but it omits them if the thing ends in a single quote
-- so that we don't get `foo''. Instead we just have foo'.
quotes d = SDoc $ \sty -
let pp_d = runSDoc d sty in
case show pp_d of
('\'' : _) - pp_d
_other - Pretty.quotes pp_d
}}}
This implementation does not match the comment - the code is checking for
a leading single-quote, not for a trailing one.
I was bitten by this bug the other day. The code I was modifying had values
called
foo
foo'
foo''
and a type error message told me there was a fault with
`foo''
so I ended up looking in entirely the wrong place for five minutes.
Regards,
Malcolm
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [Haskell-cafe] mapM is supralinear?
On 26 Sep 2011, at 23:14, Arseniy Alekseyev wrote: Garbage collection takes amortized O(1) per allocation, doesn't it? No. For Mark-Sweep GC, the cost is proportional to (H+R) / (H-R) where H is the total heap size R is the reachable (i.e. live) heap This formula amortises the cost of a collection over the amount of free space recovered. For two-space copying collection, the cost is proportional to R / ((H/2)-R) In both cases, as R approaches H (or H/2), the cost of GC becomes rather large. So in essence, the more live data you have, the more GC will cost. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] mapM is supralinear?
On 27 Sep 2011, at 11:23, Arseniy Alekseyev wrote: Malcolm, one should amortize the cost of the collection over the amount of free space allocated rather than recovered They are the same thing. You can only allocate from the space that has been recovered. It is true that generational GC has a nursery area of largely constant size, which is always used for fresh allocation, but that is usually considered an optimisation (albeit a considerable one), which does not fundamentally change the underlying asymptotic costs of the major collections. When you have large heap residency, the proportion of time spent in GC increases. (there are cases when no space is recovered, would you call the GC cost infinite then?). Indeed I would. When that happens, usually the program aborts without completing its computation, so the computation is infinitely delayed. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Please apply the comparison function given to nubBy to elements of the list in the order in which they occur in the list.
If this is a _proposal_ to change ghc's non-Report-compatible Data.List implementation to match the behaviour of the Report implementation, then count me as a +1. I think an important convention when it comes to higher order functions on lists is that to the extent which is possible, the function parameters take elements from the list (or things computed from those) in the order in which they occur in the original list. This seems like an entirely reasonable principle. I'm aware that the Report (strangely!) explicitly leaves the behaviour of nubBy unspecified for functions which are not equivalence relations, but the behaviour given by the Report implementation (the opposite of the current behaviour in GHC) is useful and desirable nonetheless. I notice that the Haskell'98 Report gives a sample implementation, but the Haskell'2010 Report does not. I wonder if this is a regression, since in days of yore, the Report implementation was treated as a gold standard reference for questions about function semantics, strictness and so forth. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: [Haskell-cafe] Categorized Weaknesses from the State of Haskell 2011 Survey
On 13 Sep 2011, at 18:59, Michael Orlitzky wrote: Malcolm Wallace and Colin Runciman's ICFP99 paper functioned well as a tutorial for HaXml when I used it - maybe it is a bit out of date now? HaXml is hardly a dire case. The paper is out-of-date, so it's worse than useless: you'll waste your time figuring out that it's wrong, and you still won't know how to do anything. There's not one single example anywhere that just shows you how to read or write a damned XML file. If there were anything approaching a physical manifestation of HaXml, I would've strangled it. I am the first to admit that HaXml's documentation is not as good as it could be, and I am sorry that you have had a bad experience. One thing I am puzzled about, is just how extremely difficult it must be, to click on Detailed documentation of the HaXml APIs from the HaXml homepage, look for a moment until you see Text.XML.HaXml.Parse in the list of modules, click on it, and find, right at the top of the page, a function that parses a String into an XML document tree. It is absolutely true that finding the reverse conversion (XML tree to String) is more obscure, being either the two-stage process of first using Text.XML.HaXml.Pretty to convert to a Doc, then Text.PrettyPrint.HughesPJ to render to a String; or alternatively the one-shot conversion in Text.XML.HaXml.Verbatim. Neither module name is as clear as it should be for a beginner, but I can't think of better ones. Plus, it requires some knowledge of the ecosystem, for instance that pretty-printing is a common technique for producing textual output. In fact, my wish as a library author would be: please tell me what you, as a beginner to this library, would like to do with it when you first pick it up? Then perhaps I could write a tutorial that answers the questions people actually ask, and tells them how to get the stuff done that they want to do. I have tried writing documentation, but it seems that people do not know how to find, or use it. Navigating an API you do not know is hard. I'd like to signpost it better. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: integer-simple
I notice that ghci is loading integer-simple before loading base. This at least explains why it cannot find a symbol from the base package - it hasn't been loaded yet. So the question is why does integer-simple use any function from the base package at all? I'm fairly sure that the dependency graph is such that it should not. On 30/07/2011, at 22:37, Chris Dornan ch...@chrisdornan.com wrote: Hi All, I thought I may as well try the same experiment 7.2.1-RC1 on completely different hardware (a network v-server running CentOS 5 with ghc-6.12.3 installed) and indeed: ghci GHCi, version 7.2.0.20110728: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-simple ... linking ... ghc: /usr/local/ghc/7.2.0.20110728/lib/ghc-7.2.0.20110728/integer-simple-0.1.0.0/HSinteger-simple-0.1.0.0.o: unknown symbol `base_ControlziExceptionziBase_patError_info' ghc: unable to load package `integer-simple' This has to be the way I am configuring the build – as y’all can see I am configuring with a non-standard prefix, but otherwise it is a case of a clean build from virginal sources with the appended build.mk. I think I am going to have to start looking at the failure mechanism… Chris snipety-snip # - # A Sample build.mk # # Uncomment one of the following BuildFlavour settings to get the desired # overall build type, and then tweak the options in the relevant section # below. # Uncomment one of these to select a build profile below: # Full build with max optimisation (slow build) #BuildFlavour = perf # Fastest build (libs unoptimised): BuildFlavour = quickest # Fast build with optimised libraries: #BuildFlavour = quick # Profile the stage2 compiler: #BuildFlavour = prof # A development build, working on the stage 1 compiler: #BuildFlavour = devel1 # A development build, working on the stage 2 compiler: #BuildFlavour = devel2 GhcLibWays = v # 1. A Performance/Distribution build ifeq $(BuildFlavour) perf # perf matches the default settings, repeated here for comparison: SRC_HC_OPTS = -O -H64m GhcStage1HcOpts = -O -fasm GhcStage2HcOpts = -O2 -fasm GhcHcOpts = -Rghc-timing GhcLibHcOpts= -O2 -XGenerics GhcLibWays += p ifeq $(PlatformSupportsSharedLibs) YES GhcLibWays += dyn endif endif # A Fast build -- ifeq $(BuildFlavour) quickest SRC_HC_OPTS= -H64m -O0 -fasm GhcStage1HcOpts= -O -fasm GhcStage2HcOpts= -O0 -fasm GhcLibHcOpts = -O0 -fasm SplitObjs = NO HADDOCK_DOCS = NO BUILD_DOCBOOK_HTML = NO BUILD_DOCBOOK_PS = NO BUILD_DOCBOOK_PDF = NO endif # A Fast build with optimised libs -- ifeq $(BuildFlavour) quick SRC_HC_OPTS= -H64m -O0 -fasm GhcStage1HcOpts= -O -fasm GhcStage2HcOpts= -O0 -fasm GhcLibHcOpts = -O -fasm SplitObjs = NO HADDOCK_DOCS = NO BUILD_DOCBOOK_HTML = NO BUILD_DOCBOOK_PS = NO BUILD_DOCBOOK_PDF = NO endif # Profile the stage2 compiler --- ifeq $(BuildFlavour) prof SRC_HC_OPTS= -H64m -O0 -fasm GhcStage1HcOpts= -O -fasm GhcStage2HcOpts= -O -fasm GhcLibHcOpts = -O -fasm GhcLibWays += p GhcProfiled= YES SplitObjs = NO HADDOCK_DOCS = NO BUILD_DOCBOOK_HTML = NO BUILD_DOCBOOK_PS = NO BUILD_DOCBOOK_PDF = NO endif # A Development build (stage 1) - ifeq $(BuildFlavour) devel1 SRC_HC_OPTS= -H64m -O -fasm GhcLibHcOpts = -O -dcore-lint GhcStage1HcOpts= -Rghc-timing -O0 -DDEBUG GhcStage2HcOpts= -Rghc-timing -O -fasm SplitObjs = NO HADDOCK_DOCS = NO BUILD_DOCBOOK_HTML = NO BUILD_DOCBOOK_PS = NO BUILD_DOCBOOK_PDF = NO endif # A Development build (stage 2) - ifeq $(BuildFlavour) devel2 SRC_HC_OPTS= -H64m -O -fasm GhcLibHcOpts = -O -dcore-lint GhcStage1HcOpts= -Rghc-timing -O -fasm GhcStage2HcOpts= -Rghc-timing -O0 -DDEBUG SplitObjs = NO HADDOCK_DOCS = NO BUILD_DOCBOOK_HTML = NO BUILD_DOCBOOK_PS = NO BUILD_DOCBOOK_PDF = NO endif #
Re: [Haskell-cafe] partial inheritance
On 19/07/2011, at 0:09, Patrick Browne patrick.bro...@dit.ie wrote: instance Bird Emperor where -- No fly method walk x y = y instance Penguin Emperor where -- How can I override the walk method in the instance Penguin? -- walk x y = x Why would you want to override the walk method for Emperor? It already has one due to being a Bird. How could you possibly distinguish an Emperor walking as a Bird from an Emperor walking as a Penguin? Why would it be desirable? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Inconsistent trailing comma in export list and record syntax
That just shifts the problem, I think? Now you can no longer comment out the
first line.
If you are using to-end-of-line comments with --, then the likelihood of
noticing a leading ( or { on the line being commented, is much greater than the
likelihood of noticing a trailing comma on the end of the line _before_ the one
you are commenting.
Regards,
Malcolm
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Time
On 2 Jul 2011, at 22:13, Yitzchak Gale wrote: [1]http://hackage.haskell.org/package/timezone-series [2]http://hackage.haskell.org/package/timezone-olson I'd just like to add that these timezone packages are fantastic. They are extremely useful if you need accurate conversion between wall-clock times in different locations of the world, at arbitrary dates in the past or future, taking account of the differing moments at which daylight savings times take effect and so on. [At least one financial institution is now using them to avoid losing money that might otherwise happen due to confusion over the exact time of expiry of contracts.] Thanks Yitz. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Proposal: fix simple pattern binding and declaration group
Once you guys have reached consensus on appropriate revised wording for this issue, I'll happily apply the changes to the Haskell 2012 Report as a bugfix. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: [Haskell-cafe] Patterns for processing large but finite streams
Sure you can. runningAverage :: Int - [Double] - [Double] runningAverage n xs = let chunk = take n xs in (sum chunk / length chunk) : runningAverage (tail xs) Lazy lists are absolutely ideal for this purpose. Regards, Malcolm On 1 Jul 2011, at 07:33, Eugene Kirpichov wrote: Plain old lazy lists do not allow me to combine multiple concurrent computations, e.g. I cannot define average from sum and length. 2011/7/1 Heinrich Apfelmus apfel...@quantentunnel.de: Eugene Kirpichov wrote: I'm rewriting timeplot to avoid holding the whole input in memory, and naturally a problem arises: How to represent large but finite streams and functions that process them, returning other streams or some kinds of aggregate values? Examples: * Adjacent differences of a stream of numbers * Given a stream of numbers with times, split it into buckets by time of given width and produce a stream of (bucket, 50%,75% and 90% quantiles in this bucket) * Sum a stream of numbers Is this, perhaps, what comonads are for? Or iteratees? Plain old lazy lists? Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Eugene Kirpichov Principal Engineer, Mirantis Inc. http://www.mirantis.com/ Editor, http://fprog.ru/ ___ 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] Alex Lexer Performance Issues
On 22 Jun 2011, at 15:53, Tristan Ravitch wrote: On Wed, Jun 22, 2011 at 07:48:40AM +0100, Stephen Tetley wrote: How fast is good old String rather than ByteString? For lexing, String is a good fit (cheap deconstruction at the head / front). For your particular case, maybe it loses due to the large file size, maybe it doesn't... I gave it a shot and the percentages in the profile are approximately the same (and peak memory usage was about double). I might end up having to parse the original binary format instead of the text format. There is an old folklore that lexing is usually the most expensive phase of any compiler-like traversal. 50% of time and space expended on lexing was pretty common twenty years ago. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Time
On 26 Jun 2011, at 01:53, Tony Morris wrote: Having only had a flirt with Data.Time previously, I assumed it would be robust like many other haskell libraries. If, by lack of robustness, you mean that you get runtime errors, then consider them bugs, and file them with the author/maintainer accordingly. If you mean something else, then being more specific might be useful. I know that the first time I looked seriously at Data.Time it seemed rather byzantine and labyrinthine. So many types! So few direct conversions between them! But when you think more closely about the domain, you realise that notions of time are not simple at all, and have varied widely over history, and the complexity of Data.Time only reflects the complexity of the domain. The old-time package is still available, and has a much simplified approach to time (which is evidently wrong in many places), but may better suit the needs of applications that only care to be approximate. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why aren't there anonymous sum types in Haskell?
On 21 Jun 2011, at 20:53, Elliot Stern wrote: A tuple is basically an anonymous product type. It's convenient to not have to spend the time making a named product type, because product types are so obviously useful. Is there any reason why Haskell doesn't have anonymous sum types? If there isn't some theoretical problem, is there any practical reason why they haven't been implemented? The Either type is the nearest Haskell comes to having anonymous sum types. If you are bothered because Either has a name and constructors, it does not take long before you realise that (,) has a name and a constructor too. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell *interpreter* on iPad? (Scheme and Ocaml are there)
On 18 Jun 2011, at 20:19, Jack Henahan wrote: but the dev would either be forced into Hugs, or they'd have to implement a more portable GHC. Does such a thing exist already? Just as a point of interest, the original nhc compiler was original written for an ARM architecture machine (Acorn Archimedes) with 2Mb of memory. Its successor, nhc98, can be bootstrapped from C sources, and always aimed to be as portable as possible. The project is largely unmaintained now, so there is likely to be some bitrot, but it would probably work OK with some effort. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: GHC and Haskell 98
As one of the few people who has habitually used Haskell'98 wherever possible, I favour plan A. As I recently discovered, in ghc 7 it is already very fragile to attempt to depend on both the base and haskell98 packages simultaneously. In most cases it simply doesn't work. Removing those few remaining cases where it happens to work by accident would be a good move. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: TypeFamilies vs. FunctionalDependencies type-level recursion
| Is there a policy that only a proposal's owner can modify the wiki | page? Or that you have to be a member of the Haskell' committee? I'm not sure. Malcolm Wallace is chair at the moment; I'm ccing him. I have no idea: I neither set up the wiki, nor do I have any interesting admin rights for it. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: How to install GhC on a Mac without registering?
On 10 Jun 2011, at 02:15, Manuel M T Chakravarty wrote: Anybody who is halfway serious about developing software on a Mac will have Xcode installed anyway. As the original poster clarified, the motivating use-case is education (specifically a class of 12-13 year olds.) These are not serious developers, but they have the potential to become serious. Placing unnecessary hurdles in their way will diminish the chances of their discovering Haskell to be a beautiful language. Having said that, I do think that Hugs (or maybe Helium) would be a more appropriate environment for teaching the basics to young students. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] location of IEEE Viz code ?
http://hackage.haskell.org/trac/PolyFunViz/wiki/IEEEVisCode talks about the code being available through darcs but I can't seem to put my hands on the http address I would need to pull the code. This is all relating to the paper, Huge Data but Small Programs: Visualization Design via Multiple Embedded DSLs. http://www.cs.york.ac.uk/fp/darcs/polyfunviz/ I can't recall the exact state of the repository; it is likely that some of it may no longer build with newer versions of ghc and/or OpenGL. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] SIGPLAN Programming Languages Software Award
Curious observation: Object languageType language OO (C++)functional functional (Haskell)logical It makes me wonder what comes next... To be more accurate, it was Functional Dependencies that introduced a logic programming language to the type level in Haskell. Type Families are an explicit attempt to use instead a functional language at the type level to mirror the functional language at the value level. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] SIGPLAN Programming Languages Software Award
More seriously, the influence of Haskell over F# (and even Python) is undoubted, but do you really think Haskell influenced Java Generics? (IMHO they were more inspired from C++ templates) (That is a question, not an assertion). Phil Wadler had a hand in designing both Haskell and Java Generics I believe. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type Constraints on Data Constructors
data Bar f a = Foo f = Bar {bar :: f a}
The class context on the data constructor buys you nothing extra in terms of
expressivity in the language. All it does is force you to repeat the context
on every function that uses the datatype. For this reason, the language
committee has decided that the feature will be removed in the next revision of
Haskell.
Regards,
Malcolm
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: How to install GhC on a Mac without registering?
On 6 Jun 2011, at 13:49, Lyndon Maydwell wrote: I would be fantastic if XCode wasn't a dependency. ... Not to detract at all from the work of the wonderful GHC and Haskell Platform contributors in any way. For me it would just make it that much easier to convince mac-using friends to give Haskell a try. The ghc team already bundle a copy of gcc in their Windows distribution, precisely because it can be fiddly to get a working copy of gcc for that platform otherwise. I wonder if they would consider the possibility of shipping gcc on Mac too? (There may be good reasons not to do that, but let's have the discussion.) Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] How to install GhC on a Mac without registering?
it won't be a pleasant choice to fork over a good chunk of money to Apple for the use of free software that they didn't develop. Whilst I acknowledge your painful situation, I'd like to rebut the idea that Apple stole someone else's free software and are selling it on. In fact, Apple developed, or paid for development of, quite a chunk of gcc: the objective-C front end and LLVM back end at least. In paying for XCode 4, you are getting a lot of proprietary code in addition to gcc. However, XCode 3 remains free to download, if you are a registered Apple developer. Registration is completely free of charge: http://developer.apple.com/programs/register/ You may find other links that make registration appear to cost $99 - but those are for the iOS or Mac developer programs, not the Apple developer program. The ones that charge money enable the right to publish software in the App Stores, which you do not need. I think you can download the free version of the XCode 3 installer, burn it to a DVD, and pass the DVD round your students. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to install GhC on a Mac without registering?
On 6 Jun 2011, at 13:49, Lyndon Maydwell wrote: I would be fantastic if XCode wasn't a dependency. ... Not to detract at all from the work of the wonderful GHC and Haskell Platform contributors in any way. For me it would just make it that much easier to convince mac-using friends to give Haskell a try. The ghc team already bundle a copy of gcc in their Windows distribution, precisely because it can be fiddly to get a working copy of gcc for that platform otherwise. I wonder if they would consider the possibility of shipping gcc on Mac too? (There may be good reasons not to do that, but let's have the discussion.) Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fwd: Abnormal behaviors when Using ghci
On 5/06/2011, at 13:12, 吴兴博 wux...@gmail.com wrote: 1) I'm using Haskell platform 2011.2 on windows (7). Every several days, ghci will crash with no messages. even when I'm just typing with text buffer, without an 'enter'. I got nothing after the crash, not even an exception code, don't even mention the core-dump. Do you have a single sign-on application installed (possibly TAM ESSO)? Weird though it sounds, we have experience of this Windows app randomly killing other processes, such that they just disappear with no apparent cause. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comment Syntax
-- followed by a symbol does not start a comment, thus for example, haddock declarations must begin with -- |, and not --|. What might --| mean, if not a comment? It doesn't seem possible to define it as an operator. GHCi, at least, allows it. Prelude let (--|) = (+) Prelude 1 --| 2 3 I believe the motivating example that persuaded the Language Committee to allow these symbols was -- which is not of course used anywhere in the standard libraries, but is an extremely nice symbol to have available in user code. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Matplotlib analog for Haskell?
I tried gnuplot: Demo.hs:25:18: Could not find module `Paths_gnuplot': Use -v to see a list of the files searched for. Failed, modules loaded: none. Prelude Graphics.Gnuplot.Simple Where to get `Paths_gnuplot': module? $ cd gnuplot-0.4.2 $ cabal install # this generates the Paths_gnuplot module $ ghci ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What's the advantage of writing Haskell this way?
instance (Monad m, MonadPlus m) = Monoid (Stream m a) where mempty = Chunks mempty mappend (Chunks xs) (Chunks ys) = Chunks (xs `mappend` ys) mappend _ _ = EOF Iteratee.hs:28:25: No instance for (Monoid (m a)) arising from a use of `mempty' There is a clue in the first part of the error message. Add the required instance as part of the predicate: instance (Monad m, MonadPlus m, Monoid (m a)) = Monoid (Stream m a) where ... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Maybe Int] sans Nothings
On 23 May 2011, at 17:20, michael rice wrote: What's the best way to end up with a list composed of only the Just values, no Nothings? Go to haskell.org/hoogle Type in [Maybe a] - [a] Click on first result. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Maybe Int] sans Nothings
On 23 May 2011, at 17:20, michael rice wrote: What's the best way to end up with a list composed of only the Just values, no Nothings? Alternatively, [ x | Just x - originals ] It also occurs to me that perhaps you still want the Just constructors. [ Just x | Just x - originals ] [ x | x@(Just _) - originals ] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cannot install base-4.3.1.0 package
On 15 May 2011, at 15:35, Immanuel Normann wrote: Why is it so complicated to install the base package? You cannot upgrade the base package that comes with ghc. It's a bad design, but there we go. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
