Re: [Haskell-cafe] lazy evaluation is not complete

[George Pollard]

On Tue, 2009-02-10 at 08:03 +0100, Thomas Davie wrote:
> On 10 Feb 2009, at 07:57, Max Rabkin wrote:
> 
> > On Mon, Feb 9, 2009 at 10:50 PM, Iavor Diatchki
> >  wrote:
> >> I 0 * _   = I 0
> >> I x * I y = I (x * y)
> >
> > Note that (*) is now non-commutative (w.r.t. _|_). Of course, that's
> > what we need here, but it means that the "obviously correct"
> > transformation of
> 
> just to improve slightly:
> 
> I 0 |* _   = I 0
> I x |* I y = I (x * y)
> 
> _ *| I 0   = I 0
> I x *| I y = I (x * y)
> 
> I x * | y = (I x |* I y) `unamb` (I x *| I y)
> 
> Now it is commutative :)
> 
> Bob

See `parCommute` from the 'lub' package :)


signature.asc
Description: This is a digitally signed message part
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANN: convertible (first release)

[Daniel Schüssler]

Hi,

On Wednesday 28 January 2009 04:30:07 John Goerzen wrote:
> On Tue, Jan 27, 2009 at 09:41:30PM -0500, wren ng thornton wrote:

> > I once again point out that realToFrac is *wrong* for converting from
> > Float or Double.
> >
> > > realToFrac (1/0::Float) ::Double
> >
> > 3.402823669209385e38
>
> Yes, I understand what you are saying and agree with you.  But there
> is nothing better in the standard library

don't know whether you consider GHC as standard library, but if you do...:

import GHC.Types
import GHC.Prim

-- | Double to Float
d2f  (D# d) = F# (double2Float# d)

-- | Float to Double
f2d  (F# f) = D# (float2Double# f)


ghci> f2d (1/0)
Infinity
it :: Double

:)

--
Daniel
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] lazy evaluation is not complete

[Thomas Davie]

On 10 Feb 2009, at 07:57, Max Rabkin wrote:


On Mon, Feb 9, 2009 at 10:50 PM, Iavor Diatchki
 wrote:

I 0 * _   = I 0
I x * I y = I (x * y)


Note that (*) is now non-commutative (w.r.t. _|_). Of course, that's
what we need here, but it means that the "obviously correct"
transformation of


just to improve slightly:

I 0 |* _   = I 0
I x |* I y = I (x * y)

_ *| I 0   = I 0
I x *| I y = I (x * y)

I x * | y = (I x |* I y) `unamb` (I x *| I y)

Now it is commutative :)

Bob
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] lazy evaluation is not complete

[Max Rabkin]

On Mon, Feb 9, 2009 at 10:50 PM, Iavor Diatchki
 wrote:
>  I 0 * _   = I 0
>  I x * I y = I (x * y)

Note that (*) is now non-commutative (w.r.t. _|_). Of course, that's
what we need here, but it means that the "obviously correct"
transformation of

> foo x = if x == 0 then 0 else foo (x - 1) * foo (x + 1)

into

foo' x = if x == 0 then 0 else foo' (x + 1) * foo' (x - 1)

is *not* in fact correct.

--Max
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] lazy evaluation is not complete

[Iavor Diatchki]

Hi,
Just for fun, here is the code that does this:

newtype Int' = I Int deriving Eq

instance Show Int' where
  show (I x) = show x

instance Num Int' where
  I x + I y = I (x + y)

  I 0 * _   = I 0
  I x * I y = I (x * y)

  I x - I y = I (x - y)

  abs (I x) = I (abs x)

  signum (I x)  = I (signum x)

  negate (I x)  = I (negate x)

  fromInteger n = I (fromInteger n)

foo x = if x == 0 then 0 else foo (x - 1) * foo (x + 1)

*Main> foo 5 :: Int'
0

-Iavor


On Mon, Feb 9, 2009 at 7:19 AM, Jochem Berndsen  wrote:
> Peter Padawitz wrote:
>> A simplied version of Example 5-16 in Manna's classical book
>> "Mathematical Theory of Computation":
>>
>> foo x = if x == 0 then 0 else foo (x-1)*foo (x+1)
>>
>> If run with ghci, foo 5 does not terminate, i.e., Haskell does not look
>> for all outermost redices in parallel. Why? For efficiency reasons?
>>
>> It's a pity because a parallel-outermost strategy would be complete.
>
> (*) is strict in both arguments for Int. If you want to avoid this, you
> could do
> newtype X = X Int
> and write your own implementation of (*) that is nonstrict.
>
> --
> Jochem Berndsen | joc...@functor.nl
> GPG: 0xE6FABFAB
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Monad explanation

[Bernie Pope]

On 10/02/2009, at 4:45 AM, Tillmann Rendel wrote:


A Haskell runtime system is a somewhat vaguely specified interpreter  
for (IO a) values. While it would be nice to a have a better  
specification of that interpreter, it is not part of the semantics  
of the language Haskell.


While not "official", there is always "Tackling the awkward squad:  
monadic input/output, concurrency, exceptions, and foreign-language  
calls in Haskell" by Simon Peyton Jones.


   https://research.microsoft.com/en-us/um/people/simonpj/papers/marktoberdorf/

Another nice aspect of that paper is that it discusses some of the  
difficulties in coming up with a denotation for values of type IO a,  
see particularly section 3.1. It suggests a set of event traces as a  
possible way forward:


   type IO a = (a, Set Trace)
   type Trace = [Event]
   data Event = PutChar Char | GetChar Char | ...

(Incidentally, this view is quite useful in a declarative debugger,  
which emphasises the denotational semantics of a program.)


In the end the paper goes for an operational semantics, on the grounds  
that the author finds it "simpler and easier to understand".


Cheers,
Bernie.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] evaluation semantics of bind

[wren ng thornton]

Gregg Reynolds wrote:

Tillmann Rendel wrote:
> An example where it would be wrong to ignore e:
>
>  sum ([1, 2] >>= const [21])
>
> This expression should evaluate to sum [21, 21] = 42, not sum [21] = 21.
>

Sigh.  I hate it when this happens.  Just when I thought I had it figured
out, it turns out I'm clueless.  This is very enlightening and should
definitely be included in any monad tutorial.  Actually you don't even need
"sum" and "const" to demo the point,  "[1,2] >>= \x -> [21]" evals to "[21,
21]" in ghci.  And I have absolutely no idea why.  Very mysterious, the
Kleisli star.  :(


Just walk through the evaluation step by step, it's not so mysterious.

[1,2] >>= \x -> [21]
  == {CT definition of bind}
join . fmap (\x -> [21]) $ [1,2]
  ==
join [(\x -> [21]) 1, (\x -> [21]) 2]
  ==
join [[21],[21]]
  ==
[21,21]

Or if you prefer to use the Haskell function definitions instead of the 
category theory definitions (it's all the same):


[1,2] >>= \x -> [21]
  ==
concatMap (\x -> [21]) [1,2]
  ==
concat . map (\x -> [21]) $ [1,2]
  ==
concat [(\x -> [21]) 1, (\x -> [21]) 2]
  ==
concat [[21],[21]]
  ==
[21,21]


This is exactly the point I was raising earlier. The "statefullness" of 
monads has nothing to do with IO, but every monad has some of it. In 
general it is wrong to throw it away just because the function passed to 
bind happens to ignore the value associated with it. There are some 
cases where that can be correct, but in general it is not.


For lists, we can envision the statefullness as a path through a 
decision tree. To get the intuition right, it's easiest to pretend that 
we never call join (or that join does nothing). If we don't call join, 
eventually after a number of binds or maps we'll end up with some value 
of type [[...[a]...]]. We can draw that value out as a B-tree where each 
level has a branch of whatever arity it needs. In this B-tree, every 
leaf is associated with a unique path through the tree and therefore 
they can be distinguished.


The reason the above example works the way it does is that the initial 
list has two leaves each associated with their unique paths through this 
 tree of choices. The function passed into bind is a continuation of 
sorts. So, given that we can non-deterministically choose either of the 
paths in the original tree, for each choice we must then continue with 
(\x -> [21]) applied to the seed value for that choice (1 or 2, as 
appropriate). Because we had two choices initially, and from there we 
have only one choice, we will have 2*1 choices in the end:


   /\
  /  \
 (1) (2)
  |   |
  |   |
 21   21


If we imagine a finite state automaton, we might think that the two 21s 
could be collapsed together since they represent the same "state". But 
that is not so: the list monad is for *paths* through an FSA not for 
states in an FSA. (For states in an FSA we'd want the set monad 
instead.) Of course for the list monad we don't actually keep around the 
decision tree. In fact lists generalize over all possible decision trees 
which could yield the given distribution of path-endpoints, so it's not 
quite the way envisioned above.


--
Live well,
~wren
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] evaluation semantics of bind

[David Menendez]

2009/2/9 Gregg Reynolds :
> On Mon, Feb 9, 2009 at 11:06 AM, Tillmann Rendel  wrote:
>>
>> Gregg Reynolds wrote::
>>>
>>> My original question was motivated by the observation that a human reader
>>> of
>>> an expression of the form "e >>= f" , on seeing that f is constant, may
>>> pull
>>> the constant value out of f, disregard e and dispense with the
>>> application f
>>> e.
>>
>> While a human reader may well do that, but it would be correct or wrong
>> depending on the definition of >>=. The same is of course true for
>> compilers. By the way, there is no "application f e".
>
> I guess it would help if I got the notation right.  My intended meaning was
> f* e, where * is the Kleisli star.  Sorry about that.

You can't assume f* is a constant function just because f is. In fact,
in most monads (excluding Identity and Reader) f* is never constant.

>> An example where it would be wrong to ignore e:
>>
>>  sum ([1, 2] >>= const [21])
>>
>> This expression should evaluate to sum [21, 21] = 42, not sum [21] = 21.
>
> Sigh.  I hate it when this happens.  Just when I thought I had it figured
> out, it turns out I'm clueless.  This is very enlightening and should
> definitely be included in any monad tutorial.  Actually you don't even need
> "sum" and "const" to demo the point,  "[1,2] >>= \x -> [21]" evals to "[21,
> 21]" in ghci.  And I have absolutely no idea why.  Very mysterious, the
> Kleisli star.  :(

Here are two ways to think about it.

First, you can decompose the Kleisli star into two operations. That
is, for a monad T with multiplication mu,

   f* = mu . T f

Or in Haskell notation,

(f =<<) = join . fmap f

For the list monad, join is concat and fmap is map. So we have,

  [1,2] >>= \x -> [21]
= concat (map (\x -> [21])) [1,2]
= concat [[21],[21]]
= [21,21]

Second, in the list monad, we have a distributive law relating mplus and >>=.

mplus x y >>= f = mplus (x >>= f) (y >>= f)

We can rewrite [1,2] >>= \x -> [21] as

mplus (return 1) (return 2) >>= \x -> return 21

then we can distribute >>=,

mplus (return 1 >>= \x -> return 21) (return 2 >>= \x -> return 21)

then by the monad laws,

mplus (return 21) (return 21)

-- 
Dave Menendez 

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] evaluation semantics of bind

[Richard O'Keefe]

On 10 Feb 2009, at 5:07 pm, Gregg Reynolds wrote:
Thanks.  I see the error of my ways.  So, IO expressions must be  
evaluated if they are in the chain leading to main.



We need some standard terminology to distinguish
between *evaluating* an expression and *performing*
the result of an expression of type IO something.

An IO expression that is passed to a function at a
strict position must be evaluated whether the result
is performed or not.

An IO expression whose result will be performed must
be evaluated before that performance can take place.

(Dash it, this really is getting us into White Knight land.)

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] evaluation semantics of bind

[Gregg Reynolds]

On Mon, Feb 9, 2009 at 8:37 PM, Richard O'Keefe  wrote:

>
> There isn't any "application f e".
> Any human reader who does that is simply WRONG to do so.
>

Sorry, should have written f*

>
> In your fragmentary example,  may be discarded
> EVEN IF it contains IO expressions, it's only if they are linked into
> the IO chain using >> and/or >>= that the environment will perform
> their values.
>

Thanks.  I see the error of my ways.  So, IO expressions must be evaluated
if they are in the chain leading to main.

-gregg
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] evaluation semantics of bind

[Gregg Reynolds]

On Mon, Feb 9, 2009 at 11:06 AM, Tillmann Rendel  wrote:

> Gregg Reynolds wrote::
>
>> My original question was motivated by the observation that a human reader
>> of
>> an expression of the form "e >>= f" , on seeing that f is constant, may
>> pull
>> the constant value out of f, disregard e and dispense with the application
>> f
>> e.
>>
>
> While a human reader may well do that, but it would be correct or wrong
> depending on the definition of >>=. The same is of course true for
> compilers. By the way, there is no "application f e".
>

I guess it would help if I got the notation right.  My intended meaning was
f* e, where * is the Kleisli star.  Sorry about that.

>
>
> An example where it would be wrong to ignore e:
>
>  sum ([1, 2] >>= const [21])
>
> This expression should evaluate to sum [21, 21] = 42, not sum [21] = 21.
>

Sigh.  I hate it when this happens.  Just when I thought I had it figured
out, it turns out I'm clueless.  This is very enlightening and should
definitely be included in any monad tutorial.  Actually you don't even need
"sum" and "const" to demo the point,  "[1,2] >>= \x -> [21]" evals to "[21,
21]" in ghci.  And I have absolutely no idea why.  Very mysterious, the
Kleisli star.  :(

Back to the drawing board!

-gregg
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Haskell Fest

[Benjamin L . Russell]

On Mon, 9 Feb 2009 16:54:15 -0800, Lyle Kopnicky 
wrote:

>Looks like a lot of fun!
>
>http://www.haskellchamber.com/page6.html

They should extend this by adding the domain Virtualhaskellcounty (see
http://whois.domaintools.com/virtualhaskellcounty.com) so we can all
participate!

-- Benjamin L. Russell
-- 
Benjamin L. Russell  /   DekuDekuplex at Yahoo dot com
http://dekudekuplex.wordpress.com/
Translator/Interpreter / Mobile:  +011 81 80-3603-6725
"Furuike ya, kawazu tobikomu mizu no oto." 
-- Matsuo Basho^ 

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] evaluation semantics of bind

[Richard O'Keefe]

On 10 Feb 2009, at 1:35 am, Gregg Reynolds wrote:
My original question was motivated by the observation that a human  
reader of an expression of the form "e >>= f" , on seeing that f is  
constant, may pull the constant value out of f, disregard e and  
dispense with the application f e.


There isn't any "application f e".
Any human reader who does that is simply WRONG to do so.

  So can a compiler, unless IO expressions are involved, in which  
case such optimizations are forbidden.


Remember that (e >>= f) means (>>=) e f.
When/whether it is sound to replace (>>=) e f by (f undefined)
depends on the semantics of >>=.

But >>= is an operation of a type class (the Monad type class).
If we come across

g :: Monad m => m a -> b -> m b
g e r = e >>= \x -> return r

then the compiler doesn't know what m is, so it doesn't know
which, if any, of its arguments >>= depends on.

data Trivial x = Trivial x

instance Monad Trivial
  where return = Trivial
(>>=) (Trivial a) f = f a

If we now try
h :: Trivial a -> b -> Trivial b
h e r = g e r
then the compiler can inline the call to g
h e r = e >>= \x -> return r
and inline the calls to >>= and return
h (Trivial a) r = (\x -> Trivial r) a
then simplify to
h (Trivial _) r = Trivial r

You might have thought that the result doesn't depend on
the first argument to h, but as written, it does.  This
version of h is strict in its first argument, so even
though there are NO side effects whatever, the first
argument will be evaluated to weak head normal form.

Of course, since there is only one constructor for Trivial,
it could be a newtype.  If I change that declaration to

newtype Trivial x = Trivial x

then the pattern match is implicitly irrefutable,

h ~(Trivial _) r = Trivial r

and if the compiler doesn't simplify ~(NTC _) to _ when NTC
is a newtype constructor, I'll be surprised, so it's like

h _ r = Trivial r

and the function will *NOT* be strict in its first argument.
Here you see that the soundness or otherwise of eliminating
the first argument of >>= when the second argument doesn't
depend on the eventual result has nothing to do with IO as
such and certainly nothing to do with side effects.  It's
really all about whether the version of >>= used is strict
in its first argument or not.


  I wondered if that was due to the semantics of >>= or the  
semantics of IO.


It's about the semantics of IO's implementation of >>=.




To summarize what I've concluded thanks to the helpful people on  
haskell-cafe:


The compiler can optimize e >>= f except for any IO expressions in e  
and f.


False.  There is nothing unusual about IO here.


  IO expressions must be evaluated, due to the semantics of IO.


False.


  The may not be disregarded, memoized, or substituted.


False.  In Haskell there is nothing whatever unusual about
expressions of type IO something.  They *MAY* be disregarded:
let n = length [getChar, putChar 'f']
can be optimised to let n = 2.  They MAY be memoised.  They
MAY be substituted.

IO semantics may be implemented in different ways by different  
compilers;


True.  But then, so may Int semantics.

these implementation techniques are not part of the formal semantics  
of the language, which may be expressed as above:  IO expressions  
must be evaluated wherever and whenever they occur.


False. Utterly false.



The bind operator >>= enforces sequencing on arguments containing IO  
expressions, but does not force evaluation.


False.  For the special case of IO (and for other similar monads)
>>= enforced sequence BY forcing evaluation (more precisely, by
being strict in its first argument).


Even bind expressions involving IO may be optimized.  For example:

  getChar >>= \x -> .. putChar 'c'

The compiler may discard  (assuming it contains  
no IO expressions), but it must evaluate getChar and putChar (due to  
IO semantics) in the correct order (due to bind semantics).


You are conflating *evaluating* (by the Haskell evaluator) with
*performance* (by the Haskell environment).  IO *values* are
determined by the Haskell evaluator exactly like any other values;
IO *actions* are performed by the Haskell environment as part of
the process of forcing the lazy evaluator to do some work.

In your fragmentary example,  may be discarded
EVEN IF it contains IO expressions, it's only if they are linked into
the IO chain using >> and/or >>= that the environment will perform
their values.




Thanks all,

gregg


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Haddock Markup

[Richard O'Keefe]

On 10 Feb 2009, at 1:19 am, Wolfgang Jeltsch wrote:
This is only true if your destination format is PDF, DVI or PS. For  
a webpage,
you’ll need MathML in the end and TeX is not so good in producing  
MathML, I

suppose.


Hmm.  I find designed-for-HTML documentation horrible.
In many ways the current Haddock output is the worst
of both worlds:  it is inconvenient for on-screen viewing
and doesn't exploit paper very well either.

Amongst other things, people who are learning a library
package need overviews, examples, conceptual models, all
sorts of details, whereas people who already know them
mainly need reminders, for which web pages are well suited.

I would point out that you DON'T need MathML for a web page,
because a PDF document can *be* a web page.  You can link to
one, you can display it in your browser, and it may contain
links to other pages.

Especially if one can download a tolerably full snapshot of
the library and all its documentation, updating this at rare
intervals, PDF-on-the-local-host suits me much better than
HTML-on-the-Web.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Monad explanation

[Richard O'Keefe]

On 9 Feb 2009, at 9:56 pm, Gregg Reynolds wrote:
Here's an analogy that will make the logical contradiction clear.   
Forget computers and assume you have been asked to referee a paper  
containing a proof with the following passage:


   Let x = ___ (Please fill in the blank)

I think you will agree that would be plainly nonsensical.  It's  
logically equivalent to an input operation ("getInt").


No, I do not agree that it would be nonsensical at all.
Why shouldn't a paper describe a family of proofs?
(paper :: Int -> Proof)

Now back to computers.  Given a program text containing the symbol  
'3', the computer will provide a physical representation: an  
electromagnetic pattern in a bit of silicon.  That's a value; the  
pattern is to be interpreted as a datum; it is not to be executed.


Who says?  It is part of the essence of the stored program computer
that the *same* bit pattern may be computed as numbers and executed
as code.  There have certainly been virtual machines where the bit
pattern for the character '+' meant, when executed, ADD.

  For "getChar", the computer will also provide such a pattern, but  
this pattern is to be interpreted as executable code, not as a datum.


"The computer" here must be understood as "The composite of a physical
machine, HAL/BIOS/whatever-maybe, hypervisor-maybe, operating system-
maybe, Haskell compiler, and Haskell libraries.  (Yes, I know that I
am oversimplifying.)

The expression (getChar) may be represented by executable code,
but then, Haskell being lazy, so may the expression (1+1) be
represented by executable code.

Your problem seems to be based on two fundamental assumptions:
(1) there is an intrinsic difference between code and data,
(2) evaluating getChar reads a character.
Neither assumption is true.
Code and data are interchangeable.
Evaluating getChar yields (without any side effects) a value,
let's call it Gamaliel, and it is the environment's performance
of Gamaliel that reads a character.

So you are seeing a difference when there is none,
and not seeing one where there is one.

  Now suppose we also have an ordinary function like "Add2"; it too  
will be represented as an electromagnetic pattern, to be interpreted  
as executable code.


*AND* as data.
Ever heard of genetic programming?
Genetic programming is a form of evolutionary computing
where members of the population are functions.
Koza's original book used lisp-style trees to represent
these functions (so something was at one and the same time
a tree resulting from genetic operations and used as input
to genetic operations) and executable code.
There have been many variations of the idea since then.
Nowadays some GP systems represent functions by native
machine code.  In such systems, native machine code is
- the result of genetic operators
- data that is input to genetic operators
- native code to be executed
all in the same program within a single "generation".


  getChar and Add2 are not data, except in the trivial sense that  
all code is data.


The sense in which all code is data is far from trivial.
It's what makes things like Windows *possible*.
(Try to imagine booting Windows by plugging wires into
a city-sized backplane!)
It's certainly what makes Genetic Programming possible.

The interesting thing here is that since getChar need not
be a function, its representation inside a computer need
not be machine code.

In all three cases, the symbolic representation is isomorphic to the  
physical representation.


Eh?  This is a very strong and extremely dubious claim.


  The 3 will not be executed.


Who says?  I once used (and still love) a computer which
had Zero and One instructions.  I don't see why you couldn't
have a Three instruction.

  When Add2 is executed, the ensuing process is isomorphic to the  
mathematical function so defined.


The *process* is isomorphic to the *function*?
I think not.

  But when getChar is executed, the ensuing process is not  
isomorphic to a mathematical function.


Yes it is.  You are confusing two very different things here:
Executing (getChar).
Performing the result of (getChar).
For what it's worth, the analogue of getChar in Clean and Mercury
*is* a mathematical function.

  The process interacts with the non-mathematical world, which a  
mathematical function can never do.


But a mathematical function can *describe* that process,
and a computing engine can have its interactions governed
by such a description.
And that's what Haskell does.

  So it has a side effect along with its ordinary representational  
effect.


No.  [The result of] (getChar) is a pure mathematical value.
(It might be or contain a function, but it need not.
It could be the number 42 in drag.)  When the Haskell
environment does what that [result] says to do, then
reading happens.  But the computation of (getChar) and
the reading are DIFFERENT events (notionally) carried
out by DIFFERENT execution engines and happening at
DIFFERENT times.

The po

Re: [Haskell-cafe] Haskell Fest

[Derek Elkins]

On Mon, 2009-02-09 at 16:54 -0800, Lyle Kopnicky wrote:
> Looks like a lot of fun!
> 
> http://www.haskellchamber.com/page6.html

I could readily go there.  Maybe I could pick up a beauty at the
pageant.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Haskell Fest

[Andrew Wagner]

We believe in Haskell!

2009/2/9 Lyle Kopnicky 

> Looks like a lot of fun!
>
> http://www.haskellchamber.com/page6.html
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Haskell Fest

[John Van Enk]

Pie auction and contest? Count me in!
/jve


2009/2/9 Lyle Kopnicky 

> Looks like a lot of fun!
>
> http://www.haskellchamber.com/page6.html
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Monad explanation

[Richard O'Keefe]

On 10 Feb 2009, at 12:24 am, Gregg Reynolds wrote:

My bad, I restate:  a value cannot be both static and dynamic.


It's not clear what you mean here,
but in what sense are "static" values not a subset of "dynamic" ones?


  Or an object and a morphism.


Crack open any book on category theory and you will discover
that an object CAN be a morphism.  Not only can the morphisms
of one category be objects of another, but you can build a
category where the objects and the morphisms are the same things.


  Or an element and a function.


An element of _what_?  Functions can be elements of sets.
Mathematicians routinely deal with function spaces.

If you mean that F : S -> S cannot be an element of S,
then if you mean a set theoretic function, no, but
a Scott domain *can* contain the continuous functions over itself.

  Sure, you can treat a morphism as an object, but only by moving to  
a higher (or different) level of abstraction.


False as a generalisation about mathematics.
False about functional programming languages, the very essence
of which is treating functions ("morphisms") as values ("objects")
exactly like any other values.


  That doesn't erase the difference between object and morphism.


There is no intrinsic difference between objects and morphisms.
It's what you DO with something that makes it an object or a
morphism (or both).

  If you do erase that difference you end up with mush.  getChar / 
looks/ like an object, but semantically it must be a morphism.


getChar is an element of an abstract data type in Haskell.
PERIOD.
Since a morphism is characterised by its source and target
objects, and since getChar is not so characterised, in what
sense is getChar a morphism?

*Within Haskell*, getChar is just some value.  For all you or
I can tell to the contrary, it might be the letter 'G' or a
JPEG image of the planet Mars.  It's only as part of a whole
system of IO primitives in the context of Haskell that the
value is interpreted as a description of the "read a character
from standard input" action.



  But it can't be a function, since it is non-deterministic.


No it isn't.  getChar is perfectly deterministic.  Whenever you
ask for the value of getChar, you get the *same* value.
Evaluating getChar does no input whatever.
If you compute
map (\_ -> getChar) [1..n]
you get a list containing n copies of the value of getChar,
and NO INPUT WHATSOEVER happens.

  So actually the logical contradiction comes from the nature of the  
beast.


There is no logical contradiction because you have mistaken
the nature of the beast.



Another reason it's confusing to newcomers:  it's typed as "IO  
Char", which looks like a type constructor.


Surely "IO" and "Char" are type constructors,
and "Char" and "IO Char" are types.


  One would expect getChar to yield a value of type IO Char, no?


Yes, that's EXACTLY what it does.
The only thing the expression (getChar) ever gives you
is an (abstract) value of type IO Char.


But it delivers a Char instead.


No it doesn't.  getChar delivers, always and only,
a value of type IO Char.  Call that value Gamaliel.
When Gamaliel is *performed* by the Haskell environment,
*then* a character is read (the action) and returned.
But it's Gamaliel that delivers a Char, not getChar.


  This is way confusing.


Composer (Haskell program) writes score (computes getChar).
Performer (Haskell environment) sings score (performs Gamaliel).
Sound happens (a character is read).


  So I take "type IO foo" to mean "type foo, after a side effect".


No.  Mistake not:  there COULD be a type system not unlike that.
Look up "effect systems".  Haskell's is not one of them.
By the way, (return 'x') has type IO Char, but never has any
side effects.  Type "IO foo" can be usefully read as meaning
"descriptions of actions that when carried out also yield a
value of type foo".


  In a sense "getChar :: IO Char" isn't even a true type signature.


Yes it is.  It is exactly and perfectly true.

Have you actually read the classic paper
"How to declare an imperative",
P. Wadler,
ACM Computing Surveys 29, 3 (1997).

For me, this was more helpful than any tutorial on monads and
monadic I/O that I ever read.



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Haskell Fest

[Lyle Kopnicky]

Looks like a lot of fun!

http://www.haskellchamber.com/page6.html
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Monad explanation

[Emilio Jesús Gallego Arias]

egall...@babel.ls.fi.upm.es (Emilio Jesús Gallego Arias) writes:

> IMHO, if you assume IO a = World -> (World, a), then getChar is indeed a
> function and deterministic. It is, there are not w :: World such that
> getChar w != getChar.

Sorry I meant:

There is not w :: World such that getChar w != getChar w.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Monad explanation

[Emilio Jesús Gallego Arias]

Gregg Reynolds  writes:

> But it can't be a function, since it is non-deterministic.  

IMHO, if you assume IO a = World -> (World, a), then getChar is indeed a
function and deterministic. It is, there are not w :: World such that
getChar w != getChar.

The fact that World is too big to be represented in Haskell and we use
IO to simulate it is a different matter.

With regard to your original question, I like to keep in mind that
arrow composition in the Kleisli category (>>= in Haskell) is defined in
terms of the monad's join :: m (m a) -> m a.

Then, the question is, how many ways can you map an IO (IO a) to an IO
a? 

You will find that you cannot ignore the inner (first) IO in order to
obey monad laws.

Regards,

Emilio


pgpwBmin8spHC.pgp
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Painting logs to get a coloured tree

[Luke Palmer]

2009/2/9 Joachim Breitner 

> Now while this works, and while ST is still somewhat pure, I'm wondering
> if there is no better way of expressing "This piece of information came
> from the point in a data structure, so something else can be put here
> easily".


You might want to look into zippers:  http://haskell.org/haskellwiki/Zipper

Luke
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Why does sleep not work?

[John Ky]

Hi Peter,

Source code:
import System.IO
import System.Posix

main = do
  putStrLn "Waiting for 5 seconds."
  sleep 5 -- doesn't sleep at all
  putStrLn "Done."

OS:
Mac OS X 10.5

Compile command:
ghc --threaded testsleep.hs

If I remove --threaded, then it does sleep.

Thanks,

-John

On Tue, Feb 10, 2009 at 8:59 AM, Peter Verswyvelen wrote:

> Hi John,
> Which sleep are you using? From which module? Can you show the full source
> with import statements?
>
> Cheers,
> Peter
>
> 2009/2/9 John Ky 
>
>> Hi Haskell Cafe,
>>
>> I wrote very short program to sleep for 5 seconds compiled with the
>> -threaded option in ghc on the Mac OS X 1.5.
>>
>> I am finding that using the sleep function doesn't sleep at all, whereas
>> using threadDelay does:
>>
>> main = do
>>   putStrLn "Waiting for 5 seconds."
>>   threadDelay 500 -- works
>>   putStrLn "Done."
>>
>> main = do
>>   putStrLn "Waiting for 5 seconds."
>>   sleep 5 -- doesn't sleep at all
>>   putStrLn "Done."
>>
>> Anybody know what's happening?
>>
>> Thanks
>>
>> -John
>>
>>
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Painting logs to get a coloured tree

[Joachim Breitner]

Hi,

I have a problem that, it seems, I can not solve cleanly without
resorting to imperative programming (via ST):

Assume you have a tree (and you can think of a real tree here), defined
by something like this:

data Tree a = Bud | Branch a Double Tree Tree
-- | ` Lenght of this branch
-- ` General storage field for additional information

Now, I have a nice algorithm that calulates something for each branch,
but it only works on lists of branches, so I have to cut them apart
first, remembering their position in space, and then work on these,
well, logs.

data Point = Point Double Double
data Log = Log Point Point
type Info = ...
noInfo :: Info

cutTreeApart :: Tree a -> [(Log, a)]
someAlgorithm :: [(Log,a)] -> [(a, Info)]

Conveniently, the algorithm allows me to tag the logs with something, to
be able to keep track at least somewhat of the logs.

Unfortunately, I need this information in the storage field in my Tree,
as the list of logs is not sufficient for later calculations.

Idea: Using ST
==

annotateTree :: Tree a -> Tree Info
annotateTree tree = runSt $ do
-- Put an STRef in each node
treeWithPointer <- mapM const (newSTRef noInfo) tree
-- Cut this tree apart
let logsWithPointers = cutTreeApart treeWithPointer
-- Run the algorithm
let informations = someAlgorithm logsWithPointers
-- Put the information back, via the ST ref
mapM (\(stRef, info) -> writeSTRef stRef info) informations
-- Read the ST refs
mapM readIORef tree

Note that I assume a instance Traversable Tree here, and mapM is
Data.Traversable.mapM.


Now while this works, and while ST is still somewhat pure, I’m wondering
if there is no better way of expressing "This piece of information came
from the point in a data structure, so something else can be put here
easily".

Some ideas where numbering the Nodes and then using this number as the
tag on the log, but this is not much different from using STRefs, it
seems.

Thanks,
Joachim

-- 
Joachim "nomeata" Breitner
  mail: m...@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C
  JID: nome...@joachim-breitner.de | http://www.joachim-breitner.de/
  Debian Developer: nome...@debian.org


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Why does sleep not work?

[Peter Verswyvelen]

Hi John,
Which sleep are you using? From which module? Can you show the full source
with import statements?

Cheers,
Peter

2009/2/9 John Ky 

> Hi Haskell Cafe,
>
> I wrote very short program to sleep for 5 seconds compiled with the
> -threaded option in ghc on the Mac OS X 1.5.
>
> I am finding that using the sleep function doesn't sleep at all, whereas
> using threadDelay does:
>
> main = do
>   putStrLn "Waiting for 5 seconds."
>   threadDelay 500 -- works
>   putStrLn "Done."
>
> main = do
>   putStrLn "Waiting for 5 seconds."
>   sleep 5 -- doesn't sleep at all
>   putStrLn "Done."
>
> Anybody know what's happening?
>
> Thanks
>
> -John
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Haskell and Java interaction

[Robert Greayer]

I'm sure this isn't the solution you are looking for, but when I had to do 
something similar (integrate an Eclipse plugin to Haskell code) the simplest 
approach I found was to simply invoke the Haskell in a separate process, 
binding the stdin/stdout of the Haskell process to Java output/input streams.  
Perhaps low-tech, but has worked well for me.




- Original Message 
From: Silviu ANDRICA 
To: "haskell-cafe@haskell.org" 
Sent: Monday, February 9, 2009 10:56:40 AM
Subject: [Haskell-cafe] Haskell and Java interaction

Hello,
I was wondering if there is a way to call Haskell code from Java. I tried using 
jvm-bridge(http://sourceforge.net/projects/jvm-bridge/), but I'm stuck on 
building it.

Thank you very much,
Silviu
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe



  
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Why does sleep not work?

[Bulat Ziganshin]

Hello John,

Tuesday, February 10, 2009, 12:35:25 AM, you wrote:

> I am finding that using the sleep function doesn't sleep at all, whereas 
> using threadDelay does:

> Anybody know what's happening?

1) this depends on your sleep definition
2) read threadDelay docs


-- 
Best regards,
 Bulatmailto:bulat.zigans...@gmail.com

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Formal semantics for Haskell?

[Alberto G. Corona]

Gregg,Too late for me, but, anyway. I support the idea of the warning

2009/2/9 gregg reynolds 

> Is that () or _|_? ;)
>
> Tim Newsham  wrote:
>
> >null
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Why does sleep not work?

[John Ky]

Hi Haskell Cafe,

I wrote very short program to sleep for 5 seconds compiled with the
-threaded option in ghc on the Mac OS X 1.5.

I am finding that using the sleep function doesn't sleep at all, whereas
using threadDelay does:

main = do
  putStrLn "Waiting for 5 seconds."
  threadDelay 500 -- works
  putStrLn "Done."

main = do
  putStrLn "Waiting for 5 seconds."
  sleep 5 -- doesn't sleep at all
  putStrLn "Done."

Anybody know what's happening?

Thanks

-John
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Haskell and Java interaction

[John A. De Goes]

The bridging projects are all dead and unsupported. You can still do  
it, but you'll have to write Haskell wrappers that use C types, then  
write C code that calls the wrapped Haskell code, then write JNI code  
to call the C code from Java.


   http://www.haskell.org/haskellwiki/Calling_Haskell_from_C

There was a promising thesis project called LambdaVM that allowed you  
to compile Haskell to JVM byte codes, but it suffered the same fate as  
all thesis projects.


Regards,

John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration

http://www.n-brain.net|877-376-2724 x 101

On Feb 9, 2009, at 8:56 AM, Silviu ANDRICA wrote:


Hello,
I was wondering if there is a way to call Haskell code from Java. I  
tried using jvm-bridge(http://sourceforge.net/projects/jvm-bridge/),  
but I'm stuck on building it.


Thank you very much,
Silviu
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: how to use a literal string with bystring useAsCString

[minh thu]

2009/2/9 minh thu :
> 2009/2/9 Colin Adams :
>> 2009/2/9 minh thu :
>>
>>>
>>> Anyway, I'd like to get my utf-8 string to C but in ascii (or latin1).
>>>
>>> How can do this ?
>>
>> You can't (in general).
>> If the data just happens to be ascii, then your utf-8 string will BE
>> ascii (there is no way to tell the difference). If it just happens to
>> be in the range of latin-1(all codepoints 0-255), then you have to
>> convert it to latin-1. But otherwise, you are stuck.
>
> That's what I thought, but in the code attached before, the output of
> the program is not what is expected, i.e. I have :
> 0xb7d7e018
> 0xb7d7e040
> Why ?
>
> Thu
>

Sorry, in both case, it's a mistake on my side.
In particular, in the attached code, I call 'print' instead
of 'c_print'.

Thu
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: how to use a literal string with bystring useAsCString

[minh thu]

2009/2/9 Colin Adams :
> 2009/2/9 minh thu :
>
>>
>> Anyway, I'd like to get my utf-8 string to C but in ascii (or latin1).
>>
>> How can do this ?
>
> You can't (in general).
> If the data just happens to be ascii, then your utf-8 string will BE
> ascii (there is no way to tell the difference). If it just happens to
> be in the range of latin-1(all codepoints 0-255), then you have to
> convert it to latin-1. But otherwise, you are stuck.

That's what I thought, but in the code attached before, the output of
the program is not what is expected, i.e. I have :
0xb7d7e018
0xb7d7e040
Why ?

Thu
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Haddock Markup

[Heinrich Apfelmus]

Henning Thielemann wrote:
> 
> I want for long to write math formulas in a paper in Haskell. Actually,
> lhs2TeX can do such transformations but it is quite limited in handling
> of parentheses and does not support more complicated transformations
> (transforming prefix notation in infix notation or vice versa with
> minimal parentheses).
> 
> I would like to write
>   sumFor [0..n] (\i -> i^2)
> (with sumFor xs f = sum $ map f xs)
> which is rendered as
>   \sum_{i=0}^{n} i^2
> or
>   integrate 1000 (a,b) (\t -> f t)
> to be rendered as
>   \int_a^b f(t) \dif t

Neat idea! Can't you do implement this as a DSL?

sumFor x xs f =
   "\sum_{" ++ x ++ "=" ++ head xs ++ "}^{" ++ last xs ++ "} "
   ++ f x


Regards,
apfelmus

-- 
http://apfelmus.nfshost.com

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: how to use a literal string with bystring useAsCString

[Colin Adams]

2009/2/9 minh thu :

>
> Anyway, I'd like to get my utf-8 string to C but in ascii (or latin1).
>
> How can do this ?

You can't (in general).
If the data just happens to be ascii, then your utf-8 string will BE
ascii (there is no way to tell the difference). If it just happens to
be in the range of latin-1(all codepoints 0-255), then you have to
convert it to latin-1. But otherwise, you are stuck.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: how to use a literal string with bystring useAsCString

[minh thu]

2009/2/9 minh thu :
> Hi,
>
> I have a Haskell source file encoded in utf-8.
> Inside that source, I have literal strings that I'd
> like to pass to a C function.
>
> withCString does the job well until I tried to use
> the double-quote character ". I get
> /usr/lib/ghc-6.10.1/ghc: `@: Bad font file format
> (even when using (chr 34) instead).
>
> I didn't understand the reason of this behavior (since
> the double quote is just ascii) but
> tried to use useAsCString but coudn't do it.
> I can ByteString.Char8.pack my string but the problem
> remains. I tried to use IConv but it uses UTF8.ByteString
> and I don't know how to make the conversion so I can
> use useAsCString or withCString.

Bulat asked me a minimal example.
I cannot come with the same behavior with ghc --make
and the attached code.
Maybe it is showed inside ghci.

Anyway, I'd like to get my utf-8 string to C but in ascii (or latin1).

How can do this ?
{-# LANGUAGE ForeignFunctionInterface #-}
module Main where

import Foreign.C.String (CString, withCString)
import Foreign.C.Types  (CInt)
import qualified Data.ByteString as B
import qualified Data.ByteString.Char8 as C
import qualified Data.ByteString.UTF8 as U
import Codec.Text.IConv (convert)

foreign import ccall "literal.h print" c_print
  :: CString -> IO CInt

-- Can't pack :
-- Expected type: [GHC.Word.Word8]
-- Inferred type: [Char]
--bytestr = B.pack "Pack Me."

str1 = "Hello world !"
bytestr1 = C.pack "Bye !"

-- How to use convert ?
-- Expected type `Data.ByteString.Lazy.Internal.ByteString'
-- Inferred type `C.ByteString'
--bytestr3 = convert "UTF-8" "LATIN1" $ C.pack "Pack"

-- Similar.
--bytestr3 = convert "UTF-8" "LATIN1" $ U.fromString "Pack"

main = do
  withCString str1 print
  B.useAsCString bytestr1 print


#include 

int print (char * msg) { printf ("%s\n", msg); }


int print (char * msg);

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Formal semantics for Haskell?

[gregg reynolds]

Is that () or _|_? ;)

Tim Newsham  wrote:

>null___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Control.Arrow being icky

[mail]

Louis Wasserman  writes:
> In GHCi, I import Control.Arrow, and Kliesli doesn't appear:
> Prelude Control.Arrow> :t Kliesli
>
> :1:0: Not in scope: data constructor `Kliesli'

It's spelled `Kleisli'

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Control.Arrow being icky

[Andrew Wagner]

It's spelled 'Kleisli'. You spelled it 'Kliesli'

2009/2/9 Louis Wasserman 

> In GHCi, I import Control.Arrow, and Kliesli doesn't appear:
> Prelude Control.Arrow> :t Kliesli
>
> :1:0: Not in scope: data constructor `Kliesli'
> Prelude Control.Arrow> :browse
> (<<^) :: (Arrow a) => a c d -> (b -> c) -> a b d
> (>>^) :: (Arrow a) => a b c -> (c -> d) -> a b d
> class (Control.Category.Category a) => Arrow a where
>   arr :: (b -> c) -> a b c
>   first :: a b c -> a (b, d) (c, d)
>   second :: a b c -> a (d, b) (d, c)
>   (***) :: a b c -> a b' c' -> a (b, b') (c, c')
>   (&&&) :: a b c -> a b c' -> a b (c, c')
> class (Arrow a) => ArrowApply a where app :: a (a b c, b) c
> class (Arrow a) => ArrowChoice a where
>   left :: a b c -> a (Either b d) (Either c d)
>   right :: a b c -> a (Either d b) (Either d c)
>   (+++) :: a b c -> a b' c' -> a (Either b b') (Either c c')
>   (|||) :: a b d -> a c d -> a (Either b c) d
> class (Arrow a) => ArrowLoop a where
>   loop :: a (b, d) (c, d) -> a b c
> newtype (ArrowApply a) => ArrowMonad a b = ArrowMonad (a () b)
> class (ArrowZero a) => ArrowPlus a where
>   (<+>) :: a b c -> a b c -> a b c
> class (Arrow a) => ArrowZero a where zeroArrow :: a b c
> newtype Kleisli m a b = Kleisli {runKleisli :: a -> m b}
> (^<<) :: (Arrow a) => (c -> d) -> a b c -> a b d
> (^>>) :: (Arrow a) => (b -> c) -> a c d -> a b d
> leftApp :: (ArrowApply a) => a b c -> a (Either b d) (Either c d)
> returnA :: (Arrow a) => a b b
> (<<<) ::
>   (Control.Category.Category cat) => cat b c -> cat a b -> cat a c
> (>>>) ::
>   (Control.Category.Category cat) => cat a b -> cat b c -> cat a c
>
> Does anybody know what's going on?
>
> Louis Wasserman
> wasserman.lo...@gmail.com
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Control.Arrow being icky

[Louis Wasserman]

In GHCi, I import Control.Arrow, and Kliesli doesn't appear:
Prelude Control.Arrow> :t Kliesli

:1:0: Not in scope: data constructor `Kliesli'
Prelude Control.Arrow> :browse
(<<^) :: (Arrow a) => a c d -> (b -> c) -> a b d
(>>^) :: (Arrow a) => a b c -> (c -> d) -> a b d
class (Control.Category.Category a) => Arrow a where
  arr :: (b -> c) -> a b c
  first :: a b c -> a (b, d) (c, d)
  second :: a b c -> a (d, b) (d, c)
  (***) :: a b c -> a b' c' -> a (b, b') (c, c')
  (&&&) :: a b c -> a b c' -> a b (c, c')
class (Arrow a) => ArrowApply a where app :: a (a b c, b) c
class (Arrow a) => ArrowChoice a where
  left :: a b c -> a (Either b d) (Either c d)
  right :: a b c -> a (Either d b) (Either d c)
  (+++) :: a b c -> a b' c' -> a (Either b b') (Either c c')
  (|||) :: a b d -> a c d -> a (Either b c) d
class (Arrow a) => ArrowLoop a where
  loop :: a (b, d) (c, d) -> a b c
newtype (ArrowApply a) => ArrowMonad a b = ArrowMonad (a () b)
class (ArrowZero a) => ArrowPlus a where
  (<+>) :: a b c -> a b c -> a b c
class (Arrow a) => ArrowZero a where zeroArrow :: a b c
newtype Kleisli m a b = Kleisli {runKleisli :: a -> m b}
(^<<) :: (Arrow a) => (c -> d) -> a b c -> a b d
(^>>) :: (Arrow a) => (b -> c) -> a c d -> a b d
leftApp :: (ArrowApply a) => a b c -> a (Either b d) (Either c d)
returnA :: (Arrow a) => a b b
(<<<) ::
  (Control.Category.Category cat) => cat b c -> cat a b -> cat a c
(>>>) ::
  (Control.Category.Category cat) => cat a b -> cat b c -> cat a c

Does anybody know what's going on?

Louis Wasserman
wasserman.lo...@gmail.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: The Haskell re-branding exercise

[Don Stewart]

marlowsd:
> Sterling Clover wrote:
>> IP based limitations are a terrible idea. Multiple users can be and  
>> often are behind the same IP if they're in some sort of intranet, be it 
>> corporate, academic, or simply multiple home computers. Mail-based  
>> authentication can be screwed with, sure, but it's also very easy to  
>> notice this (as opposed to ip nonsense) through simply eyeballing the  
>> results. There's no general everywhere way to prevent vote fraud.  
>> However, if we make it even require a mild bit of thought, that should  
>> be sufficient in this case, as there won't be enough votes to prevent  
>> some sort of rough eyeball-based check of the results, and if there 
>> are, then that's a sign of fraud for sure! Furthermore, there's very 
>> little incentive for someone to go the extra mile here, as we're voting 
>> for a haskell logo, and not, e.g., giving away ten thousand dollars.  
>> Furthermore, since I assume we'll only be presenting reasonable logos,  
>> there's not even some room for pranksters to stage a "write-in" of some 
>> gag slogan.
>
> I suggest we do voting by email, and restrict voting to those who have 
> ever posted on haskell-cafe before 1 Jan 2009.  We could then have an  
> auto-confirmation scheme similar to mailing list sign-up where the  
> confirmation message is sent back to the originator to confirm their  
> identity, containing a verification link to click on.
>
> I realise there are flaws in this, but it seems to be (a) cheap to  
> implement and participate in, and (b) good enough.

Seems good enough. Who's going to tally the votes?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Monad explanation

[Tillmann Rendel]

Hi Gregg,

Gregg Reynolds wrote:

Right; "implementation of IO" means also an implementation for >>=, not just
the IO operators.  I hadn't thought about that but it's hugely important for
the exposition of monads and IO.


Indeed, that's very important.

Note that the topics "monads in Haskell" and "IO in Haskell" can (and in 
my opinion should) be understood independently of each other.


IO in Haskell is just an abstract data type, with a bunch of functions

  return :: a -> IO a
  bind :: IO a -> (a -> IO b) -> IO b
  getChar :: IO Char
  putChar :: a -> IO ()
  ...

A Haskell runtime system is a somewhat vaguely specified interpreter for 
(IO a) values. While it would be nice to a have a better specification 
of that interpreter, it is not part of the semantics of the language 
Haskell.



"The IO Char indicates that getChar, when invoked, performs some action
which returns a character." (Gentle Intro, typical of many expositions.)


I guess that "invoked" here means really "interpreted by your Haskell 
implementation during its interpretation of the (IO a) your main 
function constructed".


  Tillmann
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Efficient string output

[Don Stewart]

ketil:
> 
> Hi,
> 
> I'm currently working on a program that parses a large binary file and
> produces various textual outputs extracted from it.  Simple enough.
> 
> But: since we're talking large amounts of data, I'd like to have
> reasonable performance.  
> 
> Reading the binary file is very efficient thanks to Data.Binary.
> However, output is a different matter.  Currently, my code looks
> something like:
> 
>   summarize :: Foo -> ByteString
>   summarize f = let f1 = accessor f
> f2 = expression f
>:
> in B.concat [f1,pack "\t",pack (show f2),...]
> 
> which isn't particularly elegant, and builds a temporary ByteString
> that usually only get passed to B.putStrLn.  I can suffer the
> inelegance were it only fast - but this ends up taking the better part
> of the execution time.

Why not use Data.Binary for output too? It is rather efficient at
output -- using a continuation-like system to fill buffers gradually.

--   Don
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Monad explanation

[David Menendez]

2009/2/9 Gregg Reynolds :
>
> Right; "implementation of IO" means also an implementation for >>=, not just
> the IO operators.  I hadn't thought about that but it's hugely important for
> the exposition of monads and IO.
>
> "The IO Char indicates that getChar, when invoked, performs some action
> which returns a character." (Gentle Intro, typical of many expositions.)

In this case, I think "invoked" is shorthand for "interpreted by the
runtime system".

> That, plus the form of \x -> putChar x used with >>=, plus the fact that one
> can do getChar at the ghci command line, plus all the other stuff - it all
> adds up to exasperation.

It's worth noting that ghci, unlike Haskell itself, *does* treat IO
specially. It checks the type of the expression you've entered, and
behaves differently depending on whether it's equal to a, IO a, or IO
().

interp[ e :: IO () ] = e
interp[ e :: IO a ] = e >>= print
interp[ e :: a ] = print e

This is convenient for users, but it has nothing to do with the
semantics of Haskell.

-- 
Dave Menendez 

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Formal semantics for Haskell?

[Tim Newsham]

ML has a formal definition[1]; why not Haskell?  Would this be a Good Thing,
or a Waste Of Time?


Not exactly what you are asking for, but a start:
http://www.cs.kent.ac.uk/pubs/1992/123/index.html


gregg


Tim Newsham
http://www.thenewsh.com/~newsham/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Haddock Markup

[Wolfgang Jeltsch]

Am Montag, 9. Februar 2009 15:10 schrieben Sie:
> I want for long to write math formulas in a paper in Haskell. Actually,
> lhs2TeX can do such transformations but it is quite limited in handling
> of parentheses and does not support more complicated transformations
> (transforming prefix notation in infix notation or vice versa with
> minimal parentheses).
>
> […]
>
> I imagine some rule based configuration that is implemented using
> haskell-src, that handles all identifiers, say, with prefix "parameter"
> as wildcards:
>
>sumFor [parameterA..parameterB] (\parameterI -> parameterS)
>=>\sum_{parameterI=parameterA}^{parameterB} parameterS
>
> Unfortunately a tool for this transformation still has to be written,
> but wouldn't that be really cool? The tool might be even relatively
> simple, but the configuration is certainly non-trivial and it would have
> to be hard-wired into cabal in order to provide identical rendering on
> all systems and output formats (TeX or MathML).

This reminds me of an idea which I had some time ago. The idea is to write all 
your documentation in Template Haskell, possibly using quasiquoting to 
support Haddock-like syntax. Then you could write math as ordinary Haskell 
expressions and embed these expressions into your documentation expressions. 
This would make the documentation language very extensible since you could 
always write your own extensions in the form of some Haskell code fragments 
or libraries.

To build the documentation, one would run GHC with a special flag or whatever 
which makes the Template Haskell parts build HTML or whatever. Without the 
flag, the documentation code would do nothing. By using Template Haskell, one 
would have access to information about identifiers, types etc. A basic 
Haddock Haskell library could provide functions which use that information to 
build HTML or whatever from the actual documentation. These functions would 
then be used in the Template Haskell code.

Does this make some sense?

Best wishes,
Wolfgang
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] evaluation semantics of bind

[David Menendez]

2009/2/9 Gregg Reynolds :
> On Sun, Feb 8, 2009 at 6:25 PM, Richard O'Keefe  wrote:
>>
>> On 6 Feb 2009, at 4:20 am, Gregg Reynolds wrote:
>>>
>>>  However, consider:
>>>
>>>getChar >>= \x -> getChar
>>>
>>> An optimizer can see that the result of the first getChar is discarded
>>> and replace the entire expression with one getChar without changing the
>>> formal semantics.
>>
>> But the result of the first getChar is *NOT* discarded.
>> **As an analogy**, think of the type IO t as (World -> (t,World))
>> for some hidden type World, and
>>getChar w = (c, w')
>>-- get a character c out of world w somehow,
>>-- changing w to w' as you go
>>(f >>= g) w = let (v,w') = f w in (g v) w'
>>
>> In this analogy, you see that the result of getChar is a value of
>> type IO Char (not of type Char), and that while the character
>> part of the result of performing the result of getChar may be
>> discarded, the "changed world" part is NOT.
>
> That's an implementation detail.  It doesn't account for other possible IO
> implementations.
>
> My original question was motivated by the observation that a human reader of
> an expression of the form "e >>= f" , on seeing that f is constant, may pull
> the constant value out of f, disregard e and dispense with the application f
> e.  So can a compiler, unless IO expressions are involved, in which case
> such optimizations are forbidden.  I wondered if that was due to the
> semantics of >>= or the semantics of IO.

Neither. It's because the expression "e >>= f" is not "f e". As far as
Haskell is concerned, >>= is just a higher-order function. You can't
arbitrarily replace "foo bar (const baz)" with "baz", unless it turns
out that foo = \x y -> y x.

Perhaps you're thinking of the monad law,

forall x f. return x >>= f  =  f x

The presence of "return" is important. Among other things, there is no
x such that getChar = return x. That's because getChar has (or,
rather, causes when interpreted by the RTS) side-effects, whereas
"return x" is pure.


Here's some code you can try on your own:

data IO a = Return a | Get (Char -> IO a) | Put Char (IO a)

instance Monad IO where
return = Return
Return a >>= f = f a
Get k >>= f = Get (\c -> k c >>= f)
Put c k >>= f = Put c (k >>= f)

getChar :: IO Char
getChar = Get (\c -> Return c)

putChar :: Char -> IO ()
putChar c = Put c (Return ())


Now, if the compiler sees "getChar >>= \_ -> getChar", it *can*
optimize out the >>=. But the result would be "Get (\_ -> Get (\c ->
Return c))", which is not equivalent to getChar. Neither IO semantics
nor monad semantics are involved.

-- 
Dave Menendez 

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] how to use a literal string with bystring useAsCString

[minh thu]

Hi,

I have a Haskell source file encoded in utf-8.
Inside that source, I have literal strings that I'd
like to pass to a C function.

withCString does the job well until I tried to use
the double-quote character ". I get
/usr/lib/ghc-6.10.1/ghc: `@: Bad font file format
(even when using (chr 34) instead).

I didn't understand the reason of this behavior (since
the double quote is just ascii) but
tried to use useAsCString but coudn't do it.
I can ByteString.Char8.pack my string but the problem
remains. I tried to use IConv but it uses UTF8.ByteString
and I don't know how to make the conversion so I can
use useAsCString or withCString.

Any idea ?
Thanks,
Thu
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] evaluation semantics of bind

[Tillmann Rendel]

Gregg Reynolds wrote::

My original question was motivated by the observation that a human reader of
an expression of the form "e >>= f" , on seeing that f is constant, may pull
the constant value out of f, disregard e and dispense with the application f
e.  


While a human reader may well do that, but it would be correct or wrong 
depending on the definition of >>=. The same is of course true for 
compilers. By the way, there is no "application f e".



An example where it would be wrong to ignore e:

  sum ([1, 2] >>= const [21])

This expression should evaluate to sum [21, 21] = 42, not sum [21] = 21.


There is nothing special with IO or >>=, so there is no need to 
introduce special cases for IO or >>= in a formal or informal semantics 
of Haskell.


  Tillmann
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Error in building profiling

[Marco Túlio Gontijo e Silva]

Em Sex, 2009-02-06 às 22:55 +, Duncan Coutts escreveu:
> On Fri, 2009-02-06 at 08:28 -0200, Marco Túlio Gontijo e Silva wrote:
> 
> > > $ ./setup configure --enable-library-profiling --disable-library-vanilla
> 
> > > /usr/bin/ld: dist/build/Control/Monad/Cont.o: No such file: No such file
> > > or directory
> > > 
> > > I'm using ghc6 6.10.1+dfsg1-5 and binutils 2.19-1~exp1.
> > 
> > I tried the same with ghc6 6.8.2dfsg1-1 and it worked.
> 
> Turns out I broke it in Cabal-1.4. It used to be that
> --disable-library-vanilla implied --disable-library-for-ghci where as
> they're now independent.
> 
> Try the Cabal head branch now. Let me know if that fixes it for you. If
> it does I'll push it to the Cabal-1.6 branch.

I tried with the updated cabal and it's working.

Thanks.

-- 
marcot
http://marcot.iaaeee.org/


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Data.Map: Enumerating ordered subset of keys

[Jared Updike]

On 2/8/09, Evan Laforge  wrote:
> I have a little util library with various map functions.  'within' is
>  almost what you want, except it's half-open.  You can make an
>  inclusive one by pulling the lowest element off the above map.
>
>  I'm also curious if there's a better way to do this...
>
>  -- | Like Map.split, except include a matched key in the above map.
>  split_map :: (Ord k) => k -> Map.Map k a -> (Map.Map k a, Map.Map k a)
>  split_map k fm = (pre, post')
> where
> (pre, at, post) = Map.splitLookup k fm
> post' = maybe post (\v -> Map.insert k v post) at
>
>  -- | Split the map into the maps below, within, and above the given range.
>  -- @low@ to @high@ is half-open, as usual.
>  split3_map :: (Ord k) => k -> k -> Map.Map k a
> -> (Map.Map k a, Map.Map k a, Map.Map k a)
>  split3_map low high fm = (below, within, way_above)
> where
> (below, above) = split_map low fm
> (within, way_above) = split_map high above
>
>  within low high fm = let (_, m, _) = split3_map low high fm in m

This looks right to me (correct time complexity). It should do what I
need. I will test it and see what I discover.

Thanks,
  Jared.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Data.Map: Enumerating ordered subset of keys

[Jared Updike]

On 2/8/09, Anish Muttreja  wrote:
> Maybe you wantData.Map.partition (\key -> key >= key1 && key <= key2) map

This will return what I want, but partition is O(n) and touches all
the keys, so if I had a million keys and only 2 of them matched the
key1..key2 range, it would still visit all of them before it
enumerated the ones that satisify the predicate. I don't believe
laziness would help here.

>  HTH,
>  Anish
>
>
>  On Sun, 08 Feb 2009 23:02:37 -0800, Jared Updike  wrote:
>
>
> >
> > It looks like two "Map.split"s will do what I need except for allowing
> > more exact testing of <= vs. < (since == elements are left out of both
> > maps...?)
> >
> >  Jared.
> >
> > On 2/8/09, Jared Updike  wrote:
> >
> > > I would like to enumerate a subset of keys in a Map satisfying \ key
> > >  >= key1 && key <= key2 but in the expected, reasonable amount of time
> > >  (e.g. < O(log(n)) + O(m) for n total keys and m keys in the subset).
> > >  (Or key > key1 and/or key < key2 or some such combination).
> > >
> > >  Is there an appropriate idiom or combination of library functions to
> > >  accomplish this, short of digging into the code for Data.Map and
> > >  writing such a function for a forked version of Data.Map?
> > >
> > >  For example I could try something like a Set.split of a Set.split of
> > >  Map.keysSet of my original map, but will laziness magically do what I
> > >  really want? which is to walk down the tree to key1 (or the nearest
> > >  key > key1) and enumerate keys in order until key2 is reached?
> > >
> > >  Data.Map almost looks like what I need if I can do this.
> > >
> > >
> > >  Jared.
> > >
> > >
> > ___
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
>
>
>
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Data.Map: Enumerating ordered subset of keys

[Jared Updike]

I had a similar thought. That will probably do the trick.

  Jared.

On 2/8/09, Svein Ove Aas  wrote:
> On Mon, Feb 9, 2009 at 8:02 AM, Jared Updike  wrote:
>  > It looks like two "Map.split"s will do what I need except for allowing
>  > more exact testing of <= vs. < (since == elements are left out of both
>  > maps...?)
>  >
>
> If your key is an instance of Enum, you can use succ/pred to work
>  around that little problem.
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Formal semantics for Haskell?

[Gregg Reynolds]

ML has a formal definition[1]; why not Haskell?  Would this be a Good Thing,
or a Waste Of Time?  The Report strikes me as a hybrid of formal and
informal.  I guess that's not a problem so far, but there aren't that many
implementations; if we had dozens, how could we verify conformance?  A
formal semantics would be useful, but it would also be Fun to use Category
Theory notation in a language definition.

Such a task would be way beyond my abilities, but I have come up with an
idea for a formal semantics of IO and other non-deterministic elements of
the language that I think is kind of interesting.  It's inspired by Category
Theory and the Z specification language.   See  my (brief) blog
article
.

Actually, I'm in a state of rather intense euphoria about it, so a bucket of
cold water realism over my head might be a Good Thing.  Then I could get
some sleep instead of obsessing about category theory and Haskell.  :)

I propose any formal definition include the following warning, modeled on
Knuth's warning about MetaFont:

  WARNING:  Haskell can be hazardous to your other interests.  Once you get
hooked, you will develop intense feelings about language design; semantic
models will intrude on the program texts you read.  And you will perpetually
be thinking of improvements to the programs that you see everywhere,
including those of your own design.

Thanks,

gregg


[1] The Definition of Standard ML (Revised); a preview is on Google Books
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Haskell and Java interaction

[C.M.Brown]

Hi Silviu,

There's the GCJNI:
http://www.haskell.org/gcjni/

Which is basically a greencard-ed JNI interface for Haskell. I'm not sure
it's still suported but may be worth a shot.

Regards,
Chris.


On Mon, 9 Feb 2009, Silviu ANDRICA wrote:

> Hello,
>   I was wondering if there is a way to call Haskell code from Java. I
> tried using jvm-bridge(http://sourceforge.net/projects/jvm-bridge/), but
> I'm stuck on building it.
>
> Thank you very much,
>   Silviu
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Haskell and Java interaction

[Silviu ANDRICA]

Hello,
 I was wondering if there is a way to call Haskell code from Java. I 
tried using jvm-bridge(http://sourceforge.net/projects/jvm-bridge/), but 
I'm stuck on building it.


Thank you very much,
 Silviu
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Haskell and Automation

[Michael Snoyman]

Gunther,

Thanks for the heads-up. I might need to interface with Excel in the future.

Michael

On Sat, Feb 7, 2009 at 8:14 PM, GŸuenther Schmidt  wrote:

>  Dear Michael,
>
> sorry too, for not telling you sooner that meanwhile I found out how to get
> it working, I hope you did not spend too much time trying on your end.
>
> It had to do with the context in which these components are initialized.
>
> Once you switch to LocalProcess (as opposed to AnyProcess) in
> coCreateInstance everything works fine and rather smoothly. The defaults in
> createObject do not work for every kind of object that you do want to
> instantiate, certainly not Excel.
>
> Of course having an old, but still fairly current manual also helps.
>
> Good luck with your projects.
>
> Günther
>
>
>
> Michael Snoyman schrieb:
>
> Gunther,
>
> Sorry for not getting back to you on your previous e-mail, I've been
> swamped.
>
> The reason I didn't put up an example was specifically because of the error
> you mention. I was hoping to get a chance to use the COM bindings in Python
> to see if I got the same thing. For the life of me I can't figure out how to
> get started with Excel and Haskell. Sorry I can't be more useful at this
> time.
>
> Michael
>
> On Fri, Feb 6, 2009 at 6:56 PM, G?uenther Schmidt wrote:
>
>> Hi Michael,
>>
>> for some reason createObject "Excel.Application" throws an "Interface not
>> supported" error.
>>
>> Can you help me out here?
>>
>> Günther
>>
>>
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] lazy evaluation is not complete

[Jochem Berndsen]

Peter Padawitz wrote:
> A simplied version of Example 5-16 in Manna's classical book
> "Mathematical Theory of Computation":
>
> foo x = if x == 0 then 0 else foo (x-1)*foo (x+1)
>
> If run with ghci, foo 5 does not terminate, i.e., Haskell does not look
> for all outermost redices in parallel. Why? For efficiency reasons?
>
> It's a pity because a parallel-outermost strategy would be complete.

(*) is strict in both arguments for Int. If you want to avoid this, you
could do
newtype X = X Int
and write your own implementation of (*) that is nonstrict.

-- 
Jochem Berndsen | joc...@functor.nl
GPG: 0xE6FABFAB
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Haddock Markup

[drblanco]

Wolfgang Jeltsch-2 wrote:
> 
> This is only true if your destination format is PDF, DVI or PS. For a
> webpage, 
> you’ll need MathML in the end and TeX is not so good in producing MathML,
> I 
> suppose.
> 
Has jsMath been considered as an alternative to images in HTML? 
(http://www.math.union.edu/~dpvc/jsMath/)  It's supposed to work on most
browsers, and the screen output is very nice.  
-- 
View this message in context: 
http://www.nabble.com/Haddock-Markup-tp21864389p21914911.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Looking for pointfree version

[Edsko de Vries]

Perfect! Beautiful. I was hoping there'd be a simple solution like that.

Thanks!

On 9 Feb 2009, at 14:31, Wouter Swierstra wrote:


> snip

How about using Data.Monoid:

down = downPar `mappend` downNew `mappend` downTrans

 Wouter



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Efficient string output

[Ketil Malde]

Duncan Coutts  writes:

> Have you considered using Data.Binary to output the data too? It has a
> pretty efficient underlying monoid for accumulating output data in a
> buffer. You'd want some wrapper functions over the top to make it a bit
> nicer for your use case, but it should work and should be quick.

I've used Data.Binary.Builder to generate the output, which is quite
nice as an interface.  Currently, I've managed to shave off a few
percent off the time - nothing radical yet, but there's a lot of room
for tuning various convenience functions in there.

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Haddock Markup

[Duncan Coutts]

On Mon, 2009-02-09 at 15:18 +0100, Henning Thielemann wrote:
> Khudyakov Alexey wrote:
> 
> > I think MathML is much less accessible than images. Yes, there are problems 
> > with them but any browser is able to display them save for text based ones. 
> > MathML on contrary doesn't have much support. According to wikipedia only 
> > recent versions of gecko based browsers and opera >=9.5 can do this. For IE 
> > special plugin is required (MathPlayer). I believe image are safest way at 
> > least for now. 
> 
> As far as I know, Haddock is not bound to HTML output. (And if it is 
> bound this way, I wished it wouldn't.)

Right, it's not. Though there are not many other backends. Translating
haddock markup into pandoc or docbook might be an easy way to get more.

> For PDF Haddock output TeX formula will be the best choice, whereas
> for HTML, MathML or embedded images are the best. I expect there will
> be no consensus and the Haddock user should decide how he wants the
> formulas to be rendered. That's best generated from a structure
> preserving notation of math formulas (like Haskell expressions).

Right, the problem is that since it is not bound to a specific output
format then it cannot use embedded tex or whatever. The current haddock
markup is deliberately very limited and simple so that it can be
rendered in more or less any output format.

Duncan

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] FFI binding to CGAL?

[minh thu]

2009/2/9 Peter Verswyvelen :
> I was wandering of someone already made a FFI binding to http://www.cgal.org
> or something similar that does computational geometry?
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

CGAL is written in C++ and makes heavy use of templates
to let user code parametrize efficiently the data structures.
I'm not sure it would be a good pick to begin with if you not
a lot of time.

On the other hand, if you're happy with a few small choices
of parametrization, you can do that in C++, then export some
C functions then bind against that. It's overall quite straightforward.

HTH,
Thu
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Looking for pointfree version

[Aai]

Rewriting it to:

concatMap ($ p)[downPar , downNew , downTrans ]

gives:

($ p) =<< [downPar, downNew, downTrans]

didn't check though!


=@@i


Edsko de Vries schreef:
> Hi,
>
> Is there a nice way to write
>
> down :: Focus -> [Focus]
> down p = concat [downPar p, downNew p, downTrans p]
>
> in point-free style? (In doesn't make much difference what these
> functions do; if it helps, their types are downPar, downNew, downTrans
> :: Focus -> [Focus]).
>
> Ideally, I would like to write something like
>
> down = downPar ... downNew ... downTrans
>
> but I'm not sure what should be on the dots. This works:
>
> down = concat . flip map [downPar, downNew, downTrans] . flip ($)
>
> but is extremely ugly and doesn't really explain what's going on :)
> (It seems to me I should be able to take advantage of the list monad,
> somehow).
>
> Pointers appreciated!
>
> Edsko
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Looking for pointfree version

[Wouter Swierstra]

> snip

How about using Data.Monoid:

down = downPar `mappend` downNew `mappend` downTrans

  Wouter

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Looking for pointfree version

[Robin Green]

On Mon, 9 Feb 2009 14:18:18 +
Edsko de Vries  wrote:

> Hi,
> 
> Is there a nice way to write
> 
> down :: Focus -> [Focus]
> down p = concat [downPar p, downNew p, downTrans p]
> 
> in point-free style?

I think this should work:

down = concat . swing map [downPar, downNew, downTrans]

swing is defined at http://www.haskell.org/haskellwiki/Pointfree#Swing

-- 
Robin
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] FFI binding to CGAL?

[Peter Verswyvelen]

I was wandering of someone already made a FFI binding to http://www.cgal.org
or something similar that does computational geometry?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] lazy evaluation is not complete

[Robin Green]

On Mon, 09 Feb 2009 15:10:22 +0100
Peter Padawitz  wrote:

> A simplied version of Example 5-16 in Manna's classical book 
> "Mathematical Theory of Computation":
> 
> foo x = if x == 0 then 0 else foo (x-1)*foo (x+1)
> 
> If run with ghci, foo 5 does not terminate, i.e., Haskell does not
> look for all outermost redices in parallel. Why? For efficiency
> reasons?

I believe * is implemented in the normal way and thus is always strict
in both arguments.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] lazy evaluation is not complete

[Bulat Ziganshin]

Hello Peter,

Monday, February 9, 2009, 5:10:22 PM, you wrote:

> If run with ghci, foo 5 does not terminate, i.e., Haskell does not look
> for all outermost redices in parallel. Why? For efficiency reasons?

of course. if you will create new thread for every cpu instruction
executed, you will definitely never compute anything :D

you need to use `par`

-- 
Best regards,
 Bulatmailto:bulat.zigans...@gmail.com

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: The Haskell re-branding exercise

[Richard Kelsall]

Simon Marlow wrote:
I suggest we do voting by email, and restrict voting to those who have 
ever posted on haskell-cafe before 1 Jan 2009.  We could then have an 
auto-confirmation scheme similar to mailing list sign-up where the 
confirmation message is sent back to the originator to confirm their 
identity, containing a verification link to click on.


I realise there are flaws in this, but it seems to be (a) cheap to 
implement and participate in, and (b) good enough.




That sounds better than my Haskell Wiki verification method.


Richard.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Looking for pointfree version

[Edsko de Vries]

Hi,

Is there a nice way to write

down :: Focus -> [Focus]
down p = concat [downPar p, downNew p, downTrans p]

in point-free style? (In doesn't make much difference what these  
functions do; if it helps, their types are downPar, downNew,  
downTrans :: Focus -> [Focus]).


Ideally, I would like to write something like

down = downPar ... downNew ... downTrans

but I'm not sure what should be on the dots. This works:

down = concat . flip map [downPar, downNew, downTrans] . flip ($)

but is extremely ugly and doesn't really explain what's going on :)  
(It seems to me I should be able to take advantage of the list monad,  
somehow).


Pointers appreciated!

Edsko

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Haddock Markup

[Henning Thielemann]

Khudyakov Alexey wrote:

I think MathML is much less accessible than images. Yes, there are problems 
with them but any browser is able to display them save for text based ones. 
MathML on contrary doesn't have much support. According to wikipedia only 
recent versions of gecko based browsers and opera >=9.5 can do this. For IE 
special plugin is required (MathPlayer). I believe image are safest way at 
least for now. 


As far as I know, Haddock is not bound to HTML output. (And if it is 
bound this way, I wished it wouldn't.) For PDF Haddock output TeX 
formula will be the best choice, whereas for HTML, MathML or embedded 
images are the best. I expect there will be no consensus and the Haddock 
user should decide how he wants the formulas to be rendered. That's best 
generated from a structure preserving notation of math formulas (like 
Haskell expressions).

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Haddock Markup

[Henning Thielemann]

Wolfgang Jeltsch wrote:

TeX is not so great for mathematics and especially not for conversion into 
MathML (which would be needed for HTML output). The TeX math language 
provides rather little semantic information. As input language for the 
concrete software named TeX this is mostly okay since the concrete rendering 
algorithm of TeX doesn’t need certain information (for example, about 
implicit bracketing).


However, even for rendering with TeX, you sometimes have to ressort to ugly 
tricks since TeX sometimes misinterprets what you wrote. Knuth gives some 
examples in chapter 18 of The TeXbook. For conversion into MathML, a TeX 
source generally doesn’t have enough information since even presentation 
MathML code contains much more structure than ordinary TeX source code does.


So using TeX as a general language for math is a very bad idea, in my opinion. 
The problem is that there is no good language which provides enough 
structural information for conversion into MathML and is at the same time 
simple to write and read. Maybe, both requirements contradict.


I want for long to write math formulas in a paper in Haskell. Actually,
lhs2TeX can do such transformations but it is quite limited in handling
of parentheses and does not support more complicated transformations
(transforming prefix notation in infix notation or vice versa with
minimal parentheses).

I would like to write
  sumFor [0..n] (\i -> i^2)
(with sumFor xs f = sum $ map f xs)
which is rendered as
  \sum_{i=0}^{n} i^2
or
  integrate 1000 (a,b) (\t -> f t)
to be rendered as
  \int_a^b f(t) \dif t

I imagine some rule based configuration that is implemented using
haskell-src, that handles all identifiers, say, with prefix "parameter"
as wildcards:

  sumFor [parameterA..parameterB] (\parameterI -> parameterS)
  =>\sum_{parameterI=parameterA}^{parameterB} parameterS

Unfortunately a tool for this transformation still has to be written,
but wouldn't that be really cool? The tool might be even relatively
simple, but the configuration is certainly non-trivial and it would have
to be hard-wired into cabal in order to provide identical rendering on
all systems and output formats (TeX or MathML).

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] lazy evaluation is not complete

[Peter Padawitz]

A simplied version of Example 5-16 in Manna's classical book 
"Mathematical Theory of Computation":


foo x = if x == 0 then 0 else foo (x-1)*foo (x+1)

If run with ghci, foo 5 does not terminate, i.e., Haskell does not look 
for all outermost redices in parallel. Why? For efficiency reasons?


It's a pity because a parallel-outermost strategy would be complete.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Does readFile "/proc/mounts" hang for you?

[Simon Marlow]

David Fox wrote:
On Wed, Jan 21, 2009 at 9:20 AM, David Fox > wrote:


I posted a bug about this
(http://hackage.haskell.org/trac/ghc/ticket/2971) but its so odd I
had to ask here.  Using ghc 6.10.1, both readFile "/proc/mounts" and
Data.ByteString.Lazy.Char8.readFile "/proc/mounts" hang on an amd64
machine running Linux.  Also, Data.ByteString.readFile
"/proc/mounts" returns the empty string.  Is this behavior present
for others?  On i386?

 
I can now confirm that this bug also affects the i386 architecture.


There was a more serious underlying bug, which is now fixed.  Thanks to 
those who reported and investigated it.


Cheers,
Simon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: The Haskell re-branding exercise

[Simon Marlow]

Sterling Clover wrote:
IP based limitations are a terrible idea. Multiple users can be and 
often are behind the same IP if they're in some sort of intranet, be it 
corporate, academic, or simply multiple home computers. Mail-based 
authentication can be screwed with, sure, but it's also very easy to 
notice this (as opposed to ip nonsense) through simply eyeballing the 
results. There's no general everywhere way to prevent vote fraud. 
However, if we make it even require a mild bit of thought, that should 
be sufficient in this case, as there won't be enough votes to prevent 
some sort of rough eyeball-based check of the results, and if there are, 
then that's a sign of fraud for sure! Furthermore, there's very little 
incentive for someone to go the extra mile here, as we're voting for a 
haskell logo, and not, e.g., giving away ten thousand dollars. 
Furthermore, since I assume we'll only be presenting reasonable logos, 
there's not even some room for pranksters to stage a "write-in" of some 
gag slogan.


I suggest we do voting by email, and restrict voting to those who have ever 
posted on haskell-cafe before 1 Jan 2009.  We could then have an 
auto-confirmation scheme similar to mailing list sign-up where the 
confirmation message is sent back to the originator to confirm their 
identity, containing a verification link to click on.


I realise there are flaws in this, but it seems to be (a) cheap to 
implement and participate in, and (b) good enough.


Cheers,
Simon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] evaluation semantics of bind

[Gregg Reynolds]

On Mon, Feb 9, 2009 at 7:17 AM, Lennart Augustsson
wrote:

> Just to clarify a little.
> If you implement the IO monad in a sane way (as some kind of state
> monad or continuation monad) then the compiler can optimize e>>=f even
> for the IO monad.  The implementation of >>= will ensure the
> sequencing of effects in e before effects in f.


I think this answers one of my questions about the relation of category
theory to Haskell. Bind is an implementation of the Kleisli star, but the
latter, being abstract, may encode data dependency but not sequence.  The IO
implementation of >>= must ensure sequence, regardless of data dependency
(e.g. even for putChar 'a' >>= \x -> putChar 'c').

So if we wanted to write a Haskell specification with more formality and
detail than the Report, we could say that the IO monad must implement the
Kleisli star operator, but that would not be enough, we would also have to
require that the implementation ensure sequencing.  IOW, Kleisli star
implementation plus a constraint on the implementation.  Does that sound
right?

>
> The IO monad is less magic than you seem to think it is. :)
>

Any sufficiently advanced technology is isomorphic to magic.  ;)

(http://www.quotationspage.com/quote/776.html)

-gregg
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] evaluation semantics of bind

[Lennart Augustsson]

Just to clarify a little.
If you implement the IO monad in a sane way (as some kind of state
monad or continuation monad) then the compiler can optimize e>>=f even
for the IO monad.  The implementation of >>= will ensure the
sequencing of effects in e before effects in f.
The IO monad is less magic than you seem to think it is. :)

  -- Lennart

2009/2/9 Gregg Reynolds :
> On Sun, Feb 8, 2009 at 6:25 PM, Richard O'Keefe  wrote:
>>
>> On 6 Feb 2009, at 4:20 am, Gregg Reynolds wrote:
>>>
>>>  However, consider:
>>>
>>>getChar >>= \x -> getChar
>>>
>>> An optimizer can see that the result of the first getChar is discarded
>>> and replace the entire expression with one getChar without changing the
>>> formal semantics.
>>
>> But the result of the first getChar is *NOT* discarded.
>> **As an analogy**, think of the type IO t as (World -> (t,World))
>> for some hidden type World, and
>>getChar w = (c, w')
>>-- get a character c out of world w somehow,
>>-- changing w to w' as you go
>>(f >>= g) w = let (v,w') = f w in (g v) w'
>>
>> In this analogy, you see that the result of getChar is a value of
>> type IO Char (not of type Char), and that while the character
>> part of the result of performing the result of getChar may be
>> discarded, the "changed world" part is NOT.
>
> That's an implementation detail.  It doesn't account for other possible IO
> implementations.
>
> My original question was motivated by the observation that a human reader of
> an expression of the form "e >>= f" , on seeing that f is constant, may pull
> the constant value out of f, disregard e and dispense with the application f
> e.  So can a compiler, unless IO expressions are involved, in which case
> such optimizations are forbidden.  I wondered if that was due to the
> semantics of >>= or the semantics of IO.
>
> To summarize what I've concluded thanks to the helpful people on
> haskell-cafe:
>
> The compiler can optimize e >>= f except for any IO expressions in e and f.
> IO expressions must be evaluated, due to the semantics of IO.  The may not
> be disregarded, memoized, or substituted.  IO semantics may be implemented
> in different ways by different compilers; these implementation techniques
> are not part of the formal semantics of the language, which may be expressed
> as above:  IO expressions must be evaluated wherever and whenever they
> occur.
>
> The bind operator >>= enforces sequencing on arguments containing IO
> expressions, but does not force evaluation.  Even bind expressions involving
> IO may be optimized.  For example:
>
>   getChar >>= \x -> .. putChar 'c'
>
> The compiler may discard  (assuming it contains no IO
> expressions), but it must evaluate getChar and putChar (due to IO semantics)
> in the correct order (due to bind semantics).
>
> Thanks all,
>
> gregg
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] The Haskell re-branding exercise

[Richard Kelsall]

Don Stewart wrote:

Help identifying and implementing a voting process is very welcome.


Maybe we could have an administrator who receives the votes by email
and we confirm our emailed vote by appending the MD5 of our email to
a Haskell wiki page. The machine-readable email format might be:

I vote for these three logos in order of preference:
23
5
78
Here is my random salt:
kauhgfhgh
Here is the MD5 of the above:
e4d909c290d0fb1ca068ffaddf22cbd0

The administrator can check the MD5s he has received by email and
mark them as good on the wiki page, count the votes and publish
the result.


Richard.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Efficient string output

[Johan Tibell]

On Mon, Feb 9, 2009 at 1:22 PM, Ketil Malde  wrote:
> Johan Tibell  writes:
>> If so, you might want to use `writev` to avoid extra copying.
>
> Is there a Haskell binding somewhere, or do I need to FFI the system
> call?  Googling 'writev haskell' didn't turn up anything useful.

To my knowledge there's no binding out there. We will include one for
sockets in the next release of network-bytestring. You might find the
code here useful if you want to write your own:

http://github.com/tibbe/network-bytestring/blob/c13d8fab5179e6afbcdebac95d4993ac57f04689/Network/Socket/ByteString/Internal.hs

Cheers,

Johan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Monad explanation

[Gregg Reynolds]

On Mon, Feb 9, 2009 at 5:32 AM, Sittampalam, Ganesh <
ganesh.sittampa...@credit-suisse.com> wrote:

>
> > My bad, I restate:  a value cannot be both static and dynamic.  Or an
> > object and a morphism.  Or an element and a function.  Sure, you can
> > treat a morphism as an object, but only by moving to a higher (or
> > different) level of abstraction.  That doesn't erase the difference
> > between object and morphism.  If you do erase that difference you end
> > up with mush.  getChar /looks/ like an object, but semantically it
> > must be a morphism.  But it can't be a function, since it is
> > non-deterministic.   So actually the logical contradiction comes from
> > the nature of the beast.
> >
> > Another reason it's confusing to newcomers:  it's typed as "IO Char",
> > which looks like a type constructor.  One would expect getChar to
> > yield a value of type IO Char, no?  But it delivers a Char instead.
> > This is way confusing.  So I take "type IO foo" to mean "type foo,
> > after a side effect".  In a sense "getChar :: IO Char" isn't even a
> > true type signature.
>
> It does yield a value of type IO Char, which it also happens that you
> can ask the Haskell runtime to interpret by combining it with other
> IO values using >>= and invoking it from the top-level.
> *When interpreted in this way* it delivers a Char, but that's precisely
> the point at which we move to the different level of abstraction you
> mention above.


Right; "implementation of IO" means also an implementation for >>=, not just
the IO operators.  I hadn't thought about that but it's hugely important for
the exposition of monads and IO.

"The IO Char indicates that getChar, when invoked, performs some action
which returns a character." (Gentle Intro, typical of many expositions.)

That, plus the form of \x -> putChar x used with >>=, plus the fact that one
can do getChar at the ghci command line, plus all the other stuff - it all
adds up to exasperation.

Thanks,

gregg
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] threadDelay

[Bulat Ziganshin]

Hello Immanuel,

Monday, February 9, 2009, 3:42:24 PM, you wrote:

> Am I correct in assuming this program should run 100 secs?
> real    0m0.104s

may be, 100 msecs? :)

-- | Suspends the current thread for a given number of microseconds
-- (GHC only).


-- 
Best regards,
 Bulatmailto:bulat.zigans...@gmail.com

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] threadDelay

[Svein Ove Aas]

2009/2/9 Immanuel Litzroth :
> Am I correct in assuming this program should run 100 secs?
>
No, you're off by a factor of a thousand. It's based on microseconds,
not milliseconds.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Efficient string output

[Ketil Malde]

Bulat Ziganshin  writes:

>> in B.concat [f1,pack "\t",pack (show f2),...]

> i'm not a BS expert but it seems that you produce Strings using show
> and then convert them to BS. of course this is inefficient - you need
> to replace show with BS analog

Do these analogous functions exist, or must I roll my own.

I've also looked a bit at Data.Binary.Builder, perhaps this is the way
to go?  Will look more closely.

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] threadDelay

[Immanuel Litzroth]

Am I correct in assuming this program should run 100 secs?

>import Control.Concurrent
>main = do
> threadDelay 10

Why do I get the folling result then?
 ghc -threaded Main.hs -o delay
time ./delay

real0m0.104s
user0m0.001s
sys0m0.002s

Thanks in advance for all your wonderful comments,
Immanuel
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Efficient string output

[Duncan Coutts]

On Mon, 2009-02-09 at 12:49 +0100, Ketil Malde wrote:
> Hi,
> 
> I'm currently working on a program that parses a large binary file and
> produces various textual outputs extracted from it.  Simple enough.
> 
> But: since we're talking large amounts of data, I'd like to have
> reasonable performance.  
> 
> Reading the binary file is very efficient thanks to Data.Binary.
> However, output is a different matter.  Currently, my code looks
> something like:

Have you considered using Data.Binary to output the data too? It has a
pretty efficient underlying monoid for accumulating output data in a
buffer. You'd want some wrapper functions over the top to make it a bit
nicer for your use case, but it should work and should be quick.

It generates a lazy bytestring, but does so with a few large chunks so
the IO will still be quick.

Duncan

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Efficient string output

[Eugene Kirpichov]

+1; it's obviously the packing that causes sloth.
Memoize the "pack "\t"" etc. stuff , and write bytestring replacements
for show for your data.
I guess you can use the Put monad instead of B.concat for that, by the way.

2009/2/9 Bulat Ziganshin :
> Hello Ketil,
>
> Monday, February 9, 2009, 2:49:05 PM, you wrote:
>
>> in B.concat [f1,pack "\t",pack (show f2),...]
>
>> inelegance were it only fast - but this ends up taking the better part
>> of the execution time.
>
> i'm not a BS expert but it seems that you produce Strings using show
> and then convert them to BS. of course this is inefficient - you need
> to replace show with BS analog
>
> --
> Best regards,
>  Bulatmailto:bulat.zigans...@gmail.com
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] evaluation semantics of bind

[Gregg Reynolds]

On Sun, Feb 8, 2009 at 6:25 PM, Richard O'Keefe  wrote:

>
> On 6 Feb 2009, at 4:20 am, Gregg Reynolds wrote:
>
>>  However, consider:
>>
>>getChar >>= \x -> getChar
>>
>> An optimizer can see that the result of the first getChar is discarded and
>> replace the entire expression with one getChar without changing the formal
>> semantics.
>>
>
> But the result of the first getChar is *NOT* discarded.
> **As an analogy**, think of the type IO t as (World -> (t,World))
> for some hidden type World, and
>getChar w = (c, w')
>-- get a character c out of world w somehow,
>-- changing w to w' as you go
>(f >>= g) w = let (v,w') = f w in (g v) w'
>
> In this analogy, you see that the result of getChar is a value of
> type IO Char (not of type Char), and that while the character
> part of the result of performing the result of getChar may be
> discarded, the "changed world" part is NOT.


That's an implementation detail.  It doesn't account for other possible IO
implementations.

My original question was motivated by the observation that a human reader of
an expression of the form "e >>= f" , on seeing that f is constant, may pull
the constant value out of f, disregard e and dispense with the application f
e.  So can a compiler, unless IO expressions are involved, in which case
such optimizations are forbidden.  I wondered if that was due to the
semantics of >>= or the semantics of IO.

To summarize what I've concluded thanks to the helpful people on
haskell-cafe:

The compiler can optimize e >>= f except for any IO expressions in e and f.
IO expressions must be evaluated, due to the semantics of IO.  The may not
be disregarded, memoized, or substituted.  IO semantics may be implemented
in different ways by different compilers; these implementation techniques
are not part of the formal semantics of the language, which may be expressed
as above:  IO expressions must be evaluated wherever and whenever they
occur.

The bind operator >>= enforces sequencing on arguments containing IO
expressions, but does not force evaluation.  Even bind expressions involving
IO may be optimized.  For example:

  getChar >>= \x -> .. putChar 'c'

The compiler may discard  (assuming it contains no IO
expressions), but it must evaluate getChar and putChar (due to IO semantics)
in the correct order (due to bind semantics).

Thanks all,

gregg
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Efficient string output

[Ketil Malde]

Johan Tibell  writes:

> Is building the strict ByteString what takes the most time? 

Yes.

> If so, you might want to use `writev` to avoid extra copying. 

Is there a Haskell binding somewhere, or do I need to FFI the system
call?  Googling 'writev haskell' didn't turn up anything useful.

> Does your data support incremental processing so that you could
> produce output before all input has been parsed?

Typically, yes.

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Efficient string output

[Bulat Ziganshin]

Hello Ketil,

Monday, February 9, 2009, 2:49:05 PM, you wrote:

> in B.concat [f1,pack "\t",pack (show f2),...]

> inelegance were it only fast - but this ends up taking the better part
> of the execution time.

i'm not a BS expert but it seems that you produce Strings using show
and then convert them to BS. of course this is inefficient - you need
to replace show with BS analog

-- 
Best regards,
 Bulatmailto:bulat.zigans...@gmail.com

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Haddock Markup

[Wolfgang Jeltsch]

Am Samstag, 7. Februar 2009 13:46 schrieb Khudyakov Alexey:
> On Friday 06 February 2009 21:24:35 Andy Smith wrote:
> > 2009/2/6 Wolfgang Jeltsch :
> > > So using TeX as a general language for math is a very bad idea, in my
> > > opinion. The problem is that there is no good language which provides
> > > enough structural information for conversion into MathML and is at the
> > > same time simple to write and read. Maybe, both requirements
> > > contradict.
> >
> > ASCIIMathML [1] is designed to do this. It doesn't cover everything in
> > Presentation MathML, and makes no attempt to handle Content MathML,
> > but you can do quite a lot with it. The notation has a formally
> > defined grammar and rules for conversion to MathML [2].
> >
> > [1] http://www1.chapman.edu/~jipsen/asciimath.html
> > [2] http://www1.chapman.edu/~jipsen/mathml/asciimathsyntax.html
>
> TeX aim is presentation quality not structural information. And it's rather
> good at it. If one want really good looking formulae TeX is the answer.

This is only true if your destination format is PDF, DVI or PS. For a webpage, 
you’ll need MathML in the end and TeX is not so good in producing MathML, I 
suppose.

> ASCIIMathML is nice but its produce not so good looking formulae.

How can you say that in general? ASCIIMathML can be converted into several 
formats (in principal) and is usually converted into MathML. And the 
rendering of MathML depends very much on the browser, plugin or whatever. Are 
there general deficiencies in ASCIIMathML or its usual conversion into MathML 
that prevent any MathML renderer from doing a good job? Or is it just a 
problem with your concrete MathML renderer?

> I've tried it some time ago and found it clearly inferior to TeX. It gives
> too little control over presentation.

If you want a format suitable for multiple output formats (including more 
strucuture-oriented ones like MathML) than control over presentation is 
probably not what you want.

> I wasn't able even to place integration indices exactly over and under
> integral sign. 

In my opinion, you should just say what the indices are and the renderer 
should place them correctly. If it doesn’t, it’s a failure of the renderer, 
not of ASCIIMathML.

Best wishes,
Wolfgang
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Efficient string output

[Johan Tibell]

On Mon, Feb 9, 2009 at 12:49 PM, Ketil Malde  wrote:
> Reading the binary file is very efficient thanks to Data.Binary.
> However, output is a different matter.  Currently, my code looks
> something like:
>
>  summarize :: Foo -> ByteString
>  summarize f = let f1 = accessor f
>f2 = expression f
>   :
>in B.concat [f1,pack "\t",pack (show f2),...]
>
> which isn't particularly elegant, and builds a temporary ByteString
> that usually only get passed to B.putStrLn.  I can suffer the
> inelegance were it only fast - but this ends up taking the better part
> of the execution time.

Is building the strict ByteString what takes the most time? If so, you
might want to use `writev` to avoid extra copying. Does your data
support incremental processing so that you could produce output before
all input has been parsed?

Cheers,

Johan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Efficient string output

[Ketil Malde]

Hi,

I'm currently working on a program that parses a large binary file and
produces various textual outputs extracted from it.  Simple enough.

But: since we're talking large amounts of data, I'd like to have
reasonable performance.  

Reading the binary file is very efficient thanks to Data.Binary.
However, output is a different matter.  Currently, my code looks
something like:

  summarize :: Foo -> ByteString
  summarize f = let f1 = accessor f
f2 = expression f
   :
in B.concat [f1,pack "\t",pack (show f2),...]

which isn't particularly elegant, and builds a temporary ByteString
that usually only get passed to B.putStrLn.  I can suffer the
inelegance were it only fast - but this ends up taking the better part
of the execution time.

I tried to use lazy ByteStrings, the theory being that the components
that already are (strict) ByteStrings could be recycled as chunks.  I
also tried to push the output down into the function 
(summarize :: Foo -> IO ()), but both of these were actuall slower.

Since I surely can't be the first person that needs to output
tab-separated text, I'd be grateful if somebody could point me in the
right direction. 

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Monad explanation

[Sittampalam, Ganesh]

> My bad, I restate:  a value cannot be both static and dynamic.  Or an
> object and a morphism.  Or an element and a function.  Sure, you can
> treat a morphism as an object, but only by moving to a higher (or
> different) level of abstraction.  That doesn't erase the difference
> between object and morphism.  If you do erase that difference you end
> up with mush.  getChar /looks/ like an object, but semantically it
> must be a morphism.  But it can't be a function, since it is
> non-deterministic.   So actually the logical contradiction comes from
> the nature of the beast.
> 
> Another reason it's confusing to newcomers:  it's typed as "IO Char",
> which looks like a type constructor.  One would expect getChar to
> yield a value of type IO Char, no?  But it delivers a Char instead. 
> This is way confusing.  So I take "type IO foo" to mean "type foo,
> after a side effect".  In a sense "getChar :: IO Char" isn't even a
> true type signature. 

It does yield a value of type IO Char, which it also happens that you
can ask the Haskell runtime to interpret by combining it with other
IO values using >>= and invoking it from the top-level.
*When interpreted in this way* it delivers a Char, but that's precisely
the point at which we move to the different level of abstraction you
mention above.

Ganesh

==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Monad explanation

[Lennart Augustsson]

Huh?  The getChar function does yield a value of type (IO Char),
exactly as the type signature says.
If you want access to the Char you must use a >>=, just like in any other monad.

2009/2/9 Gregg Reynolds :
> On Mon, Feb 9, 2009 at 4:38 AM, Tony Morris  wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> I also agree it is a value.
>> The original post was attempting to make a distinction that does not
>> exist. I deliberately avoided that topic.
>>
>> "A thing cannot be both a value and a function, but e,g, getChar"
>>
>> My original intent was to hope the poster reconsidered the whole post.
>> You've blown my cover :)
>
> My bad, I restate:  a value cannot be both static and dynamic.  Or an object
> and a morphism.  Or an element and a function.  Sure, you can treat a
> morphism as an object, but only by moving to a higher (or different) level
> of abstraction.  That doesn't erase the difference between object and
> morphism.  If you do erase that difference you end up with mush.  getChar
> /looks/ like an object, but semantically it must be a morphism.  But it
> can't be a function, since it is non-deterministic.   So actually the
> logical contradiction comes from the nature of the beast.
>
> Another reason it's confusing to newcomers:  it's typed as "IO Char", which
> looks like a type constructor.  One would expect getChar to yield a value of
> type IO Char, no?  But it delivers a Char instead.  This is way confusing.
> So I take "type IO foo" to mean "type foo, after a side effect".  In a sense
> "getChar :: IO Char" isn't even a true type signature.
>
> In any case, many thanks to all who have contributed to the thread.  It's
> sharpened my thinking revealed weaknesses in my terminology, and I expect
> I'll make my inevitable contribution to the infinite Haskell tutorial on the
> topic before too long.
>
> -gregg
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Monad explanation

[Gregg Reynolds]

On Mon, Feb 9, 2009 at 4:38 AM, Tony Morris  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I also agree it is a value.
> The original post was attempting to make a distinction that does not
> exist. I deliberately avoided that topic.
>
> "A thing cannot be both a value and a function, but e,g, getChar"
>
> My original intent was to hope the poster reconsidered the whole post.
> You've blown my cover :)
>

My bad, I restate:  a value cannot be both static and dynamic.  Or an object
and a morphism.  Or an element and a function.  Sure, you can treat a
morphism as an object, but only by moving to a higher (or different) level
of abstraction.  That doesn't erase the difference between object and
morphism.  If you do erase that difference you end up with mush.  getChar
/looks/ like an object, but semantically it must be a morphism.  But it
can't be a function, since it is non-deterministic.   So actually the
logical contradiction comes from the nature of the beast.

Another reason it's confusing to newcomers:  it's typed as "IO Char", which
looks like a type constructor.  One would expect getChar to yield a value of
type IO Char, no?  But it delivers a Char instead.  This is way confusing.
So I take "type IO foo" to mean "type foo, after a side effect".  In a sense
"getChar :: IO Char" isn't even a true type signature.

In any case, many thanks to all who have contributed to the thread.  It's
sharpened my thinking revealed weaknesses in my terminology, and I expect
I'll make my inevitable contribution to the infinite Haskell tutorial on the
topic before too long.

-gregg
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Monad explanation

[Lennart Augustsson]

Sorry, I should have come down on the original poster too. ;)
Functions are values, after all.

On Mon, Feb 9, 2009 at 10:38 AM, Tony Morris  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I also agree it is a value.
> The original post was attempting to make a distinction that does not
> exist. I deliberately avoided that topic.
>
> "A thing cannot be both a value and a function, but e,g, getChar"
>
> My original intent was to hope the poster reconsidered the whole post.
> You've blown my cover :)
>
>
> Lennart Augustsson wrote:
>> But an (IO Char) is a value.  You can do all the things with it
>> that you can do with values, e.g., pass it as an argument, stick it
>> in a list, etc.  It is a special kind of value, since if it ever
>> "gets in contact with" the top level it will be executed. But the
>> fact that IO types also behave as values makes Haskell a very
>> powerful imperative language.
>>
>> On Mon, Feb 9, 2009 at 11:14 AM, Tony Morris 
>> wrote: You're right - my statement is inaccurate.
>>
>> Implementation details aside, I am referring specifically to the
>> statement "getChar ... has the type signature of a value". It
>> clearly does not.
>>
>> Lennart Augustsson wrote:
> Not it doesn't.  getChar has the type signature IO Char. The
> IO type is abstract.  GHC happens to implement it by a state
> monad. But in, e.g., hbc it is implemented in a totally
> different way, more like a continuation monad.
>
> Peeking inside an implementation of IO can be illuminating,
> but one must remember that IO is abstract.
>
> -- Lennart
>
> On Mon, Feb 9, 2009 at 10:26 AM, Tony Morris
>  wrote: Gregg Reynolds wrote:
 The point being that the metalanguage commonly used to
 describe IO in Haskell contains a logical
 contradiction.  A thing cannot be both a value and a
 function, but e,g, getChar behaves like a function and
 has the type signature of a value.
> getChar has the signature RealWorld -> (RealWorld, Char)
>
>> ___ Haskell-Cafe
>> mailing list Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>
>
> - --
> Tony Morris
> http://tmorris.net/
>
> S, K and I ought to be enough for anybody.
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkmQB5EACgkQmnpgrYe6r60L5QCfffj1Vy2Yg25adZLsLBReOk/K
> ZAoAoISEpzQH/9D0AzQOZdxJoxmoKeBj
> =+ZZx
> -END PGP SIGNATURE-
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Monad explanation

[Tony Morris]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I also agree it is a value.
The original post was attempting to make a distinction that does not
exist. I deliberately avoided that topic.

"A thing cannot be both a value and a function, but e,g, getChar"

My original intent was to hope the poster reconsidered the whole post.
You've blown my cover :)


Lennart Augustsson wrote:
> But an (IO Char) is a value.  You can do all the things with it
> that you can do with values, e.g., pass it as an argument, stick it
> in a list, etc.  It is a special kind of value, since if it ever
> "gets in contact with" the top level it will be executed. But the
> fact that IO types also behave as values makes Haskell a very
> powerful imperative language.
>
> On Mon, Feb 9, 2009 at 11:14 AM, Tony Morris 
> wrote: You're right - my statement is inaccurate.
>
> Implementation details aside, I am referring specifically to the
> statement "getChar ... has the type signature of a value". It
> clearly does not.
>
> Lennart Augustsson wrote:
 Not it doesn't.  getChar has the type signature IO Char. The
 IO type is abstract.  GHC happens to implement it by a state
 monad. But in, e.g., hbc it is implemented in a totally
 different way, more like a continuation monad.

 Peeking inside an implementation of IO can be illuminating,
 but one must remember that IO is abstract.

 -- Lennart

 On Mon, Feb 9, 2009 at 10:26 AM, Tony Morris
  wrote: Gregg Reynolds wrote:
>>> The point being that the metalanguage commonly used to
>>> describe IO in Haskell contains a logical
>>> contradiction.  A thing cannot be both a value and a
>>> function, but e,g, getChar behaves like a function and
>>> has the type signature of a value.
 getChar has the signature RealWorld -> (RealWorld, Char)

> ___ Haskell-Cafe
> mailing list Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>

- --
Tony Morris
http://tmorris.net/

S, K and I ought to be enough for anybody.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmQB5EACgkQmnpgrYe6r60L5QCfffj1Vy2Yg25adZLsLBReOk/K
ZAoAoISEpzQH/9D0AzQOZdxJoxmoKeBj
=+ZZx
-END PGP SIGNATURE-

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Monad explanation

[Lennart Augustsson]

But an (IO Char) is a value.  You can do all the things with it that
you can do with values, e.g., pass it as an argument, stick it in a
list, etc.  It is a special kind of value, since if it ever "gets in
contact with" the top level it will be executed.
But the fact that IO types also behave as values makes Haskell a very
powerful imperative language.

On Mon, Feb 9, 2009 at 11:14 AM, Tony Morris  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> You're right - my statement is inaccurate.
>
> Implementation details aside, I am referring specifically to the
> statement "getChar ... has the type signature of a value". It clearly
> does not.
>
> Lennart Augustsson wrote:
>> Not it doesn't.  getChar has the type signature IO Char. The IO
>> type is abstract.  GHC happens to implement it by a state monad.
>> But in, e.g., hbc it is implemented in a totally different way,
>> more like a continuation monad.
>>
>> Peeking inside an implementation of IO can be illuminating, but one
>> must remember that IO is abstract.
>>
>> -- Lennart
>>
>> On Mon, Feb 9, 2009 at 10:26 AM, Tony Morris 
>> wrote: Gregg Reynolds wrote:
> The point being that the metalanguage commonly used to
> describe IO in Haskell contains a logical contradiction.  A
> thing cannot be both a value and a function, but e,g, getChar
> behaves like a function and has the type signature of a
> value.
>> getChar has the signature RealWorld -> (RealWorld, Char)
>>
>>>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>
>
> - --
> Tony Morris
> http://tmorris.net/
>
> S, K and I ought to be enough for anybody.
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkmQAfkACgkQmnpgrYe6r61tmQCcCx42Cz1iunkD7JGubla/z2Pg
> uhAAoLk5rkjeHnrfc936IhYoBQYO/+0r
> =6xWk
> -END PGP SIGNATURE-
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Switching from Mercurial to Darcs

[Paolo Losi]

Thomas Davie wrote:


On 6 Feb 2009, at 10:12, Paolo Losi wrote:


Henning Thielemann wrote:


4) hg commit -m "message"
this commits my changes locally. I always do this before pulling since
then I'm sure my changes are saved in the case a merge goes wrong.

In old darcs its precisely the other way round. Since it is so slow on
merging ready patches, you better merge uncrecorded changes.


IMO pulling & merging before commit is a good practise also for hg:
it avoids a (very often useless) merge commit in the history.


I don't understand this view.  Isn't the point of a commit that you flag 
working points.  In each branch, before you merge (hopefully) you have a 
working repository, so flag it as such, and commit.  When you merge, you 
may or may not have a working repository, fix it until it is, and merge.


I would never do a merge without the two branches I was merging having a 
commit just before the merge.


Bob


I think you're right. but:

- if you synch with the central repo at every commit you usually have
  a sort of out of band protocol with your peers for avoiding conflicts
  and in case of conflicts the manual merge is easy (if you occasionally
  merge unrelated branches that is obviously a different story)

- the problem with mercurial is that it doesn't allow to amend history
  (you cannot afford to "merge" the first commit with the
  "merge" commit) and the commit history becomes cluttered.

That's the reason why I prefer (in the case
of commit/sync/commit/sync... scenario) pulling and updating
before committing.

AFAIK darcs and git doesn't have this problem, so the
approach your suggesting should be the best in any case.

I'm an "old" user of mercurial but I'm starting seeing some
shortcomings with respect to git (and probably darcs).

I really hope there will be some sort of convergence on a de facto
DVCS soon in the opensource community :-)

Paolo

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe