bug in lex {PreludeText}

1991-09-28 Thread haskell-request
Original-Via: uk.ac.nsf; Sat, 28 Sep 91 08:19:16 BST There is a bug in the lex function (PreludeText, appendix A7). Since '-' now is valid as the first symbol of an operator, it follows that e.g. "-" is an operator, even though "-" is reserved (page 8). But the clause (page 110, line -13)

Yale Haskell Y1.2 Now Available

1991-10-11 Thread haskell-request
please specify this in your request. Note: if you have previously obtained our 1.1 release, the procedure has not changed. You are welcome to get this new version without sending a message to haskell-request if you remember how to do it.

Re: dependency analysis

1991-10-15 Thread haskell-request
Original-Via: uk.ac.st-and.cs; Tue, 15 Oct 91 14:54:37 BST Tony Davie's remarks prompt me to ask: "Who needs mutually recursive modules anyway?". I've never missed the facility in Miranda and my programs are much the clearer for it --- module dependency diagrams with NO directed

Re: dependency analysis

1991-10-15 Thread haskell-request
Original-Via: uk.ac.nsf; Tue, 15 Oct 91 14:44:45 BST Tony Davie's remarks prompt me to ask: "Who needs mutually recursive modules anyway?". I've never missed the facility in Miranda and my programs are much the clearer for it --- module dependency diagrams with NO directed cycles ---

Re: dependency analysis

1991-10-15 Thread haskell-request
Original-Via: uk.ac.ed.mrcvax; Tue, 15 Oct 91 16:19:08 BST | Our Haskell in Haskell compiler modules are often unavoidably mutually | recursive. For small programs you may be right, but for large programs | mutually recursive modules are almost inevitable: | | i)

Re: dependency analysis

1991-10-15 Thread haskell-request
Original-Via: uk.ac.ed.aiai; Tue, 15 Oct 91 17:08:55 BST | Our Haskell in Haskell compiler modules are often unavoidably mutually | recursive. For small programs you may be right, but for large programs | mutually recursive modules are almost inevitable: | | i)

Clarification

1991-10-16 Thread haskell-request
X-Comment1: # X-Comment2: # uk.ac.glasgow.cs has changed to uk.ac.glasgow.dcs # X-Comment3: # If this address does not work please ask your mail# X-Comment4: # administrator to update your NRS mailer tables. #

another typo

1991-10-16 Thread haskell-request
Original-Via: uk.ac.st-and.cs; Wed, 16 Oct 91 15:51:09 BST There should be a comma after the word 'otherwise' in the exports list of the Standard Prelude on p79 Tony Davie

Bug in lex

1991-10-16 Thread haskell-request
X-Comment1: # X-Comment2: # uk.ac.glasgow.cs has changed to uk.ac.glasgow.dcs # X-Comment3: # If this address does not work please ask your mail# X-Comment4: # administrator to update your NRS mailer tables. #

Re: dependency analysis

1991-10-17 Thread haskell-request
Original-Via: uk.ac.ed.aiai; Thu, 17 Oct 91 16:12:59 BST Mutual recursion is a natural part of functional programming style, and we shouldn't have to come up with special examples to justify its existence. If it were equally natural in this case then I think the issue would never have arisen.

Re: dependency analysis

1991-10-18 Thread haskell-request
Original-Via: uk.ac.nsf; Fri, 18 Oct 91 05:18:44 BST The question here is whether a particular way of dividing tasks should be supported by a particular language mechanism. There are good (but perhaps not conclusive) arguments in favor of support for recursive modules. But "some things are

Re: dependency analysis

1991-10-18 Thread haskell-request
Original-Via: uk.ac.st-and.cs; Fri, 18 Oct 91 09:25:44 BST All the messages pro and anti recursive modules are very interesting but my original question has been lost sight of. Are we meant to do dependency analysis across module boundaries or not? and if so can anyone see

Hiding synonyms

