[Haskell] Translation of the Gentle Introduction to Haskell 98

[Gorgonite]

Hello,


I don't know if there are French-speaking people reading this
mailing-list, but we at haskell-fr have some great news today !

We didn't find any French translation of the "Gentle Introduction to
Haskell" (version 98), thus we decide to write it.
Today, I would like to announce that  we have completed a translation into
French, that it can be read by following the link :

http://gorgonite.developpez.com/livres/traductions/haskell/gentle-haskell/


It is currently available as a set of HTML pages.  We are
also putting into the "official format" with *.verb files.
Hopefully you will soon be able to download that version as well.


Please send your comments and suggestions to the French Haskell
mailing list [EMAIL PROTECTED]



Best regards,



___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Re: [Haskell-cafe] What ever happened to Haskell 98 as a "stablebranch"?

[Andrzej Jaworski]

>Diversity is generated by mutations.

This is hardly a revelation.
My point was that you need two competing components in relative balance to
grow something meaningful.
Cancer growth is based solely on mutation!

Also I was not theological. It is the advice to multiply Prelude and use
time to verify them rather cosmic in scale. It implies the assumption that
the world will freeze and wait for the verdict.

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Haskell 98 syntax question

[Wolfgang Lux]

Sascha Böhme wrote:


Hello,

referring to the Haskell 98 report as available in the Internet, I  
have a short question. Section 4.1.3 (Syntax of Class Assertions  
and Contexts) contains the rule:


class -> qtycls tyvar
  |  qtycls ( tyvar atype1 ... atypen ) (n>=1)

Is there a (simple) practical example of a Haskell type expression  
using the second line of the above rule?


If you read a little bit further, you'll find the type
  (Eq (f a), Functor f) => (a -> b) -> f a -> f b -> Bool
in Sect 4.1.4. Another example can be found in Sect. 4.5.3:
  f :: (Monad m, Eq (m a)) => a -> m a -> Bool
  f x y = return x == y

Regards
Wolfgang

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Haskell 98 syntax question

[Stefan O'Rear]

On Wed, Jan 10, 2007 at 03:33:44PM +0100, "Sascha B?hme" wrote:
> Hello,
> 
> referring to the Haskell 98 report as available in the Internet, I have a 
> short question. Section 4.1.3 (Syntax of Class Assertions and Contexts) 
> contains the rule:
> 
> class -> qtycls tyvar
>   |  qtycls ( tyvar atype1 ... atypen ) (n>=1)
> 
> Is there a (simple) practical example of a Haskell type expression using the 
> second line of the above rule?

Prelude> :t \a b -> (Control.Monad.Trans.lift a >> b)
\a b -> (Control.Monad.Trans.lift a >> b) :: (Monad (t m), 
Control.Monad.Trans.MonadTrans t, Monad m) =>
m a -> t m b -> t m b
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Haskell 98 syntax question

[Sascha Böhme]

Hello,

referring to the Haskell 98 report as available in the Internet, I have a short 
question. Section 4.1.3 (Syntax of Class Assertions and Contexts) contains the 
rule:

class -> qtycls tyvar
  |  qtycls ( tyvar atype1 ... atypen ) (n>=1)

Is there a (simple) practical example of a Haskell type expression using the 
second line of the above rule?

Thanks a lot,
Sascha
-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] problems with Haskell 98's record system

[Johannes Waldmann]

Iavor Diatchki wrote:

>> remove export lists, introduce public/private modifiers

>  And it nicely deals with re-exporting imported entities: public
> imports get reexported, private ones don't.

note though that the public/private thing in Java
also refers to the "package" concept, which is missing from Haskell
(this is worked around at the language level by re-exporting modules,
and at the tool level by Cabal - both kludgy, methinks).
-- 
-- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 --
 http://www.imn.htwk-leipzig.de/~waldmann/ ---

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] problems with Haskell 98's record system

[Iavor Diatchki]

Hello,

On 2/19/06, Johannes Waldmann <[EMAIL PROTECTED]> wrote:
> > ... unless you export everything, you are forced to list all exports
> > explicitly, so there's no way to tell it just the few things you're
> > hiding (though that should not be a difficult extension).
>
> Alternative suggestion:
> remove export lists, introduce public/private modifiers
> http://www.haskell.org//pipermail/haskell-prime/2006-January/000230.html

Yeah, I have also thought about this option, and I think it is a good
idea.  It makes it a lot easier to deal with recursive modules,
because there is no need to do any fix-point computations, as it is
clear from the program text exactly what is exported from each module.
 And it nicely deals with re-exporting imported entities: public
imports get reexported, private ones don't.

-Iavor
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] problems with Haskell 98's record system

[Johannes Waldmann]

Cale Gibbard wrote:

> ... unless you export everything, you are forced to list all exports
> explicitly, so there's no way to tell it just the few things you're
> hiding (though that should not be a difficult extension).

Alternative suggestion:
remove export lists, introduce public/private modifiers
http://www.haskell.org//pipermail/haskell-prime/2006-January/000230.html
-- 
-- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 --
 http://www.imn.htwk-leipzig.de/~waldmann/ ---

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] problems with Haskell 98's record system

[Cale Gibbard]

On 17/02/06, Iavor Diatchki <[EMAIL PROTECTED]> wrote:
> The main problem I find with the module system is that it
> is difficult to export nearly everything from a module.

Just to clarify this, he means that in the sense that exporting all
but a few of the symbols from a module is difficult, not in the sense
that each thing is individually hard to export. :)  The problem is
that unless you export everything, you are forced to list all exports
explicitly, so there's no way to tell it just the few things you're
hiding (though that should not be a difficult extension).

 - Cale
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] problems with Haskell 98's record system

[Iavor Diatchki]

Hello,
Do you  mean the record system or the module system?  I don't think
either is exactly flawed, but for both, people have wanted them to do
more (and some have suggested that they should be the same thing :-) 
The main problem with the record system I have heard about is that
people want to be able to reuse the labels in mutiple types (and
perhaps to have records that do not need to be declared, e.g., like
tuples).   The main problem I find with the module system is that it
is difficult to export nearly everything from a module.  Other
complaints I have heard about, is that there are no signatures (in ML
style), so it is hard to use the module system to define APIs.
-Iavor

On 2/17/06, Wolfgang Jeltsch <[EMAIL PROTECTED]> wrote:
> Hello,
>
> is there any web resource which describes the problems with Haskell 98's
> record system in a compact form?  The Curry people are about to adopt (parts
> of) this module system and I warned them that many consider it flawed.  Alas,
> I'm not an expert in this area, so I cannot give much good arguments in this
> respect.  Therefore, I would be happy if someone could point me to a resource
> describing the problems or even telling the Curry people about the problems
> on the Curry Mailing List [1].
>
> Best wishes,
> Wolfgang
>
> [1] http://www.informatik.uni-kiel.de/~curry/mailinglist.html
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] problems with Haskell 98's record system

[Wolfgang Jeltsch]

Hello,

is there any web resource which describes the problems with Haskell 98's 
record system in a compact form?  The Curry people are about to adopt (parts 
of) this module system and I warned them that many consider it flawed.  Alas, 
I'm not an expert in this area, so I cannot give much good arguments in this 
respect.  Therefore, I would be happy if someone could point me to a resource 
describing the problems or even telling the Curry people about the problems 
on the Curry Mailing List [1].

Best wishes,
Wolfgang

[1] http://www.informatik.uni-kiel.de/~curry/mailinglist.html
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Haskell 98 - Slackware Package

[Alejandro C. Russo]

I use the linux distribution "Slackware" to program in Haskell and that is
why I have recently made a package that contains a compiled version of
Hugs98. This package can be found at
http://www.linuxpackages.net/pkg_details.php?id=3603
which is a big repository of Slackware's packages.

Regards,
-
 Alejandro C. Russo
 Teaching Assistant
 Computer Science Department, FCEIA
 National University of Rosario
 Argentina
-
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Haskell 98 - Slackware Package

[Alejandro C. Russo]

Dear Sr.

I use the linux distribution "Slackware" to program in Haskell and that is why 
I have recently made a package that contains a compiled version of Hugs98. 
This package can be found at
http://www.linuxpackages.net/pkg_details.php?id=3603
which is a big repository of Slackware's packages. 

Regards, 
-
Alejandro C. Russo
Teaching Assistant
Computer Science Department, FCEIA
National University of Rosario
Argentina
-

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

[Haskell] Errata to the Revised Haskell 98 Report

[Simon Peyton-Jones]

Gentle Haskellers

It's pleasing that there have been so few bug reports about the Revised
Haskell 98 report, which was published in January 2003.  But there have
been some: see

http://research.microsoft.com/~simonpj/haskell98-revised/haskell98-revis
ed-bugs.html
and every now and again another one comes up.

Malcolm Wallace has kindly agreed to take over custody of this errata
list.  There's no current plan to do more than keep a list of errors,
but if any genuine ambiguities are found, he'll start a discussion to
try to nail them down.

Thanks Malcolm!

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

Haskell 98 programs

[ru li]

Hi folks

I have been doing my project about benchmarking of functional languages at
York University. I have got my own implementation of Sets ADT, but I also
need some applications which use Sets ADT. If any readers of this mailing
list have Haskell 98 programs that make use of a data type for sets, I would
be very grateful to have copies of those programs.I would use the programs
only as test cases in my student project where their source would be duly
acknowledged.
Thank you very much
Ru
_
Find a cheaper internet access deal - choose one to suit you. 
http://www.msn.co.uk/internetaccess

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

Haskell 98 programs

[ru li]

Hi folks

I have been doing my project about benchmarking of functional languages at 
York University. I have got my own implementation of Sets ADT, but I also 
need some applications which use Sets ADT. If any readers of this mailing 
list have Haskell 98 programs that make use of a data type for sets, I would 
be very grateful to have copies of those programs.I would use the programs 
only as test cases in my student project where their source would be duly 
acknowledged.

Thank you very much
Ru
_
Find a cheaper internet access deal - choose one to suit you. 
http://www.msn.co.uk/internetaccess

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

The Revised Haskell 98 Report

[Simon Peyton-Jones]

Folks

I am holding in my hands the first copy of the Haskell 98 Report to roll off the 
presses at Cambridge University Press.  It looks great.   And it has a copyright 
notice that says "It is intended that this Report belong to the entire Haskell 
community...", just as the online version does.

It's in CUP's catalogue here:
http://titles.cambridge.org/catalogue.asp?isbn=0521826144

Order your copy now (£35)!   Not only is a physical copy useful, but CUP's agreement 
to the rather unique copyright terms deserves our support.

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

Re: announce: buddha 0.4, a declarative debugger for Haskell 98

[Oliver Braun]

* Bernard James POPE <[EMAIL PROTECTED]> [2003-01-27 21:20 +1100]:
> Buddha version 0.4 is now available.

Buddha is now available as part of the FreeBSD ports tree.

BTW, FreeBSD haskellers, we have a virtual category haskell now, see,
e.g. ftp://ftp.freebsd.org/pub/FreeBSD/ports/packages/haskell

Regards,
 Olli
-- 
obraun@ -+-[ informatik.unibw-muenchen.de ]-+-[ IIS _ INF _ UniBwM ]
 |-[ FreeBSD.org  ]-+-[ FreeBSD Commmitter ]
 |-[ unsane.org   ]-+-[ everything __ else ]



msg12156/pgp0.pgp
Description: PGP signature

announce: buddha 0.4, a declarative debugger for Haskell 98

[Bernard James POPE]

Hi all,

Buddha version 0.4 is now available.

It is a declarative debugger for Haskell 98 programs. It supports most of the
language and standard libraries.

Currently it requires ghc 5.04 or greater, and has only been tested on
unix-ish machines.

Documentation and source code are available here:

   www.cs.mu.oz.au/~bjpop/buddha

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

Re: The Haskell 98 Report

[Carl R. Witty]

"Claus Reinke" <[EMAIL PROTECTED]> writes:

> So, as a small token, I've revised my original plan and will now buy one
> of the printed versions (I shall also place higher priority on submitting
> to JFP in the future;-). Let's support forward-looking publishers!
> 
> Thanks, Simon, and thanks, Conrad Guettler & CUP!

