Re: Bogus stats when running SMP programs
Tomasz Zielonka wrote: On Tue, Sep 26, 2006 at 01:46:30AM +0100, Ian Lynagh wrote: I couldn't reproduce this with a simple program that forked off 4 threads to do computation on a single CPU machine, and neither could someone on IRC with head from Sep 15 on a Core Duo. Is it possible to send us a small example program along with exactly what flags you used to compile and run it please? It turns out it happens even with the simplest program: main = return Compilation command: ghc -threaded --make B -o B Running: [EMAIL PROTECTED]:~/src/par$ ./B +RTS -sstderr ./B +RTS -sstderr 21,864 bytes allocated in the heap 1,404 bytes copied during GC (scavenged) 4,156 bytes copied during GC (not scavenged) 21,936 bytes maximum residency (1 sample(s)) 1 collections in generation 0 ( 0.00s) 1 collections in generation 1 ( 0.00s) 1 Mb total memory in use Task 0 (worker) : MUT time: 402094045.13s ( 0.00s elapsed) GC time: 0.00s ( 0.00s elapsed) Task 1 (worker) : MUT time: 200.00s ( 0.00s elapsed) GC time: 0.00s ( 0.00s elapsed) Task 2 (worker) : MUT time: 0.00s ( 0.00s elapsed) GC time: 0.00s ( 0.00s elapsed) INIT time0.00s ( 0.00s elapsed) MUT time0.00s ( 0.00s elapsed) GCtime0.00s ( 0.00s elapsed) EXIT time0.00s ( 0.00s elapsed) Total time0.00s ( 0.00s elapsed) %GC time 0.0% (11.5% elapsed) Alloc rate21,864,000,000 bytes per MUT second Productivity 100.0% of total user, 0.2% of total elapsed It doesn't happen when I compile without -threaded. But it doesn't show task statistics then. Perhaps clock_gettime() is returning strange results on your system. Could you try compiling with -threaded -debug, and run the program under gdb. Set a breakpoint in getThreadCPUTime(), and take a look at what gets returned by clock_gettime(). Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #16: Extensionsflags
#16: Extensionsflags --+- Reporter: axelkr | Owner: igloo Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler |Version: None Severity: minor| Resolution: None Keywords: | Os: Unknown Difficulty: Unknown | Architecture: Unknown --+- Changes (by igloo): * architecture: = Unknown * difficulty: = Unknown * status: assigned = new * owner: nobody = igloo * os: = Unknown Comment: I think this is more important now that we are telling cabal what extensions we are using, but even if we get it wrong then building the cabal package will still work as cabal ends up passing -fglasgow-exts for most extensions. I'll look into it. Thanks Ian -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/16 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] #905: the `impossible' happened: ASSERT failed! file codeGen/ClosureInfo.lhs, line 596
#905: the `impossible' happened: ASSERT failed! file codeGen/ClosureInfo.lhs,
line 596
--+-
Reporter: Misha Aizatulin [EMAIL PROTECTED] | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler |Version: 6.4.2
Severity: normal | Resolution:
Keywords: | Os: Linux
Difficulty: Unknown | Architecture: x86
--+-
Comment (by simonmar):
This line:
{{{
SRC_HC_OPTS = -H32m -O -fasm -Rghc-timing -prof -auto-all
}}}
will cause ''everything'' to be built with profiling: the stage 1
compiler, the libraries, the util programs (hsc2hs etc.) and the stage 2
compiler. I'd expect something to go wrong because GHC won't expect the
normal libraries to be built for profiling.
Still, the crash is bad, so we should investigate at some point.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/905
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: Summary of GHC 6.6 test suite failures on MSYS/MinGW
Brian Smith wrote: On 9/26/06, *Simon Marlow* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Brian Smith wrote: The test always failed. When I decreased the number of threads in the test from 5,000 to 1,400 or so, then the tests passed sometimes, and sometimes failed. Decreasing the number of threads to under a thousand made the test pass consistently. IIRC, the test failed almost immediately upon executing. conc023 creates 5000 threads that all do threadDelay with varying delays. On Windows, with both the threaded and non-threaded runtimes, this results in 5000 OS threads being created, which is usually enough to fill up your VM. I intend to fix this, at least in the threaded RTS, in fact it'll be part of the fix for http://hackage.haskell.org/trac/ghc/ticket/637. The I/O manager thread handles sleeps and signals, but currently isn't implemented on Windows. It already passes in the threaded RTS and every other way except GHCi: normal, opt, optasm, prof, profasm, threaded1, and threaded2. That is what I thought was strange. It's slightly odd that the test only runs out of memory in GHCi, but I doubt there's anything GHCi-specific about the problem, just probably GHCi needs more memory full stop. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #910: --make should have a -j flag for parallel building
#910: --make should have a -j flag for parallel building
--+-
Reporter: igloo| Owner:
Type: feature request | Status: new
Priority: normal | Milestone: 6.8
Component: Driver |Version: 6.4.2
Severity: normal | Resolution:
Keywords: | Os: Multiple
Difficulty: Unknown | Architecture: Multiple
--+-
Comment (by simonmar):
This seems like a good place to hang my patch to implement {{{ghc --make
-jN}}}, which was used for the experiments in the 2005 Haskell Workshop
paper on SMP GHC, but almost certainly isn't ready for prime time.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/910
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] #880: someFunction :: TypeRep - Int
#880: someFunction :: TypeRep - Int --+- Reporter: guest| Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base |Version: 6.4.2 Severity: normal | Resolution: Keywords: | Os: Unknown Difficulty: Easy (1 hr) | Architecture: Unknown --+- Comment (by simonmar): Done. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/880 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] #880: someFunction :: TypeRep - Int
#880: someFunction :: TypeRep - Int --+- Reporter: guest| Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: libraries/base |Version: 6.4.2 Severity: normal | Resolution: fixed Keywords: | Os: Unknown Difficulty: Easy (1 hr) | Architecture: Unknown --+- Changes (by simonmar): * resolution: = fixed * status: new = closed -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/880 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] #911: Better information about the location of exceptions
#911: Better information about the location of exceptions
+---
Reporter: simonmar |Owner:
Type: feature request | Status: new
Priority: normal |Milestone:
Component: Runtime System | Version: 6.4.2
Severity: normal | Keywords:
Os: Unknown | Difficulty: Unknown
Architecture: Unknown |
+---
From Frederik Eaton, on glasgow-haskell-bugs:
I think it would be a good idea to print instructions for getting more
information when a program fails with a pattern match or other error.
Rather than
{{{
foo: Prelude.undefined
}}}
it should say
{{{
foo: Prelude.undefined
For information about the location of this error, recompile with -prof
-auto-all and run with +RTS -xc -RTS
}}}
Also, maybe these instructions aren't enough? When I do the above, it
just prints
{{{
GHC.Err.CAFGHC.Err.CAFGHC.Err.CAFGHC.Err.CAFfoo: Prelude.undefined
}}}
which isn't what I was looking for... Am I forgetting an option or
something?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/911
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: Bogus stats when running SMP programs
On Wed, Sep 27, 2006 at 09:25:39AM +0100, Simon Marlow wrote: Perhaps clock_gettime() is returning strange results on your system. Could you try compiling with -threaded -debug, and run the program under gdb. When I compile with -threaded -debug, the stats are OK :-/ Best regards Tomasz ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Bogus stats when running SMP programs
Tomasz Zielonka wrote: On Wed, Sep 27, 2006 at 09:25:39AM +0100, Simon Marlow wrote: Perhaps clock_gettime() is returning strange results on your system. Could you try compiling with -threaded -debug, and run the program under gdb. When I compile with -threaded -debug, the stats are OK :-/ Ok, maybe try strace? Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Bogus stats when running SMP programs
On Wed, Sep 27, 2006 at 12:06:34PM +0100, Simon Marlow wrote:
When I compile with -threaded -debug, the stats are OK :-/
Ok, maybe try strace?
Nothing suspicious, at least for me. Strace logs attached.
I'll try to compile GHC from sources and put some debugging
prints in the RTS. There aren't too many places where Task's
mut_time field is referenced. I just hope it's not some
other code overwriting this memory.
Best regards
Tomasz
execve(./B, [./B, +RTS, -sstderr], [/* 22 vars */]) = 0
uname({sys=Linux, node=gfs6, ...}) = 0
brk(0) = 0x8082000
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xa7f23000
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=17489, ...}) = 0
mmap2(NULL, 17489, PROT_READ, MAP_PRIVATE, 3, 0) = 0xa7f1e000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/lib/tls/libm.so.6, O_RDONLY)= 3
read(3,
\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`3\0\0004\0\0\0`B\2\0\0\0\0\0004\0
\0\10\0(\0\36\0\35\0\6\0\0\0004\0\0\0004\0\0\0004\0\0\0\0\1\0\0\0\1\0\0\5\0\0\0\4\0\0\0\3\0\0\0\370\2\0\370\2\0\370\2\0\23\0\0\0\23\0\0\0\4\0\0\0\1\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\20=\2\0\20=\2\0\5\0\0\0\0\20\0\0\1\0\0\0\344\2\0\344N\2\0\344N\2\0x\1\0\0\274\1\0\0\6\0\0\0\0\20\0\0\2\0\0\0\370\2\0\370N\2\0\370N\2\0\340\0\0\0\340\0\0\0\6\0\0\0\4\0\0\0\4\0\0\0004\1\0\0004\1\0\0004\1\0\0
\0\0\0
\0\0\0\4\0\0\0\4\0\0\0Q\345td\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\6\0\0\0\4\0\0\0R\345td\344\2\0\344N\2\0\344N\2\0\20\1\0\0\20\1\0\0\4\0\0\0\4\0\0\0\4\0\0\0\20\0\0\0\1\0\0\0GNU\0\0\0\0\0\2\0\0\0\6\0\0\0\0\0\0\0]\2\0\0`\1\0\0\216\0\0\0_\1\0\0\205\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\250\0\0\0\0\0\0\0\0\0\0\0N\1\0\0\0\0\0\0A\1\0\0\0\0\0\0\0\0\0\0\370\0\0\0\304\0\0\0\32\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\277\0\0\0\325\0\0\0\371\0\0\0\0\0\0\0\0\0\0\0?\0\0\0\0\0\0\0F\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0)\1\0\0\1\0\0\0\0\0\0\r\1\0\0\0\0\0\0\0\0\0\0,
512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=149264, ...}) = 0
mmap2(NULL, 151712, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xa7ef8000
mmap2(0xa7f1c000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x23) = 0xa7f1c000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/lib/tls/libdl.so.2, O_RDONLY) = 3
read(3, [EMAIL PROTECTED]
\0\10\0(\0\33\0\32\0\6\0\0\0004\0\0\0004\0\0\0004\0\0\0\0\1\0\0\0\1\0\0\5\0\0\0\4\0\0\0\3\0\0\0\252\32\0\0\252\32\0\0\252\32\0\0\23\0\0\0\23\0\0\0\4\0\0\0\1\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\304\32\0\0\304\32\0\0\5\0\0\0\0\20\0\0\1\0\0\0\324\36\0\0\324.\0\0\324.\0\0|\1\0\0\240\1\0\0\6\0\0\0\0\20\0\0\2\0\0\0\354\36\0\0\354.\0\0\354.\0\0\340\0\0\0\340\0\0\0\6\0\0\0\4\0\0\0\4\0\0\0004\1\0\0004\1\0\0004\1\0\0
\0\0\0
\0\0\0\4\0\0\0\4\0\0\0Q\345td\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\6\0\0\0\4\0\0\0R\345td\324\36\0\0\324.\0\0\324.\0\0
\1\0\0
\1\0\0\4\0\0\0\4\0\0\0\4\0\0\0\20\0\0\0\1\0\0\0GNU\0\0\0\0\0\2\0\0\0\6\0\0\0\0\0\0\0A\0\0\0002\0\0\0\35\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0-\0\0\0\r\0\0\0\22\0\0\0\33\0\0\0/\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0$\0\0\0\21\0\0\0\31\0\0\0\17\0\0\0#\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0.\0\0\0\0\0\0\0\16\0\0\0\24\0\0\0\0\0\0\0)\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0001\0\0\0\0\0\0\0\0\0\0\0\f\0\0\0,
512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=9592, ...}) = 0
mmap2(NULL, 12404, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xa7ef4000
mmap2(0xa7ef6000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xa7ef6000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/lib/tls/librt.so.1, O_RDONLY) = 3
read(3,
\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\35\0\0004\0\0\0\274r\0\0\0\0\0\0004\0
\0\t\0(\0\37\0\36\0\6\0\0\0004\0\0\0004\0\0\0004\0\0\0 \1\0\0
\1\0\0\5\0\0\0\4\0\0\0\3\0\0\0\214]\0\0\214]\0\0\214]\0\0\23\0\0\0\23\0\0\0\4\0\0\0\1\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\352_\0\0\352_\0\0\5\0\0\0\0\20\0\0\1\0\0\0\320n\0\0\320n\0\0\320n\0\0\270\2\0\0\200\3\0\0\6\0\0\0\0\20\0\0\2\0\0\0\354n\0\0\354n\0\0\354n\0\0\360\0\0\0\360\0\0\0\6\0\0\0\4\0\0\0\4\0\0\0T\1\0\0T\1\0\0T\1\0\0
\0\0\0
\0\0\0\4\0\0\0\4\0\0\0P\345td\240]\0\0\240]\0\0\240]\0\0\\\0\0\0\\\0\0\0\4\0\0\0\4\0\0\0Q\345td\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\6\0\0\0\4\0\0\0R\345td\320n\0\0\320n\0\0\320n\0\0$\1\0\0$\1\0\0\4\0\0\0\4\0\0\0\4\0\0\0\20\0\0\0\1\0\0\0GNU\0\0\0\0\0\2\0\0\0\6\0\0\0\0\0\0\0\331\0\0\0~\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0
Re: [GHC] #887: GHCi prints results of IO actions
#887: GHCi prints results of IO actions
--+-
Reporter: guest| Owner:
Type: bug | Status: closed
Priority: normal | Milestone:
Component: GHCi |Version: 6.5
Severity: normal | Resolution: fixed
Keywords: | Os: Linux
Difficulty: Unknown | Architecture: x86
--+-
Changes (by simonmar):
* resolution: = fixed
* status: new = closed
Comment:
Done; to disable the printing behaviour for bindings, use
{{{
:set -fno-print-bind-result
}}}
in GHCi (or -fno-print-bind-result on the command line).
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/887
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] #806: hGetBufNonBlocking doesn't work with -threaded on Windows
#806: hGetBufNonBlocking doesn't work with -threaded on Windows -+-- Reporter: [EMAIL PROTECTED] | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: libraries/base |Version: 6.4.2 Severity: normal | Resolution: Keywords: | Os: Windows Difficulty: Unknown | Architecture: x86 -+-- Changes (by simonmar): * milestone: 6.6 = 6.6.1 Comment: I've made it not crash now. It still doesn't have the right non-blocking behaviour, but that'll have to wait. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/806 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] #912: Build system is missing various dependencies
#912: Build system is missing various dependencies
-+--
Reporter: simonmar |Owner:
Type: bug | Status: new
Priority: normal|Milestone:
Component: Build System | Version: 6.5
Severity: normal| Keywords:
Os: Multiple | Difficulty: Unknown
Architecture: Multiple |
-+--
The build system is missing dependencies, which means that if you change
something and recompile, you don't always get a working build. The most
common problem is to issue a {{{darcs-all pull}}} followed by {{{make}}},
which may well result in a broken build depending on what changes were
pulled.
I'm creating this ticket to keep track of the dependencies that we know
are missing, so that maybe one day they could be fixed.
* re-configuring with a new {{{--prefix}}} will not cause the various
tools
and scripts that depend on prefix to be rebuilt.
* package dependencies are not mirrored in the build system: rebuilding
base
doesn't cause all the other packages to be rebuilt, for example.
The following are probably not feasible/desirable to fix:
* stage 2 doesn't have a dependency on the packages.
* the packages don't have a dependency on the .hi file format
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/912
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] #710: library reorganisation
#710: library reorganisation
-+--
Reporter: simonmar| Owner:
Type: task| Status: new
Priority: normal | Milestone: 6.8
Component: libraries/base |Version: 6.4.1
Severity: normal | Resolution:
Keywords: | Os: Multiple
Difficulty: Unknown | Architecture: Multiple
-+--
Changes (by igloo):
* architecture: Unknown = Multiple
* milestone: = 6.8
* os: Unknown = Multiple
Comment:
I spent some time looking at this. There are a number of issues that need
to be resolved, or at least it would be better if they could be resolved
first:
* Problem using `--make` when compiling the base package ([ticket:
#909]).
* We'd lose the ability to do parallel module building within each
library ([ticket: #910]).
* Currently the implementations don't agree on what `Read` is, as the new
`ReadP` requires rank-2 or rank-n polymorphism. I am told Haskell' will
have one or the other, so this will come in time.
* The code used by default class definitions needs to be pretty low down
in the hierarchy, and in particular `fail s = error s` in the `Monad`
class pulls in the huge exception type. This might be simplified with an
extensible exception replacement?
* For the deps from common packages to impl-specific packages we
obviously need some sort of conditional support in Cabal.
* Standalone deriving declarations (separate from the data declaration)
make some things a lot easier. I think bringert has a working
implementation for GHC, but it only truly helps if it's in all impls;
something for Haskell'?
* It's unfortunate that we can't make imported and exported class
instances explicit, so the compiler won't be checking that we are giving
consistency across impls.
In what follows, I haven't given a huge amount of thought to names, but I
don't think there's any need to do so yet.
My conclusions were that ultimately something like this would be good
(with impl replaced with ghc, hugs, ...):
* `impl-prim` at the bottom; defines things like the `Int` type
(basically all the types and functions needed by the next layer.
* `base-types-classes` next, which just have class declarations but
probably no instances.
* `impl-base next`; This is where all GHC's instances with `I#`'s etc
would go.
* `base` on top of that, with anything that can't be forked off into
another package.
I also managed to fork off
* `array`
* `containers` (`Data.{FunctorM, Foldable, Graph, IntMap, IntSet, Map,
Set, Queue, Sequence, Tree, Traversable`)
* `bytestring`
* `printf`
and it also looked plausible that `io` and/or `concurrency` would also be
able to be pulled out, but by that point I had run into enough of the
issues above that I stopped working on it. The rest can be looked at in
more detail when we come to do this for real.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/710
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: Bogus stats when running SMP programs
On Thu, Sep 21, 2006 at 08:03:53PM +0200, Tomasz Zielonka wrote: Hello! I am getting nonsensical execution statistics (+RTS -Sstderr) when running programs in SMP mode (+RTS -N2). I've found a machine which had the same problem. I think I've fixed it with Thu Sep 28 00:46:30 BST 2006 Ian Lynagh [EMAIL PROTECTED] * Handle clock_gettime failing Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #867: Integer arithmetic gives the wrong answer on amd64/Linux
#867: Integer arithmetic gives the wrong answer on amd64/Linux
---+
Reporter: igloo | Owner:
Type: bug | Status: closed
Priority: normal| Milestone:
Component: Compiler |Version: 6.4.1
Severity: normal| Resolution: fixed
Keywords:| Os: Linux
Difficulty: Unknown | Architecture: x86_64 (amd64)
---+
Changes (by igloo):
* resolution: = fixed
* status: new = closed
Comment:
Fixed by:
{{{
Thu Sep 28 01:48:06 BST 2006 Ian Lynagh [EMAIL PROTECTED]
* Fix mulIntMayOflo on 64-bit arches; fixes trac #867
We were assuming we could multiply 2 32-bit numbers without overflowing
a 64-bit number, but we can't as the top bit is the sign bit.
}}}
Test is arith019.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/867
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: Summary of GHC 6.6 test suite failures on MSYS/MinGW
On 9/26/06, Simon Marlow [EMAIL PROTECTED] wrote: Brian Smith wrote: Now, when I tried to rerun the tests against the latest ghc-6.6, ghc.exe is segfaulting on ffi012(ghci), conc049(ghci), and conc023(ghci): Unhandled exception at 0x0207fc58 in ghc.exe: 0xC005: Access violation.That's a bit worrying...This is caused by Data Execution Prevention. When I disable DEP for stage2/ghc.exe, these programs do not segfault; instead ff012 and conc023 fail while conc049 passes. When I enable DEP, all three segfault. http://hackage.haskell.org/trac/ghc/ticket/885 seems to be the relevant issue. I am using a Core Duo processor instead of an Athlon, but the gist is the same. The reason I did not notice this earlier was because I just turned on DEP for all programs in the days between the first time I ran the test suite against 6.6 and this most recent time. Regards,Brian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: UTF-8 decoding error
Fortress (sun's possibly-not-vaporware hpc language) supports arbitrary
unicode chars in code, and has an escape syntax for commonly used things.
Similarly, proof-general/isabelle supports tex-style escapes for symbols
greek. It seems to me that a pre-processor that turns human-friendly escapes
(e.g. \{lambda} rather than some magic number) into unicode and a slightly
intelligent IDE (or emacs mode?) would go most of the way to letting us use
up-side-down ys and curly as with all the visual beauty and editor niceness
that we have now with ascii.
Matthew
On Wednesday 20 September 2006 21:42, Duncan Coutts wrote:
On Wed, 2006-09-20 at 18:14 +0200, Christian Maeder wrote:
How can I convince ghc version 6.5.20060919 to accept latin1 characters
in literals?
I wish to keep source files (containing umlauts in strings) that can be
compiled by either ghc-6.4.2 and ghc-6.6.
You can use numeric escapes like \222.
Duncan
___
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[2]: Year 2038 problem in GHC 6.4.2 runtime
Hello Cyril, Tuesday, September 26, 2006, 1:30:23 AM, you wrote: I am afraid I would need the new Time library a little earlier than 2038, because I am working on financial software where it is not uncommon to have contracts over 30 years long. of course i'm joking. i even don't known is this library solves this problem or not Is the new Time library available for download? http://semantic.org/TimeLib/ moreover, it will be bundled with ghc 6.6 -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: more extra-libs for ghc 6.6
Bulat Ziganshin wrote: how about adding to the list of extra libs the following very useful ones: regex-* FilePath MissingH Edison Let me echo what Ian said: the idea with extralibs was not to bundle useful stuff with GHC, but rather to *separate* from GHC as many of the bundled libraries as we can. In the future we will probably drop extralibs altogether - it's only purpose is to reduce the surprise level for people used to all the bundled libs in GHC 6.4.2. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: bug in mallocForeignPtrBytes (both 6.4 and 6.6)
Duncan Coutts wrote: On Sun, 2006-09-24 at 01:28 +0400, Bulat Ziganshin wrote: Hello Duncan, Sunday, September 24, 2006, 12:22:38 AM, you wrote: after program prints 40 mb allocated look at Task Manager indication - it shows that two times more memory actually in use. it seems that problem is only with allocating memory buffers whose sizes are powers of 2 or very close - bug shows for bufsize = 4kb, 1mb or 4095, but not not for 4000 or 10^6 The reason for this is that for larger objects ghc has an allocation granularity of 4k. That is it always uses a multiple of 4k bytes. with 512k blocks it also allocates two times more data than requested. Oh, sorry I missed that point. Something fishy is going on then. Duncan's explanation works for allocating 4k, but there's another explanation for larger blocks. GHC allocates memory from the OS in units of a megablock (see http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage), currently 1Mb. So if you allocate a 1Mb array, the storage manager has to allocate 1Mb + overhead, which will cause it to allocate a 2Mb megablock. The surplus will be returned to the system in the form of free blocks, but if all you do is allocate lots of 1Mb arrays, you'll waste about half the sapce because there's never enough contiguous free space to contain another 1Mb array. Similar problem for 512k arrays: the storage manager allocates a 1Mb block, and returns slightly less than half of it as free blocks, so each 512k allocation takes a whole new 1Mb block. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.6 Release Candidate
Christian Maeder wrote: Simon Marlow schrieb: Only a week late, we are pleased to announce the Release Candidate phase for GHC 6.6. Snapshots beginning with 6.5.20060831 are release candidates for 6.6 Download snapshots from here: http://www.haskell.org/ghc/dist/current/dist/ I've downloaded the source bundle ghc-6.5.20060918-src.tar.bz After ./configure and make, I realized that I have no root permissions for installation. So called ./configure --prefix=/local/home/maeder/ghc-6.5 followed by make and make install only to find out that /usr/local/lib/ghc-6.5.20060918/ghc-6.5.20060918 cannot be found by my /local/home/maeder/ghc-6.5/bin/ghc (in line 5). What do I have to clean after configure with a new prefix? (I hope not everything. And I hope it works at all with a different prefix) I think this is just because you tried to re-configure with a new prefix after the first failed installation, and the (slightly hacky) binary distribution Makefile didn't know to re-generate the scripts. If you unpacked the distribution and tried from scratch with a new prefix, it should work. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.6 Release Candidate
Simon Marlow schrieb: Christian Maeder wrote: I've downloaded the source bundle ghc-6.5.20060918-src.tar.bz After ./configure and make, I realized that I have no root permissions for installation. So called ./configure --prefix=/local/home/maeder/ghc-6.5 followed by make and make install only to find out that /usr/local/lib/ghc-6.5.20060918/ghc-6.5.20060918 cannot be found by my /local/home/maeder/ghc-6.5/bin/ghc (in line 5). What do I have to clean after configure with a new prefix? (I hope not everything. And I hope it works at all with a different prefix) I think this is just because you tried to re-configure with a new prefix after the first failed installation, and the (slightly hacky) binary distribution Makefile didn't know to re-generate the scripts. If you unpacked the distribution and tried from scratch with a new prefix, it should work. You're right, I re-configured with a new prefix. (I never tried to install with the wrong prefix but only called make in the sources.) Rather than recompiling the whole sources I grabbed a new binary distribution from the dist site. So I solved my problem but it discouraged me to compile the ghc sources (again). Aren't there just a few spots to be removed to allow changing the prefix? Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: bug in mallocForeignPtrBytes (both 6.4 and 6.6)
I added notes about this to http://haskell.org/haskellwiki/Performance/GHC S | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] | On Behalf Of Simon Marlow | Sent: 27 September 2006 13:44 | To: Duncan Coutts | Cc: glasgow-haskell-users@haskell.org | Subject: Re: bug in mallocForeignPtrBytes (both 6.4 and 6.6) | | Duncan Coutts wrote: | On Sun, 2006-09-24 at 01:28 +0400, Bulat Ziganshin wrote: | | Hello Duncan, | | Sunday, September 24, 2006, 12:22:38 AM, you wrote: | | | after program prints 40 mb allocated look at Task Manager indication | - it shows that two times more memory actually in use. it seems that | problem is only with allocating memory buffers whose sizes are powers | of 2 or very close - bug shows for bufsize = 4kb, 1mb or 4095, but not | not for 4000 or 10^6 | | The reason for this is that for larger objects ghc has an allocation | granularity of 4k. That is it always uses a multiple of 4k bytes. | | with 512k blocks it also allocates two times more data than requested. | | Oh, sorry I missed that point. Something fishy is going on then. | | Duncan's explanation works for allocating 4k, but there's another explanation | for larger blocks. GHC allocates memory from the OS in units of a megablock | (see http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage), currently | 1Mb. So if you allocate a 1Mb array, the storage manager has to allocate 1Mb + | overhead, which will cause it to allocate a 2Mb megablock. The surplus will be | returned to the system in the form of free blocks, but if all you do is allocate | lots of 1Mb arrays, you'll waste about half the sapce because there's never | enough contiguous free space to contain another 1Mb array. Similar problem for | 512k arrays: the storage manager allocates a 1Mb block, and returns slightly | less than half of it as free blocks, so each 512k allocation takes a whole new | 1Mb block. | | Cheers, | Simon | ___ | 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: compiler-independent core libraries infrastructure
On Fri, Sep 15, 2006 at 05:20:36PM +0100, Ian Lynagh wrote: As it happens I was working on getting GHC to use cabal to build base et al on the plane the other day, and I had a brief look at this. See my comment in http://hackage.haskell.org/trac/ghc/ticket/710 for the results of my longer look at this. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
more fixups for GHC docs: ddump flags
The flags under section 4.17.26. Compiler debugging options seem to be out of date. They seem to be wrong for both 6.42 and 6.6 For example --ddump-cmm is not listed, but works. But --ddump-absC is listed, and gives the error unknown flag. I can't get -ddump-stix to work either. Gone, or renamed, or only works in combination with other flags? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: UTF-8 decoding error
On Sep 27, 2006, at 6:05 AM, Matthew Pocock wrote:
Fortress (sun's possibly-not-vaporware hpc language) supports
arbitrary
unicode chars in code, and has an escape syntax for commonly used
things.
I have spent the past week writing Fortress code (which runs in
parallel, even). But I'm perhaps a special case. :-)
Similarly, proof-general/isabelle supports tex-style escapes for
symbols
greek. It seems to me that a pre-processor that turns human-
friendly escapes
(e.g. \{lambda} rather than some magic number) into unicode and a
slightly
intelligent IDE (or emacs mode?) would go most of the way to
letting us use
up-side-down ys and curly as with all the visual beauty and editor
niceness
that we have now with ascii.
In Fortress we spent a *lot* of effort making the TWiki syntax as
painless as possible for stuff which we planned to use often (for
example, - and = turn into Unicode arrows, and the language syntax
is defined in terms of them). One source of both encouragement and
frustration is the fact that every unicode code point has an
associated description. We support using these descriptions---and
various shortenings of them, since they are too verbose for day-to-
day use. The frustration is that the names or their shortenings are
not necessarily unique. For characters which only occur in strings
this is less critical, but a little effort will go a long way.
One heuristic we've used is: if I do a diff on the ASCII
representation provided by my version control system, will I be able
to read the result?
We of course have a little program which processes an official
unicode character table (downloaded from the web) plus some
information about our special cases and uses it to generate the
appropriate conversion functions. This is important because Unicode
is constantly changing (mostly getting bigger).
-Jan-Willem Maessen
Fortress developer, Haskell hacker
Matthew
On Wednesday 20 September 2006 21:42, Duncan Coutts wrote:
On Wed, 2006-09-20 at 18:14 +0200, Christian Maeder wrote:
How can I convince ghc version 6.5.20060919 to accept latin1
characters
in literals?
I wish to keep source files (containing umlauts in strings) that
can be
compiled by either ghc-6.4.2 and ghc-6.6.
You can use numeric escapes like \222.
Duncan
___
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
smime.p7s
Description: S/MIME cryptographic signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] Deferred instance declarations (serialization of existential boxes)
Simon Peyton-Jones wrote: Concerning your application | I am having a box like | data Box = forall a. Cxt a = Box a | and want to write a Read instances for it. I don’t see how it helps to defer the Read instance. I would defer the instance declaration till the point where I know all types that will ever go into the box (for instance in my Main module). The Show instance of Box would write the representation of a together with it's type (this means Cxt should contain at least Show and Typeable). The Read instance will then contain something like String aType- lexP result - case aType of [Int] - (readPrec :: ReadPrec [Int]) = (return . Box) SomeOtherType - (readPrec :: ReadPrec SomeOtherType) = (return . Box) -- more of such cases _ - error (aType ++ cannot be read inside of Box) Not very elegant of course, but it seems to be the only way to Read existentials. But I think the case is stronger for top-level constraints, and I will bear it in mind. If you would like to open a Trac feature request, please do so. Ok, I will. Cheers, Misha ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] Haskell Weekly News: September 27, 2006
--- Haskell Weekly News http://haskell.org/haskellwiki/HWN Issue 42 - September 27, 2006 --- Welcome to issue 42 of HWN, a weekly newsletter covering developments in the Haskell community. Each week, new editions are posted to [1]the Haskell mailing list as well as to [2]the Haskell Sequence and [3]Planet Haskell. [4]RSS is also available, and headlines appear on [5]haskell.org. This week we see a new Hugs release, and the results of the ICFP contest are out! We feature a special report on the Commercial Users of Functional Programming workshop, courtesy of John Hughes 1. http://www.haskell.org/mailman/listinfo/haskell 2. http://sequence.complete.org/ 3. http://planet.haskell.org/ 4. http://sequence.complete.org/node/feed 5. http://haskell.org/ Announcements * ICFP Contest Results. CMU's Principles of Programming Group [6]announced the results of this year's [7]ICFP programming contest. Congratulations to the winning team from Google, 'Team Smartass', (Christopher Hendrie, Derek Kisman, Ambrose Feinstein and Daniel Wright), who used Haskell along with C++, Bash and Python. Haskell has now been used by the winning team three years running! An honourable mention to team Lazy Bottoms, another Haskell team, who managed to crack several of the puzzles first. Five teams from the [8]#haskell IRC channel were [9]placed in the top 50. A video stream of the results announcement is [10]available, shot and cut by Malcolm Wallace. Many thanks to the [11]CMU team for organising such a great contest! 6. http://icfpcontest.org/ 7. http://icfp06.cs.uchicago.edu/ 8. http://haskell.org/haskellwiki/IRC_channel 9. http://icfpcontest.org/scoreboard.shtml 10. http://video.google.com/videoplay?docid=6419094369756184531 11. http://www.cs.cmu.edu/afs/cs/Web/Groups/pop/pop.html * New release of Hugs. Ross Paterson [12]announced a new minor release of Hugs, fixing a few bugs with the May 2006 release, and with libraries roughly matching the forthcoming GHC 6.6 release. It is available from [13]the Hugs page. 12. http://article.gmane.org/gmane.comp.lang.haskell.hugs.user/493/ 13. http://www.haskell.org/hugs/ * HAppS version 0.8.2. Einar Karttunen [14]announced the release of the Haskell Application Server version 0.8.2. HAppS is a Haskell web application server for building industrial strength internet applications safely, quickly, and easily. With HAppS you focus entirely on application functionality implemented in your favourite language and you don't have to worry about making sure all sorts of server subsystems are functioning properly. [15]More info. 14. http://article.gmane.org/gmane.comp.lang.haskell.general/14292/ 15. http://happs.org/ * Codec.Compression.GZip and .BZip. Duncan Coutts [16]released two new packages: zlib and bzlib, which provide functions for compression and decompression in the gzip and bzip2 formats, directly on [17]ByteStrings. Both provide pure functions on streams of data represented by lazy ByteStrings. This makes it easy to use either in memory or with disk or network IO. There is API documentation is available [18]here and [19]here. 16. http://article.gmane.org/gmane.comp.lang.haskell.general/14265/ 17. http://www.cse.unsw.edu.au/~dons/fps.html 18. http://haskell.org/~duncan/zlib/docs 19. http://haskell.org/~duncan/bzlib/docs * System Fc branch merged into GHC. Manuel Chakravarty [20]merged the [21]System Fc branch of GHC into GHC head. This is a significant development, adding extensions to GHC to support an [22]FC-based intermediate language, a new implementation of GADTs, along with indexed data types and indexed newtypes (generalised [23]associated data types). [24]More details about the implementation. 20. http://article.gmane.org/gmane.comp.lang.haskell.cvs.all/28297/ 21. http://www.cse.unsw.edu.au/~chak/papers/SCP06.html 22. http://hackage.haskell.org/trac/ghc/wiki/IntermediateTypes 23. http://www.cse.unsw.edu.au/~chak/papers/CKPM05.html 24. http://hackage.haskell.org/trac/ghc/wiki/TypeFunctions * Job writing security software in Haskell. Andrew Pimlott [25]announced that Planning Systems, Inc. has a job opportunity for Haskell programmers, writing a high-assurance authorization system. [26]Job description. 25. http://article.gmane.org/gmane.comp.lang.haskell.cafe/15439/ 26. http://www.plansys.com/careers/job_details.cfm?JobID=28 * Dr Haskell 0.1. Neil Mitchell [27]released Dr Haskell, a tool to help suggest improvements to your Haskell code. Dr Haskell will
[Haskell] Re: compiler-independent core libraries infrastructure
On Fri, Sep 15, 2006 at 05:20:36PM +0100, Ian Lynagh wrote: As it happens I was working on getting GHC to use cabal to build base et al on the plane the other day, and I had a brief look at this. See my comment in http://hackage.haskell.org/trac/ghc/ticket/710 for the results of my longer look at this. Thanks Ian ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Haskell' Status Report
Ravi Nanavati has very helpfully put together a status report for the Haskell Prime process. Please see this link, or read the pasted text below: http://hackage.haskell.org/trac/haskell-prime/wiki/Status' peace, isaac Summary: Since the Haskell Workshop last year, the Haskell community has documented (on this wiki) over 70 proposals for changes to Haskell 98. In March of this year, two subcommittees were established to focus on concurrency and the class system - two difficult areas that are important to the success of Haskell'. The committee has also used StrawPolls to filter and discuss the universe of proposals that has been gathered. Based on the most recent straw poll, 12 proposals (listed in the table at the bottom of the page) have been identified that are expected to get into Haskell' (over 2/3 of the committee in favor). An additional 19 proposals seem likely to get into Haskell' (based on slightly weaker criteria). Members of the committee conflict on 9 of the remaining proposals, and their status will be determined during the writing process. The remaining proposals are not expected to be part of Haskell'. Concurrency: The concurrency support in Haskell' will be based on the Control.Concurrent library, with minor modifications. There will be a thread-safe interface for mutable state, suitable for use in library code that does not otherwise use concurrency (though what it will be based on is an open issue). There will also be independent FFI annotations for specifying whether foreign calls are concurrent (with other Haskell threads) and reentrant. Bound threads will not be required by the concurrency standard, but they will be an allowed extension with a specified meaning. Open issues include whether standard will require preemptive concurrency, the syntax of the new FFI annotations and the memory-model semantics of IORefs. Class system: The work on the class system has focused on resolving the MultiParamTypeClassesDilemma. The core of the dilemma is that multi-parameter typeclasses are a popular extension that is strongly desired for Haskell'. However, many important uses of MPTCs (like the monad transformer library) require additional extensions to resolve ambiguities in their typechecking. Historically, FunctionalDependencies have been used for this purpose, but they are very tricky to implement and are also difficult to specify in a way that guarantees the termination of typechecking. AssociatedTypes are a possible replacement, but our current implementation experience with them is very limited. The subcommittee has explored several ways to resolve this dilemma (including restricted FDs, fast-tracked ATs and FDs as a blessed extension), but, so far, no consensus has emerged. Our current plan is to focus on writing other parts of the Haskell' standard, in the hopes that additional implementation experience with ATs will clarify the situation. Libraries: Thus far, libraries have been an underemphasized portion of the Haskell' effort (only 7 of the 70+ proposals have significant library content). However, there is a consensus that a revised standard library is an important part of the Haskell' effort. The current plan is to focus on starting to write the language portions of the standard first, since we have a substantial amount of work to do there which requires focused attention. After that effort is well underway, a companion library effort will begin. Several members of the committee have volunteered for this effort and additional volunteers will be needed. definitely-in Proposal Status: Description (Those volunteering to write this section): add some kind of Concurrency (IJ, SM) add ForeignFunctionInterface (MC, SM) add multi-parameter type classes (MS) add RankNTypes or Rank2Types (AL) add PolymorphicComponents (AL) add ExistentialQuantification (existential components) (AL, MS, SJT) add HierarchicalModules (IJ, BH, MW) add EmptyDataDeclarations (BH, HN) DoAndIfThenElse (SM, HN) fix comment syntax grammar (SM) add PatternGuards (RN, DS) add InfixTypeConstructors (BH, AL) ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Haskell Standard: Please email me if you want to join the committee.
Greetings, As announced at the Haskell Workshop, the Haskell Prime process is running another committee selection round. We are specifically looking for people to write sections of the Haskell Report for the definitely in and probably in proposals, as described in: http://hackage.haskell.org/trac/haskell-prime/wiki/Status' Please email me if you think you would like to write sections of the report and be on the committee. Please tell me which of the definitely in or probably in sections you would like to help with writing. Also, anyone interested in the future of the language should sign up for the Haskell Prime mailing list if you aren't already: http://haskell.org/mailman/listinfo/haskell-prime peace, isaac ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Haskell' Status Report
One thing jumped out at me from the status report: everything was add, which reminded me of many old languages designed by accretion. Are the new facilities so perfectly orthogonal as not to subsume anything that was already there? Are none of them simply relaxations of previous limitatations? Parsimony is part of the allure of Haskell. What do the new facilities enable one to discard from the Haskell 98 report? Doug McIlroy ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Haskell' Status Report
Ravi Nanavati has very helpfully put together a status report for the Haskell Prime process. Please see this link, or read the pasted text below: http://hackage.haskell.org/trac/haskell-prime/wiki/Status' peace, isaac Summary: Since the Haskell Workshop last year, the Haskell community has documented (on this wiki) over 70 proposals for changes to Haskell 98. In March of this year, two subcommittees were established to focus on concurrency and the class system - two difficult areas that are important to the success of Haskell'. The committee has also used StrawPolls to filter and discuss the universe of proposals that has been gathered. Based on the most recent straw poll, 12 proposals (listed in the table at the bottom of the page) have been identified that are expected to get into Haskell' (over 2/3 of the committee in favor). An additional 19 proposals seem likely to get into Haskell' (based on slightly weaker criteria). Members of the committee conflict on 9 of the remaining proposals, and their status will be determined during the writing process. The remaining proposals are not expected to be part of Haskell'. Concurrency: The concurrency support in Haskell' will be based on the Control.Concurrent library, with minor modifications. There will be a thread-safe interface for mutable state, suitable for use in library code that does not otherwise use concurrency (though what it will be based on is an open issue). There will also be independent FFI annotations for specifying whether foreign calls are concurrent (with other Haskell threads) and reentrant. Bound threads will not be required by the concurrency standard, but they will be an allowed extension with a specified meaning. Open issues include whether standard will require preemptive concurrency, the syntax of the new FFI annotations and the memory-model semantics of IORefs. Class system: The work on the class system has focused on resolving the MultiParamTypeClassesDilemma. The core of the dilemma is that multi-parameter typeclasses are a popular extension that is strongly desired for Haskell'. However, many important uses of MPTCs (like the monad transformer library) require additional extensions to resolve ambiguities in their typechecking. Historically, FunctionalDependencies have been used for this purpose, but they are very tricky to implement and are also difficult to specify in a way that guarantees the termination of typechecking. AssociatedTypes are a possible replacement, but our current implementation experience with them is very limited. The subcommittee has explored several ways to resolve this dilemma (including restricted FDs, fast-tracked ATs and FDs as a blessed extension), but, so far, no consensus has emerged. Our current plan is to focus on writing other parts of the Haskell' standard, in the hopes that additional implementation experience with ATs will clarify the situation. Libraries: Thus far, libraries have been an underemphasized portion of the Haskell' effort (only 7 of the 70+ proposals have significant library content). However, there is a consensus that a revised standard library is an important part of the Haskell' effort. The current plan is to focus on starting to write the language portions of the standard first, since we have a substantial amount of work to do there which requires focused attention. After that effort is well underway, a companion library effort will begin. Several members of the committee have volunteered for this effort and additional volunteers will be needed. definitely-in Proposal Status: Description (Those volunteering to write this section): add some kind of Concurrency (IJ, SM) add ForeignFunctionInterface (MC, SM) add multi-parameter type classes (MS) add RankNTypes or Rank2Types (AL) add PolymorphicComponents (AL) add ExistentialQuantification (existential components) (AL, MS, SJT) add HierarchicalModules (IJ, BH, MW) add EmptyDataDeclarations (BH, HN) DoAndIfThenElse (SM, HN) fix comment syntax grammar (SM) add PatternGuards (RN, DS) add InfixTypeConstructors (BH, AL) ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Trac Ticket Component Field?
What do the various values of the Component field mean? Most issues have Proposal, but some have HaskellPrime. -- Ashley Yakeley Seattle WA ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Trac Ticket Component Field?
On Wed, 2006-09-27 at 16:27 -0700, Ashley Yakeley wrote: What do the various values of the Component field mean? Most issues have Proposal, but some have HaskellPrime. If it is a proposal for something to go into/be removed from the language, then it should be listed as proposal. If it's some task that we have to perform (write a library API or something), then the component might be something else. Proposal is the main one, though. peace, isaac ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Trac Ticket Component Field?
isaac jones wrote: On Wed, 2006-09-27 at 16:27 -0700, Ashley Yakeley wrote: What do the various values of the Component field mean? Most issues have Proposal, but some have HaskellPrime. If it is a proposal for something to go into/be removed from the language, then it should be listed as proposal. If it's some task that we have to perform (write a library API or something), then the component might be something else. Proposal is the main one, though. What does HaskellPrime mean? There are a some library proposals listed under Proposal, and others listed under HaskellPrime. I fear the latter may be falling through the cracks. -- Ashley Yakeley Seattle WA ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: [Haskell-cafe] Unable to profile program using Data.ByteString.Lazy
Jason Dagit [EMAIL PROTECTED] writes: Ubuntu seems to be a bit behind then. The current official release of the 6.4 branch is at 6.4.2. Debian seems to provide this version, maybe you can use the debian package? But, if I were you I wouldn't worry so much about upgrading ghc but instead upgrading Cabal which is much simpler and takes just a second. I've asked them to backport 6.4.2 for dapper, but they are reluctant as it would require backporting all third party software (or at least libraries) as well. I filed a request to backport it, but for some reason, I am unable to find it again. If you can make sense of the hopeless launchpad user interface, feel free to add you voice to the choir. You're cabal version is too old then. Try updating either Cabal or GHC. It's the latest version (6.4.1) packaged for Ubuntu. I'll have to download and install a newer version manually. Unfortunately, the download site seems to be down again :( The currently easiest way out is to install a binary snapshot. It would sure be nice to have a working ghc as part of the base distribution, with automatically upgrades etc. Let's hope they put a stable 6.6 into Edgy. -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] Creating DLLs with GHC
Hi On 9/27/06, Matthew Bromberg [EMAIL PROTECTED] wrote: though I have a binary build of ghc 6.5 If you have new ghc 6.5, you can use --mk-dll with --make, in case that helps. ghc --mk-dll -o netsim.dll ExternLib.o ExternLib_stub.o dllNet.o src1.o src1_stub.o src2.o -optl-lmatrixstack -optl-L. My external C library is in matrixstack.dll and it has a corresponding static link stub library matrixstack.lib in the same directory as all the sources. It has references in one of the sources (say src1.hs). If I recall correctly, to link Ms-style import libs, you must specify them as object files (ie no -optl-lfoo, but just foo.lib) or make mingw-style import libs via .def files. But as you've not run into this yet, maybe it works for you like that. Unfortunately I get a host of undefined references to basically all the functions in matrixstack.dll and also some undefined references of the form Parsefile.o:ghc2996_0.hc:(.text+0x130): undefined reference to `TextziParserCombinatorsziParsecziError_show_closure' Parsefile.o:ghc2996_0.hc:(.text+0x220): undefined reference to `TextziParserCombinatorsziParsecziChar_spaces_closure' Parsefile.o:ghc2996_0.hc:(.text+0x24a): undefined reference to `TextziParserCombinatorsziParsecziChar_spaces_closure' Parsefile.o:ghc2996_0.hc:(.text+0x29c): undefined reference to `TextziParserCombinatorsziParsecziChar_spaces_closure' Add -package parsec to you ghc commandline. And similary for any other packages you used while compiling. HTH, Esa ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Creating DLLs with GHC
Matthew, As regards the symbols that end with _closure, I believe you can resolve them by adding -package parsec to the ghc command line (as far as I can see, all the symbols you list come from the parsec package). I don't know, though, what to do with the undefined symbols from matrixstack. You can try to check two things: 1) That the options you specify with -optl really reach the linker (e.g. try to give a non-existent library in -optl option and see if it complains). 2) That matrixstack.lib is understood by the linker (that is, it must be created with dlltool) 3) That the symbols it is looking for do exist in matrixstack.lib (you can check it with objdump, for instance). Cheers, Cyril ___ Matthew Bromberg wrote: ghc --mk-dll -o netsim.dll ExternLib.o ExternLib_stub.o dllNet.o src1.o src1_stub.o src2.o -optl-lmatrixstack -optl-L. My external C library is in matrixstack.dll and it has a corresponding static link stub library matrixstack.lib in the same directory as all the sources. It has references in one of the sources (say src1.hs). Unfortunately I get a host of undefined references to basically all the functions in matrixstack.dll and also some undefined references of the form Parsefile.o:ghc2996_0.hc:(.text+0x130): undefined reference to `TextziParserCombinatorsziParsecziError_show_closure' ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unable to profile program using Data.ByteString.Lazy
Ketil Malde [EMAIL PROTECTED] writes: I filed a request to backport [ghc 6.4.2 to Ubuntu Dapper], but for some reason, I am unable to find it again. Hah! Found it (with some IRC assistance): https://launchpad.net/distros/ubuntu/+source/ghc6/+bug/56516 -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] Optimizing a title matcher
On 9/27/06, Lyle Kopnicky [EMAIL PROTECTED] wrote: Hi folks, It turns out Haskell is vindicated. It's my algorithm that was slow. As Robert Dockins pointed out, the double nested loop is just going to take a long time. As evidence, it turns out my C++ version is just as slow as the Haskell version. So, I'm going to go back to Haskell, but be more selective about which titles from the reference table I choose to match against, for any given import title. Thanks, Lyle ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe I have no idea if this helps but perhaps a Directed Acyclic Word Graphs (DAWG) could be useful? It can be used for prefix matching for example. - Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimizing a title matcher
Lyle Kopnicky [EMAIL PROTECTED] writes: If you have some other metric other than prefix in mind for partial matches, then things probably get a lot more complicated. You're probably looking at calculating minimum distances in some feature-space, which calls for pretty sophisticated algorithms if you need good performance. Yes, that's the kind of thing I'm looking at doing. Looking at edit distance. Do you really need that to search for movie titles? At any rate, an exact-match finite-map implementation is a good start - to get good performance, you probably will need to use some kind of index to reduce the amount of data to search exhaustively (all-against-all). For text searching I think it is effective to use an index that maps from words (so that looking up a word gives you all the movies with that word in the title). -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] Optimizing a title matcher
On 9/27/06, Johan Tibell [EMAIL PROTECTED] wrote: On 9/27/06, Lyle Kopnicky [EMAIL PROTECTED] wrote: Hi folks, It turns out Haskell is vindicated. It's my algorithm that was slow. As Robert Dockins pointed out, the double nested loop is just going to take a long time. As evidence, it turns out my C++ version is just as slow as the Haskell version. So, I'm going to go back to Haskell, but be more selective about which titles from the reference table I choose to match against, for any given import title. Thanks, Lyle ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe I have no idea if this helps but perhaps a Directed Acyclic Word Graphs (DAWG) could be useful? It can be used for prefix matching for example. - Johan Uhm, so this a form of trie as mentioned before. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Is Haskell a 5GL?
Hello Max, Monday, September 25, 2006, 10:41:20 PM, you wrote: Ch That's a religious statement. I was looking for some strong Ch arguments for the nonbelievers that Haskell is a 5GL. But what about nonbelievers in language classification by generation? i was not on the market when 1..3 GLs arrived, but i've seen 4/5 GL story and it was just marketing tool. 4gl was used to market task-specific languages embedded in some applications or used to quickly build applications, such as Clarion Database Developer. this name was used just to emphasize advantages of these laguages over general-purpose (3gl) ones in the areas that was targeted by these languages when Japan supercomputing/new programming paradigm was arrived, it was also marketed as 5 gl - not because it's superior to 4gl, but just because 4'th number was already used :) Japan project failed its goals, and logic programming don't ruled the world. but in some sense you can say that 5gl was about describing the problem instead of the way to solve it (algorithm=3gl), so FP is closer to this goal than C++ or Java -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Re: Is Haskell a 5GL?
Hello Bill, Tuesday, September 26, 2006, 1:03:02 AM, you wrote: I spent some time working on a large Prolog application where performance was critical, ... I think you're right that Haskell should be in the same bag as Prolog. and Haskell is the same as C++ when performance is critical, while C++ is the same as assembler. believe me - i has experience of optimizing both Haskell and C++ programs :) i think it's wrong to make decisions about language expressiveness on the base of requirements for writing optimized programs. my _application_ Haskell/C++ code contains about 80-90%% of code that _don't need_ to be optimized and it's just the case when higher language expressiveness rules. but for the remaining 10-20%% optimizing of higher-level language becomes a nightmare and it is much better to use lower-level language in these places (if it's possible!) instead of using lower-level techniques that just don't fit in the higher-language toolbox :( ps: btw, i was really thinking in assembler when optimizing my Haskell lib. it is why it so fast. on good-old DEC cpus whole getChar/putChar actions may be compiled in just one asm instruction :) so, using your logic, Haskell is 1-gl language :) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] source code for haskell web server?
There is also the HAppS application server and the HaskellNet library. Would not be possible to merge the protocol-handling parts of all these libraries into a generic Internet Haskell server that could then be expanded to support CGIs, transactions, etc.? Regards, titto -Original Message- From: [EMAIL PROTECTED] [mailto:haskell-cafe- [EMAIL PROTECTED] On Behalf Of Bjorn Bringert Sent: 27 September 2006 12:15 To: Tim Newsham Cc: Henning Thielemann; haskell-cafe Cafe Subject: Re: [Haskell-cafe] source code for haskell web server? On 4 sep 2006, at 20.24, Tim Newsham wrote: Since there are a lot of modifications of HWS around now, it seems to be worthwhile to combine the efforts. E.g. I adapted the HWS adaption provided by WASH http://www.informatik.uni-freiburg.de/~thiemann/WASH/#wsp for my needs. For instance in Request.hs I removed the call to 'Network.URI.unEscapeString' (which is 'deHex' in fptools/HWS/ Request.hs, but 'deHex' is 'id') because that affects interpretation of CGI parameters. I also think that this package needs some cleanup and Cabal. What about a darcs repository at http://darcs.haskell.org/ ? I agree its worthwhile to combine efforts. My only concern is to maintain the code quality. The original HWS was written quite well. The plugins extension I found was not of the same code quality. I haven't looked at the WASH modifications, so I don't know how they compare. I dont know much about using the haskell.org repository, but I'd be happy to contribute to it if there was an HWS repository there... I seem to have duplicated Tim's efforts before I noticed this thread. In order to keep this from happening again, I have put up a darcs repo at http://darcs.haskell.org/hws/ It contains the version from fptools-hws (http://cvs.haskell.org/cgi- bin/cvsweb.cgi/fptools/hws/) with the following modifications: - Use the hierarchical libraries. - Use Data.Map instead of FiniteMap. - Use Parsec from the hierarchical libraries and removed the included old parsec copy. - Removed ifdefs for compatibility with GHC 4.x and 5.x (they wouldn't work with the new imports anyway). - Use IOUArray in Response.squirt - Use Cabal for the build system. It now builds with GHC 6.4.1 and GHC 6.5 (if you add html and regex- compat to the build-depends). If any of you have any other updates, bugfixes etc., you are welcome to add them. Maybe we can even get Simon Marlow to update it with the current state-of-the art in high-performance concurrent Haskell? I'm thinking that we should try to keep this version reasonably close to Simon's original version, or at least its intent, and work on extra features in separate branches. /Björn___ 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] Computing lazy and strict list operations at thesame time
This is a follow-up to a thread from June-July[1]. The question was how to write the function initlast :: [a] - ([a], a) initlast xs = (init xs, last xs) so that it can be consumed in fixed space: main = print $ case initlast [0..10] of (init, last) - (length init, last) if space is the main issue, you could try to avoid the sharing (so that each part of the computation unfolds and throws away its own copy of the input list): initlast :: (()-[a]) - ([a], a) initlast xs = (init (xs ()), last (xs ())) main = print $ case initlast (\()-[0..10]) of (init, last) - (length init, last) hth, claus ps. it would occasionally be nice to be able to undo sharing instead of having to avoid it, by asking for an independent, equally unevaluated, copy of some expression. that would make it easy to write initlast with your original type. pps. compiling with -O recreates the space problem? (ghc-6.5) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Is Haskell a 5GL?
Hi, an experienced person at our lab told me that the classification into generations has become unfashioned in the last decade; thus I think I will stay away from using it but argue with concrete abstraction features. Concerning the point someone made about the features of Haskell: * pattern matching: just case distinction * list comprehensions: syntactic sugar These are indeed local syntactic issues but the amount of such small things is essential to make things easy, in addition to semantic issues like laziness. Assume that you do not have them: then your programs would look as verbose as Java or LISP programs. If someone asks me for the generation level of Haskell, I will say 5, because there are only a few small functions you have to add to implement a small theorem prover; provocatively speaking: if these were in the prelude than Haskell was an artificial intelligence language. But perhaps such marketing statements are not convincing any more. -- Christoph ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Creating DLLs with GHC
Well I tried this statement ghc --mk-dll -fglasgow-exts -fffi -I. --make ExternLib.hs It only compiled the object file, creating ExternLib.o, but it did not create the stub file or attempt to link in the dependent packages. I then went back to this, ghc --mk-dll -fglasgow-exts -fffi -o netsim.dll ExternLib.o ExternLib_stub.o dllNet.o src1.o src1_stub.o src2.o -package parsec -optl-lmatrixstack -optl-L. This removed the undefined references to the parsec package, however I still can't get it to link to the matrixstack.lib and matrixstack.dll. matrixstack.lib was created using dlltool and does link just fine if linking the sources into a stand alone executable instead of a .dll. I did try to include matrixstack.lib on the command line directly as well but that ended up with the same problem. Is it possible to just compile everything into C? I'd need to link to the haskell runtime libraries somehow. Esa Ilari Vuokko wrote: Hi On 9/27/06, Matthew Bromberg [EMAIL PROTECTED] wrote: though I have a binary build of ghc 6.5 If you have new ghc 6.5, you can use --mk-dll with --make, in case that helps. ghc --mk-dll -o netsim.dll ExternLib.o ExternLib_stub.o dllNet.o src1.o src1_stub.o src2.o -optl-lmatrixstack -optl-L. My external C library is in matrixstack.dll and it has a corresponding static link stub library matrixstack.lib in the same directory as all the sources. It has references in one of the sources (say src1.hs). If I recall correctly, to link Ms-style import libs, you must specify them as object files (ie no -optl-lfoo, but just foo.lib) or make mingw-style import libs via .def files. But as you've not run into this yet, maybe it works for you like that. Unfortunately I get a host of undefined references to basically all the functions in matrixstack.dll and also some undefined references of the form Parsefile.o:ghc2996_0.hc:(.text+0x130): undefined reference to `TextziParserCombinatorsziParsecziError_show_closure' Parsefile.o:ghc2996_0.hc:(.text+0x220): undefined reference to `TextziParserCombinatorsziParsecziChar_spaces_closure' Parsefile.o:ghc2996_0.hc:(.text+0x24a): undefined reference to `TextziParserCombinatorsziParsecziChar_spaces_closure' Parsefile.o:ghc2996_0.hc:(.text+0x29c): undefined reference to `TextziParserCombinatorsziParsecziChar_spaces_closure' Add -package parsec to you ghc commandline. And similary for any other packages you used while compiling. HTH, Esa ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- View this message in context: http://www.nabble.com/Creating-DLLs-with-GHC-tf2342692.html#a6529535 Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Computing lazy and strict list operations at the same time
Andrew Pimlott wrote: This is a follow-up to a thread from June-July[1]. The question was how to write the function initlast :: [a] - ([a], a) initlast xs = (init xs, last xs) so that it can be consumed in fixed space: main = print $ case initlast [0..10] of (init, last) - (length init, last) Attempts were along the lines of initlast :: [a] - ([a], a) initlast [x]= ([], x) initlast (x:xs) = let (init, last) = initlast xs in (x:init, last) I seemed obvious to me at first (and for a long while) that ghc should force both computations in parallel; but finally at the hackathon (thanks to Simon Marlow) I realized I was expecting magic: The elements of the pair are simply independent thunks, and there's no way to partly force the second (ie, last) without forcing it all the way. According to the stuff about selector thunks, it seems this should work initlast [x] = ([],[x]) initlast (x:xs) = let ~(init,last) = initlast xs in (x:init, last) Sometimes it does compile to a program that runs in constant space, sometimes it doesn't! I've sent a message to the list with a heap profile of a run on 10M numbers, but it's being held for moderation because it's too big. Brandon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimizing a title matcher
Ketil Malde wrote: Do you really need that to search for movie titles? At any rate, an exact-match finite-map implementation is a good start - to get good performance, you probably will need to use some kind of index to reduce the amount of data to search exhaustively (all-against-all). For text searching I think it is effective to use an index that maps from words (so that looking up a word gives you all the movies with that word in the title). Gotcha. That's exactly the approach I've switched to. It is possible to miss titles, if words are misspelled, but it's unlikely that all words in the title will be misspelled, so you can at least narrow your search to titles that have at least one matching (non-trivial) word. - Lyle ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Getting the latest
Lyle == Lyle Kopnicky [EMAIL PROTECTED] writes: Lyle My question is, when I do 'make install', will it just overwrite Lyle the version (6.4.1) I already have? Or will they go in separate Lyle places? This depends on the prefix you configured sources with (/usr/local by default). Lyle I have no idea how it decides where to go. Right now ghc Lyle 6.4.1 is in /usr/local/bin/ghc. After I 'make install', will it Lyle be ghc 6.5? I don't want to screw up the installed package so it Lyle can't be updated later. It should be :-) PS: It is better to build a custom package (dh_make will help you). -- WBR, Max Vasin. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Creating DLLs with GHC
On 9/26/06, Matthew Bromberg [EMAIL PROTECTED] wrote: I am having some difficulty with creating a dynamic link library using GHC on windows XP. I am attempting to follow the example in http://www.haskell.org/ghc/docs/6.4/html/users_guide/win32-dlls.html though I have a binary build of ghc 6.5 My problem (I think) is that some of my Haskell source files link to an external C library also contained in a DLL. I generate my Haskell object files when I compile my Haskell executable. I then attempt to use the object files in a ghc compiler statement like this, ghc --mk-dll -o netsim.dll ExternLib.o ExternLib_stub.o dllNet.o src1.o src1_stub.o src2.o -optl-lmatrixstack -optl-L. My external C library is in matrixstack.dll and it has a corresponding static link stub library matrixstack.lib in the same directory as all the sources. It has references in one of the sources (say src1.hs). Unfortunately I get a host of undefined references to basically all the functions in matrixstack.dll and also some undefined references of the form Parsefile.o:ghc2996_0.hc:(.text+0x130): undefined reference to `TextziParserCombinatorsziParsecziError_show_closure' Parsefile.o:ghc2996_0.hc:(.text+0x220): undefined reference to `TextziParserCombinatorsziParsecziChar_spaces_closure' Parsefile.o:ghc2996_0.hc:(.text+0x24a): undefined reference to `TextziParserCombinatorsziParsecziChar_spaces_closure' Parsefile.o:ghc2996_0.hc:(.text+0x29c): undefined reference to `TextziParserCombinatorsziParsecziChar_spaces_closure' ... If you use cabal I think can follow an example I put on the wiki to get these undefined references to go away: http://www.haskell.org/haskellwiki/Cabal Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimizing a title matcher
Ketil Malde wrote: Lyle Kopnicky [EMAIL PROTECTED] writes: If you have some other metric other than prefix in mind for partial matches, then things probably get a lot more complicated. You're probably looking at calculating minimum distances in some feature-space, which calls for pretty sophisticated algorithms if you need good performance. Yes, that's the kind of thing I'm looking at doing. Looking at edit distance. Do you really need that to search for movie titles? At any rate, an exact-match finite-map implementation is a good start - to get good performance, you probably will need to use some kind of index to reduce the amount of data to search exhaustively (all-against-all). For text searching I think it is effective to use an index that maps from words (so that looking up a word gives you all the movies with that word in the title). -k If you really need to do edit distance, perhaps something like Low Distortion Embeddings for Edit Distance http://www.cs.ucla.edu/~rafail/PUBLIC/68.pdf would help? This is just one of the first result from a search, probably there are plenty of things out there. Make up from any constant factors from your language choice with advanced algorithms! (and any constant is getting pretty small these days) Brandon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Getting the latest
Max Vasin wrote: Lyle I have no idea how it decides where to go. Right now ghc Lyle 6.4.1 is in /usr/local/bin/ghc. After I 'make install', will it Lyle be ghc 6.5? I don't want to screw up the installed package so it Lyle can't be updated later. It should be :-) It should be screwed up? Or it should be updated later? Ideally I'd like to keep the Ubuntu package where it is. I'd like to install the experimental GHC in a different place. Then I want to change my path to point to the experimental one for building. PS: It is better to build a custom package (dh_make will help you). I don't have a command called dh_make. I do have some other dh_* commands. What do I need to run dh_make? Where can I find documentation? Thanks, Lyle ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] A better syntax for qualified operators?
Hi -
Consider the scenario when you want to find a function that returns the i'th
element of an array but all you know is that there is a module called
Data.Array.IArray that will probably have such a function in it. So you
start typing in your program:
let
ith = Data.Array.IArray.
at this point, you'd hope the editor you're using would somehow display a
list of avaliable values exported from Data.Array.IArray including the
indexing function, so you could select it, thus I would *like* to be able to
use the syntax:
let
ith = Data.Array.IArray.(!)
because it's not the user's fault that the person who wrote
Data.Array.IArray decided to use a symbol instead of an identifier for this
function - the user of Data.Array.IArray in this case just wants to see
normal identifiers to use with prefix application so the use of (!) at this
point effectively gets rid of the unwanted operatorness associated with the
function.
However the current syntax of Haskell would not allow this. Instead you have
to write:
let
ith = (Data.Array.IArray.!)
The problem is that the user of Data.Array.IArray has to know already in
advance, before typing the 'D' of Data, that the indexing function has
been named with a symbol instead of an identifier, but this knowledge is
only available later, when the user has typed the '.' after IArray, so the
current syntax would be frustrating for the user because the user then has
to go all the way back and insert an opening paren before the 'D'.
Also, consider the appearance of:
let
ith = (Data.Array.IArray.!) arr i
b = Data.Array.IArray.bounds arr
vs
let
ith = Data.Array.IArray.(!) arr i
b = Data.Array.IArray.bounds arr
I'm not sure if I've managed to explain this problem clearly enough, but my
proposal is that we might consider changing the lexical syntax of Haskell as
follows:
varId ::= id
varOp ::= symbol
varIdOp ::= ` varId
varOpId ::= ( varOp )
varOpIdOp ::= ` varOpId
qvarId ::= {conId .}+ varId-- { }+ denotes 1 or more times
qvarIdOp ::= ` qvarId
qvarOp ::= {conId .}+ varOp
qvarOpId ::= {conId .}+ varOpId
qvarOpIdOp ::= `qvarOpId
In other words, to turn an operator symbol into an id, the parentheses would
be put immediately around the symbol (with no spaces since this is lexical
syntax), and to turn an id into an operator the backquote is put in front of
the entire (qualified) id.
(Also the trailing backquote in the existing syntax is redundant)
The above syntax would have 3 advantages:
1) It allows the client of a module to write code without having to
worry if the author of the module used symbols or identifiers to name
functions - everything exported from the module can be made to appear as if
it was named by an identifier (ie OpId)
2) Moving the parentheses to the lexical syntax makes syntax
highlighting easier (because there are no comments to worry about inside the
OpId) and also makes parsing simpler because all the mess associated with
Ops versus Ids is handled by the lexer
3) It allows an editor to make a distinction between
(+)-- an operator turned into an identifier - varOpId
( + ) -- an expression with 2 gaps in it which should be
marked as incomplete
(+ ) -- a section with 1 gap
Some examples of the proposed syntax are:
let
ith = Data.Array.IArray.(!) arr i
foo = k `Math.(+) 6-- default precendence
bar = k Math.+ 6-- using precedence of + in module Math
When you try to write an editor for Haskell (or some subset of it), you
quickly discover these areas of Haskell syntax like the above which need to
be changed to get an optimum interactive editing experience. I think it *is*
possible to adjust the Haskell grammar so that it is LL(1) and the only
reason it is not already LL(1) seems to be that the grammar has been
designed with compilers (which only need to deal with complete modules) in
mind rather than programmers interactively editing in mind.
(The other change needed for LL(1) is to give contexts a marker before they
appear eg:
foo :: {MonadIO m} a - m a
)
By LL(1) I'm really meaning that the grammar for interactive editing needs
to be adjusted so that it is possible to maintain the invariant that as code
is entered from left to right constructs and identifiers can be highlighted
according to their grammatical role and highlighting (modulo incompleteness)
must remain unchanged regardless of whatever is typed afterwards to the
right otherwise it can become more of a liability than a help, hence my hope
that some future revision of Haskell grammar might consider taking the above
points into account.
Regards, Brian.
--
Logic empowers us and Love gives us purpose.
Yet still phantoms restless for eras long past,
congealed in the present in unthought forms,
strive mightily unseen to destroy us.
[Haskell-cafe] Expressing seq
I was reading on p. 29 of A History of Haskell (a great read, by the way) about the controversy of adding seq to the language. But other than for efficiency reasons, is there really any new primitive that needs to be added to support this? As long as the compiler doesn't optimize it away, why not just do something like this (in ghci)? Prelude let sq x y = if x == x then y else y Prelude 1 `sq` 2 2 Prelude (length [1..]) `sq` 2 Interrupted. There must be a subtlety I'm missing, right? -- Chad Scherrer Time flies like an arrow; fruit flies like a banana -- Groucho Marx ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Duplicate Instance problem
Hello,
I tried to create a type class for making instances of Show display a
custom way. After using my class for a while I found that sometimes
RealFloats would display as 'NaN' and this is unacceptable. So at
this point I had something like:
{-# OPTIONS_GHC -fglasgow-exts -fallow-undecidable-instances
-fallow-overlapping-instances #-}
class Show a = StringValue a where
-- | Convert a showable value to a string
toString :: a - String
instance Num a = StringValue a where
toString = show
and I added an instance for RealFloat:
instance RealFloat a = StringValue a where
toString x
| isNaN x = -- as an example
| otherwise = show x
Now, I get the error:
Duplicate instance declarations:
instance [overlap ok] (Num a) = StringValue a
-- Defined at ...
instance [overlap ok] (RealFloat a) = StringValue a
-- Defined at ...
I've also tried spliting Num into an instance for Integral and
RealFloat but that doesn't work either (same error).
For now I'm using an instance for RealFloat and an instance for Int
and Integer (which are identical) and that seems to be okay but
suboptimal.
Why does the error say they are duplicates? I would have expected
something about them overlapping but not duplicates. Is there a way
to still do this without duplicates?
Thanks,
Jason
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Expressing seq
On 9/27/06, Chad Scherrer [EMAIL PROTECTED] wrote: I was reading on p. 29 of A History of Haskell (a great read, by the way) about the controversy of adding seq to the language. But other than for efficiency reasons, is there really any new primitive that needs to be added to support this? As long as the compiler doesn't optimize it away, why not just do something like this (in ghci)? Prelude let sq x y = if x == x then y else y Prelude 1 `sq` 2 2 Prelude (length [1..]) `sq` 2 Interrupted. There must be a subtlety I'm missing, right? What if the types are not instances of Eq? Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A better syntax for qualified operators?
Brian Hulley wrote:
Hi -
Consider the scenario when you want to find a function that returns
the i'th element of an array but all you know is that there is a
module called Data.Array.IArray that will probably have such a
function in it. So you start typing in your program:
let
ith = Data.Array.IArray.
at this point, you'd hope the editor you're using would somehow
display a list of avaliable values exported from Data.Array.IArray
including the indexing function, so you could select it, thus I would
*like* to be able to use the syntax:
let
ith = Data.Array.IArray.(!)
because it's not the user's fault that the person who wrote
Data.Array.IArray decided to use a symbol instead of an identifier for
this function - the user of Data.Array.IArray in this case just wants
to see normal identifiers to use with prefix application so the use of
(!) at this point effectively gets rid of the unwanted operatorness
associated with the function.
This is a nice argument
However the current syntax of Haskell would not allow this. Instead
you have to write:
let
ith = (Data.Array.IArray.!)
The problem is that the user of Data.Array.IArray has to know already
in advance, before typing the 'D' of Data, that the indexing
function has been named with a symbol instead of an identifier, but
this knowledge is only available later, when the user has typed the
'.' after IArray, so the current syntax would be frustrating for the
user because the user then has to go all the way back and insert an
opening paren before the 'D'.
Also, consider the appearance of:
let
ith = (Data.Array.IArray.!) arr i
b = Data.Array.IArray.bounds arr
vs
let
ith = Data.Array.IArray.(!) arr i
b = Data.Array.IArray.bounds arr
I'm not sure if I've managed to explain this problem clearly enough,
but my proposal is that we might consider changing the lexical syntax
of Haskell as follows:
varId ::= id
varOp ::= symbol
varIdOp ::= ` varId
varOpId ::= ( varOp )
varOpIdOp ::= ` varOpId
qvarId ::= {conId .}+ varId-- { }+ denotes 1 or more times
qvarIdOp ::= ` qvarId
qvarOp ::= {conId .}+ varOp
qvarOpId ::= {conId .}+ varOpId
qvarOpIdOp ::= `qvarOpId
In other words, to turn an operator symbol into an id, the parentheses
would be put immediately around the symbol (with no spaces since this
is lexical syntax), and to turn an id into an operator the backquote
is put in front of the entire (qualified) id.
Why does the nice argument not apply equally well to infixifying things?
If I think I want to use infix some thing from Data.Array
and start typing
myArr Data.Array.
and find out element access has become get while I wasn't looking,
it's not my fault the author of Data.Array decided to use a function
when I was expecting an identifier - Shouldn't I be able to write
myArr Data.Arr.`get` ix
(Also the trailing backquote in the existing syntax is redundant)
The trailing backquote is just as redundant as the trailing close paren
in the syntax for using a symbol as a prefix function and just as
important for my comment on backticks as the closing paren is to your
proposal for sections -
it means it's lexically apparent at least at one side of the identifier
that it's a section/infixification
Brandon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Expressing seq
There must be a subtlety I'm missing, right? What if the types are not instances of Eq? Jason Thanks, I figured it was something simple. Now I just to convince myself there's no way around that. Is there a proof around somewhere? -- Chad Scherrer Time flies like an arrow; fruit flies like a banana -- Groucho Marx ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Expressing seq
Chad Scherrer wrote: I was reading on p. 29 of A History of Haskell (a great read, by the way) about the controversy of adding seq to the language. But other than for efficiency reasons, is there really any new primitive that needs to be added to support this? As long as the compiler doesn't optimize it away, why not just do something like this (in ghci)? Prelude let sq x y = if x == x then y else y Prelude 1 `sq` 2 2 Prelude (length [1..]) `sq` 2 Interrupted. There must be a subtlety I'm missing, right? The (sq x) function depends on x being an instance of typeclass Eq. Imagine a new typeclass Seq that is auto-defined for all types: class Seq a where seq :: a - (b - b) data Foo x = Bar x | Baz | Foo y x The instances always use a case to force just enough evaluation to compute the constructor, then return id: instance Seq Foo where seq a = case a of Bar _ - id Baz - id Foo _ _ - id foo1,foo2 :: Foo Int foo1 = undefined foo2 = Bar 1 Now (seq foo1) b will also be undefined which (seq foo2) b will be id b which is b. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Creating DLLs with GHC
Jason Dagit wrote: On 9/27/06, SevenThunders [EMAIL PROTECTED] wrote: Does cabal really work on windows? I've never had a problem with cabal on windows. I use it instead of makefiles and I'm reasonably happy with it. Although it's installed I notice that when I try to build my library using it, it dies on the first foreign import statement in the first .hs source it tries to compile. It is reminiscent of trying to import a foreign C module directly ghci. ghc.exe, on the other hand has no problem with it. Perhaps your .cabal file is not correct or your cabal version is too old? It's very hard to say without detailed error messages and a clear description of what you're doing (with sample code). Does this scheme address the problem of being unable to link external C libraries (a DLL) into the Haskell DLL? Are there any other workarounds here? I only create a DLL from haskell and link that in a C++ application. I haven't tried the other way. Probably over the next month or so the DLL I'm creating in Haskell will need to access an existing DLL. Hopefully this will work fine. Is it possible to create static link libraries compatible with MS VC++? Ultimately I'm trying to link my C code with Matlab. The C code stub will then call a bunch of Haskell routines. I have no idea. I'm fairly new to using Haskell in windows. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Actually I've had no problems linking external C DLLs into Haskell. I suspect that I can even create Haskell DLLs provided I'm not also externally linking a C library. The problem appears to be doing both at the same time. That is creating a DLL from Haskell source that also links to an external DLL. Right now it seems that something strange is happening with the linker. I have this statement approximately ghc --mk-dll -fglasgow-exts -fffi -o netsim.dll ExternLib.o ExternLib_stub.o dllNet.o src1.o src1_stub.o src2.o -package parsec -optl-lmatrixstack -optl-L. matrixstack.lib was created with dlltool.exe on windows so it should be gcc compliant. Now I've tried the following variations with the -optl-l argument. -optl-lcheese compiler doesn't complain about the cheese library not existing (matrixlib links still unresolved of course). This is a bad sign. -lmatrixstack compiler complains that matrixstack doesn't exist. This is true even if I create libmatrixstack.a matrixstack.a libmatrixstack.lib matrixstack.lib If I add a -L. argument (instead of optl-L) I get the same behavior as the original case. No complaints about not finding matrixstack.lib, but a bunch of unresolved references from this library. In the latter case, however a -lcheese argument does result in an error saying it can't find cheese. Keep in mind that compiling the standalone executable (without the --mk-dll flag) works just fine with the original -optl options linking to the matrixstack.lib library. Could this be a bug with my version of ghc 6.5, or perhaps a known issue? There is some statement about not being able to create multiple DLLs for a single project. Am I running up against such an issue? This would be surprising since presumably the compiled C code in the static library matrixstack.lib performs the external DLL access independent from what Haskell is doing. -- View this message in context: http://www.nabble.com/Creating-DLLs-with-GHC-tf2342692.html#a6536057 Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Expressing seq
Chad Scherrer wrote: Prelude let sq x y = if x == x then y else y Prelude 1 `sq` 2 2 Prelude (length [1..]) `sq` 2 Interrupted. There must be a subtlety I'm missing, right? Two, at least: First, your sq has a different type, as it requires an Eq instance: Prelude :t sq sq :: (Eq a) = a - t - t Prelude :t seq seq :: a - b - b Secondly, your sq is more akin to a deepSeq in that it forces all of its value instead of just evaluating to weak head normal form. Prelude [undefined] `seq` 1 1 Prelude [undefined] `sq` 1 *** Exception: Prelude.undefined You could implement seq explicitely for many types, for example, seqList []x = x seqList (_:_) x = x but not for function types. HTH, Bertram ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Creating DLLs with GHC
SevenThunders wrote: I am having some difficulty with creating a dynamic link library using GHC on windows XP. I am attempting to follow the example in http://www.haskell.org/ghc/docs/6.4/html/users_guide/win32-dlls.html though I have a binary build of ghc 6.5 My problem (I think) is that some of my Haskell source files link to an external C library also contained in a DLL. I generate my Haskell object files when I compile my Haskell executable. I then attempt to use the object files in a ghc compiler statement like this, ghc --mk-dll -o netsim.dll ExternLib.o ExternLib_stub.o dllNet.o src1.o src1_stub.o src2.o -optl-lmatrixstack -optl-L. My external C library is in matrixstack.dll and it has a corresponding static link stub library matrixstack.lib in the same directory as all the sources. It has references in one of the sources (say src1.hs). Unfortunately I get a host of undefined references to basically all the functions in matrixstack.dll and also some undefined references of the form Parsefile.o:ghc2996_0.hc:(.text+0x130): undefined reference to `TextziParserCombinatorsziParsecziError_show_closure' Parsefile.o:ghc2996_0.hc:(.text+0x220): undefined reference to `TextziParserCombinatorsziParsecziChar_spaces_closure' Parsefile.o:ghc2996_0.hc:(.text+0x24a): undefined reference to `TextziParserCombinatorsziParsecziChar_spaces_closure' Parsefile.o:ghc2996_0.hc:(.text+0x29c): undefined reference to `TextziParserCombinatorsziParsecziChar_spaces_closure' ... This appears to be coming from unsatisfied references to Text.ParserCombinators.Parsec, which I thought was a standard library. I note that my stand alone haskell executable links just fine and runs perfectly. What am I missing to make this work? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe I have solved one issue here. Apparently my matrixstack.lib was corrupted. I am not sure how this happened. Recompiling this library seems to have resolved the problem concerning undefined links. Sorry for the diversion and I do appreciate the help offered. -- View this message in context: http://www.nabble.com/Creating-DLLs-with-GHC-tf2342692.html#a6536255 Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A better syntax for qualified operators?
On Wednesday 27 September 2006 22:20, Brian Hulley wrote:
(The other change needed for LL(1) is to give contexts a marker before they
appear eg:
foo :: {MonadIO m} a - m a
)
Or move contexts to the end of a type and separate it with a | like Clean
does: (See 6.2 of http://clean.cs.ru.nl/download/Clean20/doc/CleanRep2.0.pdf)
foo :: a - m a | MonadIO m
Personally I like this style because I always think first about what the type
of the function should be (a - m a) and then about the contexts /
restrictions that hold for the variables (MonadIO).
I do the same thinking when writing list comprehensions. First I think of the
general form of the elements in the list: [ (a, b) ...
then I think about the restrictions on the variables: | a - [1..10], b -
[1..10], a b]
Bas van Dijk
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Curious Functor Class
Jeremy Gibbons wrote: I haven't assimilated the forall here, but datatypes with only one shape of data have been called Naperian by Peter Hancock (because they support a notion of logarithm), and they're instances of McBride and Paterson's idioms or applicative functors. http://sneezy.cs.nott.ac.uk/containers/blog/?p=14 http://www.cs.nott.ac.uk/~ctm/Idiom.pdf As for uses: Bruno Oliveira and I claim an application via The Essence of the Iterator Pattern: http://www.comlab.ox.ac.uk/jeremy.gibbons/publications/index.html#iterator Perhaps the key is that there exist types P and Q s.t. there's an isomorphism F a = (P - a,Q) This seems to be intuitively Napierian: ln (P - a,Q) = (P,ln a) | ln Q I can believe that Hoistables are in fact Idioms, though I know there are Idioms that are not Hoistables (Maybe and Either, for instance). (Also I think Idiom is a better class name than Applicative.) -- Ashley Yakeley Seattle WA ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: compiler-independent core libraries infrastructure
On Fri, Sep 15, 2006 at 05:12:34PM +0100, Neil Mitchell wrote: So, just to confirm in my mind what you are proposing: Compiler/Version specific Core: Yhc.Core, Hugs.Core, GHC.Core With a different version for each compiler version. Tied intimately to the compiler. A large issue with this, is that what needs to be tied intimately to the complier is very different for different compilers. for instance Data.Typeable and Data.Dynamic are fairly portableish haskell on ghc, but are primitives provided by the compiler in jhc as a very simple example. It leads to the current mess with the jhc libraries where it has bits and pieces of base. I can't just use base as is, because it implements a lot that jhc needs to implement natively or expects things that GHC.* provides, but Jhc.* doesn't, or at least provides with a different interface/semantics (and #ifdefs or tieing jhc's development with the fptools repos are not acceptable solutions) However, a lot of stuff depends on libraries provided by base, so I can't just ignore it. so I end up syncing some code from base, modifying some, having a big mess that is somewhat tricky to maintain. In any case, haskell-prime will clean this up some by giving a more complete compiler-provided set of libraries, and it looks like the fptools repos are moving in the right direction with modularization. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] flip dot
Since there's talk of removal of the composition operator in Haskell-prime, how about this: Instead of:foo = f . gyou write:foo = .g.fA leading dot would mean, apply all unnamed parameters to the function on the right. A trailing dot would mean, apply the result of the left to the function on the right. Prelude notNull = .null.not= [a] - BoolnotNull [1,2,3]= True[1,2,3].notNull= True[1,2,3].null.not = TrueI like this because it has the same perks as the composition operator, yet it looks like OO code and the data flows nicely from left to right. It reads especially well when using the bind operator on the same line. Thoughts?Thanks,Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: variadic functions and typeCast
Michael Shulman wrote: class TypeCast x y | x - y, y - x where typeCast :: x - y instance TypeCast x x where typeCast = id Anyway, my main question about typeCast is this: why is it needed here at all? First of all, there is a version of TypeCast that works within the same module, please see any code described in http://pobox.com/~oleg/ftp/Haskell/typecast.html Appendix D of the full HList paper (or, HList technical report, I should say) gives the reasons for TypeCast. Briefly, TypeCast lets us replace a (ground) type T with a type variable t subject to the constraint: TypeCast t T = t. The difference seems superficial since the typechecker can immediately discharge the constraint and replace t with T. Well, placing the TypeCast declaration in a different module, or the more convenient magic 6-line declaration of class TypeCast make sure that the typechecker delays the discharging of the TypeCast constraint. So the type variable t stays uninstantiated for a while. It matters in instance declarations. For example, class Foo x where foo :: x - Int instance Foo [Int] instance Foo Bool where foo x = fromEnum x If we write test1 = foo [read 1] we get an error: No instance for (Foo [a]). Indeed, `read 1' has the type 'a', which does not match Int. The typechecker certainly cannot chose the Foo [Int] instance because who knows what other instances of Foo may occur in other modules. We can tell the typechecker however that Foo [Int] is the only instance that can ever be in the whole program (that is, the world is `locally' closed, as far as the Foo [a] is concerned). We do that by writing instance TypeCast x Int = Foo [x] where foo [x] = typeCast x and now test1 = foo [read 1] typechecks (and works), without any type annotations. BTW, if we lied and did write another instance for Foo [T] for some T, the typecheker will complain. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] flip dot
Greg Fitzgerald wrote: Since there's talk of removal of the composition operator in Haskell-prime http://hackage.haskell.org/trac/haskell-prime/wiki/CompositionAsDot, how about this: Instead of: foo = f . g you write: foo = .g.f A leading dot would mean, apply all unnamed parameters to the function on the right. A trailing dot would mean, apply the result of the left to the function on the right. You mean apply the function on the right to the result of the left? Otherwise .g.f == \x - (g x) f Prelude notNull = .null.not = [a] - Bool notNull [1,2,3] = True [1,2,3].notNull = True [1,2,3].null.not = True I like this because it has the same perks as the composition operator, yet it looks like OO code and the data flows nicely from left to right. It reads especially well when using the bind operator on the same line. Thoughts? The left-to-right flow is pretty nice. I don't like the mechanics of your leading and internal dots - I don't see any way to interpret the internal dots as an infix operator without using some fancy typeclasses, whatever the leading dot gets to do. The infix dot would have to work at types (a - b) - (b - c) - (a - b) and a - (a - b) - b Instead, How about making . reverse composition, and having some other symbol for flip ($), maybe '#'. Then you get things like [1,2,3]#null.not Which still vaguely resemble OO operations, if you think of composing together a path of accessors first, and then indexing with it. you can even work with mutable fields reasonably nicely, obj#a.b.c.readIORef obj#a.b.c.flip writeIORef newVal Finally, Writing things in this left-to-right order lets you think of the starting value and make a sequence of transformations to get a result. Dangerously imperative ;) The existing order instead calls to mind successively reducing the problem of producing desired output to simpler problems, eventually reaching a previously produced value. Wonderfully mathematical ;) Brandon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] flip dot
Brandon Moore wrote: Greg Fitzgerald wrote: Since there's talk of removal of the composition operator in Haskell-prime http://hackage.haskell.org/trac/haskell-prime/wiki/CompositionAsDot, how about this: Instead of: foo = f . g you write: foo = .g.f A leading dot would mean, apply all unnamed parameters to the function on the right. A trailing dot would mean, apply the result of the left to the function on the right. You mean apply the function on the right to the result of the left? Otherwise .g.f == \x - (g x) f Prelude notNull = .null.not = [a] - Bool notNull [1,2,3] = True [1,2,3].notNull = True [1,2,3].null.not = True I like this because it has the same perks as the composition operator, yet it looks like OO code and the data flows nicely from left to right. It reads especially well when using the bind operator on the same line. Thoughts? The left-to-right flow is pretty nice. I don't like the mechanics of your leading and internal dots - I don't see any way to interpret the internal dots as an infix operator without using some fancy typeclasses, whatever the leading dot gets to do. The infix dot would have to work at types (a - b) - (b - c) - (a - b) and a - (a - b) - b Instead, How about making . reverse composition, and having some other symbol for flip ($), maybe '#'. Then you get things like [1,2,3]#null.not Which still vaguely resemble OO operations, if you think of composing together a path of accessors first, and then indexing with it. you can even work with mutable fields reasonably nicely, obj#a.b.c.readIORef obj#a.b.c.flip writeIORef newVal Finally, Writing things in this left-to-right order lets you think of the starting value and make a sequence of transformations to get a result. Dangerously imperative ;) The existing order instead calls to mind successively reducing the problem of producing desired output to simpler problems, eventually reaching a previously produced value. Wonderfully mathematical ;) Or, think of taking the continuation of your expression, and transforming it in left-to-right steps into one prepared to accept the value you've got. Brandon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Creating DLLs with GHC
SevenThunders wrote:
I am having some difficulty with creating a dynamic link library using
GHC on windows XP.
I need to report some additional strange DLL behavior with ghc.exe
unfortunately.
Although I solved my linking problems and was able to create a .dll and a MS
VC .lib file using a .def file.
I get a nasty run time error when my program exits.
Here is a snippet of the Haskell code:
module ExternLib where
...
import Foreign.C.String
import Foreign.Ptr
import Foreign.C.Types (CInt, CDouble )
import Foreign.Marshal.Array
import Foreign.Storable
foreign export stdcall initNetChan :: CString - Ptr CInt - IO ()
-- | initialize network parameters and return an integer array containing
-- indices to the uplink channel, downlink channel
initNetChan :: CString - Ptr CInt - IO()
initNetChan simstring cptr = do
-- some processing
...
let hup = mkCInt $ hupchan netop
let hdn = mkCInt $ hdnchan netop
print $ hup = ++ (show hup)
print $ hdn = ++ (show hdn)
-- write results to the output array
pokeElemOff cptr 0 hup
pokeElemOff cptr 1 hdn
peekElemOff cptr 0 = print
Here is the C code that calls it, (test.c)
#include stdio.h
extern void initNetChan(char *str, int *iout) ;
int zout[64] ;
int main(int argc, char *argv[])
{
printf(Starting initNetChan\n) ;
initNetChan(SimPrams.in, zout) ;
printf(Done initNetChan. out: %p\n, zout) ;
printf(out[0] = %d out[1] = %d\n, zout[0], zout[1]) ;
printf(Done) ;
return(1) ;
}
The dll itself uses this template taken from the GHC manual on DLLs
#include windows.h
#include Rts.h
extern void __stginit_ExternLib(void);
static char* args[] = { ghcDll, NULL };
/* N.B. argv arrays must end with NULL */
BOOL
STDCALL
DllMain
( HANDLE hModule
, DWORD reason
, void* reserved
)
{
if (reason == DLL_PROCESS_ATTACH) {
/* By now, the RTS DLL should have been hoisted in, but we need to
start it up. */
startupHaskell(1, args, __stginit_ExternLib);
return TRUE;
}
return TRUE;
}
I link test.c to my dll via a call
cl.exe test.c netsim.lib
Running test.exe yields
Starting initNetChan
hup = 26
hdn = 30
26
Done initNetChan. out: 00408960
out[0] = 26 out[1] = 30
Done
D:\Projects\BRPhoenix\NetworkSim\FastSimtest.exe
Starting initNetChan
hup = 26
hdn = 30
26
Done initNetChan. out: 00408960
out[0] = 26 out[1] = 30
Done
which is correct, but then the code crashes with a run time error. It is an
unhandled exception: access violation.
Is it possible that the Haskell code needs to do some kind of finalization
process before terminating?
I haven't seen the documentation for it yet. Hopefully it's just something
stupid I've done, but again I am baffled.
--
View this message in context:
http://www.nabble.com/Creating-DLLs-with-GHC-tf2342692.html#a6539263
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Curious Functor Class
I wrote: Perhaps the key is that there exist types P and Q s.t. there's an isomorphism F a = (P - a,Q) This seems to be intuitively Napierian: ln (P - a,Q) = (P,ln a) | ln Q I can believe that Hoistables are in fact Idioms, though I know there are Idioms that are not Hoistables (Maybe and Either, for instance). Ah, that's not correct, not all Hoistables are Idioms. For instance, this type can be made an instance of Hoistable but not of Idiom: data Extra a = MkExtra Int a -- Ashley Yakeley Seattle WA ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Creating DLLs with GHC
SevenThunders wrote:
SevenThunders wrote:
I am having some difficulty with creating a dynamic link library using
GHC on windows XP.
I need to report some additional strange DLL behavior with ghc.exe
unfortunately.
Although I solved my linking problems and was able to create a .dll and a
MS VC .lib file using a .def file.
I get a nasty run time error when my program exits.
Here is a snippet of the Haskell code:
module ExternLib where
...
import Foreign.C.String
import Foreign.Ptr
import Foreign.C.Types (CInt, CDouble )
import Foreign.Marshal.Array
import Foreign.Storable
foreign export stdcall initNetChan :: CString - Ptr CInt - IO ()
-- | initialize network parameters and return an integer array containing
-- indices to the uplink channel, downlink channel
initNetChan :: CString - Ptr CInt - IO()
initNetChan simstring cptr = do
-- some processing
...
let hup = mkCInt $ hupchan netop
let hdn = mkCInt $ hdnchan netop
print $ hup = ++ (show hup)
print $ hdn = ++ (show hdn)
-- write results to the output array
pokeElemOff cptr 0 hup
pokeElemOff cptr 1 hdn
peekElemOff cptr 0 = print
Here is the C code that calls it, (test.c)
#include stdio.h
extern void initNetChan(char *str, int *iout) ;
int zout[64] ;
int main(int argc, char *argv[])
{
printf(Starting initNetChan\n) ;
initNetChan(SimPrams.in, zout) ;
printf(Done initNetChan. out: %p\n, zout) ;
printf(out[0] = %d out[1] = %d\n, zout[0], zout[1]) ;
printf(Done) ;
return(1) ;
}
The dll itself uses this template taken from the GHC manual on DLLs
#include windows.h
#include Rts.h
extern void __stginit_ExternLib(void);
static char* args[] = { ghcDll, NULL };
/* N.B. argv arrays must end with NULL */
BOOL
STDCALL
DllMain
( HANDLE hModule
, DWORD reason
, void* reserved
)
{
if (reason == DLL_PROCESS_ATTACH) {
/* By now, the RTS DLL should have been hoisted in, but we need to
start it up. */
startupHaskell(1, args, __stginit_ExternLib);
return TRUE;
}
return TRUE;
}
I link test.c to my dll via a call
cl.exe test.c netsim.lib
Running test.exe yields
Starting initNetChan
hup = 26
hdn = 30
26
Done initNetChan. out: 00408960
out[0] = 26 out[1] = 30
Done
D:\Projects\BRPhoenix\NetworkSim\FastSimtest.exe
Starting initNetChan
hup = 26
hdn = 30
26
Done initNetChan. out: 00408960
out[0] = 26 out[1] = 30
Done
which is correct, but then the code crashes with a run time error. It is
an unhandled exception: access violation.
Is it possible that the Haskell code needs to do some kind of finalization
process before terminating?
I haven't seen the documentation for it yet. Hopefully it's just
something stupid I've done, but again I am baffled.
Well I'm batting 1000 today. It was my dumb fault again. In case this
helps someone else, I forgot to use the --stdcall prefix to the function
declaration. Thus my stack was trashed.
I needed to use a declaration something like
__declspec(dllimport) void __stdcall initNetChan(HsPtr a1, HsPtr a2);
--
View this message in context:
http://www.nabble.com/Creating-DLLs-with-GHC-tf2342692.html#a6539496
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: variadic functions and typeCast
On 9/27/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: First of all, there is a version of TypeCast that works within the same module, please see any code described in http://pobox.com/~oleg/ftp/Haskell/typecast.html Yes, I was aware of that; I gave the shorter version just because it's shorter. I didn't realize how well-known this TypeCast is, so forgive my ignorance. Thanks for your answer. I think the real point at which I was confused is that the type-checker never unifies types in order to *find* an instance of a class, but functional dependencies of a class can make it unify types. Thus, by making the instance look more general but moving the unification into a TypeCast constraint, since TypeCast has a bidirectional fundep, we can make the instance match a pair of types that aren't yet unified, and then use TypeCast's fundep to force their unification. Is that right? Mike ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
