On Jan 9, 2008 5:43 PM, Derek Elkins [EMAIL PROTECTED] wrote:
A shorter and lighter and and also interesting and entertaining read is:
http://research.microsoft.com/~simonpj/Papers/haskell-retrospective/index.htm
While the reason Haskell was pure was to support laziness, at this point
though
On Thu, 10 Jan 2008, David Roundy wrote:
On Thu, Jan 10, 2008 at 08:10:57PM +, Sebastian Sylvan wrote:
On Jan 10, 2008 8:06 PM, Ketil Malde [EMAIL PROTECTED] wrote:
David Roundy [EMAIL PROTECTED] writes:
I just want to point out that unsafePerformIO is at the core of the
On Jan 9, 2008 5:42 PM, Henning Thielemann
[EMAIL PROTECTED] wrote:
I just want to point out that unsafePerformIO is at the core of the
(safe) bytestring library. As SPJ et al pointed out, this is crucial
functionality, and is only unsafe if unsafely used.
Indeed, there are hacks and they
Neil wrote:
Laziness. It is very difficult to have a lazy language which is not
pure.
Exactly.
Laziness and purity together help with equational reasoning, compiler
transformations, less obscure bugs, better compositionality etc.
Related, but nevertheless a shameless plug: Jurriaan Hage
On Thu, 10 Jan 2008, David Roundy wrote:
On Jan 9, 2008 5:42 PM, Henning Thielemann
In Modula-3 modules using hacks must be explicitly marked as UNSAFE. See
http://www.cs.purdue.edu/homes/hosking/m3/reference/unsafe.html
Maybe this is also an option for Haskell?
I don't think this
David Roundy [EMAIL PROTECTED] writes:
I just want to point out that unsafePerformIO is at the core of the
(safe) bytestring library. As SPJ et al pointed out, this is crucial
functionality, and is only unsafe if unsafely used.
In Modula-3 modules using hacks must be explicitly marked as
On Jan 10, 2008 8:06 PM, Ketil Malde [EMAIL PROTECTED] wrote:
David Roundy [EMAIL PROTECTED] writes:
I just want to point out that unsafePerformIO is at the core of the
(safe) bytestring library. As SPJ et al pointed out, this is crucial
functionality, and is only unsafe if unsafely
On Thu, Jan 10, 2008 at 08:10:57PM +, Sebastian Sylvan wrote:
On Jan 10, 2008 8:06 PM, Ketil Malde [EMAIL PROTECTED] wrote:
David Roundy [EMAIL PROTECTED] writes:
I just want to point out that unsafePerformIO is at the core of the
(safe) bytestring library. As SPJ et al pointed
On Jan 10, 2008 8:12 PM, David Roundy [EMAIL PROTECTED] wrote:
On Thu, Jan 10, 2008 at 08:10:57PM +, Sebastian Sylvan wrote:
On Jan 10, 2008 8:06 PM, Ketil Malde [EMAIL PROTECTED] wrote:
David Roundy [EMAIL PROTECTED] writes:
I just want to point out that unsafePerformIO is at
I got question about why haskell insist to be a purely FL. I mean is
there any feature which is only support by pure?
I mean maybe the program is much easier to prove? Or maybe we can
cache some value for laziness.
Could anyone give me some more information about why haskell needs to be pure.
On 09/01/2008, Yu-Teh Shen [EMAIL PROTECTED] wrote:
I got question about why haskell insist to be a purely FL. I mean is
there any feature which is only support by pure?
Have a look at the ueber-retrospective on Haskell, fifty-five pages of
all the history and motivation one could possibly
On Wed, 2008-01-09 at 15:06 +, Dougal Stanton wrote:
Have a look at the ueber-retrospective on Haskell, fifty-five pages of
all the history and motivation one could possibly want.
http://research.microsoft.com/~simonpj/papers/history-of-haskell/
It's interesting reading, I promise! ;-)
On Wed, 2008-01-09 at 15:06 +, Dougal Stanton wrote:
On 09/01/2008, Yu-Teh Shen [EMAIL PROTECTED] wrote:
I got question about why haskell insist to be a purely FL. I mean is
there any feature which is only support by pure?
Have a look at the ueber-retrospective on Haskell, fifty-five
Derek Elkins wrote:
A shorter and lighter and and also interesting and entertaining read is:
http://research.microsoft.com/~simonpj/Papers/haskell-retrospective/index.htm
Just read it, quoting:
`Tony Hoare’s comment: “I fear that Haskell is doomed to succeed”`
LOL! Very good stuff
If
Peter Verswyvelen wrote:
But I'm amazed that impure (albeit strong) languages like LISP and
Scheme are still used for projects... I mean, in Scheme you can set!
the addition operator to become a multiplication operator at runtime,
modifying global behavior... Now that's a side effect, C/C++ is
anton:
OTOH, the freedom to change things on the fly can be nice to have, and
if used with great responsibility (mainly an understanding of what's
safe to do and what isn't), the downside can be vanishingly small.
It can be small, unless you need to have any kind of static assurance
(say for
Don Stewart wrote:
anton:
OTOH, the freedom to change things on the fly can be nice to have, and
if used with great responsibility (mainly an understanding of what's
safe to do and what isn't), the downside can be vanishingly small.
It can be small, unless you need to have any kind of static
On Jan 9, 2008 4:21 PM, Don Stewart [EMAIL PROTECTED] wrote:
anton:
OTOH, the freedom to change things on the fly can be nice to have, and
if used with great responsibility (mainly an understanding of what's
safe to do and what isn't), the downside can be vanishingly small.
It can be
On Wed, 9 Jan 2008, David Roundy wrote:
On Jan 9, 2008 4:21 PM, Don Stewart [EMAIL PROTECTED] wrote:
anton:
OTOH, the freedom to change things on the fly can be nice to have, and
if used with great responsibility (mainly an understanding of what's
safe to do and what isn't), the
anton:
Don Stewart wrote:
anton:
OTOH, the freedom to change things on the fly can be nice to have, and
if used with great responsibility (mainly an understanding of what's
safe to do and what isn't), the downside can be vanishingly small.
It can be small, unless you need to have any
On Jan 9, 2008 6:20 PM, Don Stewart [EMAIL PROTECTED] wrote:
anton:
Oh dear - I'm going to have to rethink the paper I was working on,
provisionally titled In defense of arbitrary untracked effects in high
assurance software. ;)
That would be an awesome paper :)
Hear, hear!
Anton, if
21 matches
Mail list logo
