Re: Are anonymous type classes the right model at all? (replying to Re: Are fundeps the right model at all?)
Tom Pledger wrote: > > 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. :-) No holiday in sight, I'm afraid :-) I just managed to resist the temptation of throwing in another ad for O'Haskell. But since my name was brought up... > 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 Notice though that O'Haskell lacks the ability delete fields, which I think is what Marcin also proposes. I've avoided such a feature in O'Haskell since it would make the principal type of an expression sensitive to future type declarations. For example, assuming we have f p = p.x , its principal type would be Point -> Float if only the type definitions above are in scope, but OneDimPoint -> Float in another scope where some type OneDimPoint is defined to be Point with field y deleted. -- Johan ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Haskell Language Design Questions
Doug Ransom writes: [...] > 2. It seems to me that the Maybe monad is a poor substitute for > exception handling because the functions that raise errors may not > necessarily support it. It sometimes helps to write such functions for monads in general, rather than for Maybe in particular. Here's an example adapted from the standard List module: findIndex :: (a -> Bool) -> [a] -> Maybe Int findIndex p xs = case findIndices p xs of (i:_) -> Just i []-> Nothing It generalises to this: findIndex :: Monad m => (a -> Bool) -> [a] -> m Int findIndex p xs = case findIndices p xs of (i:_) -> return i []-> fail "findIndex: no match" The price of the generalisation is that you may need to add some type signatures to resolve any new overloading at the top level of the module. Regards, Tom ___ 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
Re: Learning Haskell and FP
> 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. 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. Erik ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
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: Extending the do-notation
| Another question concerning the do-notation: I noticed | that most parts of ghc do not use it. Is it because | the code was written before the notation was available, | because the do-notation is too weak to express these | parts, or for another fundamental reason ? The former: mostly written before do-notation existed. We're gradually migrating! Simon ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Extending the do-notation
> > 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? Which of the following is easier to read (and please forgive the short variable names) ? >x <- return $ m or >let x = m >x <- m >let (a, b) = unzip x >... -- (and this code uses an extra variable) or >(a, b) <- unzip `liftM` m Concise does not mean obfuscated. Unnecessarily inflating your code will not make it more readable. Or am I wrong ? ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
