February 2004 - Haskell

Re: [Haskell] KDevelop & Haskell
by Peter Robinson 15 Feb '04

15 Feb '04

Hi, my intention when writing the Haskell Plugin for KDevelop was mainly to increase the language's publicity, since KDevelop 3.0 is the most popular and mature IDE for Linux/Unix. I know that most of you prefer to use your favourite editor but the real audience are the C/C++/Java/Php/Python/SQL/... programmers who probably haven't heard much about Haskell yet and would like to give it a try. Things like a background parser that checks the syntax continuously can be implemented quite straightforward in KDevelop as soon as i've got a working C++ parser for Haskell. Syntax highlighting is provided by the Kate Plugin. A better integration of Hugs or GHCi is possible (via plugins). At the moment only the GHC plugin that allows the user to build and run the files in the project is implemented. regards, Peter --------- Original Message ----------- From: Gour Subject: Re: [Haskell] KDevelop & Haskell Date: Tue, 27 Jan 2004 02:26:43 -0800 Claus Reinke ([EMAIL PROTECTED]) wrote: > that's why it would be nice if the supported Haskell implementations > we have would also offer the necessary API on top of which such > enhanced IDE functionality could be implemented in everyone's > editors of choice. > > >> But I saw that haskell is in the the table of supported languages. > > > >yes, and it is nice to see it advertised this way, but I just checked, > >and the support seems to be in its very early stages: > >But, it's better than nothing :-) > > >it won't do everything (unless you do a little programming, or we get >> those APIs I keep mumbling about), but it will do a lot. >>Do you have some pointer for discussion(s) about these APIs you're mumbling >>about? >> set your editor as specified, start Hugs, type ":find foldl", enjoy. >> for extra marks, make your editor call out to Hugs, load the current >> module, and :find the identifier under the cursor. (or were you >> suggesting that most Hugs users are already aware of this >> feature and use it every day?) >At the moment (6th ch. of Thompson's Craft of FP) I'm still with Helium :-) >but otherwise I was/am using ghc to compile e.g. darcs and other Haskell >stuff. > > This one is nice. Thank you. > > why, thank you!-) >At the moment I'm compiling HaRE under MSYS/MinGW environment. Where can I >report back? > >Have you (maybe) tried KDevelop with kvim? > > no, I was thinking of the recent Haskell-in-Haskell frontends, and > of Simon M's work on providing an API for ghc to support a > visual studio binding. The frontends, or the API once it has evolved, > are just what one needs to provide programmers editors with > Haskell-awareness. > > http://www.haskell.org/communities/11-2003/html/report.html#sect5.2.3.1 > http://www.haskell.org/communities/11-2003/html/report.html#sect5.3.3 > http://www.haskell.org/communities/11-2003/html/report.html#sect6.5.5 Wow! It looks great. I definitely have to find out some more time in pursuing my learning of Haskell, since there is interesting development going on. (recently I've found few posts on Ruby list with the complain that "but ultimately lost interest because the discussions focused on a /much/ higher level than they do here on the Ruby list--arguments over language design, etc., with few mentions of using Haskell to do anything productive.", so I hope that something like Programatica Project can drastically change the situation and bring Haskell more tho the mainstream (despite the fact if this is the intention of the whole project :-) Thank you for enlighetning me about Programmatica. Sincerely, Gour

2 4

non-ASCII characters in Haddock documentation
by Wolfgang Jeltsch 15 Feb '04

15 Feb '04

Hello, how do I insert non-ASCII and maybe even non-Latin-1 characters in Haddock documentation? Wolfgang

3 5

Re: Making a spreadsheet with Haskell (S.J.Thompson)
by Lloyd Allison 15 Feb '04

15 Feb '04

I am looking at running Haskell code from within gnumeric, the opensource spreadsheet -- it's good. Gnumeric is written in C, using those "autogen" etc. tools, and has quite a nice plugin mechanism, but it does rather rely on whatever compiler is used for the plugin to produce a shared object, which ghc does not do. After much effort, a local guru did manage to "persuade" gnumeric to call a H98 hello-world kind of function but it wasn't easy or pretty. Is there any H98 compiler that can produce a shared object? And out of interest, what is the particular difficulty with ghc? Since it does go through C(?), of sorts, I'd have naively thought it would be possible (of course you get what you pay for, so you can't complain). -L -- > ... > Message: 6 > Date: Sat, 14 Feb 2004 10:28:34 +0000 > From: "S.J.Thompson" <S.J.Thompson(a)kent.ac.uk> > Subject: Re: [Haskell] Making a spreadsheet with Haskell > To: lisper(a)it.kth.se, mcob(a)hps.es > Cc: haskell(a)haskell.org > Message-ID: <E1Arx2I-0002Hx-00(a)myrtle.ukc.ac.uk> > > You could take a look at Vital > http://www.cs.kent.ac.uk/projects/vital/ > >From the web page: > Vital is a visual programming environment based on Haskell, a > contemporary functional programming language. It is particularly > intended for supporting the open-ended, incremental style of > development often preferred by end users (engineers, scientists, > analysts, etc.). It may also be useful for teaching Haskell. > Simon > ... > > etc.

