Re: [Haskell-cafe] hipmunkplayground on windows

[Felipe Lessa]

On Tue, Nov 17, 2009 at 10:21:07PM -0800, Anatoly Yakovenko wrote:
> Anyone else seeing a bunch of linker errors when trying to install
> HipmunkPlayground?

Hmmm, no, I've never seen those errors before.  Are you able to
compile any OpenGL programs at all?  You may try, for example,
installing the game 'bloxorz'[1].

[1] http://hackage.haskell.org/package/bloxorz

Cheers,

--
Felipe.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] hipmunkplayground on windows

[Anatoly Yakovenko]

Anyone else seeing a bunch of linker errors when trying to install
HipmunkPlayground?

this is what i see:

C:\Program 
Files\Haskell\OpenGL-2.2.3.0\ghc-6.10.4/libHSOpenGL-2.2.3.0.a(RenderMode.o):fake:(.text+0x5be):
more undefined references to `glRenderMode' follow
C:\Program 
Files\Haskell\OpenGL-2.2.3.0\ghc-6.10.4/libHSOpenGL-2.2.3.0.a(Environments.o):fake:(.text+0x1c25):
undefined reference to `glGetTexEnvfv'
C:\Program 
Files\Haskell\OpenGL-2.2.3.0\ghc-6.10.4/libHSOpenGL-2.2.3.0.a(Environments.o):fake:(.text+0x5779):
undefined reference to `glTexEnvi'
C:\Program 
Files\Haskell\OpenGL-2.2.3.0\ghc-6.10.4/libHSOpenGL-2.2.3.0.a(Environments.o):fake:(.text+0x58f5):
undefined reference to `glGetTexEnviv'
C:\Program 
Files\Haskell\OpenGL-2.2.3.0\ghc-6.10.4/libHSOpenGL-2.2.3.0.a(Environments.o):fake:(.text+0x5aba):
undefined reference to `glTexEnvf'
C:\Program 
Files\Haskell\OpenGL-2.2.3.0\ghc-6.10.4/libHSOpenGL-2.2.3.0.a(Environments.o):fake:(.text+0x5c7d):
undefined reference to `glGetTexEnvfv'
C:\Program 
Files\Haskell\OpenGL-2.2.3.0\ghc-6.10.4/libHSOpenGL-2.2.3.0.a(Environments.o):fake:(.text+0x6d51):
undefined reference to `glTexEnvfv'
C:\Program 
Files\Haskell\OpenGL-2.2.3.0\ghc-6.10.4/libHSOpenGL-2.2.3.0.a(Queries.o):fake:(.text+0x339):
undefined reference to `glGetTexLevelParameteriv'
collect2: ld returned 1 exit status
cabal.exe: Error: some packages failed to install:
HipmunkPlayground-5.0.0 failed during the building phase. The exception was:
exit: ExitFailure 1
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] omitting params in function bindings

[Edward Kmett]

There is the property that once you 'move across the = to the right', the
pattern matcher isn't allowed to backtrack and try other patterns any more,
which might introduce some funny business. Though, I can't -- at the moment
-- come up with a way that it would break anything.

-Edward Kmett

On Tue, Nov 17, 2009 at 2:20 PM, Doug McIlroy  wrote:

> Is there a deep reason (beyond saving a sentence
> or two in the language definition) for requiring
> all patterns in a function binding to have the
> same explicit arity?
>
> For example, in
>dropWhile0 :: Num a => [a] -> [a]
>dropWhile0 (0:xs) = dropWhile0 xs
>dropWhile0 xs = xs
> why shouldn't the last line be replaceable by
>dropWhile0 = id
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Re[Haskell-cafe] cursive to foldr

[David Menendez]

On Tue, Nov 17, 2009 at 10:01 PM, Luke Palmer  wrote:
> filter even [0..]    -->    [0,2,4,6,8,...]
> searchList even [0...]   -->   Just [0,2,4,6,8,...]
>
> searchList gives Nothing in exactly those cases that filter gives [].
> They give _|_ in exactly the same situations.  searchList could well
> be defined as:
>
> searchList p xs = if null ys then Nothing else Just ys
>    where ys = filter p xs
>
> null is strict, so searchList is just as strict as filter.

You're right. I was thinking of traverse with an exception monad.

To make up for it, I'll note that with the recently (re)proposed
mfilter, you can define searchList as:

searchList p = mfilter (not . null) . Just . filter p

-- 
Dave Menendez 

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Status of TypeDirectedNameResolution proposal?

[Roman Leshchinskiy]

Simon, have you given any thought to how this interacts with type system 
extensions, in particular with GADTs and type families? The proposal relies on 
being able to "find the type" of a term but it's not entirely clear to me what 
that means. Here is an example:

foo :: F Int -> Int
foo :: Int -> Int

bar1 :: Int -> Int
bar1 = foo

bar2 :: Int ~ F Int => Int -> Int
bar2 = foo

IIUC, bar1 is ok but bar2 isn't. Do we realy want to have such a strong 
dependency between name lookup and type inference? Can name lookup be specified 
properly without also having to specify the entire inference algorithm?

Another example: suppose we have

data T a where
  TInt  :: T Int
  TBool :: T Bool

foo :: T Int -> u
foo :: T Bool -> u

bar :: T a -> u
bar x = case x of
  TInt  -> foo x
  TBool -> foo x

Here, (foo x) calls different functions in the two alternatives, right? To be 
honest, that's not something I'd like to see in Haskell.

Roman


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: ANNOUNCE: deepseq-1.0.0.0

[Malcolm Wallace]

The documentation claim that "The default implementation of  
'deepseq' is simply 'seq'" is not exactly right, as `deepseq` and  
`seq` have different signatures.


Yes indeed.  In order to use deepseq, it looks like I also need some  
way to force the () return value, e.g.


let res = deepseq (my big computation)
in res `seq` use res

or

let res = deepseq (my big computation)
in case res of () -> use res

I suppose the advantage of this approach is to ensure that the user  
must let-bind the forced value to a name.  A beginner might write

(my big computation) `seq` use (my big computation)
without realising that it fails to do what they desire.

Regards,
Malcolm

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: ANNOUNCE: deepseq-1.0.0.0

[Luke Palmer]

On Tue, Nov 17, 2009 at 8:48 PM, Dean Herington
 wrote:
> The documentation claim that "The default implementation of 'deepseq' is
> simply 'seq'" is not exactly right, as `deepseq` and `seq` have different
> signatures.  Which raises the more interesting question: Why did you choose
> a different signature?  And, would a version of `seq` with the same
> signature as `deepseq` be useful?

The situation is analogous to, say, "null" having this signature:

null :: [a] -> Bool

Instead of this one:

null :: [a] -> b -> b -> b

Or the recent famous debate about returning Maybe a vs. Monad m => m a
for failure.

If we have seq' :: a -> (), then we have

seq = m . seq'
  where m () = id

And of course we can go the other way too.

So it is a question of taste.  deepseq is simpler by at least two
standards: it is not polymorphic and it has only one argument.  There
are exactly two values of both () and forall b. b -> b, but that fact
is more obvious of the former (IMO).  I think it is the right choice.

Luke
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: ANNOUNCE: deepseq-1.0.0.0

[Dean Herington]

At 11:00 AM + 11/17/09, Simon Marlow wrote:

I've just uploaded deepseq-1.0.0.0 to Hackage

  http://hackage.haskell.org/package/deepseq

This provides a DeepSeq class with a deepseq method, equivalent to 
the existing NFData/rnf in the parallel package.  I'll be using this 
in a newly revamped parallel package, which I hope to upload shortly.


Cheers,
Simon


