September 2003 - Haskell

Announce: wxHaskell 0.2
by Daan Leijen 19 Sep '03

19 Sep '03

Announcement: wxHaskell version 0.2 ---------------------------------------------------------------------- <http://wxhaskell.sourceforge.net> The new release has (improved) support for tree controls, list controls, toolbars, splitter windows, sliders, gauges, and bitmap buttons. Screenshots of these widgets on different platforms have been added to the website. Furthermore, there are numerous small bug fixes, especially for wxGTK. A list of non-compatible changes is attached at the end of this mail. ---------------------------------------------------------------------- wxHaskell is a portable GUI library for Haskell. The goal of the project is to provide an industrial strength portable GUI library, but without the burden of developing (and maintaining) one ourselves. wxHaskell is therefore build on top of wxWindows -- a comprehensive C++ library that is portable across all major GUI platforms; including GTK, Windows, X11, and MacOS X. Furthermore, it is a mature library (in development since 1992) that supports a wide range of widgets with native look-and-feel, and it has a very active community (ranked among the top 25 most active projects on sourceforge). Since most of the interface is automatically generated from the wxEiffel binding, the current release of wxHaskell already supports about 75% of the wxWindows functionality -- 2766 methods in 505 classes with 1279 constant definitions. wxHaskell has been build with GHC 6.0/6.01 on Windows, MacOS X and Unix systems with GTK. A binary distribution is available for Windows and MacOS X. And even if you don't intend to write GUI's yourself, it will be fun to check out the screenshots at <http://wxhaskell.sourceforge.net>. All the best, Daan Leijen. ps. More funny statistics: the wxWindows libraries have been downloaded over a million times at sourceforge! The Python binding to wxWindows (wxPython) about 600.000 times, and the Haskell binding to wxWindows about 100 times :-) ---------------------------------------------------------------------- Breaking changes to version 0.1: - Renamed the "WXH" layer to "WXCore". > import Graphics.UI.WXCore instead of > import Graphics.UI.WXH - Changed the interface of menu items a bit. The label and help text is now supplied via attributes: > medit <- menuPane [text := "&Edit"] > mfont <- menuItem medit [text := "&Font...\tCtrl+F" > ,help := "Set the font"]

4 6

RE: Syntax extensions (was: RE: The Future of Haskell discussionat the Haskell Workshop)
by Simon Marlow 18 Sep '03

18 Sep '03

> {-# LANGUAGE <specification> #-} > > where <specification> is one or more (if compatible) of keywords like > > Haskell98 Pure Haskell 98, no extensions. > SharedExtenisons (Haskell02???) A set of agreed-upon extensions > implemented by all "major" > Haskell systems. > RecursiveDo > ArrowSyntax > TemplateHaskell > OverlappingInstances > UndecidableInstances > FFI Foreign Function Interface > MPTC Multi-parameter Type Classes Looks fine to me. A few things to think about: - Some of the keywords specify an entire language (eg. Haskell98), whereas some are language modifiers (eg. FFI). We might want to make a distinction. Currently GHC supports only Haskell98 + modifiers. - Are extensions always additive? Are there any extensions which are incompatible? - There are features you might want to *disable*. eg. GHC lets you turn off the monomorphism restriction. Perhaps something like this: {-# LANGUAGE Haskell98 +FFI -MonomorphismRestriction #-} > (abbreviations used when three or more words). > > The OPTION pragma would be used for compiler-specific > options, although, > in the interest of supporting portable code without having to > resort to > preprocessing using CPP, maybe it would make sense to provide > > OPTIONS-GHC > OPTIONS-Hugs > OPTIONS-NHC > ... > > as well, the idea being that a compiler/interpreter then only > would look at options pertinent to itself. Yes, I've been meaning to rename GHC's version of the pragma to GHC_OPTIONS for some time. Cheers, Simon

3 2

Re: Syntax Extensions (and future Haskell)
by b.i.mills＠massey.ac.nz 18 Sep '03

18 Sep '03

Ton, Henrick, > | The importance of Haskell is [...] the emphasis it puts on the > | manner in which the total function is decomposed. [...] > Would the picture be less gloomy if you said "the emphasis I put on..." > rather than "the emphasis [Haskell] puts on..."? At first reading, I would have said no, but I get your point. As long as pure sub-Haskell exists, I can still write pure code. > I think most Haskeller's, agree with you: we would like to strive > for uniformity. But how does one get there, how does one agree > on agreeing? A large part of the answer, I think, is through > experiments, i.e. experimental language features, [...] > And in order to find *good* answers to such questions, one needs > to make use of these features in pretty serious projects, which > in turn implies that there has to be a reasonable way of enabling > and disabling them. And command line arguments just isn't a very > good way of doing that in practice. You've both made good points, which I accept. Although I remain wary of these things becoming too much a part of the pragmatic usage and getting locked in as standard behaviour for applications. But, you've convinced me that goal of concptualy pure pragmatic programming is still a feature of the group. Wiping nose on sleeve, I withdraw to write some more geometric software. Regards, Bruce.

1 0

Re: Syntax Extensions (and future Haskell)
by b.i.mills＠massey.ac.nz 18 Sep '03

18 Sep '03

Although a number of comments in this discussion make some sense, I personally am getting worried about the direction that it is taking. I have been a (fairly quiet) Haskell user for some time. I like it because of the strong connection to standard mathematical constructs, and the dedication to equational reasoning. I was dubious when Monads were introduced, but grew to be comfortable with that as an approach to embedding temporal characteristics, I try not to use do, I like the fact that I don't have to. But, recent developments on this list suggest that this is all going to be a thing of the past. There is a real danger that Haskell will just turn into yet another procedural language. Firstly I want to bring into the open something that you would all be aware of. It is possible to change any typical procedural imperative language into a functional language by a change of point of view. All you do is just state that each command in the imperative is a function that operates on the state of the machine. The entire program becomes a composition of these functions. Control statements such as for-do-while-until-repeat-if, simply become higher order functions. That's why the monad stuff works, all it does is demand that you explicitly admit to the passing of the state. If you keep going the way you are going you will simply turn Haskell into a procedural language with some snazzy data-types. It would survive, perhaps, but in name only. The importance of Haskell is not that it is Functional, this is in reality just a technicality of point of view, the importance of Haskell is the WAY in which it is functional, the emphasis it puts on the manner in which the total function is decomposed. It is important not simply that Haskell admits equational reasoning, but that it is equational reasoning that a human can do, not something that requires a heavy duty code transformer to work out. At least this is how I see it, perhaps this is simply the point at which Haskell and I part company? I also don't see the point of the language configuration pragmas either. Uniformity is important. Instead of agreeing to disagree, and coming up with a rag-bag language, the points need to be nutted out until they make consistent sense. The pragmas do not represent any uniformity, they actually represent a schism, you can't agree so you are splitting the language into incompatible variants. It solve the political problem of in-fighting, but only by letting the in-fighting destroy the language. It's the same sort of thing that splits C++ into multiple camps, the same thing that gives the multiple levels of comments in comments for postscript, and so on. Remember Flon's law. The fact that you CAN do something does not mean that it is a good idea. I'll get off my soap box now. Regards, Bruce. ------------------------------------------------------------------------- Institute for Information and Mathematical Sciences Massey University at Albany, email: B.I.Mills(a)massey.ac.nz web: http://www.massey.ac.nz/~bimills -------------------------------------------------------------------------

3 2

How can I implement this arrow? Thanks
by Yu Di 17 Sep '03

17 Sep '03

Hi, I want to create an arrow which is essentially data MyArrow a b = MyArrow ((String, a) -> (String,b)) i.e. there is an "information" asscioated with each piece of data (represented by the string), and I want to pass it around. But I have a problem about how to define "pure" and "first". At first, I declared pure f = MyArrow (\(s, x) -> (s, f x)) first (MyArrow f) = MyArrow (\(s, (x, y)) -> let (s', z) = f (s, x) in (s', (z, y))) this seems to work, but then I begin to have problems with the "data-plumbing" pure arrows, e.g. in pure (\x -> (x, x)) >>> first someArrow >>>> pure (\(_, x) -> x) Ideally, this arrow will preserve whatever information I put there for the input, but because "first someArrow" will change the whole information associated with the pair of result, I can't find any way to let "pure (\(_, x)->x)" (which is an extremely generic function) retrieve the part of information for the second piece in the pair tuple. Of course I can create specialized arrows for the tasks \x -> (x, x) and \(_, x) -> x which passes the information around, but this will become tedious as I will have to define specialized arrows for a lot of similar tasks one by one, and I won't be able to use the arrow pre-processor at all. So how can I implement this? Thanks very much! Di, Yu 9.15 _________________________________________________________________ Get 10MB of e-mail storage! Sign up for Hotmail Extra Storage. http://join.msn.com/?PAGE=features/es

4 6

Improvement on this function
by Gordon James Miller 17 Sep '03

17 Sep '03

Hello all. I'd be interested in getting some feedback on how to do this linear interpolation function a little more cleanly. The normal way that this is taught is to find the set of indices in the x list that bracket the input value, then use the slope between these points to calculate the y value for the input value. I had a version working at one point using !! to access particular elements but I wasn't sure which one was the better solution. linterp :: [Double] -> [Double] -> Double -> Double linterp (x1:x2:xs) (y1:y2:ys) x | x <= x2 || xs == [] = linterpPair x1 x2 y1 y2 x | otherwise = linterp (x2:xs) (y2:ys) x where linterpPair x1 x2 y1 y2 x = x1 + (x - x1) * (y2 - y1) / (x2 - x1) Gordon James Miller Promisemark, Inc. Senior Computer Scientist gmiller(a)promisemark.com (571)330-9012 Light travels faster than sound. That is why some people appear bright until you hear them speak.

1 0

Is there Haskell with a spreadsheet and/or Python?
by Lloyd Allison 17 Sep '03

17 Sep '03

Is there a spreadsheet written in Haskell? The "applications" pages don't seem to list one. (Haxcel and Vital are not really the kind of thing being sought.) Or, is there a Python binding for Haskell -- in which case one could "infiltrate" gnumeric. There seems to be some echo of a similar question in the mailing list. Lloyd -- Lloyd ALLISON, CSSE, Monash University, Victoria, Australia 3800. web: http://www.csse.monash.edu.au/~lloyd/ tel: +61 3 9905 5205 use: http://www.linux.org/ OpenOffice: http://www.openoffice.org/

1 0

Re: How can I implement this arrow? Thanks
by Yu Di 16 Sep '03

16 Sep '03

What I am trying to do is to use Haskell to simulate some process, and meanwhile collecting information about the data-flow throughout the whole process into the output. The (String, a) example is just a simplified version of that. Thanks for pointing out my mistakes, I will try to do it as a decorated-data combinator. Thanks again, Di, Yu 9.16 >From: Derek Elkins <ddarius(a)hotpop.com> >To: Yu Di <diyu01(a)hotmail.com> >CC: haskell(a)haskell.org, Ashley Yakeley <ashley(a)semantic.org> >Subject: Re: How can I implement this arrow? Thanks >Date: Tue, 16 Sep 2003 12:24:17 -0400 > >On Tue, 16 Sep 2003 01:52:03 -0700 >Ashley Yakeley <ashley(a)semantic.org> wrote: > > > In article <Sea1-F33yfxRydC3hSs00038d72(a)hotmail.com>, > > "Yu Di" <diyu01(a)hotmail.com> wrote: > >Replying to both: > > > > Hi, I want to create an arrow which is essentially > > > > > > data MyArrow a b = MyArrow ((String, a) -> (String,b)) > > > > I don't think this type is an arrow. For a "product arrow", i.e. an > > instance of Hughes' "Arrow" class with "first" defined, you can define > > this: > >Oh, it's definitely an arrow. > > > > i.e. there is an "information" asscioated with each piece of data > > > (represented by the string), > >So make a data type that sticks together something and it's information. > > > > and I want to pass it around. > >What's wrong with the support Haskell already has for passing around >things? Why do you think you need an arrow? > >From how you read the meaning of the MyArrow type, you are apparently >misunderstanding what arrows are. Arrows generalize functions. >As such things of arrow type are intuitively transformers and the arrow >framework standardizes how to stick transformations together to make a >larger transformation. The things in an arrow's representation are >what's required for the implementations of the transformations. >Therefore, things in an arrows representation are, in a sense, "owned" >by the arrow computation. This is evidenced by a) arrows have a fully >polymorphic type, they place no restrictions on their input; within the >computation, the String in MyArrow is not even visible let alone >required to be provided, and b) the above arrow is the State arrow >specialized to Strings. The String is the state and is owned by the >computation. You are having trouble defining 'first' as you'd like >because what you want is to duplicate the state of the >computation. -The- (there is only one at any time) String being passed >around isn't associated with the objects. > >From the sounds of it you simply want a combinator library that operates >on some decorated data. A monad or arrow may be useful to support >that, e.g. the environment monad, but a monad/arrow isn't that. You >haven't really given much detail to what you're ultimately trying to >achieve so I can't really provide much advice. > _________________________________________________________________ Use custom emotions -- try MSN Messenger 6.0! http://www.msnmessenger-download.com/tracking/reach_emoticon

3 2

Syntax extensions: mdo and do...rec
by nilsson＠cs.yale.edu 16 Sep '03

16 Sep '03

Dear Haskellers, A questions. The do-notation has been extended to support recursive bindings by using the "mdo" keyword. The do-notation has also been extended (through Ross Patterson's preprocessor, and now also GHC) to support programming with arrows. In that context, a different syntax, using the keyword "rec", is used to enable recursive bindings. It seems somewhat confusing to have distinct syntax for what appears to be very closely related purposes. Would it be possible have just a single syntactic extension to enable recursive bindings in either context? (Presumably the "rec" version is a bit more flexible in that it can be applied to a subset of the bindings in a do-construct.) Best regards, /Henrik -- Henrik Nilsson Yale University Department of Computer Science nilsson(a)cs.yale.edu

1 0

RE: Syntax extensions (was: RE: The Future of Haskell discussion at the Haskell Workshop)
by Simon Marlow 16 Sep '03

16 Sep '03

Mark Jones writes: > As a solution to that problem, the many-command-line-options > scheme described seems quite poor! It's far too tool specific, > not particularly scalable, and somewhat troublesome from a software > engineering perspective. We're not talking about a choice between > two points any more; there's a whole lattice of options, which, by > the proposal above might be controlled through a slew of tool-specific > and either cryptic or verbose command line switches. Will you > remember which switches you need to give to compile your code for > the first time in two months? How easy will it be to translate > those settings if you want to run your code through a different > compiler? How much help will the compiler give you in tracking > down a problem if you forget to include all the necessary switches? > And how will you figure out what options you need to use when you > try to combine code from library X with code from library Y, each > of which uses its own interesting slice through the feature set? > > I know that some of these problems can be addressed, at least in > part, by careful use of Makefiles, {-# custom pragmas #-}, and perhaps > by committing to a single tool solution. But I'd like to propose > a new approach that eliminates some of the command line complexities > by integrating the selection of language extensions more tightly > with the rest of the language. Initially I liked the idea, but now I'm not so sure (more about that later). But first I'll point out that the situation isn't nearly as bad as you make out. In GHC, the approved way to add these flags is by using a pragma to the source code, for example: {-# OPTIONS -fth -fffi #-} module Foo where ... this in itself addresses most of your complaints. Using a compiler-independent syntax would address another one. We're left with: > How much help will the compiler give you in tracking > down a problem if you forget to include all the necessary > switches? We don't make any attempt to address this, but there are various ways we could be more helpful: eg. finding a stray 'forall' in a type when rank-N is not turned on is a clear indication. Nevertheless, this seems orthogonal to the issue of how to specify the language flavour in the first place. > And how will you figure out what options you need to use when you > try to combine code from library X with code from library Y, each > of which uses its own interesting slice through the feature set? Interesting point. Our take on this is that the extension-flags specify the language variant in which the source code *in this module* is written. For example, if I define a multi-parameter type class C in module A, then it is completely legal to import A into any other module regardless of the settings of the flags, but I will only be able to write an instance of C if multi-parameter type classes are enabled. This is a consistent position which has the benefit of being easy to understand. > The main idea is to use the module system to capture information > about which language features are needed in a particular program. > For example, if you have a module that needs implicit parameters > Template Haskell, and TREX, then you'll indicate this by including > something like the following imports at the top of your code: > > import Extensions.Types.ImplicitParams > import Extensions.Language.TemplateHaskell > import Extensions.Records.TREX How do I enable hierarchical modules using this scheme? ;-) Can any of these extensions affect the syntax of the export list? If so, how do I parse the module? (perhaps I have to use a most-general syntax for the export list, parse up to and including the imports, then re-parse the export list). [snip] > Of course, code that does: > > import Extensions.Types.Multiparam > > is not standard Haskell 98 because there's no such library in the > standard. This is a good thing; our code is clearly annotated as > relying on a particular extension, without relying on the command > line syntax for a particular tool. Moreover, if the implementers > of different tools can agree on the names they use, then code that > imports Extensions.Types.Multiparam will work on any compiler that > supports multiple parameter classes, even if the underlying > mechanisms for enabling/disabling those features are different. > When somebody tries to compile that same piece of code using a > tool that doesn't support the feature, they'll get an error > message about a missing import with a (hopefully) suggestive > name/description, instead of a cryptic "Syntax error in constraint" > or similar. This complaint is also addressed by using a compiler-independent pragma, except the error message would be "unsupported extension". > Also, when you come back to compile your code after some > time away, you won't need to remember which command line options you > need because it's all there, built in to the source in a readable and > perhaps even portable notation. You just invoke the compiler (without > worrying about specifying options) and it does the rest! Also applies to pragmas. > Hmm, ok, but perhaps you're worrying now about having to enumerate > a verbose list of language features at the top of each module you > write. Isn't that going to detract from readability? This is where > the module system wins big! Just define a new module that imports all > the features you need, and then allows you to access them by a single > name. For example, you could capture the second feature set above > in the following: > > module HackersDelight where > import Extensions.Language.Mdo > import Extensions.Records.Structs > import Extensions.Types.RankN > import Extensions.Types.Multiparam > > Now the only thing you have to write at the top of a module that > needs some or all of these features is: > > import HackersDelight This seems like a compelling feature, and indeed when I started to write this message I was going to say what a great idea it is. But I've thought about it a bit more, and concluded that I don't think it is worth the implementation cost. Bah! you say, that's for the implementors to worry about - and to a certain extent you'd be right, but let me point out the difficulties that arise if you're allowed to do this. The pragma approach to specifying the language variant has a nice property: I can parse any module into abstract syntax without knowing anything about the semantics of imports. Well, that's not entirely true: to correctly implement Haskell 98 I have to know the fixities of operators to parse a module, and fixities can be imported. But none of the existing Haskell 98 implementations actually does this. Why? Because it's too much of a pain. If I have to understand the imports in order to parse a module, I can't write a standalone Haskell parser. A standalone parser would have to chase imports, which brings in a large amount of extra complexity. However, there are some extensions for which this approach works nicely: one is overlapping instances. If I have a library which exports an interface which relies heavily on overlapping instances to work, then it makes sense for all clients of the library to automatically get overlapping-instances turned on. Or does it? Do I really want overlapping instances turned on just because I imported module Foo.Bar.Baz, or would I rather have to specify them explicitly in each module that requires them? I think I lean towards having to specify extensions explicitly in each module, but there are clearly arguments both ways. [ rest of message snipped ] In conclusion, I'm not convinced. Using pragmas in the source code solves most of the problems, although admittedly we should agree on a compiler-independent syntax for them. Re-exporting extensions brings a heavy implementation burden, and it is not clear (to me) that we really want the ability to do this. Cheers, Simon

4 3