January 2001 - Haskell-Cafe

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

18 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 18 Jan '01

18 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

Re: gui building in haskell
by Jan Kort 16 Jan '01

16 Jan '01

Matthew Liberty wrote: > > Greetings, > > I've been looking at http://www.haskell.org/libraries/#guis and trying > to figure out which package is "best" for building a gui. Can anyone > give a comparison of the strengths/weaknesses of these packages (or any > others)? Hi Matt, When Manuel's Haskell GTK+ binding (gtkhs) is finished it will be really cool. On top of gtkhs there are/will be many other libraries and tools: - iHaskell: a high level GUI library that avoids the eventloop mess. - GtkGLArea: 3D graphics in your GTK+ application using Sven's HOpenGL. - GUI painter: All you need is a backend for Glade. I'm currently working on this. Or at least I was half a year ago, other (even more interesting) things claimed most of my spare time. Of course this will all take a while to come to a beta release. FranTk is currently the only high level interface that is in beta. There is no release for ghc4.08, but it takes only a day or so to get it working. In short: use FranTk now or wait a year and use gtkhs. The reason there are so many GUI libraries on the web page is that nothing ever gets removed. Most of the libraries are no longer supported. I only realized after making the table that it was a bit redundant, but since I spend 10 mins getting the stuff lined up properly (please don't tell me you have a proportional font) you'll have to suffer through it: +------------+--------+-------+-----+------+------+ | GUI lib | Status | Level | W98 | Unix | OS X | +------------+--------+-------+-----+------+------+ | TclHaskell | beta | low | yes | yes | | | Fudgets | alpha*)| high | no | yes | | | gtkhs | alpha | low | | yes | | | iHaskell | | high | | | | | FranTk | beta | high | yes | yes | | +------------+--------+-------+-----+------+------+ | Haggis | dead | high | no | yes | | | Haskell-Tk | dead | | | | | | Pidgets | dead | | | | | | Budgets | dead | | | | | | EmbWin | dead | | | | | | Gadgets | dead | | | | | +------------+--------+-------+-----+------+------+ *) I thought Fudgets was dead, but apparently it has been revived. You might want to check that out too, although it has the words "hackers release" all over it (literaly). Status: alpha/beta I guess "dead" sounds a bit rude. It means that I couldn't find a distribution or it would take too much effort to get it working. Level: low: Raw calls to C library. high: More functional style. W98: Wether it works on Windows 95/98/ME with ghc4.08. Unix: Same for Unix (Solaris in my case). OS X: Same for Macintosh OS X. Hope this helps, Jan

2 1

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

16 Jan '01

At 2001-01-16 14:36, Tom Pledger wrote: >Here's a similar example using type-substitution overlapping: > > instance TheValue Char where ... > instance Monad m => TheValue (m Char) where ... > instance TheValue a => TheValue (Maybe a) where ... > > trouble = theValue (Just 'b') Apparently this is not good Haskell syntax. I tried compiling this in Hugs: class TheValue a where theValue :: a -> Int instance TheValue Char where theValue _ = 0 instance (Monad m) => TheValue (m Char) where theValue _ = 1 -- error here instance (TheValue a) => TheValue (Maybe a) where theValue _ = 2 trouble = theValue (Just 'b') I got a syntax error: (line 3): syntax error in instance head (variable expected) -- Ashley Yakeley, Seattle WA

1 0

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

16 Jan '01

At 2001-01-16 14:04, Tom Pledger wrote: >The subtyping (struct Derived < Base ...) makes the two instances >overlap, with 'instance TheValue Derived' being strictly more specific >than 'instance TheValue Base'. If the system preferred the less >specific one, the more specific one would never be used. > >This is quite similar to the way overlapping instances are handled >when they occur via substitutions for type variables (e.g. 'instance C >[Char]' is strictly more specific than 'instance C [a]') in >implementations which support than language extension. Subtyping-overlapping is quite different from type-substitution overlapping. Consider: struct B struct D1 < Base = a1 :: Int struct D2 < Base = a2 :: Int class TheValue a where theValue :: a -> Int instance TheValue B where theValue _ = 0 instance TheValue D1 where theValue _ = 1 instance TheValue D2 where theValue _ = 2 struct M < D1,D2 m = struct a1 = 0 a2 = 0 f = theValue m What's the value of f? -- Ashley Yakeley, Seattle WA

2 1

Re: O'Haskell OOP Polymorphic Functions
by Tom Pledger 16 Jan '01

16 Jan '01

Ashley Yakeley writes: > At 2001-01-16 13:18, Magnus Carlsson wrote: > > >f1 = Just 3 > >f2 = f3 = f4 = Nothing > > So I've declared b = d, but 'theValue b' and 'theValue d' are different > because theValue is looking at the static type of its argument? > > What's to stop 'instance TheValue Base' applying in 'theValue d'? The subtyping (struct Derived < Base ...) makes the two instances overlap, with 'instance TheValue Derived' being strictly more specific than 'instance TheValue Base'. If the system preferred the less specific one, the more specific one would never be used. This is quite similar to the way overlapping instances are handled when they occur via substitutions for type variables (e.g. 'instance C [Char]' is strictly more specific than 'instance C [a]') in implementations which support than language extension. Regards, Tom

