August 2005 - Haskell

RE: [Haskell] pros and cons of static typing and side effects ?
by Simon Peyton-Jones 12 Aug '05

12 Aug '05

Perhaps this discussion could move to Haskell-café? We try to keep the bandwidth on Haskell(a)haskell.org fairly low. Simon | -----Original Message----- | From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of John Meacham | Sent: 12 August 2005 00:47 | To: haskell(a)haskell.org | Subject: Re: [Haskell] pros and cons of static typing and side effects ? | | On Thu, Aug 11, 2005 at 03:40:25PM -0400, Hamilton Richards wrote: | > At 10:40 PM +0200 2005/8/10, mt wrote: | > >... Languages with | > >static typing would be more suitable if programs were something you thought | > >of in advance, and then merely translated into code. But that's not how | > >programs get written. | > | > Well, that is actually how lots of programs do get written. | > | > For software that is experimental and exploratory, whose code | > undergoes continual change and whose only users are the code's | > authors, static typing is arguably a dispensable nuisance. A type | > error that pops up during execution is probably no more inconvenient | > than one that's caught by static type checking. That's why Lisp is | > popular for AI work. | | I find pretty much completly the opposite is true. for random hacking | and evolving code, static typing is essential. There is only so much | room in one's brain to keep track of how everything works. if you were | meerly translating from a previous design, this isn't so much an issue. | but when writing code that is evolving and changing and perhaps you | don't quite know how it will turn out, your ability to recall and | understand how everything works together is a major limiting factor on | the scope of what you can acomplish. Static typing offloads a _ton_ of | responsibility away from the programmer. you no longer need to worry or | even think about what types are held in variables because you know any | mistakes will be caught by the compiler. and with haskell's advanced | type system, you can encode much more advanced constraints and | invarients in the type system offloading even more work from your brain. | Haskell's strong type system made me writing jhc alone possible, not | because of the better reliability (that is great though!), but because | it let me 'forget' about so many inconsequential details that they type | system enforced so I only needed to use brain-space for high level | constructs and my overall evolving, changing, plan. I tend to only use | perl or other dynamically typed languages when writing something that I | know exactly what it will do and how to do it beforehand, because I find | it to be quite an inflexible language when it comes to changing code | after the fact, not because of any syntatic difficulty, but because you | basically have to constantly redervive everything the program does and | all the unspoken invarients to understand it and how to change it. which | is something that gets super-linearly harder as code size grows. | | John | | -- | John Meacham - ⑆repetae.net⑆john⑈ | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

1 0

concurrency analysis
by John Meacham 12 Aug '05

12 Aug '05

I was curious if there has been any research on "concurrency analysis" which would determine which thunks might be accessed concurrently by different threads. I imagine that the vast majority are only accessed in a single threaded manner so can use a more efficient representation when doing SMP parallelism with haskell. It seems that some sort of abstract interpretation could provide a conservative answer to this similar to the way update analysis is done. John -- John Meacham - ⑆repetae.net⑆john⑈

1 0

pros and cons of static typing and side effects ?
by mt 12 Aug '05

12 Aug '05

[thnk 4 the previous answers !] Good [morning, afternoon, night], I try to better understand some things... maybe you can help me. Id' like to know what are the pros and cons of (not) having static typing. Same question for (direct support of) side effects. To help you to find answers, here I quote this page : http://paulgraham.com/lispfaq1.html [Most hackers I know have been disappointed by the ML family. Languages with static typing would be more suitable if programs were something you thought of in advance, and then merely translated into code. But that's not how programs get written. The inability to have lists of mixed types is a particularly crippling restriction. It gets in the way of exploratory programming (it's convenient early on to represent everything as lists), and it means you can't have real macros.] Thanks a lot, minh thu

7 9

RE: [Haskell] pros and cons of static typing and side effects ?
by Bayley, Alistair 11 Aug '05

11 Aug '05

> From: mt [mailto:mtvo@info.fundp.ac.be] > > yes, that's the kind of answer i expected... that's the kind > of thing you > always see when reading something about haskell. but i guess there's > arguments against... i'd like to make my opinion without just reading > a post saying "it catches many errors". maybe this mailing > list is not the > right place to ask this question ;-) maybe i should ask on a > lisp mailing > list :) For far more reading than anyone could possibly tolerate, see various dicussions at http://lambda-the-ultimate.org. Go to the home page, enter "static typing" in the search box, and then report back two days later :-) e.g. "Why type systems are interesting" http://lambda-the-ultimate.org/node/view/100 (continued (!) in part II http://lambda-the-ultimate.org/node/view/175 ) Alistair. ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

