ANNOUNCE: GHC survey results
We've finally digested the results of the GHC survey, and you can find our analysis here: http://www.haskell.org/ghc/survey2005-summary.html There's a lot to take in, but it's an interesting read. Enjoy! -- The GHC Team.
Hello Simon, Tuesday, June 28, 2005, 1:58:13 PM, you wrote: SM> http://www.haskell.org/ghc/survey2005-summary.html SM> There's a lot to take in, but it's an interesting read. Enjoy! thank you all, processing all the 600 answers was not easy work :) i have several comments regarding results of this survey: 1) GHCi compiles to bytecode several times faster than GHC makes unoptimized compilation. can unoptimized GHC compilation just create bytecode (as Ocaml does)? 2) is your plans to support x86-64 platform includes Windows (and all other sorts of Unix), or it's for Linux only? 3) many users complaining about non-compatibility between GHC versions. if they mean library interfaces changes then how about using Pesco's library versioning scheme? (see http://www.haskell.org/tmrwiki/EternalCompatibilityInTheory) 4) i definitely will poll for nightly snapshot build for Windows (if it's possible) and frequent releases of stable versions i think there is a plans to move toward the "real world". but it encounter the chicken&egg problem - the commercial programmers don't want to use Haskell because it's too far-from-earth, and you cannot make movements toward "real world" because there is almost no voices from non-academic world. of course i can't monopolize the right to say over all these programmers. but from my point of view several things can be done to be closer to commercial programs and programmers: 1) adding OO-like features in O'Haskell style. for readers that don't know it's about adding new variants to ADT types: type Figure = Circle ... type Figure |= Box ... and adding new fields to existing records: type Point = {x,y::Int} type ColoredPoint = Point extended with {c::Color} imho these extensions are great because it's both in Haskell and C++ style 2) adding "real-world" libraries. i think about libraries for string processing, regular expression handling, command-line processing, serializing, ASCIIZ strings, working with filesystem and running external commands, networking, web-oriented libraries (http/ftp/smtp/pop3, constructing/deconstructing emails), DBMS access i enumerated here only working libraries which i seen in MissingH, or written by Pesco, John Meacham, or Peter Simons 3) may be it is time to include some FFI-generating tool in GHC? many newcomers have some C/C++ libraries they need to communicate 4) some newcomers wrote what they want to say example programs and even tutorials in the package. i think that at least links to such sources/texts can be provided so that a newcomer can easily get a TASTE of Haskell 5) of course, you must add words about Pugo and Darcs in readme :) anyway, ADT is a vehicle of progress ;) -- Best regards, Bulat mailto:bulatz@HotPOP.com
Some people would like features removed (implicit parameters was mentioned a couple of times). Linear implicit parameters is a clear candidate for removal.
I don't understand the motivation for this. Implicit parameters do weird things with the monomorphism restriction, but when I'm worried about that, I choose not to use them together. Why remove a feature from a product? Why not, instead, just choose to not use it? Jim
Some people would like features removed (implicit parameters was mentioned a couple of times). Linear implicit parameters is a clear candidate for removal.
I don't understand the motivation for this. Implicit parameters do weird things with the monomorphism restriction, but when I'm worried about that, I choose not to use them together.
Why remove a feature from a product? Why not, instead, just choose to not use it?
Jim
Because the feature complicates the product, increases maintainance costs, and keeps the maintainers from working on other things people care more about? GHC is pretty complex, and if that complexity can be reduced by eliminating unpopular features I'm all for it. (Although I have to admit I have a soft place in my heart for external core...) Robert Dockins
robert dockins wrote:
Why remove a feature from a product? Why not, instead, just choose to not use it?
Because the feature complicates the product, increases maintainance costs, and keeps the maintainers from working on other things people care more about?
That's fair. I just hope the implicit parameter implementation is orthogonal enough that it's worth keeping around. I think the motivating examples in "Implicit parameters: dynamic scoping with static types" (http://citeseer.ist.psu.edu/246042.html&e=10342) are at least as compelling as those in the just-implemented (http://article.gmane.org/gmane.comp.lang.haskell.cvs.all/19423) "Associated types with class", (http://research.microsoft.com/Users/simonpj/papers/assoc-types/), but maybe it's just me. Jim
Jim Apple
robert dockins wrote:
Why remove a feature from a product? Why not, instead, just choose to not use it?
Because the feature complicates the product, increases maintainance costs, and keeps the maintainers from working on other things people care more about?
That's fair. I just hope the implicit parameter implementation is orthogonal enough that it's worth keeping around.
Since there were also some hints about starting to use darcs, perhaps it would be possible to maintain a separate branch with the more experimental features? Or will they be too intrusive (and keeping the "experimental" branch in sync with developments from the "trunk" will cause too many conflicts)? -k -- If I haven't seen further, it is by standing in the footprints of giants
On 6/28/05, Jim Apple
Some people would like features removed (implicit parameters was mentioned a couple of times). Linear implicit parameters is a clear candidate for removal.
I don't understand the motivation for this. Implicit parameters do weird things with the monomorphism restriction, but when I'm worried about that, I choose not to use them together.
Why remove a feature from a product? Why not, instead, just choose to not use it?
It depends on what you mean by "using it," of course, but sometimes that's not a matter of choice (e.g. when you're reading others' code.) Cheers, D. Tenev
On Tue, Jun 28, 2005 at 11:30:04AM -0400, Jim Apple wrote:
Some people would like features removed (implicit parameters was mentioned a couple of times). Linear implicit parameters is a clear candidate for removal.
I don't understand the motivation for this. Implicit parameters do weird things with the monomorphism restriction, but when I'm worried about that, I choose not to use them together.
Why remove a feature from a product? Why not, instead, just choose to not use it?
implicit parameters are inherently broken according to some people (including me). There is no reason to remove them immediatly, but if it ever comes up that the code for them is holding back some other change, I would say dump them rather than try to work around or modify it. However, I would like to explore linear parameters more. I think a main issue with them is that they are mixed in with implicit parametrs and hence share their problems. An extension I was considering for jhc goes like this: in addition to normal variables, you may have linear variables which start with a %. linear variables may be used and bound exactly like normal variables. The only differences are as follows. linear variables automatically get a (Splittable a) constraint, they must be in class Splittable. and the following desugaring occurs. f %vs x y = g %vs <> h %vs z where z = name %vs x + y becomes f _vs x y = g _vs1 <> h _vs2 y x where z = name _vs3 x + y (_vs1,_nvs1) = split _vs (_vs2,_nvs2) = split _nvs1 (_vs3,_nvs3) = split _nvs2 where _vs is some unique name. basically the transformation is to change a linear variable to a normal one, replace each occurance of the linear variable with a unique name, bind the unique names to split versions of of the original ,now normal, binding. I think this gives all the advantages of linear parameters with a much simpler binding and semantics. an example of how this might be used is renameTerm %ns (EAp a b) = EAp (renameTerm %ns a) (renameTerm %ns b) renameTerm %ns (Let v e) = Let v' (renameTerm %ns e) where v' = rename v newname (newname:_) = %ns -- pull off first element of namesupply ... this assumes %ns is an infinite list of unique names. - note that %ns and ns are completly different variables with no relation. - any binding whether a let, where, function argument or monad generator can create a linear variable as long as it is in class Splittable, they are not special in any way. - The desugaring is really simple - there is no implied order of evaluation or modification of function structure like with monads. - none of the implicit parameter oddness. Comments? and yes, I know the term 'variable' is a misnomer when dealing with haskell :) John -- John Meacham - ⑆repetae.net⑆john⑈
participants (7)
-
Bulat Ziganshin -
Dinko Tenev -
Jim Apple -
John Meacham -
Ketil Malde -
robert dockins -
Simon Marlow