I agree totally (I wasn't going to buy a copy, but now I will).

Please let us know when the book becomes available through online
bookstores...

Thanks, Simon and Conrad!

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

The Haskell 98 Report

[Richard Uhtenwoldt]

Simon PJ writes:

> the existing notice that says "you can do what
>you like with this Report" will stay unchanged.  No "non-commercial
>only" caveats.

I remained relatively quiet throughout the discussion,
as I have not contributed to the Report, but I'm very
much relieved.

Scheme, too, has a completely free standards document; we do
not want to give up ground to them :)

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

Re: The Haskell 98 Report

[Antti-Juhani Kaijanaho]

[Resend, sorry for any duplicates you might get.]

On 20021129T102259-, Simon Peyton-Jones wrote:
> The copyright will still be (c) Simon Peyton Jones (as it has for some
> while; it has to be attached to someone or some thing),

AIUI, legally it is attached to everyone who has ever contributed
significant amounts of text to the report...

Anyway, I am very happy about the result.  As someone said, added value,
not monopolies :-)

And I will buy the book myself, and I will persuade the university
library to buy a copy or two too.  (Actually, I would have done that
anyway, but now I can do it without feeling quilty.)

-- 
Antti-Juhani Kaijanaho, LuK (BSc)* http://www.iki.fi/gaia/ * [EMAIL PROTECTED]
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: The Haskell 98 Report

[Claus Reinke]

Hmm, I remained relatively quiet throughout the discussion, as I didn't
expect to buy the book version, and my worries about the online version
were being addressed by others, but as a Haskell user and (occasional)
paper author, I would like to register that CUP's handling of copyrights
here is definitely not going unnoticed.

>From an author's perspective, I'd love to see more publishers approaching
the copyright question on an added-value basis (where a non-exclusive
copyright is sufficient because the item will be published timely, in good
quality and for a reasonable price - so people will want to buy it, not
because they can't get it elsewhere, but because they like what they get!).

So, as a small token, I've revised my original plan and will now buy one
of the printed versions (I shall also place higher priority on submitting
to JFP in the future;-). Let's support forward-looking publishers!

Thanks, Simon, and thanks, Conrad Guettler & CUP!
Claus

- Original Message -
From: "Simon Peyton-Jones" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "Simon Peyton-Jones" <[EMAIL PROTECTED]>; "Conrad Guettler (Conrad Guettler 
(CUP))"
<[EMAIL PROTECTED]>
Sent: Friday, November 29, 2002 10:22 AM
Subject: The Haskell 98 Report


Folks,

As you know, Cambridge University Press are doing us the huge service of publishing 
the Haskell 98
report, both as a special issue of the Journal of Functional Programming (Jan 2003) 
and as a
hardback book (it'll cost around £35).

I'm very, very, very happy to say that, following discussion with CUP, the copyright 
and
reproduction arrangements for the report will remain unchanged; i.e. exactly as they 
are at:
http://research.microsoft.com/~simonpj/haskell98-revised/haskell98-report-html

I'm signing a letter that grants CUP a *non-exclusive* license to publish the Report, 
but it places
no limitations on what else may be done with it.  The copyright will still be (c) 
Simon Peyton Jones
(as it has for some while; it has to be attached to someone or some thing), and the 
existing notice
that says "you can do what you like with this Report" will stay unchanged.  No 
"non-commercial only"
caveats.

In my view this is extremely generous of CUP, and I am particularly grateful to Conrad 
Guettler for
making it happen.  As a thank-you to CUP, perhaps you can all go out and buy a copy!

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


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

The Haskell 98 Report

[Simon Peyton-Jones]

Folks,

As you know, Cambridge University Press are doing us the huge service of publishing 
the Haskell 98 report, both as a special issue of the Journal of Functional 
Programming (Jan 2003) and as a hardback book (it'll cost around £35).

I'm very, very, very happy to say that, following discussion with CUP, the copyright 
and reproduction arrangements for the report will remain unchanged; i.e. exactly as 
they are at:
http://research.microsoft.com/~simonpj/haskell98-revised/haskell98-report-html

I'm signing a letter that grants CUP a *non-exclusive* license to publish the Report, 
but it places no limitations on what else may be done with it.  The copyright will 
still be (c) Simon Peyton Jones (as it has for some while; it has to be attached to 
someone or some thing), and the existing notice that says "you can do what you like 
with this Report" will stay unchanged.  No "non-commercial only" caveats.

In my view this is extremely generous of CUP, and I am particularly grateful to Conrad 
Guettler for making it happen.  As a thank-you to CUP, perhaps you can all go out and 
buy a copy!

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

Re: HC&A Report: "Haskell 98 Report" copyright

[Ross Paterson]

On Tue, Nov 12, 2002 at 01:19:03AM +, Ian Lynagh wrote:
> I note with some sadness the more restrictive license that may be placed
> on the "Haskell 98 Report", as reported by the HC&A. The great
> openness/freeness of haskell, both the report and implementations, is,
> IMO, one of its most important features.
> 
> I have just grabbed a copy of the latest revised report under the
> current licence. AIUI I can continue to publish this under the current
> licence and, assuming I change the name, incorporate any fixes etc
> (assuming the fixers agree to it). Also, Debian can continue to have a
> copy in main in the same way.

I've already done this, by the following process:
* updated the most recent sources (Jan 2002) to match the most recent
  HTML release (Sep 2002)
* marked it as modified, as required by the licence
* put the two reports together
* applied the small number of publicly discussed fixes since the HTML
  release
* fixed a small number of typographical glitches I noticed on the way

The results are at

http://www.soi.city.ac.uk/~ross/haskell-report-modified/

Share and enjoy.  Please let me know of any typographical errors.
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: HC&A Report: "Haskell 98 Report" copyright

[Ketil Z. Malde]

Ian Lynagh <[EMAIL PROTECTED]> writes:

> I note with some sadness the more restrictive license that may be placed
> on the "Haskell 98 Report", as reported by the HC&A.

I have a hard time imagining what this actually means.  The report, as
it is licensed now allows for:

> I have just grabbed a copy of the latest revised report under the
> current licence. AIUI I can continue to publish this under the current
> licence and [..] incorporate any fixes etc

So what exactly is it they want copyright to?  Obviously, they can
have the copyright to the *book* and it's layout and such (i.e., one
cannot xerox it), but the contents is already in the free, isn't it?

> assuming I change the name,

Do they get to own the name?

> I would really prefer it if such forking wasn't necessary

I'm not sure it would be forking, unless somebody plans on maintaining
CUP's "official" version for them.

> I must admit to not seeing what CUP would be getting
> out of it if this is so, though.

Exactly.  They can't really get an exclusive copyright to a document
that's free, can they?  Some publishers are mostly worried about
having the right to do what they will, rather than restricting
others. I think at any rate it's important to be up front with CUP
with this, so they know what's going to happen, so that they don't
feel cheated or mislead.


I'd love to have it in book form, but it's much more important to have
it freely available (e.g. in Debian).


-kzm
-- 
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: HC&A Report: "Haskell 98 Report" copyright

[Lennart Augustsson]

Ian Lynagh wrote:


Hi all,

I note with some sadness the more restrictive license that may be placed
on the "Haskell 98 Report", as reported by the HC&A. The great
openness/freeness of haskell, both the report and implementations, is,
IMO, one of its most important features.

I have just grabbed a copy of the latest revised report under the
current licence.


As much as I hate forks, I guess this is the right thing to do if the 
Haskell
report will lose its free status.  Hopefully there will not be too many 
changes
to maintain in forks.  Thanks for doing this.

   -- Lennart



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

HC&A Report: "Haskell 98 Report" copyright

[Ian Lynagh]

Hi all,

I note with some sadness the more restrictive license that may be placed
on the "Haskell 98 Report", as reported by the HC&A. The great
openness/freeness of haskell, both the report and implementations, is,
IMO, one of its most important features.

I have just grabbed a copy of the latest revised report under the
current licence. AIUI I can continue to publish this under the current
licence and, assuming I change the name, incorporate any fixes etc
(assuming the fixers agree to it). Also, Debian can continue to have a
copy in main in the same way.

I would really prefer it if such forking wasn't necessary, but if the
above is the case (I am not a lawyer, etc etc) then I guess it isn't the
end of the world - I must admit to not seeing what CUP would be getting
out of it if this is so, though.


Ian

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

RE: Haskell 98

[Simon Marlow]

> Out of curiousity, it's a bit strange that
> 
>  > data D = D !Int
>  > myD = D {}
> 
> in invalid, but
> 
>  > newtype N = N !Int
>  > myN = N {}
> 
> is not.

The second example is also invalid: the newtype declaration is
disallowed by the grammar.  (incedentally, it looks like this example
triggers a bug in nhc98).

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

RE: Haskell 98

[Hal Daume III]

> Blargh. Excellent point.  I had totally forgotten that.  I withdraw all
> suggested changes except a cross-ref to the section you mention.  Sigh.
> My brain is getting soft.

Actually the rules referenced appear immediately above, so no reference is
necessary.

My original message was not suggesting a change to the report (though I
don't know that I agree with it -- i can see arguments in each
direction): I was primarily pointing out an infelicity in GHCs
implementation...

Out of curiousity, it's a bit strange that

 > data D = D !Int
 > myD = D {}

in invalid, but

 > newtype N = N !Int
 > myN = N {}

is not.

Not that I'm proposing a change...I just think it's od..

 - Hal

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

RE: Haskell 98

[Simon Peyton-Jones]

| I think the sentence in question (end of 3.15.2) is just a
clarification;
| the preceding 4 rules are sufficient and clear: F{}, S{} and S{x=3}
are
| all illegal because they omit a value for a strict field.  That is,
it's
| correct, though not strictly necessary, nor does it cover all the
cases.

Blargh. Excellent point.  I had totally forgotten that.  I withdraw all
suggested changes except a cross-ref to the section you mention.  Sigh.
My brain is getting soft.

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

Re: Haskell 98

[Ross Paterson]

On Wed, Sep 25, 2002 at 12:34:53PM +0100, Simon Peyton-Jones wrote:
> I spoke too soon.  Consider
> 
> data F = F Int !Int
> 
> data S = S { x::Int, y::!Int }
> 
> According to the words above
>   F {} is illegal
> but what about this one?
>   S {}

I think the sentence in question (end of 3.15.2) is just a clarification;
the preceding 4 rules are sufficient and clear: F{}, S{} and S{x=3} are
all illegal because they omit a value for a strict field.  That is, it's
correct, though not strictly necessary, nor does it cover all the cases.
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Haskell 98

[Simon Peyton-Jones]

| The report says "The expression F {}, where F is a data constructor,
is
| legal whether or not F was declared with record syntax, provided F has
no
| strict fields: it denotes F _|_1 ... _|_n where n is the arity of F."
| 
| It unclear to me why there needs to be this provision for records with
| strict fields -- just let them be undefined -- but that
notwithstanding,
| GHC seems to do the wrong thing:

I spoke too soon.  Consider

data F = F Int !Int

data S = S { x::Int, y::!Int }

According to the words above
F {} is illegal
but what about this one?
S {}

It would be very odd if that were illegal, because S { x=3 } is
certainly not illegal, and is just as much bottom as S {} is.  So it
would be really odd if S {} were illegal.  But that's what the words
imply.

This changes the situation from "maybe this could be better" to "there's
an inconsistency here".  So we have to fix it somehow.

Solutions:
a) omit the clause "provided F has no strict fields"
b) make it clear that F {} is always legal if F is declared with
record syntax
regardless of field strictness; but if F was not
declared with record
syntax it's only legal if F has no strict fields
c) make F {} illegal if F has any strict fields, regardless of
how F is declared.

(c) seems stupid, because then S{x=3} is legal but S{} is not.
(b) seems simply grotesque when written out.

So I now propose to adopt (a) as Hal wanted, despite my earlier
reluctance to make any change at all.  I don't think this decision is
destablising.

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

RE: Haskell 98: Behaviour of hClose

[Simon Peyton-Jones]

Glynn writes:

| 2. Regarding the buffering issue, I suggest adding something along the
| lines of the following to section 11.4.2 of the library report:
| 
| > For a stream which is associated with a terminal device, setting the
| > mode to no-buffering will also disable any line-buffering which may
| > be performed by the operating system's terminal driver.
| >
| > Similarly, setting the mode to line-buffering or block-buffering
| > will enable any line-buffering which may be performed by the
| > operating system's terminal driver.
| 
| However, it was only when analysing the existing behaviour in order to
| write that above that I became aware of the second half. This is
| potentially more problematic than the first half.

...and there are several more paragraphs (below).

