date:20081215

#2864: ghc: panic! (the 'impossible' happened) -- Please report this as a GHC 
bug
-+--
Reporter:  megacz|Owner: 
Type:  bug   |   Status:  closed 
Priority:  normal|Milestone:  6.12 branch
   Component:  Compiler  |  Version:  6.11   
Severity:  major |   Resolution:  fixed  
Keywords:|   Difficulty:  Unknown
Testcase:|   Os:  MacOS X
Architecture:  x86   |  
-+--
Changes (by simonmar):

  * status:  new = closed
  * resolution:  = fixed

Comment:

 Worked around this bug for now:

 {{{
 Mon Dec 15 02:02:21 PST 2008  Simon Marlow marlo...@gmail.com
   * Revert CorePrep part of Completely new treatment of INLINE
 pragmas...

   The original patch said:

   * I made some changes to the way in which eta expansion happens in
 CorePrep, mainly to ensure that *arguments* that become let-bound
 are also eta-expanded.  I'm still not too happy with the clarity
 and robustness fo the result.

   Unfortunately this change apparently broke some invariants that were
   relied on elsewhere, and in particular lead to panics when compiling
   with profiling on.

   Will re-investigate in the new year.
 }}}

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2864#comment:7
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

[GHC] #2882: variable escaping in existential type error on 6.8 but not 6.10

#2882: variable escaping in existential type error on 6.8 but not 6.10
-+--
Reporter:  ckeen |  Owner:  
Type:  bug   | Status:  new 
Priority:  normal|  Component:  Compiler
 Version:  6.10.1|   Severity:  normal  
Keywords:|   Testcase:  
  Os:  Unknown/Multiple  |   Architecture:  x86 
