Re: [GHC] #5657: section suggestion adds backticks to operators
#5657: section suggestion adds backticks to operators -+-- Reporter: tinctorius| Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.4.1 Component: Compiler | Version: 7.2.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Other Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonpj): * owner: = simonmar * difficulty: = Unknown * priority: normal = high * milestone: = 7.4.1 Comment: See http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5657#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] #5658: Strict bindings are wrongly floated out of case alternatives.
#5658: Strict bindings are wrongly floated out of case alternatives. -+-- Reporter: benl | Owner: benl Type: bug | Status: new Priority: normal| Milestone: Component: Compiler | Version: 7.2.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by simonpj): Ben: I think this ticket is fixed, but it'd be good to have a test case if possible. Could you think about concocting one? Ideally without depending on vector. If it's hard, just close the ticket. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5658#comment:8 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] #5657: section suggestion adds backticks to operators
#5657: section suggestion adds backticks to operators -+-- Reporter: tinctorius| Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.4.1 Component: Compiler | Version: 7.2.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Other Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by maeder): It should be easy to change the printing of a qualified symbol within a section (namely without backticks). A more smart fix would be to change the internal qualified symbol LT.. into the two tokens, after a [, because a (qualified) symbol can never follow [ AFAICS! (Btw I vote against http://hackage.haskell.org/trac/haskell- prime/wiki/QualifiedOperators) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5657#comment:2 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] #5108: Allow unicode sub/superscript symbols in both identifiers and operators
#5108: Allow unicode sub/superscript symbols in both identifiers and operators
---+
Reporter: mikhail.vorozhtsov | Owner:
Type: feature request | Status: patch
Priority: normal | Milestone: 7.4.1
Component: Compiler (Parser) | Version: 7.1
Keywords: lexer unicode | Os: Unknown/Multiple
Architecture: Unknown/Multiple| Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby: |Blocking:
Related: |
---+
Comment(by mikhail.vorozhtsov):
Replying to [comment:4 simonmar]:
I'm not keen on this patch for a few reasons:
* It's inconsistent to allow superscript/subscript on symbols. Haskell
doesn't currently allow primes on symbols, for example.
If fact, GHC already allows unicode primes on symbols. alexGetByte
classifies OtherPunctuation characters (including primes) as `$unisymbol`.
{{{
$ ghci
GHCi, version 7.2.2: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
λ let a +′ b = a + b
}}}
The patch just makes sure that primes at least do not appear at the start
of a `@varsym`. We can further restrict sub/sup characters to appear only
in the suffix of a symbol, i.e. `@varsym = $symbol $symchar* $subsup*`.
* The patch has a bunch of Unicode constants baked into it
The same can ultimately be said about `generalCategory`, I mean look at
`u_gencat`. I can move the sup/sub test to a separate inlinable function.
* It adds a bunch of extra tests to the inner loop. I haven't
measured it but I wouldn't be surprised if this slows down the lexer.
Hm, I don't know if a few extra comparisons on already rare unicode
characters will outweight the binary search in `u_gencat`, let alone
significantly increase the overall lexing time. Is there any way to stop
GHC right after lexing so I can benchmark?
Perhaps it might be better just to allow the category Lm (MODIFIER
LETTER) as part of an identifier? That would include all the primes and
subscript/superscript things.
Lm leaves out a bunch of characters (e.g. sub/sup variants of + - =
( )), including the primes which, as I mentioned, are Po. Another
drawback is that identifies like abcₓdef would be accepted. BTW, we
already can write something not-so-beautiful like:
{{{
λ let ᵤxᵤy = 1
}}}
because ᵤ is in the Ll category.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5108#comment:5
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] #5612: panic, impossible happened, Exotic form of kind
#5612: panic, impossible happened, Exotic form of kind
---+
Reporter: guest | Owner: dreixel
Type: bug | Status: new
Priority: normal | Milestone: 7.4.1
Component: Compiler| Version: 7.3
Keywords: PolyKinds, TemplateHaskell | Os: Linux
Architecture: x86 | Failure: Other
Difficulty: |Testcase:
Blockedby: |Blocking:
Related: |
---+
Changes (by lunaris):
* keywords: = PolyKinds, TemplateHaskell
* version: 7.0.3 = 7.3
Comment:
I can reproduce what appears to be the same bug with the following:
First.hs:
{{{
{-# LANGUAGE PolyKinds #-}
module First where
data Proxy (as :: [*])
= Proxy
f :: Proxy as - ()
f _
= ()
}}}
Second.hs:
{{{
module Second where
import First
import Language.Haskell.TH
}}}
GHCI session:
{{{
% ghci -XTemplateHaskell Second.hs
GHCi, version 7.3.20111204: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
[1 of 2] Compiling First( First.hs, interpreted )
[2 of 2] Compiling Second ( Second.hs, interpreted )
Ok, modules loaded: Second, First.
*Second $(reify 'f = stringE . show)
Loading package array-0.3.0.3 ... linking ... done.
Loading package deepseq-1.2.0.1 ... linking ... done.
Loading package containers-0.4.2.0 ... linking ... done.
Loading package pretty-1.1.0.0 ... linking ... done.
Loading package template-haskell ... linking ... done.
interactive:2:3:
Exception when trying to run compile-time code:
interactive: panic! (the 'impossible' happened)
(GHC version 7.3.20111204 for x86_64-unknown-linux):
Exotic form of kind [ghc-prim:GHC.Prim.*{(w) tc 34d}]
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Code: (=) reify 'f (.) stringE show
In the expression: $(reify 'f = stringE . show)
In an equation for `it': it = $(reify 'f = stringE . show)
}}}
As far as I can tell, there aren't any TH constructors for promoted kinds
yet, so reifyKind in TcSplice can't do anything better.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5612#comment:3
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] #5612: panic, impossible happened, Exotic form of kind
#5612: panic, impossible happened, Exotic form of kind ---+ Reporter: guest | Owner: dreixel Type: bug | Status: new Priority: normal | Milestone: 7.4.1 Component: Compiler| Version: 7.3 Keywords: PolyKinds, TemplateHaskell | Os: Linux Architecture: x86 | Failure: Other Difficulty: |Testcase: Blockedby: |Blocking: Related: | ---+ Comment(by dreixel): Replying to [comment:3 lunaris]: I can reproduce what appears to be the same bug with the following: I think they are different things, as the original report wasn't using promoted kinds at all. (Though we should certainly do something about reification of promoted kinds too; thanks for reporting.) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5612#comment:4 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] #5612: panic, impossible happened, Exotic form of kind
#5612: panic, impossible happened, Exotic form of kind ---+ Reporter: guest | Owner: dreixel Type: bug | Status: new Priority: normal | Milestone: 7.4.1 Component: Compiler| Version: 7.3 Keywords: PolyKinds, TemplateHaskell | Os: Linux Architecture: x86 | Failure: Other Difficulty: |Testcase: Blockedby: |Blocking: Related: | ---+ Comment(by dreixel): I cannot reproduce the original error in ghc-7.2.1 (even after fixing a probably unintended type error in the source). So I'm leaving this to track only lunaris's report with `-XPolyKinds`. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5612#comment:5 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] #5612: panic, impossible happened, Exotic form of kind
#5612: panic, impossible happened, Exotic form of kind ---+ Reporter: guest | Owner: dreixel Type: bug | Status: new Priority: normal | Milestone: 7.4.1 Component: Compiler| Version: 7.3 Keywords: PolyKinds, TemplateHaskell | Os: Linux Architecture: x86 | Failure: Other Difficulty: |Testcase: Blockedby: |Blocking: Related: | ---+ Comment(by lunaris): If there's some sort of design in place for how kinds might be handled in TH.Kind, then I'm all up for implementing it, but there doesn't appear to be one yet. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5612#comment:6 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] #5706: building ghc from source tarball requires alex?
#5706: building ghc from source tarball requires alex? -+-- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: high | Milestone: 7.4.1 Component: Build System | Version: 7.3 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Building GHC failed Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonmar): * priority: normal = high * difficulty: = Unknown * milestone: = 7.4.1 Comment: Alex should not be required for building from source, this is indeed a bug. I'm not sure what could have changed though. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5706#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] #5705: getGCStats only works with +RTS -s
#5705: getGCStats only works with +RTS -s ---+ Reporter: tibbe | Owner: Type: bug | Status: closed Priority: normal| Milestone: Component: Runtime System|Version: 7.2.1 Resolution: wontfix | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by simonmar): * status: new = closed * difficulty: = Unknown * resolution: = wontfix Comment: I chatted with tibbe on IRC a bit about this yesterday. The conclusion is that * you can use `+RTS -T`, as ezyang noted above * you can set this at compile time with `-with-rtsopts=-T` which addresses the main issues. It's possible that we could enable `+RTS -T` by default, but someone needs to do the measurements to see if the impact is really negligible. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5705#comment:3 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] #5707: internal error: Invalid object in processHeapClosureForDead(): 0
#5707: internal error: Invalid object in processHeapClosureForDead(): 0 ---+ Reporter: brinchj | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler| Version: 7.2.1 Keywords: biographical profiling | Os: Linux Architecture: x86_64 (amd64) | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: 5451, 1519 | ---+ Changes (by simonmar): * status: new = infoneeded * difficulty: = Unknown Comment: I don't know if your issue is fixed or not. If you could try with the 7.4 RC (due out soon) that would be great, otherwise please attach a test case and we'll look into it. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5707#comment:2 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] #5708: Qualified name in binding position
#5708: Qualified name in binding position ---+ Reporter: fryguybob | Owner: Type: bug | Status: closed Priority: normal| Milestone: Component: Compiler |Version: Resolution: invalid | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by simonmar): * status: new = closed * difficulty: = Unknown * resolution: = invalid Comment: Yes, it was a bug in 7.0 that the qualified name was accepted, see [http://www.haskell.org/pipermail/cvs-ghc/2011-September/065639.html] -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5708#comment:2 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] #5709: ghc-7.2 cannot find libraries in non-standard locations
#5709: ghc-7.2 cannot find libraries in non-standard locations ---+ Reporter: kosmikus | Owner: Type: bug | Status: closed Priority: normal| Milestone: 7.4.1 Component: Package system|Version: 7.2.1 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Other | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by simonmar): * status: new = closed * difficulty: = Unknown * resolution: = fixed * milestone: = 7.4.1 Comment: I'm not quite sure how this broke in 7.2, but it is fixed in 7.4 and we have a test for it (`ghcilink005`). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5709#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] #5710: Profiling looks broken on Windows
#5710: Profiling looks broken on Windows
-+--
Reporter: simonmar | Owner:
Type: bug | Status: new
Priority: highest | Milestone: 7.4.1
Component: Compiler | Version: 7.2.1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
All the profiling tests are failing on Windows;
{{{
= arr001(profasm) 16 of 3138 [0, 0, 0]
cd ./array/should_run
'D:/slave/stable/builder/tempbuild/build/bindisttest/install
dir/bin/ghc.exe' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output
-no-user-package-conf -rtsopts -fno-ghci-history -o arr001 arr001.hs -O
-prof -auto-all arr001.comp.stderr 21
cd ./array/should_run ./arr001 +RTS -hc -p -RTS /dev/null
arr001.run.stdout 2arr001.run.stderr
Wrong exit code (expected 0 , actual 1 )
Stdout:
array (1,3) [(1,'c'),(2,'a'),(3,'b')]
Segmentation fault/access violation in generated code
Stderr:
*** unexpected failure for arr001(profasm)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5710
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] #5711: ghci asked me to report this
#5711: ghci asked me to report this --+- Reporter: guest | Owner: Type: bug | Status: new Priority: normal| Component: GHCi Version: 7.2.1 | Keywords: Os: Windows | Architecture: Unknown/Multiple Failure: None/Unknown | Testcase: Blockedby:| Blocking: Related:| --+- interactive:1:1: Not in scope: `prc' *Main ghc.exe: panic! (the 'impossible' happened) (GHC version 7.0.3 for i386-unknown-mingw32): thread blocked indefinitely in an MVar operation Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug I have tried to reproduce it but couldn't. In case it may be of help I had loaded the following file 'baby.hs': doubleMe x = x + x doubleUs x y = doubleMe x + doubleMe y doubleSmallNumber' x = (if x 100 then x else x*2) + 1 qsort [] = [] qsort (a:b) = (qsort [x|x-b,x = a]) ++ [a] ++ (qsort [x|x-b,x a]) log10 x = log x / log 10 prec a b = -log10 ((max a b) / (min a b) - 1) md x = take 3 [(a,b)|a-[1..], b-[1..], a 2, b 3] and the previous history was: (dont't laugh at my attempts to learn Haskell ;-) (Num b0) arising from the literal `3' at interactive:1:15 (Integral b0) arising from a use of `^' at interactive:1:3 (Floating b0) arising from a use of `log' at interactive:1:6-8 Probable fix: add a type signature that fixes these type variable(s) In the second argument of `(-)', namely `3' In the second argument of `(^)', namely `((log 8) - 3)' In the expression: 10 ^ ((log 8) - 3) Prelude 10.0^((log 8) - 3) interactive:1:17: Ambiguous type variable `b0' in the constraints: (Num b0) arising from the literal `3' at interactive:1:17 (Integral b0) arising from a use of `^' at interactive:1:5 (Floating b0) arising from a use of `log' at interactive:1:8-10 Probable fix: add a type signature that fixes these type variable(s) In the second argument of `(-)', namely `3' In the second argument of `(^)', namely `((log 8) - 3)' In the expression: 10.0 ^ ((log 8) - 3) Prelude 10.0^(3.1) interactive:1:5: Ambiguous type variable `b0' in the constraints: (Integral b0) arising from a use of `^' at interactive:1:5 (Fractional b0) arising from the literal `3.1' at interactive:1:7-9 Probable fix: add a type signature that fixes these type variable(s) In the expression: 10.0 ^ (3.1) In an equation for `it': it = 10.0 ^ (3.1) Prelude 10.0^3.1 interactive:1:5: Ambiguous type variable `b0' in the constraints: (Integral b0) arising from a use of `^' at interactive:1:5 (Fractional b0) arising from the literal `3.1' at interactive:1:6-8 Probable fix: add a type signature that fixes these type variable(s) In the expression: 10.0 ^ 3.1 In an equation for `it': it = 10.0 ^ 3.1 Prelude 10.0^3 1000.0 Prelude 10.0**3 1000.0 Prelude 10.0**3.1 1258.9254117941675 Prelude 10**((log 3.1) - (log 3)) 1.078424691391861 Prelude 10**((log 3.01) - (log 3)) 1.0076919520923024 Prelude log 10 2.302585092994046 Prelude log10 10 interactive:1:1: Not in scope: `log10' Prelude log 10,10 interactive:1:7: parse error on input `,' Prelude :r [1 of 1] Compiling Main ( baby.hs, interpreted ) Ok, modules loaded: Main. *Main log10 .002 interactive:1:8: No instance for (Num (a0 - c0)) arising from the literal `2' Possible fix: add an instance declaration for (Num (a0 - c0)) In the second argument of `(.)', namely `2' In the expression: log10 . 2 In an equation for `it': it = log10 . 2 *Main log10 0.002 -2.6989700043360183 *Main -log10 0.002 2.6989700043360183 *Main :r [1 of 1] Compiling Main ( baby.hs, interpreted ) Ok, modules loaded: Main. *Main prec 3.001 3 3.4771212547197097 *Main prec 3.003 3 2.951 *Main prec 3 3.003 NaN *Main prec 3.0 3.003 NaN *Main prec 3.0 2.99 2.4756711883244296 *Main :r [1 of 1] Compiling Main ( baby.hs, interpreted ) Ok, modules loaded: Main. *Main prec 3.0 3.003 3.0004340774792846 *Main prec 3.003 3 2.951 *Main :r [1 of 1] Compiling Main ( baby.hs, interpreted ) baby.hs:12:46: parse error on input `)' Failed, modules loaded: none. Prelude :r [1 of 1] Compiling Main ( baby.hs, interpreted ) Ok, modules loaded: Main. *Main prec 3.003 3 2.951 *Main prec 3 3.003 2.951 *Main :r [1 of 1] Compiling Main ( baby.hs, interpreted ) Ok, modules loaded: Main. *Main md pi
Re: [GHC] #4364: Template Haskell: Cycle in type synonym declarations
#4364: Template Haskell: Cycle in type synonym declarations +--- Reporter: igloo| Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.4.1 Component: Compiler (Type checker) | Version: 7.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: |Testcase: Blockedby: |Blocking: Related: | +--- Changes (by PHO): * cc: pho@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4364#comment:4 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] #5707: internal error: Invalid object in processHeapClosureForDead(): 0
#5707: internal error: Invalid object in processHeapClosureForDead(): 0 ---+ Reporter: brinchj | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler| Version: 7.2.1 Keywords: biographical profiling | Os: Linux Architecture: x86_64 (amd64) | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: 5451, 1519 | ---+ Comment(by brinchj): If ghc 7.4 rc is out soon, i'll give it a go and see if it works. Right now, I can't run the 7.4 due to a configuration error when installing the enumerator package: jos@laptux code/next ±master⚡ cabal install enumerator Resolving dependencies... cabal: cannot configure text-0.11.1.9. It requires integer-gmp =0.2 0.4 There is no available version of integer-gmp that satisfies =0.2 0.4 Regarding a small test case, I don't really know where to start. The project currently contains about 50 haskell modules, and I have no clue as to what part could cause the problem. There's a lot of IO going on, and the system is doing a bit of forkIO as well, running in several isolated lightweight threads. The error is triggered by the rts option -hb. Other options, like -hc or -p works. Btw, the exit code produced is 134. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5707#comment:3 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] #5707: internal error: Invalid object in processHeapClosureForDead(): 0
#5707: internal error: Invalid object in processHeapClosureForDead(): 0 ---+ Reporter: brinchj | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler| Version: 7.2.1 Keywords: biographical profiling | Os: Linux Architecture: x86_64 (amd64) | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: 5451, 1519 | ---+ Comment(by brinchj): Riiight, the threads aren't really isolated, but they communicate solely using STM and TChan/TMvar. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5707#comment:4 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] #4372: Extending quasiquotation support
#4372: Extending quasiquotation support -+-- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal| Milestone: 7.4.1 Component: Template Haskell | Version: 6.12.3 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty:|Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by PHO): * cc: pho@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4372#comment:12 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] #2041: Allow splicing in concrete syntax
#2041: Allow splicing in concrete syntax -+-- Reporter: igloo | Owner: Type: feature request | Status: new Priority: normal| Milestone: _|_ Component: Template Haskell | Version: 6.8.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by PHO): * cc: pho@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2041#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
Re: [GHC] #5671: ghc-7.2 vector code segfaults
#5671: ghc-7.2 vector code segfaults ---+ Reporter: kosmikus|Owner: Type: bug | Status: closed Priority: normal |Component: Compiler Version: 7.2.1 | Resolution: fixed Keywords: | Os: Linux Architecture: x86_64 (amd64) | Failure: Runtime crash Testcase: |Blockedby: Blocking: | Related: ---+ Changes (by kosmikus): * status: new = closed * resolution: = fixed Comment: This seems to have been fixed by the fix to bug #5658, at least I can't reproduce the problem with the latest snapshot. I'm closing this for now. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5671#comment:2 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] #5612: Better support for kinds in Template Haskell (was: panic, impossible happened, Exotic form of kind)
#5612: Better support for kinds in Template Haskell ---+ Reporter: guest | Owner: dreixel Type: feature request | Status: new Priority: normal | Milestone: 7.4.1 Component: Compiler| Version: 7.3 Keywords: PolyKinds, TemplateHaskell | Os: Unknown/Multiple Architecture: Unknown/Multiple| Failure: Other Difficulty: |Testcase: Blockedby: |Blocking: Related: | ---+ Changes (by dreixel): * type: bug = feature request * os: Linux = Unknown/Multiple * architecture: x86 = Unknown/Multiple Comment: http://hackage.haskell.org/trac/ghc/changeset/e328942561be162dd5f42b4ef630249ed34f1ef9 gives a more civilized error. Also for kinds like `Constraint`, which TH doesn't handle either. I guess this will do for 7.4, and we should indeed come up with a design for handling the new kinds in TH. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5612#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
Re: [GHC] #1476: Template Haskell: splicing types and patterns
#1476: Template Haskell: splicing types and patterns -+-- Reporter: igloo | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: Template Haskell | Version: 6.6.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by PHO): * cc: pho@… (added) * failure: = None/Unknown -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1476#comment:9 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] #5706: building ghc from source tarball requires alex?
#5706: building ghc from source tarball requires alex? -+-- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: high | Milestone: 7.4.1 Component: Build System | Version: 7.3 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Building GHC failed Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by kosmikus): It actually seems to require both alex and happy. The build succeeded once I added both packages to the build inputs. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5706#comment:2 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] #5707: internal error: Invalid object in processHeapClosureForDead(): 0
#5707: internal error: Invalid object in processHeapClosureForDead(): 0 ---+ Reporter: brinchj | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler| Version: 7.2.1 Keywords: biographical profiling | Os: Linux Architecture: x86_64 (amd64) | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: 5451, 1519 | ---+ Comment(by simonmar): The test case doesn't have to be small, as long as it is reproducible and you can give us the source code. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5707#comment:5 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] #5705: getGCStats only works with +RTS -s
#5705: getGCStats only works with +RTS -s ---+ Reporter: tibbe | Owner: Type: bug | Status: closed Priority: normal| Milestone: Component: Runtime System|Version: 7.2.1 Resolution: wontfix | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Comment(by dterei): Can we get the haddock documentation for GHC.Stats update please to include this information? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5705#comment:4 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] #5705: getGCStats only works with +RTS -s
#5705: getGCStats only works with +RTS -s ---+ Reporter: tibbe | Owner: Type: bug | Status: closed Priority: normal| Milestone: Component: Runtime System|Version: 7.2.1 Resolution: wontfix | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by dterei): * cc: dterei (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5705#comment:5 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] #5705: getGCStats only works with +RTS -s
#5705: getGCStats only works with +RTS -s
---+
Reporter: tibbe | Owner:
Type: bug | Status: closed
Priority: normal| Milestone:
Component: Runtime System|Version: 7.2.1
Resolution: wontfix | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Difficulty: Unknown
Testcase:| Blockedby:
Blocking:|Related:
---+
Comment(by ezyang):
I don't know how I failed to do this the first time around.
{{{
commit 8020e1e5eba5acf52af3b055422f93a738f95740
Author: Edward Z. Yang ezy...@mit.edu
Date: Fri Dec 16 14:50:40 2011 -0500
Document that -T RTS flag is necessary.
Signed-off-by: Edward Z. Yang ezy...@mit.edu
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5705#comment:6
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: [Haskell] Proposal to incorporate Haskell.org
Hi, As mentioned in the committee's annual report (http://haskellorg.wordpress.com/2011/10/26/first-year-report/), our attempt to join SFC has stalled because they don't have the capacity to accept new projects at the moment. We therefore applied to join SPI (http://www.spi-inc.org/), and they have now offered us associated project status (http://www.spi-inc.org/projects/associated-project-howto/). We intend to accept this offer, but are taking this final opportunity to seek feedback from the community before doing so. SPI is very like SFC in what it does and how it operates, so we don't expect this to make any substantial differences to the FAQ quoted below. Regards, Ganesh on behalf of the haskell.org committee On 10/05/2011 23:44, Don Stewart wrote: Hello everyone. The haskell.org committee[1], in the interest of the long-term stability of the open source Haskell community infrastructure, has decided to incorporate haskell.org as a legal entity. This email outlines our recommendation, and seeks input from the community on this decision. The committee's proposal is that haskell.org incorporate as an entity under the Software Freedom Conservancy umbrella organization (the same group that Darcs joined recently): http://sfconservancy.org/ If we proceed with this move, haskell.org will be a legal entity, and registered as a non-profit, allowing us to more directly accept (US tax-deductible) donations, and to invest in assets that benefit the Haskell open source community. We welcome your feedback on the proposal attached below. -- Don Stewart (on behalf of the Haskell.org committee) = A proposal for the incorporation of Haskell.org = In recent years, haskell.org has started to receive assets, e.g. money from Google Summer Of Code, donations for Hackathons, and a Sparc machine for use in GHC development. We have also started spending this money: in particular, on hosting haskell.org itself. There is also interest in running fundraising drives for specific things such as Hackathon sponsorship and hosting fees. However, haskell.org doesn't currently exist as a legal entity, meaning that these assets have had to be held on our behalf by other entities, such as Galois and various universities. This leads to tricky situations, with no-one being sure who should decide how the haskell.org assets can be used. To solve these problems, we propose that haskell.org applies to become a member project of the Software Freedom Conservancy (SFC) http://conservancy.softwarefreedom.org/. The SFC is a non-profit organization that provides free financial and administrative services to open source projects. Additionally, it has 501(c)(3) status, meaning donations from the US are tax-deductible. The SFC would hold haskell.org's money and other assets, and would be able to accept donations on behalf of haskell.org. The haskell.org committee, as described here [2], will make decisions on spending assets and other decisions related to governing the non-profit. Before proceeding, we are inviting input from the community in the form of specific objections or queries regarding the plan. We've tried to answer some of the most likely questions: Q: Does this mean that my Haskell project must now be covered by a copyleft licence such as GPL? A: No, but Haskell projects using haskell.org resource should use an Open Source licence http://www.opensource.org/licenses/alphabetical. Q: Will it still be possible to use community.h.o to host non-open-source material, such as academic papers? A: An overall minority of such content, as is the current situation, is not a problem. Q: Will it still be possible to have job ads on the haskell.org mailing lists and website? A: Yes. Q: Will this affect our ability to host the Haskell Symposium http://www.haskell.org/haskell-symposium/ and Industrial Haskell Grouphttp://industry.haskell.org/ webpages within haskell.org? A: No. Q: What will be the relationship between haskell.org and other organizations such as the Haskell Symposium and Industrial Haskell Group? A: Those organisations will continue to exist as separate entities. Q: If an umbrella non-profit organisation The Haskell Foundation was created, would haskell.org be able to join it? A: Yes. It's likely that in such a scenario, the Haskell Foundation would become the owner of the haskell.org domain name, with the cost divided between the members. The entity that is part of the SFC would be renamed community.haskell.org in order to avoid confusion. [1]: http://www.haskell.org/haskellwiki/Haskell.org_committee [2]: http://www.haskell.org/haskellwiki/Haskell.org_committee#Operation ___ Haskell mailing list hask...@haskell.org
Re: [Haskell] Proposal to incorporate Haskell.org
BTW as with the Don's original message about incorporating, I distributed this widely to increase awareness, but please restrict any feedback to haskell-cafe@ and committee@. Sorry for the noise! Ganesh On 16/12/2011 09:08, Ganesh Sittampalam wrote: Hi, As mentioned in the committee's annual report (http://haskellorg.wordpress.com/2011/10/26/first-year-report/), our attempt to join SFC has stalled because they don't have the capacity to accept new projects at the moment. We therefore applied to join SPI (http://www.spi-inc.org/), and they have now offered us associated project status (http://www.spi-inc.org/projects/associated-project-howto/). We intend to accept this offer, but are taking this final opportunity to seek feedback from the community before doing so. SPI is very like SFC in what it does and how it operates, so we don't expect this to make any substantial differences to the FAQ quoted below. Regards, Ganesh on behalf of the haskell.org committee On 10/05/2011 23:44, Don Stewart wrote: Hello everyone. The haskell.org committee[1], in the interest of the long-term stability of the open source Haskell community infrastructure, has decided to incorporate haskell.org as a legal entity. This email outlines our recommendation, and seeks input from the community on this decision. The committee's proposal is that haskell.org incorporate as an entity under the Software Freedom Conservancy umbrella organization (the same group that Darcs joined recently): http://sfconservancy.org/ If we proceed with this move, haskell.org will be a legal entity, and registered as a non-profit, allowing us to more directly accept (US tax-deductible) donations, and to invest in assets that benefit the Haskell open source community. We welcome your feedback on the proposal attached below. -- Don Stewart (on behalf of the Haskell.org committee) = A proposal for the incorporation of Haskell.org = In recent years, haskell.org has started to receive assets, e.g. money from Google Summer Of Code, donations for Hackathons, and a Sparc machine for use in GHC development. We have also started spending this money: in particular, on hosting haskell.org itself. There is also interest in running fundraising drives for specific things such as Hackathon sponsorship and hosting fees. However, haskell.org doesn't currently exist as a legal entity, meaning that these assets have had to be held on our behalf by other entities, such as Galois and various universities. This leads to tricky situations, with no-one being sure who should decide how the haskell.org assets can be used. To solve these problems, we propose that haskell.org applies to become a member project of the Software Freedom Conservancy (SFC) http://conservancy.softwarefreedom.org/. The SFC is a non-profit organization that provides free financial and administrative services to open source projects. Additionally, it has 501(c)(3) status, meaning donations from the US are tax-deductible. The SFC would hold haskell.org's money and other assets, and would be able to accept donations on behalf of haskell.org. The haskell.org committee, as described here [2], will make decisions on spending assets and other decisions related to governing the non-profit. Before proceeding, we are inviting input from the community in the form of specific objections or queries regarding the plan. We've tried to answer some of the most likely questions: Q: Does this mean that my Haskell project must now be covered by a copyleft licence such as GPL? A: No, but Haskell projects using haskell.org resource should use an Open Source licence http://www.opensource.org/licenses/alphabetical. Q: Will it still be possible to use community.h.o to host non-open-source material, such as academic papers? A: An overall minority of such content, as is the current situation, is not a problem. Q: Will it still be possible to have job ads on the haskell.org mailing lists and website? A: Yes. Q: Will this affect our ability to host the Haskell Symposium http://www.haskell.org/haskell-symposium/ and Industrial Haskell Grouphttp://industry.haskell.org/ webpages within haskell.org? A: No. Q: What will be the relationship between haskell.org and other organizations such as the Haskell Symposium and Industrial Haskell Group? A: Those organisations will continue to exist as separate entities. Q: If an umbrella non-profit organisation The Haskell Foundation was created, would haskell.org be able to join it? A: Yes. It's likely that in such a scenario, the Haskell Foundation would become the owner of the haskell.org domain name, with the cost divided between the members. The entity that is part of the SFC would be renamed community.haskell.org in order to avoid
Re: [Haskell] Proposal to incorporate Haskell.org
Hi, As mentioned in the committee's annual report (http://haskellorg.wordpress.com/2011/10/26/first-year-report/), our attempt to join SFC has stalled because they don't have the capacity to accept new projects at the moment. We therefore applied to join SPI (http://www.spi-inc.org/), and they have now offered us associated project status (http://www.spi-inc.org/projects/associated-project-howto/). We intend to accept this offer, but are taking this final opportunity to seek feedback from the community before doing so. SPI is very like SFC in what it does and how it operates, so we don't expect this to make any substantial differences to the FAQ quoted below. Regards, Ganesh on behalf of the haskell.org committee On 10/05/2011 23:44, Don Stewart wrote: Hello everyone. The haskell.org committee[1], in the interest of the long-term stability of the open source Haskell community infrastructure, has decided to incorporate haskell.org as a legal entity. This email outlines our recommendation, and seeks input from the community on this decision. The committee's proposal is that haskell.org incorporate as an entity under the Software Freedom Conservancy umbrella organization (the same group that Darcs joined recently): http://sfconservancy.org/ If we proceed with this move, haskell.org will be a legal entity, and registered as a non-profit, allowing us to more directly accept (US tax-deductible) donations, and to invest in assets that benefit the Haskell open source community. We welcome your feedback on the proposal attached below. -- Don Stewart (on behalf of the Haskell.org committee) = A proposal for the incorporation of Haskell.org = In recent years, haskell.org has started to receive assets, e.g. money from Google Summer Of Code, donations for Hackathons, and a Sparc machine for use in GHC development. We have also started spending this money: in particular, on hosting haskell.org itself. There is also interest in running fundraising drives for specific things such as Hackathon sponsorship and hosting fees. However, haskell.org doesn't currently exist as a legal entity, meaning that these assets have had to be held on our behalf by other entities, such as Galois and various universities. This leads to tricky situations, with no-one being sure who should decide how the haskell.org assets can be used. To solve these problems, we propose that haskell.org applies to become a member project of the Software Freedom Conservancy (SFC) http://conservancy.softwarefreedom.org/. The SFC is a non-profit organization that provides free financial and administrative services to open source projects. Additionally, it has 501(c)(3) status, meaning donations from the US are tax-deductible. The SFC would hold haskell.org's money and other assets, and would be able to accept donations on behalf of haskell.org. The haskell.org committee, as described here [2], will make decisions on spending assets and other decisions related to governing the non-profit. Before proceeding, we are inviting input from the community in the form of specific objections or queries regarding the plan. We've tried to answer some of the most likely questions: Q: Does this mean that my Haskell project must now be covered by a copyleft licence such as GPL? A: No, but Haskell projects using haskell.org resource should use an Open Source licence http://www.opensource.org/licenses/alphabetical. Q: Will it still be possible to use community.h.o to host non-open-source material, such as academic papers? A: An overall minority of such content, as is the current situation, is not a problem. Q: Will it still be possible to have job ads on the haskell.org mailing lists and website? A: Yes. Q: Will this affect our ability to host the Haskell Symposium http://www.haskell.org/haskell-symposium/ and Industrial Haskell Grouphttp://industry.haskell.org/ webpages within haskell.org? A: No. Q: What will be the relationship between haskell.org and other organizations such as the Haskell Symposium and Industrial Haskell Group? A: Those organisations will continue to exist as separate entities. Q: If an umbrella non-profit organisation The Haskell Foundation was created, would haskell.org be able to join it? A: Yes. It's likely that in such a scenario, the Haskell Foundation would become the owner of the haskell.org domain name, with the cost divided between the members. The entity that is part of the SFC would be renamed community.haskell.org in order to avoid confusion. [1]: http://www.haskell.org/haskellwiki/Haskell.org_committee [2]: http://www.haskell.org/haskellwiki/Haskell.org_committee#Operation ___ Haskell mailing list Haskell@haskell.org
Re: [Haskell] Proposal to incorporate Haskell.org
BTW as with the Don's original message about incorporating, I distributed this widely to increase awareness, but please restrict any feedback to haskell-cafe@ and committee@. Sorry for the noise! Ganesh On 16/12/2011 09:08, Ganesh Sittampalam wrote: Hi, As mentioned in the committee's annual report (http://haskellorg.wordpress.com/2011/10/26/first-year-report/), our attempt to join SFC has stalled because they don't have the capacity to accept new projects at the moment. We therefore applied to join SPI (http://www.spi-inc.org/), and they have now offered us associated project status (http://www.spi-inc.org/projects/associated-project-howto/). We intend to accept this offer, but are taking this final opportunity to seek feedback from the community before doing so. SPI is very like SFC in what it does and how it operates, so we don't expect this to make any substantial differences to the FAQ quoted below. Regards, Ganesh on behalf of the haskell.org committee On 10/05/2011 23:44, Don Stewart wrote: Hello everyone. The haskell.org committee[1], in the interest of the long-term stability of the open source Haskell community infrastructure, has decided to incorporate haskell.org as a legal entity. This email outlines our recommendation, and seeks input from the community on this decision. The committee's proposal is that haskell.org incorporate as an entity under the Software Freedom Conservancy umbrella organization (the same group that Darcs joined recently): http://sfconservancy.org/ If we proceed with this move, haskell.org will be a legal entity, and registered as a non-profit, allowing us to more directly accept (US tax-deductible) donations, and to invest in assets that benefit the Haskell open source community. We welcome your feedback on the proposal attached below. -- Don Stewart (on behalf of the Haskell.org committee) = A proposal for the incorporation of Haskell.org = In recent years, haskell.org has started to receive assets, e.g. money from Google Summer Of Code, donations for Hackathons, and a Sparc machine for use in GHC development. We have also started spending this money: in particular, on hosting haskell.org itself. There is also interest in running fundraising drives for specific things such as Hackathon sponsorship and hosting fees. However, haskell.org doesn't currently exist as a legal entity, meaning that these assets have had to be held on our behalf by other entities, such as Galois and various universities. This leads to tricky situations, with no-one being sure who should decide how the haskell.org assets can be used. To solve these problems, we propose that haskell.org applies to become a member project of the Software Freedom Conservancy (SFC) http://conservancy.softwarefreedom.org/. The SFC is a non-profit organization that provides free financial and administrative services to open source projects. Additionally, it has 501(c)(3) status, meaning donations from the US are tax-deductible. The SFC would hold haskell.org's money and other assets, and would be able to accept donations on behalf of haskell.org. The haskell.org committee, as described here [2], will make decisions on spending assets and other decisions related to governing the non-profit. Before proceeding, we are inviting input from the community in the form of specific objections or queries regarding the plan. We've tried to answer some of the most likely questions: Q: Does this mean that my Haskell project must now be covered by a copyleft licence such as GPL? A: No, but Haskell projects using haskell.org resource should use an Open Source licence http://www.opensource.org/licenses/alphabetical. Q: Will it still be possible to use community.h.o to host non-open-source material, such as academic papers? A: An overall minority of such content, as is the current situation, is not a problem. Q: Will it still be possible to have job ads on the haskell.org mailing lists and website? A: Yes. Q: Will this affect our ability to host the Haskell Symposium http://www.haskell.org/haskell-symposium/ and Industrial Haskell Grouphttp://industry.haskell.org/ webpages within haskell.org? A: No. Q: What will be the relationship between haskell.org and other organizations such as the Haskell Symposium and Industrial Haskell Group? A: Those organisations will continue to exist as separate entities. Q: If an umbrella non-profit organisation The Haskell Foundation was created, would haskell.org be able to join it? A: Yes. It's likely that in such a scenario, the Haskell Foundation would become the owner of the haskell.org domain name, with the cost divided between the members. The entity that is part of the SFC would be renamed community.haskell.org in order to avoid
Re: [Haskell-cafe] smt solver bindings
Dimitrios: The SBV library (http://hackage.haskell.org/package/sbv) can indeed use Z3 as a backend SBV solver. However, it uses Z3 via SMT-Lib2, not via it's C-API. It aims to provide a much higher level interface, integrating with Haskell as smoothly as possible, keeping the SMT-solver transparent to the user. I'm actively developing and using SBV (http://github.com/LeventErkok/sbv), so any comments/feedback would be most welcome. Do let me know if you decide to use it and see any issues.. -Levent. On Thu, Dec 15, 2011 at 12:17 PM, Josef Svenningsson josef.svennings...@gmail.com wrote: On Thu, Dec 15, 2011 at 7:04 PM, Dimitrios Vytiniotis dimit...@microsoft.com wrote: I've a quick question: Are there Haskell wrappers for the Z3 C API around? I believe sbv recently got support for Z3 but I don't know if it uses the C API. Neither have I tried the Z3 backend, I only played with the Yices backend. If you contact Levent Erkök, the author of sbv, he should be able to give you more information. https://github.com/LeventErkok/sbv Thanks, Josef ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] Proposal to incorporate Haskell.org
Hi, As mentioned in the committee's annual report (http://haskellorg.wordpress.com/2011/10/26/first-year-report/), our attempt to join SFC has stalled because they don't have the capacity to accept new projects at the moment. We therefore applied to join SPI (http://www.spi-inc.org/), and they have now offered us associated project status (http://www.spi-inc.org/projects/associated-project-howto/). We intend to accept this offer, but are taking this final opportunity to seek feedback from the community before doing so. SPI is very like SFC in what it does and how it operates, so we don't expect this to make any substantial differences to the FAQ quoted below. Regards, Ganesh on behalf of the haskell.org committee On 10/05/2011 23:44, Don Stewart wrote: Hello everyone. The haskell.org committee[1], in the interest of the long-term stability of the open source Haskell community infrastructure, has decided to incorporate haskell.org as a legal entity. This email outlines our recommendation, and seeks input from the community on this decision. The committee's proposal is that haskell.org incorporate as an entity under the Software Freedom Conservancy umbrella organization (the same group that Darcs joined recently): http://sfconservancy.org/ If we proceed with this move, haskell.org will be a legal entity, and registered as a non-profit, allowing us to more directly accept (US tax-deductible) donations, and to invest in assets that benefit the Haskell open source community. We welcome your feedback on the proposal attached below. -- Don Stewart (on behalf of the Haskell.org committee) = A proposal for the incorporation of Haskell.org = In recent years, haskell.org has started to receive assets, e.g. money from Google Summer Of Code, donations for Hackathons, and a Sparc machine for use in GHC development. We have also started spending this money: in particular, on hosting haskell.org itself. There is also interest in running fundraising drives for specific things such as Hackathon sponsorship and hosting fees. However, haskell.org doesn't currently exist as a legal entity, meaning that these assets have had to be held on our behalf by other entities, such as Galois and various universities. This leads to tricky situations, with no-one being sure who should decide how the haskell.org assets can be used. To solve these problems, we propose that haskell.org applies to become a member project of the Software Freedom Conservancy (SFC) http://conservancy.softwarefreedom.org/. The SFC is a non-profit organization that provides free financial and administrative services to open source projects. Additionally, it has 501(c)(3) status, meaning donations from the US are tax-deductible. The SFC would hold haskell.org's money and other assets, and would be able to accept donations on behalf of haskell.org. The haskell.org committee, as described here [2], will make decisions on spending assets and other decisions related to governing the non-profit. Before proceeding, we are inviting input from the community in the form of specific objections or queries regarding the plan. We've tried to answer some of the most likely questions: Q: Does this mean that my Haskell project must now be covered by a copyleft licence such as GPL? A: No, but Haskell projects using haskell.org resource should use an Open Source licence http://www.opensource.org/licenses/alphabetical. Q: Will it still be possible to use community.h.o to host non-open-source material, such as academic papers? A: An overall minority of such content, as is the current situation, is not a problem. Q: Will it still be possible to have job ads on the haskell.org mailing lists and website? A: Yes. Q: Will this affect our ability to host the Haskell Symposium http://www.haskell.org/haskell-symposium/ and Industrial Haskell Grouphttp://industry.haskell.org/ webpages within haskell.org? A: No. Q: What will be the relationship between haskell.org and other organizations such as the Haskell Symposium and Industrial Haskell Group? A: Those organisations will continue to exist as separate entities. Q: If an umbrella non-profit organisation The Haskell Foundation was created, would haskell.org be able to join it? A: Yes. It's likely that in such a scenario, the Haskell Foundation would become the owner of the haskell.org domain name, with the cost divided between the members. The entity that is part of the SFC would be renamed community.haskell.org in order to avoid confusion. [1]: http://www.haskell.org/haskellwiki/Haskell.org_committee [2]: http://www.haskell.org/haskellwiki/Haskell.org_committee#Operation ___ Haskell mailing list hask...@haskell.org
Re: [Haskell-cafe] Parallel Matrix Multiplication
Hi Mukesh, Great to hear you're trying parallel Haskell! I can't yet help debug your parallel performance, but maybe I can offer something for your last request. Have you tried the Parallel Haskell portal? http://www.haskell.org/haskellwiki/Parallel You will find some links mainly aimed at helping people to get started, and also a list of parallel Haskell readings. Hope this helps :-) On 10 Dec 2011, at 18:14, mukesh tiwari wrote: I am trying to learn parallel Haskell and I have gone through couple of resources ( Real world Haskell and http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel/AFP08-notes.pdf ). I understood par and pseq and I wrote matrix multiplication using these two function but it does not look. Although I did not get all these details but none of the sparks converted which is really important for parallel programming. Could some one please tell me how to improve this. Also kindly recommend me some literature for parallel programming in Haskell. -- Eric Kow http://erickow.com signature.asc Description: Message signed with OpenPGP using GPGMail ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] SMP parallelism increasing GC time dramatically
On Mon, Oct 10, 2011 at 15:55, Tom Thorne thomas.thorn...@gmail.com wrote: Yes I will try to run threadscope on it, I tried it before and the event log output produced about 1.8GB, and then crashed. Hi Tom, I'm one of the TS/ghc-events hackers and I'd like to learn more, fix it or at least put it on the TS/ghc-events issue tracker (http://trac.haskell.org/ThreadScope). Could you help me reproduce the problem? Did ThreadScope crash or RTS? Which versions? Was it 1.8GB of the log file or RAM? Did you succeed eventually? Any other TS feedback? Thank you, Mikolaj ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] Proposal to incorporate Haskell.org
BTW as with the Don's original message about incorporating, I distributed this widely to increase awareness, but please restrict any feedback to haskell-cafe@ and committee@. Sorry for the noise! Ganesh On 16/12/2011 09:08, Ganesh Sittampalam wrote: Hi, As mentioned in the committee's annual report (http://haskellorg.wordpress.com/2011/10/26/first-year-report/), our attempt to join SFC has stalled because they don't have the capacity to accept new projects at the moment. We therefore applied to join SPI (http://www.spi-inc.org/), and they have now offered us associated project status (http://www.spi-inc.org/projects/associated-project-howto/). We intend to accept this offer, but are taking this final opportunity to seek feedback from the community before doing so. SPI is very like SFC in what it does and how it operates, so we don't expect this to make any substantial differences to the FAQ quoted below. Regards, Ganesh on behalf of the haskell.org committee On 10/05/2011 23:44, Don Stewart wrote: Hello everyone. The haskell.org committee[1], in the interest of the long-term stability of the open source Haskell community infrastructure, has decided to incorporate haskell.org as a legal entity. This email outlines our recommendation, and seeks input from the community on this decision. The committee's proposal is that haskell.org incorporate as an entity under the Software Freedom Conservancy umbrella organization (the same group that Darcs joined recently): http://sfconservancy.org/ If we proceed with this move, haskell.org will be a legal entity, and registered as a non-profit, allowing us to more directly accept (US tax-deductible) donations, and to invest in assets that benefit the Haskell open source community. We welcome your feedback on the proposal attached below. -- Don Stewart (on behalf of the Haskell.org committee) = A proposal for the incorporation of Haskell.org = In recent years, haskell.org has started to receive assets, e.g. money from Google Summer Of Code, donations for Hackathons, and a Sparc machine for use in GHC development. We have also started spending this money: in particular, on hosting haskell.org itself. There is also interest in running fundraising drives for specific things such as Hackathon sponsorship and hosting fees. However, haskell.org doesn't currently exist as a legal entity, meaning that these assets have had to be held on our behalf by other entities, such as Galois and various universities. This leads to tricky situations, with no-one being sure who should decide how the haskell.org assets can be used. To solve these problems, we propose that haskell.org applies to become a member project of the Software Freedom Conservancy (SFC) http://conservancy.softwarefreedom.org/. The SFC is a non-profit organization that provides free financial and administrative services to open source projects. Additionally, it has 501(c)(3) status, meaning donations from the US are tax-deductible. The SFC would hold haskell.org's money and other assets, and would be able to accept donations on behalf of haskell.org. The haskell.org committee, as described here [2], will make decisions on spending assets and other decisions related to governing the non-profit. Before proceeding, we are inviting input from the community in the form of specific objections or queries regarding the plan. We've tried to answer some of the most likely questions: Q: Does this mean that my Haskell project must now be covered by a copyleft licence such as GPL? A: No, but Haskell projects using haskell.org resource should use an Open Source licence http://www.opensource.org/licenses/alphabetical. Q: Will it still be possible to use community.h.o to host non-open-source material, such as academic papers? A: An overall minority of such content, as is the current situation, is not a problem. Q: Will it still be possible to have job ads on the haskell.org mailing lists and website? A: Yes. Q: Will this affect our ability to host the Haskell Symposium http://www.haskell.org/haskell-symposium/ and Industrial Haskell Grouphttp://industry.haskell.org/ webpages within haskell.org? A: No. Q: What will be the relationship between haskell.org and other organizations such as the Haskell Symposium and Industrial Haskell Group? A: Those organisations will continue to exist as separate entities. Q: If an umbrella non-profit organisation The Haskell Foundation was created, would haskell.org be able to join it? A: Yes. It's likely that in such a scenario, the Haskell Foundation would become the owner of the haskell.org domain name, with the cost divided between the members. The entity that is part of the SFC would be renamed community.haskell.org in order to avoid
Re: [Haskell-cafe] ANNOUNCE: hxournal-0.5.0.0 - A pen notetaking program written in haskell
Hi, all, I just uploaded hxournal-0.5.1 which is implemented with .hxournal config file, Use X Input menu enabled, and a fix for compilation problem of gdkconfig.h by Custom build during cabal configure using pkg-config --cflags gtk+-2.0 Please try the new version by cabal update cabal install hxournal I have made a google group of hxournal : hxour...@googlegroups.com Any issues on hxournal will be welcome and discussed there. Currently, I branched 0.5.1 version for stabilization and now started to focus on pdf background rendering (which is most relevant for my purpose) in the master branch. Thank you for your interest and reports. best, On Thu, Dec 15, 2011 at 4:33 PM, Edward Z. Yang ezy...@mit.edu wrote: When I attempt to build on Ubuntu, I get: ezyang@javelin:~$ cabal install hxournal Resolving dependencies... Configuring hxournal-0.5.0.0... Preprocessing library hxournal-0.5.0.0... In file included from /usr/include/gtk-2.0/gdk/gdkscreen.h:32:0, from /usr/include/gtk-2.0/gdk/gdkapplaunchcontext.h:31, from /usr/include/gtk-2.0/gdk/gdk.h:32, from /usr/include/gtk-2.0/gtk/gtk.h:32, from Device.hsc:3: /usr/include/gtk-2.0/gdk/gdktypes.h:55:23: fatal error: gdkconfig.h: No such file or directory compilation terminated. compiling dist/build/Application/HXournal/Device_hsc_make.c failed (exit code 1) command was: /usr/bin/gcc -c dist/build/Application/HXournal/Device_hsc_make.c -o dist/build/Application/HXournal/Device_hsc_make.o -fno-stack-protector -fno-stack-protector -Wl,--hash-style=both,--no-copy-dt-needed-entries,--as-needed -D__GLASGOW_HASKELL__=700 -Dlinux_BUILD_OS -Dlinux_HOST_OS -Di386_BUILD_ARCH -Di386_HOST_ARCH -Icsrc -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/libdrm -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/lib/ghc-7.0.3/process-1.0.1.5/include -I/usr/lib/ghc-7.0.3/directory-1.1.0.0/include -I/usr/lib/ghc-7.0.3/old-time-1.0.0.6/include -I/usr/lib/ghc-7.0.3/unix-2.4.2.0/include -I/usr/lib/ghc-7.0.3/time-1.2.0.3/include -I/usr/lib/ghc-7.0.3/bytestring-0.9.1.10/include -I/usr/lib/ghc-7.0.3/base-4.3.1.0/include -I/usr/lib/ghc-7.0.3/include -I/usr/lib/ghc-7.0.3/include/ cabal: Error: some packages failed to install: hxournal-0.5.0.0 failed during the building phase. The exception was: ExitFailure 1 This may be of interest: ezyang@javelin:~$ locate gdkconfig.h /home/ezyang/Dev/gtk+/gdk/gdkconfig.h.win32 /usr/include/gtk-3.0/gdk/gdkconfig.h /usr/lib/i386-linux-gnu/gtk-2.0/include/gdkconfig.h Edward Excerpts from Edward Z. Yang's message of Mon Dec 12 20:10:19 -0500 2011: Very fancy! I am a big fan of Xournal, so I will have to take this for a spin. Edward Excerpts from Ian-Woo Kim's message of Mon Dec 12 06:56:09 -0500 2011: Hi, everyone, I am very pleased to announce a pen notetaking program: hxournal, which is written entirely in haskell using gtk2hs. I uploaded the package on hackage. This program accompanies with two library packages, xournal-parser and xournal-render for parsing and rendering xournal format file. http://hackage.haskell.org/package/hxournal http://hackage.haskell.org/package/xournal-parser http://hackage.haskell.org/package/xournal-render Installing hxournal should be very simple: cabal update cabal install hxournal hxournal can be currently regarded as a clone of xournal, which is a notetaking program developed in C. (See http://xournal.sourceforge.net) As xournal, hxournal can take wacom tablet X11 input in subpixel unit so that it can result in very smooth notetaking experience. Currently, basic pen operations and eraser operations, file open/save operations, rectangular selection, cut/copy/paste operations have been implemented. So the application is semi-usable. The file format is the same as xournal but gunzipped. So to view/edit xoj files generated from xournal, just gunzip the xoj files and read them in hxournal. Gunzipped xoj files generated from hxournal are readable in xournal program. One NEW special feature of hxournal compared with xournal: This program can make a split view (horizontal and vertical and
Re: [Haskell-cafe] SMP parallelism increasing GC time dramatically
Hi, I can't remember if it was threadscope that crashed or the RTS, since I was also having segfaults in the RTS because of this bug, that is fixed in 7.2.2: http://hackage.haskell.org/trac/ghc/ticket/5552 I successfully used threadscope by running my code for fewer iterations to produce a smaller log, and it was helpful to make sure I was dividing work equally between the threads. I think I still have the log file that was about 1.8GB so I will try running threadscope on it and see what happens. The performance problems I was having turned out to be fixed completely by changing the GC options passed to the RTS. thanks! Tom On Friday, 16 December 2011 at 09:20, Mikolaj Konarski wrote: On Mon, Oct 10, 2011 at 15:55, Tom Thorne thomas.thorn...@gmail.com (mailto:thomas.thorn...@gmail.com) wrote: Yes I will try to run threadscope on it, I tried it before and the event log output produced about 1.8GB, and then crashed. Hi Tom, I'm one of the TS/ghc-events hackers and I'd like to learn more, fix it or at least put it on the TS/ghc-events issue tracker (http://trac.haskell.org/ThreadScope). Could you help me reproduce the problem? Did ThreadScope crash or RTS? Which versions? Was it 1.8GB of the log file or RAM? Did you succeed eventually? Any other TS feedback? Thank you, Mikolaj ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] Proposal to incorporate Haskell.org
On Fri, Dec 16, 2011 at 7:08 AM, Ganesh Sittampalam gan...@earth.li wrote: Q: If an umbrella non-profit organisation The Haskell Foundation was created, would haskell.org be able to join it? A: Yes. It's likely that in such a scenario, the Haskell Foundation would become the owner of the haskell.org domain name, with the cost divided between the members. The entity that is part of the SFC would be renamed community.haskell.org in order to avoid confusion. Would it be a too ambitious goal to create the Haskell Foundation at this moment? -- Giovanni ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] Proposal to incorporate Haskell.org
On 16/12/2011 10:59, Giovanni Tirloni wrote: On Fri, Dec 16, 2011 at 7:08 AM, Ganesh Sittampalam gan...@earth.li mailto:gan...@earth.li wrote: Q: If an umbrella non-profit organisation The Haskell Foundation was created, would haskell.org http://haskell.org be able to join it? A: Yes. It's likely that in such a scenario, the Haskell Foundation would become the owner of the haskell.org http://haskell.org domain name, with the cost divided between the members. The entity that is part of the SFC would be renamed community.haskell.org http://community.haskell.org in order to avoid confusion. Would it be a too ambitious goal to create the Haskell Foundation at this moment? It would be a lot of administrative effort - managing accounts, tax filings, etc. While it would give us more control, I don't think the benefits would be very significant. So in my view for now it's best not to go it alone. Cheers, Ganesh ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] DB vs read/show for persisting large data
Thank you so much .. I am going to try out acid-state. I've been shying away from template-haskell ... but from the looks of it, acid-state/safecopy can do what I am looking for. Regards, Kashyap On Thu, Dec 15, 2011 at 12:13 AM, Bas van Dijk v.dijk@gmail.com wrote: On 14 December 2011 15:22, Claude Heiland-Allen cla...@goto10.org wrote: I ran into this very nightmare in one project, and was recommend safecopy [0] by someone on the #haskell IRC channel. I've not (yet) used it but it looks very nice! [0] http://hackage.haskell.org/package/safecopy Or better yet, use acid-state which is build on top of safecopy: http://acid-state.seize.it/ Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: hxournal-0.5.0.0 - A pen notetaking program written in haskell
Thanks :) It's working now. I tried it with XInput and without it. Lines seem smoother when XInput is activated. On 16 December 2011 11:33, Ian-Woo Kim ianwoo...@gmail.com wrote: Hi, all, I just uploaded hxournal-0.5.1 which is implemented with .hxournal config file, Use X Input menu enabled, and a fix for compilation problem of gdkconfig.h by Custom build during cabal configure using pkg-config --cflags gtk+-2.0 Please try the new version by cabal update cabal install hxournal I have made a google group of hxournal : hxour...@googlegroups.com Any issues on hxournal will be welcome and discussed there. Currently, I branched 0.5.1 version for stabilization and now started to focus on pdf background rendering (which is most relevant for my purpose) in the master branch. Thank you for your interest and reports. best, On Thu, Dec 15, 2011 at 4:33 PM, Edward Z. Yang ezy...@mit.edu wrote: When I attempt to build on Ubuntu, I get: ezyang@javelin:~$ cabal install hxournal Resolving dependencies... Configuring hxournal-0.5.0.0... Preprocessing library hxournal-0.5.0.0... In file included from /usr/include/gtk-2.0/gdk/gdkscreen.h:32:0, from /usr/include/gtk-2.0/gdk/gdkapplaunchcontext.h:31, from /usr/include/gtk-2.0/gdk/gdk.h:32, from /usr/include/gtk-2.0/gtk/gtk.h:32, from Device.hsc:3: /usr/include/gtk-2.0/gdk/gdktypes.h:55:23: fatal error: gdkconfig.h: No such file or directory compilation terminated. compiling dist/build/Application/HXournal/Device_hsc_make.c failed (exit code 1) command was: /usr/bin/gcc -c dist/build/Application/HXournal/Device_hsc_make.c -o dist/build/Application/HXournal/Device_hsc_make.o -fno-stack-protector -fno-stack-protector -Wl,--hash-style=both,--no-copy-dt-needed-entries,--as-needed -D__GLASGOW_HASKELL__=700 -Dlinux_BUILD_OS -Dlinux_HOST_OS -Di386_BUILD_ARCH -Di386_HOST_ARCH -Icsrc -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/libdrm -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/lib/ghc-7.0.3/process-1.0.1.5/include -I/usr/lib/ghc-7.0.3/directory-1.1.0.0/include -I/usr/lib/ghc-7.0.3/old-time-1.0.0.6/include -I/usr/lib/ghc-7.0.3/unix-2.4.2.0/include -I/usr/lib/ghc-7.0.3/time-1.2.0.3/include -I/usr/lib/ghc-7.0.3/bytestring-0.9.1.10/include -I/usr/lib/ghc-7.0.3/base-4.3.1.0/include -I/usr/lib/ghc-7.0.3/include -I/usr/lib/ghc-7.0.3/include/ cabal: Error: some packages failed to install: hxournal-0.5.0.0 failed during the building phase. The exception was: ExitFailure 1 This may be of interest: ezyang@javelin:~$ locate gdkconfig.h /home/ezyang/Dev/gtk+/gdk/gdkconfig.h.win32 /usr/include/gtk-3.0/gdk/gdkconfig.h /usr/lib/i386-linux-gnu/gtk-2.0/include/gdkconfig.h Edward Excerpts from Edward Z. Yang's message of Mon Dec 12 20:10:19 -0500 2011: Very fancy! I am a big fan of Xournal, so I will have to take this for a spin. Edward Excerpts from Ian-Woo Kim's message of Mon Dec 12 06:56:09 -0500 2011: Hi, everyone, I am very pleased to announce a pen notetaking program: hxournal, which is written entirely in haskell using gtk2hs. I uploaded the package on hackage. This program accompanies with two library packages, xournal-parser and xournal-render for parsing and rendering xournal format file. http://hackage.haskell.org/package/hxournal http://hackage.haskell.org/package/xournal-parser http://hackage.haskell.org/package/xournal-render Installing hxournal should be very simple: cabal update cabal install hxournal hxournal can be currently regarded as a clone of xournal, which is a notetaking program developed in C. (See http://xournal.sourceforge.net) As xournal, hxournal can take wacom tablet X11 input in subpixel unit so that it can result in very smooth notetaking experience. Currently, basic pen operations and eraser operations, file open/save operations, rectangular selection, cut/copy/paste operations have been implemented. So the application is semi-usable. The file format is the same as xournal but gunzipped. So to view/edit xoj files generated from xournal, just gunzip the xoj files and read them in hxournal. Gunzipped xoj files
Re: [Haskell-cafe] [Haskell] Proposal to incorporate Haskell.org
On 16 December 2011 11:10, Ganesh Sittampalam gan...@earth.li wrote: On 16/12/2011 10:59, Giovanni Tirloni wrote: On Fri, Dec 16, 2011 at 7:08 AM, Ganesh Sittampalam gan...@earth.li mailto:gan...@earth.li wrote: Q: If an umbrella non-profit organisation The Haskell Foundation was created, would haskell.org http://haskell.org be able to join it? A: Yes. It's likely that in such a scenario, the Haskell Foundation would become the owner of the haskell.org http://haskell.org domain name, with the cost divided between the members. The entity that is part of the SFC would be renamed community.haskell.org http://community.haskell.org in order to avoid confusion. Would it be a too ambitious goal to create the Haskell Foundation at this moment? It would be a lot of administrative effort - managing accounts, tax filings, etc. While it would give us more control, I don't think the benefits would be very significant. So in my view for now it's best not to go it alone. I agree. If at some point we feel that having a Haskell Foundation would be desirable (despite the additional overheads) there shouldn't be anything stopping us from doing so. Are there any drawbacks in joining such an organisation? How do they finance their overheads? Would a donation to haskell.org include a fee to SPI? I couldn't find any information on their website. / Thomas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] Proposal to incorporate Haskell.org
On 16/12/2011 13:21, Thomas Schilling wrote: On 16 December 2011 11:10, Ganesh Sittampalam gan...@earth.li wrote: On 16/12/2011 10:59, Giovanni Tirloni wrote: Would it be a too ambitious goal to create the Haskell Foundation at this moment? It would be a lot of administrative effort - managing accounts, tax filings, etc. While it would give us more control, I don't think the benefits would be very significant. So in my view for now it's best not to go it alone. I agree. If at some point we feel that having a Haskell Foundation would be desirable (despite the additional overheads) there shouldn't be anything stopping us from doing so. Are there any drawbacks in joining such an organisation? How do they finance their overheads? Would a donation to haskell.org include a fee to SPI? I couldn't find any information on their website. Yes - 5% goes to SPI to cover their overheads. It's detailed in http://www.spi-inc.org/projects/associated-project-howto/ but not on their donations page at http://www.spi-inc.org/donations/. 5% seems reasonable to me and in line with what similar donation aggregators charge, for example the Charities Aid Foundation in the UK charges 4%: https://www.cafonline.org/my-personal-giving/plan-your-giving/individual-charity-account.aspx In effect we've been getting the admin for free from Galois up till now, but it's been getting too troublesome for them. Cheers, Ganesh ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] Proposal to incorporate Haskell.org
On 16 December 2011 13:36, Ganesh Sittampalam gan...@earth.li wrote: Would a donation to haskell.org include a fee to SPI? I couldn't find any information on their website. Yes - 5% goes to SPI to cover their overheads. It's detailed in http://www.spi-inc.org/projects/associated-project-howto/ but not on their donations page at http://www.spi-inc.org/donations/. 5% seems reasonable to me and in line with what similar donation aggregators charge, for example the Charities Aid Foundation in the UK charges 4%: https://www.cafonline.org/my-personal-giving/plan-your-giving/individual-charity-account.aspx Yes, that sounds reasonable. Credit cards donations also cause an overhead of 4.5% (and the 5% are deducted from the rest), so the total overhead for a credit card donation would be: (1 - 0.955 * 0.95) = 9.3% That's fairly high, but I don't see a way around that. In effect we've been getting the admin for free from Galois up till now, but it's been getting too troublesome for them. Yes, I certainly understand that. The other reason are tax-deductible donations, which I assume isn't really possible with Galois handling all the financials. / Thomas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alternative versus Monoid
On 16 December 2011 05:26, Brent Yorgey byor...@seas.upenn.edu wrote:
I, for one, would be
quite in favor of changing the current Monoid (Maybe a) instance to
correspond to the failure-and-prioritized-choice semantics
So lets do this. Some questions:
1) What about the First type? Do we {-# DEPRECATE #-} it?
2) What about the Last type? It could be deprecated in favor of Dual.
3) Do we need a new type (like the current Maybe) for lifting
semigroups into a Monoid? IMHO we don't since the semigroup package
does a better job with the Option type (like Brent mentioned).
4) How much code will break from this change?
5) Anyone up for proposing this to librar...@haskell.org?
Regards,
Bas
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alternative versus Monoid
Attached is a git patch for base which makes the proposed changes.
From 824bdca994b3fcceff21fcb68e1b18f1d4f03bd5 Mon Sep 17 00:00:00 2001
From: Bas van Dijk v.dijk@gmail.com
Date: Fri, 16 Dec 2011 15:16:14 +0100
Subject: [PATCH] Give the Maybe Monoid the expected
failure-and-prioritized-choice semantics instead of the
lift-a-semigroup-to-a-monoid semantics. The old semantics
didn't even achieve the latter since it required a Monoid
instance on a, rather than a semigroup Also DEPRECATE First
in favor of Maybe and Last in favor of Dual.
---
Data/Monoid.hs | 46 --
1 files changed, 20 insertions(+), 26 deletions(-)
diff --git a/Data/Monoid.hs b/Data/Monoid.hs
index 228e254..d1d9564 100644
--- a/Data/Monoid.hs
+++ b/Data/Monoid.hs
@@ -186,14 +186,14 @@ instance Num a = Monoid (Product a) where
--
-- @
-- findLast :: Foldable t = (a - Bool) - t a - Maybe a
--- findLast pred = getLast . foldMap (\x - if pred x
---then Last (Just x)
---else Last Nothing)
+-- findLast pred = getDual . foldMap (\x - if pred x
+--then Dual (Just x)
+--else Dual Nothing)
-- @
--
-- Much of Data.Map's interface can be implemented with
-- Data.Map.alter. Some of the rest can be implemented with a new
--- @alterA@ function and either 'First' or 'Last':
+-- @alterA@ function and either 'Maybe' or 'Dual Maybe':
--
-- alterA :: (Applicative f, Ord k) =
--(Maybe a - f (Maybe a)) - k - Map k a - f (Map k a)
@@ -204,28 +204,21 @@ instance Num a = Monoid (Product a) where
-- insertLookupWithKey :: Ord k = (k - v - v - v) - k - v
-- - Map k v - (Maybe v, Map k v)
-- insertLookupWithKey combine key value =
--- Arrow.first getFirst . alterA doChange key
+-- alterA doChange key
-- where
--- doChange Nothing = (First Nothing, Just value)
--- doChange (Just oldValue) =
--- (First (Just oldValue),
--- Just (combine key value oldValue))
+-- doChange m@Nothing = (m, Just value)
+-- doChange m@(Just oldValue) = (m, Just (combine key value oldValue))
-- @
--- | Lift a semigroup into 'Maybe' forming a 'Monoid' according to
--- http://en.wikipedia.org/wiki/Monoid: \Any semigroup @S@ may be
--- turned into a monoid simply by adjoining an element @e@ not in @S@
--- and defining @e*e = e@ and @e*s = s = s*e@ for all @s ∈ S@.\ Since
--- there is no \Semigroup\ typeclass providing just 'mappend', we
--- use 'Monoid' instead.
-instance Monoid a = Monoid (Maybe a) where
+instance Monoid (Maybe a) where
mempty = Nothing
- Nothing `mappend` m = m
- m `mappend` Nothing = m
- Just m1 `mappend` Just m2 = Just (m1 `mappend` m2)
-
+ Nothing `mappend` r = r
+ l `mappend` _ = l
-- | Maybe monoid returning the leftmost non-Nothing value.
+--
+-- /DEPRECATED in favor of 'Maybe'!/
+{-# DEPRECATED First Use Maybe instead #-}
newtype First a = First { getFirst :: Maybe a }
#ifndef __HADDOCK__
deriving (Eq, Ord, Read, Show)
@@ -237,11 +230,13 @@ instance Show a = Show (First a)
#endif
instance Monoid (First a) where
-mempty = First Nothing
-r@(First (Just _)) `mappend` _ = r
-First Nothing `mappend` r = r
+mempty = First mempty
+First l `mappend` First r = First (l `mappend` r)
-- | Maybe monoid returning the rightmost non-Nothing value.
+--
+-- /DEPRECATED in favor of 'Dual'!/
+{-# DEPRECATED Last Use Dual instead #-}
newtype Last a = Last { getLast :: Maybe a }
#ifndef __HADDOCK__
deriving (Eq, Ord, Read, Show)
@@ -253,9 +248,8 @@ instance Show a = Show (Last a)
#endif
instance Monoid (Last a) where
-mempty = Last Nothing
-_ `mappend` r@(Last (Just _)) = r
-r `mappend` Last Nothing = r
+mempty = Last mempty
+Last x `mappend` Last y = Last (y `mappend` x)
{-
{
--
1.7.5.4
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Dutch national FP day, January 6, Utrecht
On http://www.cs.uu.nl/wiki/bin/view/FPDag2012/WebHome you will find the program and registration information about the next Dutch National Functional Programming day, on January 6, Utrecht University. Please forward this mail to anyone interested. Any questions can be directed to me. Hoping to meet you all, Doaitse Swierstra ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alternative versus Monoid
1) What about the First type? Do we {-# DEPRECATE #-} it?
Personnaly, I'm in favor of following the same logic than Int:
Int itself is *not *a monoid. You have to be specific: it's either Sum or
Mult.
It should be the same for Maybe: we remove its instance of Monoid, and we
only use First and Last.
2011/12/16 Bas van Dijk v.dijk@gmail.com
On 16 December 2011 05:26, Brent Yorgey byor...@seas.upenn.edu wrote:
I, for one, would be
quite in favor of changing the current Monoid (Maybe a) instance to
correspond to the failure-and-prioritized-choice semantics
So lets do this. Some questions:
1) What about the First type? Do we {-# DEPRECATE #-} it?
2) What about the Last type? It could be deprecated in favor of Dual.
3) Do we need a new type (like the current Maybe) for lifting
semigroups into a Monoid? IMHO we don't since the semigroup package
does a better job with the Option type (like Brent mentioned).
4) How much code will break from this change?
5) Anyone up for proposing this to librar...@haskell.org?
Regards,
Bas
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alternative versus Monoid
Sorry, I meant Sum and Product for the monoid equivalents of a Num instance.
2011/12/16 Yves Parès limestr...@gmail.com
1) What about the First type? Do we {-# DEPRECATE #-} it?
Personnaly, I'm in favor of following the same logic than Int:
Int itself is *not *a monoid. You have to be specific: it's either Sum or
Mult.
It should be the same for Maybe: we remove its instance of Monoid, and we
only use First and Last.
2011/12/16 Bas van Dijk v.dijk@gmail.com
On 16 December 2011 05:26, Brent Yorgey byor...@seas.upenn.edu wrote:
I, for one, would be
quite in favor of changing the current Monoid (Maybe a) instance to
correspond to the failure-and-prioritized-choice semantics
So lets do this. Some questions:
1) What about the First type? Do we {-# DEPRECATE #-} it?
2) What about the Last type? It could be deprecated in favor of Dual.
3) Do we need a new type (like the current Maybe) for lifting
semigroups into a Monoid? IMHO we don't since the semigroup package
does a better job with the Option type (like Brent mentioned).
4) How much code will break from this change?
5) Anyone up for proposing this to librar...@haskell.org?
Regards,
Bas
___
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] What happens if you get hit by a bus?
I'm learning what it means to be a professional Haskell programmer, and contemplating taking on side jobs. The path of least resistance seems to be web applications, as that is what I do at work. I've been investigating what some web developers have to say about their trade. One article addresses the question above. His answer was that he uses RoR which has a large community and he is therefore easily replaceable. My question, for freelancers in general, and web developers in particular is this: How do you address this question? I imagine potential clients would need to be assuaged of their fears that hiring me would lead to a lock-in situation at best, and no one to maintain a code base at worst. Lock-in won't be part of my business model, also sooner or later we part ways with the client. When the client wonders, What happens then?, what is a good answer? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What happens if you get hit by a bus?
I would think there were plenty of Haskell programmers ready to jump in as replacements. On 16 December 2011 15:37, Michael Litchard mich...@schmong.org wrote: I'm learning what it means to be a professional Haskell programmer, and contemplating taking on side jobs. The path of least resistance seems to be web applications, as that is what I do at work. I've been investigating what some web developers have to say about their trade. One article addresses the question above. His answer was that he uses RoR which has a large community and he is therefore easily replaceable. My question, for freelancers in general, and web developers in particular is this: How do you address this question? I imagine potential clients would need to be assuaged of their fears that hiring me would lead to a lock-in situation at best, and no one to maintain a code base at worst. Lock-in won't be part of my business model, also sooner or later we part ways with the client. When the client wonders, What happens then?, what is a good answer? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What happens if you get hit by a bus?
Yes! I could cite the large and growing set of libraries on hackage as evidence. On Fri, Dec 16, 2011 at 7:40 AM, Colin Adams colinpaulad...@gmail.com wrote: I would think there were plenty of Haskell programmers ready to jump in as replacements. On 16 December 2011 15:37, Michael Litchard mich...@schmong.org wrote: I'm learning what it means to be a professional Haskell programmer, and contemplating taking on side jobs. The path of least resistance seems to be web applications, as that is what I do at work. I've been investigating what some web developers have to say about their trade. One article addresses the question above. His answer was that he uses RoR which has a large community and he is therefore easily replaceable. My question, for freelancers in general, and web developers in particular is this: How do you address this question? I imagine potential clients would need to be assuaged of their fears that hiring me would lead to a lock-in situation at best, and no one to maintain a code base at worst. Lock-in won't be part of my business model, also sooner or later we part ways with the client. When the client wonders, What happens then?, what is a good answer? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What happens if you get hit by a bus?
What about just replying with this one link: http://www.haskellers.com/ As thumb of rule it takes half the time to review code compared to writing it (Don't remember where I read it ..). Thus even RoR can be a lock in and delay updates if stuff changes. The only chance is creating a team and provide services as team. But in the end its a matter of costs: If you have to share ideas - if you have to keep each other up to date it'll take more time and somebody has to pay for it in the end.. Its not only a Haskell vs RoR qusetion IMHO. Marc Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What happens if you get hit by a bus?
Michael Litchard mich...@schmong.org writes: One article addresses the question above. His answer was that he uses RoR which has a large community and he is therefore easily replaceable. My question, for freelancers in general, and web developers in particular is this: How do you address this question? In this particular case, you could argue that more people know PHP and Python than Ruby, so surely one should avoid Ruby as well. Managers like to think of their company as a factory, and from this perspective, it makes sense to build your factory from easily obtainable parts. But the factory mindset only works when you want to manufacture stuff, nobody who takes a minute to actually think will say that you can replace any programmer with any other, as long as they know the same programming language or framework. Anyway, here's something I found interesting in that respect: http://www.dachisgroup.com/2011/12/cant-get-no-satisfaction-why-service-companies-cant-keep-their-promises/ (This probably turned out less helpful than I intended, sorry :-) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Dutch national FP day, January 6, Utrecht
Ik wil me graag inschrijven, inc dinner. Groeten, Mathijs On Fri, Dec 16, 2011 at 3:31 PM, S D Swierstra doai...@swierstra.net wrote: On http://www.cs.uu.nl/wiki/bin/view/FPDag2012/WebHome you will find the program and registration information about the next Dutch National Functional Programming day, on January 6, Utrecht University. Please forward this mail to anyone interested. Any questions can be directed to me. Hoping to meet you all, Doaitse Swierstra ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What happens if you get hit by a bus?
I think the truck-factor implications of the programming language as dwarfed by the implications of everything else in the project. Any project of any significant size is going to have a huge amount of project-specific information tucked up inside the programmers head. It doesn't matter if there are a million other programmers who know the language you used, or only a dozen- if you're the only one who knows how things were done, and more importantly, why they were done that way, and you get hit by a truck, then your boss has a big problem. Whether there are millions of candidate replacement programmers, or only dozens, none of them had the project-specific knowledge you had. Finding a replacement who knows the language is the least of his problems. On Fri, Dec 16, 2011 at 10:40 AM, Colin Adams colinpaulad...@gmail.comwrote: I would think there were plenty of Haskell programmers ready to jump in as replacements. On 16 December 2011 15:37, Michael Litchard mich...@schmong.org wrote: I'm learning what it means to be a professional Haskell programmer, and contemplating taking on side jobs. The path of least resistance seems to be web applications, as that is what I do at work. I've been investigating what some web developers have to say about their trade. One article addresses the question above. His answer was that he uses RoR which has a large community and he is therefore easily replaceable. My question, for freelancers in general, and web developers in particular is this: How do you address this question? I imagine potential clients would need to be assuaged of their fears that hiring me would lead to a lock-in situation at best, and no one to maintain a code base at worst. Lock-in won't be part of my business model, also sooner or later we part ways with the client. When the client wonders, What happens then?, what is a good answer? ___ 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
Re: [Haskell-cafe] What happens if you get hit by a bus?
On Fri, 16 Dec 2011 11:17:20 -0500, Brian Hurt bh...@spnz.org wrote: I think the truck-factor implications of the programming language as dwarfed by the implications of everything else in the project. Any project of any significant size is going to have a huge amount of project-specific information tucked up inside the programmers head. It doesn't matter if there are a million other programmers who know the language you used, or only a dozen- if you're the only one who knows how things were done, and more importantly, why they were done that way, and you get hit by a truck, then your boss has a big problem. Whether there are millions of candidate replacement programmers, or only dozens, none of them had the project-specific knowledge you had. Finding a replacement who knows the language is the least of his problems. I believe that you're absolutely right. I also believe that corporate decision makers rarely, if ever, think that way. And that's the problem: You have to deal with the perception, not the reality. So, that's the real question that needs to be answered: How do you deal with the _perception_ that hiring a Haskell developer instead of a Rails, etc. developer will result in more chaos when said developer is hit by a bus? -Steve Schafer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What happens if you get hit by a bus?
Just like Michael, I've been learning what it means to be a professional Haskell programmer for a few months. I think the case of Ruby on Rails and Haskell are very, very, very different. Ruby on Rails has been around for many years. There are books, tutorials, examples, websites, etc. Still, there are not as many developers that use Rails than those that use PHP, or Java, or .NET, or Python (for web development). But there are many. This is definitely not the case with Haskell. If you go around the internet, it's not just that you can't find Haskell programmers with the necessary skills. You also cannot find people demanding these jobs, servers that support Haskell for web, or success stories to convince others and yourself that this is the right platform for this job. After several months, I just found the first client for which I'll create a website using Yesod. Being a professional Haskell developer requires many skills that have nothing to do with Haskell. Unless you are born with the talent of having the tax rules embedded in your head, you'll have to learn them. Maybe the hard way. That is true for lots of tasks related to social skills, design, management, negotiation. such as how do I know what the client really wants without wasting hundreds of hours, how the heck do I show my client what I have in mind or should this button go on the right or on the left and why should I care. Learning them takes time, and most of us don't learn them unless we actually need to. It's not that there aren't any people capable of creating websites using Haskell, or Haskell programmers who could learn to do it. It's just that not many people know enough, as of this day, to deliver a professional product with the results that clients expect. In my experience, the following help: - Have a good portfolio, a list of websites you've created in Haskell that shows they have nothing to fear. If you can't find clients, create websites for free. Sparked.com may help. You'll know the list is good when there are great jobs that you choose not to include in it. - Ask your previous clients and those you created websites for to leave feedback, acknowledge your work publicly or recommend you on linkedin. - Make a list of your competitors names and addresses (and put my name on top of the list ;) Haskellers.org may help. So can linkedin, guru.com, peopleperhour, etc. If they ask, tell them that there are tens of programmers with the necessary experience to go on if they are not satisfied with your work. If you want, we can created a group in a social network just for this, with the requirement that you must have created an actual product to be in the group. The amount of packages in hackage means Nothing to me. It means nothing to my clients. Good luck. Cheers, Ivan On 16 December 2011 17:08, Ketil Malde ke...@malde.org wrote: Michael Litchard mich...@schmong.org writes: One article addresses the question above. His answer was that he uses RoR which has a large community and he is therefore easily replaceable. My question, for freelancers in general, and web developers in particular is this: How do you address this question? In this particular case, you could argue that more people know PHP and Python than Ruby, so surely one should avoid Ruby as well. Managers like to think of their company as a factory, and from this perspective, it makes sense to build your factory from easily obtainable parts. But the factory mindset only works when you want to manufacture stuff, nobody who takes a minute to actually think will say that you can replace any programmer with any other, as long as they know the same programming language or framework. Anyway, here's something I found interesting in that respect: http://www.dachisgroup.com/2011/12/cant-get-no-satisfaction-why-service-companies-cant-keep-their-promises/ (This probably turned out less helpful than I intended, sorry :-) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type checker for haskell-src-exts (was: Typechecking Using GHC API)
On Thu, Dec 15, 2011 at 5:33 PM, Sean Leather leat...@cs.uu.nl wrote: On Thu, Dec 15, 2011 at 11:07, Niklas Broberg wrote: Envisioned: The function you ask for can definitely be written for haskell-src-exts, which I know you are currently using. I just need to complete my type checker for haskell-src-exts first. Which is not a small task, but one that has been started. That's good to know! I presume it's something like Haskell98 to start with? I'd be even more impressed (and possibly also concerned for your health) if you were going to tackle all of the extensions! Actually, no. Starting with Haskell98 would just lead to great pains later on, since many of the extensions require very invasive changes compared to a H98 checker. My starting point has been to identify the core structural and algorithmical requirements for a type checker that would indeed tackle all of the extensions. My current checker (which I wouldn't even call half-complete) is based on a merge of the algorithms discussed in [1] and [2]. Between the two, they give, on the one hand, the bidirectional inference needed to handle arbitrary-rank types, and, on the other hand, the power of local assumptions needed to handle GADTs and type families. I thank you for your concerns for my health. However, I assure you they are quite misplaced. Typing Haskell-with-extensions in Haskell is not only a far smaller beast than what it's made out to be, when walking in the well-documented footsteps of giants. It is also lots of fun. :-) I've been trying to find a student to write a haskell-src-exts type checker for me. It should use a particular kind of mechanism though, using constraints similar to [1]. Then, I want to adapt that to do transformations. What approach are you using? Maybe I can somehow steal your work... ;) As you note from my starting references, I'm using the same approach and base algorithms as GHC does. I looked at some alternatives briefly, including the work you reference, but I discarded them all since none of them had support for everything I wanted to cover. In particular, it is not at all clear how these systems would merge with bi-directional inference or local assumptions. Tackling *that* problem would be a large and very interesting research topic I'm sure, but not one I have time to dig into at the current time. Indeed, the feasibility of my project (and thus the sanctity of my health) relies very heavily on the footsteps-of-giants factor... So as not to give anyone false hopes, I should point out that I currently have next to no time at all to devote to this, and the project has been dormant since August. I'll return to it for sure, but at the moment cannot tell when. Cheers, /Niklas [1] S. Peyton Jones, D. Vytiniotis, S. Weirich, and M. Shields. Practical type inference for arbitrary-rank types. [2] D. Vytiniotis, S. Peyton Jones, T. Schrijvers, M. Sulzmann. OutsideIn(X) – Modular type inference with local assumptions ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type checker for haskell-src-exts (was: Typechecking Using GHC API)
On Thu, Dec 15, 2011 at 6:24 PM, Thomas Schilling nomin...@googlemail.comwrote: What exactly are the hopes for such a type checker? I can understand it being interesting as a research project, but as a realistic tools there are two huge issues: 1. It's going to take a LOT of time to reach feature parity with GHC's type checker. 2. Assuming that can be done, how is it going to be maintained and kept up to date with GHC? If it is going to be used as a development tool, both of these are a major requirement. I haven't looked into the issues, but I'd expect it would be more realistic (although definitely not trivial) to translate from GHC's internal AST into an annotated haskell-src-exts AST. With all due respect, the sentiments you give voice to here are a large part of what drives me to do this project in the first place. Haskell is not GHC, and I think that the very dominant position of GHC many times leads to ill thought-through extensions. Since GHC has no competitor, often extensions (meaning behavior as denoted and delimited by some -X flag) are based on what is most convenient from the implementation point of view, rather than what would give the most consistent, logical and modular user experience (not to mention third-party-tool-implementor-trying-to-support-GHC-extensions experience). As such, I'm not primarily doing this project to get a development tool out, even if that certainly is a very neat thing. I'm just as much doing it to provide a Haskell (front-end) implementation that can serve as a better reference than GHC, one that very explicitly does *not* choose the convenient route to what constitutes an extension, and instead attempts to apply rigid consistency and modularity between extensions. Also, just like for haskell-src-exts I hope to build the type checker from the roots with the user interface as a core design goal, not as a tacked-on afterthought. Mind you, in no way do I intend any major criticism towards GHC or its implementors. GHC is a truly amazing piece of software, indeed it's probably my personal favorite piece of software of all times. That does not mean it comes free of quirks and shady corners though, and it is my hope that by doing what I do I can help shine a light on them. Answering your specific issues: 1) Yes, it's a lot of work. Probably not half as much as you'd think though, see my previous mail about walking in the footsteps of giants. But beyond that, I think it's work that truly needs to be done, for the greater good of Haskell. 2) Well, I think I've done a reasonably good job keeping haskell-src-exts up to date so far, even if the last year has been pretty bad in that regard (writing a PhD thesis will do that to you). I'll keep doing it for the type checker as well. But I am but one man, so if anyone else feels like joining the project then they are more than welcome to. Sort-of-3) Yes, both implementation and maintenance are likely going to be far more costly than the alternative to do a translation via the GHC API. I'm not interested in that alternative though. Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What happens if you get hit by a bus?
Tell them that if you were instead on Rails, you'd have a huge chance of being hit by a train, which is likely to deal far more damage than a bus. 2011/12/16 Michael Litchard mich...@schmong.org I'm learning what it means to be a professional Haskell programmer, and contemplating taking on side jobs. The path of least resistance seems to be web applications, as that is what I do at work. I've been investigating what some web developers have to say about their trade. One article addresses the question above. His answer was that he uses RoR which has a large community and he is therefore easily replaceable. My question, for freelancers in general, and web developers in particular is this: How do you address this question? I imagine potential clients would need to be assuaged of their fears that hiring me would lead to a lock-in situation at best, and no one to maintain a code base at worst. Lock-in won't be part of my business model, also sooner or later we part ways with the client. When the client wonders, What happens then?, what is a good answer? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What happens if you get hit by a bus?
Michael Litchard wrote: [--snip--] If getting hit by a bus is a significant factor in the overall outcome of the project then I think those are pretty good odds, aren't they? (I do realize that traffic accidents are a lot more frequent than we like to think, but still...) -- Bárður Árantsson ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What happens if you get hit by a bus?
On 16/12/2011 07:05 PM, Bardur Arantsson wrote: Michael Litchard wrote: [--snip--] If getting hit by a bus is a significant factor in the overall outcome of the project then I think those are pretty good odds, aren't they? (I do realize that traffic accidents are a lot more frequent than we like to think, but still...) The /actual/ probability of being hit by a bus is irrelevant. The only thing of concequence is the /percieved/ probability. This latter quantity is not related to the former in any meaningful way. In fact, due to an effect known as availability bias, the probability of any potential threat varies depending on how long you spend thinking about it. (In other words, if you've never even considered what would happen if your sole developer got hit by a bus, your estimate of the probability of this will be very low. If you sit down and think about how much trouble you'd be in if this actually happened, suddenly your estimate of the probability starts increasing. This is completely illogical - which is why it's called a cognitive bias.) Ever heard the phrase fear, uncertainty and doubt? It's a killer in a business context. It seems clear [to me] that there are actually quite a few Haskell programmers around, and it's not especially hard to find them. The question is how many good ones there are. Good is all vague and subjective and hard to measure, unfortunately. On the other hand, if you just start the project with more than one developer on board in the first place, then the possibility of just one of them being killed prematurely becomes drastically less serious. (For the business. I'm sure it's still fairly serious for the person who just DIED...) PS. Kudos to Ketil Malde for the best link I've seen today. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What happens if you get hit by a bus?
On Fri, Dec 16, 2011 at 3:51 PM, Andrew Coppin andrewcop...@btinternet.comwrote: On 16/12/2011 07:05 PM, Bardur Arantsson wrote: Michael Litchard wrote: [--snip--] If getting hit by a bus is a significant factor in the overall outcome of the project then I think those are pretty good odds, aren't they? (I do realize that traffic accidents are a lot more frequent than we like to think, but still...) The /actual/ probability of being hit by a bus is irrelevant. The only thing of concequence is the /percieved/ probability. This latter quantity is not related to the former in any meaningful way. In fact, due to an effect known as availability bias, the probability of any potential threat varies depending on how long you spend thinking about it. (In other words, if you've never even considered what would happen if your sole developer got hit by a bus, your estimate of the probability of this will be very low. If you sit down and think about how much trouble you'd be in if this actually happened, suddenly your estimate of the probability starts increasing. This is completely illogical - which is why it's called a cognitive bias. There are a lot of ways that, from the perspective of the business, a person could get hit by a bus- they could get into an accident, including getting hit by a bus, die for some other reason, get sick, retire, get another job, or even quit to join the Peace Corp and get shipped off to Uganda (actually had that happen to me once). Sooner or later, everyone will be metaphorically hit by a bus, in that they will not be here anymore. Next time this discussion comes up, as the room how many people have been at their company for 20 years or more. Then ask them to guess how many people in the room will still be at the company in 20 years time. The high probability is that very few, if any, people will still be at the company in 20 years time. It doesn't matter why Bob is no longer here with his specialized knowledge of Bob's code, but the end result is the same. And the problem is the same- someone else has to be brought in to deal with Bob's code. And that someone, even if they know the language the code is written in as well, or even better, than Bob, doesn't know the *code*. And it's just a question of when, not if, Bob will no longer be there to maintain the code. If anything, using Haskell *reduces* the truck-factor compared to other languages. Someone new coming in needs to be able to make small changes fairly quickly (major reorganizations and refactorings can generally be delayed while the new person comes up to speed, but small bug fix and small feature additions are a constant need). What Nancy the new hire can do, if the code is in Haskell, is simply change the function, and let the compiler figure out where it's being used. Also, types are a wonderful bit of documentation- see the paper Theorems for Free by Phillip Wadler. This makes it easier fo the new person to come up to speed on what the code does, if not necessarily how or why. Ever heard the phrase fear, uncertainty and doubt? It's a killer in a business context. It seems clear [to me] that there are actually quite a few Haskell programmers around, and it's not especially hard to find them. The question is how many good ones there are. Good is all vague and subjective and hard to measure, unfortunately. On the other hand, if you just start the project with more than one developer on board in the first place, then the possibility of just one of them being killed prematurely becomes drastically less serious. (For the business. I'm sure it's still fairly serious for the person who just DIED...) Again, it depends. If there was this large body of code that only one developer ever worked on, then you have truck-factor problems. PS. Kudos to Ketil Malde for the best link I've seen today. __**_ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://www.haskell.org/mailman/listinfo/haskell-cafe Brian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What happens if you get hit by a bus?
Andrew Coppin wrote: On 16/12/2011 07:05 PM, Bardur Arantsson wrote: Michael Litchard wrote: [--snip--] If getting hit by a bus is a significant factor in the overall outcome of the project then I think those are pretty good odds, aren't they? (I do realize that traffic accidents are a lot more frequent than we like to think, but still...) The /actual/ probability of being hit by a bus is irrelevant. The only thing of concequence is the /percieved/ probability. This latter quantity is not related to the former in any meaningful way. In fact, due to an effect known as availability bias, the probability of any potential threat varies dependi ng on how long you spend thinking about it. [snip blah blah blah] - Not to be rude, but... (*) That was the point of my post. If you're actually confronted with this perception that traffic accidents are relevant to project success, you're already in deep manure because there's so much more than code in a project. That's what you need to explain. Code is the means of getting us to an end. It seems these people are worring about the means when the big problem is actually conveying the ends. (Again, just my take on the situation, I'm not claiming canonicity or anything.) -- Bárður Árantsson (*) I realize that this is rude. I can only apologize. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] I've just heard of a neat security measure that when you compile the code it generates different object code...
... with the same functionality. Thus, your program would be a moving target to hackers. Would this be challenging with ghc? -- -- Regards, KC ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I've just heard of a neat security measure that when you compile the code it generates different object code...
On Sat, Dec 17, 2011 at 12:27 PM, KC kc1...@gmail.com wrote: ... with the same functionality. Thus, your program would be a moving target to hackers. Would this be challenging with ghc? Although it's possible, I doubt this would do anything. Most exploits are just programmer mistakes; changing the object code doesn't change the fact that there's a gaping security hole in your program. Plus, it would be harder to debug the compiler, since the mangling code would be non-deterministic by definition. So I doubt anyone would try to implement that. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type checker for haskell-src-exts (was: Typechecking Using GHC API)
On 16 December 2011 17:44, Niklas Broberg niklas.brob...@gmail.com wrote: With all due respect, the sentiments you give voice to here are a large part of what drives me to do this project in the first place. Haskell is not GHC, and I think that the very dominant position of GHC many times leads to ill thought-through extensions. Since GHC has no competitor, often extensions (meaning behavior as denoted and delimited by some -X flag) are based on what is most convenient from the implementation point of view, rather than what would give the most consistent, logical and modular user experience (not to mention third-party-tool-implementor-trying-to-support-GHC-extensions experience). I agree. Various record proposals have been rejected because of the not easily implementable in GHC constraint. Of course, ease of implementation (and maintenance) is a valid argument, but it has an unusual weight if GHC is the (in practise) only implementation. Other extensions seem to just get added on (what feels like) a whim (e.g., RecordPuns). As such, I'm not primarily doing this project to get a development tool out, even if that certainly is a very neat thing. I'm just as much doing it to provide a Haskell (front-end) implementation that can serve as a better reference than GHC, one that very explicitly does *not* choose the convenient route to what constitutes an extension, and instead attempts to apply rigid consistency and modularity between extensions. Also, just like for haskell-src-exts I hope to build the type checker from the roots with the user interface as a core design goal, not as a tacked-on afterthought. Mind you, in no way do I intend any major criticism towards GHC or its implementors. GHC is a truly amazing piece of software, indeed it's probably my personal favorite piece of software of all times. That does not mean it comes free of quirks and shady corners though, and it is my hope that by doing what I do I can help shine a light on them. Wll... I've gotten a little bit of a different perspective on this since working at a company with very high code quality standards (at least for new code). There is practically no observable code review happening. I'm sure Dimitrios and Simon PJ review most of each other's code every now and then, but overall there is very little code review happening (and no formal, recorded code review whatsoever). Cleaning up the GHC code base is a huge task -- it uses lots of dirty tricks (global variables, hash tables, unique generation is non-deterministic, ...) which often complicate efforts tremendously (I tried). The lack of a unit tests doesn't help (just rewriting code so that it can be tested would help quite a bit). Don't get me wrong, I certainly appreciate the work the GHC team is doing, but GHC strikes a fine balance between industrial needs and research needs. I'm just wondering whether the balance is always right. Answering your specific issues: 1) Yes, it's a lot of work. Probably not half as much as you'd think though, see my previous mail about walking in the footsteps of giants. But beyond that, I think it's work that truly needs to be done, for the greater good of Haskell. Right OutsideIn(X) (the Journal paper description, not the ICFP'09 version) seems like the right way to go. I wasn't aware of the other paper (the original work on bidirectional type inference seemed very unpredictable in terms of when type annotations are needed, so I'm looking forward to how this new paper handles things). 2) Well, I think I've done a reasonably good job keeping haskell-src-exts up to date so far, even if the last year has been pretty bad in that regard (writing a PhD thesis will do that to you). I'll keep doing it for the type checker as well. But I am but one man, so if anyone else feels like joining the project then they are more than welcome to. Sort-of-3) Yes, both implementation and maintenance are likely going to be far more costly than the alternative to do a translation via the GHC API. I'm not interested in that alternative though. Fair enough. As I am interested in building reliable (and maintainable) development tools my priorities are obviously different. For that purpose, using two different implementations can lead to very confusing issues for the user (that's why I was asking about bug compatibility). Apart from the bus factor, there is also the bitrotting issue due to GHC's high velocity. For example, even though HaRe does build again it doesn't support many commonly used GHC extensions and it is difficult to add them into the existing code base (which isn't pretty). Anyway, good luck with your endeavours. / Thomas -- 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] [Alternative] summary of my understanding so far
On 15/12/2011, Gregory Crosswhite gcrosswh...@gmail.com wrote: 1) Documentation really needs to be improved 2) some/many cannot be physically separated from Alternative, but there *might* be an advantage to creating a subclass for them anyway purely for the sake of conveying more information about a type to users 3) Maybe and [] are sensible instances of Alternative, even if many/some often enters an infinite loop. 4) It is possible to provide special instance of many/some that satisfy the equations of many/some, with the slight disadvantage that these solutions are no longer the least solutions. Based on all of this, at this moment in time it seems to me that the most sensible way forward is to fix the documentation, tweak the definition of Alternative to no longer require the least solutions of the equations, and then to adopt the new instances for Maybe and []. Thoughts? (1) If we do (4), then the documentation ought to be adequate as-is. (2) In my opinion, no. If one is writing code polymorphic in (Alternative f = f), then one needn't worry. If one is using such code, then one ought to know whether some and many are sane for the types in question, anyhow (O_ō) (4) This is very reasonable; not the least solutions, but hey, they converge (^_^) Cheers, Greg Cheers, Matthew Farkas-Dyck ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alternative versus Monoid
On 15/12/2011, Conor McBride co...@strictlypositive.org wrote:
On 15 Dec 2011, at 15:19, Brent Yorgey wrote:
On Thu, Dec 15, 2011 at 06:49:13PM +1000, Gregory Crosswhite wrote:
So at the end of the day... what is the point of even making Maybe
and [] instances of Alternative?
The Alternative and Monoid instances for [] are equivalent. However,
the Alternative and Monoid instances for Maybe are not. To wit:
(Just (Sum 4)) | (Just (Sum 3))
Just (Sum {getSum = 4})
(Just (Sum 4)) `mappend` (Just (Sum 3))
Just (Sum {getSum = 7})
The current monoid instance for Maybe is, in my view, unfortunate.
Types are about semantic purpose, not just data representation.
Many purposes can be represented in the same way. We should identify
the purpose of a type (or type constructor), then define instances
consistent with that purpose. And better, we acquire by instance
inference compound instances consistent with that purpose! (A similar
view is often articulated well by Conal Elliott. But perhaps it's
just a Con thing.)
The purpose of Maybe, it seems to me, is to model failure and
prioritized choice, after the manner of exceptions. It's clear
what the failure-and-prioritized-choice monoid is.
It so happens that the same data representation can be used to make
a semigroup into a monoid by attaching an identity element. That's
a different semantic purpose, which deserves a different type.
This really bites. I really like being able to write things like
newtype P a x = P ([a] - Maybe (x, [a])) deriving Monoid
and then make MonadPlus/Alternative instances just by copying the
monoid that results, but it doesn't work!
It's unfortunate that we don't have local quantification in
constraints, so we can't write (forall x. Monoid (f x)), hence the
need for constructor classes doing basically the same job, with,
of necessity, newly renamed members. I think it compounds the
problem to choose inconsistent behaviour between the constructor
class and the underlying type class.
Maybe I'm an extremist, but I'd prefer it if every Alternative
instance was constructed by duplicating a polymorphic Monoid
instance.
Meanwhile, as for the issue which kicked this off, I do think it's
good to document and enforce meaningful (i.e. total on total input)
usages of operations by types where practical. At present, refining
one type class into several to account for subtle issues (like
whether some/many actually work) is expensive, even if it's
desirable. I'd once again plug default superclass instances and
Control.Newtype, then suggest that the library might benefit from a
little pruning.
All the best
Conor
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
By my reason, the instance (Monoid a = Monoid (Maybe a)) is
appropriate, since we have another class for inner-type-agnostic
choice -- Alternative! (and MonadPlus, but that's essentially the
same, and would be if (Functor m = Applicative m = Monad m), as it
ought).
Cheers,
Matthew Farkas-Dyck
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Alternative] summary of my understanding so far
On Dec 17, 2011, at 12:35 PM, Matthew Farkas-Dyck wrote: (1) If we do (4), then the documentation ought to be adequate as-is. I see your point that if we do (4) then some and many are no longer problematic for Maybe and [], and thus we don't need warnings for those types. However, nonetheless we will *still* need *big warnings* *for the sake of others who write Alternative instances* for new types to make sure that these instances do not fall into the same trap as Maybe and []. That is, we want to let future authors of instances know about the conditions under which they will need to write their own versions of some and maybe in order to make sure that these methods have sensible behavior. In addition to this, we also really need some additional documentation explaining what the point of some and many are, since few people have any clue about them. :-) Finally, if we adopt (4) then we will need to change the documentation to remove least from least solutions of the equations since the phrase will no longer be correct. Better still, we could replace the phrase entirely with something like least *converging* solutions of the equations. (*) Cheers, Greg (*) P.S: Dear people who are better at this kind of technical language than I: I am fully aware of the fact that the phrase least converging solutions of the equations [...] is sloppy wording at best and absolutely wrong at worst, but hopefully you should at least understand what I am *trying* to get at. Thus, I would welcome either your feedback on what it is that I am supposed to be thinking and saying, or an explanation about why the idea I am trying to conceive and convey is so intrinsically poorly formed that I am best off just giving up on it. ;-)___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alternative versus Monoid
On Dec 17, 2011, at 1:26 AM, Yves Parès wrote:
1) What about the First type? Do we {-# DEPRECATE #-} it?
Personnaly, I'm in favor of following the same logic than Int:
Int itself is not a monoid. You have to be specific: it's either Sum or Mult.
It should be the same for Maybe: we remove its instance of Monoid, and we
only use First and Last.
+1 for this idea, because it follows the principle of least surprise.
Cheers,
Greg___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alternative versus Monoid
On Dec 17, 2011, at 1:26 AM, Yves Parès wrote:
1) What about the First type? Do we {-# DEPRECATE #-} it?
Personnaly, I'm in favor of following the same logic than Int:
Int itself is not a monoid. You have to be specific: it's either Sum or Mult.
It should be the same for Maybe: we remove its instance of Monoid, and we
only use First and Last.
+1 for this idea, because it follows the principle of least surprise.
Cheers,
Greg
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alternative versus Monoid
On Dec 17, 2011, at 12:51 PM, Matthew Farkas-Dyck wrote: By my reason, the instance (Monoid a = Monoid (Maybe a)) is appropriate, since we have another class for inner-type-agnostic choice -- Alternative! (and MonadPlus, but that's essentially the same, and would be if (Functor m = Applicative m = Monad m), as it ought). Yes, but the problem here is that having different behavior for Alternative, MonadPlus, and Monoid instances is inherently confusing, in the sense that this would almost certainly surprise someone who wasn't already aware of the difference between the instances. Regardless, even if we keep the current behavior, we *really* *really* need to improve the documentation for the Monoid instance of Maybe. Currently it reads: Lift a semigroup into Maybe forming a Monoid according to http://en.wikipedia.org/wiki/Monoid: Any semigroup S may be turned into a monoid simply by adjoining an element e not in S and defining e*e = eand e*s = s = s*e for all s S. Since there is no Semigroup typeclass providing just mappend, we use Monoid instead. Now, I just happened to have recently spent time studying the properties of Semigroups and Monoids, so this explanation made perfect sense to me and was a beautiful way of explaining what is going on. A typical user, however --- which would have included me roughly one month ago :-) --- would have looked at this and just seen goobledegook which reinforced their perception that Haskell is first and foremost a playground for mathematicians. It would be much, much better for the documentation to be something like this: The Monoid instance for Maybe has the property that, for all x and y, (Just x) wins when combined (on either side) with Nothing values, and when (Just x) is combined with (Just y) then the result is (Just (x `mappend` y)). For the more mathematically inclined, you may think of this as being equivalent to the standard practice of turning an arbitrary semigroup into a monoid by simply adding a new element to the semigroup to serve as the identity element, where in this case the identity element is the Nothing value of Maybe; unfortunately, since the base libraries do not come with a Semigroup typeclass, this process is expressed in code as lifting from the Monoid typeclass. NOTE THAT the behavior of the Monoid instance of Maybe is DIFFERENT from the behavior of the MonadPlus and Alternative instance of Maybe. For the latter two typeclasses, the behavior is that when (Just x) is combined with (Just y) the x and y values themselves are not combined but rather y is discarded so (Just x) simply wins; put another way, for all x and z, we have that (Just x) `mappend` z is *always* equal to (Just x), regardless of whether z is equal to Nothing or whether it is equal to (Just y) for some y. For this reason, unlike the instance for Monoid, the instances for these MonadPlus and Alternative place no additional constraints on the type lifted into Maybe. Incidentally, would people be interested in me sending a patch to update the documentation to be more along these lines? (After applying your feedback, of course!) If so, could you point me to where I could learn about the process for doing so? Cheers, Greg___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alternative versus Monoid
On Dec 17, 2011, at 2:57 PM, Gregory Crosswhite wrote: +1 for this idea, because it follows the principle of least surprise. Sorry about the double-post! I was foolish enough not only to use unsafePerformIO to send my e-mail, but to forgot to mark the sending routine with NOINLINE pragma. As a result, the sending action was sparked and run twice by the runtime environment. Cheers, Greg___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type checker for haskell-src-exts (was: Typechecking Using GHC API)
On Dec 17, 2011, at 9:58 AM, Thomas Schilling wrote: Wll... I've gotten a little bit of a different perspective on this since working at a company with very high code quality standards (at least for new code). There is practically no observable code review happening. I'm sure Dimitrios and Simon PJ review most of each other's code every now and then, but overall there is very little code review happening (and no formal, recorded code review whatsoever). Cleaning up the GHC code base is a huge task -- it uses lots of dirty tricks (global variables, hash tables, unique generation is non-deterministic, ...) which often complicate efforts tremendously (I tried). The lack of a unit tests doesn't help (just rewriting code so that it can be tested would help quite a bit). So in other words, would it be helpful it we recruited GHC janitors? That is, similar to how we have the Trac which gives people bug reports to pick out and work on, would it make sense to have a Trac or some other process which gives people chunks of code to clean up and/or make easier to test? (I am of course inspired in suggesting this by the Linux kernel janitors, though it doesn't look like the project has survived, and maybe that portends ill for trying to do the same for GHC...) Cheers, Greg___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