1 0

hs2lhs
by Stenio 14 Feb '04

14 Feb '04

3 2

Re: [Haskell] Making a spreadsheet with Haskell
by S.J.Thompson 14 Feb '04

14 Feb '04

You could take a look at Vital http://www.cs.kent.ac.uk/projects/vital/ >From the web page: Vital is a visual programming environment based on Haskell, a contemporary functional programming language. It is particularly intended for supporting the open-ended, incremental style of development often preferred by end users (engineers, scientists, analysts, etc.). It may also be useful for teaching Haskell. Simon

1 0

GHC Core & backend
by Arjan van IJzendoorn 14 Feb '04

14 Feb '04

Hello all, Is anybody using GHC's backend as a backend for their own compiler? In the paper "An external representation for the GHC Core Language" the introduction states that "there are many (undocumented) idiosyncracies in the way GHC produces Core from source Haskell". And that "it will be hard to produced Core that can be integrated with GHC-produced core, and we don't aim to support this". Has this changed since the time of writing this paper? It would be cool if, let's say, Helium (http://www.cs.uu.nl/helium) could use all of GHC's libraries... Regards, Arjan van IJzendoorn

2 1

Making a spreadsheet with Haskell
by Miren Cob Isasi de Virgala 13 Feb '04

13 Feb '04

> Hi, I would like to know how can I make a spreadsheet using Haskell > (something like Excel, a very-reduced version, of course) > Do I need any kind of special library? How can I make the interface so the > user can introduce data, select data and so on? > > Thanks for your help. > Miren Cob Isasi de Vírgala >

3 2

Website redesign
by John Peterson 13 Feb '04

13 Feb '04

So there it was - another email message complaining about something on haskell.org. "Your site is so `last century'". So I, as usual, said "If you want it fixed, do it yourself". And thus the new look on haskell.org. Thanks much to Jon Lingard for giving us a facelift. The new look (same old content) is very professional. John

1 0

RE: [Haskell] GHC 64bit?
by Simon Marlow 13 Feb '04

13 Feb '04

> Dell's poweredge server with the max 12gb RAM costs $15k. > Moore's law says that > 1. you only need an extra bit/year. > 2. processing that extra bit will cost 50% less next year > > Though perhaps processing time is not linear with > the number of bits for historical/architectural > reasons....? > > I presume that, if we are conservative in the > number of bits we use then we don't run into the > ptr driven storage problem that Axel described. > > In particular, if we need only 2 or 4 times as > much memory, we should only grow pointers by 1 or > 2 bits...rather than growing immediately all the > way to 64... > > Perhaps there could be a command line option to > specify desired ptr size. I assume it is > impossible to adjust pointer size dynamically at > runtime depending on memory consumption (I > assume you would do it at garbage collection time > if it were possible). Using pointers of a size other than the machine's native word size should be possible. We experimented recently with adding tag bits to pointers, and in the process discovered all the places where you would need to convert between "abstract" pointers and real pointers, which are the same places you would need to modify if you were to use some kind of compressed representation for pointers. Cheers, Simon

1 0

RE: [Haskell] GHC 64bit?
by Simon Marlow 13 Feb '04

13 Feb '04

> alex: > > Is there a maximum memory GHC can use/reach? > > Specifically, can GHC address more than 4gb of > > memory? > > SimonM may want to comment, but at the moment I think GHC is > limited to > 4G, but only due to lack of 64bit machines/demand on the developers. > > If you look in ghc/rts/MBlock.h you'll see some references to this. > > I *think* it would be easy to overcome this limit. > > (this should really be on glasgow-haskell-users) In principle, there's no problem. In practice, GHC's storage manager needs a (fast) function of type Ptr a -> Bool to indicate whether a particular address is part of the dynamic heap or not. This is currently implemented as a bytemap, which is 4k long on a 32-bit machine. To cover the whole of a 64-bit address space, this method isn't practical. Nevertheless, we can extend the bytemap to cover a lot more real memory, as long as we have a way to map from virtual memory addresses to elements of the bytemap - this is the tricky bit. So far we haven't tackled this problem in a general way. Cheers, Simon

2 1