I conclude that this is all very tricky, and there is no chance of
getting something that is obviously sensible into 11.4.2 in the next few
days.  Again, the swamp beckons, and we've struggled by without any such
words for many years now.  So I propose to do nothing here, rather than
risk making the situation worse.

Thank you to Glynn for trying!   There's a gold medal waiting for
someone who designs a better (portable) I/O library.

Simon



| 
| While there isn't much point disabling buffering at the stream level
| if it's still being performed by the terminal driver, there *are*
| reasons why you might wish to enable buffering at the stream level
| without enabling canonical mode (which is what the terminal driver's
| "line buffering" actually corresponds to).
| 
| E.g. in canonical mode, the EOF character (typically Ctrl-D) will
| result in a read() from the OS-level descriptor indicating EOF. In
| "raw" mode, the EOF character will be read literally (i.e. '\004' for
| Ctrl-D).
| 
| IOW, while canonical mode results in line-buffering, it also has other
| side-effects.
| 
| Another consequence, which has just sprung to mind, is that whereas
| the buffering mode of a stream is strictly user-space, and therefore
| internal to the program, the terminal driver settings are a property
| of the device, and will affect other programs which use that device.
| 
| Example: a Haskell program is run on a terminal for which canonical
| mode is enabled (which is normally the case), and that program does
| "hSetBuffering stdin NoBuffering", thereby disabling canonical mode.
| After the program terminates, canonical mode will still be disabled
| for that device.
| 
| Similar issues arise in C, i.e. you need to explicitly restore the
| terminal settings when the program terminates or is suspended (via
| SIGTSTP). However, in C, you would have to have explicitly change the
| terminal settings (with e.g. tcsetattr()), whereas Haskell does this
| "under the hood".
| 
| --
| Glynn Clements <[EMAIL PROTECTED]>
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Haskell 98: Behaviour of hClose

[Simon Peyton-Jones]

On the matter of echoing, in Section 7.1 there seem to be two
possibilities:

1.  Delete the sentence "By default, these input functions echo to
standard output." altogether.

2.  Replace the sentence by 
If the standard input (stdin) is a terminal device, 
any input on stdin is normally echoed on that device,
unless the operating system or environment has disabled
such echoing.

My original inclination was for (2), so that Joe's first program will
always work.  However, Glynn and Ross and Ferenc all favour (1).
Virtually no one has said anything else.

I therefore propose to adopt (1).  It's clear that (2) is leading into a
swamp of caveats which we just do not have time to resolve.  Any
implementation will probably do something sensible (i.e. behave like
other languages).

Simon


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

RE: Haskell 98: Behaviour of hClose

[Glynn Clements]

Simon Peyton-Jones wrote:

> Thanks for your input.  If you think it is important, could you please
> propose one or more concrete changes to the wording of the Language
> Report or the Library Report or both.  Then we'll get a better idea of
> what you have in mind.   (Start from the current draft at
> http://research.microsoft.com/~simonpj/haskell98-revised)

1. Regarding the echoing issue, I would simply delete the sentence:

  By default, these input functions echo to standard output. 

from section 7.1 of the report, as:

a) The functions themselves don't do any echoing. The terminal driver
may; but if it does, it will do that regardless of whether or not
these (or any other) functions are called.

b) The terminal driver may do plenty of other things besides echoing. 
Singling out echoing for mention is rather arbitrary; OTOH, a complete
description would occupy a significant amount of space.

2. Regarding the buffering issue, I suggest adding something along the
lines of the following to section 11.4.2 of the library report:

> For a stream which is associated with a terminal device, setting the
> mode to no-buffering will also disable any line-buffering which may
> be performed by the operating system's terminal driver.
> 
> Similarly, setting the mode to line-buffering or block-buffering
> will enable any line-buffering which may be performed by the
> operating system's terminal driver.

However, it was only when analysing the existing behaviour in order to
write that above that I became aware of the second half. This is
potentially more problematic than the first half.

While there isn't much point disabling buffering at the stream level
if it's still being performed by the terminal driver, there *are*
reasons why you might wish to enable buffering at the stream level
without enabling canonical mode (which is what the terminal driver's
"line buffering" actually corresponds to).

E.g. in canonical mode, the EOF character (typically Ctrl-D) will
result in a read() from the OS-level descriptor indicating EOF. In
"raw" mode, the EOF character will be read literally (i.e. '\004' for
Ctrl-D).

IOW, while canonical mode results in line-buffering, it also has other
side-effects.

Another consequence, which has just sprung to mind, is that whereas
the buffering mode of a stream is strictly user-space, and therefore
internal to the program, the terminal driver settings are a property
of the device, and will affect other programs which use that device.

Example: a Haskell program is run on a terminal for which canonical
mode is enabled (which is normally the case), and that program does
"hSetBuffering stdin NoBuffering", thereby disabling canonical mode. 
After the program terminates, canonical mode will still be disabled
for that device.

Similar issues arise in C, i.e. you need to explicitly restore the
terminal settings when the program terminates or is suspended (via
SIGTSTP). However, in C, you would have to have explicitly change the
terminal settings (with e.g. tcsetattr()), whereas Haskell does this
"under the hood".

-- 
Glynn Clements <[EMAIL PROTECTED]>
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: Haskell 98

[Manuel M T Chakravarty]

Dylan Thurston <[EMAIL PROTECTED]> wrote,

> On Thu, Sep 19, 2002 at 02:36:01PM +0100, Simon Peyton-Jones wrote:
> > The copyright notice is, I believe, agreed with CUP, but I must check
> > that.  The online versions will remain available.
> 
> Will the online version be available with the current copyright, or
> will it only be available with the addition of 'non-commercial'?  If
> the copyright on the online version includes non-commercial, there
> might be problems.  For instance, Debian includes the Haskell report
> in its distribution, which some people put onto CDs and sell, which
> would be a violation of the non-commercial terms.

In particular, as the "old" online versions didn't carry
such a restriction, a restriction on the "new" (ie,
corrected) online versions might mean that people might use
the old version where they should use the new, which
wouldn't be in our interest.

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

RE: Haskell 98

[Simon Peyton-Jones]

| > contributions.  So the book currently shows me as editor, while the
| > preface attempts to give credit where credit is due.  Please help me
to
| > improve it.
| >
| You don't specify very clearly when someone deserves to be on the
| contribution list.
| 
| I reported some errors in the report which gave rise to some changes.
If
| that counts as a contribution I think my name should be on the list.

You are right; I should have been clearer.  Yes, you should be on the
list!  My intention was to add someone to the acknowledgements list as
soon as they contributed *anything*.  Please tell me if I have missed
you off.

Josef, I'll add you right now

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

Re: Haskell 98

[Dylan Thurston]

On Thu, Sep 19, 2002 at 02:36:01PM +0100, Simon Peyton-Jones wrote:
> The copyright notice is, I believe, agreed with CUP, but I must check
> that.  The online versions will remain available.

Will the online version be available with the current copyright, or
will it only be available with the addition of 'non-commercial'?  If
the copyright on the online version includes non-commercial, there
might be problems.  For instance, Debian includes the Haskell report
in its distribution, which some people put onto CDs and sell, which
would be a violation of the non-commercial terms.

Best,
Dylan



msg11554/pgp0.pgp
Description: PGP signature

Haskell 98

[Simon Peyton-Jones]

Folks

As you know, we're in the home straight for Haskell 98.  With the
exception of the recent discussion of echoing, there have been very,
very few changes since the May release. (Check out the bugs list.)

Cambridge University Press are going to publish the Language and Library
Reports, both as a book, and as the Jan 2003 issue of the Journal of
Functional Programming.  I have to deliver the source files to them by
end of Sept.  

The current draft is at
http://research.microsoft.com/~simonpj/haskell98-revised

It includes one new thing: a single integrated book-style document that
includes both the language and library reports, with a single index.
This book also has a new preface; this is my attempt to combine stuff
from both old prefaces, eliminating some old material at the same time.

CUP do not want to have a dozen authors for the book, and indeed there
are past members of the Haskell committee who deserve credit, as well as
many people on the Haskell mailing list who have made substantial
contributions.  So the book currently shows me as editor, while the
preface attempts to give credit where credit is due.  Please help me to
improve it.

The copyright notice is, I believe, agreed with CUP, but I must check
that.  The online versions will remain available.

Please take a look. 

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

RE: Haskell 98: Behaviour of hClose

[Simon Peyton-Jones]

Glynn

Thanks for your input.  If you think it is important, could you please
propose one or more concrete changes to the wording of the Language
Report or the Library Report or both.  Then we'll get a better idea of
what you have in mind.   (Start from the current draft at
http://research.microsoft.com/~simonpj/haskell98-revised)

The H98 report is deficient in many respects.   It's been improved
steadily over the last three years, but still has gaps.  This may be one
of them.  But since the report is about to go over the wall to CUP and
get printed as a book (end of Sept) the overriding priority is not to
introduce new errors and accidentally make things worse.  With that in
mind, I think we can only add a sentence here and there to clarify,
nothing big.

Simon

| -Original Message-
| From: Glynn Clements [mailto:[EMAIL PROTECTED]]
| Sent: 18 September 2002 20:50
| To: Simon Peyton-Jones
| Cc: [EMAIL PROTECTED]
| Subject: RE: Haskell 98: Behaviour of hClose
| 
| 
| Simon Peyton-Jones wrote:
| 
| 
| > | 2. Is there actually anything special about the treatment of
stdin, or
| > | does this apply to any input stream which is associated with a
| > | terminal?
| >
| > I'm proposing just stdin.  My motivation is to make simple stupid
| > programs work right.
| 
| Argh. Too much of this and you end up with a language which isn't
| suitable for anything other than "simple stupid programs".
| 
| If you're considering adding "magic" behaviour, the first question
| should be "if this behaviour is completely unacceptable in a certain
| context, how hard is it for the programmer to disable it, or to work
| around it?".
| 
| If you were to forcibly enable echoing on stdin, how hard would it be
| for the programmer to restore the terminal driver to its original
| state? AFAICT, it's impossible; the original state simply wouldn't be
| available. In such a situation, the only option available to the
| programmer is to not use Haskell.
| 
| Part of the reason for C's popularity is that it lets the programmer
| take care of the details, rather than being stuck with the language
| developer's idea of "the right thing". IOW, there is a complete
| absence of problems for which the only solution is "don't use C".
| 
| > If people open other terminal devices they are
| > much more likely to know what they are doing.  It would be
reasonable to
| > pin down what happens in that case, but I'm desperately afraid of
| > opening Pandora's box when I have to deliver the final bits to CUP
in a
| > couple of weeks.  So, stdin only for now.
| >
| > | 3. In general, "magic" behaviour (e.g. clearing the ICANON flag
when
| > | disabling buffering) should at least be documented, otherwise it's
| > | likely to confuse experienced programmers.
| >
| > Well I have never heard of the ICANON flag!  I don't expect to put
it in
| > the Haskell report unless someone tells me it's absolutely
unavoidable!
| 
| You don't necessarily have to mention the details, just point out that
| hSetBuffering may change the terminal driver's settings.
| 
| Because it looks so similar to ANSI C's setvbuf(), someone who is
| migrating from C to Haskell may assume that it's roughly equivalent
| (i.e. that it only affects the user-space stream, and not the
| underlying OS descriptor).
| 
| --
| Glynn Clements <[EMAIL PROTECTED]>
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Haskell 98: Behaviour of hClose

[Glynn Clements]

Simon Peyton-Jones wrote:


> | 2. Is there actually anything special about the treatment of stdin, or
> | does this apply to any input stream which is associated with a
> | terminal?
> 
> I'm proposing just stdin.  My motivation is to make simple stupid
> programs work right.

Argh. Too much of this and you end up with a language which isn't
suitable for anything other than "simple stupid programs".

If you're considering adding "magic" behaviour, the first question
should be "if this behaviour is completely unacceptable in a certain
context, how hard is it for the programmer to disable it, or to work
around it?".

If you were to forcibly enable echoing on stdin, how hard would it be
for the programmer to restore the terminal driver to its original
state? AFAICT, it's impossible; the original state simply wouldn't be
available. In such a situation, the only option available to the
programmer is to not use Haskell.

Part of the reason for C's popularity is that it lets the programmer
take care of the details, rather than being stuck with the language
developer's idea of "the right thing". IOW, there is a complete
absence of problems for which the only solution is "don't use C".

> If people open other terminal devices they are
> much more likely to know what they are doing.  It would be reasonable to
> pin down what happens in that case, but I'm desperately afraid of
> opening Pandora's box when I have to deliver the final bits to CUP in a
> couple of weeks.  So, stdin only for now. 
> 
> | 3. In general, "magic" behaviour (e.g. clearing the ICANON flag when
> | disabling buffering) should at least be documented, otherwise it's
> | likely to confuse experienced programmers. 
> 
> Well I have never heard of the ICANON flag!  I don't expect to put it in
> the Haskell report unless someone tells me it's absolutely unavoidable!

You don't necessarily have to mention the details, just point out that
hSetBuffering may change the terminal driver's settings.

Because it looks so similar to ANSI C's setvbuf(), someone who is
migrating from C to Haskell may assume that it's roughly equivalent
(i.e. that it only affects the user-space stream, and not the
underlying OS descriptor).

-- 
Glynn Clements <[EMAIL PROTECTED]>
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Haskell 98: Behaviour of hClose

[Glynn Clements]

Simon Peyton-Jones wrote:

> What I intended was
>   a simple interactive Haskell program should behave the same 
>   on any OS/environment
> 
> What you and Ross seem to be saying is
>   no, the behaviour of the program can, and should, depend 
>   on the OS/environment
> 
> If that's the consensus I'll happily leave echoing behaviour
> unspecified. Remember, that means that a conforming implementation can
> do whatever it pleases, and hence it's impossible to write a portable
> interactive Haskell program.  Is that you what you intend?

The behaviour of the program itself doesn't depend upon the
environment, but the overall user-visible behaviour of the system when
running that program does.

Any echoing, line editing, etc which is performed by the OS' terminal
driver is not part of the program's behaviour.

A conforming implementation should *not* do whatever it pleases. If
necessary, it should be explictly specified that the terminal settings
are left untouched.

-- 
Glynn Clements <[EMAIL PROTECTED]>
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Haskell 98: Behaviour of hClose

[David Feuer]

On Wed, 18 Sep 2002, Simon Peyton-Jones wrote:

> What I intended was
>   a simple interactive Haskell program should behave the same
>   on any OS/environment
>
> What you and Ross seem to be saying is
>   no, the behaviour of the program can, and should, depend
>   on the OS/environment
>
> If that's the consensus I'll happily leave echoing behaviour
> unspecified. Remember, that means that a conforming implementation can
> do whatever it pleases, and hence it's impossible to write a portable
> interactive Haskell program.  Is that you what you intend?

This is probably a non-issue.  If you start trying to specify details like
echoing, you might as well go into the details of which pixels are
supposed to light up on the monitor, or how the teletype should behave.
If you indicate leeway then implementors will probably "do the right
thing" in all or nearly all cases.  Note that the Report does not (really
cannot) precisely specify what happens when multiple programs access the
same file at once, or what happens when a program receives a SIGHUP signal
(because its controlling terminal has disconnected) or all sorts of other
things that are not really any of its business.

