RE: Were usage types ever in GHC

[Simon Peyton Jones]

Keith Wansbrough did implement his thesis work in a fork of GHC.  But (a) it 
was jolly complicated and pervasive, and (b) the performance improvements were 
not great.  It didn't pay its way. So we dropped it.  See his thesis, available 
here http://research.microsoft.com/en-us/um/people/simonpj/papers/papers.html

What we HAVE done (and is in GHC) is cardinality analysis. See "Higher order 
cardinality analysis in theory and practice"
http://research.microsoft.com/en-us/um/people/simonpj/papers/usage-types/usage.htm

Enjoy!

Simon
| -Original Message-
| From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Philip Dexter
| Sent: 21 January 2016 23:15
| To: GHC Users List 
| Subject: Were usage types ever in GHC
| 
| I've recently been digging around to see if there has ever been any
| attempt to perform any sort of data reuse optimization in functional
| languages.
| 
| Along with many other papers, I've come across `Once upon a type' as well
| as `Once upon a polymorphic type'. They both mention a desire to include a
| similar system in GHC.
| 
| Then in `Playing by the rules: rewriting as a practical optimization
| technique in GHC' I see usage types mentioned in section 5.3:
| 
| """
| To express this, GHC adds extra usage type arguments to map, both at its
| definition and at its call sites. Once this is done, a specialised version
| of map can be compiled for the case when the usage-type argument is
| “once”, and a rule generated to match such calls, in exactly the same way
| as for specialising overloading.
| """
| 
| I can't tell if this is simply a hypothetical optimization or if this
| really happened at one point in the history of GHC.
| 
| I was hoping somebody could shed some light on this topic
| 
| Was a usage type system or something similar (e.g. linear type system)
| ever present in GHC?
| 
| If it was then why was it taken out (unless I'm missing something, this
| optimization is not happening today)? I could guess at this and say that
| the gains weren't worth the overhead, but perhaps there's another reason.
| 
| If it was never present, why not? There was obviously at least some
| interest in this sort of optimization at some point in the Haskell
| community and I'd be curious as to why it was never tested in GHC.
| 
| Thanks!
| 
| Philip Dexter
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

[Haskell] Haskell Weekly News

[Kim-Ee Yeoh]

Dear Gentle Reader,

Many, many beautiful gems in the Haskell Weekly News archives are worth a
second look.

To give you a taste, I reproduce below excerpts from the quotes section of
the Jan 31, 2007 issue -- yes, that's 9 years ago -- under the editorship
of Don Stewart.

Enjoy.

Best, Kim-Ee Yeoh



*Top Picks*

   - Edsko de Vries designs O(1)-amortized and O(1)-worst-case queues
    using a
   technique different from the standard literature by Chris Okasaki. In
   particular, the O(1)-worst-case queue employs a Progress datatype that
   could be reused to also optimize data structures other than queues. On the
   other hand, Lennart Augustsson on /r/haskell was pleased as a plum until
   he saw the unsafeInterleaveST
   

   required to pull off the Progress technique.

   Elsewhere, Hacker News rates the article highly enough
    for it to stay on the
   front page for five hours . However,
   the comments there belie that the advanced Haskell goes swoosh over the
   head of the average HN reader.

   - Philipp Schuster sketches a FRP implementation based on temporal logic
   . Neel
   Krishnaswami explains on /r/haskell why it suffers from space leaks
    like
   most other FRP implementations and ways of fixing it.

   - Dan Burton reports that the latest version 0.10 of the json parsing
   package aeson suffers from deal-breaking bugs
   
.
   Aeson author Bryan O'Sullivan, of an older email-centered generation,
   explains that he has "a life outside of checking github issues" in
the /r/haskell
   discussion
   .
   In any case, the next stepping 5 of Stackage LTS rolls it back to
   version 0.9
   

   .

   - A redditor asks, "What's the TypeInType extension planned for the
   upcoming version 8 of GHC?" The short answer is that it's used for
   dependent type programming. Detailed answers can be found in the actual
   /r/haskell Q
   .

   - GHC on ARM used to suffer over 100 failures on the testsuite
   . Ben Gamari girds his
   loins and over the last 6 weeks battled against "the villains that plague
   this poor architecture." Result? Nightly builds now compile clean. Go Ben!


*A Blast from the Past (Quotes from #Haskell IRC):*


   - *huschi:* Programing in haskell seems a bit frustrating. i'm missing
   searching for errors :(

   - *bakert:* I know all my programs can be reduced to only one tenth the
   size if only I can learn all these crazy functions



*Quote of the Week*

   - Will Jones: The more I write Haskell, the more it feels like Forth.
   Where I'm basically just inventing a language for my problem, then writing
   the program in that instead.

   (Ed. Dear Will: Remember how Dijkstra once said "Always design your
   programs as a member of a whole family of programs, including those that
   are likely to succeed it"? He would have warmly congratulated you on your
   discovery.)


-- Kim-Ee Yeoh
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell