- Haskell - Haskell.org

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

Question about implementation of an "information-passnig" arrow
by Yu Di 16 Sep '03

16 Sep '03

Sorry I just now pressed "send" by mistake when the letter was not finished yet. Please ignore my last mail. Thanks. Following is the correct version of my question. ----- 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. And often the arrow's processing logic will depend on the input information, therefore a monad-style data MyArrow a b = MyArrow (a -> (String, b)) will not work. Now I have a problem with the definition of "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. I thought about this a lot, but it seems to me that the only way to solve this is to somehow make the information "lookupable" from the data itself, not "placed beside" the data, but how I can do that? And can there be some other solution to this? Thanks very much! Di, Yu 9.15 __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

2 1

Deadline for JFP Special Issue on Parallel FP Postponed
by Phil Trinder 16 Sep '03

16 Sep '03

The submission deadline for the JFP special issue on High-Performance Parallel Programming has been postponed to 31st October 2003, see http://www.macs.hw.ac.uk/~trinder/jfpCFP.htm Phil -------------------------------------------------- Phil Trinder School of Mathematical and Computer Sciences Heriot-Watt University Edinburgh, EH14 4AS E-mail: trinder(a)macs.hw.ac.uk Teleph: +44 (0)131 451 3435 Depart: +44 (0)131 451 3328 Fasmly: +44 (0)131 451 3327 Intrnt: http://www.macs.hw.ac.uk/~trinder

1 0

Question about implementation of a " arrow
by Yu Di 15 Sep '03

15 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. And often the arrow's processing logic will depend on the input information, therefore a monad-style data MyArrow a b = MyArrow (a -> (String, b)) will not work. Now I have a problem with the definition of "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)" retrieve the PART of information for the second piece in the pair tuple. __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

1 0

RE: lexer puzzle
by Simon Marlow 15 Sep '03

15 Sep '03

> I agree with Marcin, > > A... should be split into "A.." and "." > > As I read the (on-line) report the "maximal munch" rule says that you > should read the longest lexeme. It does not say that two > operators have > to be separated by whitespace. > > Because A... is not a lexeme, the longest lexeme you can read from > "A..." is "A.." (qualified dot-operator). Wow! I hadn't noticed that before. This means that for example, 'M.where ' must be interpreted as the two tokens 'M.wher' 'e' This is bound to keep the Obfuscated Haskell programmers happy :-) Cheers, Simon

1 0

RE: lexer puzzle
by Simon Marlow 15 Sep '03

15 Sep '03

Iavor Diatchki writes: > what do people think should be the tokens produced by a haskell lexer > when applied to the following input: > > A... This has been discussed before (a while back, admittedly). See: http://www.mail-archive.com/haskell@haskell.org/msg04054.html GHC (still) gets this wrong. It's a documented bug though. Cheers, Simon

1 0

RE: Circular Instance Declarations
by Simon Peyton-Jones 14 Sep '03

14 Sep '03

OK, I yield! The HEAD now runs this program. It turned out to be a case of interchanging two lines of code, which is the kind of fix I like. Simon | -----Original Message----- | From: haskell-admin(a)haskell.org [mailto:haskell-admin@haskell.org] On Behalf Of Ashley Yakeley | Sent: 07 September 2003 06:57 | To: haskell(a)haskell.org | Subject: Circular Instance Declarations | | When -fallow-undecidable-instances is switched on, is there any reason | why circular instances are forbidden? For instance: | | module CircularInsts where | { | data D r = ZeroD | SuccD (r (D r)); | | instance (Eq (r (D r))) => Eq (D r) where | { | ZeroD == ZeroD = True; | (SuccD a) == (SuccD b) = a == b; | _ == _ = False; | }; | | newtype C a = MkC a deriving Eq; | | equalDC :: D C -> D C -> Bool; | equalDC = (==); | } | | When I compile this, I get this: | | $ ghc -fglasgow-exts -fallow-undecidable-instances -c CircularInsts.hs | CircularInsts.hs:2: | Context reduction stack overflow; size = 21 | Use -fcontext-stack20 to increase stack size to (e.g.) 20 | `Eq (C (D C))' arising from use of `==' at CircularInsts.hs:16 | `Eq (D C)' arising from use of `==' at CircularInsts.hs:16 | `Eq (C (D C))' arising from use of `==' at CircularInsts.hs:16 | `Eq (D C)' arising from use of `==' at CircularInsts.hs:16 | | Would it be reasonable for the compiler to check back through the stack | and allow the circularity? It will just create an ordinary recursive | function. | | -- | Ashley Yakeley, Seattle WA | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

3 2