-+--
 I wrote a patch for darcs that does the following:
 {{{
 'l' - do let selected = case get_choices pc of
   (first_chs:_:last_chs) -
  if whichch == Last || whichch
 == FirstReversed
 then last_chs else
 first_chs
   putStrLn $  Already selected ++things++ 
   mapM_ putDocLn $ mapFL (\a -
 showPatch `unseal2` (seal2 $ tp_patch a)) selected
 }}}

 where
 {{{
 get_choices :: Patchy p = PatchChoices p C(x y) - (FL (TaggedPatch p) :
 FL (TaggedPatch p) : FL (TaggedPatch p)) C(x y)
 data (a1 : a2) C(x y) = FORALL(z) (a1 C(x z)) : (a2 C(z y))
 data FL a C(x z) where
 (::) :: a C(x y) - FL a C(y z) - FL a C(x z)
 NilFL :: FL a C(x x)

 }}}

 This gives an error with ghc-6.8.2 on Mac OS X (others have reported
 errors with 6.8.3 as well):

 {{{
 Inferred type is less polymorphic than expected
   Quantified type variable `z2' escapes
 When checking an existential match that binds
 first_chs :: FL (TaggedPatch p) x z1
 last_chs :: FL (TaggedPatch p) z2 z
 The pattern(s) have type(s): (:)
(FL (TaggedPatch p))
(FL (TaggedPatch p) : FL (TaggedPatch
 p))
x
z
 The body has type: FL (TaggedPatch p) z2 z
 In a case alternative:
 (first_chs : _ : last_chs)
   - if whichch == Last || whichch == FirstReversed then
  last_chs
  else
  first_chs
 In the expression:
 case get_choices pc of
   (first_chs : _ : last_chs)
 - if whichch == Last || whichch == FirstReversed then
last_chs
else
first_chs

 }}}

 I have been convinced that this is indeed a programming error by the fine
 people on #ghc. So the remaining question is: Why does it work on
 ghc-6.10.1?

 I will try if I can construct a simpler test case.

 Thanks,

 Christian

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2882
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #2882: variable escaping in existential type error on 6.8 but not 6.10

#2882: variable escaping in existential type error on 6.8 but not 6.10
--+-
 Reporter:  ckeen |  Owner: 
 Type:  bug   | Status:  closed 
 Priority:  normal|  Milestone: 
Component:  Compiler  |Version:  6.10.1 
 Severity:  normal| Resolution:  invalid
 Keywords:|   Testcase: 
   Os:  Unknown/Multiple  |   Architecture:  x86
--+-
Changes (by ckeen):

  * status:  new = closed
  * resolution:  = invalid

Comment:

 actually this has been identified as a user error.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2882#comment:1
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #2862: GHC Panic in ByteCodeGen

#2862: GHC Panic in ByteCodeGen
-+--
Reporter:  nominolo  |Owner:  
Type:  bug   |   Status:  closed  
Priority:  normal|Milestone:  
   Component:  Compiler  |  Version:  6.11
Severity:  normal|   Resolution:  fixed   
Keywords:|   Difficulty:  Unknown 
Testcase:|   Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  |  
-+--
Changes (by simonmar):

  * status:  new = closed
  * difficulty:  = Unknown
  * resolution:  = fixed

Comment:

 It works after this partial reversion:

 {{{
 Mon Dec 15 02:02:21 PST 2008  Simon Marlow marlo...@gmail.com
   * Revert CorePrep part of Completely new treatment of INLINE
 pragmas...

   The original patch said:

   * I made some changes to the way in which eta expansion happens in
 CorePrep, mainly to ensure that *arguments* that become let-bound
 are also eta-expanded.  I'm still not too happy with the clarity
 and robustness fo the result.

   Unfortunately this change apparently broke some invariants that were
   relied on elsewhere, and in particular lead to panics when compiling
   with profiling on.

   Will re-investigate in the new year.
 }}}

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2862#comment:1
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

[GHC] #2883: setitimer(ITIMER_VIRTUAL) is not always available

#2883: setitimer(ITIMER_VIRTUAL) is not always available
-+--
Reporter:  sthibaul  |  Owner:  
Type:  bug   | Status:  new 
Priority:  normal|  Component:  Compiler
 Version:  6.8.2 |   Severity:  normal  
Keywords:|   Testcase:  
  Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
-+--
 On some limited systems, setitimer(ITIMER_VIRTUAL) returns ENOSYS
 because the kernel does not provide a way to schedule timers based on
 virtual time. In such a case, rts/posix/Itimer.c should use
 ITIMER_REAL.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2883
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

[GHC] #2884: Compiled code performance worsens when module names are long enough

#2884: Compiled code performance worsens when module names are long enough
-+--
Reporter:  jcpetruzza|  Owner:  
Type:  bug   | Status:  new 
Priority:  normal|  Component:  Compiler
 Version:  6.10.1|   Severity:  normal  
Keywords:|   Testcase:  
  Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
-+--
 Attached to this report is an example where by simply renaming a module,
 performance degrades 2.5 times.

 {{{
 #diff long-modname-ver.hs short-modname-ver.hs
 2c2
  import VeryLongModuleName
 ---
  import ShortM

 #diff VeryLongModuleName.hs ShortM.hs
 1c1
  module VeryLongModuleName
 ---
  module ShortM

 #ghc --make -O2 -Wall long-modname-ver.hs

 #ghc --make -O2 -Wall short-modname-ver.hs

 #time -p ./long-modname-ver  /dev/null
 real 55.90
 user 55.17
 sys 0.51

 #time -p ./short-modname-ver  /dev/null
 real 22.23
 user 21.97
 sys 0.10
 }}}

 According to some measures by dons, the threshold seems to be at module
 length 10 (see attached graph).

 Some further disussion on this thread
 [http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/16037].

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2884
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

[GHC] #2885: Late and confusing error on uncallable class method

#2885: Late and confusing error on uncallable class method
-+--
Reporter:  blamario  |  Owner:
Type:  bug   | Status:  new   
Priority:  normal|  Component:  Compiler  
 Version:  6.10.1|   Severity:  minor 
Keywords:|   Testcase:
  Os:  Linux |   Architecture:  x86_64 (amd64)
-+--
 This has been discussed on Haskell Café (http://www.haskell.org/pipermail
 /haskell-cafe/2008-December/051856.html), I'm reporting it here in case
 something can be done to help other confused souls in future.

 In short, the error message reported by GHC (6.10.1):

 {{{
 Could not deduce (Container x y) from the context (Container x y1)
   arising from a use of `wrapper' at Test.hs:11:22-30
 Possible fix:
   add (Container x y) to the context of
 the type signature for `liftWrap'
 In the expression: wrapper x
 In the expression:
 (if wrapper x then rewrap . f . unwrap else id) x
 In the definition of `liftWrap':
 liftWrap f x = (if wrapper x then rewrap . f . unwrap else id) x
 }}}

 does not begin to indicate that the actual problem with the following
 program is in the type class declaration:

 {{{
{-# LANGUAGE MultiParamTypeClasses, FlexibleInstances #-}

import Data.Maybe

class Container x y where
   wrapper :: x - Bool
   unwrap :: x - y
   rewrap :: y - x

liftWrap :: Container x y = (y - y) - (x - x)
liftWrap f x = (if wrapper x then rewrap . f . unwrap else id) x

instance Container (Maybe x) x where
   wrapper = isJust
   unwrap = fromJust
   rewrap = Just

main = print (liftWrap (succ :: Int - Int) (Just 1 :: Maybe Int))
 }}}

 If the 'wrapper' method can never be called in any possible context, there
 should be an error report at the point where the method is declared. I
 don't think that's a controversial statement. Even if the compiler allows
 the declaration under the assumption that the useless method is never
 called, it should at least emit a strong warning.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2885
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: ghc 6.10.1 on freebsd 7 amd64 - ghci problems


Markus Barenhoff wrote:

I've updated my source tree today. 


But now I've problem while compiling the ghc

Here is the the build output:

[...]

/usr/home/alios/src/haskell/ghc/ghc/ghc/stage1-inplace/ghc 
-DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -package-name ghc-6.11.20081211 
-hide-all-packages -no-user-package-conf -i -idist-stage2/build -inativeGen 
-ibasicTypes -icmm -icodeGen -icoreSyn -icprAnalysis -ideSugar -ighci -ihsSyn 
-iiface -imain -iparser -iprelude -iprofiling -irename -isimplCore -isimplStg 
-ispecialise -istgSyn -istranal -itypecheck -itypes -iutils -ivectorise 
-idist-stage2/build/autogen -Idist-stage2/build/autogen -Idist-stage2/build 
-I../libffi/build/include -Istage2plus -I../libraries/base/cbits 
-I../libraries/base/include -I. -Iparser -Iutils -optP-DGHCI -optP-include 
-optPdist-stage2/build/autogen/cabal_macros.h -odir dist-stage2/build -hidir 
dist-stage2/build -stubdir dist-stage2/build -package Cabal-1.5.5 -package 
array-0.2.0.0 -package base-4.0.0.0 -package bytestring-0.9.1.4 -package 
containers-0.2.0.0 -package directory-1.0.0.2 -package filepath-1.1.0.1 
-package haskell98-1.0.1.0 -package hpc-0.

5.0.2 -package old-time-1.0.0.1 -package process-1.0.1.1 -package 
template-haskell-2.3.0.0 -package unix-2.3.1.0 -O -Wall 
-fno-warn-name-shadowing -fno-warn-orphans -XCPP -XMagicHash -XUnboxedTuples 
-XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls 
-XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRank2Types 
-XScopedTypeVariables -XDeriveDataTypeable -prof -hisuf p_hi -hcsuf p_hc -osuf 
p_o -idist-stage2/build  -H32m -O -Rghc-timing -O2  -c nativeGen/MachRegs.lhs 
-o dist-stage2/build/MachRegs.p_o  -ohi dist-stage2/build/MachRegs.p_hi

ghc: panic! (the 'impossible' happened)
  (GHC version 6.11.20081211 for x86_64-unknown-freebsd):
CoreToStg.myCollectArgs
(__scc {trivColorable ghc-6.11.20081211:MachRegs !}
 ghc-6.11.20081211:MachRegs.isSqueesed{v r2FI} [gid] 0 0)
  eta_s2Ni{v} [lid]

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug


This is a known problem with the build right now.  I'll try to install a 
fix this week, but in the meantime you can avoid building profiled 
libraries by copying mk/build.mk.sample to mk/build.mk and uncommenting the 
line that says 'BuildFlavour = quick'.


Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ghci and ghc -threaded [slowdown]

2008-12-15 Thread Malcolm Wallace

 It seems that the problem you have is that moving to the multithreaded
 runtime imposes an overhead on the communication between your two
 threads,  when run on a *single CPU*.  But performance on a single CPU
 is not what  you're interested in - you said you wanted parallelism,
 and for that you  need multiple CPUs, and hence multiple OS threads.

Well, I'm interested in getting an absolute speedup.  If the threaded
performance on a single core is slightly slower than the non-threaded
performance on a single core, that would be OK provided that the
threaded performance using multiple cores was better than the same
non-threaded baseline.

However, it doesn't seem to work like that at all.  In fact, threaded on
multiple cores was _even_slower_ than threaded on a single core!

Here are some figures:

ghc-6.8.2 -O2  
 apply   MVarstrict  thr-N2  thr-N1
silicium  7.307.95 7.23   15.25  14.71
neghip4.254.43 4.186.67   6.48
hydrogen 11.75   10.8210.99   13.45  12.96
lobster  55.851.5 57.676.6   74.5

The first three columns are variations of the program using slightly
different communications mechanisms, including threads/MVars with the
non-threaded RTS.  The final two columns are for the MVar mechanism
with threaded RTS and either 1 or 2 cores.  -N2 is slowest.

 I suspect the underlying problem in your program is that the
 communication  is synchronous.  To get good parallelism you'll need to
 use asynchronous  communication, otherwise even on multiple CPUs
 you'll see little  parallelism.

I tried using Chans instead of MVars, to provide for different speeds of
reader/writer, but the timings were even worse.  (Add another 15-100%.)

When I have time to look at this again (probably in the New Year), I
will try some other strategies for communication that vary in their
synchronous/asynchronous chunk size, to see if I can pin things down
more closely.

Regards,
Malcolm
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ghci and ghc -threaded [slowdown]


Malcolm Wallace wrote:

It seems that the problem you have is that moving to the multithreaded
runtime imposes an overhead on the communication between your two
threads,  when run on a *single CPU*.  But performance on a single CPU
is not what  you're interested in - you said you wanted parallelism,
and for that you  need multiple CPUs, and hence multiple OS threads.


Well, I'm interested in getting an absolute speedup.  If the threaded
performance on a single core is slightly slower than the non-threaded
performance on a single core, that would be OK provided that the
threaded performance using multiple cores was better than the same
non-threaded baseline.

However, it doesn't seem to work like that at all.  In fact, threaded on
multiple cores was _even_slower_ than threaded on a single core!


Entirely possible - unless there's any actual parallelism, running on 
multiple cores will probably slow things down due to thread migration.



Here are some figures:

ghc-6.8.2 -O2  
 apply   MVarstrict  thr-N2  thr-N1

silicium  7.307.95 7.23   15.25  14.71
neghip4.254.43 4.186.67   6.48
hydrogen 11.75   10.8210.99   13.45  12.96
lobster  55.851.5 57.676.6   74.5

The first three columns are variations of the program using slightly
different communications mechanisms, including threads/MVars with the
non-threaded RTS.  The final two columns are for the MVar mechanism
with threaded RTS and either 1 or 2 cores.  -N2 is slowest.


So you're not getting any parallelism at all, for some reason your program 
is sequentialised.  There could be any number of reasons for this.



I suspect the underlying problem in your program is that the
communication  is synchronous.  To get good parallelism you'll need to
use asynchronous  communication, otherwise even on multiple CPUs
you'll see little  parallelism.


I tried using Chans instead of MVars, to provide for different speeds of
reader/writer, but the timings were even worse.  (Add another 15-100%.)


That would seem to indicate that your program is doing a lot of 
communication - I'd look at trying to reduce that, by increasing task size 
or whatever.  However, the amount of communication is obviously not the 
only issue, there also seems to be some kind of dependency that 
sequentialises the program.


Are you sure that you're not accidentally communicating thunks, and hence 
doing all the computation in one of the threads?  That's a common pitfall 
that has caught me more than once.


Do you know roughly the amount of parallelism you expect - i.e. the amount 
of work done by each thread?



When I have time to look at this again (probably in the New Year), I
will try some other strategies for communication that vary in their
synchronous/asynchronous chunk size, to see if I can pin things down
more closely.


That would be good.  At some point we hope to provide some kind of 
visualisation to let you see where the parallel performance bottlenecks in 
your program are; there are various ongoing efforts but nothing useable as yet.


Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ghci and ghc -threaded [slowdown]


Malcolm Wallace wrote:

Simon Marlow marlo...@gmail.com wrote:


Malcolm Wallace wrote:

For the only application I tried, using the threaded RTS imposes a
100% performance penalty - i.e. computation time doubles, compared
to the non-threaded RTS.  This was with ghc-6.8.2, and maybe the
overhead has improved since then?

This is a guess, but I wonder if this program is concurrent, and does
a  lot of communication between the main thread and other threads? 


Exactly so - it hits the worst case behaviour.  This was a naive attempt
to parallelise an algorithm by shifting some work onto a spare
processor.  Unfortunately, there is a lot of communication to the main
thread, because the work that was shifted elsewhere computes a large
data structure in chunks, and passes those chunks back.  The main thread
then runs OpenGL calls using this data -- and I believe OpenGL calls must
run in a bound thread.

This all suggests that one consequence of ghc's RTS implementation
choices is that it will never be cheap to compute visualization data in
parallel with rendering it in OpenGL.  That would be a shame.  This was
exactly the parallelism I was hoping for.


I'm not sure how we could do any better here.  To get parallelism you need 
to run the OpenGL thread and the worker thread on separate OS threads, 
which we do.  So what aspect of the RTS design is preventing you from 
getting the parallelism you want?


It seems that the problem you have is that moving to the multithreaded 
runtime imposes an overhead on the communication between your two threads, 
when run on a *single CPU*.  But performance on a single CPU is not what 
you're interested in - you said you wanted parallelism, and for that you 
need multiple CPUs, and hence multiple OS threads.


I suspect the underlying problem in your program is that the communication 
is synchronous.  To get good parallelism you'll need to use asynchronous 
communication, otherwise even on multiple CPUs you'll see little 
parallelism.  If you still do asynchronous communication and yet don't get 
good parallelism, then we should look into what's causing that.


Cheers,
Simon

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

length of module name affecting performance??

2008-12-15 Thread Daniel Gorín


Hi

While trying to see if I could make some code run faster I stumbled  
upon something that looks weird to me: 2x-3x performance loss when a  
module is renamed to a longer name!


Here's what I see with the attached examples:

#diff long-modname-ver.hs short-modname-ver.hs
2c2
 import VeryLongModuleName
---
 import ShortM

#diff VeryLongModuleName.hs ShortM.hs
1c1
 module VeryLongModuleName
---
 module ShortM

#ghc --make -O2 -Wall long-modname-ver.hs

#ghc --make -O2 -Wall short-modname-ver.hs

#time -p ./long-modname-ver  /dev/null
real 55.90
user 55.17
sys 0.51

#time -p ./short-modname-ver  /dev/null
real 22.23
user 21.97
sys 0.10

I'm using GHC 6.10.1 on OS X. Any ideas on what may be going on?

Thanks
Daniel



files.tgz
Description: Binary data


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: length of module name affecting performance??

2008-12-15 Thread Neil Mitchell

Hi

 I'm using GHC 6.10.1 on OS X. Any ideas on what may be going on?

 Wow. Awesome bug! Got lots of discussion at Galois :)

 I can confirm a difference in running time, we also tested with 6.8.x and 
 6.10,
 with similar results.

Is -O2 implying -fvia-C? If so, could it be the evil mangler? Is there
a non-alpha rename difference in the Core?

Very cool bug :-)

Thanks

Neil
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: length of module name affecting performance??

Running time as a function of module name length,

http://galois.com/~dons/images/results.png

10 is the magic threshold, where indirections start creeping in.

Codegen cost heuristic fail?

-- Don
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: length of module name affecting performance??

dons:
 Running time as a function of module name length,
 
 http://galois.com/~dons/images/results.png
 
 10 is the magic threshold, where indirections start creeping in.
 
 Codegen cost heuristic fail?