1 0

HaXml ANYContent
by Georg Martius 11 Aug '05

11 Aug '05

Hi, I have some problems with the ANYContent type in HaXml. Currently (1.13) ANYContent is defined as data ANYContent = ANYContent which means I cannot store anything in there. I need two things: 1) Parse a file where some elements have ANY content, but be able to use the content. 2) Create a data structure and fill the ANYContent field and be able to write that to an XML file. I suggest the following sollution: > newtype Unparsed = Unparsed String > data ANYContent = forall a . XmlContent a => Either UnParsed (ANYContent a) If an XML file is parsed we don't know the type yet. Therefore we put everything in Unparsed field. Later on one can use a Parser on that explicitly. It would also make the roundtrip XML->Haskell ->XML more stable. Cheers, Georg -- ---- Georg Martius, Tel: (+49 34297) 89434 ---- ------- http://www.flexman.homeip.net ---------

1 0

RE: Re[2]: [Haskell] proposal about declaring language version andlanguage extensions used in specific module
by Simon Marlow 10 Aug '05

10 Aug '05

On 10 August 2005 08:03, Bulat Ziganshin wrote: > Hello Ross, > > Wednesday, August 10, 2005, 4:24:53 AM, you wrote: > >> On Tue, Aug 09, 2005 at 03:37:01PM -0700, John Meacham wrote: >>> I thought there was talk of a standardized {-# LANGUAGE ... #-} >>> pragma somewhere.. but I can't seem to find it. > >> http://www.haskell.org//pipermail/haskell/2003-September/012692.html >> http://www.haskell.org//pipermail/libraries/2004-October/002589.html > > of course, my proposed extension is very trivial. but compared to > above mentioned variants, it moves definition of language used in > module from pseudocomments to language itself. i also propose moving > of all pragmas from pseudocomments to special language statements The language declaration affects the grammar of the language, and even whether the source is preprocessed or not, so you can't put the declaration into the language itself. {-# LANGUAGE #-} is the right thing (and we should implement it in GHC, really). Cheers, Simon

2 1

proposal about declaring language version and language extensions used in specific module
by Bulat Ziganshin 10 Aug '05

10 Aug '05

Hello all. i have a proposal about declaring language version and language extensions used in specific module PROBLEM: 1) Haskell 2.0 may be slightly incompatible with Haskell 98. at least, new records extension will, afaik, lead to that H'98 (old) programs can't be compiled with Haskell 2.0 compilers. this will create a problem if we want to use the same extensions (hs, lhs, chs) both for Haskell 98 and Haskell 2.0 programs 2) currently language extensions needed to compile specific module are coded via {-# OPTIONS ... #-} pragma. that is both compiler-specific and encodes information, essential for compiling module, as some optional pragma/comment SOLUTION: use specific language keyword to declare language version and used extensions. i will give several examples of this statement: haskell 98 with template haskell, implicit parameters haskell 2.0 haskell 2.0 with generics haskell 2.1 so, general syntax will be: "haskell" version ["with" extension [,extension]*] where version = "98" | "2.0" | ... extension = "template haskell" | "implicit parameters" | ... such statement will declare base language version and additional extensions to this language version, used in the module. it must be first statement in the module. if this statement is not given, then "haskell 98" is supposed using this statement will give exact meaning to each module, despite all the future Haskell versions and extensions we will encounter and will simplify adding new language extensions that is not backward-compatible ps: as variants of this idea we can standartize OPTIONS and several other pragmas in the language itself or, better, add new language keyword to replace these pseudocomments. how about this: option "haskell 2.0" option "inline main, sub1, sub2" option "ghc-rule ..." -- GHC-specific options starts with "ghc-" -- Best regards, Bulat mailto:bulatz@HotPOP.com

3 3

Let's stay in touch
by M O 09 Aug '05

09 Aug '05

Hi I'm updating my address book. Please click on the link below and enter your contact info for me: http://www.ringo.com/i.html?i=116036757x738164&homeEmail=haskell%40haskell.… I'm using a new, free service where I put in my contact info for you, you put in your contact info for me, and everyone stays up to date automatically. It's surprisingly easy and useful. Thanks for your help. M O Don't receive any more invitations from M O: http://www.ringo.com/friends/invite/block.html?memberId=116036757&email=has… Don't receive any more invitations from anyone: http://www.ringo.com/friends/invite/block.html?email=haskell%40haskell.org

1 0

Haskell Weekly News: August 9, 2005
by John Goerzen 09 Aug '05

09 Aug '05

Haskell Weekly News: August 9, 2005 Greetings, and thanks for reading the second issue of HWN, a weekly newsletter for the Haskell community. Each Tuesday, new editions will be posted (as text) to [1]the Haskell mailing list and (as HTML) to [2]The Haskell Sequence. 1. http://www.haskell.org/mailman/listinfo/haskell 2. http://sequence.complete.org/ Discussion Practical Monads. Paul Moore started a [3]discussion about Monads and resources for learning about them. Quite a few readers responded with suggestions. 3. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/7964 STRef vs. IORef. Srinivas Nedunuri started a [4]discussion by asking when to STRef and when to use IORef. Iavor Diatchki posted a helpful [5]example, and many other helpful answers were posted as well. 4. http://thread.gmane.org/gmane.comp.lang.haskell.general/11895 5. http://article.gmane.org/gmane.comp.lang.haskell.general/11901 Parsing Foreign Languages. The The ParsingForeignLanguagesInHaskell wiki page was the subject of a short [6]discussion on the libraries mailing list. If you have any further information or would like to join or start a project to parse a particular language, see the [7]wiki page. 6. http://thread.gmane.org/gmane.comp.lang.haskell.libraries/3572 7. http://www.haskell.org/hawiki/ParsingForeignLanguagesInHaskell Haskell Toolchain Cabal was again a hot topic this week. There were discussions about [8]data directories, [9]running on Windows 98, and [10]package description fields in general. 8. http://thread.gmane.org/gmane.comp.lang.haskell.libraries/3594 9. http://thread.gmane.org/gmane.comp.lang.haskell.libraries/3575 10. http://thread.gmane.org/gmane.comp.lang.haskell.libraries/3566 Darcs Corner Darcs in FreshMeat. David Roundy is [11]looking for volunteers to maintain the Darcs [12]entry at FreshMeat.net. It wouldn't require much time, but the ability to summarize changes at release time. 11. http://article.gmane.org/gmane.comp.version-control.darcs.user/8034 12. http://freshmeat.net/projects/darcs/ Binary files and line endings. Phil Brooke [13]asked how darcs handles line endings and binary files. 13. http://thread.gmane.org/gmane.comp.version-control.darcs.user/8017 Uniqueness of patch names. On #darcs this week, a discussion about the uniqueness of low-level patch names in darcs. The consensus seemed to be that darcs needs an additional better-than-1-second component to patch names to eliminate a situation in which collisions can arise. New Releases * Simon Marlow announced the [14]release of Haddock version 0.7. Highlights of this version include improvements for linking across different packages, bug fixes, collapsable trees in HTML, and support for new output formats. * Einar Karttunen has released [15]hsgnutls 0.1, a Haskell binding for the GnuTLS SSL/TLS library. * John Goerzen [16]announced the release of a preliminary, but working, binding to OpenLDAP from Haskell. 14. http://article.gmane.org/gmane.comp.lang.haskell.general/11903 15. http://www.cs.helsinki.fi/u/ekarttun/hsgnutls/ 16. http://article.gmane.org/gmane.comp.lang.haskell.general/11932 Quotes of the Week <CosmicRay> "Oh Lord, bless this thy holy IO monad, and use it for thy purposes that it may smash Java to tiny bits..." (with apologies to monty python) <Pseudonym> If I ever write a GUI library for Haskell, I'm going to call it pointlesstif. About Haskell Weekly News Want to continue reading HWN? Please help us create new editions of this newsletter. Please see the [17]contributing information, or send stories to hwn -at- complete -dot- org. There is also a Darcs repository available. 17. http://sequence.complete.org/hwn-contrib

1 0

do notation and type synonym
by mt 08 Aug '05

08 Aug '05

hi, first one : i've read in different places that "there is nothing magic with do" and that do { x <- m ; return x } is the *same* as m >>= \x -> return x however i've came up with : m :: Maybe Int m = return 4 check5 = do { 5 <- m ; return 0 } check5' = m >>= \5 -> return 0 the first check5 is ok and return Nothing while the second check5' will raise an "Exception: Non-exhaustive patterns" (which is what i've expected). the sentence "there is nothing magic with do" with its reason are important for me to understand monads and do notation, so maybe someone can rephrase "there is nothing magic with do" and explain the exposed behavior? second one: is it possible to write something like type Point = (Float, Float) type Vector = (Float, Float) and still have type safety (i.e. not be able to mix Point and Vector) (and still have (*,*) without constructor)? thanks, minh thu

5 5