Re: [GHC] #1380: Safe Haskell
#1380: Safe Haskell -+-- Reporter: igloo |Owner: dterei Type: feature request | Status: new Priority: normal|Milestone: _|_ Component: Compiler | Version: 7.1 Keywords:| Testcase: Blockedby:| Difficulty: Unknown Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: Building GHC failed -+-- Changes (by dterei): * failure: None/Unknown = Building GHC failed * version: 6.6.1 = 7.1 * component: None = Compiler Comment: For the latest progress on this, see this [wiki:SafeHaskell wiki page] -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1380#comment:13 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] #1380: Safe Haskell
#1380: Safe Haskell -+-- Reporter: igloo |Owner: dterei Type: feature request | Status: new Priority: normal|Milestone: _|_ Component: Compiler | Version: 7.1 Keywords:| Testcase: Blockedby:| Difficulty: Unknown Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by dterei): * failure: Building GHC failed = None/Unknown -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1380#comment:14 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] #5203: Stack overflow in criterion
#5203: Stack overflow in criterion
-+--
Reporter: rl|Owner: simonpj
Type: bug | Status: new
Priority: normal|Milestone: 7.2.1
Component: Compiler | Version: 7.1
Keywords:| Testcase:
Blockedby:| Difficulty:
Os: MacOS X | Blocking:
Architecture: Unknown/Multiple | Failure: Runtime crash
-+--
Changes (by igloo):
* cc: bos@… (added)
* owner: igloo = simonpj
* priority: highest = normal
Comment:
OK, I don't think this is actually a GHC bug at all.
When it works, we get code like this:
{{{
$wfoldlM_loop_s1u9 =
\ [...] -
case [...] {
[...] -
$wfoldlM_loop_s1u9 [...evaluated things...]
}
}}}
and when it doesn't, we get code like this:
{{{
foldlM_loop_s1uP =
\ [...] -
foldlM_loop_s1uP
(case [...] { [...] - [...] })
}}}
i.e. we are passing a thunk to the recursive call.
The problem, as far as I can see, is simply that
`Criterion.Analysis.classifyOutliers` calls `U.foldl` rather than
`U.foldl'`.
Simon, I'm assigning to you in case you want to take a look at why GHC now
produces different code, but otherwise we can just close the ticket.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5203#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] #5208: Unroll array copy/clone primops in the native and LLVM code generators
#5208: Unroll array copy/clone primops in the native and LLVM code generators -+-- Reporter: tibbe |Owner: Type: feature request | Status: patch Priority: normal|Milestone: Component: Compiler | Version: 7.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by tibbe): * status: new = patch Comment: The attached patch makes the array copy primops use the new memcpy/memmmove/memset `MachOp`s. Please review and apply. Remaining ToDo: Unroll the `MachOp`s in the x86(-64) backend. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5208#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
[GHC] #5244: Reg build broken on powerpc-linux
#5244: Reg build broken on powerpc-linux +--- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.1 |Keywords: Testcase: | Blockedby: Os: Linux|Blocking: Architecture: powerpc | Failure: Building GHC failed +--- Hello, while attempting registerised build on powerpc-linux platform of GHC HEAD as of June 1st 2011, the last commit is: commit 02c4f41730b234728a408bbf29607d0345d2b481 Author: Ian Lynagh ig...@earth.li Date: Wed Jun 1 01:07:01 2011 +0100 Fix a warning in DEBUG code it fails with: inplace/bin/ghc-stage1 -H32m -O-package-name ghc-prim-0.2.0.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist- install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries /ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist- install/build/autogen -Ilibraries/ghc-prim/.-optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -split-objs -package-name ghc-prim -XHaskell98 -XCPP -XMagicHash -XForeignFunctionInterface -XUnliftedFFITypes -XUnboxedTuples -XEmptyDataDecls -XNoImplicitPrelude -O2 -no-user-package-conf -rtsopts -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim /dist-install/build -stubdir libraries/ghc-prim/dist-install/build -hisuf hi -osuf o -hcsuf hc -c libraries/ghc-prim/dist- install/build/GHC/PrimopWrappers.hs -o libraries/ghc-prim/dist- install/build/GHC/PrimopWrappers.o ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.1.20110601 for powerpc-unknown-linux): compiler/nativeGen/PPC/CodeGen.hs:(1050,52)-(1060,43): Non- exhaustive patterns in case Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5244 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] #5208: Unroll array copy/clone primops in the native and LLVM code generators
#5208: Unroll array copy/clone primops in the native and LLVM code generators -+-- Reporter: tibbe |Owner: Type: feature request | Status: patch Priority: normal|Milestone: Component: Compiler | Version: 7.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by tibbe): I've attached a patch that unrolls the primops in the x86 backend, together with a small test. The `0002-Unroll-memcpy-in- the-X86-backend.patch` patch depends on `0001-Use-the-new-memcpy-memmove- memset-MachOps.patch`. Please review. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5208#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
[GHC] #5245: Cmm optimizer: propagate constants across basic block boundaries
#5245: Cmm optimizer: propagate constants across basic block boundaries
-+--
Reporter: tibbe | Owner:
Type: feature request | Status: new
Priority: normal| Component: Compiler
Version: 7.0.3 |Keywords:
Testcase:| Blockedby:
Os: Unknown/Multiple |Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
The new constant propagation pass optimizes
{{{
fn
{
bits64 a, b;
a = 1;
b = a + a;
RET_N(b);
}
}}}
as
{{{
fn(){ []
}
cc: R1 = 2;
jump (I64[Sp + 0]) ();
}
}}}
which is good. However, it fails to propagate the constants across a basic
block boundary. For example, the following code
{{{
fn
{
bits64 a, b;
a = 1;
lbl:
b = a + a;
RET_N(b);
}
}}}
gets optimized as
{{{
n(){ []
}
cd: _cf::I64 = 1;
goto ce;
ce: R1 = _cf::I64 + _cf::I64;
jump (I64[Sp + 0]) ();
}
}}}
To make this work we should ideally work with a better representation of
instructions and their use sites than currently used in `CmmOpt.hs`. For
example, see how simple this optimization pass is to implement in LLVM:
http://llvm.org/viewvc/llvm-
project/llvm/trunk/lib/Transforms/Scalar/ConstantProp.cpp?view=markup
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5245
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] #5244: Reg build broken on powerpc-linux
#5244: Reg build broken on powerpc-linux +--- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.1 |Keywords: Testcase: | Blockedby: Os: Linux|Blocking: Architecture: powerpc | Failure: Building GHC failed +--- Changes (by PHO): * cc: pho@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5244#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] #5245: Cmm optimizer: propagate constants across basic block boundaries
#5245: Cmm optimizer: propagate constants across basic block boundaries -+-- Reporter: tibbe |Owner: Type: feature request | Status: new Priority: normal|Milestone: Component: Compiler | Version: 7.0.3 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by simonpj): * cc: ezyang@… (added) Comment: This should be dead easy on the new codgen path. Let's not over-invest in the path we are about to discard! -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5245#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] #5203: Stack overflow in criterion
#5203: Stack overflow in criterion -+-- Reporter: rl|Owner: simonpj Type: bug | Status: new Priority: normal|Milestone: 7.2.1 Component: Compiler | Version: 7.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: MacOS X | Blocking: Architecture: Unknown/Multiple | Failure: Runtime crash -+-- Comment(by simonpj): Could you let me know how to reproduce the problem? Ie see the offending code with old ghc (wfoldm_loop) and with new GHC (foldm_loop)? Thanks. What is old here? Presumably new is both 7.0.4 and master. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5203#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] #5203: Stack overflow in criterion
#5203: Stack overflow in criterion -+-- Reporter: rl|Owner: simonpj Type: bug | Status: new Priority: normal|Milestone: 7.2.1 Component: Compiler | Version: 7.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: MacOS X | Blocking: Architecture: Unknown/Multiple | Failure: Runtime crash -+-- Comment(by bos): Actually, this space leak does occur intermittently with 7.0.3 - I've seen it myself. I figured it was probably my fault, but hadn't gotten around to diagnosing or fixing it because most runs would complete successfully. I've replaced the use of foldl with foldl' in criterion, and just now released 0.5.0.10. Please let me know if that cures the problem for you. And thank you for CCing me on this bug! Much easier to fix when someone else finds the problem :-) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5203#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] #5208: Unroll array copy/clone primops in the native and LLVM code generators
#5208: Unroll array copy/clone primops in the native and LLVM code generators -+-- Reporter: tibbe |Owner: Type: feature request | Status: patch Priority: normal|Milestone: Component: Compiler | Version: 7.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by dterei): So it looks fine, here are some comments though: '''0002-Unroll-memcpy-in-the-X86-backend.patch''' * '-- TODO: Add movabs instruction and support 64-bit sets.' - Can this be done now rather than later? It doesn't seem like it should take very long. Also I think once you have this done you should be able to unify the go functions of memcpy and memset * By saying add the movabs instruction I assume you want to change the memset function to initially store the value to set into a register and then mov that register into each of the memory slots. With this change you could also have memset handle the case where the value to be set is an expression other than a literal. * Should 'maxInlineSizeThreshold' be shared rather than duplicated? '''0001-Use-the-new-memcpy-memmove-memset-MachOps.patch''' Looks fine but would it be worthwhile handling the alignment number in the 'emitMemmoveCall', 'emitMemcpyCall' and 'emitMemsetCall' functions themselves rather than passing it in as argument? '''0001-Add-test-for-unrolling-memcpy-memset-in-the-x86-back.patch''' I think this testing method works well. I think you should test when the alignment is 8 though as well as 4. Also maybe try to cover a few more cases by using some different sizes and alignments. So create the arrays at size 71 but then test a few times using sizes say 64,65,66,67 and alignments 1,2,4,8. The unroll code is fairly tricky and so we want an extensive test case. I'll be happy to help out with any of these points when I have time. Other than extending the test case though I would be happy pushing it to head as it stands. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5208#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] #5208: Unroll array copy/clone primops in the native and LLVM code generators
#5208: Unroll array copy/clone primops in the native and LLVM code generators -+-- Reporter: tibbe |Owner: Type: feature request | Status: patch Priority: normal|Milestone: Component: Compiler | Version: 7.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by dterei): * cc: dterei (added) Comment: For testing we could also use your new 2 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5208#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] #5176: RTS build failure with gcc-4.6.1
#5176: RTS build failure with gcc-4.6.1 -+-- Reporter: erikd |Owner: Type: bug | Status: new Priority: high |Milestone: 7.2.1 Component: Runtime System| Version: 7.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: Building GHC failed -+-- Comment(by dterei): So I've added a patch that fixes the validation errors. Unfortunately it causes a bug where the stage2 compiler freezes when compiling the utils/ghctags/Main.hs file. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5176#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] #5176: RTS build failure with gcc-4.6.1
#5176: RTS build failure with gcc-4.6.1 -+-- Reporter: erikd |Owner: Type: bug | Status: new Priority: high |Milestone: 7.2.1 Component: Runtime System| Version: 7.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: Building GHC failed -+-- Changes (by dterei): * cc: dterei (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5176#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] #5244: Reg build broken on powerpc-linux
#5244: Reg build broken on powerpc-linux --+- Reporter: kgardas | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler |Version: 7.1 Resolution: wontfix | Keywords: Testcase: | Blockedby: Difficulty: | Os: Linux Blocking: | Architecture: powerpc Failure: Building GHC failed | --+- Changes (by igloo): * status: new = closed * resolution: = wontfix Comment: I've tidied up the file, but I'm pretty sure that that just means you'll now get a panic instead. Unfortunately, we don't have the resources to support the PPC native code generator, but we'll happily apply patches to fix the problem (and provide advice as needed to anyone trying to fix it, where we can). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5244#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
Wiki page about new memcpy/memmove/memset primops need a home
Hi, I intend to write a short wiki page explaining the design and use of the new memcpy/memmove/memset primops we added recently. Where would be a good place to put such a page? Cheers, Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Wiki page about new memcpy/memmove/memset primops need a home
Johan, First, thanks for the new primops! :) While someone else may have a better idea, I would simply suggest creating a wiki page at the top-level namespace of the GHC wiki, and linking to it from the GHC Commentary page. If we look at this page now and go to the 'contributed documentation' section it seems a large portion of the 3rd party written documentation is like this (my plugins page, Iavor's type naturals work, etc): http://hackage.haskell.org/trac/ghc/wiki/Commentary So I'd make a page something like: http://hackage.haskell.org/trac/ghc/wiki/MemcpyPrimops and link to it. If a top-level wiki page isn't to your liking, instead I'd rather suggest you just put it under the 'Commentary' or 'Commentary/Compiler' namespaces, and link the same way. I know that I, as an occasional patch contributor, always check this top-level Commentary page for any random up to date notes on what people might be working on or implementing or what they might need help with. But whatever you do, looking at that page, it seems as if the commentary could stand up for a good spring cleaning... On Wed, Jun 8, 2011 at 4:05 PM, Johan Tibell johan.tib...@gmail.com wrote: Hi, I intend to write a short wiki page explaining the design and use of the new memcpy/memmove/memset primops we added recently. Where would be a good place to put such a page? Cheers, Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Regards, Austin ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Wiki page about new memcpy/memmove/memset primops need a home
I would suggest it be put under the Commentary/Compiler. http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler Just add it as a top level bullet point for now, maybe after 'Wired-in and known-key things'. Also you should update the Cmm language page: http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/CmmType#OperatorsandPrimitiveOperations Include a small update to the page and link to the main page on the new prim ops. Cheers, David On 8 June 2011 14:05, Johan Tibell johan.tib...@gmail.com wrote: Hi, I intend to write a short wiki page explaining the design and use of the new memcpy/memmove/memset primops we added recently. Where would be a good place to put such a page? Cheers, Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] Final call for papers: 8th CHR workshop
Apologies if you receive multiple copies Call for Papers Eighth International Workshop on Constraint Handling Rules CHR 2011 September 9, 2011 Cairo, Egypt Co-located with the Second CHR Summer School http://met.guc.edu.eg/events/chr2011/ws.html Introduction The Constraint Handling Rules (CHR) language has become a major declarative specification formalism and implementation language for constraint reasoning algorithms and applications. Algorithms are often specified using inference rules, rewrite rules, sequents, proof rules or logical axioms that can be directly written in CHR. Its clean semantics facilitates program design, analysis and transformation. See the CHR website (http://dtai.cs.kuleuven.be/CHR/) for more information. The aim of the CHR workshop series is to stimulate and promote international research and collaboration on topics related to the Constraint Handling Rules language. The workshop is a lively, friendly forum for presenting and discussing new results, interesting applications, and work in progress. Previous CHR workshops were organized in 2004 in Ulm (Germany), in 2005 in Sitges (Spain) at ICLP, in 2006 in Venice (Italy) at ICALP, in 2007 in Porto (Portgual) at ICLP, in 2008 in Hagenberg (Austria) at RTA, in 2009 in Pasadena (California, US) at ICLP and in 2010 in Edinburgh (Scotland) at ICLP. The workshop proceedings will be published as a technical report. Topics of Interest -- The workshop calls for full papers and short papers describing ongoing work on any aspect of CHR and related approaches. The following topics are relevant (this list is non-exhaustive): - (Logical) Algorithms - Applications - Comparisons with Related Approaches - Constraint Solvers - Critical Assessment - Expressivity and Complexity - Implementations and Optimization - Language Extensions (Types, Modules, ...) - Program Analysis - Program Transformation and Generation - Programming Environments (Debugging) - Programming Pearls - Programming Tools - Retractable Constraints - Semantics - System Descriptions Important Dates --- * Paper Registration (Abstract): June 14, 2011 * Paper Submission: June 21, 2011 * Notification of Authors:July 21, 2011 * Final version due: August 16, 2011 * Workshop date: September 9, 2011 Submission Information -- All papers must describe original, previously unpublished research, and must not simultaneously be submitted for publication elsewhere. They must be written in English. There are four submission categories: 1. technical papers for describing technically sound, innovative ideas that can advance the state of the art of logic programming; 2. application papers, where the emphasis will be on their impact on the application domain; 3. system and tool papers, where the emphasis will be on the novelty, practicality, usability and general availability of the systems and tools described; 4. technical communications, aimed at describing recent developments, new projects, and other materials that are not ready for main publication as standard papers. Technical papers, application papers, and system and tool papers must not exceed 15 pages including bibliography. The limit for technical communications is 10 pages. The authors are encouraged to submit their papers in Springer LNCS format. General information about the Springer LNCS series and the LNCS authors' instructions are available at the Springer LNCS/LNAI home page (http://www.springeronline.com/lncs/). Submissions can be made via the Easychair submission system, available at http://www.easychair.org/conferences/?conf=chr2011. Accepted papers will be published in a technical report. Organization Program Committee: * Slim Abdennadher, German University in Cairo, Egypt * Henning Christiansen, Roskilde University, Denmark * Francois Fages, INRIA Rocquencourt, France * Thom Fruehwirth, Universitaet Ulm, Germany * Maurizio Gabbrielli, Universita di Bologna, Italy * Remy Haemmerle, Universidad Politecnica de Madrid, Spain * Eric Monfroy, Universite de Nantes, France * Paolo Pilozzi, K.U.Leuven, Belgium * Jon Sneyers, K.U.Leuven, Belgium (chair) * Peter J. Stuckey, NICTA Victoria Laboratory, Australia * Armin Wolf, Fraunhofer FIRST, Germany
[Haskell] Parallel GHC project: new opportunity for an organisation to participate
GHC HQ and Well-Typed are pleased to announce a new opportunity for an organisation to take part in the Parallel GHC Project. The project started in November 2010 with four industrial partners, and consulting and engineering support from Well-Typed. Each organisation is working on its own particular project making use of parallel Haskell. The overall goal is to demonstrate successful use of parallel Haskell and along the way to apply engineering effort to any problems with the tools that the partner organisations might run into. We have capacity to support another partner organisation for the remaining duration of the project (at least another 12 months). Organisations do not need to contribute financially but should be prepared to make a significant commitment of their own time. Familiarity with Haskell would be helpful, but Haskell expertise is not needed. Partner organisations' choice of projects is similarly open-ended and could be based on anything from pre-existing code bases to green field endeavours. We would welcome organisations interested in pure parallelism, concurrency and/or distributed Haskell. Presently, two of our partner organisations are using mainly pure parallelism and two are using concurrency. What would be especially interesting for us is to diversify this mix further by working with an organisation interested in making use of of distributed Haskell, in particular the work highlighted in the recent paper Haskell for the Cloud [1]. To help give an idea what participating in the Parallel GHC Project is like, here is what some of what our current partner organisations have to say: The Parallel GHC Project has enabled us to make steady progress towards our goals. Well-typed has provided support in the form of best practice recommendations, general engagement with the project, and directly coding up key components. I have been getting lots of help from Well-Typed, and enjoy our weekly meetings. -- Finlay Thompson, Dragonfly My organization is now trying to implement highly concurrent Web servers. After GHC 7 was released we faced several critical bugs in the new IO manager and one guy at Well-Typed kindly fixed all the bugs. This has been a big benefit for our organization. Another benefit is feedback/suggestions from Well-Typed. Well-Typed and our organization have meetings every other week and we report progress to each other. During the discussions, we can set the right direction to go in. -- Kazu Yamamoto, IIJ Innovation Institute Inc. Well-Typed is coordinating the project, working directly with the participating organisations and the Simons at GHC HQ. If you think your organisation may be interested then get in touch with me via i...@well-typed.com [1] http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel/remote.pdf -- Duncan Coutts, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Haskell Weekly News: Issue 185
Welcome to issue 180 of the HWN, a newsletter covering developments in the Haskell community. This release covers the week of May 29 to Jun 4, 2011. You can find the HTML version at: http://goo.gl/Tm1Qu Announcements Sebastian Fischer wrote in to inform us of of a student internship for parallel Haskell at the National Institute of Informatics in Tokyo. The internship is for up to three months, between July and September 2011. http://goo.gl/xHjkn EIJIRO Sumii reminded us that the ICFP Programming Contest 2011 will be starting on June 17. http://goo.gl/eumwm Quotes of the Week * Tom Murphy: Great! New I really can say Come on! It's fun! I can write foldr with foldl! * Cale: C++, Y U SO UGLY? * xplat: nae, that'd be 'arr, my small example ain't half near as yellow as a lily-livered spaniard! scupper me wi' a cutlass, arr.' * Cale: rnf accidentally the entire data structure Top Reddit Stories * Haskell and parallelism in the Economist Domain: economist.com, Score: 66, Comments: 5 On Reddit: http://goo.gl/rBnc1 Original: http://goo.gl/vFtGY * I have the world's coolest hoodie (X-post from r/programming) Domain: imgur.com, Score: 28, Comments: 15 On Reddit: http://goo.gl/bk5wt Original: http://goo.gl/CT3fb * An OpenGL in Haskell anecdote which illustrates the obvious, HOpenGL is low level and imperative. Domain: haskell.org, Score: 27, Comments: 24 On Reddit: http://goo.gl/QtDNy Original: http://goo.gl/LUoL9 * Yesod for non-Haskellers (also, for Haskellers) Domain: yesodweb.com, Score: 27, Comments: 2 On Reddit: http://goo.gl/ekOQJ Original: http://goo.gl/UCyIv * Fast forwarding lrand48() Domain: blog.sigfpe.com, Score: 24, Comments: 0 On Reddit: http://goo.gl/Ki0in Original: http://goo.gl/5ICat * Silk (Haskell, semantic web start up) is hiring in Amsterdam Domain: news.ycombinator.com, Score: 24, Comments: 0 On Reddit: http://goo.gl/GUFVP Original: http://goo.gl/j8fRW * Nikki and the Robots 0.3 is out Domain: joyridelabs.de, Score: 23, Comments: 7 On Reddit: http://goo.gl/w3yrF Original: http://goo.gl/sJdwj * Introducing the Yesod Wiki Domain: yesodweb.com, Score: 19, Comments: 0 On Reddit: http://goo.gl/4TStP Original: http://goo.gl/noMVO * Communicating Haskell Processes: The Long And The Short Of It Domain: chplib.wordpress.com, Score: 19, Comments: 0 On Reddit: http://goo.gl/mC8cw Original: http://goo.gl/hHHoH * What libraries from scientific computing have yet to be written? Domain: self.haskell, Score: 17, Comments: 23 On Reddit: http://goo.gl/QXwyA Top StackOverflow Questions * A proof is a program; the formula it proves is a type for the program [migrated] votes: 17, answers: 0 Read on SO: http://goo.gl/LfzPM * Writing foldl using foldr votes: 16, answers: 2 Read on SO: http://goo.gl/O7I0Z * Binary Serialization for Lists of Undefined Length in Haskell votes: 13, answers: 1 Read on SO: http://goo.gl/pZkyI * From C ++ to Haskell Classes and States votes: 12, answers: 2 Read on SO: http://goo.gl/yYt9R * Why does Haskell force data constructor's first letter to be upper case? votes: 11, answers: 3 Read on SO: http://goo.gl/dnGIl * Why is such a function definition not allowed in haskell ? votes: 10, answers: 5 Read on SO: http://goo.gl/0RoHY About the Haskell Weekly News To help create new editions of this newsletter, please send stories to dstc...@gmail.com. Until next time, Daniel Santa Cruz ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] SIGPLAN Programming Languages Software Award
On Jun 7, 2011, at 7:53 PM, Isaac Potoczny-Jones wrote: For 2011, the winners of the award are Simon Peyton Jones and Simon Marlow of Microsoft Research, Cambridge, for GHC Congratulations :)! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] SIGPLAN Programming Languages Software Award
many of the ideas of purely functional, typeful programming have been carried into newer languages and language features. including C#, F#, Java Generics, LINQ, Perl 6, Python, and Visual Basic 9.0. typeful programming and Python in the same sentence? ^^ More seriously, the influence of Haskell over F# (and even Python) is undoubted, but do you really think Haskell influenced Java Generics? (IMHO they were more inspired from C++ templates) (That is a question, not an assertion). 2011/6/7 Isaac Potoczny-Jones ijo...@galois.com I'm pleased to be able to relay the following announcement from ACM SIGPLAN: The SIGPLAN Programming Languages Software Award is awarded to an institution or individual(s) to recognize the development a software system that has had a significant impact on programming language research, implementations, and tools. The impact may be reflected in the wide-spread adoption of the system or its underlying concepts by the wider programming language community either in research projects, in the open-source community, or commercially. The award includes a prize of $2,500. For 2011, the winners of the award are Simon Peyton Jones and Simon Marlow of Microsoft Research, Cambridge, for GHC The award winners are donating the entirety of the prize money to haskell.org. Citation: Simon Peyton Jones and Simon Marlow receive the SIGPLAN Software Award as the authors of the Glasgow Haskell Compiler (GHC), which is the preeminent lazy functional programming system for industry, teaching, and research. GHC has not only provided a language implementation, but also established the whole paradigm of lazy functional programming and formed the foundation of a large and enthusiastic user community. GHC's flexibility has supported experimental research on programming language design in areas as diverse as monads, generalized algebraic data types, rank-N polymorphism, and software transactional memory. Indeed, a large share of the research on lazy functional programming in the last 5–10 years has been carried out with GHC. Simultaneously, GHC's reliability and efficiency has encouraged commercial adoption, in the financial sector in institutions like Credit Suisse and Standard Chartered Bank, and for high assurance software in companies like Amgen, Eaton, and Galois. A measure of GHC's influence is the way that many of the ideas of purely functional, typeful programming have been carried into newer languages and language features. including C#, F#, Java Generics, LINQ, Perl 6, Python, and Visual Basic 9.0. Peyton Jones and Marlow have been visionary in the way that they have transitioned research into practice. They have been role models and leaders in creating the large and diverse Haskell community, and have made GHC an industrial-strength platform for commercial development as well as for research. Links: http://www.sigplan.org/award-software.htm http://corp.galois.com/blog/2011/6/7/sigplan-programming-languages-software-award.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comment Syntax
Guy guytsalmave...@yahoo.com writes: Out of interest, is there any other language where the comment delimiter is invalid if immediately followed by a symbol? Another quaint example, in shell scripts, lines starting with '#' are comments, except when the first line starts with '#!'. Admittedly, this is still a comment as far as the shell is concerned, it's the OS that is intercepting the comment's contents and acting on it. -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] Comment Syntax
On 8 June 2011 18:13, Ketil Malde ke...@malde.org wrote: Guy guytsalmave...@yahoo.com writes: Out of interest, is there any other language where the comment delimiter is invalid if immediately followed by a symbol? Another quaint example, in shell scripts, lines starting with '#' are comments, except when the first line starts with '#!'. Admittedly, this is still a comment as far as the shell is concerned, it's the OS that is intercepting the comment's contents and acting on it. And #! in the first line is also treated as a comment in Haskell code so that you can run it as a script. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comment Syntax
Ivan Lazar Miljenovic ivan.miljeno...@gmail.com writes: And #! in the first line is also treated as a comment in Haskell code so that you can run it as a script. True. But then you're allowed to add arbitrary symbols after it, I think. At least, GHC seems happy about it. -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] SIGPLAN Programming Languages Software Award
More seriously, the influence of Haskell over F# (and even Python) is undoubted, but do you really think Haskell influenced Java Generics? (IMHO they were more inspired from C++ templates) (That is a question, not an assertion). Phil Wadler had a hand in designing both Haskell and Java Generics I believe. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] SIGPLAN Programming Languages Software Award
Well deserved. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Twidge and identi.ca
Does twidge still support identi.ca? I was able to auth, but after that every single command returns 'twidge: user error (Bad response: 404)'. The commands work for twitter. -- Mats Rauhala MasseR pgpU14ltgvUZK.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Local Haskell Meeting (Stammtisch) Leipzig, Germany, June 27
Informal Haskell Stammtisch on Monday, June 27, 8 p.m., at Cafe Grundmann, Leipzig, Germany. http://www.cafe-grundmann.de/ Pre-registration (by email to me) is appreciated. Please bring ideas for our local Haskell Workshop (planned for end of September). See you - J.W. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: remove Stability from haddock documentation on hackage
On 6/7/11, James Cook mo...@deepbondi.net wrote: [...] The name of the field could be better, though. On first exposure, people tend to think stability: experimental or stability: unstable means the package is likely to crash (For those who don't know, it means the API is likely to change in future releases). What is the way to indicate actual code stability? Some packages on Hackage definitely have broken parts. Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: remove Stability from haddock documentation on hackage
On Jun 8, 2011, at 11:08 AM, Tom Murphy wrote: On 6/7/11, James Cook mo...@deepbondi.net wrote: [...] The name of the field could be better, though. On first exposure, people tend to think stability: experimental or stability: unstable means the package is likely to crash (For those who don't know, it means the API is likely to change in future releases). What is the way to indicate actual code stability? Some packages on Hackage definitely have broken parts. Since all cabal fields are set before uploading that would imply someone is uploading something they know to be broken, which doesn't seem right. But assuming some legitimate reason exists, WARNING or DEPRECATED pragmas on the bad stuff would probably be a good way to go. -- James ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: remove Stability from haddock documentation on hackage
Chris Smith cdsm...@gmail.com wrote: I got asked a question today about why Control.Applicative is labeled as experimental on Hackage. Perhaps that field is something of a failed experiment, and it remaining there is likely to confuse people. Just a thought... not sure of the best place to mention it. I don't think that's a proper rationale to remove the feature, because every feature can be used in a wrong way. It appears to be quite natural to me that people forget to update their module headers, but there are also programmers, who manage their comments very responsibly, including the module header. Personally I used to use the feature, but at some point I abandoned it, because although I always update the comments associated with definitions, I tend to forget the module's head comment. Also since my modules are mostly very related, the stability is a package property for me rather than a module property. If you are serious about removing failed experiments, there are more important places to get started at. ;) Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife = sex) http://ertes.de/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Does this library already exist? template haskell + generate/compile C code + dlopen
The Nikola GPU programming system has a very neat, flexible approach to how you compile the EDSL-generated code. You can do it dynamically, calling nvcc at runtime, OR it can play a trick where it calls nvcc at compile time (via template haskell) and caches the result in a string literal within the TH-generated Haskell code. That is a pretty cool trick IMHO. Moreover, we can do that with any tool that generates C code or native code, as follows: At compile time, via Template Haskell: 1. call tool which creates C code 2. create temp files and call C compiler 3. load resulting object file as a bytestring and store it as a string constant Then at runtime: 1. put bytestring back into a file 2. call dlopen 3. call dlsym, get FunPtr, voila! Anyway, I was going to put together a simple library that encapsulates the above steps. Such a library could be used, for example, in making this stencil compiler project http://people.csail.mit.edu/yuantang/ available to Haskell users as well as C++ users. (The compiler is written in Haskell already anyway!) But first I thought I'd ask if this already exists. Also, is there a better way to do it? In particular, is there any way to get static linking to work, rather than the silliness with strings, tempfiles, and dlopen. Thanks, -Ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskellwiki slow/unresponsive
+++ Gwern Branwen [Jun 06 11 17:47 ]: On Mon, Jun 6, 2011 at 4:45 PM, Greg Weber g...@gregweber.info wrote: Gitit uses darcs or git to store data, but through the command line interfaces. Unfortunately to my knowledge darcs does not expose a library interface. Gitit could be made faster and more secure by interfacing with libgit2. Darcs does export a library and pretty much has ever since I first cabalized it; see http://hackage.haskell.org/package/darcs for the module listings. It's not a very useful API, however. I don't know how to use it, and John doesn't know how to use libgit2, I suspect. I haven't had much time to work on gitit + filestore lately, and I'll have even less in the future. I'd rather focus my programming time on pandoc. So I'd be game if someone wanted to take the project in a new direction. Looks as if there are already Haskell bindings to libgit2: http://hackage.haskell.org/packages/archive/hlibgit2 A first step might be rewriting filestore to use libgit and libdarcs instead of shelling out to the programs. It also might be nice to create a filestore instance that uses a persistent in-memory datastore like acid-state; this would be very fast, and appropriate for a wiki (like hawiki) with mostly textual content. I would also not object to a rewrite using Yesod -- the type-safe URLs and the support for subsites would both be really useful in gitit. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Type Constraints on Data Constructors
{- continuing discussion from beginners@ -}
I have code such as
class Foo f where
foo :: a - f a
data Bar f a = Foo f = Bar {bar :: f a}
instance Foo (Bar f) where
foo a = Bar $ foo a
GHC insists that I put Foo f = on the instance declaration, even though the
constructor for Bar implies this.
Is there any reason why GHC cannot infer this constraint from the Bar constructor? One issue raised in the beginners
thread is that
undefined :: Bar f a
is not Foo f, but as undefined cannot be evaluated, this would not appear to be
a problem.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Parallel GHC project: new opportunity for an organisation to participate
GHC HQ and Well-Typed are pleased to announce a new opportunity for an organisation to take part in the Parallel GHC Project. The project started in November 2010 with four industrial partners, and consulting and engineering support from Well-Typed. Each organisation is working on its own particular project making use of parallel Haskell. The overall goal is to demonstrate successful use of parallel Haskell and along the way to apply engineering effort to any problems with the tools that the partner organisations might run into. We have capacity to support another partner organisation for the remaining duration of the project (at least another 12 months). Organisations do not need to contribute financially but should be prepared to make a significant commitment of their own time. Familiarity with Haskell would be helpful, but Haskell expertise is not needed. Partner organisations' choice of projects is similarly open-ended and could be based on anything from pre-existing code bases to green field endeavours. We would welcome organisations interested in pure parallelism, concurrency and/or distributed Haskell. Presently, two of our partner organisations are using mainly pure parallelism and two are using concurrency. What would be especially interesting for us is to diversify this mix further by working with an organisation interested in making use of of distributed Haskell, in particular the work highlighted in the recent paper Haskell for the Cloud [1]. To help give an idea what participating in the Parallel GHC Project is like, here is what some of what our current partner organisations have to say: The Parallel GHC Project has enabled us to make steady progress towards our goals. Well-typed has provided support in the form of best practice recommendations, general engagement with the project, and directly coding up key components. I have been getting lots of help from Well-Typed, and enjoy our weekly meetings. -- Finlay Thompson, Dragonfly My organization is now trying to implement highly concurrent Web servers. After GHC 7 was released we faced several critical bugs in the new IO manager and one guy at Well-Typed kindly fixed all the bugs. This has been a big benefit for our organization. Another benefit is feedback/suggestions from Well-Typed. Well-Typed and our organization have meetings every other week and we report progress to each other. During the discussions, we can set the right direction to go in. -- Kazu Yamamoto, IIJ Innovation Institute Inc. Well-Typed is coordinating the project, working directly with the participating organisations and the Simons at GHC HQ. If you think your organisation may be interested then get in touch with me via i...@well-typed.com [1] http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel/remote.pdf -- Duncan Coutts, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type Constraints on Data Constructors
data Bar f a = Foo f = Bar {bar :: f a}
The class context on the data constructor buys you nothing extra in terms of
expressivity in the language. All it does is force you to repeat the context
on every function that uses the datatype. For this reason, the language
committee has decided that the feature will be removed in the next revision of
Haskell.
Regards,
Malcolm
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type Constraints on Data Constructors
On Wed, Jun 8, 2011 at 3:15 PM, Malcolm Wallace malcolm.wall...@me.com wrote:
data Bar f a = Foo f = Bar {bar :: f a}
The class context on the data constructor buys you nothing extra in terms of
expressivity in the language. All it does is force you to repeat the context
on every function that uses the datatype. For this reason, the language
committee has decided that the feature will be removed in the next revision
of Haskell.
You're thinking of a context on the type constructor, i.e.,
data Foo f = Bar f a = Bar { bar :: f a }
The reason the original code does not work is that the constructor
only adds Foo f to the class context during pattern matching. So, for
example, this works:
baz :: Bar f a - a - f a -- n.b., no Foo context
baz (Bar _) = foo
But the code in the original post is trying to create a value of type
Bar f a, so the context is needed.
--
Dave Menendez d...@zednenem.com
http://www.eyrie.org/~zednenem/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: mecha-0.1.0
Mecha [1,2] is a constructive solid geometry (CSG) modeling language embedded in Haskell. This release adds OpenSCAD [3] as a backend target. OpenSCAD is a solid modeling DSL and a viewer. OpenSCAD uses OpenCSG [4] for rendering, which directly renders CSG objects with OpenGL without the need for complex mesh generation. (Thanks Corey, for pointing me to OpenCSG.) Here is a screenshot of OpenSCAD rendering a Mecha solid: http://tomahawkins.org/index.html#Mecha Here is the Mecha source: https://github.com/tomahawkins/mecha/blob/master/Language/Mecha/Examples/CSG.hs -Tom [1] http://hackage.haskell.org/package/mecha [2] https://github.com/tomahawkins/mecha [2] http://www.openscad.org/ [3] http://opencsg.org/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] SIGPLAN Programming Languages Software Award
On Wed, Jun 8, 2011 at 2:00 AM, Malcolm Wallace malcolm.wall...@me.comwrote: More seriously, the influence of Haskell over F# (and even Python) is undoubted, but do you really think Haskell influenced Java Generics? (IMHO they were more inspired from C++ templates) (That is a question, not an assertion). Phil Wadler had a hand in designing both Haskell and Java Generics I believe. As far as I understand, Java/C# Generics and C++ templates are merely keywords around what we Haskellers call parametric polymorphism. In other words, our type language is rich enough to express types like: stringConcat :: [String] - String and concat :: Monoid a = [a] - a using the same typing language, whereas the C-style languages require annotations. (You can probably guess which I prefer. I don't need keywords to tell me what the code describes, then the code describes it so clearly) I can't find any literature that specifically credits functional languages for the feature, but Bjarne Stoustrup himself acknowledges that functional programmers would tend to find template metaprogramming easier than others. He was probably aware of functional implementations (Haskell? Miranda? ML?) when he said that. I don't see the connection between Haskell's typeful programming and Python. List comprehensions are set-builder-notation-like syntactic sugar for lists. I didn't use them in Python and I don't use them in Haskell. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type Constraints on Data Constructors
Hello,
you might be thinking of this type?
{-# LANGUAGE Rank2Types #-}
class Foo f where
foo :: a - f a
data Baz f a = Baz (forall f. Foo f = f a)
instance Foo (Baz f) where
foo a = Baz (foo a)
Maybe the difference between Bar and Baz ist best explained by writing it with
an explicit class dictionary for Foo:
{-# LANGUAGE Rank2Types #-}
data FooDict f = FooDict {
foo :: forall a. a - f a
}
data Bar f a = Bar (FooDict f) (f a)
data Baz f a = Baz (FooDict f - f a)
fooDict_Baz :: FooDict (Baz f)
fooDict_Baz = FooDict (\a - Baz (\d - foo d a))
-- fooDict_Bar :: FooDict (Bar f)
-- fooDict_Bar = FooDict (\a - Bar ? ?)
-- Doesn't work - you'd have to create a 'FooDict f' and a 'f a' out of just
an 'a'
Cheers,
Daniel
On 2011-June-08 Wednesday 20:45:56 Guy wrote:
{- continuing discussion from beginners@ -}
I have code such as
class Foo f where
foo :: a - f a
data Bar f a = Foo f = Bar {bar :: f a}
instance Foo (Bar f) where
foo a = Bar $ foo a
GHC insists that I put Foo f = on the instance declaration, even though
the constructor for Bar implies this.
Is there any reason why GHC cannot infer this constraint from the Bar
constructor? One issue raised in the beginners thread is that
undefined :: Bar f a
is not Foo f, but as undefined cannot be evaluated, this would not appear
to be a problem.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell Weekly News: Issue 185
Welcome to issue 180 of the HWN, a newsletter covering developments in the Haskell community. This release covers the week of May 29 to Jun 4, 2011. You can find the HTML version at: http://goo.gl/Tm1Qu Announcements Sebastian Fischer wrote in to inform us of of a student internship for parallel Haskell at the National Institute of Informatics in Tokyo. The internship is for up to three months, between July and September 2011. http://goo.gl/xHjkn EIJIRO Sumii reminded us that the ICFP Programming Contest 2011 will be starting on June 17. http://goo.gl/eumwm Quotes of the Week * Tom Murphy: Great! New I really can say Come on! It's fun! I can write foldr with foldl! * Cale: C++, Y U SO UGLY? * xplat: nae, that'd be 'arr, my small example ain't half near as yellow as a lily-livered spaniard! scupper me wi' a cutlass, arr.' * Cale: rnf accidentally the entire data structure Top Reddit Stories * Haskell and parallelism in the Economist Domain: economist.com, Score: 66, Comments: 5 On Reddit: http://goo.gl/rBnc1 Original: http://goo.gl/vFtGY * I have the world's coolest hoodie (X-post from r/programming) Domain: imgur.com, Score: 28, Comments: 15 On Reddit: http://goo.gl/bk5wt Original: http://goo.gl/CT3fb * An OpenGL in Haskell anecdote which illustrates the obvious, HOpenGL is low level and imperative. Domain: haskell.org, Score: 27, Comments: 24 On Reddit: http://goo.gl/QtDNy Original: http://goo.gl/LUoL9 * Yesod for non-Haskellers (also, for Haskellers) Domain: yesodweb.com, Score: 27, Comments: 2 On Reddit: http://goo.gl/ekOQJ Original: http://goo.gl/UCyIv * Fast forwarding lrand48() Domain: blog.sigfpe.com, Score: 24, Comments: 0 On Reddit: http://goo.gl/Ki0in Original: http://goo.gl/5ICat * Silk (Haskell, semantic web start up) is hiring in Amsterdam Domain: news.ycombinator.com, Score: 24, Comments: 0 On Reddit: http://goo.gl/GUFVP Original: http://goo.gl/j8fRW * Nikki and the Robots 0.3 is out Domain: joyridelabs.de, Score: 23, Comments: 7 On Reddit: http://goo.gl/w3yrF Original: http://goo.gl/sJdwj * Introducing the Yesod Wiki Domain: yesodweb.com, Score: 19, Comments: 0 On Reddit: http://goo.gl/4TStP Original: http://goo.gl/noMVO * Communicating Haskell Processes: The Long And The Short Of It Domain: chplib.wordpress.com, Score: 19, Comments: 0 On Reddit: http://goo.gl/mC8cw Original: http://goo.gl/hHHoH * What libraries from scientific computing have yet to be written? Domain: self.haskell, Score: 17, Comments: 23 On Reddit: http://goo.gl/QXwyA Top StackOverflow Questions * A proof is a program; the formula it proves is a type for the program [migrated] votes: 17, answers: 0 Read on SO: http://goo.gl/LfzPM * Writing foldl using foldr votes: 16, answers: 2 Read on SO: http://goo.gl/O7I0Z * Binary Serialization for Lists of Undefined Length in Haskell votes: 13, answers: 1 Read on SO: http://goo.gl/pZkyI * From C ++ to Haskell Classes and States votes: 12, answers: 2 Read on SO: http://goo.gl/yYt9R * Why does Haskell force data constructor's first letter to be upper case? votes: 11, answers: 3 Read on SO: http://goo.gl/dnGIl * Why is such a function definition not allowed in haskell ? votes: 10, answers: 5 Read on SO: http://goo.gl/0RoHY About the Haskell Weekly News To help create new editions of this newsletter, please send stories to dstc...@gmail.com. Until next time, Daniel Santa Cruz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 93, Issue 58
An earlier note on students reactions to the imperative style forced on them by some Haskell libraries (do ...) is interesting, and seems similar to an observation in a project I was developing for students; making a version of a simple lab from previous SML assignment. It uses a dictionary to do some statistics for a text analysis, but since the dictionary is read at a leaf node of the analysis algorithm, that function must be IO(), and thus the analysis using it also, ... etc. all the way up to the top. So the implication of the rules: 1) all IO must start from the top level, and there is only one IO 2) you cannot extract anything from an IO Seems to be that the whole program structure becomes a series of do... blocks, which is basically a sequential imperative looking style. The general advice of Strive to keep as much of the program pure as possible thus seems difficult. An option I suppose would be to read the dictionary at the top level, and then pass it all the way down to the analysis routine that uses it, but that exposes the details of how the analysis is done, and couples the top and bottom levels of the previously modular functions. While this is all logical and understandable, it is quite different than how I did this in SML; where I could encapsulate the IO in the analysis function. It was a local secret of the analysis what data it needed, and where it came from. Note that (of course...) if the dictionary was static and an internal data structure, then this would all go away. It is interesting to me (and curious at first) that one could not somehow treat a constant data definition file resource in a more encapsulated manner, and not have it ripple all the way up through the program because it was impure once converted to an external definition (=IO). My first impulse was to read the dictionary in a do... and then try to extract it and go merrily on, but that won't work - by design of course! Considering something like a properties file in Java, it thus seems like every part of a program wanting to use these, must either be passed some global definition, or become a leaf on a hierarchy of do.. blocks if it does its own IO to read the properties. Anyway, while the more precise treatment and isolation of IO in Haskell seems valuable, it also seems to have a notable impact on the lack of ability to encapsulate and decouple parts of the program, and keep things pure between them. I suppose this is because that by definition, once you have touched IO at any leaf of a program, the whole thing is impure all the way up the functional tree. I rather had the feeling expressed by Robert Harper: Once you're in the IO monad, you're stuck there forever, and are reduced to Algol-style imperative programming. (http://existentialtype.wordpress.com/2011/05/01/of-course-ml-has-monads/) Just an observation, in case I am missing something - being fairly new to Haskell. I suppose this is just an adjustment to proper treatment of the impurity of IO, but the effect on program structure was not good. :-) --- -Original Message- Subject: Haskell-Cafe Digest, Vol 93, Issue 58 Now, I have a personal pedagogical comment. A few months ago I gave to some 30 students an The results? A true DISASTER! The OpenGL bindings in Haskell are hardly functional. You make us sweat with generic functional patterns, laziness, exquisite typing, non-determinism monad, parsing tools, etc., and then you throw us into this ugly imperativism ! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 93, Issue 58
An option I suppose would be to read the dictionary at the top level, and then pass it all the way down to the analysis routine that uses it, but that exposes the details of how the analysis is done, and couples the top and bottom levels of the previously modular functions. It would seem to me that having the analysis routine do the I/O itself is more coupling than designing it to be datasource-agnostic! I'd expect it to be much neater to thread the data through the various functions comprising the analysing functions, perhaps monadically, as a part of its design; and then to feed the data in at a single entry point. Thus the entire analysis is pure. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 93, Issue 58
Yes, agree. Thanks. But still this adds a coupling that I did not need in the SML versions. And in this case, the analysis is word oriented, so the algorithm is intrinsically tied to a dictionary. --- Gregory Guthrie -- -Original Message- From: Arlen Christian Mart Cuss [mailto:cel...@sairyx.org] Sent: Wednesday, June 08, 2011 10:50 PM To: Gregory Guthrie Cc: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 93, Issue 58 An option I suppose would be to read the dictionary at the top level, and then pass it all the way down to the analysis routine that uses it, but that exposes the details of how the analysis is done, and couples the top and bottom levels of the previously modular functions. It would seem to me that having the analysis routine do the I/O itself is more coupling than designing it to be datasource-agnostic! I'd expect it to be much neater to thread the data through the various functions comprising the analysing functions, perhaps monadically, as a part of its design; and then to feed the data in at a single entry point. Thus the entire analysis is pure. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 93, Issue 58
But still this adds a coupling that I did not need in the SML versions. I suppose you could call it a coupling -- but comparing to the MLs, I'd prefer be forced to specify and thread my inputs and outputs (mostly hidden by monads) than to be hit by weak/imperative type variables in other cases. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 93, Issue 58
On Wed, Jun 8, 2011 at 8:17 PM, Gregory Guthrie guth...@mum.edu wrote: An earlier note on students reactions to the imperative style forced on them by some Haskell libraries (do ...) is interesting, and seems similar to an observation in a project I was developing for students; making a version of a simple lab from previous SML assignment. It uses a dictionary to do some statistics for a text analysis, but since the dictionary is read at a leaf node of the analysis algorithm, that function must be IO(), and thus the analysis using it also, ... etc. all the way up to the top. So the implication of the rules: 1) all IO must start from the top level, and there is only one IO 2) you cannot extract anything from an IO Seems to be that the whole program structure becomes a series of do... blocks, which is basically a sequential imperative looking style. The general advice of Strive to keep as much of the program pure as possible thus seems difficult. You're right, in some ways. But it is not difficult to stay out of IO. Just don't use the (IO a) type if you don't need to do input and output. I strongly suspect that you are starting your program writing process by writing IO actions, which naturally leads to writing a tree of IO actions. Start by writing data types and transformation functions instead. Every program does three things: take some kind of input, apply a transformation, and yield some kind of output. Strive to define datatypes that capture the program's logic. For example, enumerate your cases in an abstract data type. In this way, you can move the program logic into the pure fragment of the language, as opposed to using explicit if-then-else's in the IO monad. An option I suppose would be to read the dictionary at the top level, and then pass it all the way down to the analysis routine that uses it, but that exposes the details of how the analysis is done, and couples the top and bottom levels of the previously modular functions. While this is all logical and understandable, it is quite different than how I did this in SML; where I could encapsulate the IO in the analysis function. It was a local secret of the analysis what data it needed, and where it came from. Note that (of course...) if the dictionary was static and an internal data structure, then this would all go away. It is interesting to me (and curious at first) that one could not somehow treat a constant data definition file resource in a more encapsulated manner, and not have it ripple all the way up through the program because it was impure once converted to an external definition (=IO). My first impulse was to read the dictionary in a do... and then try to extract it and go merrily on, but that won't work - by design of course! I don't know how ML handles IO, but Haskell is a lazy language. In order for a value to be computed, some other value has to request it. And programs usually have a single entry point -- main :: IO a. So it is going to be the thing that requests computations to be done. On the other hand, it can request a series of IO actions to determine program flow/logic, or it can request pure computations to do the same. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building Haskell Platform natively for 64bit Windows
On Tue, Jun 7, 2011 at 11:32 AM, Nicu Ionita nicu.ion...@acons.at wrote: Yes, I was a little bit unclear, I wanted to say: the generated code does not use the 64 bit instructions (i.e. 1 instruction for .., for example). Of course, it works, but I suppose, much slower then it could (3-4 times, for that part?) Have you checked this by looking at the generated assembly? I generated some assembly from GHC on windows. Here is what it looks ilke: http://hpaste.org/47610 My assembly-fu is not strong enough to tell if it's using 64bit instructions. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building Haskell Platform natively for 64bit Windows
On 06/09/2011 01:47 AM, Jason Dagit wrote: Have you checked this by looking at the generated assembly? I generated some assembly from GHC on windows. Here is what it looks ilke: http://hpaste.org/47610 My assembly-fu is not strong enough to tell if it's using 64bit instructions. It would appear to be 32-bit. (pushl instead of pushq no instances of aligning to 8-byte boundaries) signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