David

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

Re: Haskell 98: Behaviour of hClose

[Ferenc Wagner]

"Simon Peyton-Jones" <[EMAIL PROTECTED]> writes:

> If that's the consensus I'll happily leave echoing
> behaviour unspecified. Remember, that means that a
> conforming implementation can do whatever it pleases, and
> hence it's impossible to write a portable interactive
> Haskell program.  Is that you what you intend?

The Report should not let an implementation do whatever it
pleases.  But it could specify that the runtime system *does
not mess* with the terminal settings, so users' preferences
prevail.  For buffering, the recipe is: terminals are line
buffered, everything else is block buffered.  I find this
appropriate for most applications, except some close (one
keypress) interactions, which are done better via
specialised libraries anyway.  (I have to admit I'm from the
Unix world.  Other perspectives are surely possible.)

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

Re: Haskell 98: Behaviour of hClose

[Malcolm Wallace]

"Simon Peyton-Jones" <[EMAIL PROTECTED]> writes:

> What I intended was
>   a simple interactive Haskell program should behave the same 
>   on any OS/environment
> 
> What you and Ross seem to be saying is
>   no, the behaviour of the program can, and should, depend 
>   on the OS/environment
> 
> If that's the consensus I'll happily leave echoing behaviour
> unspecified. Remember, that means that a conforming implementation can
> do whatever it pleases, and hence it's impossible to write a portable
> interactive Haskell program.  Is that you what you intend?

How about amending your proposed insertion to say:

If the standard input (stdin) is a terminal device, 
any input on stdin is normally echoed on that device,
unless the OS/environment settings indicate otherwise.

In other words, echoing is the natural expectation, but any
external controlling influence (terminal device, terminal driver,
OS, environment) should take precedence, since (a) it is explicit
control by the user, and (b) there is no way to achieve the same
control internal to a Haskell'98 program.

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

RE: Haskell 98: Behaviour of hClose

[Simon Peyton-Jones]

Ahem how true.  I have not idea why it was removed.  But I can't put
anything back in at this stage.

Simon

| -Original Message-
| From: Malcolm Wallace [mailto:[EMAIL PROTECTED]]
| Sent: 18 September 2002 10:04
| To: Simon Peyton-Jones
| Cc: [EMAIL PROTECTED]
| Subject: Re: Haskell 98: Behaviour of hClose
| 
| "Simon Peyton-Jones" <[EMAIL PROTECTED]> writes:
| 
| > (You can change echoing settings via the IO.hSetEcho etc.)
| 
| Ahem, one of the deficiencies of Haskell'98 is that there is no
function
| IO.hSetEcho.  There used to be one in Haskell 1.3 I think, so I guess
there
| was a good reason for removing it?
| 
| Regards,
| Malcolm
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Haskell 98: Behaviour of hClose

[Simon Peyton-Jones]

What I intended was
a simple interactive Haskell program should behave the same 
on any OS/environment

What you and Ross seem to be saying is
no, the behaviour of the program can, and should, depend 
on the OS/environment

If that's the consensus I'll happily leave echoing behaviour
unspecified. Remember, that means that a conforming implementation can
do whatever it pleases, and hence it's impossible to write a portable
interactive Haskell program.  Is that you what you intend?

It's really a pain that this has come up so late in the day.

Simon

| -Original Message-
| From: Ferenc Wagner [mailto:[EMAIL PROTECTED]]
| Sent: 18 September 2002 11:50
| To: [EMAIL PROTECTED]
| Subject: Re: Haskell 98: Behaviour of hClose
| 
| Ross Paterson <[EMAIL PROTECTED]> writes:
| 
| > So I favour deletion of the offending sentence, leaving
| > this as an environment-dependency.
| 
| I second that.  I came to Haskell after many other
| programming languages, and was VERY surprised by echo
| behaviour.  I vote for consistency with long-standing
| standards (C library, every other language) and versatility
| (echo and buffering determined by environment -- it should
| be configured to also run non-Haskell programs, after all).
| 
|  Feri.
| ___
| Haskell mailing list
| [EMAIL PROTECTED]
| http://www.haskell.org/mailman/listinfo/haskell
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: Haskell 98: Behaviour of hClose

[Ferenc Wagner]

Ross Paterson <[EMAIL PROTECTED]> writes:

> So I favour deletion of the offending sentence, leaving
> this as an environment-dependency.

I second that.  I came to Haskell after many other
programming languages, and was VERY surprised by echo
behaviour.  I vote for consistency with long-standing
standards (C library, every other language) and versatility
(echo and buffering determined by environment -- it should
be configured to also run non-Haskell programs, after all).

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

Re: Haskell 98: Behaviour of hClose

[Ross Paterson]

On Wed, Sep 18, 2002 at 09:21:02AM +0100, Simon Peyton-Jones wrote:
> | No yelling, but some random points for consideration:
> | 
> | 1. It might be worth being more explicit, i.e. stating whether this is
> | because the runtime explicitly enables echoing, or because it's
> | assumed that echoing will already be enabled.
> 
> Well, a Haskell user doesn't care.  It's precisely because we want to
> specify the behaviour of Haskell programs, regardless of the underlying
> OS, that it's worth trying to nail down these things.  If the Haskell
> RTS has to nudge the OS into echoing, that's what it should do.

I'm not sure about that.  If I turn off echoing in the OS and then run a
Haskell program, I expect that it won't echo.  Echoing is a function of
the environment.  If a Haskell implementation messes with the terminal
settings for some reason (as Hugs does) then it should emulate the
original settings, but that's all.

So I favour deletion of the offending sentence, leaving this as an
environment-dependency.
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: Haskell 98: Behaviour of hClose

[Malcolm Wallace]

"Simon Peyton-Jones" <[EMAIL PROTECTED]> writes:

> (You can change echoing settings via the IO.hSetEcho etc.)

Ahem, one of the deficiencies of Haskell'98 is that there is no function
IO.hSetEcho.  There used to be one in Haskell 1.3 I think, so I guess there
was a good reason for removing it?

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

RE: Haskell 98: Behaviour of hClose

[Simon Peyton-Jones]

| No yelling, but some random points for consideration:
| 
| 1. It might be worth being more explicit, i.e. stating whether this is
| because the runtime explicitly enables echoing, or because it's
| assumed that echoing will already be enabled.

Well, at Haskell user doesn't care.  It's precisely because we want to
specify the behaviour of Haskell programs, regardless of the underlying
OS, that it's worth trying to nail down these things.  If the Haskell
RTS has to nudge the OS into echoing, that's what it should do.  This
only applies the default settings.  (You can change echoing settings via
the IO.hSetEcho etc.)

| 2. Is there actually anything special about the treatment of stdin, or
| does this apply to any input stream which is associated with a
| terminal?

I'm proposing just stdin.  My motivation is to make simple stupid
programs work right.  If people open other terminal devices they are
much more likely to know what they are doing.  It would be reasonable to
pin down what happens in that case, but I'm desperately afraid of
opening Pandora's box when I have to deliver the final bits to CUP in a
couple of weeks.  So, stdin only for now. 

| 3. In general, "magic" behaviour (e.g. clearing the ICANON flag when
| disabling buffering) should at least be documented, otherwise it's
| likely to confuse experienced programmers. 

Well I have never heard of the ICANON flag!  I don't expect to put it in
the Haskell report unless someone tells me it's absolutely unavoidable!

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

RE: Haskell 98: Behaviour of hClose

[Glynn Clements]

Simon Peyton-Jones wrote:

> | Re: your request to have a final look through the report
> | for any wibbles that might remain -- Section 11.3.2 of the
> | lib report isn't clear on what the expected behaviour of
> | (hClose h >> hClose h) ought to be, i.e., will the second
> | hClose fail or not?
> | 
> | Both GHC and Hugs will now not raise an error when
> | an already closed file is closed again.
> 
> 
> I'm inclined to agree.  Making hClose on a closed handle into a no-op is
> sometimes convenient for the programmer, and not hard for the
> implementation to support.  So I propose to specify that in H98.
> 
> 
> Meanwhile I only had one reply to this proposed clarification to input
> on "stdin":
> 
>   If the standard input (stdin) is a terminal device, 
>   any input on stdin is normally echoed on that device
> 
> The "normally" clause is a weasel way to say that if you fiddle with the
> device then odd things may happen.  The point is that programs like
>   do { s <- getLine ; putLine (reverse s) }
> should work portably.  If we leave this sentence out, then such programs
> are not portable. But they are some of the first programs people write,
> so it's important.
> 
> In short, I propose to adopt this change unless there's a lot of yelling
> soon.

No yelling, but some random points for consideration:

1. It might be worth being more explicit, i.e. stating whether this is
because the runtime explicitly enables echoing, or because it's
assumed that echoing will already be enabled.

At present, it appears to be the latter. This is good, as it leaves
the decision up to the user. E.g. my preferred terminal (XEmacs'
shell-mode) does local echo, so echoing is disabled in the terminal
driver. Having the runtime/libraries enable it would not be good.

2. Is there actually anything special about the treatment of stdin, or
does this apply to any input stream which is associated with a
terminal?

3. In general, "magic" behaviour (e.g. clearing the ICANON flag when
disabling buffering) should at least be documented, otherwise it's
likely to confuse experienced programmers. Particularly when functions
appear to mirror common C functions. Some of Haskell's IO module,
along with the Prelude IO functions, does look suspiciously like
; this can lead people to assume that the semantics are
similar.

-- 
Glynn Clements <[EMAIL PROTECTED]>
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Haskell 98: Behaviour of hClose

[Simon Peyton-Jones]

Sigbjorn writes:

| Re: your request to have a final look through the report
| for any wibbles that might remain -- Section 11.3.2 of the
| lib report isn't clear on what the expected behaviour of
| (hClose h >> hClose h) ought to be, i.e., will the second
| hClose fail or not?
| 
| Both GHC and Hugs will now not raise an error when
| an already closed file is closed again.


I'm inclined to agree.  Making hClose on a closed handle into a no-op is
sometimes convenient for the programmer, and not hard for the
implementation to support.  So I propose to specify that in H98.


Meanwhile I only had one reply to this proposed clarification to input
on "stdin":

If the standard input (stdin) is a terminal device, 
any input on stdin is normally echoed on that device

The "normally" clause is a weasel way to say that if you fiddle with the
device then odd things may happen.  The point is that programs like
do { s <- getLine ; putLine (reverse s) }
should work portably.  If we leave this sentence out, then such programs
are not portable. But they are some of the first programs people write,
so it's important.

In short, I propose to adopt this change unless there's a lot of yelling
soon.

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

Haskell 98 report

[Simon Peyton-Jones]

Folks

I'm happy to say that the Haskell 98 Report (both language and
libraries) is going to be published as a book!   It'll be a (very)
special issue of the Journal of Functional programming (Jan 2003),
but will be available separately through bookshops as a book
published by Cambridge University Press. 

I have had essentially no bug reports since the June release,
which is great.  (One or two typos but that is all.)   I'll have to
deliver source text to CUP in Sept/Oct; until then the gate is
still open to fix actual errors, but the time has now passed for
"wouldn't it be nice if..." stuff.

The online version will continue to be available, of course,
but I expect that you will all want to have the book on your
shelves too.  My paper copy is now well-thumbed.

happy days,

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

Re: Haskell 98 Report: May release

[Malcolm Wallace]

"Simon Peyton-Jones" <[EMAIL PROTECTED]> writes:

> http://research.microsoft.com/~simonpj/h98-revised

  "404 Not Found."

Make that

  http://research.microsoft.com/~simonpj/haskell98-revised
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Haskell 98 Report: May release

[Simon Peyton-Jones]

Folks,

I've finally managed to push out the May 2002 release of
the Haskell 98 report.

http://research.microsoft.com/~simonpj/h98-revised

As far as I know there are no outstanding issues, so I hope
that there will be blissful silence for a month and I can freeze it.
I'd have done so this time if it weren't for some non-trivial changes
to the specification of 'derving' for Read and Show.

As ever, the bugs list makes it easy to find the changes since last time

Happy reading.   A big thank you to those who have spotted errors
and contributed fixes.

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

announce: hatchet version 0.1, a type checking/inference tool for Haskell 98

[Bernard James POPE]

Hi Haskell friends,

This is an announcement for Hatchet version 0.1

   http://www.cs.mu.oz.au/~bjpop/hatchet.html

Hatchet is a type checking and inference tool for
Haskell 98.

It is based on "Typing Haskell in Haskell" by Mark Jones
(http://www.cse.ogi.edu/~mpj/thih/)

It is incomplete, hence version 0.1, but (I think)
usable.

I'm making it available in the hope that it might be
of use to other people.

Documentation is available on the Hatchet web page.

Please feel free to help make Hatchet better.

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

Re: Mutable arrays in Haskell 98

[Mark Tullsen]

José Romildo Malaquias wrote:
> ...
> My attempt was
> 
>   mapIOArray :: Ix ix => (a -> b) -> IOArray ix a -> IO (IOArray ix b)
>   mapIOArray f v = do w <- newIOArray bounds 
>   mapping w (range bounds)
>   where
>   bounds = boundsIOArray v
>   mapping w (i:is) = do x <- readIOArray v i
> writeIOArray w i (f x)
> mapping w is
>   mapping w [] = return w
> 
> But I do not know what to use to replace the . Is there
> a polymorphic value in Haskell that can be of any type?
> 

Yes, use "undefined" from the Prelude:

  undefined:: a
  undefined | False = undefined

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

Re: Mutable arrays in Haskell 98

[José Romildo Malaquias]

On Wed, Mar 27, 2002 at 03:58:46PM +, Malcolm Wallace wrote:
> José Romildo Malaquias <[EMAIL PROTECTED]> writes:
> 
> > I would like to use muttable arrays in Haskell 98, with the GHC
> > _and_ NHC98 compilers. By muttable arrays I mean arrays with
> > in-place updates, as with the MArray arrays (which are not
> > Haskell 98 conformant) found in GHC. Is such array implmentation
> > available?
> 
> Both compilers have libraries supporting the `IOArray' type,
> implemented with in-place update, although obviously the operations
> must be threaded through the IO monad.
> 
> module IOExtras   -- called IOExts in ghc
>   ( ... 
>   , IOArray -- data IOArray ix elt -- mutable arrays
>   , newIOArray  -- :: Ix ix => (ix,ix) -> elt -> IO (IOArray ix elt)
>   , boundsIOArray   -- :: Ix ix => IOArray ix elt -> (ix, ix)
>   , readIOArray -- :: Ix ix => IOArray ix elt -> ix -> IO elt
>   , writeIOArray-- :: Ix ix => IOArray ix elt -> ix -> elt -> IO ()
>   , freezeIOArray   -- :: Ix ix => IOArray ix elt -> IO (Array ix elt)
> 
>   , module Ix   -- re-export Ix for the benefit of IOArrays
> -- instance Eq (IOArray ix elt)
>   )

I am having difficults in defining a map function over an IOArray object.

My attempt was

  mapIOArray :: Ix ix => (a -> b) -> IOArray ix a -> IO (IOArray ix b)
  mapIOArray f v = do w <- newIOArray bounds 
  mapping w (range bounds)
  where
  bounds = boundsIOArray v
  mapping w (i:is) = do x <- readIOArray v i
writeIOArray w i (f x)
mapping w is
  mapping w [] = return w

But I do not know what to use to replace the . Is there
a polymorphic value in Haskell that can be of any type?

Is it indeed possible to have such function without resorting to
another intermediate data structure (like a list)?

Regards,

Romildo
-- 
Prof. José Romildo Malaquias   Departamento de Computação
http://iceb.ufop.br/~romildo   Universidade Federal de Ouro Preto
[EMAIL PROTECTED]   Brasil
[EMAIL PROTECTED]
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: Mutable arrays in Haskell 98

[Malcolm Wallace]

José Romildo Malaquias <[EMAIL PROTECTED]> writes:

> I would like to use muttable arrays in Haskell 98, with the GHC
> _and_ NHC98 compilers. By muttable arrays I mean arrays with
> in-place updates, as with the MArray arrays (which are not
> Haskell 98 conformant) found in GHC. Is such array implmentation
> available?

Both compilers have libraries supporting the `IOArray' type,
implemented with in-place update, although obviously the operations
must be threaded through the IO monad.

module IOExtras -- called IOExts in ghc
  ( ... 
  , IOArray -- data IOArray ix elt -- mutable arrays
  , newIOArray  -- :: Ix ix => (ix,ix) -> elt -> IO (IOArray ix elt)
  , boundsIOArray   -- :: Ix ix => IOArray ix elt -> (ix, ix)
  , readIOArray -- :: Ix ix => IOArray ix elt -> ix -> IO elt
  , writeIOArray-- :: Ix ix => IOArray ix elt -> ix -> elt -> IO ()
  , freezeIOArray   -- :: Ix ix => IOArray ix elt -> IO (Array ix elt)

  , module Ix   -- re-export Ix for the benefit of IOArrays
-- instance Eq (IOArray ix elt)
  )

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

Mutable arrays in Haskell 98

[José Romildo Malaquias]

Hello.

I would like to use muttable arrays in Haskell 98, with the GHC
_and_ NHC98 compilers. By muttable arrays I mean arrays with
in-place updates, as with the MArray arrays (which are not
Haskell 98 conformant) found in GHC. Is such array implmentation
available?

Regards.

Romildo
-- 
Prof. José Romildo Malaquias   Departamento de Computação
http://iceb.ufop.br/~romildo   Universidade Federal de Ouro Preto
[EMAIL PROTECTED]   Brasil
[EMAIL PROTECTED]
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Haskell 98 report: March release

[Simon Peyton-Jones]

Folks

Before I get buried in ICFP submissions I thought I should
get out the H98 report draft.

It's in the usual place:
http://research.microsoft.com/~simonpj/haskell98-revised

Main changes since the Dec release are:

Much improved informal semantics of pattern matching (3.17).

Minor changes to the lexical syntax for white space (!).

Two extra productions for expressions, which makes the treatment

of sections align with the text in 3.5.

Add notes in three places about hard-to-parse constructs. 
This is my eventual solution to some dark corners in the 
grammar (Chapter 3).

Allow duplicates in the subordinate names of export lists (5.2).

Remark that Eq and Ord are strict in both arguments (Appendix
D.1). 

plus quite a few other minor corrections.

As ever, your careful proofreading, esp of the new parts, would be
most helpful.
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: FW: Haskell 98 lexical syntax again

[Ian Lynagh]

On Thu, Feb 28, 2002 at 07:13:32PM -0800, Ashley Yakeley wrote:
> At 2002-02-28 07:18, Simon Peyton-Jones wrote:
> 
> >  whitechar -> newline | vertab | space | tab | uniWhite
> >  newline   -> return linefeed | return | linefeed | formfeed
> >  return-> a carriage return
> >  linefeed  -> a line feed
> >
> >This means that CR, LF, or CRLF, are all valid 'newline' separators,
> >and the same sequence of characters should therefore work on any
> >Haskell implementation.
> 
> Good.
> 
> While you're fiddling with it, I recommend this:
> 
>   newline-> return linefeed | return | linefeed | formfeed | 
> uniLineSep | uniParaSep
>   uniLineSep -> any char of General Category Zl
>   uniParaSep -> any char of General Category Zp

If this happens then

  * The characters newline, return, linefeed, and formfeed, all start a
new line.

in "B.3  Layout" should also be updated. In fact I think it should be
changed to

  * The token newline starts a new line

regardless, although that kind of reminds me the "May contain nuts"
warning on nut packets.


Ian

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

Re: FW: Haskell 98 lexical syntax again

[Ashley Yakeley]

At 2002-02-28 07:18, Simon Peyton-Jones wrote:

>  whitechar -> newline | vertab | space | tab | uniWhite
>  newline   -> return linefeed | return | linefeed | formfeed
>  return-> a carriage return
>  linefeed  -> a line feed
>
>This means that CR, LF, or CRLF, are all valid 'newline' separators,
>and the same sequence of characters should therefore work on any
>Haskell implementation.

Good.

While you're fiddling with it, I recommend this:

  newline-> return linefeed | return | linefeed | formfeed | 
uniLineSep | uniParaSep
  uniLineSep -> any char of General Category Zl
  uniParaSep -> any char of General Category Zp

Unicode defines two codepoints that unambiguously mean 'line separator' 
(\u2028) and 'paragraph separator' (\u2029). As it happens, they are the 
only codepoints in General Categories Zl and Zp. There are other 
paragraph separators (e.g. Georgian and Urdu), but they are actual marks 
rather than being whitespace and are not in GC Zp -- much like the 
pilcrow.

  uniWhite   -> any UNIcode character defined as whitespace

This is fine. But note that whitespace is an 'extended property', it 
can't be derived from General Category:



-- 
Ashley Yakeley, Seattle WA

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

RE: Haskell 98 Report

[Simon Peyton-Jones]

I don't want to do that until its finished!
Which I earnestly hope will be soon.

Simon

| -Original Message-
| From: David Feuer [mailto:[EMAIL PROTECTED]] 
| Sent: 20 February 2002 08:43
| To: [EMAIL PROTECTED]
| Subject: Haskell 98 Report
| 
| 
| Is the revised Haskell98 report going to be put in its proper 
| place on the web site any time soon?  As it is, it is sitting 
| off to the side while the old Report sits in the seat of honor.
| 
| David Feuer
| ___
| Haskell mailing list
| [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
| 
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Haskell 98 Report

[David Feuer]

Is the revised Haskell98 report going to be put in its proper place on
the web site any time soon?  As it is, it is sitting off to the side
while the old Report sits in the seat of honor.

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

Haskell 98 lexical syntax again

[Simon Peyton-Jones]

To meet Ian's observation below, I propose to replace the 
lexical production

newline  -> a newline (system dependent)

by

newline -> return linefeed | return | linefeed

which, given maximal munch, will behave decently on 
any normal system.

Any objections?

Simon


| -Original Message-
| From: Ian Lynagh [mailto:[EMAIL PROTECTED]] 

| The report says
| 
| whitechar-> newline | return | linefeed | vertab | formfeed
|  |  space | tab | uniWhite
| newline  -> a newline (system dependent)
| return   -> a carriage return
| linefeed -> a line feed
| 
| so, if your system defines a newline to be a line feed, an 
| implementation is free to choose whether to lex a line feed 
| as a whitechar or a newline, which makes quite a difference 
| when you consider the layout rule!
| 
| newline can't be arbitrarily determined by the system - 
| certainly "x" or "let" would not be acceptable - and having 
| it system dependent means that Haskell scripts are not 
| portable between different systems. I haven't looked but I 
| would be surprised if current implementations behaved 
| differently on different platforms - I assume they all look 
| for something matching (?)| everywhere.
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Haskell 98 report; D Specification of Derived Instances

[Simon Peyton-Jones]

| Just before Section D.1 there is the sentence
| 
| When inferring the context for the derived instances, type 
| synonyms must be expanded out first. 
| 
| I don't understand it. Which type synonyms need expansion? 

Consider
type Foo a = [a]
data T a = MkT (Foo a) deriving( Eq )

Then we must expand the Foo synonym when inferring the
context of the derived instance decl

instance Eq a => Eq (T a) where ...

I've tried to clarify this by saying instead:
"When inferring the context for the derived instances, type synonyms
in the constructors' argument types must be expanded out first."

| Free names in the declarations d are all defined in the 
| Prelude; the qualifier `Prelude.' is implicit here.
| 
| Well, `Prelude' does not necessarily refer to the builtin 
| prelude. I suppose the sentence should actually be the same 
| as the statement at the beginning of Chapter 3 (Expressions).

Good idea. I'll do that.

| Naturally this makes clear that it is actually impossible to 
| correctly build a tool like DrIft. There is no safe way in 
| Haskell to refer to the builtin prelude...

I guess you could say
import Prelude as DriftPrelude

and then use DriftPrelude.wuggle

Of course, the programmer might be using DriftPrelude, but that would
be surprising.

Simon

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

Re: Haskell 98 report; D Specification of Derived Instances

[Olaf Chitil]

> When inferring the context for the derived instances, type synonyms must
> be expanded out first.
> 
> I don't understand it. Which type synonyms need expansion? All the u_n
> are type variables.

I worked it out. Given 

data cx => T u1 ... uk = K1 t11 ... t1k1 | ...| Kn tn1 ... tnkn deriving
C

one constructs

instance cx' => C (T u1 ... uk) where ...

cx' is obtained by reducing the context
(cx, C t11, ..., C t1k1, ..., C tn1,... ,C tnkn)
Basically this is standard context reduction as performed by type
inference, except that in the process the need to reduce the context C
(T a1 ... ak) may arise. I assume that the least solution of all
possible solutions is used. Can anybody suggest a simple way for
computing this least fixpoint? nhc98 doesn't determine the least
fixpoint whereas ghc and hbc seem to do so.

This is way more complicated then I thought and doesn't encourage me to
implement it. Naturally all this is pure guesswork, because the Haskell
98 report doesn't explain anything of this...

Olaf

-- 
OLAF CHITIL, 
 Dept. of Computer Science, The University of York, York YO10 5DD, UK. 
 URL: http://www.cs.york.ac.uk/~olaf/
 Tel: +44 1904 434756; Fax: +44 1904 432767

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

Haskell 98 report; D Specification of Derived Instances

[Olaf Chitil]

Just before Section D.1 there is the sentence

When inferring the context for the derived instances, type synonyms must
be expanded out first. 

I don't understand it. Which type synonyms need expansion? All the u_n
are type variables.
Besides, this would make deriving even more horrible than it is. It
would require knowledge about type synonyms. I thought that it should be
possible to derive instances, only knowing the type definition with its
deriving clause.

Furthermore the next sentence in D reads:

Free names in the declarations d are all defined in the
Prelude; the qualifier `Prelude.' is implicit here.

Well, `Prelude' does not necessarily refer to the builtin prelude. I
suppose the sentence should actually be the same as the statement at the
beginning of Chapter 3 (Expressions).

Naturally this makes clear that it is actually impossible to correctly
build a tool like DrIft. There is no safe way in Haskell to refer to the
builtin prelude...

Ciao,
Olaf

-- 
OLAF CHITIL, 
 Dept. of Computer Science, The University of York, York YO10 5DD, UK. 
 URL: http://www.cs.york.ac.uk/~olaf/
 Tel: +44 1904 434756; Fax: +44 1904 432767

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

Haskell 98 sections

[Simon Peyton-Jones]

Folks,

You have all been eating too much Xmas pudding.   Only one 
Haskell98 Report issue has arisen since my release of 21 Dec.  

The issue is this: Section 3.5 says that

(a + b +) 

is a valid operator section (meaning  \x -> a + b + x) because
(+) is right associative.  But this is contradicted by the actual
syntax, which only has the productions: 

aexp ::= '(' exp(i+1) qop(a,i) ')'
|  '(' qop(a,i) exp(i+1) ')'

(Here 'a' ranges over the possible operator associativities
of left, right, non-assoc, while i ranges over precendence levels.)

This is clearly an inconsistency.  I propose to fix the syntax in the
way proposed by Simon and Ian (in a thread on GHC-bugs), by
adding the following productions for aexp.

'(' lexp(i) qop(l,i) ')'
'(' qop(r,i) rexp(i) ')'

This actually follows the way that qfunlhs is defined.
There is no ambiguity, because an exp(i+1) is not an lexp(i).

This should bring the formal syntax into line with the 
words in Section 3.5.

Can anyone think of a reason why this won't work?

Simon


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

Haskell 98 Christmas release

[Simon Peyton-Jones]

In my Sisyphian task of finishing the Haskell 98 Report, I thought
I would put out the current version before Xmas.  
http://research.microsoft.com/~simonpj/haskell98-revised

It's substantially the same as the one I put out at the start 
of December, with three exceptions

1.  The layout algorithm has changed (again).   Simon M, Ian L and
I are now all fairly confident that it is right, but we have been proved
wrong before.

2.  The "instance declaration wart" turned out to be closely connnected
to some (unspecified) scoping issues in export lists.  So I have 
nailed all that down.  GHC and Hugs both now implement the new
rules.

3.  The avalance of email about the True Meaning of gcd 0 0 cannot 
have escaped your notice.  I am too stupid to understand most of it,
but my ill-informed conclusion is:
a) there is a lot of support for gcd 0 0 = 0
b) but it is not universal support
The strong default for H98 is "no change", so I've left gcd 0 0 as an
error.
However I have added some examples.

