Tim Wawrzynczak | 1 Jul 01:26 2010
Picon

Re: State of the Hackage: Q1, Q2 2010

If anyone wants to see the popularity of their particular package(s), dons has kindly left a .txt file with the information
at the following URL: http://code.haskell.org/~dons/hackage/Jun-2010/popular.txt .

Of course, this being Haskell, I had to whip up a little script to get the information for you.

It may not be the most elegant, but it only took a few minutes and it does the job.  You'll find it attached :)

Cheers,
 - Tim

On Wed, Jun 30, 2010 at 5:08 PM, Don Stewart <dons <at> galois.com> wrote:

Downloads and popular packages on Hackage for Q1 and Q2 this year.

   http://donsbot.wordpress.com/2010/06/30/popular-haskell-packages-q2-2010-report/

-- Don
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Attachment (popular.hs): application/octet-stream, 2131 bytes
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Christopher Tauss | 1 Jul 08:04 2010
Picon

Newbie question about using WinGHCi

Hello -
 
I just a day or so ago downloaded Hakell and am playing around with it, and I came upon this problem with WinGHCi:
 
I am able to enter a multi-line "do" statement that works if I use brackets and semi-colon like so:
 
Prelude> :{
Prelude| let main2 = do {
Prelude| putStrLn "Please enter your name: ";
Prelude| name <- getLine;
Prelude| putStrLn ("Hello, " ++ name ++ ", how are you?") }
Prelude| :}
Prelude> main2
Please enter your name:
CT
Hello, CT, how are you?
Prelude>
 
Note there is no indentation.  This makes sense to me because the :{  :} just take all the lines in between and make it one line.
 
But it seems to me to be IMPOSSIBLE to input this into WinGHCi using indentation like most of the code samples seem to do.
 
Should I just be satisfied that it works using brackets/ semi-colons?  Or is there something obvious that I am missing that allows for indentation?
 
Thanks in advance. It's issues lik this that keep me up into the depths of night.
 
Best Regards,
 
Chris
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Ivan Miljenovic | 1 Jul 08:12 2010
Picon

Re: Newbie question about using WinGHCi

On 1 July 2010 16:04, Christopher Tauss <ctauss1 <at> gmail.com> wrote:
> Hello -
>
> I just a day or so ago downloaded Hakell and am playing around with it, and
> I came upon this problem with WinGHCi:
>
> I am able to enter a multi-line "do" statement that works if I use brackets
> and semi-colon like so:
>
> Prelude> :{
> Prelude| let main2 = do {
> Prelude| putStrLn "Please enter your name: ";
> Prelude| name <- getLine;
> Prelude| putStrLn ("Hello, " ++ name ++ ", how are you?") }
> Prelude| :}
> Prelude> main2
> Please enter your name:
> CT
> Hello, CT, how are you?
> Prelude>
>
> Note there is no indentation.  This makes sense to me because the :{  :}
> just take all the lines in between and make it one line.
>
> But it seems to me to be IMPOSSIBLE to input this into WinGHCi using
> indentation like most of the code samples seem to do.
>
> Should I just be satisfied that it works using brackets/ semi-colons?  Or is
> there something obvious that I am missing that allows for indentation?

Typically, ghci (including WinGHCI) and Hugs are used to evaluate and
experiment with code, rather than writing it.  Write your actual code
in a file and load it with :load (or :l for short) into ghci.

In this sense, they aren't "real" REPLs in that you can't define new
data types, classes, etc. in them (you can write functions with a let
statement, but it gets cumbersome for long functions).

It might be better off thinking of the prompt as being individual
lines in a big do-block for a specialised version of the IO monad (in
the sense that normally just entering "5+4" wouldn't typecheck let
alone print the result, etc.).

> Thanks in advance. It's issues lik this that keep me up into the depths of
> night.

Hopefully you can now get to sleep ;-)

--

-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic <at> gmail.com
IvanMiljenovic.wordpress.com
Vincent Hanquez | 1 Jul 09:25 2010

ANNOUNCE: hs-cryptohash 0.4

Hi Haskell-cafe,

I'ld like to announce the existence of hs-cryptohash [1] which provides
most common digests (sha1, sha2 family, md[245], ripemd160) in a incremental
and one-pass api.

It's also much faster than pure haskell implementation i've played with, since
the underlaying algorithms are all fairly optimized in C. The API remains pure
with the use of unsafePerformIO, which after reading everything i could about
it and some testing, seems to be safe in this context.

The main reason for this library is the lack of incremental api exposed by
current digest libraries, and filling the void about some missing digest
algorithms; Also the speed comes as a nice bonus.

I'm looking forward to hear any comments,

[1] http://github.com/vincenthz/hs-cryptohash

--

-- 
Vincent Hanquez
Tom Doris | 1 Jul 11:16 2010
Picon

chart "broken" under 6.12 according to criterion

According to the criterion.cabal file shipped with the latest (0.5.0.1) version of criterion, the Chart package is broken under GHC 6.12:
 
flag Chart
 
 
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Tom Doris | 1 Jul 11:19 2010
Picon

Re: chart "broken" under 6.12 according to criterion

According to the criterion.cabal file shipped with the latest (0.5.0.1) version of criterion, the Chart package is broken under GHC 6.12:
 
flag Chart
   description: enable use of the Chart package
   -- Broken under GHC 6.12 so far
 
Does anyone know the status of this problem? It's been a little frustrating getting Criterion up and running - it didn't work at all under 6.10 due to a compiler bug ("The impossible happened" error on uvector install) and now it works under 6.12 but without the nice charts that are so useful. Appreciate any insight or workarounds for this, thanks
 