The documentation claim that "The default implementation of 'deepseq' 
is simply 'seq'" is not exactly right, as `deepseq` and `seq` have 
different signatures.  Which raises the more interesting question: 
Why did you choose a different signature?  And, would a version of 
`seq` with the same signature as `deepseq` be useful?


Dean
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] omitting params in function bindings

[Malcolm Wallace]

Doug McIlroy wrote:


Is there a deep reason (beyond saving a sentence
or two in the language definition) for requiring
all patterns in a function binding to have the
same explicit arity?


Perhaps it is more likely that a clause omitting an argument is a  
mistake by the programmer, than that it was an intentional eta- 
conversion.


Regards,
   Malcolm
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Status of TypeDirectedNameResolution proposal?

[wren ng thornton]

Neil Brown wrote:
Having skimmed the page, it seems like the re-use of "." is one of the 
major difficulties of the proposal.  Would it be possible to use "->"?  
It has been used for accessing members in C and C++, so it is not too 
unusual a choice.


It's also the one that Perl went with.


It is already special in Haskell so it wouldn't break 
anyone's code -- but do its other uses (case statements and lambdas) 
mean that it would cause problems in the grammar if re-used for TDNR?


Given the other uses of -> in Haskell, I'm hesitant to suggest it 
either. I seem to recall # is the option used by OCaml and a few other 
functional-OO languages. So far as I know -XMagicHash is the only thing 
that would conflict with that name so it seems far less invasive than . 
or ->. Another option would be to use @ which is currently forbidden in 
expressions, though that might cause issues with System F/Core.


--
Live well,
~wren
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Re[Haskell-cafe] cursive to foldr

[Luke Palmer]

On Tue, Nov 17, 2009 at 7:39 PM, David Menendez  wrote:
> On Tue, Nov 17, 2009 at 6:31 PM, Ezra Lalonde  wrote:
>>
>> Using the same basic structure you did, and foldr, I think below is the
>> simplest method:
>>
>> 
>> import Data.Maybe
>>
>> searchList :: (a -> Bool) -> [a] -> Maybe [a]
>> searchList p xs = foldr (\x acc -> if p x then Just (x: fromMaybe [] acc)
>> else acc) Nothing xs
>> 
>
> This might be considered simpler:
>
> searchList p = foldr (\x -> if p x then Just . maybe [x] (x:) else id) Nothing
>
> The real problem with searchList is that it's strict and can't be made
> lazy. Because it returns Nothing when nothing matches the predicate,
> it has to traverse the entire list before returning anything. Instead,
> I would recommend filter, which can be used as-is or defined in terms
> of foldr.
>
> filter p = foldr (\x -> if p x then (x:) else id) []
>
> Compare the behavior of "searchList even [0..]" and "filter even [0..]".

...?

filter even [0..]-->[0,2,4,6,8,...]
searchList even [0...]   -->   Just [0,2,4,6,8,...]

searchList gives Nothing in exactly those cases that filter gives [].
They give _|_ in exactly the same situations.  searchList could well
be defined as:

searchList p xs = if null ys then Nothing else Just ys
where ys = filter p xs

null is strict, so searchList is just as strict as filter.

Luke
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Re[Haskell-cafe] cursive to foldr

[David Menendez]

On Tue, Nov 17, 2009 at 6:31 PM, Ezra Lalonde  wrote:
>
> Using the same basic structure you did, and foldr, I think below is the
> simplest method:
>
> 
> import Data.Maybe
>
> searchList :: (a -> Bool) -> [a] -> Maybe [a]
> searchList p xs = foldr (\x acc -> if p x then Just (x: fromMaybe [] acc)
> else acc) Nothing xs
> 

This might be considered simpler:

searchList p = foldr (\x -> if p x then Just . maybe [x] (x:) else id) Nothing

The real problem with searchList is that it's strict and can't be made
lazy. Because it returns Nothing when nothing matches the predicate,
it has to traverse the entire list before returning anything. Instead,
I would recommend filter, which can be used as-is or defined in terms
of foldr.

filter p = foldr (\x -> if p x then (x:) else id) []

Compare the behavior of "searchList even [0..]" and "filter even [0..]".

-- 
Dave Menendez 

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] GHCi's :t misbehaving

[Luke Palmer]

It's very hard to tell what is going on without more details.  If you
*at least* give the ghci session, and possibly the whole code (while
it might be too much to read, it is not to much to load and try
ourselves).

This looks like a monomorphism restriction, which shouldn't happen
when you are using :t.  So that's why more info is necessary.

Luke

On Tue, Nov 17, 2009 at 6:31 PM, Philippa Cowderoy  wrote:
> I have some mildly complicated parsing code, that uses parsec to return a
> computation (in a state monad) that handles operator precedence - so I can
> handle scoped precedence/fixities, much like in Haskell. I just spent a
> while bolting on some new features. More time than I'd like, I'd left it
> alone for a while and it took a bit of time getting my head around it again
> enough to be okay doing folds on parse results and the like. Enough so that
> I've been leaning on the type checker to tell me when I've messed up!
>
> So, I have something that loads into ghci okay now. I go to check the type
> of one of the functions using :t and get this error:
> :1:0:
>   Ambiguous type variable `m' in the constraint:
>     `Monad m'
>       arising from a use of `constructor' at :1:0-10
>   Probable fix: add a type signature that fixes these type variable(s)
>
> Now I'm not about the supply the type signature, that's what I asked it for!
> And it ought to typecheck okay, given that the code loaded in the first
> place. I'm about to turn in for the night, but I'm wondering what's going on
> here. Anyone?
>
> --
> fli...@flippac.org
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] GHCi's :t misbehaving

[Philippa Cowderoy]

I have some mildly complicated parsing code, that uses parsec to return 
a computation (in a state monad) that handles operator precedence - so I 
can handle scoped precedence/fixities, much like in Haskell. I just 
spent a while bolting on some new features. More time than I'd like, I'd 
left it alone for a while and it took a bit of time getting my head 
around it again enough to be okay doing folds on parse results and the 
like. Enough so that I've been leaning on the type checker to tell me 
when I've messed up!


So, I have something that loads into ghci okay now. I go to check the 
type of one of the functions using :t and get this error:

:1:0:
   Ambiguous type variable `m' in the constraint:
 `Monad m'
   arising from a use of `constructor' at :1:0-10
   Probable fix: add a type signature that fixes these type variable(s)

Now I'm not about the supply the type signature, that's what I asked it 
for! And it ought to typecheck okay, given that the code loaded in the 
first place. I'm about to turn in for the night, but I'm wondering 
what's going on here. Anyone?


--
fli...@flippac.org
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: help with musical data structures

[Rohan Drape]

On 2009-11-15, Michael Mossey  wrote:

> I will need a function that computes prime (normal?)
> form, of course, and it is just begging to be
> memoized.

there are some prime form algorithms at

http://hackage.haskell.org/packages/archive/hmt/0.1/doc/html/Music-Theory-Prime.html

completely naive and un-optimised, but this has never
been an issue in my experience.

bests
rohan

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Re[Haskell-cafe] cursive to foldr

[Ezra Lalonde]

Using the same basic structure you did, and foldr, I think below is the
simplest method:


import Data.Maybe

searchList :: (a -> Bool) -> [a] -> Maybe [a]
searchList p xs = foldr (\x acc -> if p x then Just (x: fromMaybe [] acc)
else acc) Nothing xs


ghci> searchList (=='o') "A quick brown fox"
Just "oo"
ghci> searchList (==' ') "A quick brown fox"
Just "   "
ghci> searchList (=='z') "A quick brown fox"
Nothing


>From maybe gets rid of the Maybe, so that our recursive call works:
ghci> fromMaybe [] (Just [1..3])
[1,2,3]

That's why we got the error below when we tried without fromMaybe; on
subsequent applications of foldr, the type would have to change.

