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.

Tony




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 comment, or not???  Or is there a lexical error?

The rule is clear.  Only lines beginning with  are in the program,
so indeed one is still at the comment at the place asked.  Further
complication seems unwarranted.

Paul, oh syntax honcho:  Are we going ahead with this or not?  Cheers, -- P





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.
   [...]
   Me:
   Oh no!  Not more syntactic convolution!
   
I agree with John, only more so.  I'd rather do without the proposed
1.2 gratuitous complexification, too.  What was wrong w/ the good old
friendly *lexemes*...?

var `var`
+   (+)

It never occurred to me to confuse the lexeme (+) with the syntactic
whatsit (+ ...).  Nor have I seen a Haskell program(mer) bitten by
this alleged shortcoming.

Can anyone provide an example of a *single real* Haskell program that
would benefit from the post-1.0 changes?

Will "Feeling Better, Too" Partain




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 system" document  -- just
| as we will eventually need a "Haskell std library" document.
| ... Finally: all implementations support Bird tracks anyway, so
| divergence is not a problem needing to be stamped out.  -- Will

The reason for putting this in now is so that the examples in the
Sigplan Notices version can be done in literate style.  This was Joe's
request, which I support.  (Speak up, Joe!)

Will's last point suggests to me that we do have enough experience not
to run into serious problems, which answers Tony's concern.

Let's not spend too much time on this!  Cheers,  -- P




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. 
  Negative line numbers mean counting bottom-up. 

Page Line  Says Should be 

iii  5,6  nothing "References149"
"Index.151"
(LaTeX refuses to include unnumbered 
 sections in the table of contents, but
 you can put them in the .toc file
 manually.)

ix-0  nothing " \item The precedence of prefix 
minus has been made the
same as infix minus."

11 7  "(see Figure 5)"  "(see Figure 5, page 53)" 

12-6  "Because..."  "Prefix negation has the same precedence
 as the infix - operator defined in the
 standard prelude (see Figure 5, page 53).
 Because..." 

14-1 "...if e3 is omitted,  "...if e3 is omitted, the sequence is 
  the sequence includes  infinite for types in the Real class 
  all (sic!) elements of ([maxInt..] == [maxInt,\bot,\bot,...])
  the enumeration, and   but ends when the elements run out 
  is thus infinite for   for finite enumerations like Char." 
  infinite enumerations." 

53  Fig. 5   add the entry: " 0 | infixr | $ " 

56-4  "and should be large   Delete the phrase. 
   enough to serve as It is redundant, since Ints are 
   array indices."required to cover [-2^29+1, 2^29-1],
  and it is quite weak, since booleans
  can be used as indices. 

56  Fig. 7  Caption: "Numeric   "Class inclusions between some 
class inclusions"of the predefined classes"  
(Eq, Ord, and Text are not numeric)

56  Fig. 7  strange choice  Ix and Enum should also be included. 
 of classes (Real  Enum  Ord, and 
  Integral  Ix  Ord, if the 
  proposition to make Real a 
  subclass of Enum and Integral 
  a subclass of Ix passes the 
  class Czars.)

58 7   "(Num a, Ord a) = Real a"  "(Num a, Enum a) = Real a" 
89   -13- '' ---- ''  
58 9   "(Real a) = Integral a""(Real a, Ix a) = Integral a"
89   -11- '' -  - '' ---
(If this change is adopted, see above.)


6111" -13 `rem` 4"  " (-13) `rem` 4"  
6112" -13 `mod` 4"  " (-13) `mod` 4"
(`rem` and `mod` bind tighter 
 than prefix negation)

64-3"assocs: "  "assocs:: " 

126  -13"abiguities""ambiguities"

126   -4"preface (page )."  "preface (page ix)."

151ff  index entries for add references to page 53 (the 
   !  !!  $   %   *  **   precedence table). 
   +  ++  -   .  /  // /=
   :  :%  :== ==
   =  ^  ^^ div elem mod 
   notElem rem 


*) Sections 1.5 and B.4 on layout are almost but not quite identical.
   Sec. 1.5 is not explicit on whether {- -} comments affect the indentation 
   of a line; sec. B.4 does not contain the module Astack example. The two 
   sections should at least refer to each other. 

*) The curly braces are overloaded in the BNF notation: 

 {pattern} means zero or more repetitions,

 pat   means difference; pat except pat'. 
{pat'}

   This is quite confusing, especially in the ANYseq production:

 ANYseq - {ANY}
{ANY} { {- | -} } {ANY}

   where the outermost braces of the subscript expressions are omitted.
   Suggestion: use angle brackets (\langle and \rangle) for difference.  

-- Mikael R.