- Haskell-Cafe - Haskell.org

Re: Haskell-Cafe digest, Vol 1 #616 - 12 msgs
by Chevalier Dr. Dr. Ruediger Marcus Flaig 14 Feb '03

14 Feb '03

Am Donnerstag, 13. Februar 2003 18:01 schrieb haskell-cafe-request(a)haskell.org: > Message: 5 > Date: Thu, 13 Feb 2003 10:06:53 +0100 > From: Jerzy Karczmarczuk <karczma(a)info.unicaen.fr> > Organization: =?ISO-8859-1?Q?Universit=E9_de_Caen=2C_France?= > Cc: haskell(a)haskell.org, haskell-cafe(a)haskell.org > Subject: Re: ANNOUNCE: Learning Haskell portal, version 0.1 > > Arjan van IJzendoorn wrote: > > Often we see messages from people who want to learn Haskell (something we > > applaud), but don't know where to begin. > > ... > > > Enough talk: http://www.cs.uu.nl/~afie/haskell/LearningHaskell.html > > Thanks, Arjan, nice work. > I would add some significant papers, such as John Hughes' > "Why functional programming matters", etc. > > and perhaps - for some, a little bit advanced readers - some > other papers, introducing type classes, perhaps monads (Wadler) > etc. Everything can be found through the Home of Haskell, but > gathering essential references on your page would shorten the > search path. > > I believe - from some discussions here and on comp.lang.functional > (some of them quite annoying...) that it would perhaps be a good > idea to put down a relatively comprehensive, easy comparison > between Haskell and other languages, notably functional: Clean, > also: Scheme, absolutely: ML variants, and Erlang. > Such questions are, and will continue to be recurring. > > > Jerzy Karczmarczuk > Excellent idea -- if you need a volunteer, contact me (I am familiar with Erlang, the Lisp/Scheme group and CAML). But I would also suggest to include the declarative languages such as Prolog and Mercury, if we can find anyone who knows -- the Mercury homepage (sorry, I don't have the URL right now, it was something long and winding) contains an explicit comparison between Mercury and Haskell. (A rather fair and objective one, it must be pointed out!) And maybe one should also add a few lines about hybrids such as Python? Yours, Ruediger M. Flaig -- "I was always told that death and taxes are no subjects for discussion." "Well... the one does not concern me." "And the other?" "I admit that I do not pay taxes either." -- Diane Duane: "The Wounded Sky"

2 1

RE: MArray and newSTUArray
by Simon Peyton-Jones 14 Feb '03

14 Feb '03

Excellent idea. This does indeed seem to be the cleanest way to explain the necessary type constraints. I think we (Simon M) may add it to the library. Simon | -----Original Message----- | From: Dean Herington [mailto:heringto@cs.unc.edu] | Sent: 13 February 2003 15:21 | To: haskell-cafe(a)haskell.org | Subject: MArray and newSTUArray | | The MArray class in Data.Array.MArray is a very nice abstraction. | However, when creating an array whose type partakes of MArray, say | STUArray, I find myself defining and using a type-specific creation | function, such as: | | newSTUArray :: (MArray (STUArray s) e (ST s), Ix i) | => (i, i) -> e -> ST s (STUArray s i e) | newSTUArray = newArray | | so that I don't have to give a complicated type declaration for each use | of `newArray` that creates an STUArray. | | 1. Is there a better (more concise/convenient) way to provide the | necessary type information? | 2. If not, should functions such as `newSTUArray` be provided in the | libraries? | | -- Dean | | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

RE: Pattern matching, implict par. question
by Simon Peyton-Jones 14 Feb '03

14 Feb '03

Well the definition clearly falls under the monomorphism restriction as laid down by the Report, because you haven't given a signature for us,n,j. I suggest ctPar :: (?ctPar::CTPar) => CTPar ctPar = ?ctPar (us,n,j) = ctPar That should work Simon | -----Original Message----- | From: Jorge Adriano [mailto:jadrian@mat.uc.pt] | Sent: 13 February 2003 14:36 | To: Haskell Cafe; glasgow-haskell-users(a)haskell.org | Subject: Pattern matching, implict par. question | | Hello, When trying | | type CTPar = ([Double],Int,Int) | ctPar ::(?ctPar::CTPar)=>CTPar | ctPar@(us,n,j) = ?ctPar | | I got this error message in ghci is: | " Illegal overloaded type signature(s) | in a binding group for ctPar, us, n, j | that falls under the monomorphism restriction | When generalising the type(s) for ctPar, us, n, j | Failed, modules loaded: CrossTypeOps." | | Should the monomorphis restriction really apply here? | The values of us,j,n do depend on the context, but not their types (right?). | | J.A. | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

How to read an initialization file.
by Thaddeus L. Olczyk 14 Feb '03

14 Feb '03

I'm stuck on a problem in a program and I suspect one that I will keep encountering. I need to be able to read from an initialization file a set of values, as a simple example let us take three variables: base_dir, user_name, log_file. I need to be able to access these values effieiently and from virtually anywhere in the program. It would be nice to "at some point" open the file and read all these variables, all at once. Can anyone help?

1 0

ANNOUNCE: 0th International Obfuscated Haskell Code Contest
by shae＠webwitches.com 14 Feb '03

14 Feb '03

In the spirit of http://ioccc.org/ .... Bring us your poor, weary, downtrodden, and unreadable source code. Come to the 0th INTERNATIONAL OBFUSCATED HASKELL CODE CONTEST! This contest is meant to be fun, short, and not terribly serious. Also, then we'll know if a 1st IOHCC is a good idea. * submission deadline: March 1st, 2003 * send your code (and/or complaints/comments) to: mailto:iohc-jury@mgoetze.net * winners and possible rules updates at http://iohc.mgoetze.net/ Submission must have source and some sort of description file so that the jurors won't be totally mystified. Rules: * LICENSE: your code must an original work, all submitted programs are thereby put in the public domain. All explicitly copyrighted programs will be rejected. (see the IOCCC rules) * max source size: 5k * entry must include shell script or makefile to perform the build * build must not require human intervention * doing something interesting and/or useful is a plus * we particularly like games * limited abuse of the rules is acceptable if the specific abuses are documented, and the judges think it's cool Portability: * latest public release versions of hugs, ghc, nhc, hbc, helium acceptable (any we missed?) * may use common Haskell tools such as hmake, happy etc. * program need not be portable across Haskell implementations * must be relatively portable across platforms (i.e. no Linux-specificisms) * use of ANSI/VTxxx codes which are not limited to a specific brand of terminal and work in a standard xterm are portable * FFI is discouraged, we want real Haskell source. Five person jury: * Richard Braakman (dark) * Shae Erisson (shapr) * Ian Lynagh (Igloo) * Andrew Bromage (Pseudonym) * Manuel Chakravarty (Chilli) We expect judging to take two to three weeks, but this is the 0th IOHCC, could be shorter or longer. Awards will depend on the specific entries, but may include: * best one-liner - less than 80 chars not counting imports * best .signature sized - 4x80 or 4x76 or whatever * best game * best H98-only program * best exploit of a compiler bug * most useful program * most creative layout * best abuse of implementation-specific extensions * best abuse of the type system * best abuse of category theory * worst abuse of the rules Spirit, point, reason: * to seek out new lifeforms and new civilizations * to boldly go where no Haskell programmer has ever wanted to be! Semi-seriously, obfuscated code shows neat and unusual ways of structuring a program, cool tricks, dark nooks and crannies you've never thought of, and is generally a good way to shake off all that software discipline and stomp around in the muddy world of spaghetti code for a quick vacation. -- Shae Matijs Erisson - 2 days older than RFC0226 #haskell on irc.freenode.net - We Put the Funk in Funktion

1 0

Bracketless branch if, sugar to taste...
by Alex Ferguson 13 Feb '03

13 Feb '03

Yes indeed, one can further "sugar" Keith's suggestion to eliminate the need for brackets around the branches. Though as this means using an infix operator then and else, with corresponding mangling of the lexical appearance of same, this becomes increasingly a matter of taste (or perhaps, in need of sound dental advice). Example: ifM (return (1==1)) `then_` print (2+3) `else_` print (3+4) Of course, the type errors are going to start looking more and more mysterious if you get 'em in the wrong place... Cheers, Alex. ________ infix 4 `then_` infix 5 `else_` data Branches a = Branches a a then_ :: (a->a->a) -> Branches a -> a then_ sel (Branches t e) = sel t e else_ :: a->a->Branches a else_ t e = Branches t e iff b t e = if b then t else e ifM b t e = do test <- b if test then t else e

1 0

MArray and newSTUArray
by Dean Herington 13 Feb '03

13 Feb '03

The MArray class in Data.Array.MArray is a very nice abstraction. However, when creating an array whose type partakes of MArray, say STUArray, I find myself defining and using a type-specific creation function, such as: newSTUArray :: (MArray (STUArray s) e (ST s), Ix i) => (i, i) -> e -> ST s (STUArray s i e) newSTUArray = newArray so that I don't have to give a complicated type declaration for each use of `newArray` that creates an STUArray. 1. Is there a better (more concise/convenient) way to provide the necessary type information? 2. If not, should functions such as `newSTUArray` be provided in the libraries? -- Dean

1 0

RE: a monadic if or case?
by Kevin Millikin 13 Feb '03

13 Feb '03

On Thursday, February 13, 2003 8:33 AM, Arjan van IJzendoorn [SMTP:afie@cs.uu.nl] wrote: > Not with the syntactic sugar of 'if'. > But you can write [warning: untested code ahead] > > ifM :: IO Bool -> IO a -> IO a -> IO a > ifM test yes no = do > b <- test > if b then yes else no I had ifM :: Monad m => m Bool -> m a -> m a -> m a ifM tst thn els = do b <- tst if b then thn else els And I just tested it. ---- Kevin S. Millikin Architecture Technology Corporation Research Scientist Specialists in Computer Architecture kmillikin(a)atcorp.com http://www.atcorp.com

1 0

Re: Learning Haskell moved
by Matthew Donadio 13 Feb '03

13 Feb '03

>> I would add some significant papers, such as John Hughes' >> "Why functional programming matters", etc. > >I've added that paper to the introduction. Other suggestions are welcome. "Conception, Evolution, and Application of Functional Programming Languages", Paul Hudak, ACM Computing Surveys, Volume 21, Number 3, pp.359-411, 1989 This would probably be good, too. --Matthew Donadio (m.p.donadio(a)ieee.org)

1 0

Pattern matching, implict par. question
by Jorge Adriano 13 Feb '03

13 Feb '03

Hello, When trying type CTPar = ([Double],Int,Int) ctPar ::(?ctPar::CTPar)=>CTPar ctPar@(us,n,j) = ?ctPar I got this error message in ghci is: " Illegal overloaded type signature(s) in a binding group for ctPar, us, n, j that falls under the monomorphism restriction When generalising the type(s) for ctPar, us, n, j Failed, modules loaded: CrossTypeOps." Should the monomorphis restriction really apply here? The values of us,j,n do depend on the context, but not their types (right?). J.A.

1 0