- Haskell-Cafe - Haskell.org

RE: {-# LINE 100 "Foo.hs #-} vs. # 100 "Foo.hs"
by Simon Marlow 19 Jan '01

19 Jan '01

> Indeed. Or do you want to tell me that you are going to > break one of my favourite programs? > > [ code deleted ] > # 111 "Foo.hs" Actually the cpp-style pragma is only recognised if the '#' is in the leftmost column and is followed by optional spaces and a digit. It's quite hard to write one of these in a legal Haskell program, but not impossible. Simon

3 2

Re: A simple problem
by Tom Pledger 18 Jan '01

18 Jan '01

Ashley Yakeley writes: > At 2001-01-18 15:38, I wrote: > > >3 is not always an Integer. It's of type "(Num a) => a". > > Of course, it would be nice if 3 were an Integer, and Integer were a > subtype of Real. I haven't come across a language that does this, where > for instance 3.0 can be cast to Integer (because it is one) but 3.1 > cannot be. A cast in that direction - becoming more specific - would be nicely typed as: Real -> Maybe Integer or with the help of the fail and return methods: Monad m => Real -> m Integer

1 0

Re: A simple problem
by Ashley Yakeley 18 Jan '01

18 Jan '01

At 2001-01-18 15:57, William Lee Irwin III wrote: >class C a where > fun :: a -> Integer > >instance Integral a => C a where > fun = toInteger . succ Gives "syntax error in instance head (constructor expected)" at the 'instance' line in Hugs. Is there a option I need to turn on or something? -- Ashley Yakeley, Seattle WA

2 1

Re: A simple problem
by William Lee Irwin III 18 Jan '01

18 Jan '01

Moving over to haskell-cafe... At 2001-01-18 05:16, Saswat Anand wrote: >> fun 3 --gives error in Hugs >> fun (3::Integer) -- OK >> >> I am a building an embedded language, so don't want user to cast. Is >> there a solution? On Thu, Jan 18, 2001 at 03:38:10PM -0800, Ashley Yakeley wrote: > 3 is not always an Integer. It's of type "(Num a) => a". > I couldn't find a way to say that every Num is a C. I didn't try to say every Num is C, but I found a way to make his example work: class C a where fun :: a -> Integer instance Integral a => C a where fun = toInteger . succ One has no trouble whatsoever with evaluating fun 3 with this instance defined instead of the original. I'm not sure as to the details, as I'm fuzzy on the typing derivations making heavy use of qualified types. Is this the monomorphism restriction biting us again? Cheers, Bill -- <nrut> how does one decide if something is undecidable? <Galois> carefully --

1 0

Re: O'Haskell OOP Polymorphic Functions
by Ashley Yakeley 17 Jan '01

17 Jan '01

At 2001-01-17 16:07, Johan Nordlander wrote: >Ashley Yakeley wrote: >> >> OK, I've figured it out. In this O'Haskell statement, >> >> > struct Derived < Base = >> > value :: Int >> >> ...Derived is not, in fact, a subtype of Base. Derived and Base are >> disjoint types, but an implicit map of type "Derived -> Base" has been >> defined. >> >> -- >> Ashley Yakeley, Seattle WA > >Well, they are actually subtypes, as far as no implicit mapping needs to be >defined. But since Derived and Base also are two distinct type constructors, >the overloading system treats them as completely unrelated types (which is >fine, in general). All O'Haskell treats them as completely unrelated types. In fact, this O'Haskell... > struct Base = > b1 :: Int > b2 :: Char > > struct Derived < Base = > d1 :: Int ...is a kind of syntactic sugar for this Haskell... > data Base = Base (Int,Char) > dotb1 (Base (x,_)) = x > dotb2 (Base (_,x)) = x > > data Derived = Derived (Int,Char,Int) > dotd1 (Derived (_,_,x)) = x > > implicitMap (Derived (b1,b2,d1)) = Base (b1,b2) This seems to be stretching the concept of 'subtype'. Sorry if I sound so bitter and disappointed. I was hoping for a Haskell extended with real dynamic subtyping... -- Ashley Yakeley, Seattle WA

2 1

Boolean Primes Map (continued)
by Shlomi Fish 17 Jan '01

17 Jan '01

Well, after some thought, I decided to try re-writing the boolean primes map program only using a list instead of an array. I came up with this program: primes :: Int -> [Int] primes how_much = (iterate 2 initial_map) where initial_map :: [Bool] initial_map = (map (\x -> True) [ 0 .. how_much]) iterate :: Int -> [Bool] -> [Int] iterate p (a:as) | p > mybound = process_map p (a:as) | a = p:(iterate (p+1) (mymark (p+1) step (2*p) as)) | (not a) = (iterate (p+1) as) where step :: Int step = if p == 2 then p else 2*p mymark :: Int -> Int -> Int -> [Bool] -> [Bool] mymark cur_pos step next_pos [] = [] mymark cur_pos step next_pos (a:as) = if (cur_pos == next_pos) then False:(mymark (cur_pos+1) step (cur_pos+step) as) else a:(mymark (cur_pos+1) step next_pos as) mybound :: Int mybound = ceiling(sqrt(fromIntegral(how_much))) process_map :: Int -> [Bool] -> [Int] process_map cur_pos [] = [] process_map cur_pos (a:as) | a = cur_pos:(process_map (cur_pos+1) as) | (not a) = (process_map (cur_pos+1) as) I don't know too much about Haskell yet, so it is possible this program can be further optimized using some Haskell built-ins. Now, this program can scale to 100,000 and beyond, as opposed to the array version which only got until 30,000 or 40,000. It's a pity Haskell doesn't handle arrays very well, but I guess every language has its faults. Regards, Shlomi Fish ---------------------------------------------------------------------- Shlomi Fish shlomif(a)vipe.technion.ac.il Home Page: http://t2.technion.ac.il/~shlomif/ Home E-mail: shlomif(a)techie.com The prefix "God Said" has the extraordinary logical property of converting any statement that follows it into a true one.

2 1

Re: O'Haskell OOP Polymorphic Functions
by Johan Nordlander 17 Jan '01

17 Jan '01

Ashley Yakeley wrote: > > OK, I've figured it out. In this O'Haskell statement, > > > struct Derived < Base = > > value :: Int > > ...Derived is not, in fact, a subtype of Base. Derived and Base are > disjoint types, but an implicit map of type "Derived -> Base" has been > defined. > > -- > Ashley Yakeley, Seattle WA Well, they are actually subtypes, as far as no implicit mapping needs to be defined. But since Derived and Base also are two distinct type constructors, the overloading system treats them as completely unrelated types (which is fine, in general). To this the upcoming O'Hugs release adds the capability of using an instance defined for a (unique, smallest) supertype of the inferred type, in case an instance for the inferred type is missing. This all makes a system that is very similar to the overlapping instances extension that Tom mentioned. -- Johan

1 0

RE: GHCi, Hugs (was: Mixture ...)
by Simon Peyton-Jones 17 Jan '01

17 Jan '01

| It'd be good if left-behind tools were using a BSD(-like) licence, in | the event that anybody - commercial or otherwise - who wanted to pick | them up again, were free to do so. GHC does indeed have a BSD-like license. Simon

2 1

RE: Will Haskell be commercialized in the future?
by Doug Ransom 17 Jan '01

17 Jan '01

> -----Original Message----- > From: Benjamin L. Russell [mailto:russell@brainlink.com] > Sent: Sunday, November 26, 2000 11:50 PM > To: Doug Ransom; haskell-cafe(a)haskell.org > Subject: Re: Will Haskell be commercialized in the future? > > > On Fri, 24 Nov 2000 09:15:52 -0800 > Doug Ransom <Doug_Ransom(a)pml.com> wrote: > > > > [stuff deleted] > > > > A lot of the things Haskell excells at (IMO) inferior > > tools are being used > > in place. For example, microsoft has build good XSLT > > translators and two > > new compilers (C#, VB7) in the last couple years. > > Unfortunately, C#, not > > Haskell, will probably be "the" language for the next > > decade. [stuff deleted] > > Just out of curiosity: what makes you so sure about C#? C# > has some potential big problems, too: in particular, the > ability to declare a portion of the code "unsafe," which can > encourage unsafe programming among entrenched C/C++ programmers. Well, first of all, most C++ programmers really hate C++ and will be happy to stay in safe mode and move to C#. There were cheers at the Microsoft Profesional Developers Conference when MS announced garbage collection for the COM replacement and the safety available with C# and managed C++ code. C# is a huge improvement over C++. Why would a C++ programmer want to go into unsafe mode? I guess when they are writing interfaces to device drives, operating system calls, and legacy interfaces. > > I myself am in no big hurry to master C#. I'd rather use a > set of domain-specific languages with interlinked code, > rather than a single language that purports to be as > general-purpose as C# does. Well, I would prefer to master Haskell and use that as my general purpose language. Fat chance since the object models available in the microsoft common language runtime are designed for impertive programming. > > Benjamin L. Russell > russell(a)brainlink.com > "Furuike ya! Kawazu tobikomu mizu no oto." --Matsuo Basho >

3 2

RE: Learning Haskell and FP
by Patrick M Doane 17 Jan '01

17 Jan '01

On Wed, 3 Jan 2001, Simon Peyton-Jones wrote: > I'm sure that's right. Trouble is, we're the last people qualified > to write one! > > Here's a suggestion: would someone like to write such a guide, > from the point of view of a beginner, leaving blanks that we can fill in, > when you come across a task or issue you don't know the answer > to? That is, you provide the skeleton, and we fill in the blanks. I read your paper on taming the Awkward Squad several months ago as my first exposure to Haskell. I think it is an excellent paper and really convinced me that Haskell was worthwhile to learn and use. There are aspects to the paper that are like a tutorial, but I think it would be overwhelming for a programmer not used to reading papers from academia. 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. - Avoid mentioning 'monad' and other mathematical terms until much latter in the game. It is better to see the system in action and then find out it has a nice solid foundation. 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. - Take advantage of the 2d syntax rules to avoid the unneeded braces and semicolons. Syntax with little punctuation seems to go a long way with many programmers. Pointing out the similarities to Python here could be appropriate. - After working through several examples, show that the 'do expression' is short hand for some more basic primitive operators. These can be more appropriate to use in some circumstances. - 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." Some points would still be difficult to get through: - Explaining the type system. There is no avoiding this, and users will have to learn it. - Working through the difference between 'unit' and 'void'. Perhaps this can be avoided in a beginning tutorial. A possible confusing example in the paper is that of composing putChar twice while throwing away the result. People used to C or Java might immediately think "but it doesn't have a result to through away!" - Some amount of understanding for Haskell expressions is going to be needed to understand examples. An I/O centric tutorial would want to explain as things go along as needed. I would avoid other parts of the paper for a first attempt at some new tutorial material. Any thoughts? I could take a first stab at this if people think it would be a useful direction. Patrick

6 5