Re: Preliminary Haskell 1.3 report now available

1996-03-08 Thread Fergus Henderson


Thomas Hallgren [EMAIL PROTECTED] writes:

 In the syntax for labeled fields (records) the symbol - is chosen
 as the operator used to associate a label with a value in
 constructions and patterns:
[...]
 According to a committee member, there were no convincing reasons
 why - was chosen. Other symbols, like = and := were also considered.

I support Thomas Hallgen's suggestion that `=' be used instead.
Another reason, in addition to the two he mentioned, is that the `-'
symbol is very unintuitive when used for pattern matching, because the
arrow is in the *opposite* direction to the data-flow.  I find this
very confusing.

-- 
Fergus Henderson  | Designing grand concepts is fun;
[EMAIL PROTECTED]   | finding nitty little bugs is just work.
http://www.cs.mu.oz.au/~fjh   | -- Brooks, in "The Mythical Man-Month".
PGP key fingerprint: 00 D7 A2 27 65 09 B6 AC  8B 3E 0F 01 E7 5D C4 3F






Re: Haskell 1.3

1996-03-08 Thread Philip Wadler


 It looks ugly, but we could say that a data declaration does not 
 have to have any constructors:
 
   data Empty =
 
-- Lennart

I agree that the best way to fix this is to have a form of data
declaration with no constructors, but I'm not keen on the syntax you
propose.  How about if we allow the rhs of a data declaration to be
just `empty', where `empty' is a keyword?

data Empty = empty

-- P






Re: Haskell 1.3

1996-03-08 Thread Lennart Augustsson



 Suggestion: Include among the basic types of Haskell a type `Empty'
 that contains no value except bottom.
Absolutely!  But I don't think it should be built in
(unless absolutely necessary).

It looks ugly, but we could say that a data declaration does not 
have to have any constructors:

data Empty =

   -- Lennart

PS. There are other ways of getting empty types, but they are
all convoluted, like

data Empty = Empty !Empty






Re: Haskell 1.3

1996-03-08 Thread Magnus Carlsson


Philip Wadler writes:
  
   It looks ugly, but we could say that a data declaration does not 
   have to have any constructors:
   
  data Empty =
   
  -- Lennart
  
  I agree that the best way to fix this is to have a form of data
  declaration with no constructors, but I'm not keen on the syntax you
  propose.  How about if we allow the rhs of a data declaration to be
  just `empty', where `empty' is a keyword?
  
   data Empty = empty
  
  -- P

I would like to propose an alternative that in my view has both good
syntax, and does not introduce a new keyword:

   data Empty

/Magnus






Re: Haskell 1.3

1996-03-08 Thread Ron Wichers Schreur

Lennart Augustsson wrote:

 It looks ugly, but we could say that a data declaration does not 
 have to have any constructors:
 
   data Empty =

Philip Wadler responded:

 I'm not keen on the syntax you propose.  How about if we allow the
 rhs of a data declaration to be just `empty', where `empty' is a
 keyword?

 data Empty = empty

Another suggestion is to omit the equal sign, as in

  data Empty


Cheers,

Ronny Wichers Schreur
[EMAIL PROTECTED]








Haskell library proposal and constructor classes

1996-03-08 Thread Sven Panne


After browsing through the Standard Library Proposal for Haskell 1.3 (Version 3
from September 6, 1995), I have the following questions:

   1) The proposal for collections (sec. 4.2) mentions four different
  _libraries_ which all define identical functions. IMHO, this should
  better be a single (contructor-) _class_ . To explain this a little
  further, a small sketch of it is appendend at the end of the mail.

  Implementing collections as a class would relieve the programmer from
  changing a lot of type contexts if the undelying implementation of
  collections is changed. The same argument holds for mappings, etc.

  To make my point a little clearer, imagine the following scenario:
  A program which handles collections via ListSets (requiring Eq) turns out
  to be too slow. So the programmer decides to implement collections as
  Sets (requiring Ord) instead. This forces changing the context (Eq a) to
  (Ord a) in all places where collections are used (where a is the type of
  the elements in the collection).

   2) Trying to implement this constructor class (see below), I needed a
  constructor class with _two_ type variables. Gofer allows this, but
  Haskell 1.3 does not. Are there any serious theoretical obstacles for
  insisting on a single type variable in  a class declaration? If not,
  including Gofer's generality in Haskell would be nice.

   3) Are there ways of achieving the desired behaviour with a single type
  variable in the class declaration? If so, forget my previous
  question. :-)


---SNIP--SNIP--SNIP--SNIP--SNIP--SNIP--SNIP--SNIP---

\begin{code}
-- Collections as a constructor class

module Collections (Collection, UList, SList) where

-- Not standard Haskell 1.3, but Gofer-conformant
class Collection col a where
  empty :: col a
  singleton ::a - col a
  add   ::   a - col a - col a
  delete:: (Eq a) = a - col a - col a

  singleton x = add x empty


-- a collection as an unsorted list without duplicates

data UList a = UList [a]

instance (Eq a) = Collection UList a where

   empty = UList []

   add e u@(UList l) | any (e ==) l = u
 | otherwise= UList (e:l)

   delete e (UList l) = UList (del l)
  where del [] = []
del (x:xs) | e == x= xs
   | otherwise = x:(del xs)


-- a collection as a sorted list without duplicates

data SList a = SList [a]

instance (Ord a) = Collection SList a where

   empty = SList []

   add e (SList l) = SList (adjoin l)
  where adjoin [] = [e]
adjoin ys@(x:xs) | e   x = e:ys
 | e == x = ys
 | e   x = x:(adjoin xs)

   delete e (SList l) = SList (del l)
  where del [] = []
del ys@(x:xs) | e   x = ys
  | e == x = xs
  | e   x = x:(del xs)


-- a collection as an unbalanced binary tree
--
-- data Tree a = Empty | Node a (Tree a) (Tree a)
--
-- instance (Ord a) = Collection Tree a where ...
--
-- and so on...

\end{code}

\begin{code}
-- And now to something completely different... ;-)
-- A module which uses the above Collection class
-- Note: All but the last type declarations are superfluous.

module Test where

import Collections

foo :: Collection col Char = col Char - col Char
foo c = add 'a' c

bar :: (Collection col a, Eq a) = col a - a - col a
bar c x = delete x c

baz :: Collection a Char = a Char - a Char
baz c = bar c 'a'

addRange :: (Enum a, Collection col a) = a - a - col a - col a
addRange start end c = foldr add c [start..end]

test :: SList Char
test = addRange 'a' 'z' empty
\end{code}

---SNIP--SNIP--SNIP--SNIP--SNIP--SNIP--SNIP--SNIP---


-- 
Sven Panne Tel.: +49/89/21106-90
LMU, Institut fuer Informatik  FAX : +49/89/21106-99
LFE Programmier- und Modellierungssprachen Wagmuellerstr. 23
mailto:[EMAIL PROTECTED]D-80538 Muenchen






Haskell 1.3, monad expressions

1996-03-08 Thread smk


Suggestion:

add another form of statement for monad expressions:

stmts - ...
 if exp

which is defined for MonadZero as follows:

do {if exp ; stmts} = if exp then do {stmts}
  else zero

Based on this, one can define list comprehensions by

[ e | q1,...,qn ] = do { q1' ; ... ; qn'; return e }

where either  qi' = if qi  (whenever qi is an exp)
or  qi' = qi  (otherwise).

--
Stefan Kahrs