[Haskell] Translation of the Gentle Introduction to Haskell 98

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 ha

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

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

Re: [Haskell] Haskell 98 syntax question

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 (

Re: [Haskell] Haskell 98 syntax question

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

[Haskell] Haskell 98 syntax question

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 exampl

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

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 missi

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

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:

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

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 modifi

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

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

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

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

[Haskell] problems with Haskell 98's record system

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

[Haskell] Haskell 98 - Slackware Package

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

[Haskell] Haskell 98 - Slackware Package

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 packag

[Haskell] Errata to the Revised Haskell 98 Report

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

Haskell 98 programs

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

Haskell 98 programs

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

The Revised Haskell 98 Report

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 ve

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

* 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

announce: buddha 0.4, a declarative debugger for Haskell 98

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

Re: The Haskell 98 Report

"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, Con

The Haskell 98 Report

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

Re: The Haskell 98 Report

[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

Re: The Haskell 98 Report

gt;; "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 Jo

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,

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

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,

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

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

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

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 hav

HC&A Report: "Haskell 98 Report" copyright

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

RE: Haskell 98

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

RE: Haskell 98

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

RE: Haskell 98

| 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

Re: Haskell 98

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

Haskell 98

| 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

RE: Haskell 98: Behaviour of hClose

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

RE: Haskell 98: Behaviour of hClose

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 no

RE: Haskell 98: Behaviour of hClose

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 dra

Re: Haskell 98

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 curren

RE: Haskell 98

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

Re: Haskell 98

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 ad

Haskell 98

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,

RE: Haskell 98: Behaviour of hClose

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

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

RE: Haskell 98: Behaviour of hClose

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 t

RE: Haskell 98: Behaviour of hClose

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

Re: Haskell 98: Behaviour of hClose

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

Re: Haskell 98: Behaviour of hClose

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

RE: Haskell 98: Behaviour of hClose

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

RE: Haskell 98: Behaviour of hClose

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

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

Re: Haskell 98: Behaviour of hClose

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

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 goo

RE: Haskell 98: Behaviour of hClose

| 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

RE: Haskell 98: Behaviour of hClose

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?

RE: Haskell 98: Behaviour of hClose

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 H

Haskell 98 report

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

Re: Haskell 98 Report: May release

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

Haskell 98 Report: May release

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 ha

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

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 incompl

Re: Mutable arrays in Haskell 98

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

Re: Mutable arrays in Haskell 98

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

Re: Mutable arrays in Haskell 98

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

Mutable arrays in Haskell 98

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

Haskell 98 report: March release

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

Re: FW: Haskell 98 lexical syntax again

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 l

Re: FW: Haskell 98 lexical syntax again

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

RE: Haskell 98 Report

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

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 98 lexical syntax again

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

RE: Haskell 98 report; D Specification of Derived Instances

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

Re: Haskell 98 report; D Specification of Derived Instances

hen 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

Haskell 98 report; D Specification of Derived Instances

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 i

Haskell 98 sections

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 c

Haskell 98 Christmas release

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 l

Haskell 98 IO

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

Re: Haskell 98 Revised

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

RE: Haskell 98 Revised

IL 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

RE: Haskell 98 Revised

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

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 m

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

Haskell 98 prelude bug report

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 defini

RE: Haskell 98 Revised

| 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

Re: Haskell 98 Revised

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 Haske

Re: Haskell 98 Revised

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

Haskell 98 Revised

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

Re: Haskell 98: Enum Class

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 e

RE: Haskell 98: Enum class

lieve, 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 a

RE: Haskell 98: Enum Class

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

Re: Haskell 98: Enum Class

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

Re: Haskell 98: Enum Class

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

Haskell 98 Standard; library Complex

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

Re: Haskell 98: Enum class

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

Re: Haskell 98: Enum class

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

Re: Haskell 98: Enum class

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 ad

Haskell 98: Enum class

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

Re: Haskell 98 - Standard Prelude - Floating Class

[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 (**)

RE: Haskell 98 - Standard Prelude - Floating Class

-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

RE: Haskell 98 - Standard Prelude - Floating Class

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

Re: Haskell 98 - Standard Prelude - Floating Class

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

Re: Haskell 98 - Standard Prelude - Floating Class

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

Re: Haskell 98 - Standard Prelude - Floating Class

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

  1   2   3   4   >