Send Beginners mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://www.haskell.org/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. mind your head, was: Parsing a file with data divided into
sections (Christian Maeder)
2. Re: [Haskell-cafe] Just how unsafe is unsafe (Peter Verswyvelen)
3. Re: Just how unsafe is unsafe (Thomas Davie)
4. Re: Just how unsafe is unsafe (Achim Schneider)
5. Re: mind your head, was: Parsing a file with data divided
into sections (Christian Maeder)
6. Re: mind your head, was: Parsing a file with data divided
into sections (Magnus Therning)
7. Re: mind your head, was: Parsing a file with data divided
into sections (Christian Maeder)
8. Re: Re: mind your head, was: Parsing a file with data
divided into sections (Magnus Therning)
9. Re: Just how unsafe is unsafe (Antoine Latter)
----------------------------------------------------------------------
Message: 1
Date: Thu, 05 Feb 2009 10:58:30 +0100
From: Christian Maeder <[email protected]>
Subject: [Haskell-beginners] mind your head, was: Parsing a file with
data divided into sections
To: Magnus Therning <[email protected]>
Cc: beginners <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
Magnus Therning wrote:
>> isSection line = not . isSpace . head $ line
I'ld be more careful with "head"! Imagine your binary fails with:
Prelude.head: empty list
> countDays [] = []
> countDays ls = let
> day = head ls
> count = length $ takeWhile (isSpace . head) $ tail ls
> in (day, count) : countDays (drop (1 + count) ls)
here too, and better use a pattern like: ls@(hd, tl)
Cheers Christian
------------------------------
Message: 2
Date: Thu, 5 Feb 2009 23:16:56 +0100
From: Peter Verswyvelen <[email protected]>
Subject: [Haskell-beginners] Re: [Haskell-cafe] Just how unsafe is
unsafe
To: Jake McArthur <[email protected]>
Cc: Beginners Haskell <[email protected]>, Haskell Cafe
<[email protected]>
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
I do have asked myself the question whether a "really random generating"
function could be regarded as "pure" somehow (actually would a true random
function still be a mathematical function?)
E.g. the function would return a true (not pseudo) random number,
practically unpredictable (e.g. hardware assisted, using some physical
phenomenon, e.g. using atmospheric noise or something). So you surely won't
get referential transparency but since the function is really random, this
would be correct behavior?
Of course you could just put this random generator in the IO monad, but
certain algorithms- like Monte Carlo - intuitively don't seem to operate in
a IO monad to me.
Okay, just some thoughts from someone who knows absolutely nothing about
category theory or advanced computer science, so don't shoot me ;-)
On Thu, Feb 5, 2009 at 10:36 PM, Jake McArthur <[email protected]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Andrew Wagner wrote:
> | I understand that unsafeXXX allows impurity, which defiles our ability
> | to reason logically about haskell programs like we would like to. My
> | question is, to what extent is this true?
>
> My opinion is that unsafeXXX is acceptable only when its use is
> preserved behind an abstraction that is referentially transparent and
> type safe. Others may be able to help refine this statement.
>
> | Suppose we had a module, UnsafeRandoms, which had a function that would
> | allow you to generate a different random number every time you call it.
> | The semantics are relatively well-defined, impurity is safely sectioned
> | off in its own impure module, which is clearly labeled as such. How much
> | damage does this do?
>
> This does not preserve referential transparency, so by my criteria above
> this is an unacceptable use of an unsafe function. One reason it's a bad
> idea is that it removes determinism, which may be very important for
> testability.
>
> - - Jake
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkmLW/MACgkQye5hVyvIUKniOACfQGPLiY65+eiMfsv7BlbYLI++
> Bd0An1N5wp6TDkJzhmdw831/Gj45Bv9S
> =TnQg
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Haskell-Cafe mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.haskell.org/pipermail/beginners/attachments/20090205/7eb748bf/attachment-0001.htm
------------------------------
Message: 3
Date: Fri, 6 Feb 2009 08:08:54 +0100
From: Thomas Davie <[email protected]>
Subject: Re: [Haskell-beginners] Just how unsafe is unsafe
To: Andrew Wagner <[email protected]>
Cc: Beginners Haskell <[email protected]>, Haskell Cafe
<[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed;
delsp=yes
On 5 Feb 2009, at 22:11, Andrew Wagner wrote:
> So we all know the age-old rule of thumb, that unsafeXXX is simply
> evil and anybody that uses it should be shot (except when it's ok).
>
> I understand that unsafeXXX allows impurity, which defiles our
> ability to reason logically about haskell programs like we would
> like to. My question is, to what extent is this true?
>
> Suppose we had a module, UnsafeRandoms, which had a function that
> would allow you to generate a different random number every time you
> call it. The semantics are relatively well-defined, impurity is
> safely sectioned off in its own impure module, which is clearly
> labeled as such. How much damage does this do?
The problem here is composability you have no idea how far your non
referentially transparent code has spread, because you can compose
functions together willy nilly, meaning your random numbers can get
pushed through all sorts of things, and cause odd behaviors (e.g. if a
constant happens to get evaluated twice rather than once, and return
different values each time).
> Can we push the lines elsewhere? Is sectioning unsafeXXX into Unsafe
> modules a useful idiom that we can use for other things as well?
Well not useful modules, but useful types instead. The point of IO
for example is to deliberately construct an environment in which you
can't get one of your unsafe values out into the referentially
transparent world the IO type denotes the line on which one side
contains unsafe values, and the other side does not.
There are however some instances where unsafe functions *are* safe,
Conal's unamb function for example, always returns the same value (as
long as its precondition is met), even though it contains IO based
code to race the values.
There are also some instances where unsafe functions are safe purely
through force of will. For example:
type ResourcePath = FilePath
loadImageResource :: ResourcePath -> Image
loadImageResource = unsafePerformIO . loadImage =<< readFile
This is safe iff you treat the resource as a part of your program,
just like your program's code, if it changes, the world falls down,
but as long as it's still there and still the same, you're entirely
safe.
Bob
------------------------------
Message: 4
Date: Fri, 6 Feb 2009 08:15:23 +0100
From: Achim Schneider <[email protected]>
Subject: [Haskell-beginners] Re: Just how unsafe is unsafe
To: [email protected]
Cc: [email protected]
Message-ID: <20090206081523.1eba9...@solaris>
Content-Type: text/plain; charset=US-ASCII
Peter Verswyvelen <[email protected]> wrote:
> I do have asked myself the question whether a "really random
> generating" function could be regarded as "pure" somehow (actually
> would a true random function still be a mathematical function?)
>
Wasn't there some agreement some time ago on this list that the
universe itself is pure and computers are just simulating impurity by
being, essentially, state monads on steroids?
--
(c) this sig last receiving data processing entity. Inspect headers
for copyright history. All rights reserved. Copying, hiring, renting,
performance and/or quoting of this signature prohibited.
------------------------------
Message: 5
Date: Fri, 06 Feb 2009 09:47:45 +0100
From: Christian Maeder <[email protected]>
Subject: [Haskell-beginners] Re: mind your head, was: Parsing a file
with data divided into sections
To: beginners <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
I wrote:
> Magnus Therning wrote:
>>> isSection line = not . isSpace . head $ line
>
> I'ld be more careful with "head"! Imagine your binary fails with:
>
> Prelude.head: empty list
see also
http://haskell.org/haskellwiki/Haskell_programming_tips#Partial_functions_like_fromJust_and_head
>> countDays [] = []
>> countDays ls = let
>> day = head ls
>> count = length $ takeWhile (isSpace . head) $ tail ls
>> in (day, count) : countDays (drop (1 + count) ls)
>
> here too, and better use a pattern like: ls@(hd, tl)
oops, the pattern should be: ls@(hd : tl)
Cheers again
Christian
------------------------------
Message: 6
Date: Fri, 6 Feb 2009 09:52:28 +0000
From: Magnus Therning <[email protected]>
Subject: [Haskell-beginners] Re: mind your head, was: Parsing a file
with data divided into sections
To: Christian Maeder <[email protected]>
Cc: beginners <[email protected]>
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=UTF-8
On Fri, Feb 6, 2009 at 8:47 AM, Christian Maeder
<[email protected]> wrote:
> I wrote:
>> Magnus Therning wrote:
>>>> isSection line = not . isSpace . head $ line
>>
>> I'ld be more careful with "head"! Imagine your binary fails with:
>>
>> Prelude.head: empty list
>
> see also
> http://haskell.org/haskellwiki/Haskell_programming_tips#Partial_functions_like_fromJust_and_head
>
>>> countDays [] = []
>>> countDays ls = let
>>> day = head ls
>>> count = length $ takeWhile (isSpace . head) $ tail ls
>>> in (day, count) : countDays (drop (1 + count) ls)
>>
>> here too, and better use a pattern like: ls@(hd, tl)
>
> oops, the pattern should be: ls@(hd : tl)
Another course of action would be to add exception handling; if head
throws an exception then the input file isn't following the accepted
syntax.
/M
--
Magnus Therning (OpenPGP: 0xAB4DFBA4)
magnusï¼ therningï¼org Jabber: magnusï¼ therningï¼org
http://therning.org/magnus identi.ca|twitter: magthe
------------------------------
Message: 7
Date: Fri, 06 Feb 2009 11:30:33 +0100
From: Christian Maeder <[email protected]>
Subject: [Haskell-beginners] Re: mind your head, was: Parsing a file
with data divided into sections
Cc: beginners <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
Magnus Therning wrote:
[...]
>>>>> isSection line = not . isSpace . head $ line
In this particular case I would use:
isSection = null . takeWhile isSpace
>>> Prelude.head: empty list
>> see also
>> http://haskell.org/haskellwiki/Haskell_programming_tips#Partial_functions_like_fromJust_and_head
>
> Another course of action would be to add exception handling; if head
> throws an exception then the input file isn't following the accepted
> syntax.
I'ld rather check all lines before (or filter non empty ones) than
trying to catch Prelude.head: empty list!
C.
------------------------------
Message: 8
Date: Fri, 6 Feb 2009 10:40:15 +0000
From: Magnus Therning <[email protected]>
Subject: Re: [Haskell-beginners] Re: mind your head, was: Parsing a
file with data divided into sections
To: Christian Maeder <[email protected]>
Cc: beginners <[email protected]>
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=UTF-8
On Fri, Feb 6, 2009 at 10:30 AM, Christian Maeder
<[email protected]> wrote:
[..]
>> Another course of action would be to add exception handling; if head
>> throws an exception then the input file isn't following the accepted
>> syntax.
>
> I'ld rather check all lines before (or filter non empty ones) than
> trying to catch Prelude.head: empty list!
Yes, that's how I modified my own "solution" once I tracked down what
sort of input it would fail on:
main = interact (unlines . map show . countDays . dropWhile null . lines)
/M
--
Magnus Therning (OpenPGP: 0xAB4DFBA4)
magnusï¼ therningï¼org Jabber: magnusï¼ therningï¼org
http://therning.org/magnus identi.ca|twitter: magthe
------------------------------
Message: 9
Date: Fri, 6 Feb 2009 06:00:21 -0600
From: Antoine Latter <[email protected]>
Subject: Re: [Haskell-beginners] Just how unsafe is unsafe
To: Andrew Wagner <[email protected]>
Cc: Beginners Haskell <[email protected]>, Haskell Cafe
<[email protected]>
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Feb 5, 2009 at 3:11 PM, Andrew Wagner <[email protected]> wrote:
> So we all know the age-old rule of thumb, that unsafeXXX is simply evil and
> anybody that uses it should be shot (except when it's ok).
> I understand that unsafeXXX allows impurity, which defiles our ability to
> reason logically about haskell programs like we would like to. My question
> is, to what extent is this true?
Tangential to all of this - sometimes my unsafeXXX functions are pure,
but partial. So I'll have:
foo :: a -> b -> Maybe c
and
unsafeFoo :: a -> b -> c
-Antoine
------------------------------
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 8, Issue 4
***************************************
