Re: Scheme went one direction, Haskell went another: Why?
- From: Benjamin L. Russell <DekuDekuplex@xxxxxxxxx>
- Date: Thu, 09 Apr 2009 18:06:57 +0900
On Wed, 08 Apr 2009 16:42:10 -0400, Anton van Straaten
<anton@xxxxxxxxxxxxxxxx> wrote:
[...]
This is also a reminder that Scheme has been a research platform for
these sorts of language features, and standardization is in opposition
to the goals of such research. For many people who have worked on
Scheme, the current Haskell situation may be considered an anti-goal.
In this respect, Scheme could be considered to have done better than
Haskell -- Haskellers themselves used to use the unofficial slogan
"avoid success at all costs", something which they seem to be failing at
recently. See this article:
http://www.computerworld.com.au/article/261007/-z_programming_languages_haskell?pp=10
Interestingly, this phenomenon had already been predicted in the paper
"Wearing the hair shirt: a retrospective on Haskell" (Peyton Jones,
S., 2003) (see
http://research.microsoft.com/en-us/um/people/simonpj/papers/haskell-retrospective/index.htm)
(see slide 15); viz.:
Tony Hoare's comment "I fear that Haskell is doomed to succeed"
Nevertheless, according to the paper "A History of Haskell: Being Lazy
With Class" (Hudak, Hughes, Jones, and Wadler, 2007) (see
http://research.microsoft.com/en-us/um/people/simonpj/papers/history-of-haskell/history.pdf)
(see page 10), there are definite reasons for striving to "avoid
success at all costs," as follows:
The fact that Haskell has, thus far, managed the tension between
these two strands of development [as a mature language, and as a
laboratory in which to explore advanced language design ideas] is
perhaps due to an accidental virtue: Haskell has not become too
successful. The trouble with runaway success, such as that of Java,
is that you get too many users, and the language becomes bogged
down in standards, user groups, and legacy issues. In contrast, the
Haskell community is small enough, and agile enough, that it usually
not only absorbs language changes but positively welcomes them:
it’s like throwing red meat to hyenas.
Sometimes it's actually better not to be too successful.
I need to keep reminding the folks over on Haskell-Cafe of this point
occasionally, lest they forget the spirit of Haskell.
A relevant quote from Simon Peyton-Jones:
"I’m primarily a programming language researcher, so the fact that
Haskell has up to now been used for just university types has been
ideal. Now it’s used a lot in industry but typically by people who are
generally flexible, and they are a generally a self selected rather
bright group. What that means is that we could change the language and
they wouldn’t complain. Now, however, they’re starting to complain if
their libraries don’t work, which means that we’re beginning to get
caught in the trap of being too successful."
Why do you want Scheme to be too successful? ;-)
Indeed. No need to have Scheme get bogged down in standards, user
groups, and legacy issues; the language would then cease to evolve.
Then we'd become just a slightly cleaned-up version of Common Lisp. No
need to forget the spirit of Scheme, either.
As an interesting sidenote, according to the above-mentioned paper
(Hudak, Hughes, Jones, and Wadler, 2007) (see page 3):
"An anonymous reviewer supplied the following: 'An interesting sidelight
is that the Friedman and Wise paper [“Cons should not evaluate its
arguments” (Friedman and Wise, 1976) (see
http://www.cs.indiana.edu/pub/techreports/TR44.pdf)] inspired Sussman
and Steele to examine lazy evaluation in Scheme, and for a time they
weighed whether to make the revised version of Scheme call-by-name
or call-by-value. They eventually chose to retain the original
call-by-value design, reasoning that it seemed to be much easier to
simulate call-by-name in a call-by-value language (using lambda-expressions
as thunks) than to simulate call-by-value in a call-by-name language (which
requires a separate evaluation-forcing mechanism). Whatever we might
think of that reasoning, we can only speculate on how different the
academic programming-language landscape might be today had they made
the opposite decision.”
Nevertheless, Lazy Scheme has actually been implemented as both a
language level and a module in PLT Scheme (see
http://docs.plt-scheme.org/lazy/index.html). Furthermore, according
to "The Design and Implementation of Typed Scheme" (Tobin-Hochstadt,
S., and Felleisen, M., 2008) (see page 2),
[Typed Scheme] ... provides first-class polymorphic functions, known as
impredicative polymorphism, a feature of the Glasgow Haskell Compiler
(Vytiniotis et al. 2006).
Still furthermore, according to (Hudak, Hughes, Jones, and Wadler,
2007) (see page 5):
It was also agreed at this meeting [The Glasgow Meeting] that Hudak and
Wadler would be the editors of the first Haskell Report. The name of the
report, “Report on the Programming Language Haskell, A Non-strict, Purely
Functional Language,” was inspired in part by the “Report on the Algorithmic
Language Scheme,” which in turn was modelled after the “Report on the
Algorithmic Language Algol.”
In addition, according to the same paper (ibid.) (see page 31), Scheme
compilation techniques were initially explored in one implementation
of Haskell, known as Yale Haskell (although because of lack of a T
compiler and "performance and portability issues," Common Lisp wound
up being adopted, ironically eventually causing the abandonment of the
project, circa 1995):
In the 1980s, prior to the development of Haskell, there was an
active research project at Yale involving Scheme and a dialect of
Scheme called T. SeveralMS and PhD theses grew out of this work,
supervised mostly by Hudak. The Orbit compiler, an optimising
compiler for T, was one of the key results of this effort (Kranz et al.,
2004; Kranz et al., 1986).
So once Hudak became actively involved in the design of Haskell,
it was only natural to apply Scheme compilation techniques in an
implementation of Haskell. However, rather than port the ideas to a
stand-alone Haskell compiler, it seemed easier to compile Haskell
into Scheme or T, and then use a Scheme compiler as a back end.
Unfortunately, the T compiler was no longer being maintained and
had problems with compilation speed. T was then abandoned in
favour of Common Lisp to address performance and portability
issues. This resulted in what became known as Yale Haskell.
...
Ultimately, the limitations of basing a Haskell compiler on a Common
Lisp back-end caught up with the project. Although early
on Yale Haskell was competitive with GHC and other compilers,
GHC programs were soon running two to three times faster than
Yale Haskell programs. Worse, there was no real hope of making
Yale Haskell run any faster without replacing the back-end and runtime
system. Optimisations such as reusing the storage in a thunk
to hold the result after evaluation were impossible with the Common
Lisp runtime system. The imperative nature of Lisp prevented
many other optimisations that could be done in a Haskell-specific
garbage collector and memory manager. Every thunk introduced an
extra level of indirection (a Lisp cons cell) that was unnecessary in
the other Haskell implementations. While performance within the
strict subset of Haskell was comparable with other systems, there
was a factor of 3 to 5 in lazy code that could not be overcome due
to the limitations of the Lisp back end. For this reason, in addition
to the lack of funding to pursue further research in this direction,
the Yale Haskell implementation was abandoned circa 1995.
Furthermore, according to the same paper (ibid.) (see page 37):
... Hudak’s research group and others began a flurry of
research strands which they collectively referred to as functional
reactive programming, or FRP.
...
Researchers at Brown have more recently ported the basic ideas of FRP
[Functional Reactive Programming] into a Scheme environment called
“Father Time” (Cooper and Krishnamurthi, 2006).
Thus, the languages Scheme and Haskell have historically influenced
the evolution of each other.
-- Benjamin L. Russell
References
Friedman, D. and Wise, D. (1976). CONS should not evaluate its
arguments. _Automata, Languages, and Programming_, pages
257-281.
Hudak, P., Hughes, J, Peyton Jones, S., and Wadler, P. (2007). A
History of Haskell: Being Lazy With Class. In _The Third ACM SIGPLAN
History of Programming Languages Conference (HOPL-III)_, pages 12-1 -
12-55, San Diego, California. ACM.
Peyton Jones, S. (2003). Wearing the hair shirt: a retrospective on
Haskell. Invited talk at POPL 2003. ACM.
Tobin-Hochstadt, S., and Felleisen, M. (2008). The Design and
Implementation of Typed Scheme. In _The 35th Annual ACM SIGPLAN -
SIGACT Symposium on Principles of Programming Languages_, pages
395-406, San Francisco, California. ACM.
Vytiniotis, D., Weirich, S., and Peyton Jones, S. Boxy
types: inference for higher-rank types and impredicativity. In _ICFP
’06: Proceedings of the Eleventh ACM SIGPLAN International Conference
on Functional Programming_, pages 251-62, New York, NY, USA,
2006. ACM Press.
--
Benjamin L. Russell / DekuDekuplex at Yahoo dot com
http://dekudekuplex.wordpress.com/
Translator/Interpreter / Mobile: +011 81 80-3603-6725
"Furuike ya, kawazu tobikomu mizu no oto."
-- Matsuo Basho^
.
- References:
- Scheme went one direction, Haskell went another: Why?
- From: Grant Rettke
- Re: Scheme went one direction, Haskell went another: Why?
- From: Anton van Straaten
- Scheme went one direction, Haskell went another: Why?
- Prev by Date: Re: Extol virtues of Lisp, but then use Python?
- Next by Date: Re: Scheme went one direction, Haskell went another: Why?
- Previous by thread: Re: Scheme went one direction, Haskell went another: Why?
- Next by thread: Tendrils
- Index(es):
Relevant Pages
|
Loading
