- Haskell-Cafe - Haskell.org

FP & Python
by Manuel M. T. Chakravarty 24 Nov '00

24 Nov '00

The following article featuring an interview with the authors of alternative Python implementations might be interesting to some of you, as it features the use of FP technology in the context of a popular language: http://www-4.ibm.com/software/developer/library/l-pyth7.html?open&l=666,t=g… Vyper might actually be of interest for Phil's page about real-world applications of FP. Cheers, Manuel

1 0

haskell editor..
by John Meacham 16 Nov '00

16 Nov '00

so while randomly surfing the realm of haskell space I came across the Alfa Proof assistant. (http://www.cs.chalmers.se/~hallgren/Alfa/) All I can say is WOW, this thing is fun to play with, (and to think I have been doing my proofs with pencil and paper all these years). The interactive editor in particular I found quite enjoyable to use, I was wondering if someone has ever made or considered making a similar editor for haskell programs themselves? On first thought it seems that such a thing should not be too difficult as the type system of haskell is based on the same theories and haskell programs are similar to declarative proofs. It seems like an editor of that sort coupled with a class browser would be a powerful authoring tool.. (and this coming from a vi user :) ) The other thing that Alfa made me want to try out was programming with Fudgets. however as far as I can tell Fudgets has bit-rotted away... at least I have been unable to find a version which compiles with my prefered setup (ghc 4.08.1)... I was wondering if there is anyone working on bringing Fudgets up to date? There must be some setup that can compile it as Alfa still appears to be actively developed, From a lookover of the sources probably all that would need to be done is to replace the Xlib layer with one based on FFI so as to be portable to all the modern platforms and bring the code up to haskell98 compliance... perhaps somebody has already done this but it is not well publicised or is there some other reason Fudgets has not been developed recently like the existence of an accepted better GUI API? just some random thoughts.... John -- -------------------------------------------------------------- John Meacham http://www.ugcs.caltech.edu/~john/ California Institute of Technology, Alum. john(a)foo.net --------------------------------------------------------------

2 1

Re: List types
by Scott Turner 13 Nov '00

13 Nov '00

You could make a type like this: data C a b = Raw b | Cooked ( a -> C a b ) ap :: C a b -> a -> C a b ap (Cooked f) v = f v cook :: C a (a -> t) -> C a t cook (Cooked f) = Cooked g where g a = cook (f a) cook (Raw f) = Cooked g where g a = Raw (f a) foo x y z = x <= y && y <= z f3 = cook $ cook $ cook $ Raw foo test = f3 `ap` 1 `ap` 2 `ap` 3 Though you could do something similar with a list-based approach. -- Scott At 20:12 2000-11-12 -0800, you wrote: >I would like to be able to make a list that contains functions which take >arguments of a certain type 'a'. However I don't know how many 'a' >arguments there are. For example I'd like to be able to make a list of >f,g, and h. > >f::a->b >g::a->a->b >h::a->a->a->b >[f,g,h] > >I want to be able to curry the a's one at a time. -- Scott Turner p.turner(a)computer.org http://www.ma.ultranet.com/~pkturner

1 0

List types
by Eric Allen Wohlstadter 13 Nov '00

13 Nov '00

I would like to be able to make a list that contains functions which take arguments of a certain type 'a'. However I don't know how many 'a' arguments there are. For example I'd like to be able to make a list of f,g, and h. f::a->b g::a->a->b h::a->a->a->b [f,g,h] Now I could make a function l that takes a list of 'a'. l::[a]->b However, I want to be able to curry the a's one at a time. My solution so far is declare a type Element like this: data Element a b c d = One a | Two b | Three c | Four d and then I can make my list like this, [One f,Two g,Three h] This gets very ugly. Do you guys have any ideas? Eric Wohlstadter UCDavis Software Engineering

2 1

(no subject)
by Luciano Caixeta Moreira 25 Oct '00

25 Oct '00

unsubscribe luti(a)linkexpress.com.br

1 0

Re: Haskell Programming Environment
by C.Reinke 25 Oct '00

25 Oct '00

> One of the emacs modes for Haskell gives the type of the identifier > the cursor is in in the modeline. It does this by examining the type > signatures in the current file, and having the prelude type signatures > built-in. This is quite helpful, if incomplete, and fairly easy to > implement. Similar shortcuts are possible for other aspects, and might help to produce something useful within the constraints of an MSc project. Finding a reasonable compromise between producing something for an MSc and producing something that will remain in use and that others could build on later would be the first challenge, I think. Personally, I couldn't care less about yet another non-portable IDE demo bound to one specific, non-standard, smallish editor and one specific graphics library with one specific OS. It might get a small user base, but is likely to be out of date before it can grow to a functionality that could attract more users. But that's just my personal opinion.. The results of this survey and your own thoughts about what the specific issues in a Haskell Programming Environment might be, what functionality should be provided, and how, have a greater likelihood to be of lasting value. If you want to produce anything "real", you will want to reuse the language knowledge built into existing implementations. If you then want to remain portable, a good route would be to define an interface between the HPE and some Haskell implementation, specifying exactly which functionality the HPE would want to access, and how. Examples: - syntax-awareness. Experience with syntax-directed editors shows that users don't like to be locked into the syntax, they want some leeway for errors in intermediate stages. Also, many programmers don't want to drop their favourite, productive, proven and portable editor for the ones built into IDEs. Still, the editor should be aware of the syntax of the current language (those regular-expression-based syntax-highlighters are nothing but a stop-gap measure). Having a standard interface to the implementation's parser (where is the next subexpression? where is next enclosing context? where and what is the next syntax error?..). - scope&type awareness. A natural extension of the above with an interface to the implementation's symbol table (where is the binding occurence for this variable? what the type of this expression? what are the constructors/class instances for this type? which identifiers with which types are exported from this module?..) - other language-specific interactions. (evaluate current expression in current environment; browse module graph; browse class graph; compile&run; instrument for debugging;..) Have a look at the functionality provided in Hugs and try to define an interface that could support that functionality from within a standard editor, without being dependent on Hugs. There used to be an idea of having a more modular Haskell implementation with interfaces between all parts, including an interface between Hugs-like frontend and background compiler and runtime system (part of the Haskell Execution Platform, HEP;-). That got rescheduled to low priority, but might still be a useful starting point (http://www.haskell.org/ghc/docs/papers/hep.ps.gz) Of course, that would be only one side of a modular HPE. The other half would be to make sure that standard programmer editors (Emacs, VIM, ..) get the necessary stub functionality to make use of the interfaces. And finally, both Haskell implementers and Editor developers would need to be convinced to support those interfaces.. After that, implementing and adding functionality using the editor and implementation interfaces would be the lesser problem. The really good IDEs are either built on meta-programming and reflective facilities in the underlying programming language or integrated into one particular implementation. Trying to guess types and syntax is either a lot of work (duplicating what has gone into existing implementations) or just a hack. Claus

1 0

RE: Haskell Programming Environment
by Doug Ransom 25 Oct '00

25 Oct '00

I would like to be able to inspect the type of things easily by hovering my mouse over an expression. As a beginner, I find it hard sometimes to get types correct in Haskell since often variables are not declared as a specific type. > -----Original Message----- > From: Jan Skibinski [mailto:jans@numeric-quest.com] > Sent: Wednesday, October 25, 2000 1:28 AM > To: Pawel Kot > Cc: haskell-cafe(a)haskell.org > Subject: Re: Haskell Programming Environment > > > > > On Wed, 25 Oct 2000, =?ISO-8859-2?Q? Pawe=B3?= Kot wrote: > > > Hello, > > > > I'm writing my master thesis. Its subject is 'Haskell Programming > > Environment'. It is (or rather will be) an extended text > editor working in > > graphical (XFree86) environment designed for Haskell > programmers. It will be > > implemented using Fudgets library. > > I'm wondering what features would you like to find in such > environment. What > > should be neccessary, what would help, what would make > writing programs > > easier, etc. > > I have some concepts, but I would like to hear some > suggestions from you. > > A module/class/instance/library browser perhaps? > Acquiring its information from standard libraries > and other user defined directories? Extracting comments, > module comments, class comments, and implementation > details to present them in some consistent way? Supporting > incremental compilation, a'la hmake? With intelligent use of > colorization, or other useful hints for programmers, > for a start? Intelligent inspectors? > > In short - something that exists for ages in Smalltalk, > or in Eiffel development environment, but with Haskell's > extra capabilities, limitations and goals in view? > > I once did something of this sort for Java: > + Java browser for Xcoral editor - in C > + Bongo based class hierarchy browser - in Java > You can find more about it on our web pages. > > Jan > > > > > > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

4 3

Re: Haskell Programming Environment
by Adrian Hey 25 Oct '00

25 Oct '00

Hello, On Wed 25 Oct, Pawe³ Kot wrote: > I have some concepts, but I would like to hear some suggestions from you. How about being able to type check partially written modules? Carlos Camarao posted a link to an implementation of type system CT in Haskell.. http://www.dcc.ufmg.br/~camarao/CT/CTinH.tar.gz Of course you don't really want to use a different type sytem from that currently used by Haskell. I believe this system makes use of 'principal typings' to infer the types of free variables from the context they are used, so it can be used to type check incomplete modules/programs. I can't think why such a system should be incompatible with the current Haskell type system. It seems quite appropriate for an interactive development environment and should be able to give more intelligent error reports. Regards -- Adrian Hey

1 0

Re: Haskell Programming Environment
by Jan Skibinski 25 Oct '00

25 Oct '00

On Wed, 25 Oct 2000, =?ISO-8859-2?Q? Pawe=B3?= Kot wrote: > Hello, > > I'm writing my master thesis. Its subject is 'Haskell Programming > Environment'. It is (or rather will be) an extended text editor working in > graphical (XFree86) environment designed for Haskell programmers. It will be > implemented using Fudgets library. > I'm wondering what features would you like to find in such environment. What > should be neccessary, what would help, what would make writing programs > easier, etc. > I have some concepts, but I would like to hear some suggestions from you. A module/class/instance/library browser perhaps? Acquiring its information from standard libraries and other user defined directories? Extracting comments, module comments, class comments, and implementation details to present them in some consistent way? Supporting incremental compilation, a'la hmake? With intelligent use of colorization, or other useful hints for programmers, for a start? Intelligent inspectors? In short - something that exists for ages in Smalltalk, or in Eiffel development environment, but with Haskell's extra capabilities, limitations and goals in view? I once did something of this sort for Java: + Java browser for Xcoral editor - in C + Bongo based class hierarchy browser - in Java You can find more about it on our web pages. Jan

1 0

RE: Num class
by Tom Pledger 19 Oct '00

19 Oct '00

Mark P Jones writes: > [...] > > Defaulting only kicks in if (a) at least one class is numeric, and > (b) all classes are standard. [...] Defaulting was designed to > work in this way so that (i) it would catch and deal with the most > common problems occurring with numeric literals, and (ii) it would > not be used too often; defaulting is in general undesirable because > it can silently change the semantics. Again, defaulting is an > example of a compromise in the design of Haskell. Ideally, you'd > do without it all together, but if you went that way, you'd end up > having to write more type information in your programs. And again, > I don't suppose there is a universally satisfactory point on this > spectrum. A language extension for subtyping would be of some use there. For example, if Int is set up as a subtype of Integer, meaning that an Int value is acceptable anywhere an Integer value is expected (with the typechecker inserting the conversion code), the literal 42 can unambiguously be assigned the type Int. (This is a reprise of an airy suggestion I've posted before, hence the move to the haskell-cafe list. I'm still at the reading-about- related-work stage of doing something more thorough about it.) Regards, Tom

3 7