Re: [GHC] #4359: Implement lambda-case/lambda-if
#4359: Implement lambda-case/lambda-if ---+ Reporter: batterseapower| Owner: Type: feature request | Status: new Priority: normal| Milestone: 7.6.1 Component: Compiler |Version: 7.1 Resolution:| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Comment(by mikhail.vorozhtsov): I started a new [http://www.haskell.org/pipermail/glasgow-haskell- users/2012-July/022506.html thead] on the GHC Users list. Hop in! -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4359#comment:67 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] #7053: Panic with PolyKinds + GADTs
#7053: Panic with PolyKinds + GADTs
--+-
Reporter: dreixel | Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 7.5 | Keywords: PolyKinds
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Testcase:
Blockedby:| Blocking:
Related:|
--+-
This works:
{{{
data TypeRep (a :: k) :: * where
TyApp :: TypeRep a - TypeRep b - TypeRep (a b)
}}}
Whereas this (removing the obvious return kind of the datatype):
{{{
data TypeRep (a :: k) where
TyApp :: TypeRep a - TypeRep b - TypeRep (a b)
}}}
Gives this panic:
{{{
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 7.5 for i386-unknown-linux):
metaTvRef
details unavailable
}}}
(The example is pretty much taken from Weirich, Hsu, and Eisenberg, but I
haven't seen it reported here yet.)
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7053
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] #5909: Segfault with multi-threaded retainer profiling
#5909: Segfault with multi-threaded retainer profiling
---+
Reporter: akio| Owner: simonmar
Type: bug | Status: new
Priority: high| Milestone: 7.4.3
Component: Runtime System | Version: 7.4.1
Keywords: | Os: Linux
Architecture: x86_64 (amd64) | Failure: Runtime crash
Difficulty: Unknown |Testcase:
Blockedby: |Blocking:
Related: |
---+
Comment(by akio):
If I run the program like this, I always get an immediate segfault:
{{{
./segfault +RTS -hrfoo -hc
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5909#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] #7048: Add the ability to statically define a `FunPtr` to a haskell function
#7048: Add the ability to statically define a `FunPtr` to a haskell function -+-- Reporter: pcapriotti| Owner: Type: feature request | Status: new Priority: normal| Milestone: 7.8.1 Component: Compiler | Version: 7.4.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by simonmar): Thanks Iavor. I just skimmed that thread. Your `static_wrapper` idea is indeed similar, but not quite the same. The proposed extension here differs from `static_wrapper` in two ways: * It doesn't have an implicit `StablePtr` argument built-in * It doesn't imply the creation of a C symbol -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7048#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] #7051: Runtime system crash (OS X intel -N greater than 4)
#7051: Runtime system crash (OS X intel -N greater than 4) ---+ Reporter: ndaniels| Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Runtime System | Version: 7.4.1 Keywords: | Os: MacOS X Architecture: x86_64 (amd64) | Failure: Runtime crash Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Changes (by simonmar): * status: new = infoneeded * difficulty: = Unknown Comment: Thanks for the report. Please attach the program that fails, along with any instructions necessary to reproduce the problem. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7051#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] #7052: Numeric types’ Read instances use exponential CPU/memory
#7052: Numeric types’ Read instances use exponential CPU/memory --+- Reporter: andersk | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base |Version: 7.4.2 Resolution: fixed| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: #5688 --+- Changes (by pcapriotti): * status: new = closed * difficulty: = Unknown * resolution: = fixed * related: = #5688 Comment: Are you sure you're using 7.4.2? This should be fixed, and indeed I can't reproduce it on 7.4.2. See #5688. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7052#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] #4359: Implement lambda-case/lambda-if
#4359: Implement lambda-case/lambda-if
---+
Reporter: batterseapower| Owner:
Type: feature request | Status: new
Priority: normal| Milestone: 7.6.1
Component: Compiler |Version: 7.1
Resolution:| Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Difficulty: Unknown
Testcase:| Blockedby:
Blocking:|Related:
---+
Description changed by simonpj:
Old description:
I put together a patch for this Haskell' proposal
(http://hackage.haskell.org/trac/haskell-prime/ticket/41)
{{{
Prelude (if then Haskell else Cafe) False
Cafe
Prelude (case of 1 - One; _ - Not-one) 1
One
}}}
There seems to be some support for integrating this proposal into GHC
(see http://permalink.gmane.org/gmane.comp.lang.haskell.cafe/81366)
The attached patches implement the feature, test it and document it.
New description:
I put together a patch for this Haskell' proposal
(http://hackage.haskell.org/trac/haskell-prime/ticket/41)
{{{
Prelude (if then Haskell else Cafe) False
Cafe
Prelude (case of 1 - One; _ - Not-one) 1
One
}}}
There seems to be some support for integrating this proposal into GHC (see
http://permalink.gmane.org/gmane.comp.lang.haskell.cafe/81366)
The attached patches implement the feature, test it and document it.
See also the wiki page [wiki:LambdasVsPatternMatching].
--
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4359#comment:68
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] #7052: Numeric types’ Read instances use exponential CPU/memory
#7052: Numeric types’ Read instances use exponential CPU/memory --+- Reporter: andersk | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base |Version: 7.4.1 Resolution: fixed| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: #5688 --+- Changes (by andersk): * version: 7.4.2 = 7.4.1 Comment: My mistake; I’m still on 7.4.1. Thanks. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7052#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] #7052: Numeric types’ Read instances use exponential CPU/memory
#7052: Numeric types’ Read instances use exponential CPU/memory
--+-
Reporter: andersk | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: libraries/base |Version: 7.4.2
Resolution: | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: Runtime performance bug | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related: #5688
--+-
Changes (by andersk):
* status: closed = new
* version: 7.4.1 = 7.4.2
* resolution: fixed =
Comment:
Okay hold on, there’s still something wrong in 7.4.2 (I just downloaded
ghc-7.4.2-x86_64-unknown-linux.tar.bz2).
{{{
read (1e ++ show (2^63 - 2)) :: Double
Infinity -- Fine.
read (1e ++ show (2^63 - 1)) :: Double
0.0 -- What?
read (1e ++ show (2^64 - 2^10 - 2)) :: Double
0.0 -- What?
read (1e ++ show (2^64 - 2^10 - 1)) :: Double
-- Memory-eating infinite loop!
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7052#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] #7052: Numeric types’ Read instances use exponential CPU/memory
#7052: Numeric types’ Read instances use exponential CPU/memory --+- Reporter: andersk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base |Version: 7.4.2 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: #5688 --+- Comment(by andersk): Also it looks like GHC itself (also 7.4.2) is not using the improved `read`, as compiling `x = 1e` or typing `1e` into GHCi uses lots of CPU and memory for several seconds, although this is of course a less critical problem. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7052#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] #7052: Numeric types’ Read instances use exponential CPU/memory
#7052: Numeric types’ Read instances use exponential CPU/memory --+- Reporter: andersk | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.6.1 Component: libraries/base |Version: 7.4.2 Resolution: duplicate| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: #5688 --+- Changes (by pcapriotti): * status: new = closed * resolution: = duplicate * milestone: = 7.6.1 Comment: See #7034 and #5692. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7052#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] #4862: Enable usage of gold linker with GHC
#4862: Enable usage of gold linker with GHC --+- Reporter: ajd | Owner: igloo Type: feature request | Status: new Priority: normal | Milestone: 7.4.3 Component: Compiler |Version: 7.0.1 Resolution: | Keywords: Os: Linux| Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: --+- Comment(by andersk): On Debian/Ubuntu, the `binutils-gold` package actually replaces the symlink `/usr/bin/ld - ld.bfd` with `/usr/bin/ld - ld.gold` at install time. So any build-time test won’t be enough. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4862#comment:10 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] #6167: Compile stalls with pause returning ERESTARTNOHAND
#6167: Compile stalls with pause returning ERESTARTNOHAND -+-- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal| Milestone: 7.6.1 Component: Compiler | Version: 7.4.1 Keywords:| Os: Linux Architecture: Unknown/Multiple | Failure: Building GHC failed Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by erikd): I switched from the devel2 way of build ghc (defined in mk/build.mk.sample) to the prof way and suddenly everything built without any hang. Experimenting a little further it turns out that the important difference was that for devel2 the `GhcStage2HcOpts` variable does not include `-fasm` so that the second stage was built un-registered. This raises two questsions: * Should the un-registered build correctly on PowerPC? * Should `GhcStage2HcOpts` use `-fasm`? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/6167#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] #6156: Optimiser bug on linux-powerpc
#6156: Optimiser bug on linux-powerpc --+- Reporter: erikd| Owner: pcapriotti Type: bug | Status: new Priority: normal | Milestone: 7.6.1 Component: Compiler |Version: 7.4.1 Resolution: | Keywords: Os: Linux| Architecture: powerpc Failure: Incorrect result at runtime | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: --+- Comment(by erikd): Now that I can compile git HEAD on PowerPC again, I can confirm that this problem is fixed in HEAD, but not fixed in 7.4.2. I'll see if I can figure out what it is that fixed this so we can patch 7.4.2 in Debian. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/6156#comment:20 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] #6156: Optimiser bug on linux-powerpc
#6156: Optimiser bug on linux-powerpc
--+-
Reporter: erikd| Owner: pcapriotti
Type: bug | Status: new
Priority: normal | Milestone: 7.6.1
Component: Compiler |Version: 7.4.1
Resolution: | Keywords:
Os: Linux| Architecture: powerpc
Failure: Incorrect result at runtime | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related:
--+-
Comment(by erikd):
Oops, HEAD is also broken, it just gives a different incorrect result:
{{{
./camilla-test-std
Camellia.fl 1238988323332265734 11185553392205053542 -
18360184157246690566
./camilla-test-opt
Camellia.fl 1238988323332265734 11185553392205053542 -
3698434091925017862
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/6156#comment:21
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] #5289: Can't use ghci with a library linked against libstdc++
#5289: Can't use ghci with a library linked against libstdc++
---+
Reporter: bos | Owner:
Type: bug | Status: new
Priority: normal| Milestone: 7.6.1
Component: GHCi |Version: 7.0.3
Resolution:| Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: GHCi crash| Difficulty:
Testcase:| Blockedby:
Blocking:|Related:
---+
Comment(by spl):
I'm not that familiar with the machinery of dynamic linking or building
OS-X-specific apps, but it appears to me that you might be able to simply
change the name of the library you're looking for under OS X.
If I understand it correctly, the path to `libstdc++` is found with `gcc
--print-file-name` now:
{{{
$ gcc --print-file-name=libstdc++.dylib
/usr/lib/gcc/i686-apple-darwin9/4.0.1/libstdc++.dylib
}}}
This seems to explain the error for loading `double-conversion`:
{{{
$ ghci -package double-conversion
GHCi, version 7.4.1.20120508: 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 bytestring-0.9.2.1 ... linking ... done.
Loading package array-0.4.0.0 ... linking ... done.
Loading package deepseq-1.3.0.0 ... linking ... done.
Loading package text-0.11.2.1 ... linking ... done.
Loading package double-conversion-0.2.0.4 ... command line: can't load
.so/.DLL for: /usr/lib/gcc/i686-apple-darwin9/4.0.1/libstdc++.dylib
(dlopen(/usr/lib/gcc/i686-apple-darwin9/4.0.1/libstdc++.dylib, 9): no
suitable image found. Did find:
/usr/lib/gcc/i686-apple-darwin9/4.0.1/libstdc++.dylib: can't map)
}}}
But if I want the `libstdc++` that seems to work, I look for
`libstdc++.6.dylib`:
{{{
$ gcc --print-file-name=libstdc++.6.dylib
/usr/lib/libstdc++.6.dylib
}}}
So, does it make sense to use `libstdc++.6.dylib` instead of
`libstdc++.dylib` on OS X?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5289#comment:45
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] #1658: CSE changes semantics
#1658: CSE changes semantics ---+ Reporter: guest | Owner: igloo Type: bug | Status: closed Priority: normal| Milestone: Component: Compiler |Version: 6.7 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: numrun014 | Blockedby: Blocking:|Related: ---+ Changes (by pcapriotti): * testcase: num014 = numrun014 * failure: = None/Unknown -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1658#comment:11 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] #7014: RULES for bitwise logic and shift primops
#7014: RULES for bitwise logic and shift primops -+-- Reporter: akio | Owner: pcapriotti Type: feature request | Status: patch Priority: normal| Milestone: 7.6.1 Component: Compiler | Version: 7.4.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by pcapriotti): The attached patches adds identity rules for shift and bitwise operations to `PrelRules`, as well as similar rules from `GHC.Base`. I also refactored `PrelRules` a little to remove some duplication. We're still missing rules like: x and# (complement 0) == x x or# (complement 0) == complement 0 since I'm not sure how we can match `complement 0` in `MachWord`. We could convert to `Word`, but that is wrong for cross-compilation. There were already other places where it is assumed that target == host, however, so maybe it's ok to add another one? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7014#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] #7040: ghci segfault on OS X X86_64 with foreign global data
#7040: ghci segfault on OS X X86_64 with foreign global data
--+-
Reporter: luite | Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 7.4.2 | Keywords:
Os: Unknown/Multiple | Architecture: x86_64 (amd64)
Failure: GHCi crash| Testcase:
Blockedby:| Blocking:
Related:|
--+-
Comment(by nus):
The segfault happens when OS X calloc allocates space from the region
beyond limits imposed by the small C code model.
{{{
Program stopped at 0x10b0fd624.
It stopped with signal EXC_BAD_ACCESS, Could not access memory.
(gdb) bt
#0 0x00010b0fd624 in ?? ()
#1 0x00010871043c in ffi_call_unix64 ()
(gdb) x/20i 0x10b0fd624
0x10b0fd624:mov0x7303d16(%rip),%eax# 0x112401340
0x10b0fd62a:xor%cl,%cl
0x10b0fd62c:lea0x1c7(%rip),%rdx# 0x10b0fd7fa
0x10b0fd633:mov%rdx,%rdi
0x10b0fd636:mov%eax,%esi
0x10b0fd638:mov%cl,%al
0x10b0fd63a:callq 0x10b0fda70
0x10b0fd63f:movl $0x1,0x7303cf7(%rip)# 0x112401340
0x10b0fd649:mov0x7303cf1(%rip),%ecx# 0x112401340
0x10b0fd64f:xor%dl,%dl
0x10b0fd651:lea0x1a2(%rip),%rdi# 0x10b0fd7fa
0x10b0fd658:mov%ecx,%esi
0x10b0fd65a:mov%dl,%al
0x10b0fd65c:callq 0x10b0fda70
0x10b0fd661:pop%rbp
0x10b0fd662:retq
0x10b0fd663:add%dl,(%rax)
0x10b0fd665:add%al,(%rax)
0x10b0fd667:add%bh,%bh
0x10b0fd669:(bad)
(gdb) x/4w 0x10b0fd624
0x10b0fd624:0x3d16058b 0xc9300730 0xc7158d48 0x4801
}}}
The relevant allocation:
{{{
ALLOC 0x7fdd12401340-0x7fdd12401343 [size=4]: thread_7fff72dbe960
|s258_info | loadObj | loadOc | ocGetNames_MachO | stgCallocBytes | calloc
| malloc_zone_calloc
}}}
rts/Linker.c truncates the pointer calloc returned (the offset is declared
uint32_t):
{{{
if((sections[i].flags SECTION_TYPE) == S_ZEROFILL)
{
char * zeroFillArea = stgCallocBytes(1,sections[i].size,
ocGetNames_MachO(common symbols));
sections[i].offset = zeroFillArea - image;
}
}}}
From /usr/include/mach-o/loader.h:
{{{
struct section { /* for 32-bit architectures */
charsectname[16]; /* name of this section */
charsegname[16];/* segment this section goes in */
uint32_taddr; /* memory address of this section
*/
uint32_tsize; /* size in bytes of this section
*/
uint32_toffset; /* file offset of this section */
uint32_talign; /* section alignment (power of 2)
*/
uint32_treloff; /* file offset of relocation
entries */
uint32_tnreloc; /* number of relocation entries */
uint32_tflags; /* flags (section type and
attributes)*/
uint32_treserved1; /* reserved (for offset or index)
*/
uint32_treserved2; /* reserved (for count or sizeof)
*/
};
}}}
Even if it weren't truncated, the RIP-relative displacement is still
required to fit into 32 bits.
The analysis given in a comment in rts/Linker.c (see the bit starting on
x86_64 we have a problem with relocating symbol references) is also
relevant to this situation.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7040#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] #7040: ghci segfault on OS X X86_64 with foreign global data
#7040: ghci segfault on OS X X86_64 with foreign global data
--+-
Reporter: luite | Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 7.4.2 | Keywords:
Os: Unknown/Multiple | Architecture: x86_64 (amd64)
Failure: GHCi crash| Testcase:
Blockedby:| Blocking:
Related:|
--+-
Comment(by nus):
Err, rts/Linker.c actually uses section_64 in this case:
{{{
#if x86_64_HOST_ARCH || powerpc64_HOST_ARCH
#define mach_header mach_header_64
#define segment_command segment_command_64
#define section section_64
#define nlist nlist_64
#endif
}}}
{{{
struct section_64 { /* for 64-bit architectures */
charsectname[16]; /* name of this section */
charsegname[16];/* segment this section goes in */
uint64_taddr; /* memory address of this section
*/
uint64_tsize; /* size in bytes of this section
*/
uint32_toffset; /* file offset of this section */
uint32_talign; /* section alignment (power of 2)
*/
uint32_treloff; /* file offset of relocation
entries */
uint32_tnreloc; /* number of relocation entries */
uint32_tflags; /* flags (section type and
attributes)*/
uint32_treserved1; /* reserved (for offset or index)
*/
uint32_treserved2; /* reserved (for count or sizeof)
*/
uint32_treserved3; /* reserved */
};
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7040#comment:7
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #7054: Compile failure on non x86/x86-64
#7054: Compile failure on non x86/x86-64
-+--
Reporter: erikd| Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 7.5 | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: Building GHC failed | Testcase:
Blockedby: | Blocking:
Related: |
-+--
Compile error as follows on Git HEAD
(f3aabb7eae90f68c5f9f22ff0bc7117deb22d57d):
{{{
HC [stage 0] compiler/stage1/build/X86/Regs.o
compiler/nativeGen/X86/Regs.hs:20:9:
Not in scope: `allHaskellArgRegs'
compiler/nativeGen/X86/Regs.hs:22:9:
Not in scope: `instrClobberedRegs'
Perhaps you meant `callClobberedRegs' (line 647)
}}}
I have a patch for this.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7054
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] #6167: Compile stalls with pause returning ERESTARTNOHAND
#6167: Compile stalls with pause returning ERESTARTNOHAND
-+--
Reporter: erikd | Owner:
Type: bug | Status: new
Priority: normal| Milestone: 7.6.1
Component: Compiler | Version: 7.4.1
Keywords:| Os: Linux
Architecture: Unknown/Multiple | Failure: Building GHC failed
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by erikd):
I'm using the following mk/build.mk:
{{{
SRC_HC_OPTS= -H64m -O -fasm
GhcLibHcOpts = -O -dcore-lint
GhcStage1HcOpts= -Rghc-timing -O -fasm
GhcStage2HcOpts= -Rghc-timing -O0 -fasm -DDEBUG
SplitObjs = NO
HADDOCK_DOCS = NO
BUILD_DOCBOOK_HTML = NO
BUILD_DOCBOOK_PS = NO
BUILD_DOCBOOK_PDF = NO
LAX_DEPENDENCIES = NO
NoFibWays =
STRIP_CMD = :
GhcDebugged = Yes
}}}
and now something has changed. Regardless of whether `-fasm` is included
in `GhcStage2HcOpts` the build runs to completion.
While I'm not seeing this anymore, I'm not sure if the problem is fixed.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/6167#comment:10
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] #6156: Optimiser bug on linux-powerpc
#6156: Optimiser bug on linux-powerpc
--+-
Reporter: erikd| Owner: pcapriotti
Type: bug | Status: new
Priority: normal | Milestone: 7.6.1
Component: Compiler |Version: 7.4.1
Resolution: | Keywords:
Os: Linux| Architecture: powerpc
Failure: Incorrect result at runtime | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related:
--+-
Comment(by erikd):
Simplified test case for this bug:
{{{
import Data.Bits
import Data.Word
w64tow32 :: Word64 - (Word32, Word32)
w64tow32 w =
(fromIntegral (w `shiftR` 32), fromIntegral (w .. 0x))
main :: IO ()
main =
if w64tow32 1238988323332265734 == (288474448,3440613126)
then putStrLn Pass
else putStrLn Fail
}}}
Compling without optimisation (or with -O0) passes, with -O1 or above it
fails.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/6156#comment:22
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] #7040: linker failures with foreign global data (was: ghci segfault on OS X X86_64 with foreign global data)
#7040: linker failures with foreign global data
--+-
Reporter: luite | Owner:
Type: bug | Status: new
Priority: normal| Component: Runtime System
Version:| Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: Other | Testcase:
Blockedby:| Blocking:
Related:|
--+-
Changes (by nus):
* failure: GHCi crash = Other
* version: 7.4.2 =
* component: Compiler = Runtime System
* architecture: x86_64 (amd64) = Unknown/Multiple
Comment:
This involves multiple archithectures/OS'es, changing the ticket
properties. See the following example:
{{{
#include stdio.h
#include global.h
#if defined(__MINGW32__)
# if defined(__MINGW64_VERSION_MAJOR) defined(__MINGW64__)
#define ARR_SIZE 0x0fff /* works when linked by ghc, fails with
ghci */
/* #define ARR_SIZE 0x1fff */ /* bad executable when linked by
ghc, fails to link with ghci */
# else
#define ARR_SIZE 0x1 /* this, and anything bigger fails to link with
ghci, works with ghc */
# endif
#elif defined(__APPLE__)
# if defined(__i386__)
#define ARR_SIZE 0x0fff /* works */
/* #define ARR_SIZE 0x1fff */ /* works when linked by ghc, causes
failure in malloc at ghci run-time */
/* #define ARR_SIZE 0x2fff */ /* refused by llvm-gcc as too large
*/
# elif defined(__x86_64__)
#define ARR_SIZE 0x /* works when linked by ghc, causes
failure in malloc at ghci run-time */
# endif
#elif defined(__linux__)
# if defined(__i386__)
#define ARR_SIZE 0x1fff
/* #define ARR_SIZE 0x2fff */ /* refused by gcc as too large */
# elif defined(__x86_64__)
/* #define ARR_SIZE 0x1fff */ /* works */
/* #define ARR_SIZE 0x2fff */ /* works when linked by ghc, causes
failure in malloc at ghci run-time */
/* #define ARR_SIZE 0x3fff */ /* SIGKILL'ed when linked by ghc,
causes failure in malloc at ghci run-time */
# endif
#endif
int x[ARR_SIZE];
void printx() {
printf(ARR_SIZE: %x\n, ARR_SIZE);
x[0] = 0;
printf(x: %d\n, x[0]);
x[0] = 1;
printf(x: %d\n, x[0]);
}
}}}
The versions the example was tested on:
{{{
Windows 7 SP1 x64.
x32:
CC: i686-w64-mingw32-gcc-4.6.3-release-win32_rubenvb.7z
GHC: ghc-7.4.1-i386-windows.exe
x64:
CC: x86_64-w64-mingw32-gcc-4.6.3-release-win64_rubenvb.7z
GHC: ghc-7.5.20120617-i386-windows.exe; HEAD(Project
version,7.5.20120705)(Booter version,7.5.20120617)
}}}
{{{
Mac OS X 10.7.3.
x32:
CC: gcc -m32 (i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on
Apple Inc. build 5658) (LLVM build 2336.9.00))
GHC: ghc-7.4.2-i386-apple-darwin.tar.bz2
x64:
CC: gcc (i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple
Inc. build 5658) (LLVM build 2336.9.00))
GHC: ghc-7.4.2-x86_64-apple-darwin.tar.bz2
}}}
{{{
Linux Ubuntu 12.04 LTS x64.
x32:
CC: gcc -m32 (gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3)
GHC: ghc-7.4.2-i386-unknown-linux.tar.bz2
x64:
CC: gcc (gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3)
GHC: ghc-7.4.2-x86_64-unknown-linux.tar.bz2
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7040#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
[GHC] #7055: GHCi loadArchive libiconv.a:failed Unknown PEi386 section name `.drectve'
#7055: GHCi loadArchive libiconv.a:failed Unknown PEi386 section name `.drectve' +--- Reporter: songpp | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 7.4.1 | Keywords: loadArchive Unknown PEi386 Os: Windows | Architecture: x86 Failure: GHCi crash | Testcase: Blockedby: | Blocking: Related: #2487 | +--- cygwin 1.7 $ iconv --version iconv (GNU libiconv 1.14) E:/Develop/haskell/conv.hs : import Codec.Text.IConv as IConv import Data.ByteString.Lazy as ByteString main :: IO () main = ByteString.interact (convert UTF-8 GBK) then GHCi, version 7.4.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude :load e:/Develop/haskell/conv.hs [1 of 1] Compiling Main ( E:\Develop\haskell\conv.hs, interpreted ) Ok, modules loaded: Main. *Main main Loading package bytestring-0.9.2.1 ... linking ... done. Loading package iconv-0.4.1.0 ... ghc.exe: panic! (the 'impossible' happened) (GHC version 7.4.1 for i386-unknown-mingw32): loadArchive d:/cygwin/lib\\libiconv.a: failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *Main Leaving GHCi. interactive: Unknown PEi386 section name `.drectve' (while processing: d:/cygwin/lib\libiconv.a) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7055 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] #7056: GHCi loadArchive libiconv.a:failed Unknown PEi386 section name `.drectve'
#7056: GHCi loadArchive libiconv.a:failed Unknown PEi386 section name `.drectve' +--- Reporter: songpp | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 7.4.1 | Keywords: loadArchive Unknown PEi386 Os: Windows | Architecture: x86 Failure: GHCi crash | Testcase: Blockedby: | Blocking: Related: #2487 | +--- cygwin 1.7 $ iconv --version iconv (GNU libiconv 1.14) E:/Develop/haskell/conv.hs : import Codec.Text.IConv as IConv import Data.ByteString.Lazy as ByteString main :: IO () main = ByteString.interact (convert UTF-8 GBK) then GHCi, version 7.4.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude :load e:/Develop/haskell/conv.hs [1 of 1] Compiling Main ( E:\Develop\haskell\conv.hs, interpreted ) Ok, modules loaded: Main. *Main main Loading package bytestring-0.9.2.1 ... linking ... done. Loading package iconv-0.4.1.0 ... ghc.exe: panic! (the 'impossible' happened) (GHC version 7.4.1 for i386-unknown-mingw32): loadArchive d:/cygwin/lib\\libiconv.a: failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *Main Leaving GHCi. interactive: Unknown PEi386 section name `.drectve' (while processing: d:/cygwin/lib\libiconv.a) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7056 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] #7055: GHCi loadArchive libiconv.a:failed Unknown PEi386 section name `.drectve'
#7055: GHCi loadArchive libiconv.a:failed Unknown PEi386 section name `.drectve' ---+ Reporter: songpp |Owner: Type: bug | Status: closed Priority: normal |Component: GHCi Version: 7.4.1 | Resolution: duplicate Keywords: loadArchive Unknown PEi386 | Os: Windows Architecture: x86 | Failure: GHCi crash Testcase: |Blockedby: Blocking: | Related: #2487 ---+ Changes (by songpp): * status: new = closed * resolution: = duplicate -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7055#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: Call to arms: lambda-case is stuck and needs your help
On 07/06/2012 05:47 AM, Donn Cave wrote: The `multi-clause lambda' seems more elegant, if the syntactical problems could be worked out. I mean, unnamed functions are thus just like named functions, something that you'd probably think to try just as soon as you needed the feature. I don't understand the issues well enough with the layout rules to comment on Tyson Whitehead's ideas about that, and for the same reason this may be a useless idea, but what if each clause were introduced by \, would that clarify the column structure, or does indented block structure require a less-indented `layout herald'? f = \ (Just a) (Just b) | a 0 || b 0 - Nothing \ (Just a) (Just b) - Just (a * b) \ _ _ - Nothing Donn This was suggested in the ticket comments, see http://hackage.haskell.org/trac/ghc/ticket/4359#comment:29 I'll add it to the list. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Call to arms: lambda-case is stuck and needs your help
On 07/05/2012 10:22 PM, wagne...@seas.upenn.edu wrote: Quoting Mikhail Vorozhtsov mikhail.vorozht...@gmail.com: After 21 months of occasional arguing the lambda-case proposal(s) is in danger of being buried under its own trac ticket comments. We need fresh blood to finally reach an agreement on the syntax. Read the wiki page[1], take a look at the ticket[2], vote and comment on the proposals! P.S. I'm CC-ing Cafe to attract more people, but please keep the discussion to the GHC Users list. [1] http://hackage.haskell.org/trac/ghc/wiki/LambdasVsPatternMatching [2] http://hackage.haskell.org/trac/ghc/ticket/4359 Well, for what it's worth, my vote goes for a multi-argument \case. I find the comment on the wiki page about mistyping \case Just x instead of \case (Just x) a lot a bit disingenuous, since you already need these parens with today's lambda. The complaint that multi-argument cases are unorthodox doesn't really hold a lot of weight with me -- much more serious things than syntax have changed in GHC compared to the Report! \case does /not/ require parentheses. I wrote about forgetting them when using MultiClauseLambdas, e.g. \(A b) - ... -- \ here reminds me to use () (C d) - ... ... Y z - ... -- After a while I forget about them because all I see is -- Pat - Expr, and that's instantly a case-expression -- alternative clause for me. This might as well be just my personal thing. Is there a more formal way to cast votes...? People are still coming up with new tweaks. I'll write a summary email with the voted (so far) proposals list, maybe it will be easier to go on from there. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Call to arms: lambda-case is stuck and needs your help
Oh, neat. I guess it does. :) I'll hack that into my grammar when I get into work tomorrow. My main point with that observation is it cleanly allows for multiple argument \of without breaking the intuition you get from how of already works/looks or requiring you to refactor subsequent lines, to cram parens or other odd bits of syntax in, but still lets the multi-argument crowd have a way to make multi-argument lambdas with all of the expected appropriate backtracking, if they want them. I definitely prefer \of to \case given its almost shocking brevity and the fact that the fact that it introduces a layout rule doesn't change any of the rules for when layout is introduced. On Jul 5, 2012, at 5:33 PM, Twan van Laarhoven twa...@gmail.com wrote: On 2012-07-05 23:04, Edward Kmett wrote: A similar generalization can be applied to the expression between case and of to permit a , separated list of expressions so this becomes applicable to the usual case construct. A naked unparenthesized , is illegal there currently as well. That would effectively be constructing then matching on an unboxed tuple without the (#, #) noise, but that can be viewed as a separate proposal' then the above is just the elision of the case component of: Should that also generalize to nullarry 'case of'? As in foo = case of | guard1 - bar | guard2 - baz instead of foo = case () of () | guard1 - bar | guard2 - baz I realize this is getting off-topic, and has become orthogonal to the single argument λcase proposal. Twan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Call to arms: lambda-case is stuck and needs your help
On 07/06/2012 02:31 AM, Tyson Whitehead wrote:
On July 5, 2012 10:42:53 Mikhail Vorozhtsov wrote:
After 21 months of occasional arguing the lambda-case proposal(s) is in
danger of being buried under its own trac ticket comments. We need fresh
blood to finally reach an agreement on the syntax. Read the wiki
page[1], take a look at the ticket[2], vote and comment on the proposals!
If I understand correctly, we currently we have
\ apat1 ... apatn - exp
The possibility using '\' as a layout herald (like let, do, etc.)
\ { apat1 ... apatn - exp; ... }
is suggested on the wiki, but rejected because code like so
mask $ \restore - do
stmt1
...
by translating it into (Section 9.3 of the 98 Report)
mask $ \ { restore - do { }
} stmt1
http://www.haskell.org/onlinereport/syntax-iso.html
The reason for this is
1 - the layout level for '\' is the column of the 'restore' token
2 - the layout level for 'do' would be the column of the first token of 'stmt1'
3 - the '\' level is greater than the potential 'do' level so the fall through
'{}' insertion rule fires instead of the desired '{' insertion rule
4 - the '\' level is greater than the identation level for the first token of
'stms1' (now established to not be part of the 'do') so the '}' rule fires
Why not just let enclosed scopes be less indented than their outer ones?
It would then correctly translate the above. This of course implies that any
code that requires the original translation (i.e., where the last of multiple
enclosing blocks should be an empty block) would no longer work.
Is any code actually relying on this though? It seems like a pretty esoteric
corner case. If not, my vote would be to relax this rule and go with '\'
being a layout hearld with full case style matching (i.e., guards too).
Hm, would it work for
getArgs = \args -
forM_ args putStrLn
?
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Call to arms: lambda-case is stuck and needs your help
On 07/05/2012 09:42 PM, Mikhail Vorozhtsov wrote: Hi. After 21 months of occasional arguing the lambda-case proposal(s) is in danger of being buried under its own trac ticket comments. We need fresh blood to finally reach an agreement on the syntax. Read the wiki page[1], take a look at the ticket[2], vote and comment on the proposals! P.S. I'm CC-ing Cafe to attract more people, but please keep the discussion to the GHC Users list. [1] http://hackage.haskell.org/trac/ghc/wiki/LambdasVsPatternMatching [2] http://hackage.haskell.org/trac/ghc/ticket/4359 Preliminary votes: * LambdaCase \case: 3 (Christopher, Felipe, Gábor) * LambdaCase \of: 1 (Edward) * MultiClauseLambdas \of: 1 (Daniel) * MultiClauseLambdas with \ in each clause: 1 (Donn) * MultiClauseLambdas with layout rules tweaking: 1 (Tyson) Note that LambdaCase variants do /not/ require parentheses around patterns while MultiClauseLambdas variants do. Did I forget/misunderstand someone? It would be great to have GHC HQ input on the new proposals (layout rules tweaking (Tyson) and case comma sugar (Edward)). ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Call to arms: lambda-case is stuck and needs your help
Twan, The 0-ary version you proposed actually works even nicer with \of. foo'' = case () of () | quux - ... | quaffle - ... | otherwise - ... Starting from the above legal haskell multi-way if, we can, switch to foo' = case of | quux - ... | quaffle - ... | otherwise - ... using the 0-ary form of case as a multi-way if, but since the motivation was to allow the min \of, we get the very terse foo = \of | quux - ... | quaffle - ... | otherwise - ... and you get wind up with layout starting on the |'s so they line up per-force. baz = \of Just x - Just (x + 1) Nothing - Nothing avoids an ugly temporary for baz' mx = case mx of Just x - Just (x + 1) Nothing - Nothing and in the multi-argument case, the resulting syntax is actually comparably noisy to the direct declaration syntax. One , as opposed to two pairs of parentheses in bar''' below. bar = \of Just x, Just y - Just (x + y) _ , _ - Nothing bar' mx my = case mx, my of Just x, Just y - Just (x + y) _ , _ - Nothing bar'' mx my = case (# mx, my #) of (# Just x, Just y #) - Just (x + y) (# _ , _ #) - Nothing bar''' (Just x) (Just y) = Just (x + y) bar''' _ _ = Nothing -Edward On Fri, Jul 6, 2012 at 3:12 AM, Edward Kmett ekm...@gmail.com wrote: Oh, neat. I guess it does. :) I'll hack that into my grammar when I get into work tomorrow. My main point with that observation is it cleanly allows for multiple argument \of without breaking the intuition you get from how of already works/looks or requiring you to refactor subsequent lines, to cram parens or other odd bits of syntax in, but still lets the multi-argument crowd have a way to make multi-argument lambdas with all of the expected appropriate backtracking, if they want them. I definitely prefer \of to \case given its almost shocking brevity and the fact that the fact that it introduces a layout rule doesn't change any of the rules for when layout is introduced. On Jul 5, 2012, at 5:33 PM, Twan van Laarhoven twa...@gmail.com wrote: On 2012-07-05 23:04, Edward Kmett wrote: A similar generalization can be applied to the expression between case and of to permit a , separated list of expressions so this becomes applicable to the usual case construct. A naked unparenthesized , is illegal there currently as well. That would effectively be constructing then matching on an unboxed tuple without the (#, #) noise, but that can be viewed as a separate proposal' then the above is just the elision of the case component of: Should that also generalize to nullarry 'case of'? As in foo = case of | guard1 - bar | guard2 - baz instead of foo = case () of () | guard1 - bar | guard2 - baz I realize this is getting off-topic, and has become orthogonal to the single argument λcase proposal. Twan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Call to arms: lambda-case is stuck and needs your help
Christopher Done chrisd...@gmail.com writes: P.S. \if then … else …? btw, http://www.haskell.org/haskellwiki/If-then-else ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Call to arms: lambda-case is stuck and needs your help
On 05/07/2012 20:31, Tyson Whitehead wrote:
On July 5, 2012 10:42:53 Mikhail Vorozhtsov wrote:
After 21 months of occasional arguing the lambda-case proposal(s) is in
danger of being buried under its own trac ticket comments. We need fresh
blood to finally reach an agreement on the syntax. Read the wiki
page[1], take a look at the ticket[2], vote and comment on the proposals!
If I understand correctly, we currently we have
\ apat1 ... apatn - exp
The possibility using '\' as a layout herald (like let, do, etc.)
\ { apat1 ... apatn - exp; ... }
is suggested on the wiki, but rejected because code like so
mask $ \restore - do
stmt1
...
by translating it into (Section 9.3 of the 98 Report)
mask $ \ { restore - do { }
} stmt1
http://www.haskell.org/onlinereport/syntax-iso.html
The reason for this is
1 - the layout level for '\' is the column of the 'restore' token
2 - the layout level for 'do' would be the column of the first token of 'stmt1'
3 - the '\' level is greater than the potential 'do' level so the fall through
'{}' insertion rule fires instead of the desired '{' insertion rule
4 - the '\' level is greater than the identation level for the first token of
'stms1' (now established to not be part of the 'do') so the '}' rule fires
Why not just let enclosed scopes be less indented than their outer ones?
I think this is undesirable. You get strange effects like
f x y = x + y
where -- I just left this where here by accident
g x = ...
parses as
f x y = x + y
where { -- I just left this empty where here by accident
g x = ...
}
and
instance Exception Foo where
instance Exception Bar
parses as
instance Exception Foo where {
instance Exception Bar
}
That is, layout contexts that should really be empty end up surprisingly
swallowing the rest of the file.
Cheers,
Simon
It would then correctly translate the above. This of course implies that any
code that requires the original translation (i.e., where the last of multiple
enclosing blocks should be an empty block) would no longer work.
Is any code actually relying on this though? It seems like a pretty esoteric
corner case. If not, my vote would be to relax this rule and go with '\'
being a layout hearld with full case style matching (i.e., guards too).
Cheers! -Tyson
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: More infinite simplifier bugs?
try with -ddump-rule-firings -dverbose-core2core -ddump-occur-anal -ddump-inlinings. You'll get a lot of output ,but you may either see (a) output stops but computer gets hot, (b) output goes on and on. use HEAD if you can Simon | -Original Message- | From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users- | boun...@haskell.org] On Behalf Of Ron Alford | Sent: 06 July 2012 05:04 | To: glasgow-haskell-users | Subject: More infinite simplifier bugs? | | So a while back Simon added a tick counter to the simplifier: | http://hackage.haskell.org/trac/ghc/ticket/5448 | | Are there any known bugs that can cause the simplifier to run out of | memory /without/ hitting the tick counter limit? | | I have code that /used/ to run (at least after hacking around the | previous simplifier bug): | https://github.com/ronwalf/Planning | | With GHC 7.4.[12], it exhausts all the RAM on my machine (4GB). | | Compiling with -O0 fixes the problem. I can start bisecting my code | to find the problem if nothing comes to mind. | | -Ron Alford | (who seems to be good at killing the simplifier) | | ___ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Call to arms: lambda-case is stuck and needs your help
On July 6, 2012 05:25:15 Simon Marlow wrote:
Why not just let enclosed scopes be less indented than their outer ones?
Let me be entirely clear about what I was thinking about. The third case for
the layout mapping in Section 9.3 of the report is
L ({n}:ts) (m:ms) = { : (L ts (n:m:ms)) if n m
This function takes a possibly layout sensitive token stream augmented with
'{n}' for the indentation level of the first token following a grouping token
that doesn't have a '{' and 'n' for the indentation level of first tokens
after newlines that are not already augmented with '{n}'. The 'L' functions
maps this to a non-augmented non-layout sensitive stream.
The first argument is the augmented layout stream and the current stack of
indentations for any groupings in effect. The rule above inserts a '{' if
there isn't one after a grouping token and the next token is at a deeper level
then the current grouping level. I was proposing to make it always fire on
indentation (i.e., allow enclosing scopes to be less indented).
L ({n}:ts) (m:ms) = { : (L ts (n:m:ms)) if n 0
The rest of the '{' insertion rules are for starting the first '{' on any
indentation after a grouping token not followed by a '{' and for inserting a
'{}' in all other cases.
L ({n}:ts) [] = { : (L ts [n]) if n 0
L ({n}:ts) ms = { : } : (L (n:ts) ms)
http://www.haskell.org/onlinereport/syntax-iso.html
I think this is undesirable. You get strange effects like
f x y = x + y
where -- I just left this where here by accident
g x = ...
parses as
f x y = x + y
where { -- I just left this empty where here by accident
g x = ...
}
and
instance Exception Foo where
instance Exception Bar
parses as
instance Exception Foo where {
instance Exception Bar
}
That is, layout contexts that should really be empty end up surprisingly
swallowing the rest of the file.
These would be okay under the above so long as the following lines are not
indented. The issue only arises with nested ones
f x = ...
where
g y = ...
where
h y = ...
Now the h gets sucked into the where clause as it is empty and nested. Using
the metric of what would most people expect, I agree the above is not ideal
(although I would hope empty nested where clauses not really in common use).
By this same metric though, I also think things like
where f x = do
stmt1
stmt2
mask $ let x = do
stmt1
stmt2
being parsed to
where { f x = do {}
} stmt1
stmt2
mask $ let { x = do {}
stmt1
stmt2
}
is also not ideal. The real underlying issue in both these cases and changing
'\' to a group token seems to be what happens on single lines with multiple
groupings when the last grouping actually starts on a newline indented further
than the proceeding line.
Currently it depends on the depth of this new level of indentation relative to
all the groupings started on that line. I think most people would expect it
to just apply to the last grouping though. That is
where { f x = do {
stmt1
stmt2
} }
mask $ let { x = do {
stmt1
stmt2
} }
The rule in this case would be that if the grouping began on a newline that is
idented farther then the previous line, the grouping is assocated with the
grouping token and when it closes, it closes all those deeper than itself.
Cheers! -Tyson
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Call to arms: lambda-case is stuck and needs your help
On 05/07/2012, Mikhail Vorozhtsov mikhail.vorozht...@gmail.com wrote: Hi. After 21 months of occasional arguing the lambda-case proposal(s) is in danger of being buried under its own trac ticket comments. We need fresh blood to finally reach an agreement on the syntax. Read the wiki page[1], take a look at the ticket[2], vote and comment on the proposals! +1 for \ of multi-clause lambdas It looks like binding of to me, which it ain't, but it is nicely brief... ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Call to arms: lambda-case is stuck and needs your help
Whoops, my earlier answer forgot to copy mailing lists... I would love to see \of, but I really don't think this is important enough to make case sometimes introduce layout and other times not. If it's going to obfuscate the lexical syntax like that, I'd rather just stick with \x-case x of. On Jul 6, 2012 3:15 PM, Strake strake...@gmail.com wrote: On 05/07/2012, Mikhail Vorozhtsov mikhail.vorozht...@gmail.com wrote: Hi. After 21 months of occasional arguing the lambda-case proposal(s) is in danger of being buried under its own trac ticket comments. We need fresh blood to finally reach an agreement on the syntax. Read the wiki page[1], take a look at the ticket[2], vote and comment on the proposals! +1 for \ of multi-clause lambdas It looks like binding of to me, which it ain't, but it is nicely brief... ___ Haskell-Cafe mailing list haskell-c...@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: More infinite simplifier bugs?
On Fri, Jul 6, 2012 at 7:18 AM, Simon Peyton-Jones simo...@microsoft.com wrote: try with -ddump-rule-firings -dverbose-core2core -ddump-occur-anal -ddump-inlinings. You'll get a lot of output ,but you may either see (a) output stops but computer gets hot, (b) output goes on and on. use HEAD if you can Thanks. I haven't set HEAD up yet, but for 7.4.2, (b) appears to be the case (the function pddlDocExpr appears in the output quite often). I'm still trying to whittle down my program to a small test case, but even small and seemingly irrelevant changes are enough to restore GHC's termination. -Ron Alford ghcloop.hs Description: Binary data ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Imported foreign functions should be strict
Hi all,
Recently I am tuning one of our incomplete libraries that uses FFI.
After dumping the interface file I realized strictness/demand analysis
failed for imported foreign functions---that is, they are not inferred
to be strict in their arguments. In my naive understanding all
imported foreign functions are strict! Here's a minimum example (with
GHC 7.4.2):
{-# LANGUAGE ForeignFunctionInterface #-}
module Main where
import Foreign.C
foreign import ccall unsafe sin sin' :: CDouble - CDouble
where in the interface file the function sin' will have strictness
U(L) (meaning Unpackable(Lazy)).
Regards,
Favonia
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Call to arms: lambda-case is stuck and needs your help
On July 6, 2012 11:49:23 Tyson Whitehead wrote:
Currently it depends on the depth of this new level of indentation relative
to all the groupings started on that line. I think most people would
expect it to just apply to the last grouping though. That is
where { f x = do {
stmt1
stmt2
} }
mask $ let { x = do {
stmt1
stmt2
} }
The rule in this case would be that if the grouping began on a newline that
is idented farther then the previous line, the grouping is assocated with
the grouping token and when it closes, it closes all those deeper than
itself.
I've thought some more about this and it seems to me that there are two ways
people might intuitively think about doing grouping via indentation.
1 - the first item is on the same line and subsequent ones are lined up with it
do stmt1
stmt2
2 - the first item is on a new line and subsequent ones are lined up with it.
do
stmt1
stmt2
The current layout engine is targeted at (1). It appears to do (2), but it is
not really reliable as things start to go south if the first line happened to
open more than one grouping (precisely the problem that make '\' a group token
would introduce in codes). For an example, consider
let greet name = do
putStr hello
putStrLn name
in f world
It currently translates into
let { greet name = do {} } putStr hello putStrLn name in f world
This results in an unituituve Empty 'do' construct error message.
I propose we detected (2) and make it work too. That is, if the line ends
with a grouping construct and the next line is indented relative to that line,
then assume we really don't want '{}' and instead always start grouping (even
if it isn't indented further than other possible groupings also started).
In other words, translate the above into
let { greet name = do {
putStr hello;
putStrLn name
}} in f world
This would then correctly handle the problamatic case raised in wiki where
mask $ \restore - do
stmt1
stmt2
is in translated into
mask $ \ { restore - do {} } stmt1 stmt2
under the current rules if '\' is made a grouping token.
The very limited scope of this (i.e., it would only apply to lines that end
with a grouping construct where the next line is indented further than that
line) should also address Simon's concerns regarding things like
f x y = x + y
where -- I just left this where here by accident
g x = ...
and
instance Exception Foo where
instance Exception Bar
Cheers! -Tyson
PS: To be fully precise, the modified layout decoder in 9.3 would be
L (n:ts) i (m:ms) = ; : (L ts n (m:ms)) if m = n
= } : (L (n:ts) n ms) if n m
L (n:ts) i ms = L ts n ms
L ({n}:n:ts) i ms = { : (L ts n (n:ms)) if n i (new rule)
L ({n}:ts) i (m:ms) = { : (L ts i (n:m:ms)) if n m (Note 1)
L ({n}:ts) i [] = { : (L ts i [n]) if n 0 (Note 1)
L ({n}:ts) i ms = { : } : (L (n:ts) i ms) (Note 2)
L (}:ts) i (0:ms) = } : (L ts i ms) (Note 3)
L (}:ts) i ms = parse-error (Note 3)
L ({:ts) i ms = { : (L ts i (0:ms)) (Note 4)
L (t:ts) i (m:ms) = } : (L (t:ts) i ms) if m /= 0 and parse-error(t)
(Note 5)
L (t:ts) i ms = t : (L ts i ms)
L [] i [] = []
L [] i (m:ms) = } : L [] i ms if m /= 0 (Note 6)
http://www.haskell.org/onlinereport/syntax-iso.html
As before, the function 'L' maps a layout-sensitive augmented token stream to
a non-layout-sensitive token stream, where the augmented token stream includes
'n' and '{n}' to, respectively, give the indentation level of the first token
on a new line and that following a grouping token not followed by '{'.
This time though, we allow the '{n}' 'n' sequence (before it was supressed
to just '{n}'). We also add a new state variable 'i' to track the indentation
of the current line. The new rule now opens a grouping over a newline so
long as the indentation is greater than the current line.
Upon a less indented line, it will then close all currently open groups with
an indentation less than the new line.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] ANNOUNCE: lens-family 0.0.0
I'm pleased to announce the first release of lens-family-core and lens-family. This package provide first class(†) functional references. In addition to the usual operations of getting, setting and composition, plus integration with the state monad, lens families provide some unique features: * Polymorphic updating * Cast projection functions to read-only lenses * Cast semantic editor combinators to modify-only lenses (†) For optimal first-class support use the lens-family package with rank 2 / rank N polymorphism. Lens.Family.Clone allows for first-class support of lenses for those who require Haskell 98. -- Russell O'Connor http://r6.ca/ ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: husk-scheme - a Scheme extension language for Haskell
I would like to announce the release of husk-scheme 3.5.6, a Scheme extension language and stand-alone interpreter/compiler that I have been developing. husk implements most of the Scheme R5RS standard including advanced features such as continuations, hygienic macros, and a full numeric tower. husk has been an ongoing project for over a year now, but this is the first announcement on the mailing list so feedback is very welcome. Hackage: http://hackage.haskell.org/package/husk-scheme Homepage: http://justinethier.github.com/husk-scheme Scheme Language Docs: http://schemers.org/Documents/Standards/R5RS/HTML/ Change Log: https://github.com/justinethier/husk-scheme/blob/master/ChangeLog.markdown Issues and Enhancement Requests: https://github.com/justinethier/husk-scheme/issues Thanks, Justin ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] translation between two flavors of lexically-scoped type variables
Kangyuan Niu wrote:
Aren't both Haskell and SML translatable into System F, from which
type-lambda is directly taken?
The fact that both Haskell and SML are translatable to System F does
not imply that Haskell and SML are just as expressive as System
F. Although SML (and now OCaml) does have what looks like a
type-lambda, the occurrences of that type lambda are greatly
restricted. It may only come at the beginning of a polymorphic
definition (it cannot occur in an argument, for example).
data Ap = forall a. Ap [a] ([a] - Int)
Why isn't it possible to write something like:
fun 'a revap (Ap (xs : 'a list) f) = f ys
where
ys :: 'a list
ys = reverse xs
in SML?
This looks like a polymorphic function: an expression of the form
/\a.body has the type forall a. type. However, the Haskell function
revap :: Ap - Int
revap (Ap (xs :: [a]) f) = f ys
where
ys :: [a]
ys = reverse xs
you meant to emulate is not polymorphic. Both Ap and Int are concrete
types. Therefore, your SML code cannot correspond to the Haskell code.
That does not mean we can't use SML-style type variables (which must
be forall-bound) with existentials. We have to write the
elimination principle for existentials explicitly
{-# LANGUAGE ExistentialQuantification, RankNTypes #-}
{-# LANGUAGE ScopedTypeVariables #-}
data Ap = forall a. Ap [a] ([a] - Int)
-- Elimination principle
deconAp :: Ap - (forall a. [a] - ([a] - Int) - w) - w
deconAp (Ap xs f) k = k xs f
revap :: Ap - Int
revap ap = deconAp ap revap'
revap' :: forall a. [a] - ([a] - Int) - Int
revap' xs f = f ys
where
ys :: [a]
ys = reverse xs
Incidentally, GHC now uses SML-like design for type
variables. However, there is a special exception for
existentials. Please see
7.8.7.4. Pattern type signatures
of the GHC user manual. The entire section 7.8.7 is worth reading.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Plain lambda inside banana brackets in the arrow notation
Tsuyoshi Ito tsuyoshi.ito.2...@gmail.com wrote: How can I use combinators like repeat, which takes a plain function as an argument, in the arrow notation in a more readable way? Or am I trying to do an impossible thing? To answer your question: Arrow notation has no support for what you want, so if you stick with it you will have to write the inner proc explicitly. However: The code may look much nicer, if you use applicative style for the outer computation using Applicative, Category and Profunctor [1]: test2 :: MyArr [Double] String test2 = repeat 100 rmap . liftA3 (,,) id y z where y = arr func1 z = job1 rmap i = lmap (\(xs, y, z) - xs !! i + y + z) (job3 (i * 2)) If you prefer, you can use arrow notation for the inner computation. [1]: http://hackage.haskell.org/package/profunctors Greets, Ertugrul -- Not to be or to be and (not to be or to be and (not to be or to be and (not to be or to be and ... that is the list monad. signature.asc Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [***SPAM***] Parallel Haskell Digest 11
Hi Eric (et Café), On Thu, Jul 5, 2012 at 5:13 PM, Eric Kow wrote: *[Everybody should write everything in Go?][m7] (28 May) Ryan Hayes posted a small [snippet of Go][go-snippet] showing how friendly he found it for writing concurrent programs, “No pthread... not stupid crap... just works!”. The program seems to create 4 threads which print out 1 to 100 each. What do Haskellers think? See the comments for some discussion between Haskell people like Simon Marlow, and some folks in the Go community about our respective approaches to the problem. [go-snippet]: https://gist.github.com/3010649 [m7]: https://plus.google.com/app/plus/mp/588/#~loop:view=activityaid=z13pwzbajpqeg3qmo23hgporhlywe1fd5 https://plus.google.com/app/plus/mp/588/#~loop:view=activityaid=z13pwzbajpqeg3qmo23hgporhlywe1fd5 [m8 The [m7] link didn't work for me, but the following appears to be the referenced thread: https://plus.google.com/10955911385859313/posts/FAmNTExSLtz Regards, Sean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [***SPAM***] Parallel Haskell Digest 11
Ooh, nice catch. Fixed on the HTML version. http://www.well-typed.com/blog/67 Subject line makes me wonder how often the digests get caught in people's spam filters Oh and while I'm at it, I'll take the opportunity to plug the PH Digest survey (I'll be annoying and make a reminder post just about the survey next week) http://goo.gl/bP2fn I didn't design it very well, particularly as I failed to give a clear question for people who don't read the digest. I think if you don't read the digest, the best thing for now is just to say so in the comments form. I may add a I read the Parallel Haskell Digest question if it helps later. On 6 Jul 2012, at 14:57, Sean Leather wrote: Hi Eric (et Café), On Thu, Jul 5, 2012 at 5:13 PM, Eric Kow wrote: *[Everybody should write everything in Go?][m7] (28 May) Ryan Hayes posted a small [snippet of Go][go-snippet] showing how friendly he found it for writing concurrent programs, “No pthread... not stupid crap... just works!”. The program seems to create 4 threads which print out 1 to 100 each. What do Haskellers think? See the comments for some discussion between Haskell people like Simon Marlow, and some folks in the Go community about our respective approaches to the problem. [go-snippet]: https://gist.github.com/3010649 [m7]: https://plus.google.com/app/plus/mp/588/#~loop:view=activityaid=z13pwzbajpqeg3qmo23hgporhlywe1fd5 The [m7] link didn't work for me, but the following appears to be the referenced thread: https://plus.google.com/10955911385859313/posts/FAmNTExSLtz Regards, Sean -- 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] Plain lambda inside banana brackets in the arrow notation
Dear Ertugrul, Thank you for your input. To answer your question: Arrow notation has no support for what you want, so if you stick with it you will have to write the inner proc explicitly. Oh. I was afraid of that. However: The code may look much nicer, if you use applicative style for the outer computation using Applicative, Category and Profunctor [1]: Thank you for the code. It looks much nicer than my code, which uses the arrow notation both for inner and outer computations. If you prefer, you can use arrow notation for the inner computation. This was a blind spot for me; I had not thought of mixing the arrow notation and the plain notation. This definitely helps writing a code when either the outer computation or the inner computation is simple. Unfortunately, sometimes both the outer computation and the inner computation involve many local variables, in which case I need the arrow notation for both, forcing me to write the inner proc explicitly inside the outer proc. If someone extends the arrow notation someday and makes this use case easier, that will be great. For now, avoiding the arrow notation for simple computations and writing two proc’s when both computations are complicated seems like a reasonable compromise to me. Thanks a lot! Best regards, Tsuyoshi ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [***SPAM***] Parallel Haskell Digest 11
On Fri, Jul 6, 2012 at 4:03 PM, Eric Kow wrote: Subject line makes me wonder how often the digests get caught in people's spam filters Oops! Should have removed that part before replying. I think it comes from the university's mail server, and it's rather obnoxious. I tend to ignore it. Since you're curious, I can tell you that two out of the eleven issues (9 was the other one) were tagged as spam. Regards, Sean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] combining predicates, noob question
As I was using predicates (a - bool) , it appeared the need for combining them with a boolean operator (bool - bool - bool) in order to get a new predicate combining the previous two. So I wrote my function combinerPred (see code below). While I think this is JUST ok, i'm feeling a monad in the air. So.. where is the monad? combinerPred :: (a - Bool) - (a - Bool) - (Bool - Bool - Bool) - (a - Bool) combinerPred pred1 pred2 op = \x - op (pred1 x) (pred2 x) thanks Sebastián ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Posting jobs on Haskellers.com
The link to the CUFP job posting is working now. (After I posted the previous message I found in my inbox an email telling me that the post will be live after it's been approved -- it is now). I was also able to post it on Haskellers ( http://www.haskellers.com/jobs/14 ). Posting on CUFP was easier and more convenient: they support HTML tags and preview. Haskellers needs to be improved (hopefully it should be a piece of cake with Yesod). We should be prepared for the incoming flood of Haskell jobs, if we do our job right, teaching and promoting Haskell. On Thursday, July 5, 2012 2:24:51 PM UTC-7, Bartosz Milewski wrote: There are no job postings on Haskellers.com and I'm wondering whether it's because you have to wait for the verified status before you can post (and that's after you have successfully verified your email). Posting the job on the CUFP site, on the other hand, was painless: http://cufp.org/jobs/haskell-systems-administrator . ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: lens-family 0.0.0
I'm pleased to announce the first release of lens-family-core and lens-family. This package provide first class(†) functional references. In addition to the usual operations of getting, setting and composition, plus integration with the state monad, lens families provide some unique features: * Polymorphic updating * Cast projection functions to read-only lenses * Cast semantic editor combinators to modify-only lenses (†) For optimal first-class support use the lens-family package with rank 2 / rank N polymorphism. Lens.Family.Clone allows for first-class support of lenses for those who require Haskell 98. -- Russell O'Connor http://r6.ca/ ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] ANNOUNCE: lens-family 0.0.0
Hackage links for anyone as lazy as myself =). http://hackage.haskell.org/package/lens-family-core http://hackage.haskell.org/package/lens-family -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] combining predicates, noob question
On Fri, Jul 6, 2012 at 2:11 PM, Sebastián Krynski skryn...@gmail.com wrote: As I was using predicates (a - bool) , it appeared the need for combining them with a boolean operator (bool - bool - bool) in order to get a new predicate combining the previous two. So I wrote my function combinerPred (see code below). While I think this is JUST ok, i'm feeling a monad in the air. So.. where is the monad? combinerPred :: (a - Bool) - (a - Bool) - (Bool - Bool - Bool) - (a - Bool) combinerPred pred1 pred2 op = \x - op (pred1 x) (pred2 x) That's the `(-) a` monad: import Control.Applicative combinerPred :: (a - Bool) - (a - Bool) - (Bool - Bool - Bool) - (a - Bool) combinerPred pred1 pred2 op = op $ pred1 * pred2 Cheers, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] combining predicates, noob question
On Fri, Jul 06, 2012 at 03:17:54PM -0300, Felipe Almeida Lessa wrote: On Fri, Jul 6, 2012 at 2:11 PM, Sebastián Krynski skryn...@gmail.com wrote: As I was using predicates (a - bool) , it appeared the need for combining them with a boolean operator (bool - bool - bool) in order to get a new predicate combining the previous two. So I wrote my function combinerPred (see code below). While I think this is JUST ok, i'm feeling a monad in the air. So.. where is the monad? combinerPred :: (a - Bool) - (a - Bool) - (Bool - Bool - Bool) - (a - Bool) combinerPred pred1 pred2 op = \x - op (pred1 x) (pred2 x) That's the `(-) a` monad: import Control.Applicative combinerPred :: (a - Bool) - (a - Bool) - (Bool - Bool - Bool) - (a - Bool) combinerPred pred1 pred2 op = op $ pred1 * pred2 By the way, I find it more natural to make 'op' the first argument, because it is more useful to partially apply combinerPred to an operation that it is to some predicates. Also, in that case combinerPred is simply liftA2: import Control.Applicative combinerPred :: (Bool - Bool - Bool) - (a - Bool) - (a - Bool) - (a - Bool) combinerPred = liftA2 -Brent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] vector, alignment and SIMD through FFI
Hello Cafe, Recently I've been playing with the implementation of an algorithm, for which we already have highly-optimized implementations available (in plain C/C++ as well as OCaml with calls to C through FFI). The algorithm works on buffers/arrays/vectors/whatever you want to call it, which needs to be combined in certain ways. This can be highly optimized by using SIMD instructions (like the ones provides by several SSE versions). I'd like to get a to Haskell version which is comparable in efficiency as the existing versions, whilst remaining as 'functional' as possible. I don't mind jumping into some low-level C glue and FFI (using ccall or custom primops), but this should be limited. Currently I have something working (still highly unoptimized) using (unboxed) vectors from the vector package, using mutable versions within a well-contained ST environment in some places. One hot zone of the current version is combining several vectors, and the performance of this operation could be greatly improved by using SIMD instructions. There's one catch though: when using these, memory should be aligned on certain boundaries (16 byte in this case). First and foremost, to be able to pass my vectors to some C functions, I should change my code into using Storable vectors (which should be fine, I guess I can expect similar performance characteristics?). I couldn't find any information on alignment guarantees of these vectors though... Which is how I get to my question: are there any such guarantees? If not, are there any pointers to how to proceed with this? I guess tracking alignment at the type level should be the goal, you can find some code trying to explain my reasoning up to now at the end of this email. I have some issues with this: - I'd need to re-implement almost all vector operations, which seems stupid. - It doesn't actually work right now ;-) - It'd be nice to be able to encode 'compatible' alignment: as an example, a 16 byte aligned buffer is also 8 byte aligned... I hope the above explains somewhat my goal. Any thoughts help on this would be very welcome! Thanks, Nicolas module Data.Vector.SIMD ( -- ... ) where import qualified Data.Vector.Storable as SV import Foreign.Storable (Storable, sizeOf) import Foreign.Ptr (Ptr, FunPtr) import Foreign.ForeignPtr (ForeignPtr, newForeignPtr) import System.IO.Unsafe (unsafePerformIO) class Alignment a where alignment :: a - Int data A8Byte instance Alignment A8Byte where alignment _ = 8 data A16Byte instance Alignment A16Byte where alignment _ = 16 newtype Alignment a = SIMDVector a b = V (SV.Vector b) replicate :: (Alignment a, Storable b) = a - Int - b - SIMDVector a b replicate a n b = V v where ptr = unsafePerformIO $ do v - _mm_malloc n (alignment a) -- memset etc return v v = SV.unsafeFromForeignPtr0 ptr n -- These are 2 _stub versions of the procedures since xmminstr.h (or mm_malloc.h -- when using GCC) contains them as inline procedures which are not available -- as-is in a library. There should be some C module which exports -- _mm_malloc_stub and _mm_free_stub, which simply includes xmminstr.h and calls -- the underlying procedures. foreign import ccall _mm_malloc_stub _mm_malloc_stub :: Int - Int - IO (Ptr a) foreign import ccall _mm_free_stub _mm_free_stub :: FunPtr (Ptr a - IO ()) _mm_malloc :: Storable a = Int - Int - IO (ForeignPtr a) _mm_malloc s l = do -- This fails: -- Ambiguous type variable `a0' in the constraint: -- (Storable a0) arising from a use of `sizeOf' -- v - c_mm_malloc (s * sizeOf (undefined :: a)) l newForeignPtr _mm_free_stub undefined -- This allocates a 16 byte aligned output buffer, takes 2 existing ones and -- calls some FFI function to perform some magic. -- The implementation could run inside ST, if the FFI import (which e.g. works -- on a mutable buffer and returns IO ()) is lifted into ST using unsafeIOToST mySIMDFun :: SIMDVector A16Byte a - SIMDVector A16Byte a - SIMDVector A16Byte a mySIMDFun a b = undefined ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] cabal equivalent to make -k?
When using make (or, at least, GNU make) the -k option keeps going as far as possible after a compilation error. It's handy during developing--for instance, I know half of my code is busted, but I just want to see if this file compiles. Is there a similar way to do this with cabal? Thanks. --Omari ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] vector, alignment and SIMD through FFI
On Fri, Jul 6, 2012 at 1:06 PM, Nicolas Trangez nico...@incubaid.com wrote: -- This fails: -- Ambiguous type variable `a0' in the constraint: -- (Storable a0) arising from a use of `sizeOf' Here you can either tie a type knot using proxy types or you can use the scoped type variable language extension. Perhaps I'm missing something specific to your use, but for the alignment issue you should be OK just calling allocBytes or one of its variants. I made some noise about this a bit ago and it resulted in some extra words in the report under mallocBytes: The block of memory is sufficiently aligned for any of the basic foreign types that fits into a memory block of the allocated size. Which I'm pretty sure GHC did, and still does, follow. Cheers, Thomas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] vector, alignment and SIMD through FFI
On Fri, Jul 6, 2012 at 1:43 PM, Thomas DuBuisson thomas.dubuis...@gmail.com wrote: The block of memory is sufficiently aligned for any of the basic foreign types that fits into a memory block of the allocated size. That's not the same thing as a guarantee of 16-byte alignment, note, as none of the standard foreign types have that requirement. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Call to arms: lambda-case is stuck and needs your help
On 05/07/2012, Mikhail Vorozhtsov mikhail.vorozht...@gmail.com wrote: Hi. After 21 months of occasional arguing the lambda-case proposal(s) is in danger of being buried under its own trac ticket comments. We need fresh blood to finally reach an agreement on the syntax. Read the wiki page[1], take a look at the ticket[2], vote and comment on the proposals! +1 for \ of multi-clause lambdas It looks like binding of to me, which it ain't, but it is nicely brief... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] translation between two flavors of lexically-scoped type variables
Thanks, I think I understand it now.
Do you know why they switched over in GHC 6.6?
-Kangyuan Niu
On Fri, Jul 6, 2012 at 3:11 AM, o...@okmij.org wrote:
Kangyuan Niu wrote:
Aren't both Haskell and SML translatable into System F, from which
type-lambda is directly taken?
The fact that both Haskell and SML are translatable to System F does
not imply that Haskell and SML are just as expressive as System
F. Although SML (and now OCaml) does have what looks like a
type-lambda, the occurrences of that type lambda are greatly
restricted. It may only come at the beginning of a polymorphic
definition (it cannot occur in an argument, for example).
data Ap = forall a. Ap [a] ([a] - Int)
Why isn't it possible to write something like:
fun 'a revap (Ap (xs : 'a list) f) = f ys
where
ys :: 'a list
ys = reverse xs
in SML?
This looks like a polymorphic function: an expression of the form
/\a.body has the type forall a. type. However, the Haskell function
revap :: Ap - Int
revap (Ap (xs :: [a]) f) = f ys
where
ys :: [a]
ys = reverse xs
you meant to emulate is not polymorphic. Both Ap and Int are concrete
types. Therefore, your SML code cannot correspond to the Haskell code.
That does not mean we can't use SML-style type variables (which must
be forall-bound) with existentials. We have to write the
elimination principle for existentials explicitly
{-# LANGUAGE ExistentialQuantification, RankNTypes #-}
{-# LANGUAGE ScopedTypeVariables #-}
data Ap = forall a. Ap [a] ([a] - Int)
-- Elimination principle
deconAp :: Ap - (forall a. [a] - ([a] - Int) - w) - w
deconAp (Ap xs f) k = k xs f
revap :: Ap - Int
revap ap = deconAp ap revap'
revap' :: forall a. [a] - ([a] - Int) - Int
revap' xs f = f ys
where
ys :: [a]
ys = reverse xs
Incidentally, GHC now uses SML-like design for type
variables. However, there is a special exception for
existentials. Please see
7.8.7.4. Pattern type signatures
of the GHC user manual. The entire section 7.8.7 is worth reading.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] vector, alignment and SIMD through FFI
On Fri, 2012-07-06 at 13:43 -0700, Thomas DuBuisson wrote: On Fri, Jul 6, 2012 at 1:06 PM, Nicolas Trangez nico...@incubaid.com wrote: -- This fails: -- Ambiguous type variable `a0' in the constraint: -- (Storable a0) arising from a use of `sizeOf' Here you can either tie a type knot using proxy types or you can use the scoped type variable language extension. Guess I'll have to do some reading ;-) Thanks. Perhaps I'm missing something specific to your use, but for the alignment issue you should be OK just calling allocBytes or one of its variants. I made some noise about this a bit ago and it resulted in some extra words in the report under mallocBytes: The block of memory is sufficiently aligned for any of the basic foreign types that fits into a memory block of the allocated size. Which I'm pretty sure GHC did, and still does, follow. Hmh... as far as I could find, mallocBytes basically does what malloc(3) does, which is 8-byte alignment if I'm not mistaken on my x86-64 Linux system. I could use those and the over-allocate-and-offset tricks, but... that's ugly unless strictly necessary ;-) Normally posix_memalign or memalign or valloc or _mm_malloc should provide what I need as-is. Except, when using those and vector's unsafeFromForeignPtr0, all I get is a Vector a, which no longer has any alignment information in the type, so I can't write a function which only accepts N-aligned vectors. As a result, I'd need to be very careful only to pass aligned vectors to it (checking manually), add code to handle pre/post-alignment bytes in my SIMD functions (slow and stupid), or live with it and let my application crash at random. I found some work by Oleg Kiselyov and Chung-chieh Shan at [1] which might be related, yet as of now I feel like that's too general for my purpose (e.g. I don't see how to integrate it with vector). Thanks, Nicolas [1] http://okmij.org/ftp/Haskell/types.html#ls-resources ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: lens-family-th 0.1.0.0
Following the announcement of lens-family, I'm pleased to announce lens-family-th 0.1.0.0, a Template Haskell library supplying macros to generate lens-family lenses for fields of data types declared with record syntax. Be warned that currently, type signatures are *not* generated alongside the lens definitions. Type inference should correctly determine the type of the generated lenses, but I have structured the library code so that in the future, type signatures can also be generated. Patches welcome! http://hackage.haskell.org/package/lens-family-th -- Dan Burton ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Call to arms: lambda-case is stuck and needs your help
Whoops, my earlier answer forgot to copy mailing lists... I would love to see \of, but I really don't think this is important enough to make case sometimes introduce layout and other times not. If it's going to obfuscate the lexical syntax like that, I'd rather just stick with \x-case x of. On Jul 6, 2012 3:15 PM, Strake strake...@gmail.com wrote: On 05/07/2012, Mikhail Vorozhtsov mikhail.vorozht...@gmail.com wrote: Hi. After 21 months of occasional arguing the lambda-case proposal(s) is in danger of being buried under its own trac ticket comments. We need fresh blood to finally reach an agreement on the syntax. Read the wiki page[1], take a look at the ticket[2], vote and comment on the proposals! +1 for \ of multi-clause lambdas It looks like binding of to me, which it ain't, but it is nicely brief... ___ 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] ANNOUNCE: husk-scheme, release 3.5.6
I would like to announce the release of husk-scheme 3.5.6, a Scheme extension language and stand-alone interpreter/compiler that I have been developing. husk implements most of the Scheme R5RS standardhttp://www.schemers.org/Documents/Standards/R5RS/HTML/including advanced features such as continuations, hygienic macros, and a full numeric tower. husk has been an ongoing project for over a year now, but this is the first announcement on the mailing list so feedback is very welcome. Hackage: http://hackage.haskell.org/package/husk-scheme Homepage: http://justinethier.github.com/husk-scheme Change Log: https://github.com/justinethier/husk-scheme/blob/master/ChangeLog.markdown Issues and Enhancement Requests: https://github.com/justinethier/husk-scheme/issues Thanks, Justin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Parameterized constraints
Hi! The `constraints` package provides ways to manipulate objects of kind `Constraint`. I need the same kind of manipulation, except that I need to work with objects of kind `* - Constraint`. I.e. I need parameterized constraints that can be applied to different types. BTW, is there a standard term for things of kind `* - Constraint`? I have a type family type family Constr (f :: * - *) :: * - Constraint which returns a parameterized constraint with the property that any value of type `f a` fulfills the constraint `Constr f a`. Since the constraint can be stronger than needed, I need something similar to `:-` from `constraints`, except it should operate on parameterized constraints. I have implemented the stuff I need (see below), but my question is if it's possible to do this with the `constraints` package directly (e.g. using `Forall`). I'm afraid I can't see how. Here is what I've come up with so far: -- Instead of (c1,c2) class(c1 a, c2 a) = (c1 :/\: c2) a instance (c1 a, c2 a) = (c1 :/\: c2) a -- Instead of (:-) type sub : sup = forall a . Dict (sup a) - Dict (sub a) -- Instead of weaken1 weak1 :: c1 : (c1 :/\: c2) weak1 Dict = Dict weak2 :: c2 : (c1 :/\: c2) weak2 Dict = Dict Thanks! -- / Emil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
