Re: [Haskell-cafe] Why purely in haskell?
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 it's safe to say Haskell insists on being pure no more than water insists on being wet. Wow, cool presentation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why purely in haskell?
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 (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 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 is a good idea. I think the point is (should be) to mark functions unsafe when they may be unsafe to /use/, I think using the IO monad for this works well... Would you suggest moving head and tail into the IO monad? I'm afraid we are talking about different notions of 'safe'. Modula-3's 'safe' means no segmentation fault, but program abortion due to ASSERT is still allowed. Ported to Haskell this means: 'head' and 'tail' are safe, but not total. I've seen function definitions like 'safeHead', that I would have named 'maybeHead'. For running untrusted code this means: I think it is ok that the program aborts with an error or runs into an infinite loop and must be terminated after a time-out, but it is not ok, that it overwrites some memory area or deletes some files, because unsafePerformIO was invoked. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why purely in haskell?
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 are some times necessary. The good thing about Haskell is, that hacks look like hacks. 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 is a good idea. It comes down to a question of whether you think it should be allowed for Haskell code to be used to write core Haskell libraries in a first-class manner. Perhaps you think libraries should always be in C in order to avoid the use of unsafePerformIO, but I prefer to allow them to be written in Haskell. But then, I don't see unsafePerformIO as inherently a hack. It's the only possible way that certain useful abstractions can be impelemented--at least, that's understanding. I'd be curious as to how much of the Prelude would be marked unsafe if you had your wish... David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why purely in haskell?
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 and myself did some thinking about this lately and put some stuff on paper that I presented two days ago at PEPM [1]. Here's a quote, taken from the introduction: Functional programming languages can be classified along several axes: we can distinguish between pure and impure langauges as well as between langauges with strict and nonstrict semantics. In practice, not all combinations make sense. Nonstrict languages better be pure, because reasoning about unrestricted side-effects becomes more complicated when the order of evaluation gets less predictable. Purity has some clear advantages. For example, it enables equational reasoning and it opens the road to memoization, common subexpression elimination, and parallel evaluation strategies. The driving force that enables these opportunities is referential transparency: in a pure language, each of a program's terms can, at any time, be replaced by its value without changing the meaning of the program as a whole. Cheers, Stefan - [1] Jurriaan Hage and Stefan Holdermans. Heap recycling for lazy languages. In John Hatcliff, Robert Glück, and Oege de Moor, editors, _Proceedings of the 2008 ACM SIGPLAN Symposium on Partial Evaluation and Semantics-Based Program Manipulation_, PEPM'08, San Francisco, California, USA, January 7--8, 2008, pages 189--197. ACM Press, 2008. http://doi.acm.org/10.1145/1328408.1328436 .___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why purely in haskell?
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 is a good idea. It comes down to a question of whether you think it should be allowed for Haskell code to be used to write core Haskell libraries in a first-class manner. Perhaps you think libraries should always be in C in order to avoid the use of unsafePerformIO, but I prefer to allow them to be written in Haskell. The Modula-3 designers acknowledged that there are things that should not be done, but must be done, illustrated by the quotation: There are some cases that no law can be framed to cover. That is, marking a module as UNSAFE does not discourage their usage, but it swaps the burden of proof: For a safe module the compiler guarantees that nasty things can't happen, for an unsafe module the programmer must provide this warranty. If your program seg-faults you only have to scan the UNSAFE modules. For running untrusted Haskell code, this means, that if someone sends Haskell code to you (maybe as solution of an exercise) that is labelled 'safe' and uses no IO or a restricted IO wrapper type, then some especially nasty things can't happen - however the according Wiki page lists even more problems. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why purely in haskell?
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 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 is a good idea. I think the point is (should be) to mark functions unsafe when they may be unsafe to /use/, and not when they just make use of potentially unsafe functionality. It is perfectly reasonable to write safe (pure) code that uses unsafe ones. You just have to trust the author to get it right. I'd be curious as to how much of the Prelude would be marked unsafe if you had your wish... All of it? In the end it is all passed to GCC (or generates assembly), which is inherently unsafe. :-) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why purely in haskell?
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 used. 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 is a good idea. I think the point is (should be) to mark functions unsafe when they may be unsafe to /use/, I think using the IO monad for this works well... -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why purely in haskell?
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 out, this is crucial functionality, and is only unsafe if unsafely used. 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 is a good idea. I think the point is (should be) to mark functions unsafe when they may be unsafe to /use/, I think using the IO monad for this works well... Would you suggest moving head and tail into the IO monad? -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why purely in haskell?
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 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 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 is a good idea. I think the point is (should be) to mark functions unsafe when they may be unsafe to /use/, I think using the IO monad for this works well... Would you suggest moving head and tail into the IO monad? They're not really unsafe, though, they just have the potential to fail (from which you can recover). Unsafe to me mean may reformat your harddrive, kill your dog, and break up with your girlfriend. They really should return a Maybe type, but I recognize that this would be inconvenient (so would having e.g. integer division returning Maybe). -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why purely in haskell?
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 want. http://research.microsoft.com/~simonpj/papers/history-of-haskell/ It's interesting reading, I promise! ;-) D. -- Dougal Stanton [EMAIL PROTECTED] // http://www.dougalstanton.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why purely in haskell?
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! ;-) I actually think it was a really interesting read when i read it a year ago or so! :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why purely in haskell?
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 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! ;-) 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 it's safe to say Haskell insists on being pure no more than water insists on being wet. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why purely in haskell?
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 Haskell wasn't pure, I would not spent so much time trying to bend my over-imperative mind to it. I had it with impure languages, way to tricky. Those languages were nice when I was young reckless :) 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 nothing compared to that! So I guess that with such great power comes great responsibility? Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why purely in haskell?
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 nothing compared to that! So I guess that with such great power comes great responsibility? Scheme and Lisp typically constrain this feature in various ways, ranging from compiler options and declarations to, more recently, features of a module system. For example, in R6RS Scheme, variables and syntax imported via the module system cannot be mutated, so the denotation of a name (including names like +) can be statically determined. 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. Anton ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why purely in haskell?
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 high assurance software, or for new kinds of optimisations, or if you want to reorder code in the compiler for parallelism). Then the downside to arbitrary, untracked effects in the system is huge. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why purely in haskell?
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 assurance (say for high assurance software, or for new kinds of optimisations, or if you want to reorder code in the compiler for parallelism). Then the downside to arbitrary, untracked effects in the system is huge. 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. ;) But by can be vanishingly small, I definitely meant something like in cases where it's technically and economically appropriate. Anton ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why purely in haskell?
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 small, unless you need to have any kind of static assurance (say for high assurance software, or for new kinds of optimisations, or if you want to reorder code in the compiler for parallelism). Then the downside to arbitrary, untracked effects in the system is huge. 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. (Yes, it's unsafe, but you can write a safe module with a purely safe interface that uses unsafePerformIO in its core.) David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why purely in haskell?
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 downside can be vanishingly small. It can be small, unless you need to have any kind of static assurance (say for high assurance software, or for new kinds of optimisations, or if you want to reorder code in the compiler for parallelism). Then the downside to arbitrary, untracked effects in the system is huge. 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 are some times necessary. The good thing about Haskell is, that hacks look like hacks. 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? Wouldn't this also simplify http://www.haskell.org/haskellwiki/Safely_running_untrusted_Haskell_code ? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why purely in haskell?
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 kind of static assurance (say for high assurance software, or for new kinds of optimisations, or if you want to reorder code in the compiler for parallelism). Then the downside to arbitrary, untracked effects in the system is huge. 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 :) -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why purely in haskell?
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 you're looking for a co-author, and you're willing to tackle the high-assurance parts, I have years of experience with arbitrary untracked effects. ;-) Graham ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