:1:51:
Couldn't match expected type `[a]'
   against inferred type `Maybe [a]'
In the expression: if p x then Just (x : acc) else acc
In the first argument of `foldr', namely
`(\ x acc -> if p x then Just (x : acc) else acc)'
In the expression:
foldr (\ x acc -> if p x then Just (x : acc) else acc) Nothing xs


I have a feeling that using fromMaybe is not the best way, but it gets the
job done for now.

On that note; if somebody with some more experience would chime in, that'd
be awesome. ;)

Ezra


dima.neg wrote:
> 
> How can I do this using foldr?
> 
> searchList p [] = Nothing
> searchList p (x:xs)
>   | p x = Just (x:filter p xs)
>   | otherwise = searchList p xs
> 
> 
> I try this: 
> searchList p xs = foldr (\x acc -> if p x then Just (x:acc) else acc)
> Nothing xs
> but don't work.
> 
> Thanks
> 

-- 
View this message in context: 
http://old.nabble.com/Recursive-to-foldr-tp26368900p26399795.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Re[2]: [Haskell-cafe] Simple hash table creation

[michael rice]

Hi Bulat,

I was just looking for a simple hashing function. I was going to use the length 
function but a constant int is even simpler.  I'm supposing that had I used the 
length function "mike" and "fred" would end up in the same bucket.

This is the first time I've tried to do anything in Haskell with data 
structures other than lists, so I needed to see how things work.

Thanks, everyone, for the help.

Michael

--- On Tue, 11/17/09, Bulat Ziganshin  wrote:

From: Bulat Ziganshin 
Subject: Re[2]: [Haskell-cafe] Simple hash table creation
To: "michael rice" 
Cc: "Gregory Crosswhite" , haskell-cafe@haskell.org
Date: Tuesday, November 17, 2009, 4:38 PM

Hello michael,

Wednesday, November 18, 2009, 12:00:58 AM, you wrote:

*Main>> toList ht
> [("miguel",3),("michael",2),("mike",1)] 
>
> It seems my dummy function is being ignored.

i wonder why you think so?

your ht has all 3 pairs you ever inserted

inside, they all are inside the same bucket since hash function
returns the same value for them

... hmm, i guess that you expect something like low-level hashtable
from other languages - i.e. it should have just one slot for all
values hashed to 7 and save here last value

it works other way - it has just one slot for all your values but it
stores here LIST of your pairs. so nothing is lost. if you want to
save only the last value, replace (==) to (\a b -> dummy a==dummy b)

the whole story is that hash function used to select slot, and then
key part of pair is compared using (==) with keys of all values in the
slot. it will replace existing pair if key1==key2, otherwise added to
list

so, hashing allows to quickly find pair by its key, but it still full
map as far as you pass a usual (==)

-- 
Best regards,
 Bulat                            mailto:bulat.zigans...@gmail.com




  ___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re[2]: [Haskell-cafe] Simple hash table creation

[Bulat Ziganshin]

Hello michael,

Wednesday, November 18, 2009, 12:00:58 AM, you wrote:

*Main>> toList ht
> [("miguel",3),("michael",2),("mike",1)] 
>
> It seems my dummy function is being ignored.

i wonder why you think so?

your ht has all 3 pairs you ever inserted

inside, they all are inside the same bucket since hash function
returns the same value for them

... hmm, i guess that you expect something like low-level hashtable
from other languages - i.e. it should have just one slot for all
values hashed to 7 and save here last value

it works other way - it has just one slot for all your values but it
stores here LIST of your pairs. so nothing is lost. if you want to
save only the last value, replace (==) to (\a b -> dummy a==dummy b)

the whole story is that hash function used to select slot, and then
key part of pair is compared using (==) with keys of all values in the
slot. it will replace existing pair if key1==key2, otherwise added to
list

so, hashing allows to quickly find pair by its key, but it still full
map as far as you pass a usual (==)

-- 
Best regards,
 Bulatmailto:bulat.zigans...@gmail.com

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Simple hash table creation

[Brad Larsen]

On Tue, Nov 17, 2009 at 4:22 PM, michael rice  wrote:
>
> So, what you're telling me is, my dummy hash function IS being used, and 
> because of collisions the other values are placed in different locations?
>
> Michael
[...]

If Data.HashTable is implemented using separate chaining, then all the
key/value pairs would be hashed to the same bucket (hash value 7).  If
a different scheme is used, then hash collisions would be resolved in
a different way, e.g., through linear probing.  Regardless of the
collision resolution scheme used, excessive hash collisions are bad,
and are what can cause the worst-case time complexity of hash table
operations (in most implementations) to be O(n).

The Wikipedia page on hash tables isn't bad:
.

Sincerely,
Brad
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Simple hash table creation

[michael rice]

So, what you're telling me is, my dummy hash function IS being used, and 
because of collisions the other values are placed in different locations?

Michael

--- On Tue, 11/17/09, Brad Larsen  wrote:

From: Brad Larsen 
Subject: Re: [Haskell-cafe] Simple hash table creation
To: "michael rice" 
Cc: "Gregory Crosswhite" , haskell-cafe@haskell.org
Date: Tuesday, November 17, 2009, 4:17 PM

On Tue, Nov 17, 2009 at 4:00 PM, michael rice  wrote:
>
> Hi Gregory,
>
> I was wondering about that, because of the following:
>
> [1 of 1] Compiling Main ( hash1.hs, interpreted )
> Ok, modules loaded: Main.
> *Main> ht <- new (==) dummy :: IO MyHashTable
> *Main> dummy "mike"
> 7
> *Main> dummy "michael"
> 7
> *Main> insert ht "mike" 1
> *Main> toList ht
> [("mike",1)]
> *Main> insert ht "michael" 2
> *Main> toList ht
> [("michael",2),("mike",1)]
> *Main> insert ht "miguel" 3
> *Main> toList ht
> [("miguel",3),("michael",2),("mike",1)]
> *Main> :t dummy "miguel"
> dummy "miguel" :: Int32
> *Main>
>
> It seems my dummy function is being ignored. I figured I would only be able 
> to store a single value with a hash function that always returns 7. Why ask 
> for a hash function and not use it?
[...]

Most hash tables deal with collisions, i.e. the case when two keys
stored in the table hash to the same value.  In the case of your
'dummy' hash function, which always returns 7, every key hashes to the
same value, hence collisions galore.

One way to deal with collisions is to hash a key to a bucket (i.e.
list) of items, then walk down the list looking for the given key.  In
such an implementation (and I believe for hash tables in general), the
quality of the hash function greatly affects the performance of the
hash table operations.

I am not sure what implementation Data.HashTable uses.  However, I
believe Data.HashTable is not all that good:  for multi-million
element tables from Int to Int, Data.IntMap runs many times faster
than Data.HashTable.  I have no wish to start a flame war here (this
topic has in the past), but the state of affairs regarding hash tables
in Haskell is not good.

Sincerely,
Brad



  ___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Simple hash table creation

[Brad Larsen]

On Tue, Nov 17, 2009 at 4:00 PM, michael rice  wrote:
>
> Hi Gregory,
>
> I was wondering about that, because of the following:
>
> [1 of 1] Compiling Main ( hash1.hs, interpreted )
> Ok, modules loaded: Main.
> *Main> ht <- new (==) dummy :: IO MyHashTable
> *Main> dummy "mike"
> 7
> *Main> dummy "michael"
> 7
> *Main> insert ht "mike" 1
> *Main> toList ht
> [("mike",1)]
> *Main> insert ht "michael" 2
> *Main> toList ht
> [("michael",2),("mike",1)]
> *Main> insert ht "miguel" 3
> *Main> toList ht
> [("miguel",3),("michael",2),("mike",1)]
> *Main> :t dummy "miguel"
> dummy "miguel" :: Int32
> *Main>
>
> It seems my dummy function is being ignored. I figured I would only be able 
> to store a single value with a hash function that always returns 7. Why ask 
> for a hash function and not use it?
[...]

Most hash tables deal with collisions, i.e. the case when two keys
stored in the table hash to the same value.  In the case of your
'dummy' hash function, which always returns 7, every key hashes to the
same value, hence collisions galore.

One way to deal with collisions is to hash a key to a bucket (i.e.
list) of items, then walk down the list looking for the given key.  In
such an implementation (and I believe for hash tables in general), the
quality of the hash function greatly affects the performance of the
hash table operations.

I am not sure what implementation Data.HashTable uses.  However, I
believe Data.HashTable is not all that good:  for multi-million
element tables from Int to Int, Data.IntMap runs many times faster
than Data.HashTable.  I have no wish to start a flame war here (this
topic has in the past), but the state of affairs regarding hash tables
in Haskell is not good.

Sincerely,
Brad
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Simple hash table creation

[michael rice]

Hi Gregory,



I was wondering about that, because of the following:



[1 of 1] Compiling Main ( hash1.hs, interpreted )

Ok, modules loaded: Main.

*Main> ht <- new (==) dummy :: IO MyHashTable

*Main> dummy "mike"

7

*Main> dummy "michael"

7

*Main> insert ht "mike" 1

*Main> toList ht

[("mike",1)]

*Main> insert ht "michael" 2

*Main> toList ht

[("michael",2),("mike",1)]

*Main> insert ht "miguel" 3

*Main> toList ht

[("miguel",3),("michael",2),("mike",1)]

*Main> :t dummy "miguel"

dummy "miguel" :: Int32

*Main> 



It seems my dummy function is being ignored. I figured I would only be able to 
store a single value with a hash function that always returns 7. Why ask for a 
hash function and not use it?



Also, it's said that it is good programming practice  to include type
information in function definitions, so I always try to do that, even
though it usually leads to my code being rejected. I need to step back
and use the :t  and module functions defs to figure out what types are
returned and required as arguments, instead of trying to puzzle it out
myself.

Like juggling, there's a lot of balls in the air w/Haskell, lots of things to 
remember, but it's the most intriguing computer language I've looked at in a 
long time.



Thanks for your input.



Michael





--- On Tue, 11/17/09, Gregory Crosswhite  wrote:

From: Gregory Crosswhite 
Subject: Re: [Haskell-cafe] Simple hash table creation
To: "michael rice" 
Cc: haskell-cafe@haskell.org, "Daniel Fischer" 
Date: Tuesday, November 17, 2009, 3:30 PM

Look in Data.Int for a list of the Int types.
Basically you generally only use Int unless you are working at a lower-level 
which has an explicit requirement for the number of bits.  In this case, 
HashTable has such a requirement, so you have two choices:  you can either 
change the type annotation on dummy:

import Data.Int
dummy:: String -> Int32
dummy s = 7


or you can just leave it off entirely, and GHC will automatically infer the 
correct type (without you needing to import Data.Int):
dummy s = 7

On Nov 17, 2009, at 12:09 PM, michael rice wrote:
Hi Daniel,



Thanks for the IO monad reminder.



What is GHC.Int.Int32? Can't find it on Hoogle.



Michael



==



*Main> ht <- new (==) dummy :: IO MyHashTable



:1:15:

    Couldn't match expected type `GHC.Int.Int32'

   against inferred type `Int'

    In the second argument of `new', namely `dummy'

    In a stmt of a 'do' expression:

    ht <- new (==) dummy :: IO MyHashTable

