A list to discuss Haskell', the next revision of the programming language Haskell. ()

headers R Hayes | 3 Apr 2007 06:46

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

As I brought up earlier in Haskell-cafe
http://thread.gmane.org/gmane.comp.lang.haskell.cafe/20026
, the Haskell98 specification for literate haskell (report section 9.4)
could use some work, at least clarifications (existing haskell
implementations differ in some ways) - see that thread for details.
Since I haven't successfully gotten to writing a concrete revision of
that section, I thought I'd at least bring the issue to the attention of
specifically haskell-prime people, as it is an issue that "should
definitely" be addressed in the Report.  Hopefully there's someone
around here who might tackle it :)

Good luck,
Isaac

In the interest of removing things from the standard, I found this in 
the Haskell 98 report (section 4.4.3.2):

 > The general form of a pattern binding is p match, where a match is the
 > same structure as for function bindings above; in other words, a
 > pattern binding is:
 >
 > p 	| g1 	= e1
 >	| g2 	= e2
 >	...
 >	| gm 	= em
 >	where { decls }

I did not even know these things existed, is there anyone who actually 
uses general pattern bindings?

If not, the question becomes whether removing these bindings would 
improve the language. It can be argued that it makes the language less 
consistent. Declarations would change from

 > decl   ->    (funlhs | pat0) rhs
 > rhs    ->    = exp [where decls]
 >        |     gdrhs [where decls]

to something like

 > decl   ->    funlhs rhs
 >        |     pat0 srhs
 > srhs   ->    = exp [where decls]
 > rhs    ->    srhs
 >        |     gdrhs [where decls]

On the other hand, we can remove most of section 4.3.2.2.

Any opinions?

Twan

On Sat, Apr 14, 2007 at 03:43:03AM +0200, Twan van Laarhoven wrote:
> In the interest of removing things from the standard, I found this in 
> the Haskell 98 report (section 4.4.3.2):
> 
> > The general form of a pattern binding is p match, where a match is the
> > same structure as for function bindings above; in other words, a
> > pattern binding is:
> >
> > p 	| g1 	= e1
> >	| g2 	= e2
> >	...
> >	| gm 	= em
> >	where { decls }
> 
> I did not even know these things existed, is there anyone who actually 
> uses general pattern bindings?
> 
> If not, the question becomes whether removing these bindings would 
> improve the language. It can be argued that it makes the language less 
> consistent. Declarations would change from
> 
> > decl   ->    (funlhs | pat0) rhs
> > rhs    ->    = exp [where decls]
> >        |     gdrhs [where decls]
> 
> to something like
> 
> > decl   ->    funlhs rhs
> >        |     pat0 srhs
> > srhs   ->    = exp [where decls]
> > rhs    ->    srhs
> >        |     gdrhs [where decls]
> 
> On the other hand, we can remove most of section 4.3.2.2.
> 
> Any opinions?

At one point vty defined the standard colors using the following wonderfully elegant code:

[black, red, green, yellow, blue, magenta, cyan, white] = map Color [0..7]

Unfortunately ghc generated hideous code for this, so I had to inline
it manually.  So it goes.  (yow, what got into me there?)

I'm pretty sure I've seen this once or twice:

(x,y) | someCondition = x y z
      | otherwise     = b a r

Stefan

Hi Twan,

> > In the interest of removing things from the standard, I found this in
> > the Haskell 98 report (section 4.4.3.2):

Great idea to remove things, but keep your hands off extended pattern
guards! I've got at least 3 instances of that in the module that is
currently open on my screen. I've got loads of it everywhere, its
great.

If you are looking for things to remove, I'd look in the direction of
n+k patterns 

Thanks

Neil

Hello Twan,

Saturday, April 14, 2007, 5:43:03 AM, you wrote:

> I did not even know these things existed, is there anyone who actually
> uses general pattern bindings?

b:kb:mb:gb:_ = iterate (1024*) 1

unfortunately, they got monotypes, so at last end i finished with
simpler definitions

nevertheless, i think that this feature should remain. in particular,
it may be required for initialization via unsafePerformIO:

(hin,hout) = unsafePerformIO $ do
                runProcess "sh"

--

-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@...

Twan van Laarhoven <twanvl@...> wrote:

>  > The general form of a pattern binding is p match, where a match is
>  > the same structure as for function bindings above; in other words,
>  > a pattern binding is:
>  >
>  > p 	| g1 	= e1
>  >	| g2 	= e2
>  >	...
>  >	| gm 	= em
>  >	where { decls }
> 
> I did not even know these things existed, is there anyone who actually
> uses general pattern bindings?

It is worth mentioning that such pattern bindings are not only used at
the top-level - they are also valid in local definitions, where the
guards may involve variables bound at an outer scope.  This makes them
highly useful.

Regards,
    Malcolm

Hi,

>From Section 10 of the Haskell report, regarding automatic derivation:

to derive Bounded for a type: "the type must be either an enumeration
(all constructors must be nullary) or have only one constructor."

This seems a very artificial restriction - since it allows you to be
in any one of two camps, but no where in between. It also means that
Either doesn't derive Bounded, while it could easily do so:

instance (Bounded a, Bounded b) => Bounded (Either a b) where
    minBound = Left minBound
    maxBound = Right maxBound

So I propose that this restriction be lifted, and that the obvious
extension be given such that minBound is the lowest constructor with a
pile of minBounds, and maxBound is the highest constructor with a pile
of maxBound.

This proposal has been implemented in Derive:
http://www-users.cs.york.ac.uk/~ndm/derive/

Thanks

Neil

Given:

data X = (:*){ x :: Int, y :: Int }  deriving(Show)

which is syntactically correct:

> constr -> con { fielddecl[1] , ... , fielddecl[n] } (n>=0)
> con -> ( consym )

and the following from 10.4:

     * If the constructor is defined to be an infix operator, then the
       derived Read instance will parse only infix applications of the
       constructor (not the prefix form). 

     * If the constructor is defined using record syntax, the derived
       Read will parse only the record-syntax form, and furthermore,
       the fields must be given in the same order as the original
       declaration. 

the behavor of the Show instance seems to be contradicted, since :+ is
an infix operator and is defined using record syntax. 

Suggested resolution:

     * If the constructor is defined using infix syntax, then the
       derived Read instance will parse only infix applications of the
       constructor (not the prefix form). 

Thus, 'data X = Int :+ Int' would show infix but 'data X = (:+) Int
Int' would not. 

Alternatively, change the con in the above production for constr to
conid, thus banning infix record constructors. 

Status:

stefan <at> stefans:/tmp$ cat Main.hs
data X = (:*) { x :: Int, y :: Int } deriving(Show)

main = print ((:*) 2 2)
stefan <at> stefans:/tmp$ runghc Main.hs
(:*) {x = 2, y = 2}
stefan <at> stefans:/tmp$ runhugs Main.hs
:* {x = 2, y = 2}
stefan <at> stefans:/tmp$ yhc Main.hs
Compiling Main             ( Main.hs )
stefan <at> stefans:/tmp$ yhi Main.hbc
2 :* 2
stefan <at> stefans:/tmp$

Note that the hugs output for this corner case is unparseable and thus
buggy!

Stefan

_______________________________________________
Haskell-prime mailing list
Haskell-prime@...
http://www.haskell.org/mailman/listinfo/haskell-prime

Mon	Tue	Wed	Thu	Fri	Sat	Sun

						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30

31	May 2013
11	April 2013
1	March 2013
21	February 2013
1	January 2013
20	December 2012
14	November 2012
18	October 2012
2	September 2012
10	August 2012
14	July 2012
7	June 2012
8	May 2012
4	April 2012
132	March 2012
34	February 2012
3	December 2011
1	October 2011
11	September 2011
4	August 2011
8	July 2011
65	June 2011
19	May 2011
34	April 2011
19	February 2011
37	January 2011
5	December 2010
25	November 2010
1	October 2010
13	September 2010
1	August 2010
60	July 2010
4	June 2010
19	May 2010
10	April 2010
7	March 2010
74	February 2010
2	January 2010
7	December 2009
19	November 2009
18	October 2009
22	September 2009
55	August 2009
147	July 2009
23	June 2009
2	April 2009
52	March 2009
8	February 2009
22	January 2009
4	December 2008
11	November 2008
12	October 2008
2	September 2008
24	August 2008
1	July 2008
11	June 2008
37	May 2008
224	April 2008
48	March 2008
10	January 2008
5	November 2007
12	October 2007
6	September 2007
11	August 2007
32	July 2007
23	June 2007
40	May 2007
16	April 2007
41	March 2007
85	February 2007
69	January 2007
43	December 2006
113	November 2006
129	October 2006
56	September 2006
67	August 2006
12	July 2006
69	May 2006
304	April 2006
371	March 2006
598	February 2006
218	January 2006

Re: Mathematics in Haskell

Literate Haskell specification

General pattern bindings

Re: General pattern bindings

Re: General pattern bindings

Re: General pattern bindings

Re: General pattern bindings

Relax the restriction on Bounded derivation

Apparent contradiction in H98 prescribed behavior of 'data X = (:+){ x :: Int, y :: Int } deriving(Show)'

Re: Relax the restriction on Bounded derivation