headers
Isaac Jones | 1 Jun 2004 20:49

new Library Infrastructure spec.

(followups to libraries <at> haskell.org)

Hail Haskellers! 

A commonly-identified obstacle to the spread of Haskell libraries is
that there is no standard way

   a) for authors to package a library or other tool for distribution
      to others

   b) for customers to install such a package

Platforms vary.  Haskell compilers vary.  Packages have
dependencies. Etc.

Isaac Jones has coordinated an effort to address this problem.  We've
had a lot of discussion between him and (at least some of) the folk
involved in the GHC, Hugs, and nhc implementations.  This discussion
has led to a new concrete proposed specification[1].  Here it is:
http://www.haskell.org/libraryInfrastructure/proposal

See also the project home page:
http://www.haskell.org/libraryInfrastructure/

We would welcome your feedback, either as a potential library or tool
author, or as a potential consumer, or both.  The specification isn't
complete in every detail, but it seems better to post it before
investing in details that may be rendered void by subsequent
discussion.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nathan Weston | 2 Jun 2004 01:04
Favicon

emacs haskell-mode indentation

I am learning haskell from "The Haskell School of Expression", and finding the 
indentation in the emacs mode rather unhelpful. When I try to type in the 
following example from the book:

main = runGraphics (
       do w <- openWindow "Graphics" (300,300)
          drawInWindow w (text(100,200) "Hello, world!")
          k <- getKey w
          closeWindow w       
		   )

emacs wants to indent it like so:

main = runGraphics (
       do w <- openWindow "Graphics" (300,300)
       drawInWindow w (text(100,200) "Hello, world!")
       k <- getKey w
       closeWindow w       
		   )

(For those not using a fixed-width font, in the first example, everything 
lines up under the 'w <-', in the second, everything lines up under the 'do')

If I let emacs have its way, I get a syntax error.
Am I doing something wrong here? Is the emacs mode broken?

Thanks,
Nathan
Permalink | Reply | 1 comment |
headers
Jeremy Shaw | 2 Jun 2004 01:59

Re: emacs haskell-mode indentation

At Tue, 1 Jun 2004 19:04:56 -0400,
Nathan Weston wrote:
> 
> I am learning haskell from "The Haskell School of Expression", and finding the 
> indentation in the emacs mode rather unhelpful. When I try to type in the 
> following example from the book:
> 
> main = runGraphics (
>        do w <- openWindow "Graphics" (300,300)
>           drawInWindow w (text(100,200) "Hello, world!")
>           k <- getKey w
>           closeWindow w       
> 		   )
> 
> emacs wants to indent it like so:
> 
> main = runGraphics (
>        do w <- openWindow "Graphics" (300,300)
>        drawInWindow w (text(100,200) "Hello, world!")
>        k <- getKey w
>        closeWindow w       
> 		   )
> 
> (For those not using a fixed-width font, in the first example, everything 
> lines up under the 'w <-', in the second, everything lines up under the 'do')
> 
> If I let emacs have its way, I get a syntax error.
> Am I doing something wrong here? Is the emacs mode broken?

The emacs mode definately leaves much to be desired, you could try
(Continue reading)

Permalink | Reply | 0 comments |
headers
Graham Klyne | 2 Jun 2004 12:31

Re: how to write a list builder? fixpoint?

[moved to Haskell-cafe]

This makes my head hurt!  Let me see if I get this right.

When the type checker sees:

    build' as a a2 ...

then it invokes the second instance of BuildList (i.e. BuildList a (a->r)) 
and returns the value:

    build'(a:as) a2 ...

But when it sees just:

   build' as a

(as a value, not used as a function application), then the type checker 
invokes the first instance and returns:

   reverse$ a:as

So they key here appears to be that the type-checker can distinguish 
between function application and other uses of an expression?

#g
--

At 18:18 01/06/04 -0700, oleg <at> pobox.com wrote:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ron de Bruijn | 7 Jun 2004 21:19
Picon
Favicon

Join and it's relation to >>= and return

Hello,

The last 3 or 4 days I have been studying a lot of
Category Theory so that I would be able to explain the
concept of a monad to some people at the university in
a "learn to present something"-course. 

newtype S a = State -> (a,State) -- functor T to map
objects 
mapS::(a-> b) -> (S a -> S b)  -- functor T to map 
morphisms 
unitS :: a -> S a  --\eta 
joinS::S(S a)-> S a -- \mu

This is a complete monad using a direct mapping from
Category Theory. I really like it, because it's
mathematically grounded. But I don't know how to map
this to Haskell monads using the standard "bind" and
"return", as I explain below. 

Although, I do believe I understand most parts of
it(as in Functor, Natural Transformation and so on), 
I don't really understand how the join function
(conventional monadic multiplication as it's called in
the documentation) relates to the >>= and return
functions that are mostly used. I read somewhere at
Google that join can be expresed in terms of >>= and
return, but I couldn't find it anymore. 

I also read that the Kleisli triple has more
(Continue reading)

Permalink | Reply | 1 comment |
headers
Scott Turner | 7 Jun 2004 23:53
Picon
Favicon

Re: Join and it's relation to >>= and return

On 2004 June 07 Monday 15:19, Ron de Bruijn wrote:
> newtype S a = State -> (a,State) -- functor T to map
> objects
> mapS::(a-> b) -> (S a -> S b)  -- functor T to map
> morphisms
> unitS :: a -> S a  --\eta
> joinS::S(S a)-> S a -- \mu
>
> This is a complete monad using a direct mapping from
> Category Theory. I really like it, because it's
> mathematically grounded. But I don't know how to map
> this to Haskell monads using the standard "bind" and
> "return", as I explain below.

Wadler's "The Essence of Functional Programming" goes into monads to the point 
of relating map, unit, and join to bind and return.
http://homepages.inf.ed.ac.uk/wadler/topics/monads.html
Permalink | Reply | 0 comments |
headers
S. Alexander Jacobson | 7 Jun 2004 23:58

forkIO preemption

When you forkIO and one of the threads blocks
(e.g. on a socket or a readchan), do execution
automatically resume on other threads and does the
blocked thread consume timeslices while it is
blocked?

In other words, is there any performance
penalty in setting timeslices very large in a
server app (where all I care about is throughput)?

-Alex-

_________________________________________________________________
S. Alexander Jacobson                  mailto:me <at> alexjacobson.com
tel:917-770-6565                       http://alexjacobson.com
Permalink | Reply | 0 comments |
headers
Ralf Laemmel | 8 Jun 2004 15:01
Picon
Picon
Favicon

Re: Modelling Java Interfaces with Existential data types

Hi Mike,

Let's redirect to Haskell cafe.
http://www.mail-archive.com/glasgow-haskell-users%40haskell.org/msg06288.html
http://www.mail-archive.com/glasgow-haskell-users%40haskell.org/msg06289.html

thanks for your time to look into the HList paper.

>1. It looks like your HList is basically a "sugarized" version of
>
>data AnyMyInterface = Impl1 MyImplementation1 | Impl2 MyImplementation2
>
>with the same drawback: you require me to explicitly list all the possible
>implementations of my interface

I don't think that anything was required to be explicit:

If you mean this here:

type MyList =  MyImplementation1
           :*: MyImplementation2
           :*: HNil

... then note that this type is inferred!

So with HLists, there is nothing like your Impl1 and Impl2,
and no new datatype like your AnyMyInterface.

Just for clarity:
(Continue reading)

Permalink | Reply | 6 comments |
headers
Ron de Bruijn | 8 Jun 2004 22:45
Picon
Favicon

Re: Join and it's relation to >>= and return

I am pretty sure, that >>= is to monads what * is to
for example natural numbers, but I don't know what the
inverse of >>= is. And I can't really find it anywhere
on the web(papers, websites, not a single sole does
mention it. 

It should have type, at least that's what I think:
inv::M a->M b

I say this, because I find this definition of a
multiplication operation:

   1. There exists a unique special element called
neutral such that the operation on any element and the
neutral does not change the element.
   2. For every element there exists an inverse such
that the operation on an element and its inverse is
always neutral.
   3. The operation is associative: it does not matter
how you apply the operation to three elements. You may
apply it to the first two and then to the result and
the third element. Or you may first apply the
operation to the last two and then to the first and
the result of the previous operation. 

An operation may also be commutative

   4. The order of two elements in operation is not
important.
(Continue reading)

Permalink | Reply | 503 comments |
headers
Iavor S. Diatchki | 8 Jun 2004 23:50
Picon

Re: Join and it's relation to >>= and return

hi ron,

here are the relations between the two formulations of monads:
(using haskell notation)

map f  m     = m >>= (return . f)
join m         = m >>= id

m >>= f      = join (fmap f m)

there are quite a few general concepts that you need
to understand in what sense monads are monoids, but
to understand how monads work you don't need to know that.

Ron de Bruijn wrote:

>I am pretty sure, that >>= is to monads what * is to
>for example natural numbers, but I don't know what the
>inverse of >>= is. And I can't really find it anywhere
>on the web(papers, websites, not a single sole does
>mention it. 
>  
>
this is not quie correct.  (join & return) for a monad are like
(*,1) or (+,0) for the set of integers.  however those operations on
integers have more structure than join and return.

there is no operation for "inverse". in mathematical terms:
monads are a monoid (given that the notion is generalized considerably
from its usual use), and not a group.
(Continue reading)

Permalink | Reply | 502 comments |

Gmane