- Haskell - Haskell.org

ANNOUNCE: A Haskell-CORBA interface
by Zoltan.2.Varga＠nokia.com 17 Oct '01

17 Oct '01

Dear All, I'm happy to announce the first release of my Haskell-CORBA interface package, which is available from: http://sourceforge.net/projects/haskell-corba/ This package allows Haskell programmers to write CORBA clients and servers using the MICO open-source CORBA implementation (www.mico.org) It defines a Haskell language mapping for CORBA, and includes an IDL compiler which generates Haskell stub and skeleton modules from IDL files. Comments and suggestions are welcome Zoltan

1 0

ANNOUNCE: popenhs-0.00 released
by Jens-Ulrik Petersen 17 Oct '01

17 Oct '01

I am happy to announce the first release of popenhs, version 0.00. popenhs is a very small Haskell library, based on runProcess in hslibs' posix library. It provides lazy output from subprocesses through two functions popen2 and popen3. The source and rpm files are available from: http://www.01.246.ne.jp/~juhp/haskell/popenhs/ I welcome comments and feedback. Jens

1 0

Re: Haskell 98 - Standard Prelude - Floating Class
by Marcin 'Qrczak' Kowalczyk 16 Oct '01

16 Oct '01

Tue, 16 Oct 2001 15:29:36 +1000, Fergus Henderson <fjh(a)cs.mu.oz.au> pisze: > Not giving a default definition is *not* the same as giving a default > definition that calls "error". It's significantly safer. The difference > is that the former makes it much easier for compilers to issue warnings > when you forget to define a class method in an instance declaration. There are no warnings when default definitions are expressed in terms of themselves such that when no explicit definition is present, they will diverge. In practice this is analogous to not having a definition at all. But the compiler sees this as if they had a good definition. If we are serious about ensuring that definitions are not omitted, we should handle this case too. It can be done with a pragma which tells the compiler and a programmer who wants to make instances what are possible sets of methods to be provided by instances (in terms of conjunctions and alternatives). This is often already specified in comments. An optimizing compiler could detect most of such "incomplete" instances itself, with the help of strictness analysis. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

Re: Standard Prelude - Floating Class
by George Russell 16 Oct '01

16 Oct '01

I wrote > I'm afraid that I have very little faith in the numerical analysis > expertise of the typical Haskell implementor, so I think it is dangerous > to give them an incorrect "default" implementation. I am reminded of > the notorious ASCII C (very)-pseudo-random number generator . . . Dylan wrote > > I don't think it's worth worrying about much. I wrote > This is a good argument for leaving things as they are. Jerzy Karczmarczuk wrote > Absolutely NO. Unless you don't care at all about the potential scientific > users of the language. Leaving the details which are of utmost importance for > professional applications is killing the language. Most readers of this forum > are very far away from numerics, and this is normal. But languages live through > their libraries. At least 4 times a year somebody on this list complains about > lack of such a support even if the actual libraries are already quite > impressive. The potential scientific users of the language are not going to be well served if the language includes *incorrect* implementations of mathematical functions. This is my point. > > So, I would encourage to organize one day a group - not necessarily a "task > force" > like the GUI people - of people who would test all the numerics, and at least > give to the freshmen some implementation prototypes, e.g. Padés for small > arguments > of sinh, etc Yes, in the ideal world, we would form a group of numerically-knowledgable Haskell people who would test things out properly. Well, perhaps. I would like to be on this group. I at least know what a Pad'e approximation is, and perhaps I could even remember how you find them. I have implemented sinh properly in ML based on the netlib specification. Still, I am not a numerical analyst, and I am not sure we are going to be able to find it easy to assemble a group of numerical analysts willing to give time to define the transcendental functions properly. I also doubt if this is going to be possible. At the moment for example, Haskell cannot even require IEEE arithmetic, because virtually no platform supports it completely. (Intel has too much precision which needs to be artificially clobbered if we want IEEE, Alpha doesn't do underflows properly unless you are very careful with inserting traps to fix things up.) So getting a standard which specifies exactly what Haskell transcendental functions should do (be accurate within 0.8ULP for example, though when you think about it that is horrendously complicated to guarantee in some instances . . .) is going to be tricky, to say the least. > > And what is this: "typical Haskell implementor"? Do you know many of them? Do > you > think really that some fellow totally inconscious in the domain of STANDARD > numeric > maths, somebody who never heard about IEEE etc. will NOW engage in implementing > Haskell? What is the rationale behind your little faith, Man of Little Faith? I think numerical analysis is a prime example of "A little learning is a dangerous thing". I think I would like a Haskell implementor to be either totally ignorant of numerical analysis, and simply call out to C routines written by an expert, such as the excellent ones available at netlib. Or else a Haskell implementor should be a skilled numerical analyst. Unfortunately expecting writers of functional compilers to be an s.n.a. seems to me rather like expecting them to be brain surgeons; it just isn't so. On the other hand, they have enough mathematical learning to know about sinh(x)=(exp(x)-exp(-x))/2, so they erroneously introduce it into their code, having forgotten whatever they learnt in bright college days about never subtracting two nearly-equal floating-point numbers. Standard ML/NJ and Microsoft Excel (when I tested it a couple of years ago) both get sinh wrong, so I think my pessimism is well-grounded. Incidentally, another fruitful example of ALLIADT is random number generators. I have yet to see a language standard which defined a random number generator which wasn't completely pathetic.