1 0

Re: gui building in haskell
by Ashley Yakeley 16 Jan '01

16 Jan '01

At 2001-01-16 02:48, Jan Kort wrote: >Ashley Yakeley wrote: >> Would some kind Haskell-to-Java bridge be a cost-effective way of >> providing a multi-platform GUI library, as well as network, SQL, RMI >> etc., etc.? >> >> It doesn't necessarily imply compiling to the JVM. Java could simply see >> the compiled Haskell code through the JNI. > >That sounds unlikely to me, how do you overide methods through JNI ? You create a stub Java class with methods declared 'native'. Anything you can do in Java, you can do in the JNI. -- Ashley Yakeley, Seattle WA

1 0

Re: Too Strict?
by C.Reinke 16 Jan '01

16 Jan '01

Dominic, > What I can't see at the moment is how to keep what I was doing modular. I had > a module Anonymize, the implementation of which I wanted to change without > the user of it having to change their code. The initial implementation was a > state monad which generated a new string every time it needed one but if it > was a string it had already anonymized then it looked it up in the state. I > initially used a list but with 100,000+ strings it took a long time. The next > implementation used FiniteMap which improved things considerably. I only had > to make three changes in Anonymize and none in Main. Using MD5 is quicker > still but isn't so good from the program maintenance point of view. my first stab at the modularity issue was the version _2 in my last message. Looking back at the Anonymizable class and instances in your full program, type Anon a = IO a class Anonymizable a where anonymize :: a -> Anon a -- MyString avoids overlapping instances of Strings -- with the [Char] data MyString = MyString String deriving Show instance Anonymizable MyString where anonymize (MyString x) = do s <- digest x return ((MyString . showHex') s) instance Anonymizable a => Anonymizable [a] where anonymize xs = mapM anonymize xs the problem is in the Anonymizable instance for [a]: the mapM in anonymize constructs an IO script, consisting of some IO operation for each list element, all chained together into a monolithic whole. As IO a is an abstract type, this is a bit too restrictive to be modular: if I ever want any of the anonymized Strings, I can only get a script that anonymizes them all - before executing that script, I don't have any anonymized Strings, and after executing the script, all of them have been processed. This forestalls any attempt to interleave the anonymization with some further per-element processing. Instead, I would prefer to have a list of IO actions, not yet chained together (after all, in Haskell, they are just data items), but that doesn't fit the current return type of anonymize. One approach would be to change the type of Anon a to [IO a], or to ignore the [a] instance and use the MyString instance only, but the longer I look at the code, the less I'm convinced that the overloading is needed at all. Unless there are other instances of Anonymizable, why not simply have a function anonymize :: String -> Anon String ? That would still allow you to hide the implementation decisions you mentioned (even in a separate module), provided that any extra state you need can be kept in the IO monad. One would have to write mapM anonymize explicitly where you had simply anonymize, but it would then become possible to do something else with the list of IO actions before executing them (in this case, to interleave the printing with the anonymization). First, here is the interesting fragment with the un-overloaded anonymize: readAndWriteAttrVals = do h <- openFile fileout WriteMode s <- readFile filename a <- mapM anonymize (lines s) hPutStr h (unlines a) It is now possible to import anonymize from elsewhere and do the interleaving in the code that uses anonymize: readAndWriteAttrVals = do h <- openFile fileout WriteMode s <- readFile filename let action line = do { a <- anonymize l ; hPutStr h a } mapM_ action (lines s) Would that work for your problem? Alternatively, if some of your implementation options require initialization or cleanup, your Anonymize module could offer a function to process all lines, with a hook for per-line processing: processLinesWith perLineAction ls = do { initialize ; as <- mapM action ls ; cleanup ; return as } where action l = do { a <- anonymize l ; perLineAction a } Then the code in the client module could simply be: readAndWriteAttrVals = do h <- openFile fileout WriteMode s <- readFile filename processLinesWith (hPutStr h) (lines s) return () Closing the loop, one could now redefine the original, overloaded anonymize to take a perLineAction, with the obvious instances for MyString and [a], but I really don't see why every function should have to be called anonymize?-) Claus PS The simplified code of the new variant, for observation: module Main(main) where import Observe import IO(openFile, hPutStr, IOMode(ReadMode,WriteMode,AppendMode)) filename = "ldif1.txt" fileout = "ldif.out" readAndWriteAttrVals = do h <- openFile fileout WriteMode s <- readFile filename let { anonymize s = return (':':s) ; action l = do { a <- anonymize l ; hPutStr h a } } mapM_ (observe "action" action) (lines s) main = runO readAndWriteAttrVals

1 0