Re: runghc -fdefer-type-errors
On Mon, Mar 11, 2013 at 9:33 PM, Isaac Dupree m...@isaac.cedarswampstudios.org wrote: On 03/11/2013 07:04 PM, Simon Peyton-Jones wrote: Aha. It is indeed true that ghc -fdefer-type-errors -w does not suppress the warnings that arise from the type errors; indeed there is no current way to do so. How to do that? To be kosher there should really be a flag to switch off those warnings alone, perhaps -fno-warn-type-errors So then -fwarn-type-errors is on by default, but is only relevant when -fdefer-type-errors is on. Once -fdefer-type-errors is on, -fno-warn-type-errors and -fwarn-type-errors suppress or enable the warnings. -w would then include -fno-warn-type-errors. GCC has a concept -Werror=unused-variable for example: each warning can be disabled, a warning, or an error. If GHC had that, we could have type-errors be a warning whose default state is -Werror. That's cleaner in a certain way, but it also seems fishy. Just throwing the idea out there. I don't know which way GHC would like to go, but I can comment on the GCC feature as I have direct experience here. For a long time I was very reluctant to the fine-grained warning categories; rather I preferred a much coarser grained warning categories; my thinking was that warnings or questionable coding practices come in cluster (I still do.) Remember that the more nobs you give user to control the compiler, the larger your test matrix becomes and the higher is the probability of untested and/or incoherent compiler switch combinations. However, several fellow GCC developers felt otherwise -- many citing the pressure of the competition (e.g. icc, clang, etc.), so I eventually gave in but under the condition that we still maintain the coarse-grained warning categories (e.g. -Wall, -Wextra, etc.) and display in the diagnostics how users are to turn off a specific warning they did not like. I suspect that if users frequently need to turn off a warning, then that warning should probably be off by default. Most users rarely want to specify long (and arcane) command lines; very few want to litter their otherwise pretty programs with lines of pragmas (no matter how much effort was spent in designing the syntax.) -- Gaby ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On Mon, Feb 11, 2013 at 2:46 AM, Joachim Breitner m...@joachim-breitner.de wrote: Hi, one remedy to the problem could be better infrastructure: * More automated test-building of packages on hackage (including test suites) with various GHC releases, and better display of the results. This way, library authors would not have to manually build their library to see if they work with the latest compiler. * Automatic test building of packages with explicit relaxation of the dependencies, to suggest dependency relaxation that would work without code changes (from my work at Debian, in most cases only meta-data changes are required to support newer versions of dependencies, including core libs). * A more liberal attitude to changing other peoples packages’s metadata to fix the dependencies – either to exclude broken combinations or to expand the range. Preferably online, similar to the edit button in github, and checked by the above CI infrastructure. This way, it would be easier for libraries to support newer GHC releases without having to give up supporting older releases. But I know that development of Hackage is not something that seems to be happening a lot right now, and as I don’t help, I’m not complaining. So consider this a side notice and carry on discussing :-) Greetings, Joachim The issue is largely social problem that I suspect technological solutions won't solve. Yes, it would be nice to have better infrastructure. However, at the end of the day, when the automated tests say an API or ABI set has been broken, a non-technical decision needs to be taken (should it be part of the next release, or should it be delayed or removed?) And you will be back to square one. Part of the problem is what happens to successful programming languages: you get users, and users -- believe it or not -- like stability (few people like fiddling with function names and arguments in an otherwise working program or library) and, yes they will take new improvements as long as their working programs continue working. Researchers on the other hand need room to experiment with ideas; they need to get their implementations in the wild to get a sense of what scales, what doesn't. These facts are in tension; you can't solve it by more automated testing. If you want GHC to compete with GCC or Clang, then you know what to do: stop experimenting with the language. So far, most of the work on GHC has been done by researchers who are not paid to do development work -- unless academia changes its standards... -- Gaby ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On Sun, Feb 10, 2013 at 3:30 PM, Simon Peyton-Jones simo...@microsoft.com wrote: | You may ask what use is a GHC release that doesn't cause a wave of updates? | And hence that doesn't work with at least some libraries. Well, it's a very useful | forcing function to get new features actually out and tested. | | But the way you test new features is to write programs that use them, | and programs depend on libraries. That is of course ideal, but the ideal carries costs. A half way house is a release whose library support will be patchy. Not such good testing, but much lower costs. But still (I think) a lot more testing than compile HEAD gives us. Simon Fitting: http://xkcd.com/1172/ (sorry, I couldn't resist) -- Gaby ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On Mon, Feb 11, 2013 at 5:03 PM, Johan Tibell johan.tib...@gmail.com wrote: Hi, I think reducing breakages is not necessarily, and maybe not even primarily, an issue of releases. It's more about realizing that the cost of breaking things (e.g. changing library APIs) has gone up as the Haskell community and ecosystem has grown. We need to be conscious of that and carefully consider if making a breaking change (e.g. changing a function instead of adding a new function) is really necessary. Many platforms (e.g. Java and Python) rarely, if ever, make breaking changes. If you look at compiler projects (e.g. LLVM and GCC) you never see intentional breakages, even in major releases*. Here's a question I think we should be asking ourselves: why is the major version of base bumped with every release? Is it really necessary to make breaking changes this often? How about aiming for having GHC 7.10 be a release where we only add new stuff and improve old stuff? -- Johan * A major GCC release usually signifies that some large change to the code generator was made. I have some experience with GCC releases -- having served as a GCC Release Manager for several years. In fact, the release scheme we currently have has gone through several iterations -- usually after many existential crisis. Yes, we don't break GCC ABI lightly, mostly because GCC isn't a research compiler and most research works are done on forgotten branches that nobody cares about anymore. Implementing new standards (e.g. moving from C++03 to C++11 that has several mandated API and ABI breakage) is a royal pain that isn't worth replicating in GHC -- at least if you want GHC to remain a research compiler. Concerning your question about release number, I would venture that there is a certain marketing aspect to it. I can tell you that we, the GCC community, are very poor at that -- otherwise, we would have been at version 26 or something :-) -- Gaby ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On Mon, Feb 11, 2013 at 6:37 PM, Johan Tibell johan.tib...@gmail.com wrote: On Mon, Feb 11, 2013 at 4:34 PM, Gabriel Dos Reis g...@integrable-solutions.net wrote: I have some experience with GCC releases -- having served as a GCC Release Manager for several years. In fact, the release scheme we currently have has gone through several iterations -- usually after many existential crisis. Yes, we don't break GCC ABI lightly, mostly because GCC isn't a research compiler and most research works are done on forgotten branches that nobody cares about anymore. Implementing new standards (e.g. moving from C++03 to C++11 that has several mandated API and ABI breakage) is a royal pain that isn't worth replicating in GHC -- at least if you want GHC to remain a research compiler. Concerning your question about release number, I would venture that there is a certain marketing aspect to it. I can tell you that we, the GCC community, are very poor at that -- otherwise, we would have been at version 26 or something :-) Thanks for sharing! My perspective is of course as a user. I don't think I've ever run into a case where the compiler broken a previous work e.g. C++ program. On the other hand I have to make a release of most of the libraries I maintain with every GHC release (to bump cabal version constraints to accept the new base version, if nothing else). -- Johan I understand. Concerning GCC, it is true that the shear size of the user base and the audience of the compiler (industrial strength) calls for a very conservative approach to ABI or API breaking. On the hand, that means that there are certain welcomed, beneficial changes that we cannot effect. For example, because libstdc++ has been an early adopter of a reference counted-based implementation of std::string, we could not switch to more efficient and more multithread-friendly implementation. That was has been contributed for years but has been sequestered in some branches and namespaces integrated with the rest of the library. That is a shame, but one that is unavoidable given the expectation of the GCC audience. It is not clear to me that GHC is ready for that kind of constraints. We are still describing the C++11 implementation as experimental because we fear that doing otherwise might commit ourselves to an ABI and API that we may need to break later -- possibly because of undetected bugs or because we have found implementations we like better. Of course, that causes some distress in the community because people would like to say GCC implements C++11. Finally, we do break API, you have just been lucky :-) http://gcc.gnu.org/onlinedocs/libstdc++/manual/api.html But, we have also developed very elaborate scheme for symbol versioning and namespace associations to help users digest API breakages without tears. Symbol versioning is a very messy business. I am still of the opinion that the current issue with GHC and HP is social, and it can be resolved through communication and coordination between the two communities for the great good of the Haskell community. -- Gaby ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On Sun, Feb 10, 2013 at 3:16 PM, Ian Lynagh i...@well-typed.com wrote: On Sun, Feb 10, 2013 at 09:02:18PM +, Simon Peyton-Jones wrote: You may ask what use is a GHC release that doesn't cause a wave of updates? And hence that doesn't work with at least some libraries. Well, it's a very useful forcing function to get new features actually out and tested. But the way you test new features is to write programs that use them, and programs depend on libraries. Thanks Ian Releasing GHC early and often (possibly with API breakage) isn't really the problem. The real problem is how to coordinate with library authors (e.g. Haskell Platform), etc. I suspect GHC should continue to offer a platform for research and experiments. That is much harder if you curtail the ability to release GHC early and often. -- Gaby ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell
On Thu, Mar 1, 2012 at 8:38 AM, Ian Lynagh ig...@earth.li wrote: On Thu, Mar 01, 2012 at 07:58:42AM +, AntC wrote: SORF's whadyoumaycalls are at the Kind level. (I'm not opposed to them because they're new-fangled, I'm opposed because I can't control the namespace.) I haven't followed everything, so please forgive me if this is a stupid question, but if you implement this variant of SORF: http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields#ScopecontrolbygeneralisingtheStringtypeinHas then do you get the behaviour of SORF when using field names starting with a lower-case letter, and DORF when they start with an upper-case letter? Thanks Ian It is close to a hack (e.g. taking over a special meaning for String) that has been implemented in the Scratchpad II (now known as AXIOM) system for over 3 decades. I found it odd, this maybe for Haskell it may have a completely different taste. If you have a copy of the AXIOM book http://www.amazon.com/AXIOM-Scientific-Computation-Richard-Jenks/dp/0387978550 have a look at the end of page 71. -- Gaby ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