1 0

RE: Haskell 98 - Standard Prelude - Floating Class
by George Russell 16 Oct '01

16 Oct '01

Simon PJ wrote: > Fpr the Revised Haskell 98 report, Russell O'Connor suggests: > =20 > | Also, I understand you are reluctant to make library changes,=20 > | but sinh and cosh can easily be defined in terms of exp > |=20 > | sinh x =3D (exp(x) - exp(-x))/2 > | cosh x =3D (exp(x) + exp(-x))/2 > |=20 > | (source: Calculus Third Edition by Michael Spivak, page 349,=20 > | or any decent calculus book) > |=20 > | I suggest removing sinh and cosh from the minimal complete=20 > | definition, and add the above defaults. > > This looks pretty reasonable to me. We should have default methods > for anything we can. > > Comments? No. As has been pointed out, this is a bad idea numerically because it will give the wrong answer for sinh x for very small values of x. As a matter of fact, you will also get the wrong answer for very large values of x, where exp(x) can overflow even though sinh x and cosh x don't, meaning you get an incorrect answer of positive infinity. I suggest saying as little about the transcendental functions as possible, rather than forcing incorrect rules on the implementor. I imagine most Haskell implementors do not want to waste time writing their own transcendental function routines, but simply call out to one of the various high-quality C implementations. (Netlib has a good free one, for example.) This will probably produce better results than suggesting buggy code to the implementor. Technically, you would probably be able to define all the functions sinh/cosh/tanh/exp functions with reasonable precision in terms of expm1, defined mathematically as expm1(x) = exp(x) - 1. But please don't . . .

4 4

RE: Harmful spammers
by Simon Marlow 16 Oct '01

16 Oct '01

> There are a couple things to do that can at least cut down on spam. > > 1) Make sure that your mail gateway, or (in this case) the mailing > list host is not an open relay site. It isn't. > 2) Every time you get spam, locate all the hosts it came through > in the header. Or alternatively just report it using Spamcop (http://spamcop.net) or some other reporting tool. Life is just too short to do this by hand every time you get spam. On the Haskell mailing list we have a good compromise at the moment: the mailing list software's auto-filtering catches most of the spam (not allowing Bcc's to the list is a good one), and for any spam that gets through I just add it to the list of disallowed addresses. I asked recently if we should move to allowing subscriber-only posting, and I got a small number of responses, which were split roughly 50/50 so no action was taken. Cheers, Simon

2 1

RE: Haskell 98 - Standard Prelude - Floating Class
by Lennart Augustsson 15 Oct '01

15 Oct '01

> | sinh x = (exp(x) - exp(-x))/2 > | cosh x = (exp(x) + exp(-x))/2 ... > This looks pretty reasonable to me. We should have default methods > for anything we can. Why not provide defaults for the inverse functions as well? asinh x = log (x + sqrt (1+x*x)) acosh x = log (x + (x+1) * sqrt ((x-1)/(x+1))) atanh x = log ((x+1) / sqrt (1 - x*x)) -- Lennart

2 1

RE: Haskell 98 - Standard Prelude - Floating Class
by Simon Peyton-Jones 15 Oct '01

15 Oct '01

Fpr the Revised Haskell 98 report, Russell O'Connor suggests: | Also, I understand you are reluctant to make library changes, | but sinh and cosh can easily be defined in terms of exp | | sinh x = (exp(x) - exp(-x))/2 | cosh x = (exp(x) + exp(-x))/2 | | (source: Calculus Third Edition by Michael Spivak, page 349, | or any decent calculus book) | | I suggest removing sinh and cosh from the minimal complete | definition, and add the above defaults. This looks pretty reasonable to me. We should have default methods for anything we can. Comments? Simon

3 2

Re: Haskell 98 - Standard Prelude - Floating Class
by Lennart Augustsson 15 Oct '01

15 Oct '01

> 2. So, they hold for the Complex numbers as well. The gymnastics with > complex sinh and cosh seems to be redundant. Well, I would be a little careful changing these. Some of the definitions in numerical part of the Prelude look more convoluted than they need to be, but it's because they have better numerical properties. I know Joe Fasel spent a lot of work on getting definitions that are numerically well behaved. But we should definitely have the "default definitions" for sinh and cosh. Any decent implementation will of course override these for speed and accuracy. -- Lennart

1 0

Re: bracket_
by Marcin 'Qrczak' Kowalczyk 15 Oct '01

15 Oct '01

Sun, 14 Oct 2001 23:25:40 -0400, Ken Shan <ken(a)digitas.harvard.edu> pisze: > In Haskell's standard IO module, bracket_ is defined to have type > > IO a -> (a -> IO b) -> IO c -> IO c > > However, in the Exception module in hslibs, bracket_ has type > > IO a -> IO b -> IO c -> IO c > > which IMHO is much less useful, not to mention confusing. Why less useful? There is already bracket which provides the value produced by initialization. IMHO Exception.bracket_ is more useful when there is really no initialization, only closing. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0