(Apologies, previous email sent prematurely!)
Tom

 
On 1 July 2010 10:16, Tom Doris <tomdoris <at> gmail.com> wrote:
According to the criterion.cabal file shipped with the latest (0.5.0.1) version of criterion, the Chart package is broken under GHC 6.12:
 
flag Chart
 
 

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Neil Brown | 1 Jul 11:32 2010
Picon

Re: Re: chart "broken" under 6.12 according to criterion

On 01/07/10 10:19, Tom Doris wrote:
> According to the criterion.cabal file shipped with the latest 
> (0.5.0.1) version of criterion, the Chart package is broken under GHC 
> 6.12:
> flag Chart
>    description: enable use of the Chart package
>    -- Broken under GHC 6.12 so far
> Does anyone know the status of this problem? It's been a little 
> frustrating getting Criterion up and running - it didn't work at all 
> under 6.10 due to a compiler bug ("The impossible happened" error on 
> uvector install) and now it works under 6.12 but without the nice 
> charts that are so useful. Appreciate any insight or workarounds for 
> this, thanks
>
Hi,

"cabal install criterion -fChart --reinstall" builds fine for me on GHC 
6.12.1, and I can draw the KDE graphs succesfully for the criterion 
examples.  I think that comment in the cabal file is probably related to 
Chart's dependency on gtk2hs.  gtk2hs used to be broken on GHC 6.12, but 
these days it works -- and is on Hackage, too.  Give that cabal command 
a go and see if it works for you.

Thanks,

Neil.
Patrick Browne | 1 Jul 13:37 2010
Picon

functional dependencies question

Hi,
My understanding of functional dependencies is that they can be used to
ensure that one type depends on another type.
For example, the type of location depends could on the type of the
object at that location.
Consider two models
1) The location of an aircraft landing should have location of the type
AirportCode,
2) The location of a car's destination should have a type
CartesianCoordinate.

AirportCodes should not be used as locations in 2) and
CartesianCoordinates should not be used as locations in 1).
Haskell class, instances, and fundeps were used to represent the above
requirements. I generalized the requirement a bit, testing on a variety
of types (below).

Obviously, some cases are ambigous and/or conflicting and the Haskell
compiler correctly flags this.

Why do some cases such as 1) fail to run even if they are the only
instantiation.

Regards,
Pat

{-
C:\GHC\ghc-6.8.3\bin\ghci.exe  -XMultiParamTypeClasses
-XFunctionalDependencies -fglasgow-exts -fallow-undecidable-instances
-}

class LocatedAt object location | object -> location where
 spatialLocation :: object -> location

-- 1) Compiles but does not run
instance LocatedAt  Int  String  where
 spatialLocation(1)="home"

-- 2) Compiles and runs OK
instance LocatedAt String Int where
 spatialLocation("home")=1

-- 3) Compiles and runs  OK, but obviously not in conjunction with 2
instance LocatedAt  String  String  where
  spatialLocation("home")="home"

-- 4) Compiles and runs OK
instance LocatedAt  Bool  String  where
  spatialLocation(True)="home"

-- 5) Compiles and runs OK, but obviously not in conjunction with 2
instance LocatedAt    String  Bool where
    spatialLocation("home") = True

-- 6) Not OK
instance LocatedAt  Float  String  where
   spatialLocation(2.3)="home"

-- 7) Compiles but does not run
 instance LocatedAt Int Char  where
  spatialLocation(1)='1'

-- 8)  Compiles and runs OK
instance LocatedAt Char Int   where
 spatialLocation('1')=1

This message has been scanned for content and viruses by the DIT Information Services E-Mail Scanning
Service, and is believed to be clean. http://www.dit.ie
Neil Brown | 1 Jul 13:45 2010
Picon

Re: functional dependencies question

On 01/07/10 12:37, Patrick Browne wrote:
> Why do some cases such as 1) fail to run even if they are the only
> instantiation.
>
> -- 1) Compiles but does not run
> instance LocatedAt  Int  String  where
>   spatialLocation(1)="home"
>    

That instance is fine.  I presume the problem is that you are trying to 
run this function using "spatialLocation 1" as the function call.  The 
problem with that is that the "1" part has type Num a => a, i.e. it can 
be any Num type.  Even though you only have one instance, that's not 
used to constrain the type for "1".  The call "spatialLocation (1::Int)" 
works correctly.  Looking at your other examples, all the ones that 
don't work have a numeric type for the parameter, so I suspect it is the 
same issue throughout.

Thanks,

Neil.
Patrick Browne | 1 Jul 14:11 2010
Picon

Re: functional dependencies question

Neil,
Does the following sum up the situation?
The class Num has subclasses containing various numeric types and the
literal 1 is a value for one or more of those types.
Hence the Haskell compiler says the instance 1) is OK.
But at run time, without the quantified (1:Int), the 1 could of more
than one type, which causes a problem.

Thanks for the quick and informative response,
Pat

Neil Brown wrote:
> On 01/07/10 12:37, Patrick Browne wrote:
>> Why do some cases such as 1) fail to run even if they are the only
>> instantiation.
>>
>> -- 1) Compiles but does not run
>> instance LocatedAt  Int  String  where
>>   spatialLocation(1)="home"
>>    
> 
> That instance is fine.  I presume the problem is that you are trying to
> run this function using "spatialLocation 1" as the function call.  The
> problem with that is that the "1" part has type Num a => a, i.e. it can
> be any Num type.  Even though you only have one instance, that's not
> used to constrain the type for "1".  The call "spatialLocation (1::Int)"
> works correctly.  Looking at your other examples, all the ones that
> don't work have a numeric type for the parameter, so I suspect it is the
> same issue throughout.
> 
> Thanks,
> 
> Neil.

This message has been scanned for content and viruses by the DIT Information Services E-Mail Scanning
Service, and is believed to be clean. http://www.dit.ie

Gmane