Re: Existentials and type var escaping

Roberto Zunino wrote:
> foo, as defined above does not work (lazy patterns not allowed), and in
> 
> foo y = E (case y of E x -> x)
> 
> a variable escapes. I also tried with CPS with no success.
> 
> Is foo definable at all? I'm starting to think that it is not, and that
> there must be a very good reason for that...

It's not definable, and there is a good reason. Existential boxes in 
principle contain an extra field storing their hidden type, and the type 
language is strongly normalizing. If you make the type argument explicit, 
you have

   foo (E <t> x) = E <t> x
   foo _|_ = E ??? _|_

The ??? can't be a divergent type term, because there aren't any; it must be 
a type, but no suitable type is available (foo has no type argument). You 
can't even use some default dummy type like (), even though _|_ does have 
that type, because you'd have to solve the halting problem to tell when it's 
safe to default.

I'm less clear on how important it is that type terms don't diverge. I think 
it may be possible to write cast :: a -> b if this restriction is removed, 
but I don't actually know how to do it.

-- Ben

found monad in a comic

<http://xkcd.com/c248.html>
( join /= coreturn )

IMHO this could be a beautiful and easy way to explain monads.
comments?

- marc

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: found monad in a comic

On Tue, 2007-06-12 at 04:16 +0200, Marc A. Ziegert wrote:
> <http://xkcd.com/c248.html>
> ( join /= coreturn )
> 
> IMHO this could be a beautiful and easy way to explain monads.
> comments?
> 
> - marc

Reader IceCream

Monad Transformer (Was: Just curios)

On Mon, 11 Jun 2007, Andrew Coppin wrote:

> Paul Hudak wrote:
> > As reported in the recent HOPL paper, /A History of Haskell/, Haskell
> > Brooks Curry actually didn't like his first name!  I learned this when
> > I visited his wife, Virginia Curry, at the time when we decided to
> > name a language after her husband.
>
> Yes... I recall reading that somewhere. (Irony, eh? Name something after
> somebody and find they hated the name anyway...)
>
>
> I *also* distinctly recall reading somewhere the following words:
>
>   "Of course, our biggest mistake was using the word 'monad'. We should
> have called it 'warm fuzzy thing'..."

This is no longer a problem, because you can visit a web with (almost) no
monads:
  http://saxophone.jpberlin.de/MonadTransformer?source=http%3A%2F%2Fwww%2Ehaskell%2Eorg%2Fhaskellwiki%2FCategory%3AMonad

Re: killThread on a terminated thread.

Bit Connor wrote:
> Is it safe to use killThread to terminate a thread that has already
> terminated(it's IO action has run to completion)? Or are ThreadIds
> reused, potentially causing an unwanted thread to be terminated?

Yes, it's safe.

Simon

Re: tail recursion ?

Simon Brenner <simbr843 <at> student.liu.se> writes:
> > listOfIndices' ubound = concat [ [i,(2*i) .. ubound] | i <- [1..ubound] ]
> > calc ubound = accumArray (const.not) False (1,ubound) $
> > 	[(x,False) | x <- listOfIndices ubound]

Thanks a lot! 
Your solution works fine as long as there are not to much modifications (you 
mentioned the memory...)

-- accumArray -----------------------------------
       20 Mb total memory in use

INIT  time    0.02s  (  0.00s elapsed)
MUT   time    1.73s  (  1.81s elapsed)
GC    time    2.83s  (  2.86s elapsed)
EXIT  time    0.00s  (  0.01s elapsed)
Total time    4.59s  (  4.68s elapsed)

So I tried another possibility, STUArrays, which are significantly faster and 
use less memory:

-------------------------------------------------
main = mapM_ print $ filter snd $ runST calc
x = 100000 :: Int
calc = do 
  arr <- newArray (1,x) False :: ST s (STUArray s Int Bool)
  calc' arr
  d <- getAssocs arr
  return (d)
    where

Re: Re: Mathematica

On Sun, May 13, 2007 at 02:19:55PM +0100, Andrew Coppin wrote:
> Writing *insanely* efficient number chrunking software requires a deep 
> understanding of the target architecture, and lots of playing with very 
> low-level constructs. Assembly is really the only language you can do it 
> with; even C is probably too high-level.
> 
> The "notebook" interface is very sophisticated and clearly beyond the 
> capabilities of any current GUI toolkit for Haskell. (Implementing this 
> would be approximately as hard as writing a full web browser in Haskell.)
> 
> The pattern matching engine could be implemented, but it's not a trivial 
> task. Mathematica's pattern matching is quite sophisticated. It would 
> take someone a while to do, that's all.

Thanks, that's exactly what we need - someone telling it's impossible
motivating somebody else to prove it isn't 

BTW, how do you know that Mathematica's number chrunking software is
written in assembler? Do they brag about it?

Best regards
Tomek

Re: Just curios

Thomas Schilling wrote:
> On 6/11/07, Andrew Coppin <andrewcoppin <at> btinternet.com> wrote:
>>   "Of course, our biggest mistake was using the word 'monad'. We should
>> have called it 'warm fuzzy thing'..."
>
> You know that thing called "Google"? ;)
>
>  http://lambda-the-ultimate.org/node/92
>
> Among others.
>
I don't see any reference t-- oh, wait. Half way down the 20-mile page. 
I see it now. Simon (the PJ one) says

  "Our biggest mistake [in designing Haskell] was using the scary term 
'monad' rather than 'warm fuzzy thing'."

in Wearing the hair shirt: A retrospective on Haskell. And now I have a 
URL. >

Construct all possible trees

I'm trying to construct a function

  all_trees :: [Int] -> [Tree]

such that all_trees [1,2,3] will yield

[
Leaf 1,
Leaf 2,
Leaf 3,
Branch (Leaf 1) (Leaf 2),
Branch (Leaf 1) (Leaf 3),
Branch (Leaf 2) (Leaf 1),
Branch (Leaf 2) (Leaf 3),
Branch (Leaf 3) (Leaf 1),
Branch (Leaf 3) (Leaf 2),
Branch (Branch (Leaf 1) (Leaf 2)) (Leaf 3),
Branch (Branch (Leaf 1) (Leaf 3)) (Leaf 1),
Branch (Branch (Leaf 2) (Leaf 1)) (Leaf 3),
Branch (Branch (Leaf 2) (Leaf 3)) (Leaf 1),
Branch (Branch (Leaf 3) (Leaf 1)) (Leaf 2),
Branch (Branch (Leaf 3) (Leaf 2)) (Leaf 1),
Branch (Leaf 1) (Branch (Leaf 2) (Leaf 3)),
Branch (Leaf 1) (Branch (Leaf 3) (Leaf 2)),
Branch (Leaf 2) (Branch (Leaf 1) (Leaf 3)),
Branch (Leaf 2) (Branch (Leaf 3) (Leaf 2)),
Branch (Leaf 3) (Branch (Leaf 1) (Leaf 2)),
Branch (Leaf 3) (Branch (Leaf 2) (Leaf 1))
]

Re: Re: Mathematica

On Tuesday 12 June 2007 18:41:34 Tomasz Zielonka wrote:
> On Sun, May 13, 2007 at 02:19:55PM +0100, Andrew Coppin wrote:
> > Writing *insanely* efficient number chrunking software requires a deep
> > understanding of the target architecture, and lots of playing with very
> > low-level constructs. Assembly is really the only language you can do it
> > with; even C is probably too high-level.

Just reuse existing libraries: BLAS, LAPACK, ATLAS, FFTW. The free libraries 
that I have benchmarked were all much faster than Mathematica. FFTW was 4x 
faster on average, for example.

> > The "notebook" interface is very sophisticated and clearly beyond the
> > capabilities of any current GUI toolkit for Haskell. (Implementing this
> > would be approximately as hard as writing a full web browser in Haskell.)

Yes. Our technical presentation software took 6 man months but it supported 
antialiasing, real-time visualization and zooming and panning of the whole 
GUI. A simple notebook interface rendering to OpenGL would only be ~20kLOC of 
OCaml/Haskell.

> > The pattern matching engine could be implemented, but it's not a trivial
> > task. Mathematica's pattern matching is quite sophisticated. It would
> > take someone a while to do, that's all.

Beyond the pattern matchers in ML and Haskell, Mathematica adds sequence 
patterns. These just search linear sequences or permutations completely 
naively.

For example, the obvious implementation of the higher-order map function has 
quadratic complexity because Mathematica eagerly copies entire sub arrays "t"