Given this, could you open a bug ticket for it, with all the info we
have,

http://hackage.haskell.org/trac/ghc/newticket?type=bug

E.g. the graph, the code, the asm diff.

Cheers,
  Don
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: length of module name affecting performance??

2008-12-15 Thread Lennart Augustsson

That's a truly awesome feature!  I'll shorten all my module names to
single letters tomorrow.

  -- Lennart

On Tue, Dec 16, 2008 at 12:43 AM, Don Stewart d...@galois.com wrote:
 dons:
 Running time as a function of module name length,

 http://galois.com/~dons/images/results.png

 10 is the magic threshold, where indirections start creeping in.

 Codegen cost heuristic fail?

 Given this, could you open a bug ticket for it, with all the info we
 have,

http://hackage.haskell.org/trac/ghc/newticket?type=bug

 E.g. the graph, the code, the asm diff.

 Cheers,
  Don
 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: length of module name affecting performance??

2008-12-15 Thread Sigbjorn Finne


Ditto. Can I claim the [A-Z].*  hierarchies as belonging to me? :-)

--sigbjorn putting them up on eBay afterwards...maybe

On 12/15/2008 18:00, Lennart Augustsson wrote:

That's a truly awesome feature!  I'll shorten all my module names to
single letters tomorrow.

  -- Lennart

On Tue, Dec 16, 2008 at 12:43 AM, Don Stewart d...@galois.com wrote:
  

dons:


Running time as a function of module name length,

http://galois.com/~dons/images/results.png

10 is the magic threshold, where indirections start creeping in.

Codegen cost heuristic fail?
  

Given this, could you open a bug ticket for it, with all the info we
have,

   http://hackage.haskell.org/trac/ghc/newticket?type=bug

E.g. the graph, the code, the asm diff.

Cheers,
 Don
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users



___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
  


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: length of module name affecting performance??

2008-12-15 Thread Daniel Gorín


On Dec 15, 2008, at 10:43 PM, Don Stewart wrote:


dons:

Running time as a function of module name length,

   http://galois.com/~dons/images/results.png

10 is the magic threshold, where indirections start creeping in.

Codegen cost heuristic fail?


Given this, could you open a bug ticket for it, with all the info we
have,

   http://hackage.haskell.org/trac/ghc/newticket?type=bug

E.g. the graph, the code, the asm diff.

Cheers,
 Don


done! http://hackage.haskell.org/trac/ghc/ticket/2884

thanks,
daniel
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Haskell] possible bug in pretty-1.0.1.0

2008-12-15 Thread John MacFarlane

I noticed a difference in how hang works between pretty-1.0.0.0 and
pretty-1.0.1.0. I think it's a bug. If this isn't the right place to
report it, please let me know where I should.  (Maintainer is listed
as librar...@haskell.org, but that is a closed mailing list.  Perhaps
Cabal should include a report-bugs-at field?)

John

GHCi, version 6.8.3: http://www.haskell.org/ghc/  :? for help
...
Prelude Text.PrettyPrint  putStrLn $ render $ hang (char '*') 4 (text hi $$ 
text there)
Loading package pretty-1.0.0.0 ... linking ... done.
*   hi
there

GHCi, version 6.10.1: http://www.haskell.org/ghc/  :? for help
...
Prelude Text.PrettyPrint  putStrLn $ render $ hang (char '*') 4 (text hi $$ 
text there)
Loading package pretty-1.0.1.0 ... linking ... done.
*
hi
there

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

[Haskell] ICFP09 Call for Papers

2008-12-15 Thread Matthew Fluet (ICFP Publicity Chair)

   Call for Papers
ICFP 2009: International Conference on Functional Programming
  Edinburgh, Scotland, 31 August - 2 September 2009
  http://www.cs.nott.ac.uk/~gmh/icfp09.html
   ** Submission deadline: 2 March 2009 **
 (submission deadline is earlier than usual)

ICFP 2009 seeks original papers on the art and science of functional
programming. Submissions are invited on all topics from principles to
practice, from foundations to features, from abstraction to
application.  The scope includes all languages that encourage
functional programming, including both purely applicative and
imperative languages, as well as languages with objects or
concurrency. Particular topics of interest include
  * Language Design: type systems; concurrency and distribution;
modules; components and composition; metaprogramming; relations to
object-oriented or logic programming; interoperability
  * Implementation: abstract machines; compilation; compile-time and
run-time optimization; memory management; multi-threading;
exploiting parallel hardware; interfaces to foreign functions,
services, components or low-level machine resources
  * Software-Development Techniques: algorithms and data structures;
design patterns; specification; verification; validation; proof
assistants; debugging; testing; tracing; profiling
  * Foundations: formal semantics; lambda calculus; rewriting; type
theory; monads; continuations; control; state; effects
  * Transformation and Analysis: abstract interpretation; partial
evaluation; program transformation; program calculation; program
proof
  * Applications and Domain-Specific Languages: symbolic computing;
formal-methods tools; artificial intelligence; systems
programming; distributed-systems and web programming; hardware
design; databases; XML processing; scientific and numerical
computing; graphical user interfaces; multimedia programming;
scripting; system administration; security; education
  * Functional Pearls: elegant, instructive, and fun essays on
functional programming

The conference also solicits Experience Reports, which are short
papers that provide evidence that functional programming really works
or describe obstacles that have kept it from working in a particular
application.


 What's different this year?
 ~~~

  * The conference dates and the submission deadline are about one
month earlier than usual.

  * Special 'Call for Experience Reports' page, suitable as a target
for posts on blogs and social networks to reach practitioners who
wouldn't normally think about submitting to a conference.  If you
have a blog, etc., please help by pointing your readers to:
http://web.cecs.pdx.edu/~apt/icfp09_cfer.html


   Instructions for authors
   

By Monday, 2 March 2009, 20:00 UTC, submit an abstract of at most 300
words and a full paper of at most 12 pages (4 pages for an Experience
Report), including bibliography and figures. The deadline will be
strictly enforced and papers exceeding the page limits will be
summarily rejected.  Authors have the option to attach supplementary
material to a submission, on the understanding that reviewers may
choose not to look at it.

A submission will be evaluated according to its relevance,
correctness, significance, originality, and clarity. It should explain
its contributions in both general and technical terms, clearly
identifying what has been accomplished, explaining why it is
significant, and comparing it with previous work. The technical
content should be accessible to a broad audience. Functional Pearls
and Experience Reports are separate categories of papers that need not
report original research results and must be marked as such at the
time of submission. Detailed guidelines on both categories are below.

Each submission must adhere to SIGPLAN's republication policy, as
explained on the web. Violation risks summary rejection of the
offending submission.

Proceedings will be published by ACM Press. Authors of accepted
submissions are expected to transfer the copyright to
ACM. Presentations will be videotaped and released online if the
presenter consents by signing an additional permission form at the
time of the presentation.  Released videos will be included along with
the conference proceedings in the ACM Digital Library and may also be
placed on a host such as YouTube or Google Video.

Formatting:
~~~
Submissions must be in PDF format printable in black and white on US
Letter sized paper and interpretable by Ghostscript. If this
requirement is a hardship, make contact with the program chair at
least one week before the deadline. ICFP proceedings are printed in
black and white. It is permissible to include color in a submission,
but you risk annoying

[Haskell] Missing Documentation

2008-12-15 Thread Ronald Legere

This may very well be a FAQ, but I tried to search the archives and could not 
find a post... 
Anyway, some documentation seems to be missing, which was there before I 
thought. For example:
http://www.haskell.org/ghc/docs/latest/html/libraries/haskell98/Random.html

Thanks, and sorry if this lowers the S/N

Ron



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

Re: [Haskell-cafe] Data.List.Split

2008-12-15 Thread Neil Mitchell

Hi

 I should have said that, on the other hand, with stream fusion enabled,
 (concat . map) outperforms (concatMap) :)

That can only be a bug in stream fusion - concatMap should always be prefered!

Thanks

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

Re: [Haskell-cafe] Time for a new logo?

2008-12-15 Thread Thomas Davie



On 15 Dec 2008, at 03:27, Don Stewart wrote:

Could you attach it to the web page,

   http://haskell.org/haskellwiki/Haskell_logos/New_logo_ideas


I've stuck a contender up there too.

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

Re: [Haskell-cafe] Problem with haddock 2.3.0 (again)

2008-12-15 Thread David Waern

2008/12/12 Sean Leather leat...@cs.uu.nl:
 On Fri, Dec 12, 2008 at 13:22, Thomas Schilling wrote:

 The fromJust error is a bug, of course, however, the underlying
 problem is a bit more difficult:

 Haddock doesn't generate any code, it only typechecks.  If the code
 uses Template Haskell, however, the typechecker will have to run
 Haskell code and potentially this code will have to come from a module
 of the same package.  If the code indeed comes from the same package,
 fixing the fromJust error will just lead to GHCi linker error, since
 Haddock didn't generate any code for these.

 Thanks for enlightening us, Thomas.

 Here are a couple of solutions and non-solutions:

 [...]


 Any other?

 What about the eventual (maybe never?) solution of collecting comments and
 types for Haddock after splicing in code? This is more long term, perhaps,
 but in the end ideal if it can be made to work.

This is what Haddock does, actually. It works when the spliced-in code
comes from another package (although this causes another problem,
currently), and we should make it work also for your case where the
code comes from the same package. With some improvements to the GHC
API (and Haddock), we should be able to fix this.

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

Re: [Haskell-cafe] Time for a new logo?

2008-12-15 Thread Eelco Lempsink


On 15 dec 2008, at 03:31, Derek Elkins wrote:

On Mon, 2008-12-15 at 02:57 +0100, Eelco Lempsink wrote:

I'm not a graphic designer, but that doesn't prevent me giving a try.

By the way, the font used (Kautiva) is not free.  You might recognize
it from Tupil's logo ;)


Someone would pay for that font?  It literally hurts my eyes.


Oh, I'm terribly sorry, I didn't mean to cause any harm.  To sooth  
your eyes, I created another variation, which also features a tagline  
that, in my opinion, captures more closely the gist of the impression  
Haskell makes on most programmers.


inline: haskell-logo-funny.png



This one is dedicated to you, Derek.  Good luck with your eyes.

--
Regards,

Eelco Lempsink



PGP.sig
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] Problem with haddock 2.3.0 (again)

2008-12-15 Thread David Waern

2008/12/12 Duncan Coutts duncan.cou...@worc.ox.ac.uk:
 Let's see what David thinks. If he thinks is possible to fix these kinds
 of things where haddock is not covering the whole GHC AST (at least to
 the degree where it can ignore bits it does not understand). If that's
 not realistic in the short term then we probably should introduce some
 haddock version macro so that people can workaround it.

Haddock already tries to filter out declarations that it can't (or
shouldn't) handle. I think that works well, although it's possible it
can be improved. If we find a case where more filtering is needed,
it's an easy fix to make.

In this case, we can't filter out the TH declarations (since the code
might then not compile),  but we can perhaps fix the root-cause in the
short-term (I'm not sure about that, but I hope so).

So let's wait with the flag until we find something that can't be
filtered out and for which we don't have a short-term fix?

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

[Haskell-cafe] Re: [Haskell] Re: Help : A problem with IO

2008-12-15 Thread wman

you probably got it pointed out in haskell-beginners, but in case not:

On Thu, Nov 27, 2008 at 7:10 PM, abdullah abdul Khadir 
abdullah.ak2...@gmail.com wrote:

 a) I need to put a do after else for more than one instruction (?)


No, the do thingy is a syntactic sugar for chaining warm, fuzzy (the
preffered wannabe-joke-term for the presumably scary term monads/monadic)
operations.

it allows you to write in classical imperative/sequential style instead of
chaining operations manually (using the  and = operators, which the do
notation translates into anyway). lookup some monad tutorials/docs.

you are right in that if there is only one operation, no transformation is
needed, so the do is unnecessary.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Time for a new logo?

2008-12-15 Thread Martin DeMello

Something incorporating λ∀ perhaps

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

Re: [Haskell-cafe] Multi-parameter type class woes

2008-12-15 Thread Thomas DuBuisson

2008/12/15 Mario Blazevic mblaze...@stilo.com

 Alexander Dunlap wrote:

 The problem is that y is not mentioned in the signature of wrapper.
 When you call wrapper x, there could be many different instances of
 Container x y with the same x, so GHC doesn't know which version to
 call.



I guess I see it now. However, if the explicit 'Container x y ='
 context couldn't fix the y to use for instantiation of Container x y, I
 don't see any way to fix it. And if there is no way to call wrapper in any
 context, the class declaration itself is illegal and GHC should have
 reported the error much sooner. Should I create a ticket?



Please do not create a ticket.  Such a typeclass is legitimate, but not
useful alone or with functional dependencies.  It is useful with Type
Families though, so celebrate!

Thomas

- START CODE 
{-# LANGUAGE TypeFamilies, MultiParamTypeClasses, FlexibleInstances #-}

import Data.Maybe

class Container x where
 type Contains x
 wrapper :: x - Bool
 unwrap :: x - Contains x
 rewrap :: Contains x - x

liftWrap :: Container x = (Contains x - Contains x) - x - x
liftWrap f x = (if wrapper x then rewrap . f . unwrap else id) x

instance Container (Maybe x) where
 type Contains (Maybe x) = x
 wrapper = isJust
 unwrap = fromJust
 rewrap = Just

main = print (liftWrap (succ :: Int - Int) (Just 1 :: Maybe Int))
-
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Multi-parameter type class woes

2008-12-15 Thread Thomas DuBuisson

On Mon, Dec 15, 2008 at 2:15 PM, Thomas DuBuisson 
thomas.dubuis...@gmail.com wrote:

 2008/12/15 Mario Blazevic mblaze...@stilo.com

 Alexander Dunlap wrote:

 The problem is that y is not mentioned in the signature of wrapper.
 When you call wrapper x, there could be many different instances of
 Container x y with the same x, so GHC doesn't know which version to
 call.



I guess I see it now. However, if the explicit 'Container x y ='
 context couldn't fix the y to use for instantiation of Container x y, I
 don't see any way to fix it. And if there is no way to call wrapper in any
 context, the class declaration itself is illegal and GHC should have
 reported the error much sooner. Should I create a ticket?



 Please do not create a ticket.  Such a typeclass is legitimate, but not
 useful alone or with functional dependencies.  It is useful with Type
 Families though, so celebrate!

 Thomas


Ok, now I get to laugh at myself.  Caught up in the type family fun, I
didn't even notice I obliterated the MPTC issue that started the whole
discussion.  Slowing down to think, I can't find an example where the
original MPTC is any good and it should thus receive a compile time error.
Perhaps someone will come along and give a legitimate example.

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

[Haskell-cafe] Re: Threads not running under GHC 6.10?


Gwern Branwen wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

So, the Hint library was recently updated and I was editing Mueval to
run with (i386) 6.10, when I discovered that for some reason, DoS'ing
expressions were succeeding in rendering my machine unusable.
Eventually, I discovered that my watchdog thread didn't seem to be
running. But with +RTS -N2 -RTS all my tests did pass!

Here's a simple example of what I mean; the following is basically a
very lightly adapted version of the actual Mueval code:

- 
import Control.Concurrent   (forkIO, killThread, myThreadId,
threadDelay, throwTo, yield, ThreadId)
import System.Posix.Signals (sigXCPU, installHandler, Handler(CatchOnce))
import Control.OldException (Exception(ErrorCall))

main :: IO ()
main = do tid  ThreadId - IO ()
watchDog tout tid = do installHandler sigXCPU
  (CatchOnce
   $ throwTo tid $ ErrorCall
Time limit exceeded.) Nothing
   forkIO $ do threadDelay (tout * 10)
   -- Time's up. It's a good day to die.
   throwTo tid (ErrorCall Time limit exceeded)
   yield -- give the other thread a chance
   killThread tid -- Die now, srsly.
   error Time expired
   return () -- Never reached. Either we error out in
 -- watchDog, or the evaluation thread finishes.


This particular example illustrates a bug in 6.10.1 that we've since fixed:

  http://hackage.haskell.org/trac/ghc/ticket/2783

However in general you can still write expressions that don't allocate 
anything (e.g. nfib 1000), and your watchdog thread won't get a chance to 
run unless there's a spare CPU available (+RTS -N2).


Cheers,
Simon

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

Re: [Haskell-cafe] Time for a new logo?

2008-12-15 Thread Henning Thielemann



On Sun, 14 Dec 2008, Don Stewart wrote:


I noticed a new haskell logo idea on a tshirt today,

   
http://image.spreadshirt.net/image-server/image/configuration/13215127/producttypecolor/2/type/png

Simple, clean and *pure*.

Instead of the we got lots going on of the current logo.


Call me conservative, but I like the current logo more than the new 
suggestions. Why isn't it shown big on the welcome page of haskell.org?

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

Re: [Haskell-cafe] Time for a new logo?

2008-12-15 Thread Gianfranco Alongi

Looks, good, actually among the top of the ones I like,
should we not have some kind of voting mechanism for selecting a logo?
And also some kind of last date for when entries are accepted..

Of course this requires a call for logos and so forth.

2008/12/15 Jeff Heard jefferson.r.he...@gmail.com:
 My entry...

 2008/12/15 Martin DeMello martindeme...@gmail.com:
 Something incorporating λ∀ perhaps

 martin
 ___
 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





-- 
Patience is the last resort for those unable to take action
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Time for a new logo?

2008-12-15 Thread Thomas Schilling

So far this one is still the best, although the kerning between the s
and the k seems off, so that would need fixing first.

In terms of slogan purely functional, lazy with class, or lazy.
pure. functional. look ok.  The rest, not so much.

2008/12/14 Don Stewart d...@galois.com:
 I noticed a new haskell logo idea on a tshirt today,


 http://image.spreadshirt.net/image-server/image/configuration/13215127/producttypecolor/2/type/png

 Simple, clean and *pure*.

 Instead of the we got lots going on of the current logo.

 Any graphic designers want to try some variations on this theme of
 purity?

 A new year, and a new mature logo...

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




-- 
Push the envelope.  Watch it bend.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Multi-parameter type class woes

2008-12-15 Thread Mario Blazevic


Alexander Dunlap wrote:

On Sun, Dec 14, 2008 at 8:10 PM, Mario Blažević mblaze...@stilo.com wrote:

I'll take a swing at this one:

instance Container (Maybe x) [x] where
wrapper = isNothing
. . .

That isn't a sensible definition of 'wrapper', but I believe without
trying to compile it is completely legal.  Which wrapper do you use?

You /don't/ have a different matching Container instance, but without the
functional dependency you /might/, and ghc barfs.


   But liftWrap doesn't require any particular instance, it's a
generic function accepting any pair of types for which there is
an instance of Container. Instance selection (as I understand it)
shouldn't come into play until one applies liftWrap to a
particular type, and indeed it does cause problems there: note
the type annotations on the last line. That part I understand
and accept, or at least have learned to live with.


The problem is that y is not mentioned in the signature of wrapper.
When you call wrapper x, there could be many different instances of
Container x y with the same x, so GHC doesn't know which version to
call.



	I guess I see it now. However, if the explicit 'Container x y =' 
context couldn't fix the y to use for instantiation of Container x y, I 
don't see any way to fix it. And if there is no way to call wrapper in 
any context, the class declaration itself is illegal and GHC should have 
reported the error much sooner. Should I create a ticket?





You can fix this problem either by adding a functional
dependency or by splitting wrapper out into its own class (Wrapper x,
e.g.) so all of the type variables in the class head are mentioned in
its type and the instance can be determined by the call.

Thanks for asking this question, by the way. I had known about this
issue but had never really realized why it happened. Now that I have
thought about it, I understand it too. :)

Hope that helps,
Alex



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

Re: [Haskell-cafe] Time for a new logo?

2008-12-15 Thread Álvaro Vilanova Vidal

One more concept.


attachment: haskell_infinitylambda_logo.svgattachment: haskell_infinitylambda.svgattachment: haskell_infinitylambda.png___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Time for a new logo?

And anyone who does a version, place put it on the wiki.
It'll be lost if you only post to the list.

I propose we gather submissions and vote on the best for a new logo in
2009.

-- Don

nominolo:
 So far this one is still the best, although the kerning between the s
 and the k seems off, so that would need fixing first.
 
 In terms of slogan purely functional, lazy with class, or lazy.
 pure. functional. look ok.  The rest, not so much.
 
 2008/12/14 Don Stewart d...@galois.com:
  I noticed a new haskell logo idea on a tshirt today,
 
 
  http://image.spreadshirt.net/image-server/image/configuration/13215127/producttypecolor/2/type/png
 
  Simple, clean and *pure*.
 
  Instead of the we got lots going on of the current logo.
 
  Any graphic designers want to try some variations on this theme of
  purity?
 
  A new year, and a new mature logo...
 
  -- Don
  ___
  Haskell-Cafe mailing list
  Haskell-Cafe@haskell.org
  http://www.haskell.org/mailman/listinfo/haskell-cafe
 
 
 
 
 -- 
 Push the envelope.  Watch it bend.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Time for a new logo?

2008-12-15 Thread Thomas Davie



On 15 Dec 2008, at 12:43, Henning Thielemann wrote:



On Sun, 14 Dec 2008, Don Stewart wrote:


I noticed a new haskell logo idea on a tshirt today,

  
http://image.spreadshirt.net/image-server/image/configuration/13215127/producttypecolor/2/type/png

Simple, clean and *pure*.

Instead of the we got lots going on of the current logo.


Call me conservative, but I like the current logo more than the new  
suggestions. Why isn't it shown big on the welcome page of  
haskell.org?


Are you referring to this logo?
inline: Haskell.png


In which case, it is shown on Haskell.org, unless there's another logo  
that I don't know about?


Personally, this logo I find cluttered, and complicated, which I  
suspect conveys something to people thinking about using Haskell.


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

Re: [Haskell-cafe] Missing comment highlighting in vim syntax script

2008-12-15 Thread Arthur van Leeuwen



On 14 dec 2008, at 19:04, Claus Reinke wrote:


The Haskell syntax script for vim mentions this mailing list as the
maintainer. Perhaps one of you could fix this bug.
Comments on the same line as import declarations don't get  
highlighted:


I don't know how this list-as-maintainer idea is going to work,
but the fix seems straightforward: find the line in $VIMRUNTIME/ 
syntax/haskell.vim that says


  syn match hsImport  \import\.*he=s+6 contains=hsImportMod

and change it to

  syn match hsImport  \import\.*he=s+6  
contains=hsImportMod,hsLineComment,hsBlockComment


See :help syn-contains.


Good fix. Have also modified my copy and forwarded the patch to
the vim maintainer.

With kind regards, Arthur van Leeuwen.

--

Arthur van Leeuwen
arthu...@cs.uu.nl



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

Re: [Haskell-cafe] Time for a new logo? - Haskell logo as a stamp!

2008-12-15 Thread Henning Thielemann



On Mon, 15 Dec 2008, Don Stewart wrote:


And anyone who does a version, place put it on the wiki.
It'll be lost if you only post to the list.

I propose we gather submissions and vote on the best for a new logo in
2009.


Whatever logo someone prefers: I have written a program using HPDF which 
creates stamps for the German post (see http://www.internetmarke.de/) with 
custom images:

  http://code.haskell.org/~thielema/internetmarke/
 It needs a bit generalization, though, and will then be uploaded to 
Hackage, of course. So a dedicated Haskell stamp is close to German 
Haskell users!

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

[Haskell-cafe] ICFP09 Call for Papers

2008-12-15 Thread Matthew Fluet (ICFP Publicity Chair)

   Call for Papers
ICFP 2009: International Conference on Functional Programming
  Edinburgh, Scotland, 31 August - 2 September 2009
  http://www.cs.nott.ac.uk/~gmh/icfp09.html
   ** Submission deadline: 2 March 2009 **
 (submission deadline is earlier than usual)

ICFP 2009 seeks original papers on the art and science of functional
programming. Submissions are invited on all topics from principles to
practice, from foundations to features, from abstraction to
application.  The scope includes all languages that encourage
functional programming, including both purely applicative and
imperative languages, as well as languages with objects or
concurrency. Particular topics of interest include
  * Language Design: type systems; concurrency and distribution;
modules; components and composition; metaprogramming; relations to
object-oriented or logic programming; interoperability
  * Implementation: abstract machines; compilation; compile-time and
run-time optimization; memory management; multi-threading;
exploiting parallel hardware; interfaces to foreign functions,
services, components or low-level machine resources
  * Software-Development Techniques: algorithms and data structures;
design patterns; specification; verification; validation; proof
assistants; debugging; testing; tracing; profiling
  * Foundations: formal semantics; lambda calculus; rewriting; type
theory; monads; continuations; control; state; effects
  * Transformation and Analysis: abstract interpretation; partial
evaluation; program transformation; program calculation; program
proof
  * Applications and Domain-Specific Languages: symbolic computing;
formal-methods tools; artificial intelligence; systems
programming; distributed-systems and web programming; hardware
design; databases; XML processing; scientific and numerical
computing; graphical user interfaces; multimedia programming;
scripting; system administration; security; education
  * Functional Pearls: elegant, instructive, and fun essays on
functional programming

The conference also solicits Experience Reports, which are short
papers that provide evidence that functional programming really works
or describe obstacles that have kept it from working in a particular
application.


 What's different this year?
 ~~~

  * The conference dates and the submission deadline are about one
month earlier than usual.

  * Special 'Call for Experience Reports' page, suitable as a target
for posts on blogs and social networks to reach practitioners who
wouldn't normally think about submitting to a conference.  If you
have a blog, etc., please help by pointing your readers to:
http://web.cecs.pdx.edu/~apt/icfp09_cfer.html


   Instructions for authors
   

By Monday, 2 March 2009, 20:00 UTC, submit an abstract of at most 300
words and a full paper of at most 12 pages (4 pages for an Experience
Report), including bibliography and figures. The deadline will be
strictly enforced and papers exceeding the page limits will be
summarily rejected.  Authors have the option to attach supplementary
material to a submission, on the understanding that reviewers may
choose not to look at it.

A submission will be evaluated according to its relevance,
correctness, significance, originality, and clarity. It should explain
its contributions in both general and technical terms, clearly
identifying what has been accomplished, explaining why it is
significant, and comparing it with previous work. The technical
content should be accessible to a broad audience. Functional Pearls
and Experience Reports are separate categories of papers that need not
report original research results and must be marked as such at the
time of submission. Detailed guidelines on both categories are below.

Each submission must adhere to SIGPLAN's republication policy, as
explained on the web. Violation risks summary rejection of the
offending submission.

Proceedings will be published by ACM Press. Authors of accepted
submissions are expected to transfer the copyright to
ACM. Presentations will be videotaped and released online if the
presenter consents by signing an additional permission form at the
time of the presentation.  Released videos will be included along with
the conference proceedings in the ACM Digital Library and may also be
placed on a host such as YouTube or Google Video.

Formatting:
~~~
Submissions must be in PDF format printable in black and white on US
Letter sized paper and interpretable by Ghostscript. If this
requirement is a hardship, make contact with the program chair at
least one week before the deadline. ICFP proceedings are printed in
black and white. It is permissible to include color in a submission,
but you risk annoying

Re: [Haskell-cafe] Time for a new logo?

2008-12-15 Thread Brettschneider, Matthias

If there is someone interested in playing around with the logo Don posted, 
I made a gimp-version out of it.

http://frosch03.de/haskell/Haskell.xcf
http://frosch03.de/haskell/Haskell.png

-- Matthias

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

Re: [Haskell-cafe] Time for a new logo?

Could you  upload it to the logo contest page:

http://haskell.org/haskellwiki/Haskell_logos/New_logo_ideas


jefferson.r.heard:
 My entry...
 
 2008/12/15 Martin DeMello martindeme...@gmail.com:
  Something incorporating λ∀ perhaps
 
  martin
  ___
  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 mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] haskell compiler never comes back

Haskellians,

The simple-minded and smallish code sample at this
linkhttp://paste.pocoo.org/show/95503/causes the compiler to go off
into never-never land. Any clues would be
greatly appreciated.

Best wishes,

--greg

-- 
L.G. Meredith
Managing Partner
Biosimilarity LLC
806 55th St NE
Seattle, WA 98105

+1 206.650.3740

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

Re: [Haskell-cafe] Data.List.Split

On Mon, 2008-12-15 at 08:40 +, Neil Mitchell wrote:
 That can only be a bug in stream fusion - concatMap should always be prefered!

Yes, but it is unclear from the article whether the concatMap (w/ stream
fusion enabled) is Data.List.Stream's concatMap or the Prelude's
concatMap. It's only a bug in the former case :)

- George


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] Time for a new logo?

2008-12-15 Thread Andrew Coppin

Don Stewart wrote:
I noticed a new haskell logo idea on a tshirt today,

http://image.spreadshirt.net/image-server/image/configuration/13215127/producttypecolor/2/type/png

Simple, clean and *pure*.

Instead of the we got lots going on of the current logo.

Any graphic designers want to try some variations on this theme of
purity?

A new year, and a new mature logo...

Well overdue, IMHO.

I showed the current logo to Mr C++ (who, obviously, is slightly
biased). To him, apparently, the current logo says Haskell is all about
arcane and obscure mathematical constructs. In fact, we think that
complicated mathematics is so good that we stuffed our logo full of it.
If you don't like hard math, don't even bother trying to learn this
language.

Obviously, that's a rather negative image to be projecting. And
obviously, his opinion is biased. To me, the logo just looks a) rather
cluttered, and b) home-made. It doesn't have that professional glitter
to it. (I have no idea how to fix that though - maybe ask a professional??)

I see lots of people posting various logos, but they all seem to consist
essentially of a lambda and the word Haskell. I guess it depends on
what you want from a logo. Is our logo going to be just a lambda
symbol in a specific typeface with specific colours? Or do we want
something more particular? (Looking at what other languages have... well
Ruby has a gemstone. Duh. And Python has two snakes nicely stylised.
Oh well!) But yeah, certainly I think having a neat T-shirt to wear
would be fun! (Note that the lambda was the symbol for the LGBT folks
though!)

(Actually, just noticing... Ruby's front page says Hello World is
trivial - here it is! We can do that too, eh?)

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

