R Hayes | 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

_______________________________________________
Haskell-Cafe mailing list

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Isaac Dupree | 6 Apr 21:07 2007
Picon

Literate Haskell specification


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
Twan van Laarhoven | 14 Apr 03:43 2007
Picon

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
Stefan O'Rear | 14 Apr 04:24 2007
Picon
Picon

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
Neil Mitchell | 14 Apr 12:45 2007
Picon

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
Bulat Ziganshin | 15 Apr 11:06 2007
Picon

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

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
Neil Mitchell | 18 Apr 02:18 2007
Picon

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
Stefan O'Rear | 18 Apr 02:41 2007
Picon
Picon

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
Ravi Nanavati | 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
_______________________________________________
Haskell-prime mailing list
Haskell-prime@...
http://www.haskell.org/mailman/listinfo/haskell-prime

Gmane