Changes since the early-dec release are marked
[Late Dec 2001] in the Bugs List, so you can find them easily.

I don't think I know of any other loose ends.  Happy reading.

Simon

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

Haskell 98 IO

[Simon Peyton-Jones]

| Anyway, what should the report say?  I think it is reasonable 
| to expect that stdin & stdout should both be unbuffered in 
| order for interact to work right.  So the defn of interact should be
| 
|   interact f = do
|  hSetBuffering stdin  NoBuffering -- new
|  hSetBuffering stdout NoBuffering -- new
|  s <- hGetContents
|  putStr (f s)

Simon Marlow raises a good point here.  If 'interact' is to be
interactive
it had better be unbuffered.  So I propose to add the two new lines
above to the Report.   This does not change the intended behaviour
at all.

Simon

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

Re: Haskell 98 Revised

[Karl-Filip Faxen]

Hi!

For whatever that is worth, my semantics agrees with Simon's point here,
ie in the example code

module M( C(op1) ) where-- NB: op2 not exported
   class C a where
  op1 :: a->a
  op2 :: a->a

module N where
  import M

  instance C Int where
op1 = ...
op2 = ...   -- Is this ok?

the method binding for op2 is not allowed.

But then there *is* a scope issue with instance declarations. What about
the following example:

module M( C(..) ) where  -- NB: both methods exported ...
   class C a where
  op1 :: a->a
  op2 :: a->a

module N where
  import M hiding (op2)  -- ... but op2 is not imported

  instance C Int where
op1 = ...
op2 = ...-- Is this ok?

As far as I've understood, the current revision of the Report states that
a 'hiding' clause affects the qualified names as well as the unqualified
names. Then 'op2' is not visible either qualified or unqualified.

So, should it be legal to make a method declaration for it?

Cheers,

   /kff



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

RE: Haskell 98 Revised

[Simon Peyton-Jones]

Folks,

Concerning the recent change about instance declarations, should
this be valid?

module M( C(op1) ) where-- NB: op2 not exported
   class C a where
  op1 :: a->a
  op2 :: a->a

module N where
  import M

  instance C Int where
op1 = ...
op2 = ...   -- Is this ok?

The point here is that M does not export op2. Can
we still bind it in the instance declaration in N? The old Report
was silent on this point, and so is the new one.

I'd like to say "no, this is illegal".   Haskell uses hiding as its
main abstraction mechanism, and if op2 is hidden then an
importing module should not be able to see it in any way.

I'll clarify this; but I thought I should point out the issue.

Simon

| -Original Message-
| From: Simon Peyton-Jones [mailto:[EMAIL PROTECTED]] 
| Sent: 04 December 2001 12:03
| To: [EMAIL PROTECTED]
| Cc: Simon Peyton-Jones
| Subject: Haskell 98 Revised
| 
| 
| Gentle Haskellers
| 
| The December issue of the Haskell 98 Report is done.
| 
|   http://research.microsoft.com/~simonpj/haskell98-revised
| 
| As usual, changes are highlighted in the overall bugs list 
| thus: [Dec 2001], so you can find them easily.
| 
| There are the usual crop of presentational improvements 
| (thanks esp to Ian Lynagh, George Russel, Feliks Kluzniak for 
| much careful reading). There are two non-trivial changes that 
| I decided to adopt:
| 
| 1.  Add showIntAtBase, showOct and showHex to the Numeric library.
| 
| 2.  Remove the wart concerning qualified names in instance 
| declarations.
|  This a breaking change, in the sense that exotic Haskell programs
|  may have to change, but I judge it worth it, after some 
| consultation.
|  In particular: 
|   * if you use H/Direct, you'll have to re-generate your
|   Haskell files with a different flag
|   * if you use the Edison library, you'll need a new copy of
|   the library (this isn't a problem in practice because it
|   comes bundled with your compiler)
| 
| The other thing I'd ask you to look at particularly is the 
| layout algorithm. George and Ian have both pointed out bugs, 
| but it's very easy to get wrong so a few more eyeballs on it 
| would be a Good Thing.
| 
| The only unresolved thing I have in my pile is some stuff
| about the lexical syntax of comments, which I find it hard to 
| get excited about.  We are definitely converging.  My earnest 
| hope is to finally freeze the Report at Christmas.  So this 
| is your last chance. I hope.
| 
| Thanks
| 
| Simon
| 
| ==========
| The instance decl wart
| 
| In Haskell 98 as she stands, when you give an instance 
| declaration, the method name is treated as an *occurrence* 
| and so has to be 
| qualified if it is ambiguous:
| 
|   module Foo where
| 
|   compare = 
| 
|   instance Ord T where
|  Prelude.compare = ...-- NB!
| 
| You have to say "Prelude.compare" on the LHS, because both 
| Prelude.compare and Foo.compare are in scope.  This is 
| reasonable on the RHS, of course, but it is plain silly on 
| the LHS, because it 
| *must* refer to the compare from the Ord class!  After all, 
| its an instance declaration for Ord.  
| 
| Not only is it surprising (most people think that plain 
| "compare" should be fine) but it also adds a whole new big 
| production to the grammar (qfunlhs).
| 
| So, after some consulation, I have decided to remove this 
| wierd thing. The analogy is with type signatures, where we 
| can already write
| 
|   module Foo where
| 
|   compare :: Int -> Int
|   compare = ...
| 
| Note that we don't have to write "Foo.compare :: Int -> Int" 
| in the type signature.  
| 
| 
| The remaining question is how to explain this point in the 
| Report. My initial conclusion is that simply deleting the 
| offending text was enough. Explaining the problem (given that 
| it isn't really a problem) seems to complicate matters.  
| Nevertheless I'm entirely happy to add an explanation, if 
| people want it and say what they'd like to see.
| 
| The relevant section is 4.3.2. page 46 of the Report.
| 
| 
| ___
| Haskell mailing list
| [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
| 

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

RE: Haskell 98 Revised

[Simon Peyton-Jones]

A good point.   You are right that the report is not very explicit
on this point; and right that omitting the qualifier would be in the
spirit of the story for type sigs and instance decls.  

I'd be interested to know what others think.

Simon

| -Original Message-
| From: Iavor S. Diatchki [mailto:[EMAIL PROTECTED]] 
| Sent: 04 December 2001 18:41
| To: [EMAIL PROTECTED]
| Subject: Re: Haskell 98 Revised
| 
| 
| hello,
| 
| it seems that if the qualified names in instance declarations 
| are removed, the qualified methods (data constructors) in 
| exports ought to be removed as 
| well.  example: currently in Haskell one may write
| 
| module M ( P.C(Q.f) ) where
| import qualified P
| import qualified Q
| ...
| qualifying the method (or data cosntructor) does not  give 
| any additional 
| information.  however if i read the current report correctly 
| (and i don't 
| think it is quite clear on that)  omitting the qualifier of 
| "f" results in an 
| invalid program as there is no method "f" in scope (there 
| probably are "P.f" 
| and "Q.f"however).   having said that, GHC accepts the 
| program without the 
| qualifier,so it seems that it essentailly ignores the qualifiers of 
| "subordinate" names in export lists.  so why not adjust the 
| report so that 
| such qualified names are just not allowed?
| 
| bye
| iavor
| 
| 
| 
| 
| 
| 
| ___
| Haskell mailing list
| [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
| 

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

Re: Haskell 98 Revised

[Iavor S. Diatchki]

hello,

it seems that if the qualified names in instance declarations are removed,
the qualified methods (data constructors) in exports ought to be removed as 
well.  example: currently in Haskell one may write

module M ( P.C(Q.f) ) where
import qualified P
import qualified Q
...
qualifying the method (or data cosntructor) does not  give any additional 
information.  however if i read the current report correctly (and i don't 
think it is quite clear on that)  omitting the qualifier of "f" results in an 
invalid program as there is no method "f" in scope (there probably are "P.f" 
and "Q.f"however).   having said that, GHC accepts the program without the 
qualifier,so it seems that it essentailly ignores the qualifiers of 
"subordinate" names in export lists.  so why not adjust the report so that 
such qualified names are just not allowed?

bye
iavor






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

Haskell 98 Revised

[Simon Peyton-Jones]

Gentle Haskellers

The December issue of the Haskell 98 Report is done.

http://research.microsoft.com/~simonpj/haskell98-revised

As usual, changes are highlighted in the overall bugs list thus: [Dec
2001],
so you can find them easily.

There are the usual crop of presentational improvements (thanks
esp to Ian Lynagh, George Russel, Feliks Kluzniak for much careful
reading).
There are two non-trivial changes that I decided to adopt:

1.  Add showIntAtBase, showOct and showHex to the Numeric library.

2.  Remove the wart concerning qualified names in instance declarations.
 This a breaking change, in the sense that exotic Haskell programs
 may have to change, but I judge it worth it, after some
consultation.
 In particular: 
* if you use H/Direct, you'll have to re-generate your
Haskell files with a different flag
* if you use the Edison library, you'll need a new copy of
the library (this isn't a problem in practice because it
comes bundled with your compiler)

The other thing I'd ask you to look at particularly is the layout
algorithm.
George and Ian have both pointed out bugs, but it's very easy to get
wrong
so a few more eyeballs on it would be a Good Thing.

The only unresolved thing I have in my pile is some stuff
about the lexical syntax of comments, which I find it hard to get
excited about.  We are definitely converging.  My earnest hope is to
finally freeze the Report at Christmas.  So this is your last chance.
I hope.

Thanks

Simon

==
The instance decl wart

In Haskell 98 as she stands, when you give an instance declaration,
the method name is treated as an *occurrence* and so has to be 
qualified if it is ambiguous:

module Foo where

compare = 

instance Ord T where
   Prelude.compare = ...-- NB!

You have to say "Prelude.compare" on the LHS, because both
Prelude.compare and Foo.compare are in scope.  This is reasonable
on the RHS, of course, but it is plain silly on the LHS, because it 
*must* refer to the compare from the Ord class!  After all, its an
instance
declaration for Ord.  

Not only is it surprising (most people think that plain "compare" should
be fine) but it also adds a whole new big production to the grammar
(qfunlhs).

So, after some consulation, I have decided to remove this wierd thing.
The analogy is with type signatures, where we can already write

module Foo where

compare :: Int -> Int
compare = ...

Note that we don't have to write "Foo.compare :: Int -> Int" in the
type signature.  


The remaining question is how to explain this point in the Report.
My initial conclusion is that simply deleting the offending text was
enough.
Explaining the problem (given that it isn't really a problem) seems to
complicate matters.  Nevertheless I'm entirely happy to add an
explanation, if people want it and say what they'd like to see.

The relevant section is 4.3.2. page 46 of the Report.


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

Haskell 98 prelude bug report

[Olaf Chitil]

The prelude contains 

instance  Bounded Char  where
minBound=  '\0'
maxBound=  '\x'

I didn't follow all the discussion about unicode, but the maxBound seems
to be wrong. It probably should be '\x10'. The exact specification
could also be avoided by defining

maxBound = primUnicodeMaxBound

where primUnicodeMaxBound is imported from UnicodePrims.



-- 
OLAF CHITIL, 
 Dept. of Computer Science, University of York, York YO10 5DD, UK. 
 URL: http://www.cs.york.ac.uk/~olaf/
 Tel: +44 1904 434756; Fax: +44 1904 432767

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

RE: Haskell 98 Revised

[Simon Peyton-Jones]

|
http://research.microsoft.com/~simonpj/haskell98-revised/haskell98-repor
t-html/index.html
| says "Revised: October 2001" - am I seeing the latest version?

Yes you are -- my mistake.

| You still have
| lexeme -> ... | qop | ...
| in the lexical syntax but have
| qop -> qvarop | qconop
| in the context-free syntax - is this deliberate? It really sucks IMO.

Your message about this is still in my "to deal with" pile.  Last time I
looked
I didn't see an obvious solution, but now I look again, it seem simple.
(Procrastination sometimes works.)

Proposal: 

in the syntax for "lexeme", replace "qop" by "qvarsym |
qconsym".

So the syntax for lexeme becomes

lexeme -> qvarid | qconid | qvarsym | qconsym | 
literal | special | reservedop | reservedid 

I think this restores the stratification between the lexical structure
(no whitespace allowed) and the syntactic structure (whitespace allowed
between lexemes).  It also makes the syntax for "lexeme" look more
symmetrical.

Do you agree?

Simon

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

Re: Haskell 98 Revised

[Ian Lynagh]

Hi Simon

> It's that time of the month.   I'm putting out the November release
> of the Revised Haskell 98 Report.  As ever, I earnestly seek your
> feedback.

In appendix B (syntax), B.3 (layout) says

  * A stream of tokens as specified by the lexical syntax in the Haskell
report, with the following additional tokens:
  + If the first *token after a let, where, do, or of keyword is not {, it
is preceded by {n} where n is the indentation of the *token.
  + If the first *token of a module is not { or module, then it is preceded
by {n} where n is the indentation of the *token.
  + Where the start of a *token does not follow any complete *token on the
same line, this *token is preceded by  where n is the indentation of
the *token, provided that it is not, as a consequence of the first two
rules, preceded by {n}.

I think the word "token" should be replaced with "lexeme" where I have
marked it with *.

I am also not clear what you mean by "complete token"?

Finally, ghci, hi and hugs seem to accept

> instance Fractional Int where

as a valid program, but the layout rule doesn't seem to specify how ot
handle this (and as the last token is a new line token some simple fixes
don't work).

If I have this module:

> module Foo where
> instance Fractional Int where
> foo = 5

then with ghci I can evaluate foo:

Compiling Foo  ( QQW.lhs, interpreted )

QQW.lhs:3:
Warning: No explicit method nor default method for `fromRational'
 In the instance declaration for `Fractional Int'
Foo> foo
5
Foo>

hi lets me load it but complains when I try to evaluate it:

Prelude> foo
[Compiling...

Error when renaming::
Identifier foo used at 10:21 is not defined. (in overlap resolution)
...failed]
Prelude> 

and hugs won't even let me load it:

Reading file "QQW.lhs":
ERROR QQW.lhs:4 - No member "foo" in class "Fractional"
Prelude> 

As the report stands I don't think any implementation does the right
thing, but that they should fail due to not being able to offsideify the
module as n == m on the line defining foo so the { is neither explicitly
nor implicitly provided for the idecls.


Thanks
Ian


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

Re: Haskell 98 Revised

[Ian Lynagh]

On Fri, Nov 02, 2001 at 09:30:36AM -0800, Simon Peyton-Jones wrote:
> Haskellers!

Hi Simon  :-)

> It's that time of the month.   I'm putting out the November release
> of the Revised Haskell 98 Report.  As ever, I earnestly seek your
> feedback.  Especially I'd like to know whether I have stumbled
> in rewriting the section about Enum in the light of recent email.
> 
>   http://research.microsoft.com/~simonpj/haskell98-revised

http://research.microsoft.com/~simonpj/haskell98-revised/haskell98-report-html/index.html
says "Revised: October 2001" - am I seeing the latest version?

Actually,
http://research.microsoft.com/~simonpj/haskell98-revised/haskell98-report-html/syntax-iso.html
has "November 2001" at the bottom so I guess I am.

You still have
lexeme -> ... | qop | ...
in the lexical syntax but have
qop -> qvarop | qconop
in the context-free syntax - is this deliberate? It really sucks IMO.

> My plan is to iterate just once more (early Dec), and then freeze 
> the report at Christmas.  I'm getting tired!

:-)


Thanks
Ian


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

Haskell 98 Revised

[Simon Peyton-Jones]

Haskellers!

It's that time of the month.   I'm putting out the November release
of the Revised Haskell 98 Report.  As ever, I earnestly seek your
feedback.  Especially I'd like to know whether I have stumbled
in rewriting the section about Enum in the light of recent email.

http://research.microsoft.com/~simonpj/haskell98-revised

My plan is to iterate just once more (early Dec), and then freeze 
the report at Christmas.  I'm getting tired!

Simon

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

Re: Haskell 98: Enum Class

[George Russell]

Simon Peyton-Jones wrote:
[snip]
> 
> The Revised Haskell 98 report is suppposed to be in
> conclusion mode.  An attempt to decide what features are
> deprecated would open up a big new debate.  One could
> instead list features which are controversial --- that would
> be easier.  Whether it would actually be worth the work of
> getting consensus on such a list is not clear to me.
I don't really understand what is meant by "controversial".  For n+k
patterns we can summarise section 1.4 as saying
(1) they are discouraged.
(2) they may be altered or removed in a future version of Haskell.
(3) implementors are encouraged to provide a mechanism for users
to selectively enable or disable them.  (Personally I would prefer
warnings, but the difference isn't very important; in both cases the
effect is to draw the users' attention to the use of deprecated features.)
Now I think that, at least, the use of the instance of Enum Float/Double
should also be like this.  Does anyone actually disagree with this?

Fortunately I am not responsible for revising the Haskell standard.  I say
fortunately, because there a very large number of things I would change if
redesigning the language from scratch, and I might be tempted to try and
sneak them into the current revision.  In the current circumstances, I think
the best we can do is try to identify those features which can safely be 
deprecated without upsetting a large body of users.  n+k patterns are safely
in there, and I think Enum Float/Double should be too.  I think the suggestion
that contexts in datatypes should also be on the list is a good one, since at
the moment they do nothing useful, though a future change might more sensibly
change them so that they do.

I appreciate the problem if the Haskell98 revision has to be completed in the
very near future.  Is there a set timetable?   I think we should be able to
reach some conclusion on an agreed set of deprecated features in the next month
at the worst.

I wonder if we should make some kind of shared intensive effort to track down
some of the remaining bugs in the Haskell standard.  It's a bit unfair putting
it all on SPJ's shoulders.  I've already had a go at being pedantic with the 
lexing and layout sections.  I don't mind doing the same with another few pages 
of the library or report, if some other people will do so too so we can debug
the whole thing.  Then perhaps we might be able to get the whole thing done by
Christmas.

George Russell

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

RE: Haskell 98: Enum class

[Simon Peyton-Jones]

| Somebody raised the issue why to/fromEnum doesn't use Integer 
| instead of Int.  This would, it would seem, solve at least 
| some of the Enum problems that arise from (integral) types 
| with more than 4G values. So, again, why not?

There was an extended discussion on this point, I believe, 
during the Haskell 1.4 --> Haskell 98 transition.  I forget the
details, but I expect that efficiency was an issue.

However, regardless of the merits of the case, changing 
the type of to/fromEnum is not a possibility for the Haskell 98
report, I'm afraid.

Simon

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

RE: Haskell 98: Enum Class

[Simon Peyton-Jones]

| In addition, I suggest that, since it is widely agreed that 
| the instances of Enum for Float and Double are highly 
| unsatisfactory, the report should give these instances the 
| same status as n+k patterns have (in 1.4 of the recent 
| revision).  In particular, their use should be "discouraged", 
| and there 
| should be a warning that the instances may be "altered or 
| removed in Haskell 2".
| 
| It might clear the ground somewhat for Haskell 2 if there 
| were a new section containing a list of deprecated features; 
| we can probably think of some other things which should go in 
| there.  In addition to what's said for n+k patterns, I 
| suggest the standard explicitly encourage (but not oblige) 
| conforming compilers to issue warnings when deprecated 
| features are used.

The Revised Haskell 98 report is suppposed to be in
conclusion mode.  An attempt to decide what features are
deprecated would open up a big new debate.  One could
instead list features which are controversial --- that would
be easier.  Whether it would actually be worth the work of
getting consensus on such a list is not clear to me.  

Simon

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

Re: Haskell 98: Enum Class

[George Russell]

Ketil Malde wrote:
> 
> George Russell <[EMAIL PROTECTED]> writes:
> 
> > In addition, I suggest that, since it is widely agreed that the instances of
> > Enum for Float and Double
> 
> And (Ratio a)?
Yes, you've got a point there.  They'd none of 'em be missed.

Of course mathematicians are well aware that rational numbers can be enumerated,
just not the way the Haskell standard does it . . .

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

Re: Haskell 98: Enum Class

[Ketil Malde]

George Russell <[EMAIL PROTECTED]> writes:

> In addition, I suggest that, since it is widely agreed that the instances of
> Enum for Float and Double

And (Ratio a)?

>are highly unsatisfactory

-kzm
-- 
If I haven't seen further, it is by standing in the footprints of giants

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

Haskell 98 Standard; library Complex

[George Russell]

I sent a report to SPJ on Tuesday complaining about the Haskell 98 definition of asin
on Complex.  Whatever the outcome of this report, I think the Haskell 98 definitions 
for 
Complex need the following documentational change.  We should document, not in Haskell 
code,
but in words, what each function is supposed to do, where there might be any doubt.
For example, how do you tell from the definition of sqrt in the standard which of the 
two possible square roots is being chosen:
> sqrt 0 =  0
> sqrt z@(x:+y)  =  u :+ (if y < 0 then -v else v)
>   where (u,v) = if x < 0 then (v',u') else (u',v')
> v'= abs y / (u'*2)
> u'= sqrt ((magnitude z + abs x) / 2)
(I think I'll leave this as an exercise for the reader 8-)

What is needed is a statement saying that sqrt z approximates the squareroot with phase
in [0,pi) (or whatever the answer is).

The standard should also specify in words which answer to log, asinh, acosh, atanh, 
asin,
acos, atan, is being chosen.

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

Re: Haskell 98: Enum class

[Ketil Malde]

Malcolm Wallace <[EMAIL PROTECTED]> writes:

>> 5.  In Appendix A, the Enum class defn, add comments to explain that the
>> default methods only work for types whose fromEnum/toEnum range fits
>> inside Int.

> I would rather have correct default definitions.

Somebody raised the issue why to/fromEnum doesn't use Integer instead
of Int.  This would, it would seem, solve at least some of the Enum
problems that arise from (integral) types with more than 4G values.
So, again, why not?

-kzm
-- 
If I haven't seen further, it is by standing in the footprints of giants

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

Re: Haskell 98: Enum class

[Malcolm Wallace]

| | (Actually, ghc is `wrong': hbc, hugs and nhc98 match the Report's
| | specification here:   succ = toEnum . (+1) . fromEnum
| | This is confirmed by the description of the semantics in
| | section 3.10.)
| 
| Lies, all lies.   The default methods do not constitute a specification;
| in this case at least, they only approximate the truth.

But the Report is emphatic that Appendix A _does_ constitute a
specification for the Prelude, and I had always assumed that the
default definitions given there are "safe" for all types, though not
necessarily efficient.

If the default methods are semantically incorrect (for some types)
then they must be changed or removed.

| The Report is (regrettably) silent about what the Integer
| instances for succ and pred should be, but they should definitely simply
| add 1 (resp subtract 1).

Admittedly section 3.10 does not mention succ and pred explicitly,
but it does otherwise confirm the semantics of the current default
definitions, namely that:

"For other discrete Prelude types t that are instances of Enum,
namely ... Integer, the semantics is given by mapping ... to Int
using fromEnum, ... , and then mapping back to t with toEnum."

However I agree that
 succ = (+1)
 pred = (\x-> x-1)
would make better sense.

> 5.  In Appendix A, the Enum class defn, add comments to explain that the
> default methods only work for types whose fromEnum/toEnum range fits
> inside Int.

I would rather have correct default definitions.

Regards,
Malcolm

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

Re: Haskell 98: Enum class

[Dylan Thurston]

On Wed, Oct 24, 2001 at 07:51:12AM -0700, Simon Peyton-Jones wrote:
> The Report is (regrettably) silent about what the Integer
> instances for succ and pred should be, but they should definitely simply
> add 1 (resp subtract 1).  They should emphatically not use the default
> methods.   I will add something to that effect in 6.3.4.
> ...
> 3.  Specify that succ and pred on numeric types just add/subtract 1
> (subject to (2) above).

Can you write some code people can cut&paste for instance of Enum on
ordered numeric types, just so this is crystal clear?  You might even
put in some bounds checking:

succ x = let y = x+1 in if y > x then y else error "succ overflowed"

--Dylan

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

Haskell 98: Enum class

[Simon Peyton-Jones]

| > i_succ' = succ i'
| >   -- ghc :  2147483648
| >   -- hugs:  -2147483648
| -- nhc98: -2147483648
| -- hbc:   -2147483648
| 
| > I think Hugs is wrong.  Integer shouldn't wrap.
| 
| (Actually, ghc is `wrong': hbc, hugs and nhc98 match the Report's
| specification here:   succ = toEnum . (+1) . fromEnum
| This is confirmed by the description of the semantics in 
| section 3.10.)

Lies, all lies.   The default methods do not constitute a specification;
in this case at least, they only approximate the truth.

The Report is quite specific about what enumFrom and friends
should do for Integer (Section 3.10).   Admittedly, that's a funny place
to have 
to look.  Maybe I should move that stuff from 3.10 to 6.3.4.

The Report is (regrettably) silent about what the Integer
instances for succ and pred should be, but they should definitely simply
add 1 (resp subtract 1).  They should emphatically not use the default
methods.   I will add something to that effect in 6.3.4.

However Section 6.3.4 is silent on the question of what succ and pred do
at the end of the range.  What is (succ maxInt)?   Bizarrely, Appendix
D.2
(derived instances of Enum) tells us that that's an error.  (Bizarre
because
this fact belongs in 6.3.4 not in D.2.)


In summary, I propose the following (presentational) changes to the
Report.

1. Move specification of enumFrom and friends from 3.10 to 6.3.4

2. Specify that for bounded types, (succ maxBound) and (pred minBound)
are errors.

3.  Specify that succ and pred on numeric types just add/subtract 1
(subject to
(2) above.

4. Rewrite D.2 to talk about deriving only, not about Enum in general.

5.  In Appendix A, the Enum class defn, add comments to explain that the
default methods only work for types whose fromEnum/toEnum range fits 
inside Int.


Would that at least make the present sitation clear.  Acknowledging
that Enum has warty features.

Simon

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

Re: Haskell 98 - Standard Prelude - Floating Class

[Brian Boutel]

[EMAIL PROTECTED] wrote:
> 
> 
> How about making default method for asin
> 
> asin x = atan(x/sqrt(1-x^2))
> 
> Can't be worse than the default for (**) ;-)
> 

Oh, it can. As well as its own problems when x is close to 1, it
inherits, through the default definition of sqrt, the problems of (**)
when x is near 0.

--brian

___
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

How about making default method for asin

asin x = atan(x/sqrt(1-x^2))

Can't be worse than the default for (**) ;-)

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

iD8DBQE71gyFZG3em5NXM14RAsTUAKCfalnIJ/JsBDak0V7jhgesMGrg0ACg1mJr
3Yx6mHcAQ7nyy02UMTdG/L0=
=oJdQ
-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]

An apparently-innocuous suggestion about adding default methods for
sinh and cosh led to a flood of mail.  Since no consensus emerged, I
plan to leave things as they are in the Haskell 98 Report.  Namely, 
the following default methods for the Floating class are there:

x**y = exp (log x * y)
logBase x y = log x / log y
sqrt x = x ** 0.5
tan x = sin x / cos x
tanh x = sinh x / cosh x

but there are no default methods for sinh, cosh.

If someone feels strongly that this is wrong, perhaps they could
try to form consensus among those who responded to the earlier
mail flurry (without bothering the list as a whole), and then put
forward
a proposal.  But I'm not a numerical expert, and the default method here
is definitely "no-op".

Simon


| -Original Message-
| From: George Russell [mailto:[EMAIL PROTECTED]] 
| Sent: 15 October 2001 17:28
| To: [EMAIL PROTECTED]
| > | 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
| > | 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.
|
| 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.  

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

Re: Haskell 98 - Standard Prelude - Floating Class

[Marcin 'Qrczak' Kowalczyk]

Thu, 18 Oct 2001 13:49:11 +0200, Karl-Filip Faxen <[EMAIL PROTECTED]> pisze:

> There are two solutions that I can see: Annotate classes in class 
> constraints with exactly which methods were used. Thus for the
> expression "x+y" the inference algorithm would record the constraint
> "Num{+} a" if x and y has type a in the type environment. Then if
> an instance declaration for type Wurble omitted +, that instance 
> declaration would not allow us to simplify "Num{+} Wurble".

This is equivalent to putting all methods in separate classes.

IMHO missing method definitions should be detected where the instance
is defined, not when it's used. You can still define diverging
methods explicitly or manually split the class if you really want
partial instances.

-- 
 __("<  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

[Karl-Filip Faxen]

Hi!

Jon Fairbairn wrote:
> I agree too, but being able to omit method definitions is
> sometimes useful -- would it be possible to make calls to
> those methods a /static/ error? I suspect this would be hard
> to do.

Yes, quite tricky. The problem is that the class constraints (in an 
inference algorithm or a semantics) only record that some method
was used, not which one. And at the method invocation site it is not
known which instance declaration the method will come from (that's
the point of the Haskell class system, after all).

There are two solutions that I can see: Annotate classes in class 
constraints with exactly which methods were used. Thus for the
expression "x+y" the inference algorithm would record the constraint
"Num{+} a" if x and y has type a in the type environment. Then if
an instance declaration for type Wurble omitted +, that instance 
declaration would not allow us to simplify "Num{+} Wurble".

The second possibility would be to use a separate dataflow analysis
after dictionary conversion to find out if some incomplete dictionary
could flow to a dangerous place. For compilers which use partial 
evaluation to eliminate overloading, this would be particularly
easy. But I think that, given the stylized way dictionaries are
inserted in the code, that this solution is viable in general.

Cheers,

   /kff




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

Re: Haskell 98 - Standard Prelude - Floating Class

[Jon Fairbairn]

> On Tuesday 16 October 2001 07:29, Fergus Henderson wrote:
> > [...]
> > 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.
> 
> This is exactly what I think.

I agree too, but being able to omit method definitions is
sometimes useful -- would it be possible to make calls to
those methods a /static/ error? I suspect this would be hard
to do.

-- 
Jón Fairbairn [EMAIL PROTECTED]
31 Chalmers Road [EMAIL PROTECTED]
Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!)



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