Re: Haskell 98 - Standard Prelude - Floating Class

[Fergus Henderson]

On 15-Oct-2001, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
> 
> The proposal is only to give "default declarations"
> in the class defn for sinh, cosh, and perhaps as Lennart suggests
> asinh, acosh, atanh. They give a reasonable first cut if you
> don't write definitions yourself.  But you can overrride them at will.
> The only reason not to do this (which amounts to giving a default
> decl of "error") is if the default decl is so awful that it's badly
> misleading to provide it.  Which doesn't look true in this case.

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.
With the latter, compilers can't issue such warnings without getting
too many false positives.

The whole idea of letting you omit method definitions for methods with
no default and having calls to such methods be run-time errors is IMHO
exceedingly odd in a supposedly strongly typed language, and IMHO ought
to be reconsidered in the next major revision of Haskell.

-- 
Fergus Henderson <[EMAIL PROTECTED]>  | "... it seems to me that 15 years of
The University of Melbourne | email is plenty for one lifetime."
WWW:   | -- Prof. Donald E. Knuth

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: Harmful spammers

[Andre W B Furtado]

> 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.

CAUCE (The Coalition Against Unsolicited Commercial Email) seems to me a
nice alternative. Check www.cauce.org.

> 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.

I think moving the list to allowing subscriber-only posting may cause some
trouble to the subscribers too... (now there isn't a 50/50 split anymore
)  )

Andre W B Furtado
Recife - Brazil
www.cin.ufpe.br/~haskell/hopengl/


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Haskell Communities Survey - Second Call for Contributions

[C.Reinke]

Dear Haskellers,

after the first rush of volunteers seems to have ebbed away, it is
probably time for a reminder. First, the good news:

We have just about enough topics covered to convince me that it makes
sense to go ahead. So the Haskell Communities page has moved to a more
permanent location at

  http://www.haskell.org/communities/

and any further documents will appear there as well.

I even have the first reports coming in already (thanks very much!).
If everyone else could please send in their reports over the next two
weeks, i.e., before

  *** Monday, 29. October 2001 ***,

then I could try to edit everything together in the following week
(modulo my own deadlines..) and put out the first version of the
collective Haskell Communities Status Report early in November.

Simon Marlow sent a nice example of a (more frequent) report from the
FreeBSD community, which might give an idea of how a collection of
brief summaries can help to get and keep an overview of a field:

  http://www.geocrawler.com/archives/3/159/2001/9/150/6646127/

So far, so good. The not so good news is that there are still some
quite important areas uncovered, so 

  *** we are still looking for active Haskellers ***
  *** to write (and send to me) brief summaries. ***

Below, you'll find first a list of topics I would like to see covered,
then the list of topics for which we already have volunteers.

If you think you can help out with information on one or more of the
outstanding topics, please let me know. If you have the information,
but are unsure about what would be a useful summary for the report, 
get in touch with me and we'll see what we can do.

Cheers,
Claus

 contacts still needed:

 core

* Haskell Central
  changes over the last year, plans for the next few months?

* Hugs
  often feared to be dying, but kept very much alive by enthusiasts;
  Currently, OGI and other enthusiastic volunteers are supporting.
  Any ideas about the future? What about the new release (when, what)?

* nhc98
  lots of new work there, though much of it will probably
  be covered by Olaf's report on tracing and debugging?

!! for all implementations, it would be nice to know the
!! position and status regarding recent extensions that 
!! need support to be portable, such as FFI, hierarchical 
!! modules namespace, portable libraries, GUI API & libraries.

 others

* non-sequential Haskell
  This is an important and active area, and we seem to have lots
  of projects there. Ideally, someone in the field could give an
  overview of the state-of-the-art, but I would also be happy to
  get summaries from individual projects (we've got Concurrent
  Haskell, but nothing else yet; what about GPH, port-based 
  distributed Haskell, ..?).

  [and why is there no dedicated mailing-list for the collection
   of non-sequential Haskell projects?]

* meta programming support for Haskell
  Tim Sheard would like to start a project on a Haskell version of
  Meta ML. Any progress there? Meanwhile, there are a small number of
  Haskell parsers and pretty-printers around. But how complete are
  they, are they being kept up to date, what about language extensions?
  What about a standard AST format?  What about static analysis and
  type checking/inference? A standard interface to symbol table
  information? Partial evaluation for Haskell?-) 

  Reification/reflection (Bernard Pope and Lee Naish have done some
  work here in the context of declarative debugging)?  

  Why all the extra tools, btw? Could we not have a standard interface
  to the parsers, type checkers, symbol tables that exist in our
  Haskell implementations (as is the case for other respectable 
  languages?-)

* lightweight modules for Haskell
  At this year's Haskell workshop, Mark Shields asked those interested
  to cooperate on this topic to contact him, mentioning that he was
  working on the topic. It would be useful to have an idea of the plans
  there.  Aha, I've just found a brand new paper on that, perhaps Mark 
  could give a brief summary of that and the implementation plans?-)

* Haskell libraries collection
  will that be covered in the report on hierarchical module
  namespaces or do we need a separate report? Simon?

* FFI tools
  Manuel will cover FFI language extensions and libraries,
  as well as his own C->Haskell, but what about the other tools 
  built on top of the FFI basis? What is the status of Greencard,
  Hdirect & co? What about all that recent talk about new Haskell
  to Java connections?-) 

  If anything is still (or newly) active: summaries&pointers, please!

* Documentation tools
  earlier this year, there was some work and discussion on this.
  Anyone willing to summarise the results?

* Applications
  Perhaps someone at Galois Connections could summarise their
  recent successes and immediate plans (I've heard lots of good
  news from that direction recently)?

  Haskell in hardware specification 

Re: Haskell 98 - Standard Prelude - Floating Class

[George Russell]

Dylan Thurston wrote:
[snip]
> > 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.
> 
> Err, what?  Surely sinh x is at least 1/2 of exp x, leaving only a
> very narrow range for this to happen.  Behaviour of sinh x near 0 is
> more important, unless I'm missing something?
If we are planning to introduce bugs into the Haskell standard, I am not
going to argue about which bug is more important than which other bug. 
Personally I think we should avoid all bugs.
> 
> > I suggest saying as little about the transcendental functions as
> > possible, rather than forcing incorrect rules on the implementor.
> 
> The suggestions are for default methods, which force nothing on
> anybody.  They would be suggestions, in case anyone writes their own
> instances of these classes; the question should be whether they are
> useful suggestions.  For instance, if you have a class of computable
> reals (increasingly good approximations), the default definitions of
> sinh and cosh are excellent.
I would like to see such an implementation.  The definition of sinh/cosh
requires the number to be an instance of Floating, which requires
Fractional, which requires Num, which requires Eq.  Testing equality for
computable reals is equivalent to solving the Turing Halting Problem, which
would have wide-ranging applications for computer science . . .

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 . . . 
> 
> I don't think it's worth worrying about much.
This is a good argument for leaving things as they are.
[snip]

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: Haskell 98 - Standard Prelude - Floating Class

[Dylan Thurston]

On Mon, Oct 15, 2001 at 06:27:52PM +0200, George Russell wrote:
> 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.

Err, what?  Surely sinh x is at least 1/2 of exp x, leaving only a
very narrow range for this to happen.  Behaviour of sinh x near 0 is
more important, unless I'm missing something?

> I suggest saying as little about the transcendental functions as
> possible, rather than forcing incorrect rules on the implementor.

The suggestions are for default methods, which force nothing on
anybody.  They would be suggestions, in case anyone writes their own
instances of these classes; the question should be whether they are
useful suggestions.  For instance, if you have a class of computable
reals (increasingly good approximations), the default definitions of
sinh and cosh are excellent.

I don't think it's worth worrying about much.

(They don't work for floating point numbers because of the special
behaviour near 0.)

Best,
Dylan Thurston

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Haskell 98 - Standard Prelude - Floating Class

[George Russell]

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 . . .

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RTA 2002 Call for papers

[Pierre Lescanne]

  CALL FOR PAPERS

 RTA 2002

 13th International Conference on Rewriting Techniques and Applications

July 22--24, Copenhagen, Denmark
   
as part of FLoC'02 (http://floc02.diku.dk)
 


TOPICS:

RTA is the major forum for the presentation of research on all aspects
of rewriting. The 13th International Conference on Rewriting Techniques
and Applications solicits original papers on theoretical and practical
topics related to rewriting in a broad sense. 
Suggested, but not exclusive, topics include:


* Applications: case studies; rule-based programming; symbolic and
  algebraic computation; theorem proving; functional and logic
  programming; proof checking.

* Foundations: matching and unification; completion techniques;
  strategies; constraint solving; explicit substitutions; tree automata.

* Frameworks: string, term, and graph rewriting; lambda-calculus and
  higher-order rewriting; conditional rewriting; constrained rewriting and deduction; 
proof nets;
  categorical and infinitary rewriting.

* Implementation: compilation techniques; parallel execution; rewriting
  tools.

* Semantics: equational logic; rewriting logic.

 
INVITED SPEAKERS

  Franz Baader (RWTH Aachen, Germany )
  John Mitchell (Stanford, USA) 
  Natarajan Shankar (SRI, USA) (joint FME-LICS-RTA) 


SUBMISSIONS:

Submissions must be original and not submitted for publication
elsewhere. Submissions should fall into one of the following categories:

1. Regular research papers describing new results; they will be judged
   on correctness and significance.

2. Papers describing the experience of applying rewriting techniques in
   other areas; they will be judged on relevance and comparison with
   other approaches.

3. Problem sets that provide realistic and interesting challenges in
   the field of rewriting.

4. System descriptions; they should contain a link to a working system
   and will be judged on usefulness and design.

Submissions in the first three categories can be up to 15 proceedings pages 
long, system descriptions 4 proceedings pages. Authors are strongly encouraged 
to use LaTeX2e and the Springer llncs class file, available at
http://www.springer.de/comp/lncs/authors.html. The title page should
include the submission category. Submission is by email: Send a
self-contained postscript file and  an ASCII version of the paper's cover
 page (title, authors, submission category, abstract, contact information) to

 [EMAIL PROTECTED]  

 
 

CONFERENCE CHAIR:

Thomas Arts
Ericsson 
Computer Science Laboratory   
Box 1505
125 25 Alvsjo 
SWEDEN 
<[EMAIL PROTECTED]>

PROGRAM CHAIR:

Sophie Tison 
LIFL   
Université de Lille I   
Cité Scientifique -- Bat.M3  
59655 Villeneuve d'Ascq Cedex  
France 
<[EMAIL PROTECTED]>


PROGRAM COMMITTEE:

Andrea Corradini (Pisa) Daniel J. Dougherty (Wesleyan University)
Jürgen Giesl (Aachen)   Bernhard Gramlich (Wien) 
Thérèse Hardin (Paris)  Christopher Lynch (Postdam) 
Jerzy  Marcinkowski (Wroclaw)   Aart  Middeldorp (Tsukuba) 
 
Joachim Niehren (Saarbrucken)   Femke van Raamsdonk (Amsterdam)  
Albert  Rubio (Barcelona)   Sophie Tison (Lille) 
Ralf Treinen   (Paris-Sud)  
 
BEST PAPER AWARD:

A prize of 500 EUR will be given to the best paper as judged by the
program committee. The program committee may decline to make the award
or may split it among several papers.


IMPORTANT DATES:

Submission: January 15,  2002
Notification:   March 22, 2002
Final Version:  April 25, 2002

RTA 2002 WEB SITE:

http://www.ericsson.com/cslab/rta2002/



PostScript version: http://www.ens-lyon.fr/~plescann/CONTRIBUTIONS/RTA_2002.ps

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Haskell 98 - Standard Prelude - Floating Class

[Lennart Augustsson]

> That's a good idea too.
> Is there a reason for defining acosh as above instead of
> acosh x = log(x + sqrt(x*x-1))
If there is one I can't remember it. :-)

-- Lennart

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Haskell 98 - Standard Prelude - Floating Class

[roconnor]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, 15 Oct 2001, Lennart Augustsson wrote:

> 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))

That's a good idea too.
Is there a reason for defining acosh as above instead of

acosh x = log(x + sqrt(x*x-1))

- -- 
Russell O'Connor[EMAIL PROTECTED]
   
``This is not a time, as it is never a time, to seek vengeance, but a
time to seek the courage to forgive'' -- George W. Bush
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (SunOS)
Comment: For info see http://www.gnupg.org

iD8DBQE7yv8aZG3em5NXM14RAqO2AJ4hsVYSbtFYgDmjturcQOr/AUbH0ACfTYKw
IZA2w18pSxdMAvZrLPoOJLM=
=+Pkw
-END PGP SIGNATURE-


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Haskell 98 - Standard Prelude - Floating Class

[Simon Peyton-Jones]

| > 1. Actually, I wouldn't even call that "default 
| definitions". These ARE
| >definitions of sinh and cosh.
| 
| Mathematically, yes.  Numerically, no.  Even if 'exp' is 
| implemented with high accuracy, the suggested defaults may 
| return a very inaccurate (in ulps) result.  Take sinh near 
| zero.  sinh(x) with x very close to 0 should return x.  With 
| the above 'default' sinh(x) will return exactly 0 for a 
| relatively wide interval around 0, which is the wrong result 
| except for 0 itself.

Indeed.  The proposal is only to give "default declarations"
in the class defn for sinh, cosh, and perhaps as Lennart suggests
asinh, acosh, atanh. They give a reasonable first cut if you
don't write definitions yourself.  But you can overrride them at will.
The only reason not to do this (which amounts to giving a default
decl of "error") is if the default decl is so awful that it's badly
misleading
to provide it.  Which doesn't look true in this case.

I don't propose to change any of the actual instance declarations,
because (as Lennart says) it's entirely possible that they have better
numerical properties than the default declarations.

Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: Haskell 98 - Standard Prelude - Floating Class

[Kent Karlsson]

- Original Message - 
From: "Jerzy Karczmarczuk" <[EMAIL PROTECTED]>
...
> Simon Peyton-Jones:
> > 
> > Russell O'Connor suggests:
> 
> > | 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
> 
> > | 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?
> 
> Three.
> 
> 1. Actually, I wouldn't even call that "default definitions". These ARE
>definitions of sinh and cosh.

Mathematically, yes.  Numerically, no.  Even if 'exp' is implemented
with high accuracy, the suggested defaults may return a very inaccurate
(in ulps) result.  Take sinh near zero.  sinh(x) with x very close to 0 should
return x.  With the above 'default' sinh(x) will return exactly 0 for a relatively
wide interval around 0, which is the wrong result except for 0 itself.

In general, this is why LIA-2 (Language Independent Arithmetic, part 2,
"Elementary numerical functions", ISO/IEC 10967-2:2001) rarely attempts to
define one numerical operation in terms of other numerical operations.  That
is done only when the relationship is exact (even if the operations themselves
are inexact).  That is not the case for the abovementioned operations. But
it is the case for the relationship between the complex sin operation and the
complex sinh operation, for instance. (Complex will be covered by LIA-3.)

Kind regards
/Kent Karlsson



___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Haskell 98 - Standard Prelude - Floating Class

[Lennart Augustsson]

> | 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

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: Haskell 98 - Standard Prelude - Floating Class

[Lennart Augustsson]

> 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

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: Haskell 98 - Standard Prelude - Floating Class

[Jerzy Karczmarczuk]

Simon Peyton-Jones:
> 
> Russell O'Connor suggests:

> | 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

> | 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?

Three.

1. Actually, I wouldn't even call that "default definitions". These ARE
   definitions of sinh and cosh.

2. So, they hold for the Complex numbers as well. The gymnastics with
   complex sinh and cosh seems to be redundant.

3. The above code is less than useful for a person who
   really needs it. I would propose rather the most obvious

   sinh x = (u-recip u)/2 where u=exp x

   etc.

Jerzy Karczmarczuk

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: bracket_

[Marcin 'Qrczak' Kowalczyk]

Sun, 14 Oct 2001 23:25:40 -0400, Ken Shan <[EMAIL PROTECTED]> 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 * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^  SYGNATURA ZASTÊPCZA
QRCZAK


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Haskell 98 - Standard Prelude - Floating Class

[Simon Peyton-Jones]

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

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: let-floating

[Simon Peyton-Jones]

| Is there a compiler (which version?) that optimizes qsort1 to 
| (essentially) qsort2 ?
| 
| Any hints concerning the possibility/impossibility of this 
| would be helpful. Thanks and regards, Janis.

Alas, (still) not yet.  As you say, the transformation depends
on spotting a one-shot lambda, and our plan was to use
Keith Wansbrough's usage-type work to do that.  But Keith
has another job, and is busy writing up his thesis.  I'm still
hoping to get his stuff into GHC though, but it's not imminent.

A possible stop-gap would be a simpler analysis to catch
common cases like the one you give.  Any volunteers?  

Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Harmful spammers

[Simon Marlow]

> 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

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

let-floating

[Janis Voigtlaender]

Hello,

I've got a question regarding let-floating [1]. 
Consider the following two versions of the quicksort algorithm:

> qsort1 l = f l []
> where f [] = (\y -> y)
>   f (x:xs) = let (xs_1,xs_2) = part (  in  (\y -> f xs_1 (x:(f xs_2 y)))

> qsort2 l = f l []
> where f [] = (\y -> y)
>   f (x:xs) = (\y -> let (xs_1,xs_2) = part ( in  f xs_1 (x:(f xs_2 y)))

where the following auxiliary function is used for partitioning a list according 
to some predicate p:

> part  p l = part' p l [] []
> part' p [] = (\y_1 y_2 -> (y_1,y_2))
> part' p (x:xs) = (\y_1 y_2 -> if p x then part' p xs (x:y_1) y_2
>  else part' p xs y_1 (x:y_2))

If compiled with "ghc -O", qsort1 runs considerably slower than qsort2 
(profiling shows that the problem is garbage collection). However, qsort2 can be 
obtained from qsort1 by floating the let-binding into the lambda-abstraction. Of 
course, [1] states that this is no good idea unless we know that the 
lambda-abstraction will be applied only once (as is the case here, right?). 
There it is also stated that an analysis phase is added to GHC that spots such 
"one-shot-lambdas". I use a fairly old GHC, so my question is:

Is there a compiler (which version?) that optimizes qsort1 to (essentially) 
qsort2 ?

Any hints concerning the possibility/impossibility of this would be helpful.
Thanks and regards, Janis.


[1] Simon L. Peyton Jones, Will Partain, André Santos: "Let-floating: Moving 
Bindings to Give Faster Programs", ICFP 1996.


--
Janis Voigtlaender
http://wwwtcs.inf.tu-dresden.de/~voigt/
mailto:[EMAIL PROTECTED]


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell