GHC 8.2.2 for WSL Ubuntu 16.04 64 bit
I have made available a build of GHC 8.2.2 with the config option: --disable-large-address-space You may find this useful if you are using Ubuntu 16.04 on Windows Subsystem for Linux. https://github.com/zoominsoftware/ghc-8.2.2-wsl Although Microsoft has been making gradual progress on the large address mapping issue[1][2], and the situation is much improved, there is still an extra startup latency of about 13 secs. for applications that pre-map a large address space as GHC does by default. This makes the standard GHC binary unusable for compiling projects of any non-trivial size. WSL is now out of beta. It can be enabled on any computer running Windows 10. Almost all 64-bit linux binaries run fine out of the box on WSL. GHC is unfortunately an exception, due to its large address space mapping behavior. WSL is extremely useful as a development platform, except for this annoyance for Haskell developers. Could we consider providing binary installers with --disable-large-address-space as an official part of our releases? It seems that it would take very little extra work to do so: just run the build for latest Debian twice, once as usual and once with --disable-large-address-space. Is there anything I could do to help? Thanks, Yitz [1] https://ghc.haskell.org/trac/ghc/ticket/13304 [2] https://github.com/Microsoft/WSL/issues/1671 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: How to get a heap visualization
Joachim, first and foremost, thanks for the awesome libraries ghc-vis and ghc-heap-view. The design trade-offs for ghc-vis do make sense if you think of it as a didactic tool. But as a debugging tool, the most important factor is that it should "Just Work", with no big builds, no fiddling, no googling. When you reach for a debugging tool, you are *already* in a debugging situation; you don't have patience for also debugging the tool. I wrote: >> Getting ghc-vis to compile looks hopeless, for a number of >> reasons..The dependencies on gtk and cairo are huge. You wrote: > Is that really a problem? Admittedly I haven't tried in quite a while. In the past, getting all the Haskell libraries and C libraries to match up and work together on any given platform at matching versions was a huge task. If nowadays you can just type "stack build" or "cabal install" (with new-build or in a sandbox) on even one platform and have it just work, reliably every time, month after month, that would be an amazing feat. But in my case, I need even more than that. I need it to "Just Work" on certain specific platforms, none of which have ever been known as the best for running GTK: Windows, and headless Ubuntu. >> The heap scraper backend for ghc-vis, ghc-heap-view, >> looks usable, and better supported than vacuum. >> But is there a quick and simple >> visualizer for its output, without ghc-vis? > Well, the :printHeap command that comes with it does > “visualize” things as something resembling Haskell syntax... > I don’t know of anything more graphical besides ghc-vis, > but you could roll your own, if you want to; you can use > ghc-heap-view to get a graph using buildHeapGraph > and then visualize that as you like. Yes, this is the approach I will probably take. I'll start with just printing the output into a text file. Maybe I can massage that and find what I need. Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: How to get a heap visualization
I wrote: >> I need a simple heap visualization for debugging purposes... >> Vacuum... has some long-outstanding PRs against it... >> that were never applied... >> Getting ghc-vis to compile looks hopeless... >> ghc-heap-view... is there a quick and simple >> visualizer for its output, without ghc-vis? Edward Z. Yang wrote: > Why not the plain old heap profiler? That didn't prove helpful in this case. We need to dive down into the structure of certain large and complex objects to find out what is happening. My plan is to see if I can apply the vacuum PR manually locally and see if I can get it working reasonably soon. If not, I guess I'll try running ghc-heap-view without visualization and see if I can make sense of the textual output. Actually, the profiling was done by someone else, not me. Now that you mention it, maybe I'll first give that another try myself and see if I can get any farther. Still, vacuum-style heap visualization is a really nice tool. It's a shame that it has fallen into such a state of disrepair. Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
How to get a heap visualization
I need a simple heap visualization for debugging purposes. I'm using GHC 8.0.2 to compile a large and complex yesod-based web app. What's the quickest and easiest way? Vacuum looks simple and nice. But it has some long-outstanding PRs against it to support GHC 7.10 and GHC 8.0 that were never applied. https://github.com/thoughtpolice/vacuum/issues/9 Getting ghc-vis to compile looks hopeless, for a number of reasons. The dependencies on gtk and cairo are huge. It hasn't been updated on Hackage for a year and a half. It requires base < 4.9. I need to run the visualizer either on a headless Ubuntu 16.04 server, or locally on Windows. And anyway, the fancy GUI in ghc-vis is way overkill for me. The heap scraper backend for ghc-vis, ghc-heap-view, looks usable, and better supported than vacuum. But is there a quick and simple visualizer for its output, without ghc-vis? Is there anything else? Is the best option to fork vacuum and and try to apply the PRs? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Unused import warning on re-export
I have a module A with no export list, and a function f which from the API point of view should part of the export list of A. But f must be defined in module B, not module A, due an import cycle. I added this line in module A to re-export f from A: import B as A (f) This resulted in an unused import warning. That is a problem for us - we keep our large code base clean of warnings as a policy. Is there a reason GHC considers this case an unused import? It seems that the use of the import is explicitly stated right within the import itself. Should I submit a ticket for this? Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.4.2 on Ubuntu Trusty
Resurrecting this thread: My impression was that Edward's suggestion was a simple and obvious solution to the problem of previous GHC versions quickly becoming orphaned and unbuildable. But Austin thought that this thread was stuck. Would Edward's suggestion be difficult to implement for any reason? Specifically, right now would be the time to do it, and it would mean: 1. Create a 7.8.5 branch. 2. Tweak the stage 1 Haskell sources to build with 7.10 and tag 3. Create only a source tarball and upload it to the download site Thanks, Yitz On Wed, Oct 29, 2014 at 12:10 AM, Edward Z. Yang wrote: Excerpts from Yitzchak Gale's message of 2014-10-28 13:58:08 -0700: How about this: Currently, every GHC source distribution requires no later than its own version of GHC for bootstrapping. Going backwards, that chops up the sequence of GHC versions into tiny incompatible pieces - there is no way to start with a working GHC and work backwards to an older version by compiling successively older GHC sources. If instead each GHC could be compiled using at least one subsequent version, the chain would not be broken. I.e., always provide a compatibility flag or some other reasonably simple mechanism that would enable the current GHC to compile the source code of at least the last previous released version. Here is an alternate proposal: when we make a new major version release, we should also make a minor version release of the previous series, which is prepped so that it can compile from the new major version. If it is the case that one version of the compiler can compile any other version in the same series, this would be sufficient to go backwards. Concretely, the action plan is very simple too: take 7.6 and apply as many patches as is necessary to make it compile from 7.8, and cut a release with those patches. Edward ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.4.2 on Ubuntu Trusty
I wrote: This thread makes it clear what a mess we have inherited from the days when GHC was primarily a research compiler. Let's face it - GHC is now also a serious production compiler, and this urgently needs to be cleaned up. hvr wrote: Are you referring to the GMP dependency or something else? ...I'm not sure what can be done differently here. Agreed. No, not any one of those many little details. I mean the general extreme difficulty of getting almost any version of GHC working on almost any platform, unless the two were released within a fairly short time of each other. Well, that is, not counting your wonderful ppa for Ubuntu. That is fantastic - but the dire need for it is evidence for the severity of the problem. How about this: Currently, every GHC source distribution requires no later than its own version of GHC for bootstrapping. Going backwards, that chops up the sequence of GHC versions into tiny incompatible pieces - there is no way to start with a working GHC and work backwards to an older version by compiling successively older GHC sources. If instead each GHC could be compiled using at least one subsequent version, the chain would not be broken. I.e., always provide a compatibility flag or some other reasonably simple mechanism that would enable the current GHC to compile the source code of at least the last previous released version. I realize that this might be disruptive to GHC devs, because as a compiler with a research heritage, GHC experiments with its own new features on its own source code. But as a compiler that is used commercially, some general kind of backward portability is critically important. The other direction is equally problematic. Although GHC does support bootstrapping itself from a few previous releases, porting GHC to a new platform has become harder and harder as GHC becomes more complex. I think this could become a threat to the viability of GHC - technology is always changing. As a commercial developer, I am always plagued by nagging worry about GHC portability, forward and backward. Will we always be able in the future to support code we release, or will it die someday because there will no longer exist a GHC able to compile it? Will our whole technology die someday just because we can't get GHC working on a platform we need to support? Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC 7.4.2 on Ubuntu Trusty
In order support some older software that we released, we need to get a working GHC 7.4.2 on Ubuntu Trusty. We currently have GHC 7.8.3. The binary tarball for GHC 7.4.2 does not install on Trusty due to multiple incompatibilities. For example, GHC requires GMP 3, but Trusty only provides GMP = 4. Etc. I tried building GHC 7.4.2. from source on Trusty. But the process won't boot from our currently installed GHC 7.8.3. The oldest GHC binary I can get is GHC 7.6.3, which happens to be still available from the Ubuntu distribution itself (neither the binary tarball nor compiling from source work for GHC 7.6.3 on Trusty either). But booting from GHC 7.6.3 won't work either. How do I get a working GHC 7.4.2 on Trusty? Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.4.2 on Ubuntu Trusty
I wrote: How do I get a working GHC 7.4.2 on Trusty? Thanks to all for the suggestions. Daniel Trstenjak wrote, off-list: I can only recommend: https://launchpad.net/~hvr/+archive/ubuntu/ghc Thanks Daniel! I hadn't looked at Herbert's ppa for a while. Despite the comments, which say it is only updated for precise but should also work for trusty, the ppa actually *is* updated for trusty now. This is trivially simple to use and worked great, so that's what I ended up using. But still - something really really needs to be done about GHC portability. This thread makes it clear what a mess we have inherited from the days when GHC was primarily a research compiler. Let's face it - GHC is now also a serious production compiler, and this urgently needs to be cleaned up. Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Linux deployment requirements for GHC-produced binaries
You may need to resort to strace to find out what's trying to pull in libgmp.so.whatever. I don't know how to do that. And anyway, I don't have access to the machine on which the customer is reporting this. I do believe the report - there is no compilation going on here, they are only running our GHC-compiled binary. They know nothing about GHC (not even that we are using it). I was hoping that there would be some general knowledge about this so I could just pass it on to our customers. But I see everyone else is as surprised as I am about a supposedly static GHC-compiled binary requiring a libgmp.so to run. Unless this program is like xmonad and requires ghc behind the scenes to build something, in which case you would indeed need everything that ghc requires (and, of course, ghc itself). No definitely not. Erik de Castro Lopo wrote: I suspect the OP's exectuable is already being compiled static. I compiled it static. Brandon Allbery wrote: Yes; which leaves the question of why it requires libgmp.so, and if it's static the only things I can think of are (a) it's using dlopen(), or (b) it's running something else that is not static and requires libgmp.so. Right. Could a dependent library be causing this? For example, this program depends on direct-sqlite, which in turn links to sqlite via FFI. It also depends on wai, which pulls in quite a few indirect dependencies. If so - how would I investigate this and get a complete list of the system libraries that customers are required to install as prerequisites? Jens Petersen wrote: You built ghc yourself? No. It is the generic Linux binary tarball from GHC HQ. And ran ldd on $bindir/ghc or $libdir/ghc-version ? No, in $bindir that's just a shell script. It's in $libdir. The executable is ghc; ghc-version is a directory containing object files compiled from libraries. Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Linux deployment requirements for GHC-produced binaries
We received a complaint from one of our customers that the Linux executable for one of our products - compiled using GHC - does not run because of libgmp not being installed on their server. This binary was compiled using GHC 7.4.2 (HP 2012.4.0.0). We hope to be migrating soon to GHC 7.6.3 (HP 2013.2.0.0.). Do GHC-compiled binaries have a dynamic dependence on libgmp? If so, what are the exact requirements we need to communicate to our customers? Does this limit what versions of Linux we can claim that our product supports? Are there similar requirements and limitations regarding GNU Readline? Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Linux deployment requirements for GHC-produced binaries
Hi Brandon, Thanks for your response and explanation. I wrote: [For] GHC-compiled binaries... what are the exact requirements we need to communicate to our customers? You wrote: Ideally you would use `ldd` on binaries to determine other dynamic dependencies that must be communicated ldd just says not a dynamic executable. When run against ghc itself, ldd gives a list of 11 dynamic libraries, and for each of them the specific binary version of the library that it linked against on my own particular machine. Does the machine on which we run the GHC-compiled binary need every single one of these libraries in order to run? Here is the list of libraries - identical for both GHC 7.4.2 and GHC 7.6.3: linux-vdso.so.1 libncursesw.so.5 librt.so.1 libutil.so.1 libdl.so.2 libgmp.so.3 libm.so.6 libpthread.so.0 libc.so.6 libtinfo.so.5 /lib64/ld-linux-x86-64.so.2 Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
32-bit libs required for 64-bit install
I had trouble installing the generic 64-bit Linux tarball for 7.6.3. With some help from Ian, who pointed out that the problem was related to ld-linux.so, I finally figured out the root of the problem: the installation requires *both* the 64-bit and 32-bit versions of libc6 plus deps to be available. Once the installation was complete, I could then remove the 32-bit libs and ghc still seems to work. It appears that the 32-bit libs are only required for some of the auxiliary executables that come with the tarball, such as ghc-pwd. Is there any reason in principle that we only allow 64-bit GHC to be installed on multiarch Linux? That seems like a rather arbitrary restriction. In the meantime, something ought to be said about this on the download page. More details: the target system for the installation in my case was an up-to-date Ubuntu 12.04 LTS (precise) amd64 headless server running in a VMware containter. Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GADTs in the wild
Simon Peyton-Jones wrote: This message is to invite you to send me your favourite example of using a GADT to get the job done. Ideally I’d like to use examples that are (a) realistic, drawn from practice (b) compelling and (c) easy to present without a lot of background. Last year I presented the following simple puzzle to the community: http://www.haskell.org/pipermail/haskell-cafe/2011-February/089719.html That puzzle actually came up in a real-life software project in Haskell that I was working on. Several solutions were submitted that used various Haskell extensions such as rank N types and generics, as well as a rather cumbersome Haskell 98 solution. But in my opinion, by far the best solution, using only GADTs, was submitted by Eric Mertens: http://hpaste.org/44469/software_stack_puzzle Eric's solution could now be simplified even further using data kinds. Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: default instance for IsString
Hi Simon, First of all, I'm sorry if I'm coming off as too combative, as Greg says. That is certainly not my intention. I'm not asking for any free work from you, either. The only reason I don't like using OverloadedStrings for typing string literals as Text and ByteString is that when you turn on OverloadedStrings, you turn it on for all types, not just Text and ByteString. I don't want to be forced to do that. Because all other uses of OverloadedStrings that I have seen, and there are many, are ill-advised in my opinion. They all should have been quasiquoters. If it's really important to use this mechanism for typing string literals as Text and ByteString, how about this: Create a new class IsBuiltinString, with method isBuiltinString. Make it hidden so that no new instances can be defined outside of base, and provide instances only for String, Text, and ByteString, for now. Then I will happily use the OverloadedBuiltinStrings extension. People who don't see any problem with OverloadedStrings can go on using it as before. Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: default instance for IsString
Erik Hesselink wrote: I don't think IsString should be dismissed so easily. I'm just saying I don't want to be forced to use it. If others like it, I'm not dismissing it. we have a couple of newtypes over Text that do different kinds of normalization. An IsString instance for these is useful and total. True. Perhaps you'd be able to get IsBuiltinString instances for those too, using newtype deriving, if only the method names of IsBuiltinString are hidden and the class name is exported. If that doesn't work, I'm fine with using a quasiquoter for those instead. Or even just the usual newtype unwrapping and wrapping. And again, if you provide IsString and others want to use it, that's fine. Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: default instance for IsString
I wrote: In addition, OverloadedStrings is unsound. J. Garrett Morris wrote: fromString can throw errors, just like fromInteger This is true; the use of polymorphism for numeric literals is also unsound. However, in practice, it is rare for there to be dangerous instances of the numeric type classes. this is no less sound than any Haskell function throwing an exception. No. Usually, operations that can throw an exception are in the IO monad, where the specter of a potential exception is more obvious, and where the operation can be wrapped in try or catch. Whereas a string literal that might throw an exception at run time is bizarre, to say the least. And it is extremely difficult to deal with potential exceptions thrown by fundamental language syntax that is sprinkled throughout nearly every Haskell module in existence. Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: default instance for IsString
Greg Weber wrote: I very much agree with you. However, when we complain about something essentially we are asking others to prioritize it ahead of other things. I don't think any more visibility of this issue is going to improve its prioritization. I suspect your only way forward right now is to start implementing something yourself. You're right. But as a professional Haskell developer, I am under the same kinds of deadline pressures as any other professional. So I'm afraid it's not going to be me, at least not in the near future. However, what I can do is raise the red flag. Some people are pushing things in directions which would cause OverloadStrings to become more and more ubiquitous, perhaps even the default. I want to make sure that the people who are doing that are aware of the deep problems with that approach. Sure, as much as anyone else, I want string literals that can be typed as Text. But not at the cost of delaying syntax checking to run time. And, as Bas points out, that there are many different compile time mechanisms that could be used for this. Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: default instance for IsString
J. Garrett Morris wrote: By this logic, head is unsound, since head [] throws an error. Haskell types are pointed; Haskell computations can diverge. Well, there are those who would actually agree with that and banish 'head' and friends from the language. But I'll agree with you here. [As an aside - I'm finding that liberal use of Edward's non-empty list type, found in the semigroups package, solves many of those problems for me.] But there are two crucial differences. First, head is just a partial function, not basic language syntax. Second, the divergence of head is constant and well-known, and not dependent on the implementation of a type class at particular types by various library authors. What happens after the computation diverges is irrelevant to type soundness. Agreed. I'm not talking about type soundness, in the technical sense. I'm talking about engineering soundness. Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: default instance for IsString
Michael Snoyman wrote: Here's a theoretically simple solution to the problem. How about adding a new method to the IsString typeclass: isValidString :: String - Bool ...whenever GHC applies OverloadedStrings in a case where the type is fully known at compile time (likely the most common case), it can run the check and- if it returns False- stop the compile. This approach does address the real reason that OverloadedStrings is unsafe in practice: library authors sometimes feel that they must reject certain strings. This gives them a safer outlet for that, with a nice simple API. However, it requires GHC to be able to resolve the monomorphic type of the string literal at a time when it can get its hands on the appropriate isValidString method, already compiled, and call it. Seems like in GHC, at least, the implementation of that would have to involve some kind of TH magic in the background. Is this possible? Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: default instance for IsString
Markus Läll wrote: What can go wrong when you use an overloaded string to be fromString'd into Text? Here's an example: The author of the xml-types package provides an IsString instance for XML names, so you can conveniently represent XML names as string literals in your source code. But not every string is a valid XML name. If you mistype the literal, your program will still compile. It may even run for a while. But when someone uses your program in a way that causes that mistyped XML name literal to be resolved, your program will likely crash, unless you structured it in a way that allows that XML name literal to be wrapped in an appropriate exception handler in the IO monad. -Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: default instance for IsString
Simon Peyton-Jones wrote: If you want validation of literal strings, then TH quasiquotes are the way to go: I agree. OverloadedStrings is, in effect, an unsafe replacement for quasiquotes. People find OverloadedStrings easier to use than quasiquotes, so its use in that way is becoming popular. What we need is a mechanism for allowing string literals to have the type Text or ByteString instead of String. I do not want to be forced to turn on UnsafeQuasiQuotes every time I need a string literal. So in my opinion, OverloadedStrings is the wrong mechanism for providing Text and ByteString literals. Alternatives that have been suggested: o A hard-coded pragma to specify the type of string literals in a module as Text or ByteString. o An extra method of IsString, of type QuasiQuoter, that runs at compile time in a monomorphic context. o As above, but only check syntax at compile time in a monomorphic context. That allows a simpler API, without requiring any TH knowledge in most cases. Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: default instance for IsString
Markus Läll wrote: You do know, that you already *can* have safe Text and ByteString from an overloaded string literal. Yes, the IsString instances for Text and ByteString are safe (I hope). But in order to use them, I have to turn on OverloadedStrings. That could cause other string literals in the same module to throw exceptions at run time. -Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: default instance for IsString
Daniel Peebles wrote: Why are potentially partial literals scarier than the fact that every value in the language could lead to an exception when forced? That's a legitimate question, but it's strange to hear it from you. People ask that same question about Haskell's static type system. Why bother? Every value could lead to an exception when forced. So we might as well check everything at run time. Wouldn't it be ironic if the one thing that every language other than Haskell is able to check at compile time, namely the static syntax of string literals, could only be checked at run time in Haskell? Especially when, with just a little care, we could easily continue to check it at compile time while still supporting string literals of type Text and ByteString. I guess I'm just not understanding your question. Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: default instance for IsString
Simon Marlow wrote: In this thread people are using the term safe to mean total. We already overload safe too much, might it be a better idea to use total instead? I'm not sure what you're talking about. I don't see how this thread has anything to do with total vs. partial functions. I'm saying that the static syntax of string literals should be checked at compile time, not at run time. Isn't that simple enough, and self-evident? Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: default instance for IsString
Jeremy Shaw wrote:
I have often wished for something like:
{-# LANGUAGE StringLiteralsAs Text #-}
where all string literals like:
f = foo
would be translated to:
f = (fromString foo :: Text)
Agreed, I would also really like this.
I find that OverloadedStrings is too general and causes ambiguous type
errors. Additionally, I seldom find that I have more than one type of
string literal per file. Things tend to be all String, all Text, etc.
So, if I could just pick a concrete type for all the string literals
in my file, I would be happy.
In addition, OverloadedStrings is unsound. Library authors can,
and do, write unsafe implementations of IsString that cause
syntax errors to be caught only at run time instead of at
compile time. That is the opposite of one of the most
important things we are trying to accomplish by using
Haskell instead of, say, some dynamically typed language.
Greg Weber wrote:
You can default a String. So this compiles just fine:
{-# LANGUAGE OverloadedStrings #-}
{-# LANGUAGE ExtendedDefaultRules #-}
import Data.Text as T
default (T.Text)
No, I do not want string literals to be polymorphic, even
if there is some kind of defaulting. I want them to be
monomorphic, as they always have been. But I still
want to be able to specify to the compiler somehow
that the monomorphic type for string literals in a
particular module should be something other than
String.
Thanks,
Yitz
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci 7.4.1 no longer loading .o files?
Evan Laforge wrote: Is there something that changed in 7.4.1 that would cause it to decide to interpret .hs files instead of loading their .o files? E.g.: Brandon Allbery wrote: I thought this was deliberate because the debugger won't work with object files? Oh I hope not. I almost never use the debugger, and it's so much slower to re-interpret all those modules. I am surprised about this complaint. I have never noticed any significant delay for re-interpreting, even when working on projects that are quite large, with tens of thousands of LOC. I have always found the behavior of using .o files by default surprising and annoying. The i in GHCi stands for interactive. I expect work in GHCi to be as interactive as possible in every way, including having access to the debugger. I expect performance to be similar to the usual performance of interpreter shells in any language; I don't mind if it doesn't match the speed of compiled Haskell. It's nice if there is a way for experts to load .o files in GHCi, e.g., for the rare case where the performance difference for some specific module is so great that you can't work effectively interactively in some other module that imports it. There could be something to set in .ghci for people who do like that behavior all the time, perhaps. But it should not be the default. GHCi is headed in that direction in many ways, and I think that's great. I don't think more flags should be excluded from the fingerprint by default if that would detract in any way from the interactive experience. In particular, it is especially important for -XNoMonomorphismRestriction to be the default in GHCi. See also these tickets: http://hackage.haskell.org/trac/ghc/ticket/3217 http://hackage.haskell.org/trac/ghc/ticket/3202 Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell
By the way, thanks to Greg for driving this discussion,
please keep up the good work!
Simon Peyton-Jones wrote:
Can you turn your proposal into a Wiki page?
OK I'll try to get to that later today.
It's different to Johan's.
Oh? I didn't realize that. OK, I'll look at it more closely.
I'm basically just using modules the way they are,
changing almost nothing.
I wrote:
[This has the additional advantage of giving SPJ
motivation to remain engaged, because he seems
to prefer B. :)]
True: but that's because I think that in the end A will
be deemed too clumsy, so we'll end with B anyway.
And I'd rather not do both. But I'm quite open to
persuasion!
I agree that B would be great! It just seems harder,
and I'm worried that we'll get stuck again.
As long as we are moving forward productively towards
a solution to B, I'm happy with that.
I'm trying to suggest a simple, workable approach to A
as a backup.
OK, so consider this:
module M where
module T where
data T = MkT { x :: Int }
module S where
data S = MkS { x :: Int }
So inside M I can refer to T.x and S.x.
Fine! What does M export?
As it stands, M exports nothing. In my scheme, nested modules
have almost exactly the same meaning as they would have
if they were written as separate modules. So far, the only
differences are: module T is syntactic sugar for module M.T,
and there are implied import statements added to M, T, and S.
So an module external to M that wants to use T or S would
need to import them explicitly in addition to the import of M.
The usual rules would then apply.
Based on your comments, I see that another optional
enhancement to my proposal could be as follows:
Whenever any module E imports M unqualified without an
import list, as in:
import M
then the following implied imports would be added to E:
import qualified M.T as T
import qualified M.S as S
and whenever E imports M qualified without an
import list, as in:
import qualified M as Q
then the following implied imports would be
added to E:
import qualified M.T as Q.T
import qualified M.S as Q.S
Similarly, if M also contains more deeply nested
modules and E imports M either qualified or
unqualified without an import list, the corresponding
implied imports of the deeply nested modules would
also be added to E. But in fact, this is nothing
more than a recursive application of the previous
rule.
Note that an import statement with an import list
will never generate any automatic import of
a nested module.
I will add this additional enhancement to the wiki
page (when I write it).
Thanks,
Yitz
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-cabal-Random
I wrote: Today, it is very unusual to use GHC by itself. To use Haskell, you install the Haskell Platform. That is GHC together with Cabal and a basic set of libraries. It is very easy to install. Wolfram Kahl wrote: However, since you are willing and able to test bleeding-edge versions of GHC, you need to be able to live without the platform, which typically catches up to GHC versions only within a couple of months. It's true that the platform provides a stable version of GHC, as needed by most people, not the bleeding edge. But even if you need GHC HEAD you would typically use cabal. Unless for some reason you need to shuffle around manually the various pieces that get built, follow trees of package dependencies manually, etc. There are some people who need to do it, and it is doable, though much more complicated and error-prone than just using cabal. Almost all Haskell software is expected to be installed using Cabal nowadays. It is important to know that people associate two packages with the name ``Cabal'' They are closely interconnected though. If you use the platform, that distinction is not very important. It just works. Life without cabal-install is not only possible, but also safer. I disagree with that. Manual processes are error-prone. With experience, you can learn how to do things totally manually, just like you can learn to build C projects manually without make, and with even more experience, you can learn to avoid all of the pitfalls. It's a good thing to know, but I wouldn't put it at first priority unless there's a special reason for it. (See also: http://www.vex.net/~trebla/haskell/sicp.xhtml ) The Cabal system is quite mature now, but still far from perfect. Problems can arise. Most of the problems are inherent to the DLL Hell that can occur in any separate compilation system, and some arise from the fact that Cabal's dependency solver needs improvement (that's a hard problem). That link is a detailed write-up of just about everything that can possibly go wrong. In my experience, none of that happens until you've been using an installation for a long time, or if you are very trigger-happy with upgrading packages to the latest version for no reason. Or if you're using a package with a huge amount of fast-changing dependencies, like one of the web frameworks. Even then, it's almost always easy enough just to re-install the platform to get a fresh install. Your next few compiles will take a few minutes longer as some packages get rebuilt, but that's about it. To avoid that altogether, I use cabal-dev. This allows me to build a package I am working on in a sandbox with just the dependencies it needs, tailored exactly for the needs of my specific package. Cabal-dev also makes it easy to experiment with how users will experience building my package. It's good to know all the intricacies of the build system, and what is happening beneath the surface if it gets lost. The linked article is a worthwhile read for that. Regards, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell
Gershom Bazerman wrote: Beyond that, it would really help namespacing in general to appropriately extend the module system to allow multiple modules to be declared within a single file -- or, better yet, submodules. I know that this introduces a few corner cases that need to be thought through -- what happens with overlapping declarations, for example. But I tend to think the path here is relatively straightforward and obvious, and the added expressive power should make namespacing issues much more tractable. I agree, this would be a great first step forward. Nested modules would be the most helpful. But even just multiple modules per file would be an improvement, and that is Haskell 98 compliant. For past discussion about this idea, see the thread that begins here: http://www.haskell.org/pipermail/haskell-cafe/2008-August/046494.html There is also the issue of how GHC decides which files to open when searching for modules. One easy way to begin would be just to have the caveat that GHC will not find such modules unless it would otherwise look in the file based on the traditional GHC naming conventions. For various reasons including this one, I still think it is a good idea to allow the user to specify a manifest file to GHC instead of relying on GHC to walk the file system itself. See this GHC ticket: http://hackage.haskell.org/trac/ghc/ticket/2550 Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-cabal-Random
Serge D. Mechveliani wrote: I have ghc-7.4.0.20111219 made from source and tested it on the DoCon-2.12 application -- thanks to people for their help! It looks all right. This was -- with skipping the module Random Now it remains to add the Random package. I have taken AC-Random Version 0.1 from hackage... Its installation requires Cabal.. And Cabal is difficult to install.. Glad to hear that you are working on getting DoCon working again in a modern Haskell environment. I hope you will be successful. Today, it is very unusual to use GHC by itself. To use Haskell, you install the Haskell Platform. That is GHC together with Cabal and a basic set of libraries. It is very easy to install. http://hackage.haskell.org/platform/ Almost all Haskell software is expected to be installed using Cabal nowadays. The random package is included with the Haskell Platform, so that problem should be solved too. If you need anything else that is not included in the Haskell Platform, you will most likely want to install it using the command: cabal install package-name Once you get DoCon working on a recent Haskell Platform, it would be wonderful if you could make it available on Hackage so that it, too, could be easily installed this way. Since the Haskell Platform is now a separate project from GHC and provides GHC only as one of its many components, you will probably get a better response to your questions on the Haskell Cafe mailing list rather than here. Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Why not allow empty record updates?
I wrote:
Yes. The translation of record updates given in the Report
makes perfect sense for {}. It is only forbidden by
n = 1, but no reason is given for that restriction.
d wagner wrote:
It doesn't make sense to me. The translation explodes a value into a case
statement over its constructors; what constructors do you use when you don't
know the type of the value?
When n = 1, you know the type of the value by looking where the field came
from, and hence which constructors to use in the case statement.
Well, yes, you need to know the type. That's why I asked
Simon if there is difficulty with implementation.
I do have an algorithm in mind, but it seemed silly for me
to write it out given that I know near zero about
the implementation details of GHC's type checker.
But if you insist, here is a rough sketch:
Replace each subexpression of the form e {} by
v' and add v = e to the let bindings, where v and v' are
fresh variables. Resolve the type. For any v that resolves
to an ADT (even if the types of its parameters are not
resolved), replace e {} in the original expression by
its case expansion. Repeat until all are resolved,
rejecting the program if an iteration does not resolve
any v. Resolve the final form of the expression one
more time to obtain its type.
Does this make any sense?
Thanks,
Yitz
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Why not allow empty record updates?
Simon Peyton-Jones wrote:
Trouble is, what type does this have?
f x = x {}
Malcolm Wallace wrote:
Empty record patterns {} are permitted, even for types
that are not declared with named fields.
So I don't see why an empty record update should
require the type to be declared with named fields either.
Yes. The translation of record updates given in the Report
makes perfect sense for {}. It is only forbidden by
n = 1, but no reason is given for that restriction.
According to that translation, the type of x {} is
the type of the case expression it translates to.
Thanks,
Yitz
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Why not allow empty record updates?
Simon Peyton-Jones wrote:
Trouble is, what type does this have?
f x = x {}
Malcolm Wallace wrote:
f :: a - a
Ian Lynagh wrote:
That wouldn't help the original poster, as it is incompatible with
f :: Foo Clean - Foo Dirty
Only because in that expression the type of x is not known.
...the whole feature of type-changing update is (as you know)
a bit obscure and not widely used, so it'd be adding
complexity to an already-dark corner.
To me, at least, that is surprising. The report implies that
record updates are just sugar for the given case expression.
Whether or not it changes a type parameter seems
unimportant.
In fact, I would even advocate adding a line of explanation
in the Report that this is a convenient way of copying
a value from an ADT to itself with a different type
as its parameter. I agree with Malcolm that this is
analogous to using empty record syntax in a pattern
to avoid hard-coding the number of parameter to
a constructor.
I usually avoid using the combination of type parameters and
record syntax altogether, mainly because this obvious syntax
doesn't work. Perhaps that's the reason why type-changing
update is not widely used.
(Admittedly, I didn't think of Herbert's trick. But doesn't
that seem like somewhat of an ugly hack?)
Are you hesitant because of implementation difficulty,
or only because you are worried about the semantics
being confusing? In my opinion, it's more confusing
the way it is now.
Thanks,
Yitz
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: behaviour change in getDirectoryContents in GHC 7.2?
Simon Marlow wrote: It would probably be better to have an abstract FilePath type and to keep the original bytes, decoding on demand. But that is a big change to the API and would break much more code. One day we'll do this properly; for now we have this, which I think is a pretty reasonble compromise. John Millikin wrote: Please understand, I am not arguing against the existence of this encoding layer in general. It's a fine idea for a simplistic high-level filesystem interaction library. But it should be *optional*, not part of the compiler or base. The problem is that Haskell 98 specifies type FilePath = String. In retrospect, we now know that this is too simplistic. But that's what we have right now. As implemented in GHC 7.2, this encoding is a complex and untested behavior with no escape hatch. Isn't System.Posix.IO the escape hatch? Even though FilePath is still used there instead of ByteString as it should be, this is the low-level POSIX-specific library. So the old hack of interpreting the lowest 8 bits as bytes makes a lot more sense there. Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Two Proposals
George Giorgidze wrote: My second proposal is to introduce the OverloadedLists extension that overloads list literals... I am opposed to this proposal as stated. But I think that with a modification, it can not only be improved, but also solve the problems with the current OverloadedStrings extension. OverloadedStrings - and George's unmodified proposal - change compile time errors into run time errors. Literals with hard-to-find problems are accepted by the compiler and become _|_ at run time. An example of the problem: the xml-types package has an IsString instance for Name. The fromString method parses XML namespaces from XML names and calls error if the parse fails. Without the extension, one would specify the parts using constructors; that is wordy and awkward but checked at compile time. A quasi-quoter could be defined, but that syntax would still be far less convenient in practice than string literals. I agree that we need a way of allowing literals to have some flexibility in their types. But there should be a way for overloading to work at compile time, i.e. more like a quasi-quoter, when needed. Of course, quasi-quoter overloading can also just create an expression that applies a coercion function at run time. So in that sense, quasi-quoter overloading is more general than ad-hoc-polymorphism overloading. In all of George's examples fromList happens to be total, so there isn't an issue having it happen at run time. But if we make this generally available, you can be certain that it will cause problems later on. Just as with IsString, people will not be able to resist the nice syntax, and they will define fromList implementations that are partial. Here is a tentative modification of George's proposal: class IsList l where type Item l fromList :: [Item l] - l listExpQ :: [ExpQ] - ExpQ -- Minimal complete definition: fromList listExpQ = appE (varE (mkName fromList)) . listE If the type of a list literal determines a specific instance of IsList at compile time, use the listExpQ from that instance to interpret the list literal. Otherwise, use the default listExpQ, which is just George's original proposal. An alternative would be to put listExpQ in a separate type class with an IsList constraint. IsString can similarly be extended in a backward compatible way to allow syntax checking at compile time. Here the type could be stringExpQ :: String - ExpQ Numeric literals with Num and Integral can also be extended, though I think the problem is less common for those. Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Two Proposals
Roman Leshchinskiy wrote: In general, if we are going to overload list literals then forcing the desugaring to always go through lists seems wrong to me. There are plenty of data structures where that might result in a significant performance hit. These are literals. So the lists will almost always be quite short, and they will be evaluated only once. So I don't think there will be that much of a performance hit normally. That said, my extension that allows them to be desugared at compile time would solve that issue if it arises. Regards, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Quoting a quasi-quote
It was pointed out by Ben Millwood on the Cafe that there is an undocumented way to escape the closing oxford bracket of a quasi-quote using a backslash: [s|This quasi-quote contains this, \|], an escaped closing oxford bracket.|] The backslash itself cannot be escaped in this way: [s|Also contains an escaped bracket \\|] |] Thus there is a fairly strong limitation on the contents of a quasi-quote: it can never end in a backslash. This behavior is not mentioned in the GHC docs. Is it a mistake, or is it meant to be a supported feature? This behavior is a bit surprising to me. Since the whole point of a quasi-quoter is to allow the user to define syntax, you would think that the syntax for the quasi-quote itself would be as quiet as possible and stay out of the way. People who need to be able to escape the closing bracket can easily define their own syntax to do so. In any case, if this is indeed a feature, it certainly should be documented. Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Proposal to incorporate Haskell.org
Don Stewart wrote: The haskell.org committee... has decided to incorporate haskell.org as a legal entity. This email outlines our recommendation, and seeks input from the community on this decision. Thanks, good news! And thanks for posting to multiple lists for maximum public notification to the community. Can the committee now designate a single list for further discussion please? Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Deriviable type classes
Simon Peyton-Jones wrote: Generic Defaults... will replace... the Derivable type classes stuff... in GHC 7.2 or 7.4... Please yell if you are a secret user of derivable type classes, so this change would discombobulate you. Could you give us a preview of the parts of the syntax spectrum that will be gobbled up by this? That is a way that the change could affect even people who are not using the current generics. For example, the old generics knocked a very nice bracket out of consideration for TH syntax. It also blessed the names of certain magical constructors, which can be good to know about even if the magic doesn't leak out of the generics world. Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [darcs-users] How to develop on a (GHC) branch with darcs
Iavor Diatchki wrote: I use git for a lot of my development... Given the responses though, it sounds like this is a well known problem with darcs with no obvious solution. Why do you say there is no obvious solution? In fact, Ganesh, representing the Darcs team, responded: 1) a darcs rebase command... very much hope to have it in the next darcs release. Simon M has already tried out an experimental version and was quite positive about it... 2) multi-branch repos... perhaps the release after next... 3) Better performance when there are conflicts... [by upgrading GHC to v2 patches] 4) Better UI around managing conflicts... 5) new patch types that reduce the number of conflicts you get at all Some of those are already in the works, and all except possibly (5) are known to be within reach. So the answer is yes, this problem is now on the verge of being solved in Darcs. After focusing mostly on performance for a while and achieving huge gains, the Darcs team has turned a significant portion of its attention to the branching problem for some time now, and the fruits of this labor will begin to become available in the next release. VCS discussions tend to spark religious wars in which zealous proponents of one system conveniently ignore the positive points of another in order to push as hard as possible for the adoption of their darling. Standing somewhat on the outside, it seems to me that the discussion about switching VCS has been more than thoroughly exhausted. Even when Darcs was in a far less advanced state than it is in now, the conclusion seemed to be that the best interests of the Haskell community at large are served by remaining with Darcs. So it would be a bit strange if this branching issue, which is a serious issue currently but will likely become a non-issue in a few months time, triggers GHC to abandon Darcs. On the other hand, I suppose GHC HQ can't afford to have a revolt on their hands. So if the majority of people doing the actual work on GHC want to change to git and are willing to put in the effort to make the change, it will probably happen regardless. Regards, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
doesDirectoryExist always returns False on Mac OS X
Just after upgrading some basic packages from Hackage, doesDirectoryExist began always returning False. I suspect that this is related to the unix package, and/or its strange interaction with the directory package. See: http://hackage.haskell.org/trac/ghc/ticket/4812 Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Space leak with unsafePerformIO
Henning Thielemann wrote on Haskell Cafe: Attached is a program with a space leak... I have coded a simple 'map' function, once using unsafePerformIO and once without. UnsafePerformIO has a space leak in some circumstances. In the main program I demonstrate cases with and without space leak. Without space leak the program writes a file to the disk until it is full. Bertram Felgenhauer wrote: The program relies on the GC doing short-cut evaluation of record selectors to avoid a space leak... Use of suffix: Due to the call of Main.go1 this is *not* a record selector. It is compiled to an actual case expression, which to the garbage collector looks just like an ordinary thunk. A reference to Main.ds is kept around until the suffix is about to be processed and a memory leak ensues. The good news is that the problem is completely unrelated to unsafePerformIO (the presence of unsafePerformIO makes optimisations more difficult, but any pure function of sufficient complexity would have the same effect). Is there already a GHC Trac bug for this? Link to Bertram's original email, with detailed analysis of the GHC Core: http://www.haskell.org/pipermail/haskell-cafe/2010-June/079479.html Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Cutting down GHC installation to bare minimum
leledumbo wrote:
I notice that many of the installed libs aren't required for learning
Haskell. What libs are required so I can get the bare minimum version of
GHC?
For most people, the recommended approach is to install
the Haskell Platform. This is not a minimal setup - it includes
packages you would need for most normal use of Haskell.
http://hackage.haskell.org/platform/
To get a minimal setup, you need to install GHC and cabal-install.
That will allow you to install just the packages you need as you
need them. This is not recommended for most people - there are
prerequisites, and there may be some complexities depending
on your platform. Anyway, the instructions are here:
http://www.haskell.org/ghc/download_ghc_6_12_2.html
http://www.haskell.org/cabal/download.html
Also, is there any automatic way so that I don't have to manually
delete the folders and edit package.conf?
There isn't a smooth way to uninstall packages at the moment.
You don't need to edit package.conf, though, and you shouldn't.
Use ghc-pkg unregister {pkg-id}. You do need to delete the folders
manually, unfortunately.
Regards,
Yitz
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] London HUG domain expired
On Fri, Apr 23, 2010 at 1:24 PM, Bayley, Alistair wrote: Looks like the London HUG domain (londonhug.net) registration has expired. Neil Bartlett was the registrant. Neil: do you plan to renew? The whois database reports: Domain name: LONDONHUG.NET This domain name is up for auction for a limited time. To place a bid, visit: http://www.namejet.com And it appears that someone has already placed a $75 bid. The domain should be renewed promptly, before the grace period expires. Alternatively, sell the domain name before the grace period expires, and use the proceeds to register a different name for several years. Regards, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unicode alternative for '..' (ticket #3894)
I wrote: My opinion is that we should either use TWO DOT LEADER, or just leave it as it is now, two FULL STOP characters. Simon Marlow wrote: Just to be clear, you're suggesting *removing* the Unicode alternative for '..' from GHC's UnicodeSyntax extension? Yes, sorry. Either use TWO DOT LEADER, or remove this Unicode alternative altogether (i.e. leave it the way it is *without* the UnicodeSyntax extension). I'm happy with either of those. I just don't like moving the dots up to the middle, or changing the number of dots. Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unicode alternative for '..' (ticket #3894)
My opinion is that we should either use TWO DOT LEADER, or just leave it as it is now, two FULL STOP characters. Two dots indicating a range is not the same symbol as a three dot ellipsis. Traditional non-Unicode Haskell will continue to be around for a long time to come. It would be very confusing to have two different visual glyphs for this symbol. I don't think there is any semantic problem with using TWO DOT LEADER here. All three of the characters ONE DOT LEADER, TWO DOT LEADER, and HORIZONTAL ELLIPSIS are legacy characters from Xerox's XCCS. There, the characters they come from were used for forming dot leaders, e.g., in a table of contents. Using them that way in Unicode is considered incorrect unless they represent text that was originally encoded in XCCS; in Unicode, one does not form dot leaders using those characters. However, other new uses are considered legitimate. For example, HORIZONTAL ELLIPSIS can be used for fonts that have a special ellipsis glyph, and ONE DOT LEADER represents mijaket in Armenian encodings. So I don't see any reason why we can't use TWO DOT LEADER to represent the two-dot range symbol. The above analysis is based in part upon a discussion of these characters on the Unicode list in 2003: http://www.mail-archive.com/unic...@unicode.org/msg16285.html The author of that particular message, Kenneth Whistler, is of the opinion that two dots expressing a range as in [0..1] should be represented in Unicode as two FULL STOP characters, as we do now in Haskell. Others in that thread - whom Mr. Whistler seems to feel are less expert than himself regarding Unicode - think that TWO DOT LEADER is appropriate. No one considers replacing two-dot ranges with HORIZONTAL ELLIPSIS. If we can't find a Unicode character that everyone agrees upon, I also don't see any problem with leaving it as two FULL STOP characters. Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: I accidentally the Prelude
I wrote: I was suggesting that whenever the Prelude fails to load, the error message should contain that hint. hmm, I'll think about that. Is it not enough to see a compilation error pointing to the file Prelude.hs? Seems obvious in the context of this thread. But not being in the middle of reading the thread, I am certain that this hint would save me a lot of time and anguish. And it clearly would have done the same for Josef. it's probably not that bad, actually: $ ghc --make hello [1 of 2] Compiling Prelude ( Prelude.hs, Prelude.o ) [2 of 2] Compiling Main ( hello.hs, hello.o ) hello.hs:1:8: Not in scope: `putStr' You can pretty clearly see what happened there. When something goes wrong with a basic system component like the Prelude, the natural reaction of most people is panic. I've been getting file system corruption lately on a removable hard disk - could it be that? Did I cause this when I moved around some system directories the other day? Are my different copies of GHC getting mixed up with each other's files? It's hard to overestimate how much a soothing message from GHC is appreciated in that kind of situation. Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: integer-simple by default
Isaac Dupree: We could try to find out how large Integers get, in practice, in existing Haskell code (this may be difficult to find out). Daniel Fischer wrote: Just as a data-point, my code rarely exceeds 128 bits (at least, beyond that performance isn't so important anymore). And Daniel, who is part of the Project Euler team, uses large integers far more than most people. As another data point, Python has also re-invented the GMP wheel, likely for the same licensing reasons. They have been using a simple implementation of Karatsuba multiplication for years. I have never heard of anyone complaining about it. Furthermore, they currently use naive multiplication and don't even bother with Karatsuba for less than about 2000 bits on most recent platforms. Regards, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: integer-simple by default
I wrote: As another data point, Python has also re-invented the GMP wheel, likely for the same licensing reasons. They have been using a simple implementation of Karatsuba multiplication for years. I have never heard of anyone complaining about it Greg Fitzgerald wrote: Looks like they swapped out their integer implementation for Python3 Interesting! This will be new in Python 3.2 - the first changes in many years. It's not exactly swapped out, but there are many changes. At first glance, it looks like better 64-bit support, a new division algorithm via floating-point, a new exponentiation algorithm using a 5-bits-at-a-time trick in some cases, optimized Read and Show instances (pardon the expression), a few other things. A lot of the new stuff seems to be from HAC. As before, everything is fully explained in expository comments inside the code, with references; a worthwhile read. Multiplication is still the same basic idea though - naive up to about 2000 bits, followed by just Karatsuba and nothing more. Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Type families and type inference - a question
Daniel Fischer wrote:
(Note: Surprisingly (?), if you load a module with
{-# LANGUAGE NoMonomorphismRestriction #-}
, the monomorphsm restriction is still enabled at the ghci prompt, so we
have to disable it for that again - or we could have loaded the module with
$ ghci -XNoMonomorphismRestriction Movie)
IMHO, the monomorphism restriction does not make sense at the
GHCi prompt in any case, no matter what you have or haven't
loaded, and no matter what your opinion of MR in general.
I recommend that you create a file called .ghci
in your home directory, and put into it the line:
:set -XNoMonomorphismRestriction
Then you won't be bothered by this anymore for things
that you type in at the prompt.
I think this may be scheduled to be fixed in a coming version
of GHCi.
Regards,
Yitz
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-beginners] Performance of parallel mergesort
This discussion definitely does not belong on the Haskell-Beginners list. Besides not being a topic for beginners, being there is keeping it under the radar of many or most of the people who work on these things in Haskell. I am moving the discussion to the GHC users list, as suggested by Antoine. For those joining us in progress, the first part of the thread starts here: http://www.haskell.org/pipermail/beginners/2009-December/003045.html On Mon, Dec 28, 2009 at 5:19 AM, Jon Harrop wrote: On Sunday 27 December 2009 20:56:51 Stephen Blackheath wrote: Jon Harrop wrote: This is something that concerns me. Lots of discussions of parallelism, including the Haskell literature I have read, neglect this critical problem of making sure that more time is spent doing useful work than spawning tasks (sparks). How is this solved in Haskell? Do you just put magic numbers in that work on the machine you're currently using? It is simply not true that Haskell literature neglects the question of spark granularity - this is very basic and is always covered. Read Real World Haskell (available free online). There's no 'magic number'. You must explicitly write your code to give the right granule size. There is no right granule size. That's the whole point: the optimum is a function of the machine. If you hardcode the granularity then your code isn't future proof and isn't portable. From chapter 24 of Real World Haskell on sorting: At this fine granularity, the cost of using par outweighs any possible usefulness. To reduce this effect, we switch to our non-parallel sort after passing some threshold. From the Sorting.hs file, parSort2 accepts a threshold d: parSort2 :: (Ord a) = Int - [a] - [a] parSort2 d list@(x:xs) | d = 0 = sort list | otherwise = force greater `par` (force lesser `pseq` (lesser ++ x:greater)) where lesser = parSort2 d' [y | y - xs, y x] greater = parSort2 d' [y | y - xs, y = x] d' = d - 1 parSort2 _ _ = [] From the SortMain.hs file, it is always invoked with the magic number 2: testFunction = parSort2 2 Moreover, their approach of subdividing a fixed number of times is suboptimal because it inhibits load balancing. Later, about parallelized IO, they give the code: chunkedReadWith :: (NFData a) = ([LB.ByteString] - a) - FilePath - IO a chunkedReadWith func path = withChunks (lineChunks (numCapabilities * 4)) func path where 4 is one magic number that gets multiplied by the magic number the user supplied via the +RTS -Nn command-line option. They make no attempt to adapt the granularity to the machine at all and rely entirely upon magic numbers. Consequently, their parallel sort that got a 25% speedup on two cores achieves a 30% slowdown on my 8 core. I don't know the exact cost of sparking, but in my experience it is quite small - so - as long as your granule is doing *some* real work, it should speed up. Can you quantify it, e.g. How many FLOPS? Jon Harrop wrote: The parallelism is obviously not obtaining any real speedup so something is wrong. But can anyone fix it? I've spent a bit of time measuring parallel speedup on real commercial projects, and this is what I've found: 1. ghc-6.12 performs significantly better than ghc-6.10, and has now been released, therefore don't use ghc-6.10. Ok. 2. The defaults generally work better than giving huge heap sizes. Your -K1 - maximum heap size per thread - will either do nothing or cause an artificial slowdown (I have observed this with the minimum heap size option). Don't use it, unless experimentation proves it makes things better. On the contrary, the Haskell program dies without it: $ time ./mergesort +RTS -N8 Stack space overflow: current size 8388608 bytes. Use `+RTS -Ksize' to increase it. [1]+ Done kwrite mergesort.hs real 0m33.320s user 3m29.397s sys 0m0.592s I had to add that -K command line option just to get the program to run to completion. 3. +RTS -s is well worth using. It breaks the time down into MUT (mutator) and GC (garbage collector). Its says 78.5% GC time (with GHC 6.10). 4. MUT parallelization is excellent, but the parallel GC is not so good. If your code is GC-heavy it can spend around half of its time garbage collecting, which doesn't parallelize so well, and this eats into the speedup. Ok. 5. There seems to be a scalability problem with the parallel gc for larger numbers of cores (namely 8). I am guessing somewhat, but my experiments tend to confirm the issue raised in Simon Marlow's (the implementor of GHC parallelization) recent paper that it's to do with stopping the world for gc. Do you mean this bug: http://hackage.haskell.org/trac/ghc/ticket/3553 If GHC's lack of perfection at this point in time makes Haskell look bad I don't
A few small points about GHCi command documentation in section 2.7
Please add to the documentation for :set prompt:
If you enclose \i{prompt} in quotes, you can use Haskell
syntax for String literals.
Actually, :set prompt is nearly useless without quotes, because
GHCi strips off trailing spaces from commands. We should either
add a space at the end of a prompt entered without quotes,
or just require quotes. Or at least change the help text
to be:
:set prompt \prompt\ set the prompt used in GHCi\n
so that people will know the right thing to do. Perhaps add
a few more words of explanation to the docs in section 2.7
once we decide which of these to do.
The :run command is not documented in section 2.7 - the
only mention of it is buried within the documentation for
the :main command. It is also not mentioned in helpText.
Thanks,
Yitz
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Data.List permutations
Hi Slavomir, Slavomir Kaslev wrote: inter x [] = [[x]] inter x yys@(y:ys) = [x:yys] ++ map (y:) (inter x ys) perm [] = [[]] perm (x:xs) = concatMap (inter x) (perm xs) I was surprised to find that not only my version is much simpler from the one in Data.List but it also performs better. I would like to suggest to change the current implementation in Data.List with the simpler one. Thanks for looking into this. A lot of work went into the permutations function in Data.List, most of it by Twan van Laarhoven, including studying the order in which the permutations are returned, laziness, and extensive performance testing. The result was compared against Knuth's algorithmic work on this topic. Your algorithm is indeed similar to one that was considered during that development process. See the following thread for the details: http://www.haskell.org/pipermail/libraries/2007-December/008788.html and continued in: http://www.haskell.org/pipermail/libraries/2008-January/008859.html Things do change with time, so it's always worthwhile to revisit these things and not take them for granted. If you can improve on this work, please let us know on the libraries mailing list. Also, it would be nice to add variations and combinations in the Data.List module. Personally, I disagree. I think those should go in a separate combinatorics library, not Data.List. As an example, take a look at the combinat package on Hackage: http://hackage.haskell.org/package/combinat But you don't have to agree with me. If you think that they should go into Data.List, propose it using the following procedure: http://www.haskell.org/haskellwiki/Library_submissions Regards, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.4
The (Interactive) Glasgow Haskell Compiler -- version 6.10.4 How to get it http://www.haskell.org/ghc/ I have a few comments about the Distribution Packages page that is linked from there: http://www.haskell.org/ghc/distribution_packages.html Debian: Remove the line Newer packages may be available in Haskell Unsafe. That stuff is very, very old. Mac OS X: Paragraph beginning Contrary to the recommendation at the top of this page... rather than using the alternatives below. It makes no sense. It appears to be referring to an older version of the page. Both 10.3 (Panther) and 10.4 (Tiger) are supported. should be changed to 10.4 (Tiger) and 10.5 (Leopard). The paragraph about the ghc-devel port should be removed, I think. The port still exists, but it doesn't seem to be actively supported since 6.7. Anyone who wants to use GHC HEAD will probably just build current HEAD manually. (Greg - is this correct?) Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Debian stable not supported?
The Debian ghc6 package for the stable distribution is currently back at GHC 6.6 - not surprising given the way stable works at Debian. There is currently no backport of a more recent GHC to Debian stable. I need GHC 6.8 for a project to run on a production server. That means it will be running Debian stable. Unfortunately, the so-called generic Linux binary distribution package for GHC 6.8.3 does not work on the current, up-to-date Debian stable distribution because it is too old. In my case, and I suspect for many people, the production server running stable is on a low-cost hosted VPS. That kind of platform doesn't have nearly enough memory and disk space to compile GHC. So even that is not an option. I know that in the past Haskell was used exclusively for research, but nowadays shouldn't it be possible to use Haskell also for production-quality projects? With help from Igloo and thetallguy on #ghc, for which I am grateful, I was finally able to get a working GHC 6.8.3 on my production server, but only after jumping through a lot of hoops. It involved setting up a Debian-stable-like environment in a chroot on another computer, building GHC there from source, and manually moving all of the appropriate files up to the server. Before I delete that chroot build environment - could it be useful for making GHC 6.8.3 available to others? If someone points me in the right direction, perhaps I could create a binary tarball and/or backport deb. Or at least record somewhere the basic steps of how to get a recent GHC in this situation. Thanks Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Re: ANNOUNCE: protocol-buffers-0.2.9 for Haskell is ready
Chris Kuklewicz wrote: Who can suggest a way to cast from Float to Word32 and Double to Word64 using ghc? The actual task is that I need to write out the Float as a little endian sequence of four bytes and also be able to read it back in. The writing and reading are done in Put and Get monads to ByteString (from the binary package). I think alloca-like hacks is really the wrong direction and asking for trouble. You are trying to translate between platform-dependent native floats, and IEEE floats in a specified platform-independent binary format for Google. So use encodeFloat/decodeFloat - fast primitives in GHC - on the native side, and a hand-written Binary instance for the exact format you need on the Google side. My opinion, YMMV. Regards, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Orphan Instances
Moving this side point to the ghc users list... Ashley Yakely wrote: What is an orphan instance, and why do we care about them? Simon Peyton-Jones wrote: They are documented in the GHC manual http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compilation.html#orphan-modules Thanks for the nice explanation there. Since you brought it up, though, the explanation might be made even clearer with two small changes: 1. The term instance head is used throughout the explanation, beginning already with the second paragraph (the head of the instance...). However, that term is only defined near the very end '(the part after the =)'. For those who do not already know the surprise ending, this makes the explanation read rather like a mystery story. 2. I believe that the text by setting a = Int was meant to be by setting a = T. Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problems interrupting IO with -threaded
Judah Jacobson wrote: I'm writing a program that reads input from the user but should also handle a ctrl-c... It works fine compiled without -threaded, but with -threaded it blocks forever after a ctrl-c. Simon Marlow wrote: Ah, this is a consequence of the change we made to stdin/stdout/stderr so that they no longer use O_NONBLOCK, but with -threaded they use blocking foreign calls instead... I don't see a good workaround... Unix semantics just isn't the right thing when it comes to non-blocking I/O. If only there were non-blocking read()/write() system calls, we'd be fine. I believe you that the Unix semantics may not be very pretty. But all modern high-level programming languages have a getChar that can be interrupted by ^C. Can't we just do what they all do? This is basic, essential functionality that we use every day. In my opinion, Judah should file a bug, and it should be marked high priority. Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [GHC] #2153: GHCi does not have a :source command to load further .ghci files
Claus Reinke wrote: i tried at the time to get others to post their .ghci files at well, and share their favourite tricks, but there weren't many responses. OK, OK. I just posted Customized GHCi interactive environments to wiki. It's a simple but very powerful trick that I use all the time. I hope others will also post their favorites. -Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: swap (x, y)
Hi Neil, Neil Mitchell wrote: You can search for it in the standard libraries using Hoogle: [something mangled] I think you were trying to suggest searching for (a,b)-(b,a) by using a URI directly. My mail reader justifiably mangled your proposed URI, as would any non-broken mail reader, since it included the illegal character ''. See RFC 2396. You would have to use http://haskell.org/hoogle/?q=(a,b)-%3E(b,a) Easiest just to say: Go to http://haskell.org/hoogle and search for (a,b)-(b,a). Regards, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Tiger installer [was: Re: ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel)]
Manuel M T Chakravarty wrote: The file length is correct. MD5 (Public/Web/haskell/GHC-6.9.20080213-i386.dmg) = cc76dea615234aa83d85ef5c30021828 Bingo! Thanks. I wrote: In the readme, you say that I require Xcode 3.0. Tiger came with Xcode 2.4.1, and I have not updated it. Could that be part of the problem? ...your Xcode version should be fine. OK, good. http://www.cse.unsw.edu.au/~chak/HelloWorld.tar.bz2 It contains HelloWorld-Leopard and HelloWorld-Tiger. Please try to run them both. I believe HelloWorld-Leopard will also give you a bus error, but I hope HelloWorld-Tiger will work. $ ./HelloWorld-Tiger Hello World! $ ./HelloWorld-Leopard Bus error Yay! Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Tiger installer [was: Re: ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel)]
Manuel M T Chakravarty wrote: Try this http://www.cse.unsw.edu.au/~chak/haskell/GHC-6.9.20080213-i386.dmg I got it, but there were some download problems. I hope the file is intact. It has exactly 44740924 bytes. Perhaps you could send me an md5sum to be certain. Have a look whether that installs on Tiger (I am pretty sure it will) It did. and whether you can run /usr/bin/ghci (not so sure about that). It didn't. $ /usr/bin/ghci Bus error In the readme, you say that I require Xcode 3.0. Tiger came with Xcode 2.4.1, and I have not updated it. (I tried once, but the download was so huge that I decided to forget it unless there was some real need.) Could that be part of the problem? Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel)
Manuel M T Chakravarty wrote: I'd also be nice to have a cool logo/icon. Don Stewart wrote: Someone want to clean up the classic GHC logo? http://www.cse.unsw.edu.au/~dons/images/happy-dino.jpg :) The Clyde Arc in Glasgow, combined somehow with a lambda, could be the basis of a striking logo. Unfortunately, that bridge is suffering from some serious structural and safety issues these days, so perhaps that is ill-advised... -Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel)
Manuel M T Chakravarty wrote: Finally, you can have the glorious GHC in a format satisfying the discerning Mac user Fantastic news! Thanks! The GHC binary in the package links statically against GNU readline (to provide editing capabilities at the GHCi prompt). This is fine as GHC's BSD3 licence is compatible with readline's GPL, and it does *not* affect programs compiled with GHC at all. Thank you for clarifying this. The above package is for Intel Leopard... it should be possible to build packages on Leopard that run on both Tiger and Leopard. (I could give that a try if anybody with a Tiger box is willing to play guinea pig.) I volunteer. What do I need to do? Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Read instance of StdGen returns no parse
Denis Bueno wrote: the Read StdGen instance should never fail. However, in GHC 6.8.2, it appears to: It first fails for me on strings of length seven. You need to use fst . head . reads instead of read. The Read instance of StdGen only uses part of the string, and politely gives you back the unused portion so that you can use it for something else. But the side effect of that is that you can only use reads, not read. Using read means that you guarantee that the entire string you supply will be consumed by the parser. When you supply an arbitrary string to the parser for StdGen - i.e., not one produced by the Show instance - there isn't any way for you ever to guarantee that, because the exact amount of the string that will be needed is an internal implementation detail. (Whereas the use of head with reads is safe, because there is guaranteed to be some parse.) The documentation in System.Random is a bit misleading. It says the read instance of StdGen has the following properties: It guarantees to succeed on any string... The word read should really be Read instead. It also wouldn't hurt to mention that the read *function* may fail, so use reads instead. Hope this helps. -Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Integrating editline with ghc
Christian Maeder wrote: Where are the users that use the functionality not supported by editline's emulation layer? (Shout now or be quiet ever after) I only wanted to find out which user group would need to change readline to editline and (if following my suggestion) which group readline to GPL-readline in cabal files, and which of the two user groups is bigger. Since it's not clear yet, what portion of readline can be emulated by editline this is difficult to estimate. It is always impossible to estimate this, because users are not required to register anyplace, and they are not required to read this or any other discussion list. We should not cause people's programs to break silently by changing a fundamental API, unless there is no alternative. In this case there is a reasonable alternative. Anyone who wants to change over to editline - native or readline-compatible - can easily do so, at their leisure. Anyone who wants things to stay the way they are can do nothing. Do you see any problem with that approach? I think that in most cases, people are happy with readline and will not need to change. Nevertheless, making editline available in this way is critically important, because certain projects are difficult or impossible without it. And of course, it's a great improvement for the Mac platform. So your work on this is highly appreciated. Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Integrating editline with ghc
Christian Maeder wrote: 3. if ghci is going to use editline... then readline would not need to be a core package und users might need to install package readline explicitly. OK, I get it. Even if we leave readline as it is, so that the package system will theoretically not force the person to take action, in practice action will be needed the next time the person upgrades GHC. So you would like to minimize overall work of changing packages over all users. Even so, I think it is more important to minimize confusion over users who are not aware of this whole discussion, and may have minimal knowledge of the package system. They don't want to have to figure things out - they just want it to keep working as before. The need to re-install some package due to the shrinking GHC library core is an annoyance all GHC users are aware of by now. You figure out what has disappeared, and you install it. Changing the semantics of the readline package would add to the confusion, I believe. Also, I think in general we should do what makes the most sense within the package system itself. GHC library core shrinkage is an external issue, though I agree that in practice it will affect everyone. So I am still in favor of keeping readline as it is. Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Integrating editline with ghc
Hi Christian, Christian Maeder wrote: ...Even better if the current package readline is renamed to old-readline and readline-compat to readline. I have been trying to understand why you want to do that. What would we gain? Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Integrating editline with ghc
Christian Maeder wrote: The extended packages 2 could go under extra libs or hackageDB, while 1 remains a boot package for ghc that can link to editline on macs and readline under linux, but has the same interface and package name! I would hope that ghc will link to editline-ext on all platforms. That gives ghc the functionality it needs without getting into legal trouble with the license. Then those who want the full readline interface can install readline-ext, and those who want the full editline interface can install editline. -Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Re[4]: bindist for Intel MacOS X 10.4 (Tiger) with static libs
Bulat Ziganshin wrote: for me, GMP is much more problematic issue. strictly speaking, we can't say that GHC is BSD-licensed because it includes LGPL-licensed code (and that much worse, it includes this code in run-time libs) Manuel M T Chakravarty wrote: ..binary distributions of GHC that include libgmp.a and statically link it into compiled code... All that is needed to make this legal is to (a)... (b) give users access to another version of the proprietary program that links GMP dynamically. Wow, I didn't realize that. Now I understand Bulat. In a project of any serious size and complexity, the use of static or dynamic linking is often architechted in and cannot be changed. So LGPL is really bad for a general purpose compiler like GHC. We've got to make GMP optional, or get rid of it. -Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Integrating editline with ghc
Isaac Dupree wrote: GHC is in no legal trouble whatsoever... only if proprietary Haskell code uses the readline library and doesn't switch to using the editline backend. Agreed. I didn't mean that GHC itself was ever in any legal trouble. But as a compiler, it must be possible for users to compile with it without getting into legal trouble. On Linux here I have readline installed and not editline currently, so it seems silly to require installing editline by default (default meaning if I don't want to, I have to figure out the right configure flag to give to allow readline to be used). It makes sense to use editline by default for Mac and Windows builds though, where readline isn't native, I guess. Statically linking to editline for binary builds would be alright (not exporting any readline to ghc-compiled programs by default?). How is Search for editline first; if not found, try to use readline? Yes, I also have a Debian box, and I agree. Regards, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: gmp
Don Stewart wrote: However, its buried in the rts/distributed with the runtime, so that users may optionally use that version, rather than finding and installing their own external gmp package. On almost all platforms though, the distributed-with-ghc gmp is unused. But doesn't that mean that it gets linked into any program compiled with ghc? If so, that is not a good choice for a just-in-case mp lib. -Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: gmp
Don Stewart wrote: on any system where an external libgmp is available, it will be dynamically linked into the generated haskell programs, and in-tree gmp isn't used at all (or compiled, or installed) So on linux and *bsd, that should be fine. On Mac OS X (as a special case of *bsd), we have that framework thing. It is a real pain, and it also requires the framework on any client machine where you install your ghc-compiled binary. OK for the time being, but it would be really, really good to be able to compile ghc without gmp. This idea of a Mac OS X binary with statically-linked gmp is nice, it is really convenient. But someone needs to completely clarify the license issues in that case, and make it completely clear to all users. What is the situation on Windows? Does the standard GHC binary on Windows have dynamically linked gmp for binaries produced by ghc? Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Integrating editline with ghc
Christian Maeder wrote: ghc will link to libedit if it is available on your platform, but the Haskell package will still have the name readline and give ghc all the functionality it needs (without licence problems). Only the current readline Haskell package needs libreadline and supplies more functionality than needed by ghc. This extra-functionality should go into a new Haskell package readline-ext (that will only be rarely needed). That is one possible solution for GHC. The problem is that the readline package currently provides System.Console.Readline with the full interface to readline. It has been that way for eons, so we must assume that there is software out there that uses all of it, even though ghc only uses part of it. We don't want to break those programs, and that includes creating a situation where the programs will no longer compile unless the user installs some new package with a different name. So I think the package named readline needs to continue to provide both the interface and the implementation for full readline. However, if needed, it can provide some or all of the pieces vacuously by simply depending on some new packages. On the other hand, GHC should depend only on a subset of readline that can optionally be provided by editline instead. And in fact, editline should be preferred over readline when available. There should be a smooth upgrade path to the new system for all users, both of GHC and the readline, for any combination of versions installed of any of those things. Everything should happen automatically as people gradually upgrade GHC and/or various readline-like packages to new versions. Can we meet all of those goals? Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: bindist for Intel MacOS X 10.4 (Tiger) with static libs
Isaac Dupree wrote: It's also possible to just distribute, for example, the .o file(s) and a way to link them with a GMP to get the final result; this doesn't even reveal your source-code any more than your program being dynamically linked, at least if you do it right -- right? It doesn't matter. In a typical commercial development environment, you just don't have any control over that. At some companies I've gotten free software included in products in a way that required certain extra files from the 3rd party to be included inside our installation package - such as a source code tarball, GNU license, and such. It wasn't easy, but I've done it. But to change the way our own code is distributed - forget it. If you happen to be in a situation where the LGPL thing can be integrated as a dynamic library, fine. Otherwise, I don't see it. -Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Re[2]: bindist for Intel MacOS X 10.4 (Tiger) with static libs
Thorkil Naur wrote: Readline is free software, distributed under the terms of the GNU General Public License, version 2. Bulat Ziganshin wrote: in short, that means that software compiled with this compiler AND distributed to general audience, should have GPL-compatible license (i.e. GPL or BSD-like) (as far as i understand GPL/LGPL terms) Any software compiled with this compiler, or only software that uses System.Console.Readline? Isn't this the same on all platforms? If what you are saying is correct, then isn't it required for any program compiled with any readline-enabled GHC to have a GPL-compatible license? I don't think that's right, but IANAL. -Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Re[4]: bindist for Intel MacOS X 10.4 (Tiger) with static libs
Bulat Ziganshin wrote: in short, that means that software compiled with this compiler AND distributed to general audience, should have GPL-compatible license (i.e. GPL or BSD-like) (as far as i understand GPL/LGPL terms) Any software compiled with this compiler, or only software that uses System.Console.Readline? any software that links with readline.a or gmp.a. which actually means every program because even if you don't use GMP, it's probably still linked in No, GMP is only LGPL, not GPL. So it only needs to be LGPL compatible unless it uses readline. Isn't this the same on all platforms? If what you are saying is correct, then isn't it required for any program compiled with any readline-enabled GHC to have a GPL-compatible license? I don't think that's right, but IANAL. for me, GMP is much more problematic issue. strictly speaking, we can't say that GHC is BSD-licensed because it includes LGPL-licensed code (and that much worse, it includes this code in run-time libs) LGPL specifically allows BSD-licensed software to link in object code that is LGPL. But, basically, you need to include the source code of the LGPL parts in your distribution package, and mention in your license notice that part of the code is LGPL. If LGPL is a problem for your project, that is hard to get around right now. We have been reading about efforts to allow alternative multi-precision libraries with GHC. That is very important work, but apparently difficult. However, LGPL is often not a serious problem, even for commercial products. GNU readline, on the other hand, is never suitable for non-free software. The authors of the GNU readline library have publicly stated that the whole reason they are using GPL is to make sure that no non-free software ever uses it. So this work to use editline instead of readline in GHC is very important for all platforms, not just the Mac. editline is BSD licensed. Therefore, I think the focus should be to get the best readline compatibility possible by using a sufficiently recent version of editline. If that causes problems on a specific platform, like Tiger, that is a lower priority. (I say that even though I myself am on Tiger.) We can work around that separately. -Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.8.2
I wrote: Removing support for %HOME% has suddenly broken many programs. If people don't like it, we can consider deprecating it in some future version of GHC, but for now it should put back. Simon Marlow wrote: Only GHCi has changed here. Perhaps you're under the impression that we recently changed the behaviour of getHomeDirectory? In fact, it was introduced in GHC 6.4 and has always had the same behaviour, calling SHGetFolderPath on Windows. Thanks, Simon. Yes, I was originally under that mistaken impression, but Duncan set me straight. I am glad that %HOMEPATH% is not being used, though ShGetFolderPath sometimes gives the wrong answer on Vista. So having a customizable notion of home directory on Windows would be a new feature for getHomeDirectory. For GHCi it would be rescuing a recently removed one. -Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Re[2]: ANNOUNCE: GHC version 6.8.2
Hi Felix, You have described your own style of using some of the Window's Known Folders. In my opinion your style is a bit Unixy, but that's fine, you should be allowed to do it that way in GHC. But GHC should not force others to do it only that way. btw, years ago I used to use the Profile folder as if it were a home directory. It caused me no end of problems. But if it works for you, it should certainly be possible for you to do it that way. I wrote: The %HOMEPATH% variable should definitely not be used. The folder that it points to is not a home directory and should not be used that way. Felix Martini wrote: That's not correct. It is the user's home folder aka user profile folder No, the two are not the same. It is the User Profile folder. It is not a Unix-style home directory - there is no such concept on Windows. The two are used very differently. see e.g. http://support.microsoft.com/kb/101507. That is an ancient article about NT 4.0, and even then it was only about how to deal with legacy scripts back in those days. The environment variables %homedrive% and %homepath% are set by Windows for use by (legacy) scripts. Think of them as readonly variables. Modifying environment variables is not a Windows convention. There are other ways to change the location of a user's profile folder. Correct. That is one of the reasons that this folder is not suitable for use as a home directory. By reasonable alternative, I mean a way that users can configure GHC's notion of home directory at run-time on Windows. This is not a task for GHC, but Windows itself. GHC should just use the win api to ask Windows for the user's home folder. That is the current behaviour. It is not the current behavior, and it is not a task for Windows. Windows will never do it. There is no such thing as a home folder on Windows. The new current behavior is to ask the Windows API for the user's Profile folder, and force it to be used as if it were a home directory. That is wrong. As long as GHC has a built-in notion of home directory, which doesn't exist on Windows, there needs to be a user-configurable way to specify what to do instead, as there always was until now. It depends on a lot of factors - exactly how are you using this home directory, how does it interact with other apps, details about the platform, etc.. If nothing is specified, then, as a last resort, there is no choice but to use the Profile folder as the default. As Duncan Coutts pointed out, the getAppUserDataDirectory function makes much more sense - that is a notion that ought to exist on all platforms. This is the ideal solution for ghci on Windows. Yes, that is the right place to put the .ghci file. Ach, here I go again. I've got to get back to work... Regards, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Re[2]: ANNOUNCE: GHC version 6.8.2
Removing support for %HOME% has suddenly broken many programs. If people don't like it, we can consider deprecating it in some future version of GHC, but for now it should put back. I would say it is quite ironic that some people are arguing against this by saying that it will lead to more bug reports. It is *not* trivial to wrap the function in question, and it is not more correct. The current behavior is not more WIndows native - it is arguably much worse. The %HOMEPATH% variable should definitely not be used. The folder that it points to is not a home directory and should not be used that way. But if there is no other way to provide a value for getHomeDirectory, I guess that is still better than throwing a run-time exception, but at least obtain the path in a somewhat Windows-friendly way by using the API properly. It is just not true that using %HOME% creates problems. This is a widespread convention, in active use. Admittedly ad-hoc, but it works. Does anyone know of even a single incident in which this created a problem? Better native Windows integration is definitely an important goal. The whole idea of a .ghci file is very Unixy, for example. There is a lot of work to be done in this direction. Pulling the rug out from under %HOME% without providing a reasonable alternative is not the way to begin. By reasonable alternative, I mean a way that users can configure GHC's notion of home directory at run-time on Windows. Truthfully, I don't think this should be the first priority for better Windows integration. Wouldn't our time be better spent on Visual Studio integration and WinAPI support? Not to mention .NET... Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Re[2]: ANNOUNCE: GHC version 6.8.2
Hi Seth. Sorry, my asterisks were not at all meant to be a flame. Please accept my sincere apologies if it appeared that way. I wrote: It is *not* trivial to wrap the function in question, and it is not more correct. Seth Kurtzberg wrote: Why is it *not* trivial to wrap the function? Regardless of whether you like the resulting solution, it is undeniably trivial to change the name of a function, create a new function with the (original) name, and have that new function... implement different behavior... That may be trivial when writing a new program, but it may also be difficult or even impossible when the code is already in use and shared among many other existing programs. Summarizing: o The current (until recently) method has been in place for a long time, and works fine. o It follows a widely-used convention, though arguably a somewhat messy one. o It provides a prominent behavior, so changing it suddenly is very painful. o It is dubious whether the change, as implemented, achieves its intended purpose at all, namely better Windows integration. o Even if you believe that it does, the small amount of value it provides is not worth the cost. I support providing a default value for the home directory when the user does not specify one. It would be nice if this could be done in a more Windowsy way. Since another of my points is that we are focusing too much on this issue, I will say no more and gracefully accept whatever the community decides at this point. Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.8.2
Juanma Barranquero wrote: In fact, it'd be better if GHC/GHCi would do what Emacs on Windows does: use HOME if defined, else use ShGetFolderPath to find the Windows-defined home directory. I agree, that is closer to the correct behavior. Except that on Vista ShGetFolderPath is deprecated. Use ShGetKnownFolderPath instead on Vista. On Vista, users may have their settings stored somewhere else on the network. The old interface does not support that. Claus Reinke wrote: in the interest of backwards-compatibility, perhaps. but as the links i gave should demonstrate, there is no %HOME% on windows, unless you invent it. %HOMEPATH% is *not* the usual Windows native way of finding a place for files like dot-ghci. Your link to MS documentation of %HOMEPATH% for XP doesn't use the word legacy, but it certainly smells that way to any modern Windows developer. It is a throwback to the old DOS days. I was unable to find any mention of %HOMEPATH% at all for Vista on the MS site, though it does still seem to exist. Anyone have a link? Note that the old cmd.exe shell itself is deprecated on Vista - the new MSH shell is based on .NET. There I think you would use the IKnownFolders interface to get (something vagualy analagous to) the home directory, not %HOMEPATH% Also, %HOMEPATH% is unsuitable for a Unix-style home directory on pre-Vista systems, because it usually points to a directory with spaces in its path name. %HOME% is the de-facto standard for Unix-like shell applications that were ported to Windows and need a home directory. If someone sets that, it means they want to use the folder in that way. And yes, that is the way GHCi has been working until now, so I think it should still be supported if someone sets it. Otherwise, the native Windows way is via ShGetFolderPath on pre-Vista, and ShGetKnownFolder on Vista. The installer should create a GHC subfolder of that, and that is where dot-ghci should go on Windows, unless %HOME% is set. now, imagine the surprise when, in your %HOME%/.ghci, you do home - System.Directory.getHomeDirectory System.Directory.getDirectoryContents home and the script ghci claims to be executing isn't even there!-) Yes, that is a problem. A user who sets %HOME% has indicated that this should be used. I think that should be returned by getHomeDirectory. If you like using Documents and Settings... no one is forcing you to set %HOME% to anything, you can just use the default settings. Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] class default method proposal
Simon Peyton-Jones wrote: Given instance C T where ..., for any method 'm' not defined by ...: for every class D of which C is a superclass where there is an instance for (D T) see if the instance gives a binding for 'm' If this search finds exactly one binding, use it, otherwise behave as now A better rule would be: If this search finds exactly one binding that is minimal in the partial ordering defined by the superclass hierarchy, use it, otherwise behave as now. Would that be much harder to implement? -Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci changing 'm' to 'g'
Sigbjorn wrote: This was a hack to work around similar behaviour when starting up GHCi, Notice that my workaround is only applied upon startup, not in the REPL. = floating the hackery inward could just save the day. OK. Simon Marlow wrote: The underlying bug is in the Windows CRT, or perhaps a deeper level. Perhaps. But eval-print loop shells in other languages do not seem to exhibit this problem afaik, so there must be some way to do it. E.g., glancing through the source code of the Python interpreter, they don't seem to do anything special. They flush like we do, and they set O_BINARY, and that's about it I think. Unless I missed something. Regards, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci changing 'm' to 'g'
Greg Fitzgerald wrote: Running 6.8.1 on Windows XP, typing 'main' while :r is still processing causes the 'm' in 'main' to morph to a 'g'. Olivier Boudry wrote: it (also works with :l). Stefan O'Rear wrote: It's very old. http://hackage.haskell.org/trac/ghc/ticket/831 But these observations indicate several clues that do not yet appear in the Trac ticket: 1. Occurs on Windows (I can't reproduce it in on Mac OS X Intel or Debian Lenny) 2. Occurs also with :r and :l, not just evaluating an expression. Perhaps someone with with a Trac login should make note of them. -Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci changing 'm' to 'g'
Quoth InteractiveUI.runGHCi: case maybe_expr of Nothing - do #if defined(mingw32_HOST_OS) -- The win32 Console API mutates the first character of -- type-ahead when reading from it in a non-buffered manner. Work -- around this by flushing the input buffer of type-ahead characters, -- but only if stdin is available. flushed - io (IO.try (GHC.ConsoleHandler.flushConsole stdin)) case flushed of Left err | isDoesNotExistError err - return () | otherwise - io (ioError err) Right () - return () #endif -- enter the interactive loop interactiveLoop is_tty show_prompt Could this be related somehow? -Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.8.1 on Mac OS X 10.4 (Tiger)
Hi Christian, binary distributions of GHC 6.8.1 for Mac OS X 10.4 (Tiger) Great, thanks! Can this be posted together with the other binary distributions at: http://haskell.org/ghc/download_ghc_681.html and also Manuel Chakravarty's Leopard build? Warning: this binary distribution does NOT contain documentation! The links to get the documentation are at: http://haskell.org/haskellwiki/GHC For the HTML version, the links are: http://www.haskell.org/ghc/docs/latest/users_guide.html.tar.gz http://www.haskell.org/ghc/docs/latest/libraries.html.tar.gz http://www.haskell.org/ghc/docs/latest/Cabal.html.tar.gz -Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: isSpace is too slow
Duncan Coutts wrote: iswspace... We could short-cut that for ascii characters. Also, '\t', '\n', '\r', '\f', and '\v' are contiguous. So isSpace c =c == ' ' || c = '\r' c = '\t' || c == '\xa0' || c '\xff' iswspace (fromIntegral (ord c)) /= 0 That makes 4 comparisons or less in the common cases. If we assume that ascii characters greater than '\xa0' occur much less often than average, we can short-cut those also and cut it down to 3 or less. Note that the first space character above 255 is '\x1680' (according to isSpace). -Yitzchak ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci confused by hi files
I wrote: I have observed the following weird behavior: ...ghci's ability to recognize the methods of the class seems to vary depending on whether or not hi files exist for the modules. Daniel Fischer wrote: Pertinent to this is section 3.4.3 of the user's guide, What's really in scope at the prompt. For compiled modules, only the exports of these are in scope. So this is documented behaviour. OK, thanks, I see that now. But I would have only expected that to apply to modules that are _only_ compiled. If the source code is also available, why should I be penalized for compiling it? Preferring the source code over the compiled code by default would be much more convenient for iterative debugging. But if that cannot be the default, it would be nice if it were at least an option. Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghci confused by hi files
I have observed the following weird behavior:
When I define an instance of a certain MPTC
in a separate module from the definition of
the class, ghci's ability to recognize the
methods of the class seems to vary depending
on whether or not hi files exist for the modules.
I am using the current Debian build of GHC 6.6.
Below are a set of three files that reproduce the
behavior, and a shell session that demonstrates
it.
Before I compile the program, ghci works fine.
After I compile with ghc - thus generating hi files -
ghci gets confused. Then I delete the hi files
and everything is fine again.
Thanks,
Yitz
-- File Oops.hs
{-# OPTIONS_GHC -fglasgow-exts #-}
module Oops where
class Oops a b c | a - b c where
foo :: a - b - a
-- File Whoops.hs
{-# OPTIONS_GHC -fglasgow-exts #-}
module Whoops where
import Oops
instance Oops String Int Bool where
foo x n = show (x, n)
-- File runWhoops.hs
module Main where
import Whoops
import Oops
main = putStrLn $ foo bar 42
$ ghci Whoops
/ /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98.
Loading package base ... linking ... done.
[1 of 2] Compiling Oops ( Oops.hs, interpreted )
[2 of 2] Compiling Whoops ( Whoops.hs, interpreted )
Ok, modules loaded: Oops, Whoops.
*Whoops foo baz 7
(\baz\,7)
*Whoops Leaving GHCi.
$ ghc --make runWhoops.hs
[1 of 3] Compiling Oops ( Oops.hs, Oops.o )
[2 of 3] Compiling Whoops ( Whoops.hs, Whoops.o )
[3 of 3] Compiling Main ( runWhoops.hs, runWhoops.o )
Linking runWhoops ...
$ ghci Whoops
/ /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98.
Loading package base ... linking ... done.
Ok, modules loaded: Oops, Whoops.
Prelude Whoops foo baz 7
interactive:1:0: Not in scope: `foo'
Prelude Whoops Leaving GHCi.
$ rm *.hi
$ ghci Whoops
/ /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98.
Loading package base ... linking ... done.
[1 of 2] Compiling Oops ( Oops.hs, interpreted )
[2 of 2] Compiling Whoops ( Whoops.hs, interpreted )
Ok, modules loaded: Oops, Whoops.
*Whoops foo baz 7
(\baz\,7)
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] Fundep broken in GHC 6.6
Simon Peyton-Jones wrote: I just applied this rule http://www.haskell.org/ghc/docs/latest/html/users_guide/type-extensions.html#id3170412 In this case the type of newBoard is newBoard :: (Game b mv e, MonadStaet b m) = m () Following the rules in that manual section, this type sig is (now) ok. Does that answer your qn Yes, I think it does. I guess I'll only really know when I can either get my hands on 6.6.1, or successfully compile GHC from darcs. Thanks! -Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] Fundep broken in GHC 6.6
On 12 November 2006 I wrote (on the haskell list): class Error e = Game b mv e | b - mv e where newBoard :: MonadState b m = m () ... Since MonadState has the fundep m - b, the type of newBoard fully specifies all of the class parameters But GHC 6.6 complains... Simon Peyton-Jones wrote: I have committed a fix to the HEAD that relaxes the condition, and allows this program. It should appear in 6.6.1 also. Thank you! Am I correct to assume that this fix only applies to the specific case of unspecified class parameters in method declarations? And not any of the other cases where fundeps on class constraints resolve type ambiguity but are ignored by GHC, such as instance declarations? Does the fix actually look at the fundeps in the class constraint on the method, or just relax the requirement that all class parameters be specified in every method? If it is the latter, as I suspect, then is the requirement always relaxed, or only when there is a class constraint on the method? Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