*Main> :t dummy

dummy :: String -> Int

*Main> 




--- On Tue, 11/17/09, Daniel Fischer  wrote:

From: Daniel Fischer 
Subject: Re: [Haskell-cafe] Simple hash table creation
To: haskell-cafe@haskell.org
Date: Tuesday, November 17, 2009, 2:45 PM

Am Dienstag 17 November 2009 20:36:46 schrieb Daniel Fischer:
> What you probably wanted was
>
> type MyHashTable = HashTable String Int -- not data MyHashTable
>

Just in case it's not clear:

> ht <- new (==) dummy :: IO MyHashTable

only works at the prompt or in an IO do-block, not at the top level of the 
module.

>
> then ht is a hashtable of type MyHashTable.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe





  ___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe




  ___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re[2]: [Haskell-cafe] Simple hash table creation

[Bulat Ziganshin]

Hello Daniel,

Tuesday, November 17, 2009, 11:21:18 PM, you wrote:

> The hash function must have a return type of fixed and specified width, or 
> porting the app
> between 32-bit and 64-bit platforms could have enormous performance impact, 
> so it can't be
> plain Int.

i think that the problem with use of Int instead of Int32 here would
be different results with incorrect comparison functions, nothing more


-- 
Best regards,
 Bulatmailto:bulat.zigans...@gmail.com

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Simple hash table creation

[Gregory Crosswhite]

Look in Data.Int for a list of the Int types.

Basically you generally only use Int unless you are working at a lower- 
level which has an explicit requirement for the number of bits.  In  
this case, HashTable has such a requirement, so you have two choices:   
you can either change the type annotation on dummy:



import Data.Int

dummy:: String -> Int32
dummy s = 7



or you can just leave it off entirely, and GHC will automatically  
infer the correct type (without you needing to import Data.Int):


dummy s = 7


On Nov 17, 2009, at 12:09 PM, michael rice wrote:


Hi Daniel,

Thanks for the IO monad reminder.

What is GHC.Int.Int32? Can't find it on Hoogle.

Michael

==

*Main> ht <- new (==) dummy :: IO MyHashTable

:1:15:
Couldn't match expected type `GHC.Int.Int32'
   against inferred type `Int'
In the second argument of `new', namely `dummy'
In a stmt of a 'do' expression:
ht <- new (==) dummy :: IO MyHashTable
*Main> :t dummy
dummy :: String -> Int
*Main>



--- On Tue, 11/17/09, Daniel Fischer  wrote:

From: Daniel Fischer 
Subject: Re: [Haskell-cafe] Simple hash table creation
To: haskell-cafe@haskell.org
Date: Tuesday, November 17, 2009, 2:45 PM

Am Dienstag 17 November 2009 20:36:46 schrieb Daniel Fischer:
> What you probably wanted was
>
> type MyHashTable = HashTable String Int -- not data MyHashTable
>

Just in case it's not clear:

> ht <- new (==) dummy :: IO MyHashTable

only works at the prompt or in an IO do-block, not at the top level  
of the module.


>
> then ht is a hashtable of type MyHashTable.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ghci + user prelude

[Edward Z. Yang]

Excerpts from Sean McLaughlin's message of Mon Nov 16 19:06:06 -0500 2009:
> Hi.  I'm aware of this option, and use it frequently to override the
> default prelude, but it doesn't help this problem:

I suppose this is the appropriate quote from the GHC manual:

""" GHC normally imports Prelude.hi files for you. If you'd rather it didn't,
then give it a -XNoImplicitPrelude option. The idea is that you can then import
a Prelude of your own. (But don't call it Prelude; the Haskell module namespace
is flat, and you must not conflict with any Prelude module.)"""

Cheers,
Edward
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Simple hash table creation

[Daniel Fischer]

Am Dienstag 17 November 2009 21:09:26 schrieb michael rice:
> What is GHC.Int.Int32? Can't find it on Hoogle.

Int32 is the guaranteed-to-be-32-bits integer type, it's defined in the module 
GHC.Int, 
typically it's imported via Data.Int (because, naturally, using GHC's own 
modules isn't 
portable).
Due to the way ghci's :type command works, such types are printed qualified.

The hash function must have a return type of fixed and specified width, or 
porting the app 
between 32-bit and 64-bit platforms could have enormous performance impact, so 
it can't be 
plain Int.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Simple hash table creation

[Gregory Crosswhite]

You don't need to create a new type for a String -> Int hashtable, you  
already get it for free because HashTable is a parameterized type.


Also, although you are apparently trying to make life simpler for  
yourself using a HashTable, you are actually making like more  
complicated because the Data.HashTable implementation can only be  
worked with inside the IO monad.  So what you'd need is something like:





import Prelude hiding (lookup)
import Data.HashTable

dummy s = 7

main = do
ht <- new (==) dummy
insert ht "Foo" 12
value <- lookup ht "Foo"
putStrLn . show $ value



Note that I didn't have to label any of the types;  Haskell is smart  
enough to mostly infer all of them automatically.  The main reason to  
include types is if there is some ambiguity.  So for example, if you  
actually wanted to map Strings to Floats, then you would need to  
explicitly tell it somewhere that the values it is storing are  
floats.  You could do this by either pinning down explicitly the  
HashTable type:




import Prelude hiding (lookup)
import Data.HashTable

dummy s = 7

main = do
ht <- new (==) dummy  :: IO (HashTable String Float)
insert ht "Foo" 12
value <- lookup ht "Foo"
putStrLn . show $ value



Or just by pinning down the type of a value that you insert into it:



import Prelude hiding (lookup)
import Data.HashTable

dummy s = 7

main = do
ht <- new (==) dummy
insert ht "Foo" (12 :: Float)
value <- lookup ht "Foo"
putStrLn . show $ value



Again, the downside though is that you can't work with HashTable  
outside of the IO monad.  If what you want is just a map from strings  
to values, then you probably are better off using Data.Map:




import Prelude hiding (lookup)
import Data.Map

my_map = empty :: Map String Int

my_map_after_adding_key = insert "Foo" 12 my_map

value_associated_with_Foo = lookup "Foo" my_map_after_adding_key

main = putStrLn . show $ value_associated_with_Foo



Cheers,
Greg

On Nov 17, 2009, at 11:16 AM, michael rice wrote:

I'm trying to create a hash table. Yeah, I know, don't use hash  
tables, but I need to create something I'm familiar with, not  
something I've never worked with before. What's wrong with this code?


Michael



import Prelude hiding (lookup)
import Data.HashTable

data MyHashTable = HashTable String Int

dummy:: String -> Int
dummy s = 7

ht = MyHashTable.new (==) dummy



[mich...@localhost ~]$ ghci hash1
GHCi, version 6.10.3: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling Main ( hash1.hs, interpreted )

hash1.hs:9:5: Not in scope: `MyHashTable.new'
Failed, modules loaded: none.
Prelude>


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Simple hash table creation

[michael rice]

Hi Daniel,



Thanks for the IO monad reminder.



What is GHC.Int.Int32? Can't find it on Hoogle.



Michael



==



*Main> ht <- new (==) dummy :: IO MyHashTable



:1:15:

    Couldn't match expected type `GHC.Int.Int32'

   against inferred type `Int'

    In the second argument of `new', namely `dummy'

    In a stmt of a 'do' expression:

    ht <- new (==) dummy :: IO MyHashTable

*Main> :t dummy

dummy :: String -> Int

*Main> 




--- On Tue, 11/17/09, Daniel Fischer  wrote:

From: Daniel Fischer 
Subject: Re: [Haskell-cafe] Simple hash table creation
To: haskell-cafe@haskell.org
Date: Tuesday, November 17, 2009, 2:45 PM

Am Dienstag 17 November 2009 20:36:46 schrieb Daniel Fischer:
> What you probably wanted was
>
> type MyHashTable = HashTable String Int -- not data MyHashTable
>

Just in case it's not clear:

> ht <- new (==) dummy :: IO MyHashTable

only works at the prompt or in an IO do-block, not at the top level of the 
module.

>
> then ht is a hashtable of type MyHashTable.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe



  ___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Simple hash table creation

[michael rice]

Thanks all,

Got it! type rather than data and <- rather than = (should have remembered this 
from monad stuff). Also, don't need the qualification.

Onward and upward.

Thanks,

Michael

--- On Tue, 11/17/09, Daniel Fischer  wrote:

From: Daniel Fischer 
Subject: Re: [Haskell-cafe] Simple hash table creation
To: haskell-cafe@haskell.org
Date: Tuesday, November 17, 2009, 2:36 PM

Am Dienstag 17 November 2009 20:16:50 schrieb michael rice:
> I'm trying to create a hash table. Yeah, I know, don't use hash tables, but
> I need to create something I'm familiar with, not something I've never
> worked with before. What's wrong with this code?
>
> Michael
>
> 
>
> import Prelude hiding (lookup)
> import Data.HashTable
>
> data MyHashTable = HashTable String Int
>
> dummy:: String -> Int
> dummy s = 7
>
> ht = MyHashTable.new (==) dummy
>
> 

 MyHashTable.new is parsed as a qualified function, 'new' from the module 
MyHashTable. But 
there's no module MyHashTable imported, hence there's no function 'new' from 
that module 
in scope.

>
> [mich...@localhost ~]$ ghci hash1
> GHCi, version 6.10.3: http://www.haskell.org/ghc/  :? for help
> Loading package ghc-prim ... linking ... done.
> Loading package integer ... linking ... done.
> Loading package base ... linking ... done.
> [1 of 1] Compiling Main ( hash1.hs, interpreted )
>
> hash1.hs:9:5: Not in scope: `MyHashTable.new'
> Failed, modules loaded: none.
> Prelude>

If we look at the type of Data.HashTable.new:

new ::  (key -> key -> Bool)  -> (key -> GHC.Int.Int32)  -> IO (HashTable key 
val)

we see that

new (==) dummy

(or Data.HashTable.new (==) dummy, but we don't need to qualify new)
has type

IO (HashTable String val), so is an IO-action returning a hashtable.

What you probably wanted was

type MyHashTable = HashTable String Int -- not data MyHashTable

ht <- new (==) dummy :: IO MyHashTable

then ht is a hashtable of type MyHashTable.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe



  ___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Simple hash table creation

[Daniel Fischer]

Am Dienstag 17 November 2009 20:36:46 schrieb Daniel Fischer:
> What you probably wanted was
>
> type MyHashTable = HashTable String Int -- not data MyHashTable
>

Just in case it's not clear:

> ht <- new (==) dummy :: IO MyHashTable

only works at the prompt or in an IO do-block, not at the top level of the 
module.

>
> then ht is a hashtable of type MyHashTable.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Simple hash table creation

[Daniel Fischer]

Am Dienstag 17 November 2009 20:16:50 schrieb michael rice:
> I'm trying to create a hash table. Yeah, I know, don't use hash tables, but
> I need to create something I'm familiar with, not something I've never
> worked with before. What's wrong with this code?
>
> Michael
>
> 
>
> import Prelude hiding (lookup)
> import Data.HashTable
>
> data MyHashTable = HashTable String Int
>
> dummy:: String -> Int
> dummy s = 7
>
> ht = MyHashTable.new (==) dummy
>
> 

 MyHashTable.new is parsed as a qualified function, 'new' from the module 
MyHashTable. But 
there's no module MyHashTable imported, hence there's no function 'new' from 
that module 
in scope.

>
> [mich...@localhost ~]$ ghci hash1
> GHCi, version 6.10.3: http://www.haskell.org/ghc/  :? for help
> Loading package ghc-prim ... linking ... done.
> Loading package integer ... linking ... done.
> Loading package base ... linking ... done.
> [1 of 1] Compiling Main ( hash1.hs, interpreted )
>
> hash1.hs:9:5: Not in scope: `MyHashTable.new'
> Failed, modules loaded: none.
> Prelude>

