Hi

...

If you application will be only small you'll be faster using VBScript.

Or Python or Perl, or (probably, I'm not sure) Ruby. Or likely many others.

No, VBA only. VBA is integrated with Excel and can talk to all the Excel data structures, be developed inside the Excel program etc. It can be saved with a .xls file, install toolbar buttons etc. No other language can do that without painful hoop jumping. Thanks Neil

I hate to recommend Java to Haskellers, but there is a project named Poi at Apache's Jakarta site[1] that will allow you to (with some Java programming) read, write, and manipulate Excel files directly. You don't have to COM to Excel, you don't even need Excel installed! Nice for producing spreadsheets for download from a web-based app on the fly. It is complete enough to do formatting, formulas, and such, but you can see the ugly internals of the Microsoft file formats bleeding out, or at least that was true 4 years ago. Maybe it would be a nice project to create a Haskell version of Poi. --doug [1] http://jakarta.apache.org/poi/ On 4/19/07, Paul Moore wrote:

On 19/04/07, Marc Weber wrote:

...

There is only one library: hdirect. But I don't know its status there have been some posts and some authors may have chnaged it. I'd suggest grepping some mailinglist archives (you can find them all on haskell.org) or wait till someone else gives a more helpful reply ;)

I tried quite a while ago to build hdirect, and failed. It looked like it didn't quite support the then-current GHC (6.2???) As far as I can tell, the library hasn't been updated since, so I doubt there's much hope. I'd love to be proved wrong...

...

If you application will be only small you'll be faster using VBScript.

Or Python or Perl, or (probably, I'm not sure) Ruby. Or likely many others.

Sad, but true...

Paul. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Hi

...

I'm interested in automating Excel using Haskell. I'm writing a little program for my wife and it'd be nice to fill out an Excel spreadsheet for her (with formatting so I don't think CSV will cut it). A bit of Googling didn't turn up anything interesting.

Does she need to manipulate the spread sheet afterwards? If not, you'd be much better off producing an HTML table. You may also want to see exactly what Excel can do when reading in a formatted HTML table, it may give you CSV+formatting quite easily.

If you application will be only small you'll be faster using VBScript.

VBA, not VBScript. VB 6 is the standalone programming language, VBA is VB 6 with an API for Excel/Word/Office. VBScript is a scripting version of VB, which should never be used (use JScript instead - its more portable). And I would recommend using VBA, I've done loads of Excel programming - VBA is perfectly easy enough, the hard bit is the Excel API which is quite big. If you move to Haskell you get a slightly better programming language, with the same huge API, at the cost of a painful translation layer to the API. Thanks Neil

On Thu, Apr 19, 2007 at 08:59:17AM -0700, Justin Bailey wrote:

...

All, I'm interested in automating Excel using Haskell. I'm Has any work been done on using Excel (or more generally, COM) from Haskell?

There is only one library: hdirect.

No-one remembers Krasimir's hscom announcement? It was only back in Jan: http://www.mail-archive.com/haskell@haskell.org/msg19723.html http://darcs.haskell.org/packages/hscom/ It's not complete but maybe it does enough for your needs. Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

I've done things that are almost identical to what Neil suggests, and I've also done a lot of work on calling Haskell code from Excel via the Excel4 (XLL) API, but not so much work on calling COM from Haskell. It's all doable, but it's a lot of work. And the code I've written is proprietary, I'm afraid. -- Lennart On Apr 23, 2007, at 08:07 , Simon Peyton-Jones wrote:

Lennart Augustsson has quite a bit of experience in interface Haskell and Excel, although I’m not sure which “way”.

Simon

From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe- bounces@haskell.org] On Behalf Of Justin Bailey Sent: 19 April 2007 16:59 To: haskell-cafe@haskell.org Subject: [Haskell-cafe] COM and Haskell

All,

I'm interested in automating Excel using Haskell. I'm writing a little program for my wife and it'd be nice to fill out an Excel spreadsheet for her (with formatting so I don't think CSV will cut it). A bit of Googling didn't turn up anything interesting.

Has any work been done on using Excel (or more generally, COM) from Haskell?

Thanks for any pointers!

Justin

p.s. I'm aware of the article "Spreadsheet for Functional Programmers" article and Neil Mitchell's post about HsExcel - but those go the wrong way :(

On 4/23/07, Simon Peyton-Jones wrote:

I wonder what we (or someone else) could do to make it less work?

Even a 'cookbook' to explain what to do would be jolly useful.

Give me a way to get to the .NET libraries and the world is my oyster ... Based on my experience using .NET from Ruby (via the RubyCLR library by John Lam), having access to the .NET libraries allows you to get a lot of useful work done. Ruby, of course, is extremely flexible so working with .NET from it feels very natural, and John did a lot of work to make it that way. It's like he built an embedded DSL for interacting with .NET. I imagine the same could be done in Haskell, though it might involve some sort of code generation technique. Justin p.s. Mr. Lam is now working at Microsoft, FYI ...

Hello Andrew, Tuesday, April 24, 2007, 5:03:53 AM, you wrote:

A core difficulty is the mismatch between the object-oriented type system of .NET and Haskell's. This is something that RubyCLR didn't need to conquer, Ruby already having object-oriented concepts.

Simon Marlow recently wrote paper about handling dynamic exceptions - for me it seems that he described general system to mimic OOP in Haskell -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Andrew Appleyard wrote:

On 26/04/2007, at 12:12 am, Bulat Ziganshin wrote:

...

Simon Marlow recently wrote paper about handling dynamic exceptions - for me it seems that he described general system to mimic OOP in Haskell

I found the paper (titled 'An Extensible Dynamically-Typed Hierarchy of Exceptions'). The system described is not a complete OO mapping (it doesn't deal with method overloading, for example) however because it is a recent paper and the mapping is quite lightweight it could be useful to me.

The best reference I know of for how to do OO in Haskell is the Kiselyov/Lämmel OOHaskell paper: http://homepages.cwi.nl/~ralf/OOHaskell/. Quite often you don't need the full range of OO functionality to implement a particular abstraction, and in that case you can pick from the menu of techniques described in that paper. Extensible exceptions is one particular example of an OO-like abstraction. Cheers, Simon