1 Jun 2004 20:49

### new Library Infrastructure spec.

(followups to libraries <at> haskell.org)

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:

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.



2 Jun 2004 01:04

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

2 Jun 2004 01:59

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


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:



7 Jun 2004 21:19

### 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
"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


7 Jun 2004 23:53

### 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
> "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.

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

8 Jun 2004 15:01

### Re: Modelling Java Interfaces with Existential data types

Hi Mike,

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:



8 Jun 2004 22:45

### 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.



8 Jun 2004 23:50

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

hi ron,

here are the relations between the two formulations of monads:

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.