If we look at the type of Data.HashTable.new:

new ::  (key -> key -> Bool)  -> (key -> GHC.Int.Int32)  -> IO (HashTable key 
val)

we see that

new (==) dummy

(or Data.HashTable.new (==) dummy, but we don't need to qualify new)
has type

IO (HashTable String val), so is an IO-action returning a hashtable.

What you probably wanted was

type MyHashTable = HashTable String Int -- not data MyHashTable

ht <- new (==) dummy :: IO MyHashTable

then ht is a hashtable of type MyHashTable.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Simple hash table creation

[Bulat Ziganshin]

Hello michael,

Tuesday, November 17, 2009, 10:16:50 PM, you wrote:

> I'm trying to create a hash table. Yeah, I know, don't use hash
> tables, but I need to create something I'm familiar with, not
> something I've never worked with before. What's wrong with this code?

> ht = MyHashTable.new (==) dummy

MyHashTable should be a name of module. seems that you try to use your OOP
instinct here :)

-- 
Best regards,
 Bulatmailto:bulat.zigans...@gmail.com

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] omitting params in function bindings

[Doug McIlroy]

Is there a deep reason (beyond saving a sentence
or two in the language definition) for requiring
all patterns in a function binding to have the
same explicit arity?

For example, in
dropWhile0 :: Num a => [a] -> [a]
dropWhile0 (0:xs) = dropWhile0 xs
dropWhile0 xs = xs
why shouldn't the last line be replaceable by
dropWhile0 = id
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Simple hash table creation

[michael rice]

I'm trying to create a hash table. Yeah, I know, don't use hash tables, but I 
need to create something I'm familiar with, not something I've never worked 
with before. What's wrong with this code?

Michael



import Prelude hiding (lookup)
import Data.HashTable

data MyHashTable = HashTable String Int

dummy:: String -> Int
dummy s = 7

ht = MyHashTable.new (==) dummy



[mich...@localhost ~]$ ghci hash1
GHCi, version 6.10.3: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling Main ( hash1.hs, interpreted )

