Personal tools

Modest GHC Proposals

From HaskellWiki

(Difference between revisions)
Jump to: navigation, search
m
(better Adhoc Monomorphization / Specialization support)
 
(10 intermediate revisions by 4 users not shown)
Line 4: Line 4:
   
 
Proposals are suitable for this page if they do not require deep changes to GHC, though they may still be nontrivial, and which ghc-hq is likely to merge in when there is a strong community consensus and well-written patch is on hand.
 
Proposals are suitable for this page if they do not require deep changes to GHC, though they may still be nontrivial, and which ghc-hq is likely to merge in when there is a strong community consensus and well-written patch is on hand.
  +
  +
Many but not all of these may be associated with feature request tickets on the ghc trac: http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status=reopened&type=feature+request&order=priority
  +
  +
Many tickets tracked by SPJ also fall in this category: http://hackage.haskell.org/trac/ghc/wiki/Status/SLPJ-Tickets
   
   
Line 14: Line 18:
   
 
There are other possible things we may wish to deprecate as well. Expanding this pragma would make certain changes to libraries more tractable and easily managed.
 
There are other possible things we may wish to deprecate as well. Expanding this pragma would make certain changes to libraries more tractable and easily managed.
  +
  +
http://hackage.haskell.org/trac/ghc/ticket/4879
  +
  +
Perhaps there is a framework to be designed for the following ad-hoc warnings as well: http://hackage.haskell.org/trac/ghc/ticket/8004
   
 
== Records and Modules ==
 
== Records and Modules ==
Yitzchak Gale's nested modules proposal l which would address one of the larger warts with the current module system and records while adding essentially no complexity to the GHC internals. (i.e. no changes would be needed to GHC beyond the parsing phase possibly, so an ''easy'' changeto experiment with )
+
Yitzchak Gale's nested modules proposal which would address one of the larger warts with the current module system and records while adding essentially no complexity to the GHC internals. (i.e. no changes would be needed to GHC beyond the parsing phase possibly, so an ''easy'' change to experiment with )
   
http://www.haskell.org/pipermail/glasgow-haskell-users/2012-January/021591.htm
+
http://www.haskell.org/pipermail/glasgow-haskell-users/2012-January/021591.html
   
  +
(alternately at: http://osdir.com/ml/glasgow-haskell-users@haskell.org/2012-01/msg00171.html)
   
 
== Pattern Synonyms ==
 
== Pattern Synonyms ==
Line 26: Line 35:
 
and
 
and
 
http://hackage.haskell.org/trac/ghc/ticket/5144
 
http://hackage.haskell.org/trac/ghc/ticket/5144
  +
  +
== Make Template Haskell quieter ==
  +
  +
Template Haskell spits out a lot of module loading text by default. Clearance has been given to increase the verbosity threshold for this to -v2, but someone needs to implement it. See:
  +
  +
http://hackage.haskell.org/trac/ghc/ticket/7863
  +
  +
== Qualified Module Exports ==
  +
  +
Delailed here: [[QualifiedModuleExport]]
  +
  +
== better Adhoc Monomorphization / Specialization support ==
  +
  +
Currently many libraries achieve monomorphization of code by aggressive inlining. This would be better achieved (with better compilation time) by allowing adding monomorphic variants to stand alone functions. Currently we can only specialize type class instances! Theres also been the idea of supporting monomorphization of polymorphic data types kicked around a few times, but thats a bit more subtle.
   
 
[[Category:Proposals]]
 
[[Category:Proposals]]

Latest revision as of 03:43, 20 October 2013

There are many many proposals to augment GHC (and Haskell) that would be valuable yet languish because they have not be documented / collected anywhere aside from persisting in the Mailing lists.

Such proposals are things, typically, that would be uncontroversial and welcomed, but which no core GHC developers have free cycles to work on.

Proposals are suitable for this page if they do not require deep changes to GHC, though they may still be nontrivial, and which ghc-hq is likely to merge in when there is a strong community consensus and well-written patch is on hand.

Many but not all of these may be associated with feature request tickets on the ghc trac: http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status=reopened&type=feature+request&order=priority

Many tickets tracked by SPJ also fall in this category: http://hackage.haskell.org/trac/ghc/wiki/Status/SLPJ-Tickets


Contents

[edit] 1 Expanded Deprecated Pragma

The current pragma can attach to modules or top level entities including functions, classes, and types.

It cannot attach to exports (i.e. if we wish to not deprecate "foo" but only its reexport from module Bar).

It also cannot attach to methods within classes.

There are other possible things we may wish to deprecate as well. Expanding this pragma would make certain changes to libraries more tractable and easily managed.

http://hackage.haskell.org/trac/ghc/ticket/4879

Perhaps there is a framework to be designed for the following ad-hoc warnings as well: http://hackage.haskell.org/trac/ghc/ticket/8004

[edit] 2 Records and Modules

Yitzchak Gale's nested modules proposal which would address one of the larger warts with the current module system and records while adding essentially no complexity to the GHC internals. (i.e. no changes would be needed to GHC beyond the parsing phase possibly, so an easy change to experiment with )

http://www.haskell.org/pipermail/glasgow-haskell-users/2012-January/021591.html

(alternately at: http://osdir.com/ml/glasgow-haskell-users@haskell.org/2012-01/msg00171.html)

[edit] 3 Pattern Synonyms

http://hackage.haskell.org/trac/ghc/ticket/5144 and http://hackage.haskell.org/trac/ghc/ticket/5144

[edit] 4 Make Template Haskell quieter

Template Haskell spits out a lot of module loading text by default. Clearance has been given to increase the verbosity threshold for this to -v2, but someone needs to implement it. See:

http://hackage.haskell.org/trac/ghc/ticket/7863

[edit] 5 Qualified Module Exports

Delailed here: QualifiedModuleExport

[edit] 6 better Adhoc Monomorphization / Specialization support

Currently many libraries achieve monomorphization of code by aggressive inlining. This would be better achieved (with better compilation time) by allowing adding monomorphic variants to stand alone functions. Currently we can only specialize type class instances! Theres also been the idea of supporting monomorphization of polymorphic data types kicked around a few times, but thats a bit more subtle.