New-to-Haskell, i.e. elementary, Haskell questions; extended discussions

headers Tim Wawrzynczak | 1 Jul 2010 01:26

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

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

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

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

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

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

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.

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

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.

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

Mon	Tue	Wed	Thu	Fri	Sat	Sun

			1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29	30	31

368	May 2013
645	April 2013
530	March 2013
608	February 2013
511	January 2013
612	December 2012
615	November 2012
534	October 2012
502	September 2012
534	August 2012
536	July 2012
503	June 2012
491	May 2012
433	April 2012
684	March 2012
723	February 2012
822	January 2012
933	December 2011
684	November 2011
726	October 2011
619	September 2011
637	August 2011
735	July 2011
1007	June 2011
995	May 2011
824	April 2011
846	March 2011
876	February 2011
840	January 2011
1035	December 2010
1030	November 2010
1507	October 2010
1279	September 2010
1692	August 2010
1619	July 2010
1195	June 2010
1302	May 2010
1498	April 2010
1605	March 2010
1180	February 2010
1133	January 2010
1649	December 2009
1481	November 2009
1287	October 2009
1156	September 2009
1131	August 2009
1085	July 2009
1521	June 2009
1444	May 2009
1698	April 2009
2224	March 2009
2166	February 2009
1988	January 2009
1420	December 2008
1206	November 2008
1640	October 2008
1556	September 2008
1193	August 2008
839	July 2008
1100	June 2008
1438	May 2008
1116	April 2008
1087	March 2008
1168	February 2008
1622	January 2008
1698	December 2007
1754	November 2007
1387	October 2007
1253	September 2007
1456	August 2007
2006	July 2007
1387	June 2007
1351	May 2007
991	April 2007
1040	March 2007
1011	February 2007
954	January 2007
1087	December 2006
760	November 2006
602	October 2006
856	September 2006
698	August 2006
641	July 2006
476	June 2006
389	May 2006
380	April 2006
439	March 2006
576	February 2006
558	January 2006
1085	December 2005
545	November 2005
421	October 2005
385	September 2005
201	August 2005
355	July 2005
343	June 2005
466	May 2005
242	April 2005
267	March 2005
287	February 2005
767	January 2005
452	December 2004
415	November 2004
389	October 2004
228	September 2004
186	August 2004
212	July 2004
128	June 2004
89	May 2004
99	April 2004
150	March 2004
63	February 2004
138	January 2004
91	December 2003
154	November 2003
231	October 2003
132	September 2003
238	August 2003
185	July 2003
153	June 2003
208	May 2003
88	April 2003
101	March 2003
127	February 2003
104	January 2003
141	December 2002
109	November 2002
109	October 2002
78	September 2002
108	August 2002
69	July 2002
62	June 2002
73	May 2002
26	April 2002

Re: State of the Hackage: Q1, Q2 2010

Newbie question about using WinGHCi

Re: Newbie question about using WinGHCi

ANNOUNCE: hs-cryptohash 0.4

chart "broken" under 6.12 according to criterion

Re: chart "broken" under 6.12 according to criterion

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

functional dependencies question

Re: functional dependencies question

Re: functional dependencies question