hash1.hs:9:5: Not in scope: `MyHashTable.new'
Failed, modules loaded: none.
Prelude> 




  ___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANNOUNCE: deepseq-1.0.0.0

[Brandon S. Allbery KF8NH]

On Nov 17, 2009, at 11:36 , Bryan O'Sullivan wrote:
On Tue, Nov 17, 2009 at 3:00 AM, Simon Marlow   
wrote:

I've just uploaded deepseq-1.0.0.0 to Hackage

 http://hackage.haskell.org/package/deepseq

This provides a DeepSeq class with a deepseq method, equivalent to  
the existing NFData/rnf in the parallel package.


If it's equivalent, what are the relevant differences? Why would I  
choose DeepSeq over NFData or vice versa?



Considering that he said he's going to be using it in parallel, the  
difference is merely that it's usable *without* parallel.  It's about  
dependencies, not functionality.


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon universityKF8NH




PGP.sig
Description: This is a digitally signed message part
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Status of TypeDirectedNameResolution proposal?

[Simon Peyton-Jones]

Sigh.  Apologies.  Turns out that [1] is not publicly editable. So I've created 
a HaskellWiki page [2] and cross-linked them.

[2] http://haskell.org/haskellwiki/TypeDirectedNameResolution

You should be able to edit that!

Simon

| -Original Message-
| From: haskell-cafe-boun...@haskell.org 
[mailto:haskell-cafe-boun...@haskell.org] On
| Behalf Of Luke Palmer
| Sent: 17 November 2009 17:08
| To: Simon Peyton-Jones
| Cc: Levi Greenspan; Haskell Cafe
| Subject: Re: [Haskell-cafe] Status of TypeDirectedNameResolution proposal?
| 
| On Tue, Nov 17, 2009 at 5:18 AM, Simon Peyton-Jones
|  wrote:
| > | What's the status of the TDNR proposal [1]? Personally I think it is a
| > | very good idea and I'd like to see it in Haskell'/GHC rather sooner
| > | than later. Working around the limitations of the current record
| > | system is one of my biggest pain points in Haskell and TDNR would be a
| > | major improvement. Thus I wonder if someone is actively working on
| > | this proposal?
| >
| > It's stalled.  As far as I know, there's been very little discussion about 
it.
|  It's not a trivial thing to implement, and it treads on delicate territory 
(how "."
| is treated).  So I'd need to be convinced there was a strong constituency who 
really
| wanted it before adding it.
| >
| > I've added an informal straw poll to the bottom of [1] to allow you to 
express an
| opinion.
| 
| And how I love expressing my opinion :-P.   I would if only I could
| figure out how to edit the page!  Am I being dense?  (Yes, I am logged
| in)
| 
| Luke
| 
| > Also I'm not very happy with the "stacking operations" part, and I'd like a 
better
| idea.
| >
| > Simon
| >
| >
| > ___
| > Haskell-Cafe mailing list
| > Haskell-Cafe@haskell.org
| > http://www.haskell.org/mailman/listinfo/haskell-cafe
| >
| >
| ___
| Haskell-Cafe mailing list
| Haskell-Cafe@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to show record syntax?

[Duncan Coutts]

On Tue, 2009-11-17 at 17:14 +0100, Sean Leather wrote:

> > module Main where
> > data A = A {x :: Int} deriving Show
> > main = print $ Just A {x = 5}

> This led to an issue report [3] which developed a few responses. Some
> don't like the grammar as defined, because, at a glance, it appears
> too much like function application. Others noted that Hugs does not
> add the parentheses and wanted to see consistency between compilers.
> 
> In the spirit of the GHC Bug Sweep [4] and finding resolution, I put
> the question to the wider community. How should we show record syntax?
> Should we try to ensure consistency between the compilers? Should we
> try to print as few parentheses as possible? Should we write a
> Haskell' proposal to "fix" the grammar and make Just A {x=5} illegal?
> What do you think?

If you want my opinion, I think consistency between the compilers is
probably a good thing. I do not have a very strong opinion on whether
the derived Show instances should use the extra brackets here or not.
Just pick one. The Show output is not readable in the first place so it
does not really matter.

However I am opposed to "fixing" the grammar to add lots of unnecessary
brackets and to make my programs uglier. Using records for the named
function argument idiom is rather nice and should be encouraged not
discouraged by making the syntax for it worse.

bigChunkyCallWithLotsOfArgs defaultArgs {
someArg  = 3,
someOtherArg = 4,
  }

Lovely!

bigChunkyCallWithLotsOfArgs (defaultArgs {
someArg  = 3,
someOtherArg = 4,
  })

Bleugh!


Duncan

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Status of TypeDirectedNameResolution proposal?

[Luke Palmer]

On Tue, Nov 17, 2009 at 5:18 AM, Simon Peyton-Jones
 wrote:
> | What's the status of the TDNR proposal [1]? Personally I think it is a
> | very good idea and I'd like to see it in Haskell'/GHC rather sooner
> | than later. Working around the limitations of the current record
> | system is one of my biggest pain points in Haskell and TDNR would be a
> | major improvement. Thus I wonder if someone is actively working on
> | this proposal?
>
> It's stalled.  As far as I know, there's been very little discussion about 
> it.  It's not a trivial thing to implement, and it treads on delicate 
> territory (how "." is treated).  So I'd need to be convinced there was a 
> strong constituency who really wanted it before adding it.
>
> I've added an informal straw poll to the bottom of [1] to allow you to 
> express an opinion.

And how I love expressing my opinion :-P.   I would if only I could
figure out how to edit the page!  Am I being dense?  (Yes, I am logged
in)

Luke

> Also I'm not very happy with the "stacking operations" part, and I'd like a 
> better idea.
>
> Simon
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANNOUNCE: deepseq-1.0.0.0

[Bryan O'Sullivan]

On Tue, Nov 17, 2009 at 3:00 AM, Simon Marlow  wrote:

> I've just uploaded deepseq-1.0.0.0 to Hackage
>
>  http://hackage.haskell.org/package/deepseq
>
> This provides a DeepSeq class with a deepseq method, equivalent to the
> existing NFData/rnf in the parallel package.
> 
>

If it's equivalent, what are the relevant differences? Why would I choose
DeepSeq over NFData or vice versa?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] How to show record syntax?

[Sean Leather]

A while back, I was working on the Show function for EMGM [1] and verifying
its output vs. that of GHC's when I discovered (I thought) a minor
difference between what was necessary and what GHC did for record syntax.
Labeled construction and update, according to the Report [2], have higher
precedence than function application. This means that I can do the following

> module Main where
> data A = A {x :: Int} deriving Show
> main = print $ Just A {x = 5}

without putting parentheses around A {x = 5}. If I run this in GHCi,

  *Main> main
  Just (A {x = 5})

I see that the derived show in GHC adds parentheses around the record value.

This led to an issue report [3] which developed a few responses. Some don't
like the grammar as defined, because, at a glance, it appears too much like
function application. Others noted that Hugs does not add the parentheses
and wanted to see consistency between compilers.

In the spirit of the GHC Bug Sweep [4] and finding resolution, I put the
question to the wider community. How should we show record syntax? Should we
try to ensure consistency between the compilers? Should we try to print as
few parentheses as possible? Should we write a Haskell' proposal to "fix"
the grammar and make Just A {x=5} illegal? What do you think?

[1]
http://hackage.haskell.org/packages/archive/emgm/0.3.1/doc/html/Generics-EMGM-Functions-Show.html
[2] http://www.haskell.org/onlinereport/exps.html#sect3
[3] http://hackage.haskell.org/trac/ghc/ticket/2530
[4] http://hackage.haskell.org/trac/ghc/wiki/BugSweep

Regards,
Sean
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Status of TypeDirectedNameResolution proposal?

[Daniel Fischer]

Am Dienstag 17 November 2009 15:36:52 schrieb Levi Greenspan:
> As pointed out by others one may choose a different string instead of
> "." like "->"  if this makes the implementation of TDNR feasible.

Or, if both of these strings would make the implementation awkward, one can 
choose a 
different but similar, "~>", "-->" (to annoy bad syntax highlighters 8-)), 
which is 
neither special in Haskell syntax nor a prominent operator from a library.
I wouldn't lay much stress on using the same notation as other languages. After 
all, we 
have (/=) instead of (!=) and it works.

> But some mechanism to have some sort of scoped record selectors or TDNR is
> needed in my opinion.

I haven't needed the feature yet, but I think it would be A Good Thing™ to have 
it.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Status of TypeDirectedNameResolution proposal?

[Levi Greenspan]

On Tue, Nov 17, 2009 at 1:18 PM, Simon Peyton-Jones
 wrote:
> I've added an informal straw poll to the bottom of [1] to allow you to 
> express an opinion.

Forgive my ignorance, but I can not find a way to edit the wiki page.
What am I doing wrong?

Cheers,
Levi
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Status of TypeDirectedNameResolution proposal?

[Levi Greenspan]

On Tue, Nov 17, 2009 at 1:18 PM, Simon Peyton-Jones
 wrote:
> | What's the status of the TDNR proposal [1]? Personally I think it is a
> | very good idea and I'd like to see it in Haskell'/GHC rather sooner
> | than later. Working around the limitations of the current record
> | system is one of my biggest pain points in Haskell and TDNR would be a
> | major improvement. Thus I wonder if someone is actively working on
> | this proposal?
>
> It's stalled.  As far as I know, there's been very little discussion about 
> it.  It's not a trivial thing to implement, and it treads on delicate 
> territory (how "." is treated).  So I'd need to be convinced there was a 
> strong constituency who really wanted it before adding it.

Well, implementing certain protocols (e.g. based on JSON, like Bayeux
[1]) in a type-safe way requires lots of records and many of these
records have similar selectors, e.g. channel. Currently one can only
have a nice interface to such a protocol by using type classes and
creating lots of instance declarations, which is a lot of boilerplate
to be written. This would be much easier with TDNR, than with
module-scoped record selectors. Also the hack to use different modules
is further complicated by the fact that at least GHC insists on having
each module in a separate file.

As pointed out by others one may choose a different string instead of
"." like "->"  if this makes the implementation of TDNR feasible. But
some mechanism to have some sort of scoped record selectors or TDNR is
needed in my opinion.

Many thanks,
Levi


[1] http://svn.cometd.org/trunk/bayeux/bayeux.html

>
> I've added an informal straw poll to the bottom of [1] to allow you to 
> express an opinion.
>
> Also I'm not very happy with the "stacking operations" part, and I'd like a 
> better idea.
>
> Simon
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Little errors in number calculations

[Abby Henríquez Tejera]

It's curious that Hugs "lies"...

Thanks for the answers :) .

2009/11/15 Lennart Augustsson :
> Hugs is wrong, as you can easily see by evaluating
>   let x = 123.35503 * 10.0 in x == read (show x)
> With ghc it comes out as True and with Hugs as False.
>
>  -- Lennart
>
> On Sat, Nov 14, 2009 at 9:00 PM, Abby Henríquez Tejera
>  wrote:
>> Hi.
>>
>> I've seen that in GHC sometimes there are little errors in some basic
>> number calculations:
>>
>> *Prelude> 123.35503 * 10.0
>> 1233.55029
>>
>> *Prelude> properFraction 123.35503
>> (123,0.35502993)
>>
>> whereas in Hugs no such errors seem to occur (that I have found, at
>> least):
>>
>> *Hugs> 123.35503 * 10.0
>> 1233.5503
>>
>> (but:)
>>
>> *Hugs> properFraction 123.35503
>> (123,0.3550299)
>>
>> I understand that error may (and will) happen in floating point, but
>> it surprises me that they do so easily, and, above all, the difference
>> between GHC and Hugs. Does someone know why does this difference
>> occur?
>>
>> (Thanks in advance, by the way :) ).
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: ANNOUNCE: deepseq-1.0.0.0

[Duncan Coutts]

On Tue, 2009-11-17 at 11:00 +, Simon Marlow wrote:
> I've just uploaded deepseq-1.0.0.0 to Hackage
> 
>http://hackage.haskell.org/package/deepseq
> 
> This provides a DeepSeq class with a deepseq method, equivalent to the 
> existing NFData/rnf in the parallel package.  I'll be using this in a 
> newly revamped parallel package, which I hope to upload shortly.

Yay, you get to be the first person to try out the new platform package
proposal process!

http://trac.haskell.org/haskell-platform/wiki/AddingPackages

(because it's a new dependency of a platform package)


Duncan

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANNOUNCE: gnome-keyring 0.1 (bindings to libgnome-keyring)

[Magnus Therning]

Excellent.  It seems that my sit-back-and-wait approach is slowly
resulting in all the libraries required to rewrite my old (Python)
password storage tool are being put into place :-)

/M

On Tue, Nov 17, 2009 at 2:38 AM, John Millikin  wrote:
> The GNOME Keyring is a service for securely storing per-user secret
> information, such as passwords and encryption keys, on the GNOME
> desktop. This library is a binding to the libgnome-keyring C library.
>
> The API is still a bit too slave-ish to the original for my taste,
> some modules will be changing/merging in the next version. The innards
> are an absolute horror -- don't look too close if you're one of those
> people who faint at rampant unsafe casting.
>
> That said, it works surprisingly well for a first-release FFI binding
> -- mostly due to the excellent design of libgnome-keyring and c2hs.
>
> So if any Linux/BSD/OpenSolaris/etc users have needed secure password
> storage in Haskell, please try it out and let me know if you encounter
> any problems.
> Download: http://hackage.haskell.org/package/gnome-keyring/
> API docs (copy of original library docs):
> https://dl.dropbox.com/u/1947532/gnome-keyring_0.1/index.html
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
Magnus Therning(OpenPGP: 0xAB4DFBA4)
magnus＠therning．org  Jabber: magnus＠therning．org
http://therning.org/magnus identi.ca|twitter: magthe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Status of TypeDirectedNameResolution proposal?

[Neil Brown]

Simon Peyton-Jones wrote:
| What's the status of the TDNR proposal [1]? 

It's stalled.  As far as I know, there's been very little discussion about it.  It's not a trivial thing to implement, and it treads on delicate territory (how "." is treated).  
Having skimmed the page, it seems like the re-use of "." is one of the 
major difficulties of the proposal.  Would it be possible to use "->"?  
It has been used for accessing members in C and C++, so it is not too 
unusual a choice.  It is already special in Haskell so it wouldn't break 
anyone's code -- but do its other uses (case statements and lambdas) 
mean that it would cause problems in the grammar if re-used for TDNR?


Neil.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

FW: [Haskell-cafe] Status of TypeDirectedNameResolution proposal?

[Simon Peyton-Jones]

[Resending, this time with link; sorry]

| What's the status of the TDNR proposal [1]? Personally I think it is a
| very good idea and I'd like to see it in Haskell'/GHC rather sooner
| than later. Working around the limitations of the current record
| system is one of my biggest pain points in Haskell and TDNR would be a
| major improvement. Thus I wonder if someone is actively working on
| this proposal?

It's stalled.  As far as I know, there's been very little discussion about it.  
It's not a trivial thing to implement, and it treads on delicate territory (how 
"." is treated).  So I'd need to be convinced there was a strong constituency 
who really wanted it before adding it.

I've added an informal straw poll to the bottom of [1] to allow you to express 
an opinion.

Also I'm not very happy with the "stacking operations" part, and I'd like a 
better idea.

Simon

[1]   
http://hackage.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResolution
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANNOUNCE: deepseq-1.0.0.0

[Nicolas Pouillard]

Excerpts from Simon Marlow's message of Tue Nov 17 12:00:21 +0100 2009:
> I've just uploaded deepseq-1.0.0.0 to Hackage

Great!

I'm wondering what is the need/purpose for DeepSeqIntegral and DeepSeqOrd?

-- 
Nicolas Pouillard
http://nicolaspouillard.fr
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Status of TypeDirectedNameResolution proposal?

[Matthijs Kooijman]

> I've added an informal straw poll to the bottom of [1] to allow you to 
> express an opinion.

[1]: ?


signature.asc
Description: Digital signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Status of TypeDirectedNameResolution proposal?

[Simon Peyton-Jones]

| What's the status of the TDNR proposal [1]? Personally I think it is a
| very good idea and I'd like to see it in Haskell'/GHC rather sooner
| than later. Working around the limitations of the current record
| system is one of my biggest pain points in Haskell and TDNR would be a
| major improvement. Thus I wonder if someone is actively working on
| this proposal?

It's stalled.  As far as I know, there's been very little discussion about it.  
It's not a trivial thing to implement, and it treads on delicate territory (how 
"." is treated).  So I'd need to be convinced there was a strong constituency 
who really wanted it before adding it.

I've added an informal straw poll to the bottom of [1] to allow you to express 
an opinion.

Also I'm not very happy with the "stacking operations" part, and I'd like a 
better idea.

Simon

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANNOUNCE: control-monad-failure and safe-failure

[Nicolas Pouillard]

Excerpts from Kalman Noel's message of Tue Nov 17 12:55:54 +0100 2009:
> Nicolas Pouillard schrieb:
>  class MonadFailure e m where failure :: e -> m a 
> >> Why is it called "MonadFailure" (specifically, what's the "Monad" bit 
> >> doing 
> >> there)?
> > 
> > Because of 'Monad m' being a superclass of 'MonadFailure e m'.
> > 
> > Here is the class:
> > class Monad m => MonadFailure e m where
> >   failure :: e -> m a
> 
> Oh ok; I misguidedly took the line at the top to be the class definition. I'd 
> still be interested if such a simple Failure class could be meaningful or 
> useful for mere, say, Applicatives.

I think it is meaningful.

-- 
Nicolas Pouillard
http://nicolaspouillard.fr
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANNOUNCE: control-monad-failure and safe-failure

[Kalman Noel]

Nicolas Pouillard schrieb:
class MonadFailure e m where failure :: e -> m a 
Why is it called "MonadFailure" (specifically, what's the "Monad" bit doing 
there)?


Because of 'Monad m' being a superclass of 'MonadFailure e m'.

Here is the class:
class Monad m => MonadFailure e m where
  failure :: e -> m a


Oh ok; I misguidedly took the line at the top to be the class definition. I'd 
still be interested if such a simple Failure class could be meaningful or 
useful for mere, say, Applicatives.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANNOUNCE: deepseq-1.0.0.0

[José Pedro Magalhães]

Hello,

The release of the regular library for generic programming on Hackage
[1] also contains a form of deep seq [2]. This means that you don't
even have to write the definition of 'deepseq', you can just use
'gdseq' (assuming you have used Template Haskell to derive the generic
representations for your types).


Cheers,
Pedro

[1] http://hackage.haskell.org/package/regular
[2] 
http://hackage.haskell.org/packages/archive/regular/0.2.1/doc/html/Generics-Regular-Functions-Seq.html#t%3ASeq

On Tue, Nov 17, 2009 at 12:04, Roel van Dijk  wrote:
> On Tue, Nov 17, 2009 at 12:00 PM, Simon Marlow  wrote:
>> I've just uploaded deepseq-1.0.0.0 to Hackage
>
> This is great! I often use rnf to fully evaluate some expression where
> I didn't need parallelism at all. Time to update some packages.
>
> Thank you,
> Roel
> ___
> Libraries mailing list
> librar...@haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANNOUNCE: deepseq-1.0.0.0

[Roel van Dijk]

On Tue, Nov 17, 2009 at 12:00 PM, Simon Marlow  wrote:
> I've just uploaded deepseq-1.0.0.0 to Hackage

This is great! I often use rnf to fully evaluate some expression where
I didn't need parallelism at all. Time to update some packages.

Thank you,
Roel
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] ANNOUNCE: deepseq-1.0.0.0

[Simon Marlow]

I've just uploaded deepseq-1.0.0.0 to Hackage

  http://hackage.haskell.org/package/deepseq

This provides a DeepSeq class with a deepseq method, equivalent to the 
existing NFData/rnf in the parallel package.  I'll be using this in a 
newly revamped parallel package, which I hope to upload shortly.


Cheers,
Simon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANNOUNCE: control-monad-failure and safe-failure

[Nicolas Pouillard]

Excerpts from Kalman Noel's message of Tue Nov 17 07:47:14 +0100 2009:
> Michael Snoyman schrieb:
> > control-monad-failure provides a basic notion of failure which does not
> > commit to any concrete representation.
> > It is just a version of the MonadError class without the annoying bits.
> > 
> >> class MonadFailure e m where failure :: e -> m a 
> 
> Why is it called "MonadFailure" (specifically, what's the "Monad" bit doing 
> there)?

Because of 'Monad m' being a superclass of 'MonadFailure e m'.

Here is the class:
class Monad m => MonadFailure e m where
  failure :: e -> m a

-- 
Nicolas Pouillard
http://nicolaspouillard.fr
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe