Re: Extending the do-notation
Sebastien Carlier wrote: import Monad ... do y - liftM unzip m1 Thanks. I'm constantly amazed by the number of tricks one has to know before he can write concise code using the do-notation (among other things, I used to write "x - return $ m" instead of "let x = m"). [snip] Why do you WANT to write concise code using the do-notation? Has someone revived the Obfuscated Haskell Contest, or do you find touch-typing difficult? ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Yet more on functional dependencies
I am finding functional dependencies confusing. (I suspect I am not alone.) Should the following code work? class HasConverter a b | a - b where convert :: a - b instance (HasConverter a b,Show b) = Show a where show value = show (convert value) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Are fundeps the right model at all?
Mon, 8 Jan 2001 17:53:35 +1300, Tom Pledger [EMAIL PROTECTED] pisze:
Having types with type variables which are never instantiated nor
constrained should be equivalent to having ground types!
Do you have any examples of such a type variable in an instance decl?
Not quite. When the type variable is never instantiated, like in ST
(ghc's and hbc's state threads), I don't see fundeps.
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTPCZA
QRCZAK
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Yet more on functional dependencies
George Russell writes: I am finding functional dependencies confusing. (I suspect I am not alone.) Should the following code work? class HasConverter a b | a - b where convert :: a - b instance (HasConverter a b,Show b) = Show a where show value = show (convert value) Yes. Let's assume that multi-parameter classes and overlapping instances are enabled. Without the functional dependency, the instance decl would be rejected because the type variable b occurs in the context (HasConverter a b, Show b) but not in the head (Show a). The compiler needs to generate some code for `show value', but it's not allowed to make an arbitrary substitution for b. The functional dependency provides a way to determine b uniquely once a is matched. So, the compiler can generate the code for `show value' without being arbitrary. Regards, Tom ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Are anonymous type classes the right model at all? (replying to Re: Are fundeps the right model at all?)
Marcin 'Qrczak' Kowalczyk writes: [...] My new record scheme proposal does not provide such lightweight extensibility, but fields can be added and deleted in a controlled way if the right types and instances are made. Johan Nordlander must be on holiday or something, so I'll deputise for him. :-) O'Haskell also has add-a-field subtyping. Here's the coloured point example (from http://www.cs.chalmers.se/~nordland/ohaskell/survey.html): struct Point = x,y :: Float struct CPoint Point = color :: Color Regards, Tom ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
ANNOUNCE: Draft TOC of Haskell in a Nutshell
Inspired by the recent discussions of what kinds of books would encourage the spread of Haskell, I whipped up a draft table of contents for "Haskell in a Nutshell." You can find it in PDF form at http://nellardo.com/lang/haskell/hianTOC.pdf (it should have the fonts embedded - OReilly uses a couple of oddballs) and in ASCII text at http://nellardo.com/lang/haskell/haskell-in-a-nutshellTOC.txt. While there are page numbers attached, you should simply ignore those for the moment :-) Rather, I'd be interested in feedback on the structure etc. Oh, and please don't just rip it off and write it yourself :-) Like "Java in a Nutshell", the first part is a firehose description of the language. As Haskell is somewhat different from what most OReilly readers are used to, I've included a bit more about different ways you can run Haskell (which, incidentally, points out that it runs *everywhere*). Also like "Java in a Nutshell", the last part is a reference to common packages. The middle part is a bit different - a short "cookbook" of semi-practical programs addressing fairly common programming tasks - some of the kinds of things you'd typically do with Perl or C++. I think it needs more "recipes" of course, but I'd like to know if the general idea is working. Brook ps - for the curious, I have in fact written a textbook before (object-oriented programming for a first-semester course, from 1994...). And I'm using O'Reilly's FrameMaker templates, so the draft is "camera-ready" (hence the page numbers - the TOC is automatically generated). ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: ANNOUNCE: Draft TOC of Haskell in a Nutshell
Brook Conner [EMAIL PROTECTED] wrote, You can find it in PDF form at http://nellardo.com/lang/haskell/hianTOC.pdf (it should have the fonts embedded - OReilly uses a couple of oddballs) and in ASCII text at http://nellardo.com/lang/haskell/haskell-in-a-nutshellTOC.txt. Makes sense to me. However, I would move IO further to the front. For any "real life" programming, IO is essential and, I think, it is bad for the image of Haskell to treat it as something dirty that is relegated to end of every (at least, many) introduction of Haskell. I have just given an Introduction to Computing course using Haskell and written a set of lecture notes, which introduce a couple of concepts (including IO) differently than commonly done. The whole stuff is at http://www.cse.unsw.edu.au/~cs1011/lectures/index.html Feel free to get inspiration from the material (except Weeks 8 - 10, which weren't given by me). You will find IO in Week 5. Note that I haven't used the word monad a single time. IMHO, monads are an advanced concept, IO is not. It's like you can introduce recursion without discussing stacks. If you understand stacks, you can gain a deeper understanding of recursion, but if you hear about recursion for the first time, the mention of stacks will only distract the average student. The middle part is a bit different - a short "cookbook" of semi-practical programs addressing fairly common programming tasks - some of the kinds of things you'd typically do with Perl or C++. I think it needs more "recipes" of course, but I'd like to know if the general idea is working. I think, that this is a good idea. Cheers, Manuel ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: ANNOUNCE: Draft TOC of Haskell in a Nutshell
Yes! I agree with Manuel about the IO. It looks bad being towards the end. Regards, Bill Halchin From: "Manuel M. T. Chakravarty" [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: Re: ANNOUNCE: Draft TOC of Haskell in a Nutshell Date: Tue, 09 Jan 2001 13:43:59 +1100 Brook Conner [EMAIL PROTECTED] wrote, You can find it in PDF form at http://nellardo.com/lang/haskell/hianTOC.pdf (it should have the fonts embedded - OReilly uses a couple of oddballs) and in ASCII text at http://nellardo.com/lang/haskell/haskell-in-a-nutshellTOC.txt. Makes sense to me. However, I would move IO further to the front. For any "real life" programming, IO is essential and, I think, it is bad for the image of Haskell to treat it as something dirty that is relegated to end of every (at least, many) introduction of Haskell. I have just given an Introduction to Computing course using Haskell and written a set of lecture notes, which introduce a couple of concepts (including IO) differently than commonly done. The whole stuff is at http://www.cse.unsw.edu.au/~cs1011/lectures/index.html Feel free to get inspiration from the material (except Weeks 8 - 10, which weren't given by me). You will find IO in Week 5. Note that I haven't used the word monad a single time. IMHO, monads are an advanced concept, IO is not. It's like you can introduce recursion without discussing stacks. If you understand stacks, you can gain a deeper understanding of recursion, but if you hear about recursion for the first time, the mention of stacks will only distract the average student. The middle part is a bit different - a short "cookbook" of semi-practical programs addressing fairly common programming tasks - some of the kinds of things you'd typically do with Perl or C++. I think it needs more "recipes" of course, but I'd like to know if the general idea is working. I think, that this is a good idea. Cheers, Manuel ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell _ Get your FREE download of MSN Explorer at http://explorer.msn.com ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: ANNOUNCE: Draft TOC of Haskell in a Nutshell
Brook Conner [EMAIL PROTECTED] writes: Inspired by the recent discussions of what kinds of books would encourage the spread of Haskell, I whipped up a draft table of contents for "Haskell in a Nutshell." Let's see. It all depends on what you put into the chapters, of course, but you seem to jump directly from simple concepts into Haskell for web servers. Wouldn't it be better to push this further out, until at least some of the syntax has been explored? From the headlines, one might get the impression that type declarations are only important when the compiler can't figure it out itself - I'm sure the actual text will give a different view, no? The cookbook looks great, and it's certainly something I'd buy the book for. I can, of course, think of many kinds of example programs I'd like to see - how about a GUI oriented program, for instance? Perhaps you could finish it off with a "real" application, say a GUIed JPEG viewer, where you sort of string it all (the JPEG codec, a C library interface for something or other, and GUI stuff, etc.) together into a whole? On the whole, I think it looks good. Best of luck! -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: ANNOUNCE: Draft TOC of Haskell in a Nutshell
However, I would move IO further to the front. For any "real life" programming, IO is essential... I am currently teaching a Functional Programming lecture (notes in German: http://www.informatik.uni-leipzig.de/~joe/edu/ws00/praxis/skript/) and I also used this approach: use the do-notation intuitively (for text IO and graphics, using SOE book), and explain monads later (with parser combinators and interpreters). This could be driven to the extreme: not only hide the word "monad", but also "functional". The title would be "Imperative programming in Haskell" (as S. Peyton Jones says in Tackling the Awkward Squad: "Haskell is the world's finest imperative programming language"). The students would start writing do-notated programs in the IO monad, starting with putStrLn "Hello World"; and gradually the emphasis is shifted from sequencing (the "semicolon") to "what can we do on the righthand side of let x = ... ", thus introducing functional programming. Not sure if this is really a good idea, though... -- -- Johannes Waldmann http://www.informatik.uni-leipzig.de/~joe/ -- -- [EMAIL PROTECTED] -- phone/fax (+49) 341 9732 204/252 -- ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Learning Haskell and FP
On Fri, 5 Jan 2001 10:26:19 -0500 (EST) Patrick M Doane [EMAIL PROTECTED] wrote: [snip] I think a really good beginner's tutorial on I/O could be started from this paper: - Start immediately with using the 'do expression' and don't worry about the history that led to its development. Actually, the history, especially from a comparative programming languages standpoint, can sometimes be useful for motivation. For example, many Java textbooks motivated study of the language by explaining the need for a C-style language without explicit memory allocation or explicit pointer casting. Similarly, an on-line document for C# motivated it by explaining the history of how it grew out of a need for a language similar to C and C++ (the document somehow left out the Java comparison :-( ), but that allowed programmers to develop more efficiently in it. Even for a "Haskell in a Nutshell"-style textbook, a couple of paragraphs comparing Haskell to other languages from a historical viewpoint and describing the advantages and disadvantages of Haskell in particular could prove quite useful. [snip] Many people are also annoyed by an author using new vocabulary even if it is well defined. It's better to get them comfortable with the system first. That depends on which new vocabulary is being mentioned, though. That may true for unnecessary new vocabulary, such as "monads" for the first chapter. However, e.g. in the following example (borrowed from Chapter 3 of _A Gentle Introduction to Haskell, Version 98,_ by Paul Hudak): add :: Integer - Integer - Integer add x y = x + y it is hard not to introduce such vocabulary as "has type," "arrow" (or "mapping"), and maybe even "currying." [snip] - Conclude with explaining the difference between executing an action and building a value to execute the action. There is no need to point out that this is a requirement of being a lazy language. Instead point out the benefits such a system provides to back up the claim that Haskell truly is "the world's finest imperative programming language." Forgive me if I am ignorant, but who claimed that Haskell was an "imperative" language? Also, in order to take full advantage of Haskell, it would seem necessary to get used to functional programming style (the Haskell school of expression, in particular). It seems that using Haskell as an "imperative" language is a bit like thinking in C when programming in C++; only worse, since the imperative habits are being brought into the functional, rather than the OO, realm. --Ben -- Benjamin L. Russell [EMAIL PROTECTED] [EMAIL PROTECTED] "Furuike ya! Kawazu tobikomu mizu no oto." --Matsuo Basho ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Learning Haskell and FP
Erik Meijer wrote: Nope, I also think that Haskell is the world's finest *imperative* language (and the world's best functional language as well). The beauty of monads is that you can encapsulate imperative actions as first class values, ie they have the same status as functions, lists, ... Not many other imperative languages have statements as first class citizens. It may be the only imperative language that doesn't have mutable variables as a standard part of the language. :-) I do agree that Haskell has a lot of nice imperative features, but it is also missing a few that are fundamental to imperative programming. Personally, I'd love to see a language that is imperative from the ground up, that has some of the design features of Haskell (especially the type system), but I don't think that Haskell is that language (yet?). A question for the list: Is there a book that gives a good introduction to Hindley-Milner typing theory and practice, and that delves into its various extensions (e.g. imperative programs, type classes, record types). I have Mitchell's book out from the library, but it seems a bit limited with respect to extentions (I think it deals with subtypes, but not type classes and mutable variables, for example). Cheers, Theodore Norvell Dr. Theodore Norvell[EMAIL PROTECTED] Electrical and Computer Engineering http://www.engr.mun.ca/~theo Engineering and Applied SciencePhone: (709) 737-8962 Memorial University of Newfoundland Fax: (709) 737-4042 St. John's, NF, Canada, A1B 3X5 ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
