Re: [Haskell-cafe] ANN: Leksah 0.10.0
On 03/05/2011 02:49, Mathew de Detrich wrote: The best thing that Leksah can turn into (and something that Haskell desperately needs) is a Haskell version of Eclipse, because as Java has a weakness of being incredibly verbose (which Eclipse gets around with very easily, try coding Java in vim!!!), Haskell being a statically typed language has a weakness that in non trivial code, types can become convoluted and 'piping' functions together becoming complicated, something that a very smart code completion along with very powerful refactoring techniques that Eclipse has would do wonders. The one thing that Haskell is missing is a proper editing environment, and at least in my opinion one of the major things that a language needs to become widely adopted (unless its a first like perl,C was) is a proper editing environment that is approachable for newer people but remains powerful for advanced users There is a Haskell version of eclipse - eclipsefp. (Unless you specifically meant an Eclipse written in Haskell.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Do we need Monad fail (or MonadFail)?
Monads seem to use fail in one of three ways: -Regular monads leave it at the default definition of error -MonadPlus sometimes redefines it to mzero -IO redefines it to failIO Are there any other definitions of fail? If not, does the special case of IO really need a class-level definition, or could there be another way of dealing with failed pattern matches? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] Functor = Applicative = Monad
On 15/12/2010 14:31, Lennart Augustsson wrote: Yes, I think there should be a MonadFail distinct from MonadPlus. Some types, like IO, are not in MonadPlus, but have a special implementation of the fail method. Personally, I think fail should just be removed, but that would break existing code. The fail method was introduced for the wrong reasons (better error messages was the excuse). Which other monads (other than MonadPlus subclasses) define fail? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] Functor = Applicative = Monad
On 15/12/2010 04:01, Jonathan Geddes wrote: Fail can't just be removed. That would just break too much code. For example, I find myself writing code like the following: [a,b,c]- Just someList in place of let [a,b,c] = someList so that pattern match failure is lifted into the maybe monad (as long as I'm already in the maybe monad). I would like to see a MonadFail class, with one method 'fail', such that it is a compile-time error to try 'failable' pattern matches in a monad that is not an instance of MonadFail. --Jonathan Perhaps pattern match failures in a MonadPlus should bind to mzero - I believe that this is what your example and similar wish to achieve. I've updated http://haskell.org/haskellwiki/Functor-Applicative-Monad_Proposal to mention this. Does anyone know why fail and Pointed (in the paragraph This would eliminate...) aren't beginning a new paragraph? They are both preceded by a blank line in the wiki source. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] Functor = Applicative = Monad
On 15/12/2010 11:39, Lennart Augustsson wrote: Any refutable pattern match in do would force MonadFail (or MonadPlus if you prefer). So 1. (MonadFail m) = a - m a, \ a - return a 2. (MonadFail m) = m a, mfail ... 3. (MonadFail m) = Maybe a - m a, \ a - case a of Nothing - mfail ...; Just x - return x 4. (Monad m) = a - b - m a, \ a b - return a 5. (Monad m) = (a, b) - m a, \ (a, b) - return a As far as type inference and desugaring goes, it seems very little would have to be changed in an implementation. Is there a need for a MonadFail, as distinct from mzero? fail always seems to be defined as error in ordinary monads, and as mzero in MonadPlus (or left at the default error). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: GHC Out of memory
On 23/11/2010 17:08, Stefan Kersten wrote: i've also noticed this on linux and osx with ghc 6.12.1/6.12.3 and qtHaskell 1.1.3.5/1.1.4. possibly a memory leak in ghc --make? Should I report this as a bug? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: GHC Out of memory
On 23/11/2010 10:36, Christopher Done wrote: What version of GHC/qtHaskell? GHC 6.12.3, qtHaskell 1.1.4 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GHC Out of memory
I get an out-of-memory error about two thirds of the way through building qtHaskell. If I start again, the remaining modules are compiled successfully, although GHC's memory usage creeps up to about 1.5Gb by the time it's finished. Is there a memory leak? (Compiling on Win64 with 4Gb RAM.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Type-Directed Name Resolution for Records?
Two significant points which have emerged from the TDNR thread are: -The wiki page combines two orthogonal proposals: type-directed name resolution, which requires no special syntax, and the x.f syntax, which does not require TDNR. -Implementing both proposals may be a desired fix for the record system, but their use in the rest of the language is more controversial. I would therefore like to propose that TDNR (both parts thereof) be implemented for record accessors. In the fullness of time, the community may come to some consensus regarding the implementation of either or both of these features in the rest of the language. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Type Directed Name Resolution
Type-directed name resolution, as originally proposed for Haskell', has now been proposed for GHC. Obvious benefits of this are that conflicting function names from imported modules can be used without qualification (verbose) or pseudo-Hungarian renaming (verbose, and requires that you control the source, and perform the same renaming in all dependencies). This is important for both readability and programming in the large, particularly where records are concerned, as the duplicate name problem cannot be alleviated with typeclasses, and it is often desirable to have the same field names for many records in the same module. http://hackage.haskell.org/trac/ghc/ticket/4479 http://hackage.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResolution ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Type Directed Name Resolution
On 10/11/2010 13:52, Stephen Tetley wrote: Qualification is hardly verbose, idiomatically it tends to be two characters. Two characters is verbose by Haskell standards :-) Perhaps it't subjective, but if there's a click function to operate on a button, I find button.click much clearer that G.radioBtnClick button (as distinguished from M.radioBtnClick, which I imported from a different module). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Import proposal from Haskell'?
Type-directed name resolution was proposed by SPJ for Haskell', but not for GHC. Is there any particular process for importing tickets from Haskell' to GHC? http://hackage.haskell.org/trac/haskell-prime/ticket/129 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Current thinking on CompositionAsDot issue in haskell prime?
On 28/10/2010 10:15, Alexander Kjeldaas wrote: Hi haskellers. Reading through the Haskell Prime suggestions, one that caught my eye is the CompositionAsDot issue. I'm especially thinking of the Pro issue: * Paves the way for using . as the selection operator in improved record or module systems I think I recognize this issue from common lisp. Basically the code becomes verbose because accessor functions usually need to redundantly encode the name of the module or struct in its name. The alternative is to require users to import qualified, and that doesn't deal with the occasional intra-module collision. This is a typical large-software-system issue and it annoys me a little that Haskell seems to have inherited the problems from common lisp. I worry that in large systems, a very conservative coding standard is needed with quite verbose naming conventions as that's the only safe way to avoid these conflicts in a large system while allowing refactoring code etc. What is the current thinking on this issue? Thanks, Alexander TypeDirectedNameResolution would solve the problem you describe, and make Haskell a lot more suitable for real-world development (which is usually large-software-system, or at least must be capable of scaling to one). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Suggestions for an MSc Project?
Thanks! A lot of good ideas, although a GUI or database framework look like the most promising possibilities at the moment. I like the email/wiki idea, although it may not meet the University's academic requirements. (Would probably just be an email client running on top of a Wiki.) It may also require a decent GUI/persistence framework, so this would be a good project to bring both of these together! Any further comments from those with experience in GIU/databases on Haskell? On 05/07/2010 23:51, Jason Dagit wrote: Have you looked over Don's list of suggested summer of code projects? These were the suggested ones by Don: http://donsbot.wordpress.com/2010/04/01/the-8-most-important-haskell-org-gsoc-projects/ Here are the ones that were actually accepted: http://donsbot.wordpress.com/2010/04/26/the-7-haskell-projects-in-the-google-summer-of-code/ It seems like anything from the original list that isn't being tackled would count as an important contribution. Summer of Code is probably a smaller scope than your MSc, but that doesn't strike me as a problem. Typically in any software project, once you start working on it you can easily find room to expand it in useful directions. Similarly with the need for a research component. If you get creative you should be able to find some aspect that others haven't investigated. One thing I've been wanting lately is a good client / server, meeting scheduling / calendaring / time tracking software. Something along the lines of Meeting Maker or iCal, but open source, extensible, and with the polish of Google Calendar. I've been thinking about it a lot and I have several other usability ideas to throw in to make it really shine. I keep meaning to post my requirements on my blog. Maybe I'll get to that this week. Another thing I'd like, is to augment GHC with a type level debugger. One simple idea I had for that was to have GHC dump out the source code it's type checking with the types it has figured out (and the ones that don't type check, expect vs. inferred) annotated at every term and subterm. This has some technical hurdles, but mainly I think it has usability concerns to address. For example, how to let the user zoom in to the smallest term and see the type while also letting them select larger terms and see the type, all without being overwhelmed. Something that novices can make sense of but experts enjoy using too. Here is another idea. I'd like to see more integration between personal wikis (ones you run on localhost) and email systems. Imagine that an email comes into your inbox and then you can annotate the email by adding notes, sort of like track changes in Word. The email + notes stays in your inbox. It would be nice if you could bookmark those emails too in your web browser or similar. This would be handy for me as I sometimes reference specific emails for a long time and I often want to make notes as I reference them. Currently I paste the email into gitit and go for there. A universal interface / adapter for version control systems would be nice, but I think this one needs more research. We currently have a problem with vcs that each one speaks its own language. To me this is analogous to only being able to email people who use the same email client as you. Quite suboptimal. I hope that helps, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Suggestions for an MSc Project?
None of the frameworks in http://www.haskell.org/haskellwiki/Applications_and_libraries/GUI_libraries#High-level appear to have a working build in http://hackage.haskell.org/packages/archive/pkg-list.html#cat:gui, except wxFruit. Is there a need that isn't being met for high-level GUI libraries? Another suggestion I received in a private reply is to work on data persistence, but it would be tough to evaluate all the dozens of entries in http://hackage.haskell.org/packages/archive/pkg-list.html#cat:database. Is there some database need that isn't being met? I've never done serious Haskell programming (I've played with it a little while doing lots of C# at work), so I'm hoping that more experienced Haskell programmers could identify a potentially useful contribution. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Suggestions for an MSc Project?
My MSc requires a project dissertation, which is expected to take about 800 hours. I would like to work on something which is of use to the Haskell community. Any suggestions? My interests are in higher-level application programming, rather than low-level libraries or compiler hacking. (This is also the focus of my course.) I don't know whether Haskell is suitable for this (the only significant Haskell programs seem to be its own tool-set), but I had fun learning Haskell and I'd be interested in using it for my project if relevant. The details for the project's requirements are here http://www.ljmu.ac.uk/cmp/onlinemsc/students/97939.htm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Suggestions for an MSc Project?
On 04/07/2010 12:00, Ivan Lazar Miljenovic wrote: My interests are in higher-level application programming, rather than low-level libraries or compiler hacking. What do you mean by this? Using web programming as an example, a CMS would be high-level, while a networking library would be low-level. I was thinking of having a go at a web framework, but the space seems to be filled with Happstack. Have a look through the wish-list here: http://www.reddit.com/r/haskell_proposals/ Thanks, I had a look at the list, but none of it seems to be appropriate for a medium-length academic project with real-world benefits. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Suggestions for an MSc Project?
On 04/07/2010 13:23, Ivan Lazar Miljenovic wrote: Well, it depends upon what your interests are. What kind of stuff (apart from web frameworks) do you like hacking on? End-user applications, and high-level frameworks. (I'm not sure how to define high-level, I hope the CMS example gets the point across.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Suggestions for an MSc Project?
On 04/07/2010 13:32, Christopher Done wrote: It isn't really filled with happstack. Many of us use FastCGI or a straight web server like hyena or Snap, or salvia, etc. People keep writing web frameworks because they're unsatisfied with what's currently available. But yeah, I'd pick something more interesting than a web framework. A web framework would be interesting enough, if I knew what it is that people want which isn't satisfied by the incumbents. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Suggestions for an MSc Project?
On 04/07/2010 14:13, Ivan Lazar Miljenovic wrote: End-user applications, and high-level frameworks. (I'm not sure how to define high-level, I hope the CMS example gets the point across.) What _kind_ of application though? end-user application is rather broad. For example, do you like programming maths stuff? Accounting stuff? Games? A maths example would be a Matlab-like environment (I assume that's high-level enough for you?). All of these would be good, although there would probably have to be some kind of academic challenge for it to qualify. A Matlab clone would be a good idea, although I'm not sufficiently familiar with the maths, and that might take it out of scope. What kind of application, within these constraints, would the community be interested in? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Suggestions for an MSc Project?
On 04/07/2010 15:44, Felipe Lessa wrote: What about [1]? Such a graphical editor could be used, for example, for an EDSL. =D Cheers, [1] http://www.reddit.com/r/haskell_proposals/comments/9n8nc/write_a_scratchlike_graphical_editor_for_a/ Already exists :-) http://mypage.iu.edu/~gdweber/software/sifflet/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Types and hashes of hashes, trouble for a Java-programmer...
Thanks, I was close, but the I was trying to use (something like) this statement without the return: maybe (return Nothing) (flip HashTable.lookup 1000) More or less like this: maybe (Nothing) (flip HashTable.lookup 1000) Which did't work... Guess the return is needed because we use a new monad (Maybe) inside another monad (IO). Petter On Mon, Apr 13, 2009 at 7:45 PM, Lennart Augustsson lenn...@augustsson.net wrote: res - HashTable.lookup h 3 = maybe (return Nothing) (flip HashTable.lookup 1000) On Mon, Apr 13, 2009 at 6:59 PM, John Smith smithsno...@gmail.com wrote: Yes, agreed. Got any clue on the original problem (except to use Data.Map)? On Mon, Apr 13, 2009 at 6:55 PM, Jason Dagit da...@codersbase.com wrote: Others have provided help to answer your question but I'd like to provide a little bit different feedback. On Mon, Apr 13, 2009 at 8:42 AM, John Smith smithsno...@gmail.com wrote: Hi, a java-programmer running into trouble while trying to learn Haskell. I try to make a hash containing hashes but can not getting a value out of the innermost hash - I keep running into type-trouble where IO and Maybe monad is getting mixed? My attempt: removeMaybeHash x = case x of Just ref - ref Nothing - HashTable.new (==) (\key - key) When you see yourself writing a function like this, you could write it like this instead: removeMaybeHash (Just ref) = ref removeMaybeHash Nothing = HashTable.new (==) (\key - key) Hopefully you agree this 2 line version is more clear. You could go further of course and use the function 'maybe' from the prelude, and pass the function 'id' instead of \key - key, but I don't want to overwhelm you. Good luck, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: language proposal: ad-hoc overloading
Ryan Ingram wrote:
module Prob where
import qualified Data.Map as M
newtype Prob p a = Prob { runProb :: [(a,p)] }
combine :: (Num p, Ord a) = Prob p a - Prob p a
combine m = Prob $
M.assocs $
foldl' (flip $ uncurry $ M.insertWith (+)) M.empty $
runProb m
Do you see it? All those M. just seem dirty to me, especially
because the compiler should be able to deduce them from the types of
the arguments.
May I humbly suggest a much simpler solution to your problem: if an identifier is ambiguous, the compiler will use the
last import. So, in your example, the compiler will assume that any instance of empty is Data.Map.empty
Some means of using an imported module as the default namespace, and requiring
the Prelude to be qualified, may also help.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
