3 Apr 06:46 2007

### Re: Mathematics in Haskell

Wouldn't this be a good discussion for the Haskell Prime List?

Reilly Hayes
+1 415 388 3903 (office)
+1 415 846 1827 (mobile)

On Apr 2, 2007, at 3:24 PM, Andrzej Jaworski wrote:

I too was put off by the Num issues though--strange mixture of sophisticated
category theory and lack of a sensible hierarchy of algebraic objects.

Perhaps we should replace CT with lattice theoretic thinking (e.g. functor = monotonic
function) before cleaning up the type-related mess?

so count me in on an effort to make Haskell more mathematical.  For me that
probably starts with the semigroup/group/ring setup, and good
arbitrary-precision as well as approximate linear algebra support.

I agree: semigoups like lattices are everywhere.
Then there could be a uniform treatment of linear algebra, polynomial equations, operator
algebra, etc. So, perhaps haste is not a good advice here?

-Andrzej

_______________________________________________

```_______________________________________________
```
6 Apr 21:07 2007

### Literate Haskell specification

```
As I brought up earlier in Haskell-cafe
, 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
```
14 Apr 03:43 2007

### General pattern bindings

```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
```
14 Apr 04:24 2007

### Re: General pattern bindings

```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
```
14 Apr 12:45 2007

### Re: General pattern bindings

```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
```
15 Apr 11:06 2007

### Re: General pattern bindings

```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@...
```
16 Apr 13:04 2007

### Re: General pattern bindings

```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
```
18 Apr 02:18 2007

### Relax the restriction on Bounded derivation

```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
```
18 Apr 02:41 2007

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

```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
```
18 Apr 05:05 2007

### Re: Relax the restriction on Bounded derivation

On 4/17/07, Neil Mitchell <ndmitchell-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

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.

In general, I like the idea of of allowing more flexible derivation of Bounded, but I'm worried your specific proposal ends up mandating the derivation of Bounded instances for types that aren't really "bounded" (used in a deliberately loose sense). Consider the following type:

data Foo = A Char | B Integer | C Int

On some level, there's no real problem in creating a Bounded instance as follows (which is how I interpret your proposal):

instance Bounded Foo
minBound  =  A (minBound :: Char)
maxBound =  C (maxBound :: Int)

On the other hand, there's a real sense in which the type isn't actually "bounded". For instance, if it was also an instance of Enum, enumerating all of the values from minBound to maxBound might not terminate. I'm not sure what to do about the scenario. Should we (unnecessarily) insist that all of the arguments of all of the constructors be Bounded to avoid this? Should Bounded more explicitly document what properties the minBound, maxBound and the type should satisfy? Or something else?

- Ravi
```_______________________________________________