[Haskell-cafe] Re: haskell compiler never comes back

Haskellians,

An even simpler version http://paste.pocoo.org/show/95518/ that reveals
the issue. i'm astounded that the compiler literally just hangs.

Best wishes,

--greg

On Mon, Dec 15, 2008 at 12:23 PM, Greg Meredith 
lgreg.mered...@biosimilarity.com wrote:

 Haskellians,

 The simple-minded and smallish code sample at this 
 linkhttp://paste.pocoo.org/show/95503/causes the compiler to go off into 
 never-never land. Any clues would be
 greatly appreciated.

 Best wishes,

 --greg

 --
 L.G. Meredith
 Managing Partner
 Biosimilarity LLC
 806 55th St NE
 Seattle, WA 98105

 +1 206.650.3740

 http://biosimilarity.blogspot.com




-- 
L.G. Meredith
Managing Partner
Biosimilarity LLC
806 55th St NE
Seattle, WA 98105

+1 206.650.3740

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

Re: [Haskell-cafe] Re: haskell compiler never comes back

George,

Thanks for the response. If i take out the AllowUndecidableInstances i get
no complaints and the compiler hangs. See
thishttp://paste.pocoo.org/show/95523/.
Thus, i can find no observable difference for this flag in this particular
code sample.

Best wishes,

--greg

On Mon, Dec 15, 2008 at 2:34 PM, George Pollard por...@porg.es wrote:

 This is precisely what AllowUndecidableInstances allows; the type
 checking becomes possibly non-terminating. It should *eventually*
 terminate because the stack depth is restricted.

 - George




-- 
L.G. Meredith
Managing Partner
Biosimilarity LLC
806 55th St NE
Seattle, WA 98105

+1 206.650.3740

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

Re: [Haskell-cafe] Re: haskell compiler never comes back

2008-12-15 Thread Daniel Fischer

Am Montag, 15. Dezember 2008 23:16 schrieb Greg Meredith:
 Haskellians,

 An even simpler version http://paste.pocoo.org/show/95518/ that reveals
 the issue. i'm astounded that the compiler literally just hangs.

 Best wishes,

 --greg

 On Mon, Dec 15, 2008 at 12:23 PM, Greg Meredith 

 lgreg.mered...@biosimilarity.com wrote:
  Haskellians,
 
  The simple-minded and smallish code sample at this
  linkhttp://paste.pocoo.org/show/95503/causes the compiler to go off
  into never-never land. Any clues would be greatly appreciated.
 
  Best wishes,
 
  --greg

I can't confirm it, with 6.8.3:

$ ghc -O2 --make Monoidal.hs
[1 of 1] Compiling Monoidal ( Monoidal.hs, Monoidal.o )

Monoidal.hs:110:11:
Couldn't match expected type `i1'
   against inferred type `Isomorpism (HFTensorExpr a i) a'
  `i1' is a rigid type variable bound by
   the instance declaration at Monoidal.hs:103:42
In the expression: (PutIn (\ a - (HFTLVal a)))
In the third argument of `HFTExpr', namely
`[(PutIn (\ a - (HFTLVal a)))]'
In the expression:
(HFTExpr
   (HFTLVal a)
   (HFTRVal b)
   [(PutIn (\ a - (HFTLVal a)))]
   [(PutIn (\ b - (HFTRVal b)))])
$

and the earlier version:

$ ghc -O2 --make Monoidal2.hs
[1 of 1] Compiling Monoidal2( Monoidal2.hs, Monoidal2.o )

Monoidal2.hs:105:18:
Couldn't match expected type `HFTensorExpr a i'
   against inferred type `[i1] - [i1] - HFTensorExpr a i1'
In the expression: HFTExpr (HFTLVal a) (HFTRVal b)
In the definition of `tMult':
a tMult b = HFTExpr (HFTLVal a) (HFTRVal b)
In the definition for method `tMult'

Monoidal2.hs:122:10:
Couldn't match expected type `[]' against inferred type `++ msa'
  Expected type: [i]
  Inferred type: ++ msa msb
In the third argument of `HFTExpr', namely
`((Shuffle
 (\ (HFTExpr (HFTExpr u v msu msv) w msuv msw)
  - (tAssoc (HFTExpr (HFTExpr u v msu msv) w msuv msw ::
msa ++ msb)'
In the expression:
(HFTExpr
   (HFTExpr a b msa msb)
   c
   ((Shuffle
   (\ (HFTExpr (HFTExpr u v msu msv) w msuv msw)
- (tAssoc (HFTExpr (HFTExpr u v msu msv) w msuv msw 
::
  msa ++ msb)
   msc)

Monoidal2.hs:139:10:
Couldn't match expected type `[]' against inferred type `++ msl'
  Expected type: [i]
  Inferred type: ++ msl msr
In the third argument of `HFTExpr', namely
`((Shuffle
 (\ (HFTExpr (HFTExpr a b msa msb) c msab msc)
  - (tAssoc (HFTExpr (HFTExpr a b msa msb) c msab msc ::
msl ++ msr)'
In the expression:
(HFTExpr
   (HFTExpr l r msl msr)
   (HFTRVal b)
   ((Shuffle
   (\ (HFTExpr (HFTExpr a b msa msb) c msab msc)
- (tAssoc (HFTExpr (HFTExpr a b msa msb) c msab msc 
::
  msl ++ msr)
   [(PutIn (\ b - (HFTRVal b)))])

Monoidal2.hs:150:11:
Couldn't match expected type `i1'
   against inferred type `Isomorpism (HFTensorExpr a i) a'
  `i1' is a rigid type variable bound by
   the instance declaration at Monoidal2.hs:103:42
In the expression: (PutIn (\ a - (HFTRVal a)))
In the third argument of `HFTExpr', namely
`[(PutIn (\ a - (HFTRVal a)))]'
In the expression:
(HFTExpr
   (HFTLVal a)
   (HFTRVal b)
   [(PutIn (\ a - (HFTRVal a)))]
   [(PutIn (\ b - (HFTRVal b)))])
$

No hang, which compiler version did you use?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: haskell compiler never comes back

Daniel,

Thanks. i'm using

GHCi, version 6.8.2: http://www.haskell.org/ghc/  :? for help
Loading package base ... linking ... done.
Prelude :l monoidal.hs
[1 of 1] Compiling Monoidal ( monoidal.hs, interpreted )
  C-c C-cInterrupted.
 :q

Best wishes,

--greg

On Mon, Dec 15, 2008 at 2:50 PM, Daniel Fischer daniel.is.fisc...@web.dewrote:

 Am Montag, 15. Dezember 2008 23:16 schrieb Greg Meredith:
  Haskellians,
 
  An even simpler version http://paste.pocoo.org/show/95518/ that
 reveals
  the issue. i'm astounded that the compiler literally just hangs.
 
  Best wishes,
 
  --greg
 
  On Mon, Dec 15, 2008 at 12:23 PM, Greg Meredith 
 
  lgreg.mered...@biosimilarity.com wrote:
   Haskellians,
  
   The simple-minded and smallish code sample at this
   linkhttp://paste.pocoo.org/show/95503/causes the compiler to go off
   into never-never land. Any clues would be greatly appreciated.
  
   Best wishes,
  
   --greg

 I can't confirm it, with 6.8.3:

 $ ghc -O2 --make Monoidal.hs
 [1 of 1] Compiling Monoidal ( Monoidal.hs, Monoidal.o )

 Monoidal.hs:110:11:
Couldn't match expected type `i1'
   against inferred type `Isomorpism (HFTensorExpr a i) a'
  `i1' is a rigid type variable bound by
   the instance declaration at Monoidal.hs:103:42
In the expression: (PutIn (\ a - (HFTLVal a)))
In the third argument of `HFTExpr', namely
`[(PutIn (\ a - (HFTLVal a)))]'
In the expression:
(HFTExpr
   (HFTLVal a)
   (HFTRVal b)
   [(PutIn (\ a - (HFTLVal a)))]
   [(PutIn (\ b - (HFTRVal b)))])
 $

 and the earlier version:

 $ ghc -O2 --make Monoidal2.hs
 [1 of 1] Compiling Monoidal2( Monoidal2.hs, Monoidal2.o )

 Monoidal2.hs:105:18:
Couldn't match expected type `HFTensorExpr a i'
   against inferred type `[i1] - [i1] - HFTensorExpr a i1'
In the expression: HFTExpr (HFTLVal a) (HFTRVal b)
In the definition of `tMult':
a tMult b = HFTExpr (HFTLVal a) (HFTRVal b)
In the definition for method `tMult'

 Monoidal2.hs:122:10:
Couldn't match expected type `[]' against inferred type `++ msa'
  Expected type: [i]
  Inferred type: ++ msa msb
In the third argument of `HFTExpr', namely
`((Shuffle
 (\ (HFTExpr (HFTExpr u v msu msv) w msuv msw)
  - (tAssoc (HFTExpr (HFTExpr u v msu msv) w msuv msw
 ::
msa ++ msb)'
In the expression:
(HFTExpr
   (HFTExpr a b msa msb)
   c
   ((Shuffle
   (\ (HFTExpr (HFTExpr u v msu msv) w msuv msw)
- (tAssoc (HFTExpr (HFTExpr u v msu msv) w msuv msw
 ::
  msa ++ msb)
   msc)

 Monoidal2.hs:139:10:
Couldn't match expected type `[]' against inferred type `++ msl'
  Expected type: [i]
  Inferred type: ++ msl msr
In the third argument of `HFTExpr', namely
`((Shuffle
 (\ (HFTExpr (HFTExpr a b msa msb) c msab msc)
  - (tAssoc (HFTExpr (HFTExpr a b msa msb) c msab msc
 ::
msl ++ msr)'
In the expression:
(HFTExpr
   (HFTExpr l r msl msr)
   (HFTRVal b)
   ((Shuffle
   (\ (HFTExpr (HFTExpr a b msa msb) c msab msc)
- (tAssoc (HFTExpr (HFTExpr a b msa msb) c msab msc
 ::
  msl ++ msr)
   [(PutIn (\ b - (HFTRVal b)))])

 Monoidal2.hs:150:11:
Couldn't match expected type `i1'
   against inferred type `Isomorpism (HFTensorExpr a i) a'
  `i1' is a rigid type variable bound by
   the instance declaration at Monoidal2.hs:103:42
In the expression: (PutIn (\ a - (HFTRVal a)))
In the third argument of `HFTExpr', namely
`[(PutIn (\ a - (HFTRVal a)))]'
In the expression:
(HFTExpr
   (HFTLVal a)
   (HFTRVal b)
   [(PutIn (\ a - (HFTRVal a)))]
   [(PutIn (\ b - (HFTRVal b)))])
 $

 No hang, which compiler version did you use?




-- 
L.G. Meredith
Managing Partner
Biosimilarity LLC
806 55th St NE
Seattle, WA 98105

+1 206.650.3740

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

Re: [Haskell-cafe] Re: haskell compiler never comes back

Daniel,

BTW, if i comment out the version of PutIn that calls HF{L,R}Val and put in
the unit, instead, i see the complaint you're seeing. i'll upgrade ghc.

Best wishes,

--greg

On Mon, Dec 15, 2008 at 2:49 PM, Greg Meredith 
lgreg.mered...@biosimilarity.com wrote:

 Daniel,

 Thanks. i'm using

 GHCi, version 6.8.2: http://www.haskell.org/ghc/  :? for help
 Loading package base ... linking ... done.
 Prelude :l monoidal.hs
 [1 of 1] Compiling Monoidal ( monoidal.hs, interpreted )
   C-c C-cInterrupted.
  :q

 Best wishes,

 --greg


 On Mon, Dec 15, 2008 at 2:50 PM, Daniel Fischer 
 daniel.is.fisc...@web.dewrote:

 Am Montag, 15. Dezember 2008 23:16 schrieb Greg Meredith:
  Haskellians,
 
  An even simpler version http://paste.pocoo.org/show/95518/ that
 reveals
  the issue. i'm astounded that the compiler literally just hangs.
 
  Best wishes,
 
  --greg
 
  On Mon, Dec 15, 2008 at 12:23 PM, Greg Meredith 
 
  lgreg.mered...@biosimilarity.com wrote:
   Haskellians,
  
   The simple-minded and smallish code sample at this
   linkhttp://paste.pocoo.org/show/95503/causes the compiler to go off
   into never-never land. Any clues would be greatly appreciated.
  
   Best wishes,
  
   --greg

 I can't confirm it, with 6.8.3:

 $ ghc -O2 --make Monoidal.hs
 [1 of 1] Compiling Monoidal ( Monoidal.hs, Monoidal.o )

 Monoidal.hs:110:11:
Couldn't match expected type `i1'
   against inferred type `Isomorpism (HFTensorExpr a i) a'
  `i1' is a rigid type variable bound by
   the instance declaration at Monoidal.hs:103:42
In the expression: (PutIn (\ a - (HFTLVal a)))
In the third argument of `HFTExpr', namely
`[(PutIn (\ a - (HFTLVal a)))]'
In the expression:
(HFTExpr
   (HFTLVal a)
   (HFTRVal b)
   [(PutIn (\ a - (HFTLVal a)))]
   [(PutIn (\ b - (HFTRVal b)))])
 $

 and the earlier version:

 $ ghc -O2 --make Monoidal2.hs
 [1 of 1] Compiling Monoidal2( Monoidal2.hs, Monoidal2.o )

 Monoidal2.hs:105:18:
Couldn't match expected type `HFTensorExpr a i'
   against inferred type `[i1] - [i1] - HFTensorExpr a i1'
In the expression: HFTExpr (HFTLVal a) (HFTRVal b)
In the definition of `tMult':
a tMult b = HFTExpr (HFTLVal a) (HFTRVal b)
In the definition for method `tMult'

 Monoidal2.hs:122:10:
Couldn't match expected type `[]' against inferred type `++ msa'
  Expected type: [i]
  Inferred type: ++ msa msb
In the third argument of `HFTExpr', namely
`((Shuffle
 (\ (HFTExpr (HFTExpr u v msu msv) w msuv msw)
  - (tAssoc (HFTExpr (HFTExpr u v msu msv) w msuv msw
 ::
msa ++ msb)'
In the expression:
(HFTExpr
   (HFTExpr a b msa msb)
   c
   ((Shuffle
   (\ (HFTExpr (HFTExpr u v msu msv) w msuv msw)
- (tAssoc (HFTExpr (HFTExpr u v msu msv) w msuv
 msw
 ::
  msa ++ msb)
   msc)

 Monoidal2.hs:139:10:
Couldn't match expected type `[]' against inferred type `++ msl'
  Expected type: [i]
  Inferred type: ++ msl msr
In the third argument of `HFTExpr', namely
`((Shuffle
 (\ (HFTExpr (HFTExpr a b msa msb) c msab msc)
  - (tAssoc (HFTExpr (HFTExpr a b msa msb) c msab msc
 ::
msl ++ msr)'
In the expression:
(HFTExpr
   (HFTExpr l r msl msr)
   (HFTRVal b)
   ((Shuffle
   (\ (HFTExpr (HFTExpr a b msa msb) c msab msc)
- (tAssoc (HFTExpr (HFTExpr a b msa msb) c msab
 msc
 ::
  msl ++ msr)
   [(PutIn (\ b - (HFTRVal b)))])

 Monoidal2.hs:150:11:
Couldn't match expected type `i1'
   against inferred type `Isomorpism (HFTensorExpr a i) a'
  `i1' is a rigid type variable bound by
   the instance declaration at Monoidal2.hs:103:42
In the expression: (PutIn (\ a - (HFTRVal a)))
In the third argument of `HFTExpr', namely
`[(PutIn (\ a - (HFTRVal a)))]'
In the expression:
(HFTExpr
   (HFTLVal a)
   (HFTRVal b)
   [(PutIn (\ a - (HFTRVal a)))]
   [(PutIn (\ b - (HFTRVal b)))])
 $

 No hang, which compiler version did you use?




 --
 L.G. Meredith
 Managing Partner
 Biosimilarity LLC
 806 55th St NE
 Seattle, WA 98105

 +1 206.650.3740

 http://biosimilarity.blogspot.com




-- 
L.G. Meredith
Managing Partner
Biosimilarity LLC
806 55th St NE
Seattle, WA 98105

+1 206.650.3740

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

RE: [Haskell-cafe] Time for a new logo?

2008-12-15 Thread Michael Giagnocavo

Don Stewart wrote:
 I noticed a new haskell logo idea on a tshirt today,

 
 http://image.spreadshirt.net/image-server/image/configuration/13215127/producttypecolor/2/type/png

 Simple, clean and *pure*.


While lambda in a circle is quite powerful, it's also quite similar to the 
logo for the rather popular game Half-Life (especially if orange is used). 
I'm not sure if this is relevant.
http://images.google.com/images?q=half+life+logo

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

Re: [Haskell-cafe] Time for a new logo?

mgg:
 Don Stewart wrote:
  I noticed a new haskell logo idea on a tshirt today,
 
  
  http://image.spreadshirt.net/image-server/image/configuration/13215127/producttypecolor/2/type/png
 
  Simple, clean and *pure*.
 
 
 While lambda in a circle is quite powerful, it's also quite similar to the 
 logo for the rather popular game Half-Life (especially if orange is used). 
 I'm not sure if this is relevant.
 http://images.google.com/images?q=half+life+logo
 

Haskell and Scheme have been using lambda in a circle for 20+ years, also...

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

Re: [Haskell-cafe] Re: haskell compiler never comes back

2008-12-15 Thread Daniel Fischer

Am Montag, 15. Dezember 2008 23:49 schrieb Greg Meredith:
 Daniel,

 Thanks. i'm using

 GHCi, version 6.8.2: http://www.haskell.org/ghc/  :? for help

Indeed, 6.8.2 hangs here, too.

 Loading package base ... linking ... done.
 Prelude :l monoidal.hs
 [1 of 1] Compiling Monoidal ( monoidal.hs, interpreted )
   C-c C-cInterrupted.

  :q

 Best wishes,

 --greg


Cheers,
Daniel

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

[Haskell-cafe] How to think about this? (profiling)

2008-12-15 Thread Magnus Therning

This behaviour by Haskell seems to go against my intuition, I'm sure I
just need an update of my intuition ;-)

I wanted to improve on the following little example code:

  foo :: Int - Int
  foo 0 = 0
  foo 1 = 1
  foo 2 = 2
  foo n = foo (n - 1) + foo (n - 2) + foo (n - 3)

This is obviously going to run into problems for large values of `n` so
I introduced a state to keep intermediate results in:

  foo :: Int - State (UArray Int Int) Int
  foo 0 = return 0
  foo 1 = return 1
  foo 2 = return 2
  foo n = do
  c - get
  if (c ! n) /= -1
  then return $ c ! n
  else do
  r - liftM3 (\ a b c - a + b + c)
  (foo $ n - 1) (foo $ n - 2) (foo $ n - 3)
  modify (\ s - s // [(n, r)])
  return r

Then I added a convenience function and called it like this:

  createArray :: Int - UArray Int Int
  createArray n = array (0, n) (zip [0..n] (repeat (-1)))

  main = do
  (n:_)  - liftM (map read) getArgs
  print $ evalState (foo n) (createArray n)

Then I thought that this still looks pretty deeply recursive, but if I
call the function for increasing values of `n` then I'll simply build up
the state, sort of like doing a for-loop in an imperative language.  I
could then end it with a call to `foo n` and be done.  I replaced `main`
by:

  main = do
  (n:_)  - liftM (map read) getArgs
  print $ evalState (mapM_ foo [0..n]  foo n) (createArray n)

Then I started profiling and found out that the latter version both uses
more memory and makes far more calls to `foo`.  That's not what I
expected!  (I suspect there's something about laziness I'm missing.)

Anyway, I ran it with `n=35` and got

 foo n : 202,048 bytes , foo entries 100
 mapM_ foo [0..n]  foo n : 236,312 , foo entries 135 + 1

How should I think about this in order to predict this behaviour in the
future?

/M

-- 
Magnus Therning (OpenPGP: 0xAB4DFBA4)
magnus＠therning．org Jabber: magnus＠therning．org
http://therning.org/magnus

Haskell is an even 'redder' pill than Lisp or Scheme.
 -- PaulPotts



signature.asc
Description: OpenPGP digital signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: haskell compiler never comes back

So I retract that email ;)


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] Time for a new logo?

2008-12-15 Thread Sterling Clover

Alvaro's infinity lambda is awesome! The fancy treatments -- shadows,
reflections, and the funny haskell font can all go, but the infinity lambda
is distinctive, conceptually clear, and conveys the notion that we're not
just the lambda calculus, but the lambda calculus to the power of our type
system. Speaking of which, maybe the lambda cube could be the basis for a
logo?
--S
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to think about this? (profiling)

2008-12-15 Thread Lemmih

2008/12/16 Magnus Therning mag...@therning.org:
 This behaviour by Haskell seems to go against my intuition, I'm sure I
 just need an update of my intuition ;-)

 I wanted to improve on the following little example code:

  foo :: Int - Int
  foo 0 = 0
  foo 1 = 1
  foo 2 = 2
  foo n = foo (n - 1) + foo (n - 2) + foo (n - 3)

 This is obviously going to run into problems for large values of `n` so
 I introduced a state to keep intermediate results in:

  foo :: Int - State (UArray Int Int) Int
  foo 0 = return 0
  foo 1 = return 1
  foo 2 = return 2
  foo n = do
  c - get
  if (c ! n) /= -1
  then return $ c ! n
  else do
  r - liftM3 (\ a b c - a + b + c)
  (foo $ n - 1) (foo $ n - 2) (foo $ n - 3)
  modify (\ s - s // [(n, r)])
  return r

 Then I added a convenience function and called it like this:

  createArray :: Int - UArray Int Int
  createArray n = array (0, n) (zip [0..n] (repeat (-1)))

  main = do
  (n:_)  - liftM (map read) getArgs
  print $ evalState (foo n) (createArray n)

 Then I thought that this still looks pretty deeply recursive, but if I
 call the function for increasing values of `n` then I'll simply build up
 the state, sort of like doing a for-loop in an imperative language.  I
 could then end it with a call to `foo n` and be done.  I replaced `main`
 by:

  main = do
  (n:_)  - liftM (map read) getArgs
  print $ evalState (mapM_ foo [0..n]  foo n) (createArray n)

 Then I started profiling and found out that the latter version both uses
 more memory and makes far more calls to `foo`.  That's not what I
 expected!  (I suspect there's something about laziness I'm missing.)

 Anyway, I ran it with `n=35` and got

  foo n : 202,048 bytes , foo entries 100
  mapM_ foo [0..n]  foo n : 236,312 , foo entries 135 + 1

 How should I think about this in order to predict this behaviour in the
 future?

Immutable arrays are duplicated every time you write to them. Making
lots of small updates is going to be /very/ expensive.
You have the right idea, though. Saving intermediate results is the
right thing to do but arrays aren't the right way to do it. In this
case, a lazy list will perform much better.

 ack n = ackList !! n
where ackList = 0:1:2:zipWith3 (\a b c - a+b+c) ackList (drop 1 ackList) 
 (drop 2 ackList)

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

Re: [Haskell-cafe] Time for a new logo?

2008-12-15 Thread Derek Elkins

On Mon, 2008-12-15 at 18:25 -0500, Sterling Clover wrote:
 Alvaro's infinity lambda is awesome! The fancy treatments -- shadows,
 reflections, and the funny haskell font can all go, but the infinity
 lambda is distinctive, conceptually clear, and conveys the notion that
 we're not just the lambda calculus, but the lambda calculus to the
 power of our type system. Speaking of which, maybe the lambda cube
 could be the basis for a logo?

Haskell sits in the middle of one of the faces of the lambda cube,
possibly even a bit in the volume, though I don't think so.


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

Re: [Haskell-cafe] Time for a new logo?

2008-12-15 Thread Isaac Dupree

okay, I want a t-shirt like this (but with all the greek 
letters and formatting)


back:
\t. 2^-t kg
is equally[or: sometimes] bothered by math

front:
\gbtq
is [sometimes] bothered by acronyms

:-)

or, sometimes likes each of them :-)

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

Re: [Haskell-cafe] Multi-parameter type class woes

2008-12-15 Thread Alexander Dunlap

2008/12/15 Mario Blazevic mblaze...@stilo.com:
 Alexander Dunlap wrote:

 On Sun, Dec 14, 2008 at 8:10 PM, Mario Blažević mblaze...@stilo.com
 wrote:

 I'll take a swing at this one:

 instance Container (Maybe x) [x] where
 wrapper = isNothing
 . . .

 That isn't a sensible definition of 'wrapper', but I believe without
 trying to compile it is completely legal.  Which wrapper do you use?

 You /don't/ have a different matching Container instance, but without
 the
 functional dependency you /might/, and ghc barfs.

   But liftWrap doesn't require any particular instance, it's a
 generic function accepting any pair of types for which there is
 an instance of Container. Instance selection (as I understand it)
 shouldn't come into play until one applies liftWrap to a
 particular type, and indeed it does cause problems there: note
 the type annotations on the last line. That part I understand
 and accept, or at least have learned to live with.

 The problem is that y is not mentioned in the signature of wrapper.
 When you call wrapper x, there could be many different instances of
 Container x y with the same x, so GHC doesn't know which version to
 call.


I guess I see it now. However, if the explicit 'Container x y ='
 context couldn't fix the y to use for instantiation of Container x y, I
 don't see any way to fix it. And if there is no way to call wrapper in any
 context, the class declaration itself is illegal and GHC should have
 reported the error much sooner. Should I create a ticket?



 You can fix this problem either by adding a functional
 dependency or by splitting wrapper out into its own class (Wrapper x,
 e.g.) so all of the type variables in the class head are mentioned in
 its type and the instance can be determined by the call.

 Thanks for asking this question, by the way. I had known about this
 issue but had never really realized why it happened. Now that I have
 thought about it, I understand it too. :)

 Hope that helps,
 Alex




I think that 
http://www.haskell.org/pipermail/haskell-cafe/2008-April/041461.html
may be relevant. It's a design decision.

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

[Haskell-cafe] Minimal complete definitions

Good afternoon Café,

I've written a little bit of code to calculate minimal complete
definitions for a class given which of its functions use which other
functions.

As an example:

doDependencies ord =
([],[[=],[compare]])

doDependencies num =
([plus,times,abs,signum,fromInteger],[[minus],[negate]])

The first part of the pair is those functions which must *always* be
implemented, the second part is a list of possible minimal complete
definitions available for the provided list.

This can help catch mistakes; a comment in the GHC source for
GHC.Classes notes that compare must be implemented using (=) and not
() in order to give the minimal complete definition (= OR compare). If
we use the incorrect () then my code calculates the MCD as:

doDependencies wrongOrd =
([],[[],[,=,compare],[compare]])

That is, the MCD is ( OR ( AND = AND compare) OR compare).

Now I have two questions:

1) Is my code correct? ;)
2) Could this be incorporated into GHC in order to detect when someone
hasn't provided a sufficient definition for a class? As an example, it
could detect this:

 ~$ cat test2.hs
 data Die d = Die d
 instance Eq (Die d) where
 main = do
 let i = Die stack overflow
 print (i == i)
 ~$ ghc -Wall test2.hs --make
 ~$ ./test2
 Stack space overflow: current size 8388608 bytes.
 Use `+RTS -Ksize' to increase it.

Given the following:

doDependencies [(==, Just [/=]),(/=, Just [==])] =
([],[[/=],[==]])

GHC could warn that either (==) or (/=) must be implemented.

Thanks,
- George


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] Minimal complete definitions

Code might help :P


import qualified Data.Set as Set
import Data.Set (Set)
import Data.List (partition,delete)
import Data.Maybe (isJust,fromJust)

-- A snippet for working out minimal complete definitions.

num =
	[
	(plus,Nothing),
	(times,Nothing),
	(abs,Nothing),
	(minus,Just [negate]),
	(negate,Just [minus]),
	(signum,Nothing),
	(fromInteger,Nothing)
	]

ord = 
	[
	(compare,Just [=]),
	(,Just [compare]),
	(=,Just [compare]),
	(,Just [compare]),
	(=,Just [compare]),
	(max,Just [=]),
	(min,Just [=])
	]

-- a nice example from a comment in GHC's GHC.Classes
wrongOrd = 
	[
	(compare,Just []),
	(,Just [compare]),
	(=,Just [compare]),
	(,Just [compare]),
	(=,Just [compare]),
	(max,Just [=]),
	(min,Just [=])
	]

-- given a list of:
-- (thing, depends upon)
-- * depends upon can be Nothing if no implementation is defined (i.e.
--   you *always* have to implement it
-- * depends upon can be Just [] if the implementation depends on nothing else
-- * otherwise the depends upon is Just [a] where it lists the things it depends upon
--
-- returns:
-- (a list of what you must always implement, and lists of minimal dependencies)
-- doDependencies :: [(a, Maybe [a])] - (a,[[a]])
doDependencies xs = (mustImplementNames,Set.toList . Set.fromList $ map (Set.toList . Set.fromList) $ doDependencies' maybeImplement'')
	where
	(maybeImplement,mustImplement) = partition (isJust . snd) xs
	mustImplementNames = map fst mustImplement
	maybeImplement' = map (\(x,y)-(x,fromJust y)) maybeImplement
	maybeImplement'' = foldr eliminateDepends maybeImplement' mustImplementNames

eliminateDepends :: (Ord a, Eq a) = a - [(a,[a])] - [(a,[a])]
eliminateDepends x xs
	| null removeUs = stillHere
	| otherwise = foldr eliminateDepends stillHere (map fst removeUs)
	where (removeUs,stillHere) = partition (null . snd) $ map (\(it,depends) - (it, delete x depends)) xs

doDependencies' :: (Ord a, Eq a) = [(a,[a])] - [[a]]
doDependencies' eqs = dd eqs []
	where 
	dd [] solution = [solution]
	dd eqs solution =
		[concat $ dd (eliminateDepends dependency eqs) (dependency:solution)
		|dependency-rhs]
		where
			rhs = concatMap snd eqs


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] Minimal complete definitions