1991-10-24 Thread haskell-request
Original-Via: uk.ac.nsf; Thu, 24 Oct 91 22:23:45 BST Original-Sender: [EMAIL PROTECTED] Lennart brings up some interesting points. What is at stake here is the interpretation of the closure rule, Section 5.1.3. The question needs to be a little more precise. Lennart's example is What happens

modules in the report

1991-10-25 Thread haskell-request
Original-Via: uk.ac.st-and.cs; Fri, 25 Oct 91 13:01:49 BST Original-Via: 1: The functions 'approximants' and 'partialQuotients' are exported from module 'PreludeRatio' (see p94). Should they appear in Figure 9, p58 together with a description of what they do in section 6.8.3? 2: The module

previous 2nd level typos

1991-10-28 Thread haskell-request
Original-Via: uk.ac.st-and.cs; Mon, 28 Oct 91 15:31:11 GMT Oh * !! Tony

Superclass instances (Oops)

1991-11-10 Thread haskell-request
Original-Via: uk.ac.nsf; Sun, 10 Nov 91 16:03:39 GMT Original-Sender: [EMAIL PROTECTED] From: [EMAIL PROTECTED] | From: john peterson [EMAIL PROTECTED] | I'll still stick with my opinion on this one, though. Here's more | reasons: | a) This represents a potentially large

Superclass declarations

1991-11-10 Thread haskell-request
Original-Via: uk.ac.nsf; Sun, 10 Nov 91 18:58:02 GMT I was originally going to stay out of this one, but here's why I'm voting for explicit superclass declarations. The problem I see is that allowing implicit class declarations is bound to cause confusion when a user does not actually see an

Superclass instances

1991-11-10 Thread haskell-request
Original-Via: uk.ac.nsf; Sun, 10 Nov 91 02:23:26 GMT a) If an instance declaration is given for a type T and class C, instance declarations must also be given for T and all the superclasses of C. b) If an instance declaration is given for a type T and class C, T is automatically an

Gofer version 2.21

1991-11-25 Thread haskell-request
Original-Via: uk.ac.ox.prg; Mon, 25 Nov 91 18:31:48 GMT [My apologies to those who receive this message from more than one source. In future, messages about new versions of Gofer will be sent to those people on the Gofer mailing list, and will not normally be duplicated in other places.] A new

Proper CITATION for Haskell 1.1

1991-11-27 Thread haskell-request
Original-Via: uk.ac.nsf; Wed, 27 Nov 91 01:09:30 GMT Hi, I have a copy of the Haskell 1.1 report, except for the first ten pages or so which our LaserWriter refused to print (probably a dvi2ps problem). Anyway, how should I cite it correctly? (bibTeX entry preferred) Is it to appear in a

Report desiderata

1991-11-29 Thread haskell-request
Original-Via: uk.ac.nsf; Fri, 29 Nov 91 15:38:59 GMT Here are some things I would like to see in the next version of the Report: (a) A coalesced diagram over the subclass inclusions between all standard classes (fig. 4, p. 30) and all numeric classes (fig. 7, p. 55). Below the

Re: type expression and data type declaration syntax

1991-12-05 Thread haskell-request
Original-Via: uk.ac.nsf; Thu, 5 Dec 91 04:33:50 GMT Original-Sender: [EMAIL PROTECTED] | 1. On p. 24, 125 it says | | " type -type_1 - type_2 | ... | Function arrow associate to the right." |Why not be just as explicit for type expressions as for expressions: I

Re: Dialogue main

1991-12-07 Thread haskell-request
Original-Via: uk.ac.nsf; Sat, 7 Dec 91 13:59:04 GMT X-Comment1: # X-Comment2: # uk.ac.glasgow.cs has changed to uk.ac.glasgow.dcs # X-Comment3: # If this address does not work please ask your mail # X-Comment4: # administrator to update

Re: Need clarification from Haskell designers

1991-12-10 Thread haskell-request
X-Comment1: # X-Comment2: # uk.ac.glasgow.cs has changed to uk.ac.glasgow.dcs # X-Comment3: # If this address does not work please ask your mail# X-Comment4: # administrator to update your NRS mailer tables. #

Re: PreludeCore

1991-12-06 Thread haskell-request
Original-Via: uk.ac.nsf; Fri, 6 Dec 91 05:43:44 GMT I agree with Simon. | The Haskell report claims that all data types, type synonyms and | classes in the Prelude are declared in PreludeCore. This is blatantly | untrue. The exceptions are appended at the end of this message. | | So we either

Re: Comments on the state of play

1991-12-13 Thread haskell-request
X-Comment1: # X-Comment2: # uk.ac.glasgow.cs has changed to uk.ac.glasgow.dcs # X-Comment3: # If this address does not work please ask your mail# X-Comment4: # administrator to update your NRS mailer tables. #

Re: State of play

1991-12-13 Thread haskell-request
X-Comment1: # X-Comment2: # uk.ac.glasgow.cs has changed to uk.ac.glasgow.dcs # X-Comment3: # If this address does not work please ask your mail# X-Comment4: # administrator to update your NRS mailer tables. #

Re: Comments on the state of play

1991-12-13 Thread haskell-request
X-Comment1: # X-Comment2: # uk.ac.glasgow.cs has changed to uk.ac.glasgow.dcs # X-Comment3: # If this address does not work please ask your mail# X-Comment4: # administrator to update your NRS mailer tables. #

Re: Haskell and Wadler and Blott

1991-12-13 Thread haskell-request
Original-Via: uk.ac.nsf; Fri, 13 Dec 91 13:53:03 GMT Original-Sender: [EMAIL PROTECTED] I think the problem is that Haskell's eager resolution strategy for overloading is a major design decision that needs to be emphasized much more in the preface, but the addition to section 4.5.2 fills the gap

Re: PreludeCore

1991-12-13 Thread haskell-request
Original-Via: uk.ac.nsf; Fri, 13 Dec 91 23:01:21 GMT Original-Sender: [EMAIL PROTECTED] If class Text is not in PreludeCore any more what is the meaning of the following program? -- Lennart module Foo where import Prelude hiding(Text(..)) class Text a data T = A deriving (Text)

Kent's infixr application?

1991-12-14 Thread haskell-request
Original-Via: uk.ac.nsf; Sat, 14 Dec 91 08:32:06 GMT Original-Sender: [EMAIL PROTECTED] I remember an old suggestion by Kent K, that the Prelude be extended with something like infixr @@ f @@ x = f x to fix the problems of excessive parentheses when programming with

SYNTAX ONLY: Patterns, LHSes and Type Arrows

1991-12-16 Thread haskell-request
X-Comment1: # X-Comment2: # uk.ac.glasgow.cs has changed to uk.ac.glasgow.dcs # X-Comment3: # If this address does not work please ask your mail# X-Comment4: # administrator to update your NRS mailer tables. #

Re: SYNTAX ONLY: let/if/case/lambda and Function Application

1991-12-15 Thread haskell-request
Original-Via: uk.ac.ox.prg; Sun, 15 Dec 91 17:11:26 GMT ***SYNTAX ONLY*** I was quite suprised to see `atype' in the syntax for expression type signatures in Kevin's proposal: | exp - exp(0,n) [ :: [ context = ] atype] Then I looked at the current Haskell report and

Re: hiding again

1991-12-16 Thread haskell-request
X-Comment1: # X-Comment2: # uk.ac.glasgow.cs has changed to uk.ac.glasgow.dcs # X-Comment3: # If this address does not work please ask your mail# X-Comment4: # administrator to update your NRS mailer tables. #

Re: Comments on the state of play

1991-12-13 Thread haskell-request
X-Comment1: # X-Comment2: # uk.ac.glasgow.cs has changed to uk.ac.glasgow.dcs # X-Comment3: # If this address does not work please ask your mail# X-Comment4: # administrator to update your NRS mailer tables. #

Re: Type arrow erratum

1991-12-16 Thread haskell-request
X-Comment1: # X-Comment2: # uk.ac.glasgow.cs has changed to uk.ac.glasgow.dcs # X-Comment3: # If this address does not work please ask your mail# X-Comment4: # administrator to update your NRS mailer tables. #

Re: PreludeCore

1991-12-16 Thread haskell-request
X-Comment1: # X-Comment2: # uk.ac.glasgow.cs has changed to uk.ac.glasgow.dcs # X-Comment3: # If this address does not work please ask your mail# X-Comment4: # administrator to update your NRS mailer tables. #

hiding again

1991-12-15 Thread haskell-request
Original-Via: uk.ac.nsf; Sun, 15 Dec 91 05:18:50 GMT What about this (sorry to keep complaining): module M where import Prelude hiding (ShowS) ... Is it legal? Well, that depends what the interface file for Prelude looks like. If it says (e.g.) showChar ::

New version of hbc/lml

1991-12-17 Thread haskell-request
Original-Via: uk.ac.nsf; Tue, 17 Dec 91 20:24:41 GMT Original-Sender: [EMAIL PROTECTED] *** * Haskell B. and LML version 0.997.1 * * now available from Chalmers * *** The Haskell B.

Minor corrections

1992-01-03 Thread haskell-request
Original-Via: uk.ac.st-and.cs; Fri, 3 Jan 92 16:24:54 GMT On p100 of the report about half way down, the comment preceding the defn of (!!) talks about "Array index". Shouldn't this be "List index"? Array indexing is elsewhere (!). On p101 the large comment at the top gives certain rules obeyed

Haskell library

1991-12-16 Thread haskell-request
will be made on the Haskell mailing list. Send mail to haskell-request@{dcs.glasgow.ac.uk,cs.yale.edu} to subscribe. Don't get too excited yet: these directories are empty at the moment.

Re: Minor corrections

1992-01-06 Thread haskell-request
Original-Via: uk.ac.nsf; Mon, 6 Jan 92 18:54:51 GMT | On p100 of the report about half way down, the comment preceding the defn | of (!!) talks about "Array index". Shouldn't this be "List index"? Array | indexing is elsewhere (!). | | On p101 the large comment at the top gives certain rules

minor typos

1992-01-09 Thread haskell-request
Original-Via: uk.ac.st-and.cs; Thu, 9 Jan 92 09:48:48 GMT Another minor error. On p123, line -5, the syntax of a let expression is given. The reservedids 'let' and 'in' should be in typwwriter font. Tony

Modules one more time

1992-01-11 Thread haskell-request
Original-Via: uk.ac.nsf; Sat, 11 Jan 92 00:42:09 GMT Original-Sender: [EMAIL PROTECTED] I have some problems with modules again. This time with instance declarations. Consider the following two modules: module M(C(..),T(..)) where module N(C(..),T(..)) where import N

Abstract classes

1992-01-15 Thread haskell-request
Idea (derived from Lennart's hbc compiler): allow a class to be exported without its signature Reason: module M(f,C) class C a where op :: a - a f :: C a = a - a f x = op (op x) We might reasonably want to export "f" but not

Re: An omission in Section 4.3.1?

1992-01-16 Thread haskell-request
Original-Via: uk.ac.nsf; Thu, 16 Jan 92 20:17:50 GMT Original-Sender: [EMAIL PROTECTED] Hmm. That instance declaration is not illegal as things stand. Instance decls must have the form instance cxt = C (T u1 ... un) where ... That is, you can't give an instance decl which gives an

Re: An omission in Section 4.3.1?

1992-01-16 Thread haskell-request
Original-Via: uk.ac.nsf; Thu, 16 Jan 92 22:23:30 GMT Original-Sender: [EMAIL PROTECTED] As Simon points out, I made such an obvious blunder in the example I gave for the so-called omission in Section 4.3.1 that I thought everyone would just ignore it and let me recover from my red face (but

A new book on functional-language implementations

1992-01-17 Thread haskell-request
Implementing functional languages: a tutorial ~ SL Peyton Jones and DR Lester In the Spring of 1992 Prentice Hall will publish the above book, as part of their International Series in Computer Science (ed Hoare). The

Re: An omission in Section 4.3.1?

1992-01-15 Thread haskell-request
Is the following legal? It doesn't violate any stated restriction I think. Class Foo a where x::a instance Foo a = Foo a where x = x Satish As far as I'm aware, this is perfectly legal (the Foo a in the context is redundant, Foo a can always be inferred from Foo a). It

Operators

1992-01-17 Thread haskell-request
I see from Joe's revised syntax that he proposes allowing ( {-white space-} + {-white space-} ) where previously only (+) was allowed. That seems great to me. He also proposed allowing ` {-white space-} f {-white space-} ` where previously only `f` was allowed. I can see

Re: Operators

1992-01-17 Thread haskell-request
So I propose: the back-quote stuff in the lexical syntax, and the paren-ifying in the ordinary syntax. Does anyone else have an opinion. I don't think there are any technical issues here; just stylistic. Simon I agree with you, Simon. Errors from unmatched backquotes

Operators

1992-01-17 Thread haskell-request
Original-Via: uk.ac.ed.dcs; Fri, 17 Jan 92 17:56:56 GMT I was to lazy to get the new version (1.2 beta), but I guess the following slight modification would do the desired effect for expressions like (+) : Add "op^{(a,i)}" as a further alternative for "exp". This would even allow to write lists

Oh no - not more syntax wars! (was: operators)

1992-01-23 Thread haskell-request
Original-Via: uk.ac.nsf; Thu, 23 Jan 92 21:22:37 GMT Original-Sender: [EMAIL PROTECTED] I was planning to stand aside on syntax issues, but this is going too far! Simon proposes: the back-quote stuff in the lexical syntax, and the paren-ifying in the ordinary syntax. Kevin adds:

Oh no - not more syntax wars! (was: operators)

1992-01-23 Thread haskell-request
Original-Via: uk.ac.nsf; Fri, 24 Jan 92 00:07:18 GMT Original-Sender: [EMAIL PROTECTED] If I wasn't such a wimp at this point I would have argued as John has; his argument was exactly why Joe and I made the change. However, the reality is that I have become a wimp (about syntax, anyway).

Re: Operators

1992-01-18 Thread haskell-request
Original-Via: uk.ac.nsf; Sat, 18 Jan 92 14:50:25 GMT Backquotes with or without whitespace are both fine with me. Paul and I did in fact discuss this, and when he made his decision, I think it was a pretty close call. --Joe |I see from Joe's revised syntax that he proposes allowing | |

Operators

1992-01-23 Thread haskell-request
Original-Via: uk.ac.nsf; Thu, 23 Jan 92 22:28:37 GMT So I propose: the back-quote stuff in the lexical syntax, and the paren-ifying in the ordinary syntax. Does anyone else have an opinion. I don't think there are any technical issues here; just stylistic.

Re: A new book on functional-language implementations

1992-01-17 Thread haskell-request
Original-Via: uk.ac.nsf; Fri, 17 Jan 92 18:30:47 GMT Kudos! And Thanks! What a lovely idea! (And I wish you good fortune on your royalties.) Don Stanat

Real Enum, Integral Ix.

1992-01-24 Thread haskell-request
Original-Via: uk.ac.nsf; Fri, 24 Jan 92 20:04:55 GMT Haskell 1.2.beta defines (pp. 58 and 89) class (Num a, Ord a) = Real a and class (Real a) = Integral a Proposal: change this to class (Num a, Ord a, Enum a) = Real a and class (Real a, Ix a) = Integral a

Re: LHSes -- SYNTAX ONLY

1992-01-24 Thread haskell-request
Kevin's argument that a context free grammare(*) is our best tool to express what the difference between an LHS and an RHS is seems very weak. The restrictions on an LHS properly belong to the world of *abstract* syntax. My point was really that a formal mechanism for expressing concrete

Examples of Haskell code

1992-01-22 Thread haskell-request
Original-Via: uk.ac.nsf; Wed, 22 Jan 92 19:31:00 GMT I've been receiving the mailing list now for about a year and now is the first time I've been able to site down and try to code some stuff in Haskell. Reading the Haskell definition is a bit tought going, even though I've programmed in

LHSes -- SYNTAX ONLY

1992-01-23 Thread haskell-request
I've been looking at the syntax of LHSes with Brian Boutel. These are essentially the same for both Haskell 1.1 and 1.2. As stated in the reports, the syntax is very irregular, allowing parentheses in some circumstances, but not in others. The result seems quite arbitrary. f = ...

Re: literate comments

1992-01-24 Thread haskell-request
Phil writes: ... (at Glasgow, we use .has for regular and .lhs for literate). Make that ".hs" and ".lhs"; ".hs" is standard across all known implementations; HBC does ".lhs" as well. Will "We know when Phil last wrote a Haskell pgm :-)" Partain

Re: literate comments

1992-01-27 Thread haskell-request
Original-Via: uk.ac.uknet; Mon, 27 Jan 92 09:49:41 GMT Yes - please include the literate program convention. I never write any other way. Small pedantic point: I think program lines should begin with the two characters " " to prevent people writing lines beginning "=", which could confuse the

literate comments

1992-01-24 Thread haskell-request
Joe Fasel has proposed that we add a literate comment convention to Haskell. A good reason to make this change NOW is that it would let Joe put the prelude in literate style for the SIGPLAN version of the report, which he says he is willing to do. I suggest the following: In literate

Re: literate comments

1992-01-24 Thread haskell-request
I'd be happy with a literate style; but time is short, so decision needed rapidly (Paul) and then (if positive) appropriate changes made (mainly Joe). Simon

Re: literate comments

1992-01-27 Thread haskell-request
Original-Via: uk.ac.ed.aiai; Mon, 27 Jan 92 17:36:47 GMT Could someone please explain to me why there needs to be support for literate comments in the langauge (rather than in the editor or some other program) and why conventions involving or .troff-like-commands are good ones? Maybe I'm just

Re: literate comments

1992-01-29 Thread haskell-request
Original-Via: uk.ac.st-and.cs; Wed, 29 Jan 92 12:57:04 GMT Should we rush into this? Kent's problem, although solved by Phil, convinces me that there may be more to discuss about this subject. I suggest leaving out literate comments until 1.3 or 2.0 or whatever the next version will be called.

Re: literate comments

1992-01-28 Thread haskell-request
Original-Via: uk.ac.uknet; Tue, 28 Jan 92 14:04:42 GMT Jeff Dalton writes: Could someone please explain to me why there needs to be support for literate comments in the language (rather than in the editor or some other program) and why conventions involving or .troff-like-commands are

Re: literate comments

1992-01-29 Thread haskell-request
Kent inquires about the following program: | This is a 'literate' Haskell comment line. | {- This is an illiterate (?? :-) Haskell comment line, but where does it end? | -- This question sounds familiar, but then no | -- """literate""" programming was involved. | -} | Still in a

Re: literate comments

1992-01-28 Thread haskell-request
| Could someone please explain to me why there needs to be support | for literate comments in the langauge (rather than in the editor | or some other program) and why conventions involving or | .troff-like-commands are good ones? The reason for putting literate comments in the language is so

Strict constructors

1992-01-20 Thread haskell-request
Original-Via: uk.ac.susx.syma; Mon, 20 Jan 92 13:33:58 GMT How do you force a constructor to be strict in Haskell ? -- Gavin Wraith

Re: Oh no - not more SYNTAX wars! (was: operators)

1992-01-29 Thread haskell-request
Original-Via: uk.ac.nsf; Wed, 29 Jan 92 15:14:28 GMT John Peterson writes: I was planning to stand aside on syntax issues, but this is going too far! Simon proposes: the back-quote stuff in the lexical syntax, and the paren-ifying in the ordinary syntax.

Pattern-matching (was Re: LHSes -- SYNTAX only)

1992-01-30 Thread haskell-request
Original-Via: uk.ac.nsf; Thu, 30 Jan 92 19:28:07 GMT Posted-Date: Thu, 30 Jan 92 12:22:11 CST X-Mailer: ELM [version 2.3 PL11] I agree with Kevin Hammond when he points out that the syntactic differences between legal and illegal LHSes are subtle. This appears to be yet another of a growing

Re: literate comments

1992-01-30 Thread haskell-request
Original-Via: uk.ac.nsf; Thu, 30 Jan 92 23:14:16 GMT A personal opinion about this 'literate' feature; I have done my thesis programming part in Miranda, which has the same 'literate' option ( lines beginning with are in the program, the other lines are comments ), and I found it very useful

Re: literate comments

1992-02-01 Thread haskell-request
Original-Via: uk.ac.nsf; Sun, 2 Feb 92 00:18:29 GMT A personal opinion about this 'literate' feature; I have done my thesis programming part in Miranda, which has the same 'literate' option ( lines beginning with are in the program, the other lines are comments ), and I found it very

literate comments

1992-02-02 Thread haskell-request
Original-Via: uk.ac.nsf; Sun, 2 Feb 92 02:07:28 GMT I, too, am puzzled about trying to fix a ``literate style'' in a particular programming language. It seems to have limited use. There appear to be many other kinds of ``documented code'' where it seems to be inappropriate: - Documents where

Re: literate comments

1992-02-03 Thread haskell-request
Original-Via: uk.ac.durham; Mon, 3 Feb 92 10:37:28 GMT I think people are asking too much of a literate style. In my opinion it is useful when writing programs with more comments than code. In such situations, it is important to be able to distinguish comment lines and code lines without having

Literate comments

1992-01-29 Thread haskell-request
| Should we rush into this? Kent's problem, although solved by Phil, | convinces me that there may be more to discuss about this subject. I | suggest leaving out literate comments until 1.3 or 2.0 or whatever the | next version will be called. -- Tony | Maybe we need a "how to be a good Haskell

First Australasian Functional Programming Workshop

1992-02-03 Thread haskell-request
Original-Via: uk.ac.nsf; Mon, 3 Feb 92 23:25:42 GMT To all those who may be interested (particularly in Australasia), We are considering running a workshop on functional programming in July 1992 at Massey University, Palmerston North, New Zealand. The aim is to bring together a small number of

Errata sheet (unauthorized)

1992-01-29 Thread haskell-request
Original-Via: uk.ac.nsf; Thu, 30 Jan 92 00:30:12 GMT Since no one has argued against making Real a subclass of Enum and Integer a subclass of Ix (see my previous letter), I assume that everyone agrees with me. ;-) -- Mikael R. P.S: Here are some errata in 1.2.beta, with suggested fixes.

Syntax Decisions

1992-01-30 Thread haskell-request
Original-Via: uk.ac.nsf; Thu, 30 Jan 92 22:13:52 GMT Original-Sender: [EMAIL PROTECTED] Here are three decisions regarding recent syntax issues. Please let's not discuss them any further for now unless you are absolutely convinced that something terribly wrong is happening. An overriding

Re: literate comments

1992-02-04 Thread haskell-request
Original-Via: uk.ac.ed.aiai; Tue, 4 Feb 92 17:26:28 GMT I think people are asking too much of a literate style. In my opinion it is useful when writing programs with more comments than code. In such situations, it is important to be able to distinguish comment lines and code lines without

Re: literate comments

1992-02-04 Thread haskell-request
Original-Via: uk.ac.ed.mrcvax; Tue, 4 Feb 92 18:37:31 GMT When programming in Miranda, I almost always produce a literate script, which doubles as a LaTeX document. I think it would be sad if Haskell did'nt define a literate style. Ian

Re: literate comments

1992-02-05 Thread haskell-request
I have been following the recent discussions on "literate style" of programming and I fail to see the purpose of making this part of the language. As Mr. Dalton suggested, a preprocessor to separate code lines from literate lines can easily be written. But I think this should be a agreed upon