Re: [GHC] #1781: Type equality class leads to non-termination
#1781: Type equality class leads to non-termination
+---
Reporter: chak |Owner:
Type: bug | Status: new
Priority: normal |Milestone:
Component: Compiler (Type checker) | Version: 6.9
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Os: Unknown | Testcase:
Architecture: Unknown |
+---
Comment (by chak):
This program was rejected by 6.6.1 with the message
{{{
/Users/chak/Code/haskell/E_Class.hs:10:0:
The equation(s) for `plus' have two arguments,
but its type `Int - a' has only one
}}}
which is arguably not the right thing to do either.
I haven't traced this, but the problem may well be due to an interaction
between equality constraints and FDs - at least since I fixed
`TcUnify.subFunTys`. The latter function will defer a wanted equality `a
~ (b1 - b2)`, which in principle would be entailed by the given `E a (Int
- Int)` (with `b1, b2 := Int`). However, the normalisation and
entailment machinery for equalities doesn't know about FDs. (I would
think that should lead to an error message rather than non-termination,
but oh well)
Incidentally,
{{{
module ShouldCompile where
plus :: (a ~ (Int - Int)) = Int - a
plus x y = x + y
}}}
works fine.
I would expect that this would be fixed as soon as we implement FDs by way
of TFs.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1781#comment:1
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
-O bug?
Dear GHC developers, The point (1) below looks like a bug (in all GHC versions!). (1) -O for demo-test. Take (the public) docon-2.10 build it under -O, install, and build also under -O its test program by cd demotest ghc $doconCpOpt -O --make Main Either the latter compilation will loop forever or it will take an unnaturally large resource. Yes, the functions T_.test, T_tt are defined in rather a particular way (see them). I always build this test under -Onot, because compiling with optimization has not much sense for this part. But slill. (2) -O2 In my DoCon programs, -O2 was always worse than -O: the code is about 1.3 times larger and 1.2 times slower. There are some particular points in my programs. For example, almost everywhere I set Integer rather than Int, I do not recall others, now. In never complained on (1) and (2) because did not recall of them and because they do not bite me in practice, so far. - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
6.8.1-candidate tested
Dear GHC developers, I have tested ghc-6.8.0.20071015-src.tar.bz2 on DoCon and on Dumatel. It looks all right (except the bug-candidate for -O which is common to all GHC versions and which I recently reported ). On DoCon, ghc-6.8.0.20071015 1) builds the project 2-3 times faster than ghc-6.6.1, 2) its produced .a code is 1.6 times larger, 3) the test runs 1.4 times faster, 4) the minimal space (2500 Kb) for the test running remains. This looks all right. Regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #1782: gmake check-packages fails for ghc-6.8.0.20071017-src on solaris
#1782: gmake check-packages fails for ghc-6.8.0.20071017-src on solaris
---+
Reporter: guest | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: Compiler |Version: 6.8
Severity: normal| Keywords:
Difficulty: Unknown | Os: Solaris
Testcase:| Architecture: x86
---+
the tests in the toplevel Makefile go wrong:
{{{
check-packages :
- @for d in `cat libraries/core-packages`; do \
+ @ds=`cat libraries/core-packages`;\
+ for d in $$ds; do \
if test ! -d libraries/$$d; then \
echo Looks like you're missing libraries/$$d,; \
echo maybe you haven't done './darcs-all get'?; \
exit 1; \
fi \
done
- @if test ! -e libraries/base/configure; then \
+ @if test ! -f libraries/base/configure; then \
echo Looks like you're missing base's configure script.; \
}}}
sh `test` under solaris does not understand '`-e`' and '`cat libraries
/core-packages`' is treated as a single argument if not assigned to a
variable.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1782
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: 6.8.1-candidate tested
Serge D. Mechveliani wrote: Dear GHC developers, I have tested ghc-6.8.0.20071015-src.tar.bz2 on DoCon and on Dumatel. It looks all right (except the bug-candidate for -O which is common to all GHC versions and which I recently reported ). On DoCon, ghc-6.8.0.20071015 1) builds the project 2-3 times faster than ghc-6.6.1, 2) its produced .a code is 1.6 times larger, I have noticed binary sizes increasing by around 20% on the nofib suite too. We've discovered one issue with some dictionaries not being inlined when we would expect them to, but there may be others. I'm investigating. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
profiling missing from snapshot?
Hi, I installed the binary ghc-6.8.0.20071017 snapshot, but when I try to compile with -prof, I get % ghc --make -O2 src/Xml2Xls -o xml2xls2 -prof [1 of 1] Compiling Main ( src/Xml2Xls.hs, src/Xml2Xls.o ) Linking xml2xls2 ... /usr/bin/ld: cannot find -lHSrts_p collect2: ld returned 1 exit status 'locate HSrts_p' and other searches only find some old ghc-6.6 stuff. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1545: GHCi debugger doesn't work on an unregisterised compiler
#1545: GHCi debugger doesn't work on an unregisterised compiler +--- Reporter: igloo|Owner: simonmar Type: bug | Status: new Priority: normal |Milestone: 6.10 branch Component: GHCi | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | +--- Changes (by simonmar): * owner: = simonmar Comment: validating a fix -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1545#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: profiling missing from snapshot?
Ketil Malde wrote: I installed the binary ghc-6.8.0.20071017 snapshot, but when I try to compile with -prof, I get % ghc --make -O2 src/Xml2Xls -o xml2xls2 -prof [1 of 1] Compiling Main ( src/Xml2Xls.hs, src/Xml2Xls.o ) Linking xml2xls2 ... /usr/bin/ld: cannot find -lHSrts_p collect2: ld returned 1 exit status 'locate HSrts_p' and other searches only find some old ghc-6.6 stuff. This one we know about: http://hackage.haskell.org/trac/ghc/ticket/1778 Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #1783: FD leads to non-termination of type checker
#1783: FD leads to non-termination of type checker
--+-
Reporter: chak | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler (Type checker) |Version: 6.9
Severity: normal | Keywords:
Difficulty: Unknown | Os: Unknown
Testcase: | Architecture: Unknown
--+-
Here another program that causes the type checker to diverge:
{{{
{-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies #-}
{-# LANGUAGE PatternSignatures, ScopedTypeVariables, FlexibleContexts #-}
module ShouldCompile where
import Prelude hiding (foldr, foldr1)
import Data.Maybe
class Elem a e | a - e
class Foldable a where
foldr :: Elem a e = (e - b - b) - b - a - b
-- foldr1 :: forall e. Elem a e = (e - e - e) - a - e -- WORKS!
foldr1 :: Elem a e = (e - e - e) - a - e
foldr1 f xs = fromMaybe (error foldr1: empty structure)
(foldr mf Nothing xs)
where mf :: Elem a e = (e - Maybe e - Maybe e)
mf x Nothing = Just x
mf x (Just y) = Just (f x y)
}}}
This is the FD version of #1776. If we use lexically scoped type
variables - i.e., the signature marked with WORKS! - everything is fine.
However, we shouldn't have to use the scoped type variable as the FD rule
should combine the `Elem a e` constraints in the two signatures to
establish that the `e` in `foldr1`'s signature is the same as the `e` in
`mf`'s signature.
In contrast to #1781, there doesn't seem to be an equality constraint
involved in this example.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1783
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] #1546: maessen_hashtab is broken
#1546: maessen_hashtab is broken -+-- Reporter: igloo |Owner: simonpj Type: bug | Status: new Priority: high |Milestone: 6.8 branch Component: Compiler | Version: 6.6.1 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -+-- Comment (by simonmar): The cause of the segfaults is now fixed. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1546#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1545: GHCi debugger doesn't work on an unregisterised compiler
#1545: GHCi debugger doesn't work on an unregisterised compiler
+---
Reporter: igloo|Owner: igloo
Type: merge| Status: new
Priority: normal |Milestone: 6.10 branch
Component: GHCi | Version: 6.6.1
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Os: Unknown | Testcase:
Architecture: Unknown |
+---
Changes (by simonmar):
* owner: simonmar = igloo
* type: bug = merge
Comment:
Fixed, to merge:
{{{
Thu Oct 18 11:19:29 BST 2007 Simon Marlow [EMAIL PROTECTED]
* fix breakpoints in unregisterised mode
Thu Oct 18 11:53:40 BST 2007 Simon Marlow [EMAIL PROTECTED]
* fix :print when !tablesNextToCode
Thu Oct 18 12:06:21 BST 2007 Simon Marlow [EMAIL PROTECTED]
* fix -fbreak-on-exception for unregsterised
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1545#comment:2
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1545: GHCi debugger doesn't work on an unregisterised compiler
#1545: GHCi debugger doesn't work on an unregisterised compiler +--- Reporter: igloo|Owner: igloo Type: merge| Status: new Priority: normal |Milestone: 6.8 branch Component: GHCi | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | +--- Changes (by simonmar): * milestone: 6.10 branch = 6.8 branch -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1545#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1546: maessen_hashtab is broken
#1546: maessen_hashtab is broken
-+--
Reporter: igloo |Owner: simonpj
Type: bug | Status: new
Priority: high |Milestone: 6.8 branch
Component: Compiler | Version: 6.6.1
Severity: normal| Resolution:
Keywords:| Difficulty: Unknown
Os: Unknown | Testcase:
Architecture: Unknown |
-+--
Comment (by simonmar):
For reference, the patch that fixed the segfaults was:
{{{
Wed Oct 17 13:56:57 BST 2007 Simon Marlow [EMAIL PROTECTED]
* recordMutable: test for gen0 before calling recordMutableCap
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1546#comment:4
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #1785: xargs failure
#1785: xargs failure
---+
Reporter: guest | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: Compiler |Version: 6.8
Severity: normal| Keywords:
Difficulty: Unknown | Os: Solaris
Testcase:| Architecture: x86
---+
I don't know how the file `libraries/base/GNUMakefile` is generated. Maybe
this is a cabal bug.
My build of ghc-6.8.0.20071017 failed as follows:
{{{
...
t/build/Unsafe/Coerce_split -name '*.o' -print) | xargs -s 3
/usr/ccs/bin/ar
q dist/build/libHSbase-3.0.a
xargs: 0 max-cmd-line-size = 2048: 3
xargs: Usage: xargs: [-t] [-p] [-e[eofstr]] [-E eofstr] [-I replstr]
[-i[replstr
]] [-L #] [-l[#]] [-n # [-x]] [-s size] [cmd [args ...]]
gmake[2]: *** [dist/build/libHSbase-3.0.a] Error 2
}}}
if I replace 3 with 2048 compilation goes through, but I don't know if
something is cut off.
(also see http://hackage.haskell.org/trac/hackage/ticket/98#comment:2)
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1785
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] #1784: Duplicate cases for EM_AMD64 and EM_X86_64
#1784: Duplicate cases for EM_AMD64 and EM_X86_64
---+
Reporter: guest | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: Compiler |Version: 6.8
Severity: normal| Keywords:
Difficulty: Unknown | Os: Solaris
Testcase:| Architecture: x86
---+
The Solaris compiler gcc_4.2.2 complained about the values EM_AMD64 and
EM_X86_64 being identical:
{{{
Linker.c: In function 'ocVerifyImage_ELF':
Linker.c:2908:0: error: duplicate case value
Linker.c:2905:0: error: previously used here
gmake[1]: *** [Linker.o] Error 1
}}}
As a workaround I've deleted the EM_AMD64 case in `rts/Linker.c` of the
ghc-6.8.0.20071017 sources.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1784
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] #1652: System.Directory.copyFile breakage
#1652: System.Directory.copyFile breakage
---+
Reporter: sorear |Owner: igloo
Type: merge | Status: new
Priority: normal |Milestone: 6.8 branch
Component: libraries/base | Version: 6.7
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Os: Linux | Testcase:
Architecture: x86 |
---+
Changes (by simonmar):
* owner: simonmar = igloo
* type: bug = merge
Comment:
Fixed, thanks.
In libraries/base:
{{{
Thu Oct 18 13:23:45 BST 2007 Simon Marlow [EMAIL PROTECTED]
* FIX #1652: openTempFile should accept an empty string for the
directory
}}}
in libraries/directory:
{{{
Thu Oct 18 13:01:15 BST 2007 Simon Marlow [EMAIL PROTECTED]
* Move tests from testsuite/tests/ghc-regress/lib/Directory
Thu Oct 18 13:14:05 BST 2007 Simon Marlow [EMAIL PROTECTED]
* move copyFile001 from testsuite
Thu Oct 18 13:17:55 BST 2007 Simon Marlow [EMAIL PROTECTED]
* import System.Directory, not Directory
Thu Oct 18 14:06:23 BST 2007 Simon Marlow [EMAIL PROTECTED]
* add test for #1652
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1652#comment:3
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1776: type families : couldn't match type Elem a against type Elem a
#1776: type families : couldn't match type Elem a against type Elem a -+-- Reporter: guest |Owner: chak Type: bug | Status: closed Priority: normal|Milestone: Component: Compiler | Version: 6.8 Severity: normal| Resolution: fixed Keywords:| Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -+-- Changes (by chak): * status: new = closed * resolution: = fixed -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1776#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1450: ^C doesn't result in the cost center stack being printed when running with +RTS -xc
#1450: ^C doesn't result in the cost center stack being printed when running with +RTS -xc ---+ Reporter: SamB|Owner: simonmar Type: bug | Status: new Priority: normal |Milestone: 6.8 branch Component: Runtime System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | ---+ Changes (by simonmar): * owner: = simonmar Comment: validating fix -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1450#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1530: debugging :steps inside TH spliced code need to be bypassed
#1530: debugging :steps inside TH spliced code need to be bypassed -+-- Reporter: mnislaih |Owner: Type: bug | Status: new Priority: normal|Milestone: 6.8 branch Component: GHCi | Version: 6.7 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Os: Unknown | Testcase: dynbrk005 Architecture: Unknown | -+-- Changes (by simonmar): * owner: [EMAIL PROTECTED] = -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1530#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #1786: can't build ghc-6.8.0.20071017 under Solaris using a GNU linker
#1786: can't build ghc-6.8.0.20071017 under Solaris using a GNU linker
---+
Reporter: guest | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: Compiler |Version: 6.8
Severity: normal| Keywords:
Difficulty: Unknown | Os: Solaris
Testcase:| Architecture: x86
---+
if I have a GNU linker first in my PATH then configure allows the -x
option for linking, but then the stage1/ghc-inplace still uses the Solaris
linker via gcc and fails:
{{{
/usr/ccs/bin/ld: illegal option -- x
usage: ld [-6:abc:d:e:f:h:il:mo:p:rstu:z:B:CD:F:GI:L:M:N:P:Q:R:S:VY:?]
file(s)
[-64] enforce a 64-bit link-edit
[-a]create an absolute file
[-b]do not do special PIC relocations in a.out
[-B direct | nodirect]
establish direct bindings, or inhibit direct
binding
to, the object being created
[-B dynamic | static]
search for shared libraries|archives
[-B eliminate] eliminate unqualified global symbols from the
symbol table
[-B group] relocate object from within group
[-B local] reduce unqualified global symbols to local
[-B reduce] process symbol reductions
[-B symbolic] bind external references to definitions when
creating
shared objects
[-c name] record configuration file `name'
[-C]demangle C++ symbol name diagnostics
[-d y | n] operate in dynamic|static mode
[-D token,...] print diagnostic messages
[-e epsym] use `epsym' as entry point address
[-f name] specify library for which this file is an
auxiliary
filter
[-F name] specify library for which this file is a filter
[-G]create a shared object
[-h name] use `name' as internal shared object identifier
[-i]ignore LD_LIBRARY_PATH setting
[-I name] use `name' as path of interpreter
[-l x] search for libx.so or libx.a
[-L path] search for libraries in directory `path'
[-m]print memory map
[-M mapfile]use processing directives contained in `mapfile'
[-N string] create a dynamic dependency for `string'
[-o outfile]name the output file `outfile'
[-p auditlib] identify audit library to accompany this object
[-P auditlib] identify audit library for processing the
dependencies
of this object
[-Q y | n] do|do not place version information in output file
[-r]create a relocatable object
[-R path] specify a library search path to be used at run
time
[-s]strip any symbol and debugging information
[-S supportlib]
specify a link-edit support library
[-t]do not warn of multiply-defined symbols that have
different sizes or alignments
[-u symname]create an undefined symbol `symname'
[-V]print version information
[-Y P,dirlist] use `dirlist' as a default path when searching for
libraries
[-z absexec]when building an executable absolute symbols
referenced in dynamic objects are promoted to
the executable
[-z allextract | defaultextract | weakextract]
extract all member files, only members that
resolve
undefined tor tentative symbols, or allow
extraction of
archive members to resolvetweak references from
archive files
[-z altexec64] execute the 64-bit link-editor
[-z combreloc] combine multiple relocation sections
[-z defs] disallow undefined symbol references
[-z direct | nodirect]
enable|disable direct binding to shared object
dependencies
[-z endfiltee] marks a filtee such that it will terminate a
filters
search
[-z finiarray=function]
name of function to be appended to the .finiarray
[-z groupperm | nogroupperm]
enable|disable setting of group permissions
on dynamic dependencies
[-z help ] print this usage message
[-z ignore | record]
Re: [GHC] #1395: let ./configure check for a GNUreadline framework
#1395: let ./configure check for a GNUreadline framework +--- Reporter: [EMAIL PROTECTED]|Owner: Type: feature request | Status: reopened Priority: normal |Milestone: 6.8 branch Component: Build System | Version: 6.8 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Os: MacOS X | Testcase: Architecture: Multiple | +--- Changes (by guest): * status: closed = reopened * cc: [EMAIL PROTECTED] (added) * version: 6.6.1 = 6.8 * resolution: fixed = Comment: It would be nice if also the frameworks under `$HOME/Library/Frameworks` are checked (and used) when building ghc. This requires an extra flag `-F$HOME/Library/Frameworks`. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1395#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1785: xargs failure
#1785: xargs failure -+-- Reporter: guest |Owner: Type: bug | Status: new Priority: normal|Milestone: Component: Compiler | Version: 6.8 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Os: Solaris | Testcase: Architecture: x86 | -+-- Comment (by guest): `xargs -s 3` is hard-coded in `libraries/Cabal/Distribution/Simple/GHC/Makefile.in` -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1785#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1785: xargs failure
#1785: xargs failure -+-- Reporter: guest |Owner: Type: bug | Status: new Priority: normal|Milestone: 6.8.1 Component: Compiler | Version: 6.8 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Os: Solaris | Testcase: Architecture: x86 | -+-- Changes (by igloo): * milestone: = 6.8.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1785#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1395: let ./configure check for a GNUreadline framework
#1395: let ./configure check for a GNUreadline framework +--- Reporter: [EMAIL PROTECTED]|Owner: Type: feature request | Status: reopened Priority: normal |Milestone: 6.8 branch Component: Build System | Version: 6.8 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Os: MacOS X | Testcase: Architecture: Multiple | +--- Comment (by igloo): Does this make a runtime dependency on frameworks in $HOME/Library/Frameworks? If so then this sounds like it could cause problems for a multi-user system. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1395#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1395: let ./configure check for a GNUreadline framework
#1395: let ./configure check for a GNUreadline framework
+---
Reporter: [EMAIL PROTECTED]|Owner:
Type: feature request | Status: reopened
Priority: normal |Milestone: 6.8 branch
Component: Build System | Version: 6.8
Severity: normal | Resolution:
Keywords: | Difficulty: Easy (1 hr)
Os: MacOS X | Testcase:
Architecture: Multiple |
+---
Comment (by guest):
Replying to [comment:4 igloo]:
Interesting question. I've created the mac binary dists with a local
GNUreadline framework. I hope my home directory wasn't left as framework
search path in the ghc-6.6.1 binary. man ld on Mac did not give me a
clue about this. (There's nothing like a RUN_LIBRARY_PATH.)
{{{
-search_paths_first
By default when the -dynamic flag is in effect, the -lx
and
-weak-lx options first search for a file of the
form
`libx.dylib' in each directory in the library search path,
then
a file of the form `libx.a' is searched for in the
library
search paths. This option changes it so that in each
path
`libx.dylib' is searched for then `libx.a' before the next
path
in the library search path is searched.
-framework name[,suffix]
Specifies a framework to link against. Frameworks are
dynamic
shared libraries, but they are stored in different
locations,
and therefore must be searched for differently. When this
option
is specified, ld searches for framework
`name.framework/name'
first in any directories specified with the -F option,
then in
the standard framework directories /Library/Frameworks,
/Net-
work/Library/Frameworks, and /System/Library/Frameworks.
The
placement of the -framework option is significant, as it
deter-
mines when and how the framework is searched. If the
optional
suffix is specified the framework is first searched for the
name
with the suffix and then without.
-weak_framework name[,suffix]
This is the same as the -framework name[,suffix] but forces
the
framework and all references to it to be marked as weak
imports.
Care must be taken when using this as the use of the non-
weak
symbol references in an object file may cause the program
to
crash when the symbol or framework is not present at
execution
time.
-Fdir Add dir to the list of directories in which to search for
frame-
works. Directories specified with -F are searched before
the
standard framework directories.
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1395#comment:5
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1395: let ./configure check for a GNUreadline framework
#1395: let ./configure check for a GNUreadline framework +--- Reporter: [EMAIL PROTECTED]|Owner: Type: feature request | Status: reopened Priority: normal |Milestone: 6.8 branch Component: Build System | Version: 6.8 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Os: MacOS X | Testcase: Architecture: Multiple | +--- Comment (by guest): I didn't find any dependencies in my binaries created with local frameworks (using grep and otool). Christian -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1395#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: bug 1711 revisited
Hi Ian - Here's what I've found: - libraries/haskell-src/Language/Haskell/Parser.hs still exists at the point the build stopped, with the original Oct.15 timestamp. - the suggested make.rebuild... command fails with the same problem. Console output: make rebuild.library.haskell-src rm -f -f stamp/configure.library.*.haskell-src haskell-src/unbuildable cd haskell-src setup/Setup clean cleaning... rm -f -rf haskell-src/setup rm -f haskell-src/GNUmakefile haskell-src/Makefile.local rm -f -rf haskell-src/setup mkdir haskell-src/setup cp haskell-src/Setup.*hs haskell-src/setup cd haskell-src/setup /usr/local/bin/ghc -Wall -cpp --make Setup.*hs -o Setup \ -i../../bootstrapping.Cabal -i../../ bootstrapping.filepath [42 of 42] Compiling Main ( Setup.hs, Setup.o ) Linking Setup ... rm -f -f stamp/configure.library.*.haskell-src haskell-src/unbuildable ( cd haskell-src setup/Setup configure \ --enable-library-profiling --enable-split-objs \ --prefix=/NONEXISTANT \ --bindir=/NONEXISTANT \ --libdir=/NONEXISTANT \ --libsubdir='$pkgid' \ --libexecdir=/NONEXISTANT \ --datadir=/NONEXISTANT \ --docdir=/NONEXISTANT \ --htmldir=/NONEXISTANT \ --with-compiler=../../compiler/stage1/ghc-inplace \ --with-hc-pkg=../../utils/ghc-pkg/ghc-pkg-inplace \ --with-hsc2hs=../../utils/hsc2hs/hsc2hs-inplace \ --with-ld=/usr/bin/ld \ --haddock-options=--use-contents=../index.html \ --use-index=../doc-index.html \ \ --configure-option=--with-cc=gcc ) \ touch stamp/configure.library.build-profiling- splitting.haskell-src || touch haskell-src/unbuildable Configuring haskell-src-1.0.1... rm -f haskell-src/GNUmakefile cp Makefile.local haskell-src if ifBuildable/ifBuildable haskell-src; then \ cd haskell-src setup/Setup makefile -f GNUmakefile; \ fi Preprocessing library haskell-src-1.0.1... Setup: happy command not found make: *** [haskell-src/GNUmakefile] Error 1 - I couldn't find a Parser.y file in haskell-src/Language/Haskell, but there was a Parser.ly file. When I removed that and reran the make command it ran for a while and eventually completed with: == Finished recursively making `all' for ways: p ... Registering haskell-src-1.0.1... Reading package info from dist/inplace-pkg-config ... done. Saving old package config file... done. Writing new package config file... done. which looks like success. Once that worked, I changed to the main directory (..) and ran make from there to continue the build, and that appears to have completed normally. Hope that gives you some clues about what to do next. Thanks Hal On Oct 17, 2007, at 11:33 AM, Ian Lynagh wrote: Hi Hal, On Tue, Oct 16, 2007 at 09:54:32PM -0700, Hal Perkins wrote: Sorry to revive a dead horse, but there's still a bit of a problem with building ghc on os x because of missing files that need to be created by happy. I downloaded the current stable sources yesterday (ghc-6.8.0.20071015-src.tar.bz2 and ghc-6.8.0.20071015-src- extralibs.tar.bz2) OK, ghc-6.8.0.20071015-src-extralibs.tar.bz2 definitely includes libraries/haskell-src/Language/Haskell/Parser.hs Preprocessing library haskell-src-1.0.1... Setup: happy command not found make[1]: *** [haskell-src/GNUmakefile] Error 1 Does the above file still exist at this point? If so, does cd libraries touch haskell-src/Language/Haskell/Parser.hs make rebuild.library.haskell-src work? If that doesn't do it, what about if you delete haskell-src/Language/Haskell/Parser.y and then try make rebuild.library.haskell-src ? Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #1787: Test.QuickCheck does not install (unbuildable) in HEAD
#1787: Test.QuickCheck does not install (unbuildable) in HEAD +--- Reporter: guest | Owner: Type: bug| Status: new Priority: normal | Milestone: Component: libraries (other) |Version: 6.9 Severity: major | Keywords: Difficulty: Unknown| Os: Unknown Testcase: | Architecture: Unknown +--- Title says it all. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1787 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] #1429: debugger src locations break with lhs files
#1429: debugger src locations break with lhs files -+-- Reporter: mnislaih |Owner: Type: bug | Status: reopened Priority: normal|Milestone: 6.8 branch Component: GHCi | Version: 6.7 Severity: minor | Resolution: Keywords: debugger | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -+-- Changes (by mnislaih): * status: closed = reopened * resolution: invalid = * severity: major = minor Old description: Probably srclocs being used by the debugger are those of the unlit-ed source tree. Things that fail include * :break line sets the breakpoint in the wrong place * :list * the ghci prompt New description: A bang pattern in a .lhs file confuses :list by one line Comment: I found it, it is a bang pattern in a .lhs file. Try with the usual suspect, a Setup.lhs file. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1429#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1429: :list gets confused by bang patterns in .lhs files
#1429: :list gets confused by bang patterns in .lhs files -+-- Reporter: mnislaih |Owner: Type: bug | Status: reopened Priority: normal|Milestone: 6.8 branch Component: GHCi | Version: 6.7 Severity: minor | Resolution: Keywords: debugger | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -+-- Changes (by mnislaih): * summary: debugger src locations break with lhs files = :list gets confused by bang patterns in .lhs files -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1429#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #1788: panic with Template Haskell splicing/quoting
#1788: panic with Template Haskell splicing/quoting ---+ Reporter: guest | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Compiler |Version: 6.6.1 Severity: normal| Keywords: Difficulty: Unknown | Os: Unknown Testcase:| Architecture: Unknown ---+ I got a panic when quoting a name in some qualified module. The demonstration code is at http://hpaste.org/3380. See http://hpaste.org/3380/diff?old=1new=2 for the diff between the panicky and non-panicky versions. This looks very similar to bug #1755, but shachaf in #haskell says it affects GHC 6.9.20071012. #haskell discussion log, search for 'panic' around 00:29: http://ircbrowse.com/channel/haskell/20071019 -- Nicholas Messenger ([EMAIL PROTECTED], omnId on #haskell) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1788 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] #1786: can't build ghc-6.8.0.20071017 under Solaris using a GNU linker
#1786: can't build ghc-6.8.0.20071017 under Solaris using a GNU linker
-+--
Reporter: guest |Owner:
Type: bug | Status: new
Priority: normal|Milestone: 6.8.1
Component: Compiler | Version: 6.8
Severity: normal| Resolution:
Keywords:| Difficulty: Unknown
Os: Solaris | Testcase:
Architecture: x86 |
-+--
Comment (by duncan):
This is a Cabal bug. See:
http://hackage.haskell.org/trac/hackage/ticket/98
Distribution/Simple/GHC.hs line 374:
{{{
ldArgs = [-r]
++ [-x] -- FIXME: only some systems's ld support the -x flag
++ [-o, ghciLibName . tmp]
}}}
We could fix this with a test during the configure step, or we could hack
it and assume that if we're on Solaris then we never use -x. The latter is
easy, the former is better.
Probably the right thing to do is in the configure step (in the
Distribution.Simple.Configure.configure function) is after all the known
programs have been configured, to run ld and test if it supports -x. If it
does, use lookupProgram/updateProgram to update the ProgramConfiguration
with the configured ld program modified to have programArgs = [-x].
Any volunteers?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1786#comment:2
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1787: Test.QuickCheck does not install (unbuildable) in HEAD
#1787: Test.QuickCheck does not install (unbuildable) in HEAD --+- Reporter: guest |Owner: duncan Type: bug| Status: new Priority: normal |Milestone: Component: libraries (other) | Version: 6.9 Severity: major | Resolution: Keywords: | Difficulty: Unknown Os: Unknown| Testcase: Architecture: Unknown| --+- Changes (by duncan): * owner: = duncan Comment: This is my fault and it should be fixed now, though that needs to be confirmed. I was updating ghc-6.8 to bootstrap cabal correctly and then taking advantage of that fix to update several packages to use cabal-1.2 features and add the cabal-version: =1.2 to the .cabal files of those libs. Cabal needs to be bootstraped correctly for this to work, otherwise it does not know it's own version number and will barf when it tries to check cabal-version: =1.2. So I fixed that in ghc-6.8 and updated a bunch of packages and validated. However many of those packages are aliased to packages used by ghc HEAD. QuickCheck is one of them. So in the mean time ghc HEAD was still not bootstrapping Cabal correctly so it fell over when it found QuickCheck.cabal specified cabal-version: =1.2. That's why it was unbuildable. I've now validated and pushed the same fix to bootstrap Cabal in ghc HEAD (and updated Cabal to match Cabal HEAD while I was at it). So it should now be fixed. It's amazing, I validated dozens of patches today and still managed to break ghc HEAD once and ghc-6.8 three times. I broke ghc-6.8 twice (with the same mistake of tabs in .cabal files which I still don't know how it got through) and once due to breaking windows which I didn't pick up with validating on linux (that should also be fixed). Then as I said, I broke ghc HEAD without ever touching it, but because parts of it are aliased with parts from the ghc-6.8 which I was modifying. The good news is that almost every core and extralib package builds with ghc-6.6 and 6.8 (where it makes sense for them to build with 6.6) and many also build with 6.4. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1787#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: -O in 6.8.1-candidate
On Thu, 2007-10-18 at 11:02 +0400, Serge D. Mechveliani wrote: On Oct 17, 2007, Don Stewart and Duncan Coutts wrote: [..] By default cabal uses ghc -O to build projects, so you won't see any difference if you comment it out of the cabal file. You will however if you explicitly turn off optimisations: ghc-options: -Onot or: cabal-setup configure --disable-optimization since the default is --enable-optimization which with ghc uses -O For GHC, it is necessary for the .cabal file to provide the field `ghc-options:', and the optimization keys are of this field. Hence, is not this confusing to allow the optimization keys anywhere else? Also seeing `--enable-optimization' the user needs also to recall of what kind of optimization is it. The ghc-options field allows you to pass anything flags you like to ghc. That does not mean that you should! :-) Cabal is supposed to be portable between Haskell implementations and to allow packages to also be portable. Some Haskell implementations provide a notion of optimisation and so Cabal supports that with the --enable-optimization flag. There's an additional advantage here, we can let the user decide if they want to build with or without optimization. With the ghc-options field, only the developer gets to decide. So, in summary it's much better not* to use lines like: ghc-options: -O and to let the user manage that with Cabal's --enable-optimization flag (which is on by default). If you have specific ghc optimisations that you really need to be applied, then it's ok to use the ghc-options: field. For example we use that in bytestring. The --enable-optimization flag also applies to other things, like compiling C code and in principle could apply to other tools like happy/alex, though at the moment it does not. Duncan ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
-O bug?
Dear GHC developers, The point (1) below looks like a bug (in all GHC versions!). (1) -O for demo-test. Take (the public) docon-2.10 build it under -O, install, and build also under -O its test program by cd demotest ghc $doconCpOpt -O --make Main Either the latter compilation will loop forever or it will take an unnaturally large resource. Yes, the functions T_.test, T_tt are defined in rather a particular way (see them). I always build this test under -Onot, because compiling with optimization has not much sense for this part. But slill. (2) -O2 In my DoCon programs, -O2 was always worse than -O: the code is about 1.3 times larger and 1.2 times slower. There are some particular points in my programs. For example, almost everywhere I set Integer rather than Int, I do not recall others, now. In never complained on (1) and (2) because did not recall of them and because they do not bite me in practice, so far. - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
6.8.1-candidate tested
Dear GHC developers, I have tested ghc-6.8.0.20071015-src.tar.bz2 on DoCon and on Dumatel. It looks all right (except the bug-candidate for -O which is common to all GHC versions and which I recently reported ). On DoCon, ghc-6.8.0.20071015 1) builds the project 2-3 times faster than ghc-6.6.1, 2) its produced .a code is 1.6 times larger, 3) the test runs 1.4 times faster, 4) the minimal space (2500 Kb) for the test running remains. This looks all right. Regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ANNOUNCE: GHC 6.8.1 Second Release Candidate
| - the list of outstanding issues for 6.8 branch is suspiciously long. has | this been reviewed in detail? Good point, Claus. Lots of people are using GHC for lots of things. This is a nice problem to have! But it does lead to lots of bug reports. We have limited resources, so we have to decide how best to spend them. In this case we have not reviewed the 6.8 list in detail because we thought it was more important to fix the ones that we knew were important. A major reason for Ian's announcement is that we'd like to give everyone an opportunity to say this one is really important to me. We certainly might have missed ones that actually are important. We also started the add yourself to the cc list mechanism, to enable the community to say which bugs are important to them. | several of the tickets look more or less | fixed, and there seems to be nothing standing in the way for fixing | some more, such as this one: | http://hackage.haskell.org/trac/ghc/ticket/1226 We would absolutely love help from you or anyone else to verify that the ones that are more or less fixed are indeed fixed; and to fix ones for which there is nothing standing in the way. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.8.1-candidate tested
Serge D. Mechveliani wrote: Dear GHC developers, I have tested ghc-6.8.0.20071015-src.tar.bz2 on DoCon and on Dumatel. It looks all right (except the bug-candidate for -O which is common to all GHC versions and which I recently reported ). On DoCon, ghc-6.8.0.20071015 1) builds the project 2-3 times faster than ghc-6.6.1, 2) its produced .a code is 1.6 times larger, I have noticed binary sizes increasing by around 20% on the nofib suite too. We've discovered one issue with some dictionaries not being inlined when we would expect them to, but there may be others. I'm investigating. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.8.1-candidate tested
On Thu, Oct 18, 2007 at 11:33:52AM +0100, Simon Marlow wrote: Serge D. Mechveliani wrote: Dear GHC developers, I have tested ghc-6.8.0.20071015-src.tar.bz2 on DoCon and on Dumatel. It looks all right (except the bug-candidate for -O which is common to all GHC versions and which I recently reported ). On DoCon, ghc-6.8.0.20071015 1) builds the project 2-3 times faster than ghc-6.6.1, 2) its produced .a code is 1.6 times larger, I have noticed binary sizes increasing by around 20% on the nofib suite too. We've discovered one issue with some dictionaries not being inlined when we would expect them to, but there may be others. I'm investigating. All this you can easily reproduce in the public docon-2.10: build the library under -O, build demotest/Main under -Onot and see the timing of everything and the .a size. Then try to build demotest/Main under -O. And compare to 6.6.1. Regards, --- Mechveliani ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Why only inference in type checking?
Dear All, A while ago, I had trouble understanding the coverage condition and I raised a question on this mailing list. Help was swift and adequate, especially the reference to the paper entitled Understanding Functional Dependencies via Constraint Handling Rules was very useful. However, having considered the problem of non-termination of the type checker, I can't help but wonder why the type checker is inference only. From the paper mentioned above, consider the following example: class Mul a b c | a b - c where (*) :: a - b - c type Vec b = [b] instance Mul a b c = Mul a (Vec b) (Vec c) where ... f b x y = if b then (*) x [y] else y For actual arguments of f, there is no issue whatsoever with decidability. The type checker in my brain uses unification, i.e. top-down. The type checker in GHC uses inference, i.e. bottom-up. Why inference potentially suffers from non-termination for this program, I understand. My question is this: Is there a reason why type checking in GHC is inference-only, as opposed to a meet-in-the-middle combination of unification and inference? Would the type checker use both unification and inference (let's say alternating evaluation of both), the number of programs for which termination can be guaranteed is considerably larger - if I'm not mistaken, but I may very well have gotten it wrong. Regards, Philip PS. I realize that for this dependent typing scenario is useless once Type Families are here. I can't wait for a GHC with TFs. I raise this question, simply to understand why inference was chosen exclusively. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc --make-parallel ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Can ghc execute compilations in parallel? (With GNU make, I'd say make -j 2 but how to achieve this with ghc --make ?) Thanks - J. Waldmann. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHF0FB3ZnXZuOVyMIRAv0LAKCu8Ub2Cbb9xGNlfVNhLAKdwe/vXQCfUG0l RokmawVrEibckG7QknybMkg= =eQQY -END PGP SIGNATURE- ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Prevent optimization from tempering with unsafePerformIO
Hello to all who have given me hints an suggestions about this topic whether directly by mail or over the mailing list. I do now have a much more concrete idea of how to optimize my programs. Thanks for your time! Bernd ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc --make-parallel ?
Johannes Waldmann wrote: Can ghc execute compilations in parallel? (With GNU make, I'd say make -j 2 but how to achieve this with ghc --make ?) Sorry, not at the moment. We implemented a hacky version of it for our Haskell Workshop '05 paper: http://haskell.org/~simonmar/bib/multiproc05_abstract.html but later concluded that GHC really needed some more substantial re-engineering to make it reliable. There's a ticket for it: http://hackage.haskell.org/trac/ghc/ticket/910 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.8.1 Second Release Candidate
| - the list of outstanding issues for 6.8 branch is suspiciously long. has | this been reviewed in detail? Good point, Claus. Lots of people are using GHC for lots of things. This is a nice problem to have! But it does lead to lots of bug reports. We have limited resources, so we have to decide how best to spend them. In this case we have not reviewed the 6.8 list in detail because we thought it was more important to fix the ones that we knew were important. i tried to explain my concerns to Ian off-list, but i'll make another attempt here, adding some related points about the tracker that have been on my mind for a while now. sorry if that make this reply longer, but i think the points are important (i would think that, wouldn't i?-). as usual, please understand that i hope this criticism may help you to get more out of your efforts, which i appreciate as much as others do: - people submit bugreports because they hope something is done about them; ideally, that something would be a fix, but with limited resources, that isn't always possible - i understand; what should be possible, though, is to let everyone know where each ticket stands, what is going to happen when, and that it hasn't just been forgotten - your previous habit of going through all tickets when a release comes up, and either assigning them or moving their milestone, was reassuring - one might disagree with your decisions, but at least nothing was forgotten, and it was clear what happened; my main suggestion was _not_ to abandon that habit for this and future releases. - the longer tickets stay in the tracker, the more tickets there'll be, the more difficult it will be to find the important ones, and the more difficult it will be to ensure that things don't fall by the wayside (noone bothers to report things they do not find important); the number of tickets in the tracker is not just a function of users vs resources, it is also affected by the way workflows are organised, and the efficiency of the tracker in supporting such organisation if you try to go through all tickets even briefly, i hope you'll agree with the following: - the current tracking system is not set up efficiently: one cannot tell the state of play just by looking at a ticket, but has to delve into the comments instead; in brief, trac is still mostly tracking tickets, instead of tracking the state of work in a workflow. just from looking at a ticket (not its description/history), it should be clear what its status is, what the next action is (need not be fix/merge, but could be: getting a testcase, clarifying an issue, looking up some specs, consulting some expert, waiting for a buildbot donation, waiting for a volunteer, ..; anything that explains what is holding things up), who's responsible for that next action (might be the submitter, the assignee, or a third party), what the deadline for that next action is (so people can make plans and decisions), and what is going to happen afterwards (so that everyone can see the intended workflow). the current system tells me none of that, it only tells me at what milestone the ticket will next be reviewed, and you're about to abandon even that guarantee. - clearing mostly fixed tickets away completely saves time and effort, delaying them creates extra work and clogs up the tracker - having whole groups of tickets without any milestone, or with obsolete milestones, stongly suggests that the tracker has passed its limits of useability and needs to be looked into as a matter of urgency before things get worse We also started the add yourself to the cc list mechanism, to enable the community to say which bugs are important to them. is there a query that lists tickets in priority order? also, each ticket should include its priority ranking and a text saying: add yourself to the cc list if you want to raise this ticket. other suggestions for the tracker: adding more status/next action/deadline/actor fields would help, if trac supports that (could be simple free-form text fields, or selections), and adding an email interface, so that you can simply forward an email to the tracker if you know your todo list is already full, to get back an issue/ ticket number (a lot better than to tell the sender to go away and submit a ticket, btw; you could initialise the ticket with the email, then ask the sender to fill in the details; there could be bugs-ghc-head@ and bugs-ghc-release@). also, if you want to increase the use of the tracker for patches, there needs to be a document flow (submitter sends patch for review, assignee reviews and returns comments, submitter updates patch, submitter adds tests, assignee takes over patch, assignee validates/ applies to head, release maintainer takes over patch, etc), not just attachments to tickets. it needs to be obvious not only what files
RE: Why only inference in type checking?
| For actual arguments of f, there is no issue whatsoever with | decidability. The type checker in my brain uses unification, i.e. | top-down. The type checker in GHC uses inference, i.e. bottom-up. Why | inference potentially suffers from non-termination for this program, I | understand. Actually GHC's type check uses checking when it knows the types, and inference only when it doesn't. | My question is this: Is there a reason why type checking in GHC is | inference-only, as opposed to a meet-in-the-middle combination of | unification and inference? It exactly does meet-in-the-middle. Maybe you can elaborate your reasoning? In any case, the restrictions on fundeps are needed for checking too. I believe. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Command Line Arguments
As an Haskell beginner, and considering this may be compiler dependent, I shall ask it on this list. How can I access command line arguments from my main function in my Main module? Cheers, -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Command Line Arguments
Hi As an Haskell beginner, and considering this may be compiler dependent, I shall ask it on this list. It's standard across all implementations. How can I access command line arguments from my main function in my Main module? import System.Environment main = do args - getArgs print args You can also do in GHCi and Hugs: :main test arguments To test your code with argument values. Thanks Neil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Command Line Arguments
On 18/10/2007, Neil Mitchell [EMAIL PROTECTED] wrote: Hi As an Haskell beginner, and considering this may be compiler dependent, I shall ask it on this list. It's standard across all implementations. So that's part of the Haskell98 standard? Nice! So, is it usual for compilers to implement extensions to the standard? If yes, where can I find the documentation for GHC extensions? How can I access command line arguments from my wmain function in my Main module? import System.Environment main = do args - getArgs print args Thank you! You can also do in GHCi and Hugs: :main test arguments To test your code with argument values. Thanks Neil -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Command Line Arguments
Hi So that's part of the Haskell98 standard? In the Haskell98 standard it can be imported from System, rather than System.Environment. Nowadays all compilers can use either. Nice! So, is it usual for compilers to implement extensions to the standard? If yes, where can I find the documentation for GHC extensions? Different compilers have different extensions. Yhc has very few, Hugs has a couple, GHC has loads. They are documented in the GHC manual. Thanks Neil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.8.1 Second Release Candidate
Claus Reinke wrote: - people submit bugreports because they hope something is done about them often. Sometimes I submit a bugreport to make sure the issue isn't completely forgotten, not because it's an important issue to me. (not really disagreeing, just saying) Isaac ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: type families not advertised for 6.8
On Thu, Oct 18, 2007 at 02:58:21AM +0100, Simon Peyton-Jones wrote: | Absolutely not; quite the reverse. It means that some of the *code* for | type functions happens to be in the 6.8 release --- but that code has bugs. | It's only in 6.8 for our convenience (to avoid too great a divergence between | the HEAD and 6.8), but we do not plan to *support* type functions in 6.8. | Doing that would delay 6.8 by 3 months. | | Do you make any difference between associated type synonyms and type | functions in this respect? No difference: both are in the 6.8 code base, but we won't support them there. Both are in the HEAD, and we will support them there. What does this imply for 6.8 support for FD's, as they now use the same type-coercions? Groeten, Remi ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc --make-parallel ?
On Thu, 2007-10-18 at 13:19 +0200, Johannes Waldmann wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Can ghc execute compilations in parallel? (With GNU make, I'd say make -j 2 but how to achieve this with ghc --make ?) We're also going to try and solve this in Cabal by having Cabal do the module dependency analysis and then call ghc (and pre-processors) in single shot mode and in parallel. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] [[spam]]
. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: Lazy SmallCheck 0.1
Announcing Lazy SmallCheck 0.1, a library for exhaustive, demand-driven testing of Haskell programs. Lazy SmallCheck is based on the idea that if a property holds for a partially-defined input then it must also hold for all fully-defined instantiations of that input. Compared to `eager' input generation in SmallCheck, Lazy SmallCheck may require significantly fewer test-cases to verify a property for all inputs up to a given depth. There is a webpage for Lazy SmallCheck: http://www-users.cs.york.ac.uk/~mfn/lazysmallcheck/ There you'll find a more detailed description, a worked example, a comparison with SmallCheck on a number of benchmarks, and link to download the library. The library was developed together with Fredrik Lindblad during his recent visits to York. Suggestions, experiences and bug reports are welcome! Matthew. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Trying to install binary-0.4
On Fri, 2007-10-19 at 01:00 +0200, Udo Stenzel wrote: Don Stewart wrote: If I understand correctly, the main issue for Udo is simply that the MonadFix instance is required by his code, and isn't available in binary 0.3 -- the version to be used on earlier GHCs. Is that right Udo? No, the issue is that nothing works. I replied earlier to Udo but just for the benefit of everyone else... The current darcs versions of binary and tar work with ghc-6.4, 6.6 and 6.8.x. They do require Cabal-1.2.x, but that also works with ghc 6.4 to 6.8. The bytestring package also works with 6.4 and 6.8. The Data.ByteString code was included in base in ghc-6.6 so the bytestring package is not needed for ghc-6.6. New tarball releases of Cabal-1.2.1, bytestring-0.9, binary-0.4.1, tar and others (zlib, bzlib, iconv) will appear on hackage in the next few days. The fps package is archaic and should be ignored. There is quite a bit of churn with ghc-6.8 because of the base package having been split up. This requires changes to the .cabal files of many packages to allow them to continue to build with old and new versions of ghc. So all will not be plain sailing for the first few weeks after ghc-6.8 comes out as maintainers update their packages. People will have to be patient and/or stick to ghc-6.6 for a bit. Duncan ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Trying to install binary-0.4
Don Stewart wrote: If I understand correctly, the main issue for Udo is simply that the MonadFix instance is required by his code, and isn't available in binary 0.3 -- the version to be used on earlier GHCs. Is that right Udo? No, the issue is that nothing works. It turns out that I actually wanted the MonadFix instance for something unrelated, only at about the same time (and using runGetState, I can even work around that if I want). Here's the story of how not to intall tar-1.0 on GHC 6.4: - I'm on a Ubuntu system, GHC 6.4 has been installen from .deb packages, my local GHC config is empty. - I unpack tar-1.0 and try to run Setup configure on it = module Distribution.Simple does not export UserHooks(confHook) - I need a more recent cabal, my choice is cabal-1.1.6.2, which install flawlessly. - back to tar-1.0 = base = 2.0 is required, = unix-1.0 is used for unix-any This is already messed up, tar wants unix-compat, not unix-any. (Or is it? See below.) Apparently, it is a fatal error to have a dash in any package name. This explains why System.PosixCompat will never be found, no matter how often I install it. - Since binary is also needed, I'll now install binary-0.3 = could not find module Data.ByteString - So I need ByteString. It is not in Hackage. Googling around leads me to http://www.cse.unsw.edu.au/~dons/fps.html, where I download fps-0.7, since fps is what binary.cabal mentions in a comment. - fps-0.7 install flawlessly. - back to building binary = constructor LPS is not found - no newer fps is available, I get bytestring from darcs - bytestring wants a newer cabal. But my patience is already running out, so instead I edit the cabal file, and it installs. - back to building binary = module Data.ByteString.Base not found At this point I'm fed up, delete the whole setup and go back to the one I already hacked up to work with binary-0.4. Getting binary-0.4 and hammering it into shape to run on GHC 6.4 would have been the next step anyway, and after that, tar-1.0 needs to be edited to refer to System.Posix and then it would probably work. I dimply remember that it was also impossible to install unix-compat because the wrong cabal was picked up and I ended up throwing out unix-compat completely. Okay, summarizing, what did cabal do for me? Well, it helped me install a new version of cabal and an obsolete version of something else. Sorry, but this whole experience is a huge turnoff. With things going that smoothly, I'm better off using ghc --make and distributing the stuff I cannot rely on directly with my code. Now here's the story for GHC 6.6: - I'm on Debian testing, GHC 6.6.1 is installed, cabal is 1.1.6.2. I'm in a fresh user account without local additions to GHC. - download tar-1.0, unpack and configure. Binary is needed. - download binary-0.3, installs flawlessly. - back to tar-1.0. Now this is weird: = Dependency unix-any: using unix-2.1 = cannot satisfy dependency unix-compat=0.1 Why does it want *both* unix and unix-compat? The .cabal file mentions only one of them, unix-compat. - download unix-compat, installs flawlessly. - tar works now So things look a lot better on GHC 6.6, but only because I used binary-0.3 instead of 0.4, and I did this only because Don recently mentioned it. Suppose I tried binary-0.4 (because I want 'instance MonadFix Get' or because I don't know better): - dependencies on split base cannot be fulfilled. I have to edit the cabal file. - bytestring needs to be updated - a new cabal is needed - the description of base has to be patched to remove the conflict with base - binary-0.4 installs now - try to configure tar-1.0 = Could not find module `Distribution.Setup' This is no fun at all. Not only do I have to work around the incompatible changes in base, the interface of Cabal also changed in an incompatible way. -Udo -- My teachers could easily have ridden with Jesse James for all the time they stole from me. -- Richard Brautigan signature.asc Description: Digital signature ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: Status of Haskell Prime Language definition
Iavor Diatchki wrote: http://hackage.haskell.org/trac/haskell-prime/wiki/FunctionalDependencies#Lossofconfluence There is nothing about the system being unsound there. Furthermore, I am unclear about the problem described by the link... The two sets of predicates are logically equivalent (have the same set of ground instances), here is a full derivation: (B a b, C [a] c d) using the instance (B a b, C [a] c d, C [a] b Bool) using the FD rule (B a b, C [a] c d, C [a] b Bool, b = c) using b = c (B a b, C [a] c d, C [a] b Bool, b = c, C [a] b d) omitting unnecessary predicates and rearranging: (b = c, B a b, C [a] b d) The derivation in the other direction is much simpler: (b = c, B a b, C [a] b d) using b = c (b = c, B a b, C [a] b d, C [a] c d) omitting unnecessary predicates (B a b, C [a] c d) You're right, I think I'm mixing up soundness with completeness and termination. My thought was that not explicitly mentioning the b=c constraint could lead to the type inference silently dropping this fact and letting an inconsistent set of instance declarations go through without noticing. But that would only be important in a setting where inconsistent instances are not reported early via the consistency condition but late when actually constructing terms. The consistency condition should be enough for soundness (no inconsistent axioms accepted), but I didn't dwell enough into FD to know such things for sure. Regards, apfelmus ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: [Haskell-cafe] Re: [Haskell] Announce: generating free theorems, online and offline
G'day. Quoting Janis Voigtlaender [EMAIL PROTECTED]: Hmm, but I can easily define an instance of Eq that does not satisfy this invariant. And I want the generated free theorem to be true for any legal Haskell program. I would think that if x == y isn't the same as not (x /= y) for some type, then it isn't a legal Haskell program, because it breaks a fairly obvious invariant of Eq. (The consensus on #haskell is that this is even true for NaNs, but I'd like to get an official ruling on that.) Unfortunately, the H98 report doesn't say this explicitly, so you're technically correct that such a misbehaving program is legal. Many invariants of this form are expressed as default instances, and if not, they should be. Obviously that's impossible in the case of, say, the associative law of Monoid. However, that isn't a precondition for a free theorem. Of course, it does not affect the correctness of the generated theorem, just its legibility. Of course. Consider this user feedback. :-) Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Bug in runInteractiveProcess?
On Oct 17, 2007, at 6:11 PM, Stefan O'Rear wrote: Just to be precise about it, though, there's nothing about Haskell per se that causes trouble with fork, right? This is a GHC implementation issue. Forking in the presense of multiple threads is a semantic nightmare. Anything any Haskell implementation does is going to be wrong in at least two ways, so it's probably best not to try. Write your fork- child code in C. Forking in the presence of multiple threads is not my problem - I don't want multiple threads. Any Haskell implementation will do fine as long as, like C, it doesn't use threads to solve internal runtime problems. I know that for some, the UNIX process machinery - fork, the file descriptors, execve, etc. - is an appalling and gruesome spectacle that surely ought to have faded away in the lovely new order of things, but it's really a fairly elegant system in its antique way, and UNIX (et al.) is built around it on a big scale. It isn't going away. Donn Cave, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Announce: generating free theorems, online and offline
[EMAIL PROTECTED] wrote: G'day. Quoting Janis Voigtlaender [EMAIL PROTECTED]: Hmm, but I can easily define an instance of Eq that does not satisfy this invariant. And I want the generated free theorem to be true for any legal Haskell program. I would think that if x == y isn't the same as not (x /= y) for some type, then it isn't a legal Haskell program, because it breaks a fairly obvious invariant of Eq. (The consensus on #haskell is that this is even true for NaNs, but I'd like to get an official ruling on that.) Okay, it is quite natural to take this stand. But as you say, there is no such commitment in the language definition. And even if there were, I doubt it would be possible to enforce such invariants in a compiler. So there would be illegal programs that are nevertheless accepted by the compilers. Not what we want, do we, in Haskell land? Many invariants of this form are expressed as default instances, and if not, they should be. Agreed. I was about to answer that the situation is the same with the monad laws not being valid for some monad we all love, and still we do not consider the resulting programs illegal. But your point about the associativity law for Monoid is correct: these laws do not turn up as preconditions for a free theorem. So we are back to those invariants that are expressed as default instances. For Eq the invariant is quite obvious. But what about Ord? Certainly there is also an invariant that can be observed from its default instances, but I don't see how it could be read off mechanically. And that's really the point of free theorems: to get as far as possible with an automated process. Afterwards, one can always simplify by using knowledge not possibly available to the generation algorithm. So if for the Eq-instances we are actually interested in we really know that the invariant holds, we can of course do away with one of the two (==)-, (/=)-conditions. Alternatively, it would be possible to hard-code special treatment of Haskell's standard type classes into Sascha's tool, so that for Eq, Ord, and so on, a minimal set of conditions is imposed from the outset. But that would not help in general with type classes specified by the user. A more general solution here would really be welcome. Of course, it does not affect the correctness of the generated theorem, just its legibility. Of course. Consider this user feedback. :-) Sure. More wanted :-) Ciao, Janis. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Announce: generating free theorems, online and offline
On 10/17/07, Janis Voigtlaender [EMAIL PROTECTED] wrote: Okay, it is quite natural to take this stand. But as you say, there is no such commitment in the language definition. And even if there were, I doubt it would be possible to enforce such invariants in a compiler. So there would be illegal programs that are nevertheless accepted by the compilers. Not what we want, do we, in Haskell land? These invariants are basically impossible to enforce by the compiler, but nonetheless certain classes have laws which are expected to hold, and I would not be surprised if (for example) GHC optimization RULES depended on them. For example, there's no way to enforce that the implementation of = is associative, but it's nonetheless stated in the description of Monad and code assumes it to be true. -- ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] [Fwd: undecidable overlapping instances: a bug?]
[Sorry, I guess this should have been in the cafe ...] Simon Peyton-Jones wrote: The trouble is that a) the coverage condition ensures that everything is well behaved b) but it's too restrictive for some uses of FDs, notably the MTL library c) there are many possibilities for more generous conditions, but the useful ones all seem complicated Concerning the last point I've dumped the current brand leader for (c) into http://hackage.haskell.org/trac/ghc/ticket/1241#comment:15. Better ideas for (c) would be welcome. Let's take the declaration: instance P = C t where ... The version of the coverage condition in my paper [1] requires that TV(t_Y) \subseteq TV(t_X), for each dependency (X-Y) \in F_C. (I'm using the notation from the paper; let me know if you need more help to parse it.) This formulation is simple and sound, but it doesn't use any dependency information that could be extracted from P. To remedy this, calculate L = F_P, the set of functional dependencies induced by P, and then expand the right hand side of the set inequality above by taking the closure of TV(t_X) with respect to L. In symbols, we have to check that: TV(t_Y) \subseteq TV(t_X)^+_L, for each (X-Y) \in F_C. I believe (but haven't formally proved) that this is sound; I don't know how to make a more general coverage condition without losing that. I don't know if it's sufficient for examples like MTL (because I'm not sure where to look for details of what that requires), but if it isn't then I'd be very suspicious ... All the best, Mark [1] http://www.cs.pdx.edu/~mpj/pubs/fundeps-esop2000.pdf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Class invariants/laws
Ryan Ingram wrote: These invariants are basically impossible to enforce by the compiler, but nonetheless certain classes have laws which are expected to hold, and I would not be surprised if (for example) GHC optimization RULES depended on them. I, in fact, would be surprised if there were such dependencies. (Not that there might not be good reasons to want to rely on such laws for some conceivable optimization, I just doubt that any implementation actually does.) Simon? For example, there's no way to enforce that the implementation of = is associative, but it's nonetheless stated in the description of Monad and code assumes it to be true. Do you have an example of such code? Anyway, how can code assume = to be associative? It would not make any difference for code whether or not = is associative. What is, of course, possible is that programmers assume = to be associative when doing refactorings of their code, such as juggling with do-notation. As far as implementations are concerned, I would conjecture that they all implement the single translation from do-notation to =-notation specified in the report. No need for any assumptions about associativity there. I might be wrong. Ciao, Janis. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Suspected stupid Haskell Question
Thomas Hartman wrote: Since I'm interested in the stack overflow issue, and getting acquainted with quickcheck, I thought I would take this opportunity to compare your ordTable with some code Yitzchak Gale posted earlier, against Ham's original problem. As far as I can tell, they're the same. They work on lists up to 10 element lists of strings, but on 10^6 size lists I lose patience waiting for them to finish. Is there a more scientific way of figuring out if one version is better than the other by using, say profiling tools? Or by reasoning about the code? No, measuring actual performance is the only way. t. import Data.List import qualified Data.Map as M import Control.Arrow import Test.QuickCheck import Test.GenTestData I couldn't find this one, so I was unable to test anything. [snip] Some ideas: - Your code doesn't contain a main function. Did you compile it? - Strings are lists; storing a string of n characters needs 12*n bytes on 32 bit architectures, and 24*n bytes with 64 bits. 1 million strings with 10 characters each will consume 120MB (or 240MB), without accounting for any overhead for the copying garbage collector. I expect that you can save some memory (and thus garbage collection time) by using Data.ByteString.ByteString (which uses about 32 + n (32 bits) or 64 + n bytes (64 bits), if I remember correctly). - On using Data.Map vs. sort and group: The main advantage of the first approach is that duplicates are eliminated as they are found. So in fact, if you have a list of only 100 different strings, your code will run in constant memory, assuming the list is built lazily. Your test case looks like there are only few duplicates, so I'd expect the Data.Map code to perform a bit worse than the Data.List one. But as I wrote above, profiling is the only way to find out for sure. Bertram ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] [Fwd: undecidable overlapping instances: a bug?]
Mark P Jones writes: [Sorry, I guess this should have been in the cafe ...] Simon Peyton-Jones wrote: The trouble is that a) the coverage condition ensures that everything is well behaved b) but it's too restrictive for some uses of FDs, notably the MTL library c) there are many possibilities for more generous conditions, but the useful ones all seem complicated Concerning the last point I've dumped the current brand leader for (c) into http://hackage.haskell.org/trac/ghc/ticket/1241#comment:15. Better ideas for (c) would be welcome. Let's take the declaration: instance P = C t where ... The version of the coverage condition in my paper [1] requires that TV(t_Y) \subseteq TV(t_X), for each dependency (X-Y) \in F_C. (I'm using the notation from the paper; let me know if you need more help to parse it.) This formulation is simple and sound, but it doesn't use any dependency information that could be extracted from P. To remedy this, calculate L = F_P, the set of functional dependencies induced by P, and then expand the right hand side of the set inequality above by taking the closure of TV(t_X) with respect to L. In symbols, we have to check that: TV(t_Y) \subseteq TV(t_X)^+_L, for each (X-Y) \in F_C. I believe (but haven't formally proved) that this is sound; I don't know how to make a more general coverage condition without losing that. I don't know if it's sufficient for examples like MTL (because I'm not sure where to look for details of what that requires), but if it isn't then I'd be very suspicious ... All the best, Mark [1] http://www.cs.pdx.edu/~mpj/pubs/fundeps-esop2000.pdf I think the above is equivalent to the (refined) weak coverage condition in [2] (see Section 6, p26). The weak coverage condition give us soundness. More precisely, we obtain confluence from which we can derive consistency (which in turn guarantees that the type class program is sound). *BUT* this only works if we have termination which is often very tricky to establish. For the example, class Concrete a b | a - b where bar :: a - String instance (Show a) = Concrete a b termination holds, but the weak coverage condition does *not* hold. Indeed, this program should be therefore rejected. Martin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Announce: generating free theorems, online and offline
G'day all. Quoting Janis Voigtlaender [EMAIL PROTECTED]: Okay, it is quite natural to take this stand. But as you say, there is no such commitment in the language definition. And even if there were, I doubt it would be possible to enforce such invariants in a compiler. So there would be illegal programs that are nevertheless accepted by the compilers. Not what we want, do we, in Haskell land? I guess this is, at its core, a philosophical question: Does the existence of default implementations imply that any specialised implementation must do the same thing (modulo strictness, efficiency etc) as the default one? I don't know the answer to that. Agreed. I was about to answer that the situation is the same with the monad laws not being valid for some monad we all love, and still we do not consider the resulting programs illegal. I do! The H98 report says that all Monad instances must obey the monad laws. If they don't, they're illegal. (As an aside: The H98 report still list the right-zero law as being a law for MonadPlus, even though most MonadPlus instances don't obey it. That's actually a defect in the report.) But your point about the associativity law for Monoid is correct: these laws do not turn up as preconditions for a free theorem. Right. And in that case, there's a clear reason why. The precondition for (Alg a) essentially says that the mapping function g :: C1 - C2 must be a Alg-homomorphism. That implicitly assumes that C1 and C2 are both valid Alg-es, so if there are any laws of Alg, C1 and C2 both obey them by fiat. So we are back to those invariants that are expressed as default instances. For Eq the invariant is quite obvious. But what about Ord? Certainly there is also an invariant that can be observed from its default instances, but I don't see how it could be read off mechanically. You could, from a dependency analysis, automatically work out a minimal set of methods which are needed to satisfy the class. In the case of Ord, for example, it doesn't seem too hard to deduce that you could either use (==) and (=), or (==) and compare. (You can't, unfortunately, mechanically deduce that (==) can be defined in terms of compare, despite what the last sentence of section 6.3.2 in the report says.) Now that I look at it, the report notes that: -- Note that (min x y, max x y) = (x,y) or (y,x) but never says that this requirement is mandatory. A more general solution here would really be welcome. In general, it'd be nice to be able to get the compiler to check that you've implemented at least a minimal set of operations in your class instance. Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] [Fwd: undecidable overlapping instances: a bug?]
Sorry, forgot to add [2] http://www.comp.nus.edu.sg/~sulzmann/publications/jfp-fds-revised.pdf Martin Martin Sulzmann writes: Mark P Jones writes: [Sorry, I guess this should have been in the cafe ...] Simon Peyton-Jones wrote: The trouble is that a) the coverage condition ensures that everything is well behaved b) but it's too restrictive for some uses of FDs, notably the MTL library c) there are many possibilities for more generous conditions, but the useful ones all seem complicated Concerning the last point I've dumped the current brand leader for (c) into http://hackage.haskell.org/trac/ghc/ticket/1241#comment:15. Better ideas for (c) would be welcome. Let's take the declaration: instance P = C t where ... The version of the coverage condition in my paper [1] requires that TV(t_Y) \subseteq TV(t_X), for each dependency (X-Y) \in F_C. (I'm using the notation from the paper; let me know if you need more help to parse it.) This formulation is simple and sound, but it doesn't use any dependency information that could be extracted from P. To remedy this, calculate L = F_P, the set of functional dependencies induced by P, and then expand the right hand side of the set inequality above by taking the closure of TV(t_X) with respect to L. In symbols, we have to check that: TV(t_Y) \subseteq TV(t_X)^+_L, for each (X-Y) \in F_C. I believe (but haven't formally proved) that this is sound; I don't know how to make a more general coverage condition without losing that. I don't know if it's sufficient for examples like MTL (because I'm not sure where to look for details of what that requires), but if it isn't then I'd be very suspicious ... All the best, Mark [1] http://www.cs.pdx.edu/~mpj/pubs/fundeps-esop2000.pdf I think the above is equivalent to the (refined) weak coverage condition in [2] (see Section 6, p26). The weak coverage condition give us soundness. More precisely, we obtain confluence from which we can derive consistency (which in turn guarantees that the type class program is sound). *BUT* this only works if we have termination which is often very tricky to establish. For the example, class Concrete a b | a - b where bar :: a - String instance (Show a) = Concrete a b termination holds, but the weak coverage condition does *not* hold. Indeed, this program should be therefore rejected. Martin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up!
On Wed, 17 Oct 2007 21:59:41 +0100 Andrew Coppin [EMAIL PROTECTED] wrote: Well anyway, as you can see, I'm back. Mainly because I have questions that I need answers for... Welcome back ;) This mailing list is the only place I know of that is inhabited by people who actually think Haskell is something worth persuing. Huh, the above is grievous offence to #haskell :-) Sincerely, Gour signature.asc Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Class invariants/laws
[EMAIL PROTECTED] wrote: Agreed. I was about to answer that the situation is the same with the monad laws not being valid for some monad we all love, and still we do not consider the resulting programs illegal. I do! The H98 report says that all Monad instances must obey the monad laws. If they don't, they're illegal. Okay. I wasn't aware that the report makes this mandatory. In general, it'd be nice to be able to get the compiler to check that you've implemented at least a minimal set of operations in your class instance. Yes. But actually what we would need would be that it checks as well that we have implemented at *most* a minimal set of operations. Otherwise, we are back to the point where I can implement both (==) and (/=), and in a way that the supposed invariant is broken. Ciao, Janis. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] [Fwd: undecidable overlapping instances: a bug?]
Hello, I believe that this weak coverage condition (which is also called the dependency condition somewhere on the wiki) is exactly what GHC 6.4 used to implement but than in 6.6 this changed. According to Simon's comments on the trac ticket, this rule requires FDs to be full to preserve the confluence of the system that is described in the Understanding Fds via CHRs paper. I have looked at the paper many times, and I am very unclear on this point, any enlightenment would be most appreciated (by the way, there was a post about that on the haskell-prime list a couple of days ago, which contains a concrete example as well). To answer Mark's question, this rule provides enough power for mtl and monadLib. They use classes like class StateM m s | m - s and instances like instance StateM m s = StateM (ExceptionT m) s. (The full source code for monadLib is at http://www.galois.com/~diatchki/monadLib/monadLib-3.3.0/src/MonadLib.hs) Martin, could you elaborate on the problem with non-termination? I have seen examples where the type-checker could loop while trying to prove things, but I was not aware that there were implications related to soundness as well. -Iavor On 10/18/07, Martin Sulzmann [EMAIL PROTECTED] wrote: Mark P Jones writes: [Sorry, I guess this should have been in the cafe ...] Simon Peyton-Jones wrote: The trouble is that a) the coverage condition ensures that everything is well behaved b) but it's too restrictive for some uses of FDs, notably the MTL library c) there are many possibilities for more generous conditions, but the useful ones all seem complicated Concerning the last point I've dumped the current brand leader for (c) into http://hackage.haskell.org/trac/ghc/ticket/1241#comment:15. Better ideas for (c) would be welcome. Let's take the declaration: instance P = C t where ... The version of the coverage condition in my paper [1] requires that TV(t_Y) \subseteq TV(t_X), for each dependency (X-Y) \in F_C. (I'm using the notation from the paper; let me know if you need more help to parse it.) This formulation is simple and sound, but it doesn't use any dependency information that could be extracted from P. To remedy this, calculate L = F_P, the set of functional dependencies induced by P, and then expand the right hand side of the set inequality above by taking the closure of TV(t_X) with respect to L. In symbols, we have to check that: TV(t_Y) \subseteq TV(t_X)^+_L, for each (X-Y) \in F_C. I believe (but haven't formally proved) that this is sound; I don't know how to make a more general coverage condition without losing that. I don't know if it's sufficient for examples like MTL (because I'm not sure where to look for details of what that requires), but if it isn't then I'd be very suspicious ... All the best, Mark [1] http://www.cs.pdx.edu/~mpj/pubs/fundeps-esop2000.pdf I think the above is equivalent to the (refined) weak coverage condition in [2] (see Section 6, p26). The weak coverage condition give us soundness. More precisely, we obtain confluence from which we can derive consistency (which in turn guarantees that the type class program is sound). *BUT* this only works if we have termination which is often very tricky to establish. For the example, class Concrete a b | a - b where bar :: a - String instance (Show a) = Concrete a b termination holds, but the weak coverage condition does *not* hold. Indeed, this program should be therefore rejected. Martin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] RE: [Haskell] [Fwd: undecidable overlapping instances: a bug?]
| I believe that this weak coverage condition (which is also called | the dependency condition somewhere on the wiki) is exactly what GHC | 6.4 used to implement but than in 6.6 this changed. According to | Simon's comments on the trac ticket, this rule requires FDs to be | full to preserve the confluence of the system that is described in | the Understanding Fds via CHRs paper. I have looked at the paper | many times, and I am very unclear on this point, any enlightenment | would be most appreciated. Right. In the language of http://hackage.haskell.org/trac/ghc/ticket/1241, last comment (date 10/17/07), it would be *great* to replace the Coverage Condition (CC) with the Weak Coverage Condition (WCC) as Mark suggests. BUT to retain soundness we can only replace CC with WCC + B WCC alone without (B) threatens soundness. To retain termination as well (surely desirable) we must have WCC + B + C (You'll have to look at the ticket to see what B,C are.) And since A+B+C are somewhat onerous, we probably want to have CC or (WCC + B + C) At least we know of nothing else weaker that will do (apart from CC of course). Like you, Iavor, I find it very hard to internalise just why (B) and (C) are important. But I believe the paper gives examples of why they are, and Martin is getting good at explaining it. Martin: can you give an example, once more, of the importance of (B) (=fullness)? Anyway that's why I have been moving slowly in fixing GHC: the rule CC or (WCC + B + C) just seems too baroque. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
Daniel McAllansmith [EMAIL PROTECTED] writes: 3. Otherwise, major.minor MUST remain the same (other version components MAY change). Is it an option to say SHOULD rather than MUST here? There are other reasons for a version bump than breaking compatibility. -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] Class invariants/laws
| These invariants are basically impossible to enforce by the compiler, | but nonetheless certain classes have laws which are expected to hold, | and I would not be surprised if (for example) GHC optimization RULES | depended on them. | | I, in fact, would be surprised if there were such dependencies. (Not | that there might not be good reasons to want to rely on such laws for | some conceivable optimization, I just doubt that any implementation | actually does.) | | Simon? I don't believe GHC relies on any class laws. It'd be pretty dangerous to do so, I think. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Do you trust Wikipedia?
Dan Weston writes: I find the mathematics is more accurate on http://www.conservapedia.com Their facts get checked by the Almighty Himself! ;) Since decent people here pointed out how my sarcasm may be blessing and useless, I must ask (living so far from the Bible Belt that I miss all standard American connotations...) Are you serious? (Not about the checking by the Lord, but concerning the quality of that conservapathologia?) My favourite citation, (apart from such obvious and meaningful things, as underlining the fact that Stalin appreciated Darwin, and now you know what to think about...) is the definition of point in geometry as an infinitely small dot. If you are not satisfied, you go point itself, and you read that A point can be represented on paper by a dot; however the dot is not a point, but only represents it. Because the actual dot contains millions of molecules of ink and other substances, whereas the point exists as an abstraction only. And you can die happy. === Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Bug in runInteractiveProcess?
John Goerzen wrote: On 2007-10-17, Simon Marlow [EMAIL PROTECTED] wrote: Note that forkProcess doesn't currently work with +RTS -N2 (or any value larger than 1), and it isn't likely to in the future. I suspect forkProcess should be deprecated. That would be most annoying, and would render HSH unable to function without using FFI to import fork from C. I suspect that forkProcess has some more intelligence to it than that, though I haven't looked. System.Process is not powerful enough to do serious work on POSIX, and perhaps it never can be. The mechanism for setting up a direct pipeline with more than 2 processes is extremely inconvenient at best, and it does not seem possible to create n-process pipelines using System.Process without having to resort to copying data in the Haskell process at some point. (This even putting aside the instant bug) Not only that, but the ProcessHandle system doesn't: * Let me get the child process's PID * Send arbitrary signals to the child process * Handle SIGCHLD in a custom and sane way * Get full exit status information (stopped by a particular signal, etc) Now, there are likely perfectly valid cross-platform reasons that it doesn't do this. Yes, absolutely. Although I *would* like there to be a more general version of runInteractiveProcess where for each FD the caller can choose whether to supply an existing Handle or to have a new pipe generated. This would let you pipe multiple processes together directly, which can't be done at the moment (we've discussed this before, I think). I am merely trying to point out that removing forkProcess in favor of System.Process will shut out a large number of very useful things. I wasn't intending to push users towards System.Process instead, rather to forking in C where it can be done safely. I completely agree that System.Process isn't a replacement for everything you might want to do with fork. Don't forget either that there are a whole class of programs whose multithreading needs may be better addressed by forkProcess, executeFile, and clever management of subprograms rather than by a threaded RTS. Ok, the non-threaded RTS can indeed support forkProcess without any difficulties. I'm not sure where that leaves us; the non-threaded RTS also cannot support waitForProcess in a multithreaded Haskell program, and it can't do non-blocking FFI calls in general. While we have no immediate plans to get rid of the non-threaded RTS, I'd really like to. The main reasons being that it adds another testing dimension, and it contains a completely separate implementation of non-blocking IO that we have to maintain. forkProcess, with the ability to dupTo, closeFd, and executeFile is still mighty useful in my book. Noted! Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Do you trust Wikipedia?
PR Stanley [EMAIL PROTECTED] writes: Do you trust mathematical materials on Wikipedia? Generally, yes. Another site you might want to cross check with is Wolfram Research's Mathworld: http://mathworld.wolfram.com/ -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Automatic file closing after readFile
I recently bumped into a problem with the feed on my WordPress blog. The problem was an extra empty line at the top of the XML file which some parsers choked on. I suspected there was some PHP file that contained an extra empty line at the top or bottom of the file so I hacked up this: hasEmpty s = let _first_empty = s !! 0 == '\n' _last_empty = (reverse s) !! 1 == '\n' in _first_empty || _last_empty loadAndCheck fp = liftM hasEmpty $ readFile fp main = getArgs = filterM loadAndCheck = mapM_ putStrLn Maybe not the most effective piece of code, but it worked. The one problem I had was that running this on /all/ files in my WP resulted in an exception: *** Exception: ./wp-includes/images/smilies/icon_mrgreen.gif: openFile: resource exhausted (Too many open files) Is there some (easy) way to avoid this while still using readFile? /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus．therning＠gmail．com http://therning.org/magnus Beauty is more important in computing than anywhere else in technology because software is so complicated. Beauty is the ultimate defence against complexity. -- David Gelernter signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
On Thursday 18 October 2007 21:15, you wrote: Daniel McAllansmith [EMAIL PROTECTED] writes: 3. Otherwise, major.minor MUST remain the same (other version components MAY change). Is it an option to say SHOULD rather than MUST here? Of course, SHOULD is an option just like MAY is. But both SHOULD and MAY reduce what you can reliably infer from a version number in the same way. If the rule is SHOULD or MAY, and the freedom is exercised, compatible versions of a package will differ in major[.minor] and dependent packages will be unable to benefit from their release. You'll need more maintenance work on package dependencies if you want to use the latest and greatest versions. In a similar way, if packages are being retained for a 'long time' to ensure dependent packages remain buildable, you are losing garbage collection opportunities. I'm pretty certain SHOULD will be far more socially acceptable than MUST. I can appreciate the fact that people are accustomed to incrementing version numbers in liberal ways. But if you look at version numbers dispassionately in the context of The goal of a versioning system is to inform clients of a package of changes to that package that might affect them... MUST seems a better choice. Maybe the Right Way of informing clients is full-on metadata and typing of packages and maybe we'll have that soon, so maybe a socially acceptable, weaker versioning scheme is acceptable. There are other reasons for a version bump than breaking compatibility. Technical reasons? In some cases a major bump would just be devolving to a minor bump. Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] About scandalous teaching
Dipankar Ray decided to invest himself after my last grumbling concerning the uselessnes of recalling that Haskell may be presented in schools in a very bad way. JK, of course there are foolish teachers out there. I don't think Felipe was suggesting that this teacher had the right idea, nor that he himself was going to stop haskelling anytime soon. But when people in relative power say wrong things, it makes it harder for junior colleagues (or students) to establish credibility, with other colleagues and students. I *never* implied that. I suggested only that - after the statement of A. Coppin that 100% of the world ignores/despises Haskell - coroborating such a statement by a clearly inadequate example is not serious. You may be of the opinion that such colleagues and students are fools, or beyond help. I would *NEVER* say that, and I never did. On the contrary, my philosophy addressed to young was always: be *proud* that you began to learn sthing, since you *progress*. Potentially, you are more valuable that old guys who know everything they think they need... (*) If I blessed Felipe, I am terribly sorry. But I will fight with all arms against our auto-flagellation, and the victimization atmosphere! This is a road to hell. ... and we should all cultivate self-confidence. Yes, absolutely. Without exaggeration... Perhaps the Feynman's wife phrase which became the book title What Do You Care What Other People Think is not the way of selling Haskell, but - please - there is a well known personage in the Great Literature, somebody really nice, but *absolutely* bad example to follow: Eyore, the Winnie the Pooh friend... You mention MS Research supporting the Simons - well, MSR does so in part because both of them (and their colleagues at MSR Cambridge) are tireless evangelists, who are fantastically generous with their time, ideas, and code. Not only that, of course, there are plenty of tireless evangelists who got no support. I wanted to point out that there are people/institutions who dispose of non-negligeable resources, and who decided to *invest* in people who do - apparently - an ever unpopular branch of programming theory and practice. ++ (*) OK, an absolutely irrelevant anecdote. Quite a time ago, far east of Poland (now Ukraine). An old Jew enters a train in a small station at his shtetl, enter the compartment, and - shock: he sees therein two well known Rebbis, wise men, very famous in the region. Oh, my! thinks he, what a chance. Now I will learn something, since they will probably engage in an extremely profound and enlightening discussion. But hours pass, the train is slow, nothing happens... After three hours, our hero is worried. He dares to open his mouth: Excuse me, Rebbe. I apologize for interrupting your meditation, but aren't you the well know Rabbi from Pinsk? - Yes, indeed. And other gentelman..., I know you as well! You are the most well known thinkers of the region. Now, please, tell me, why do you remain silent, having such an opportunity to exchange some ideas, points of view, etc. I really hoped I would profit from your presence, it would be a godly gift for me! - Well - the Rabbi smiles. You are right, we are wise men. My neighbour is really very, very wise. He knows everything. Actually, I know many, many things myself as well. Why should we waste time on discussions? We won't learn more... = Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Proposal: register a package asprovidingseveralAPI versions
ChrisK wrote: I disagree with Simon Marlow here. In practice I think Claus' definition of compatible is good enough: I don't think you're disagreeing with me :-) In fact, you agreed that extending an API can break a client: One can write such a module. But that is only a problem if the old client accidentally can tell the difference. As far as I can see, the only two things that can go wrong are name conflicts and new instances. New names can only cause compilation to fail, and this can be fixed by using a mix of (1) adding an explicit import list to the old import statement, or (2) adding/expanding a hiding list to the old import statement, or (3) using module qualified names to remove the collision Fixing this sort of compile error is easy; nearly simple enough for a regexp script. And the fix does not break using the client with the old library. Adding things to the namespace should not always force a new API version number. Yes the errors can be fixed, but it's too late - the client already failed to compile out of the box against the specified dependencies. New instances are ruled out in the definition of an extended API in the version policy proposal, incedentally: http://haskell.org/haskellwiki/Package_versioning_policy And I agree with you that name clashes are rare, which is why that page recommends specifying dependencies that are insensitive to changes in the minor version number (i.e. API extensions). But that still leaves the possibility of breakage if the client isn't using import lists, and Claus argued for a system with no uncertainty. So if you want no uncertainty in your dependencies, you either have to (a) not depend on API versions (including minor versions) that you haven't tested, or (b) use explicit import lists and allow minor version changes only. Incedentally, this reminds me that GHC should have a warning for not using explicit import lists (perhaps only for external package imports). Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Class invariants/laws
On 10/18/07, Simon Peyton-Jones [EMAIL PROTECTED] wrote: I don't believe GHC relies on any class laws. It'd be pretty dangerous to do so, I think. Incidentally, I consider it a slight infelicity that the H98 spec doesn't seem to mention the implied laws of classes like Eq and Ord, not even to disclaim responsibility for them. Even if the standard doesn't require that the laws hold, I suggest that it should at least state this explicitly, and perhaps recommend that they be obeyed. Is this something that might change in Haskell-Prime? Stuart ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Strange subtract operator behavior - and lazy naturals
David Benbennick [EMAIL PROTECTED] writes: On 10/17/07, John Meacham [EMAIL PROTECTED] wrote: Oops, sorry, the version I posted was an intermediate one that had a different addition algorithm. here is a better one that fixes that issue: Zero + y = y Sum x n1 + y = Sum x (y + n1) note that it alternates the order in the recursive call, interleaving the elements of the two arguments. Thanks. Have you thought at all about how to make maximally lazy Naturals? For example, a data type that can answer True to both genericLength (1:undefined) + genericLength (1:2:3:4:5:6:undefined) (6 :: Nat) genericLength (1:2:3:4:5:6:undefined) + genericLength (1:undefined) (6 :: Nat) Is that a desired feature? It may be desirable, but it's not lambda definable, so you'd have to use concurrency to acheive it. -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Type-level arithmetic
On Tue, Oct 16, 2007 at 10:56:27AM +1000, Manuel M T Chakravarty wrote: Lennart Augustsson wrote, And Haskell embedded a logical programming language on accident. Well, we are just trying to fix that :) Since types are inferred using unification, and classes are still present, adding functions yields a functional logic programming language at the type level. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
Daniel McAllansmith [EMAIL PROTECTED] writes: There are other reasons for a version bump than breaking compatibility. Technical reasons? Well - say I refactor everything, and use algorithms with different run-time complexities, and possibly introduce different bugs than the ones the applications have come to rely on/work around. Even if the interface is type-level compatible, a conservative application would still prefer to link with the old version. -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] Automatic file closing after readFile
Magnus Therning:
hasEmpty s = let
_first_empty = s !! 0 == '\n'
_last_empty = (reverse s) !! 1 == '\n'
in _first_empty || _last_empty
loadAndCheck fp = liftM hasEmpty $ readFile fp
main = getArgs = filterM loadAndCheck = mapM_ putStrLn
The one problem I had was that running this on /all/ files in my WP
resulted in an exception:
*** Exception: ./wp-includes/images/smilies/icon_mrgreen.gif:
openFile: resource exhausted (Too many open files)
Is there some (easy) way to avoid this while still using readFile?
The perils of lazy IO: readFile closes its file descriptor only if it is
is forced to read to end of file. Otherwise, you rely on the garbage
collector to run the finaliser on the file handle sometime after it
becomes unreachable, but since file handle exhaustion does not trigger
garbage collection, there are no guarantees. See also the System.IO
documentation.
For an extremely hackish (and untested) solution to your problem,
replace the expression (_first_empty || _last_empty) with (_last_empty
|| _first_empty). If you can explain why that works, then you advance to
the next level in your training!
For a less hackish solution, you need to do a bit more work. Again, this
is untested.
loadAndCheck fn = bracket (openFile fn ReadMode) hClose checkContents
checkContents fh = do { s - hGetContents fh; return $! hasEmpty s }
Note the explicit close, and return $! to ensure that hasEmpty has
done its work before the file is closed.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Automatic file closing after readFile
Is there some (easy) way to avoid this while still using readFile? readFile' f = do s - readFile f return (length s `seq` s) (and curse the fact that the default readFile is unsafelazy). Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Suspected stupid Haskell Question
Hi Chad, Chad Scherrer wrote: I think the stack overflows were happening because Map.insertWith isn't strict enough. Otherwise I think the code is the same. They are visibly almost identical - except that you do an extra lookup to get your strictness, while insertWith' has internal access and can do it in the same pass. So using insertWith' should be faster. But I would expect intTable to be faster, since it uses IntMap, I'm not sure if that's strictly true. I have never done any testing, but I get the feeling that the performance of IntMap may depend on the distribution of the keys. After some not so good experiences, I abandonned IntMap and just use Map. Anyone know? Also - I don't have insertWith' for IntMap. and there's no IntMap.insertWith' as of 6.6.1 The mtl package is now independent of GHC. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Strange subtract operator behavior - and lazy naturals
I wrote: Nice, lots of fun! Wouldn't it be more convenient to allow them to be signed? John Meacham wrote: Well, a couple reasons. One is that Natural numbers are a pretty useful type in and of themselves, often times when used with lazy evaluation. The other is that it is unclear what semantics lazy signed numbers would have... True. I was thinking of the sign at the beginning - which means, essentially, the same as what you already have. The real only differences are: - Zero really means 0, not 0 or negative. - In certain special cases where you happen to know that the result should be a certain negative number, you get that In particular, the scrictness properties - which you have already so carefully worked out for the case of the naturals - do not change. Of course, you can then easily restrict to the naturals when you want that. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Automatic file closing after readFile
On Thu, Oct 18, 2007 at 12:05:40 +0100, Jules Bean wrote: Is there some (easy) way to avoid this while still using readFile? readFile' f = do s - readFile f return (length s `seq` s) (and curse the fact that the default readFile is unsafelazy). :( Doesn't work. I'm starting to suspect there is no automatic close of opened files even after they've been completely read. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus．therning＠gmail．com http://therning.org/magnus pgpB34xnOe4q7.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Automatic file closing after readFile
On Thu, Oct 18, 2007 at 20:58:45 +1000, Matthew Brecknell wrote:
Magnus Therning:
hasEmpty s = let
_first_empty = s !! 0 == '\n'
_last_empty = (reverse s) !! 1 == '\n'
in _first_empty || _last_empty
loadAndCheck fp = liftM hasEmpty $ readFile fp
main = getArgs = filterM loadAndCheck = mapM_ putStrLn
The one problem I had was that running this on /all/ files in my WP
resulted in an exception:
*** Exception: ./wp-includes/images/smilies/icon_mrgreen.gif:
openFile: resource exhausted (Too many open files)
Is there some (easy) way to avoid this while still using readFile?
The perils of lazy IO: readFile closes its file descriptor only if it
is is forced to read to end of file. Otherwise, you rely on the garbage
collector to run the finaliser on the file handle sometime after it
becomes unreachable, but since file handle exhaustion does not trigger
garbage collection, there are no guarantees. See also the System.IO
documentation.
For an extremely hackish (and untested) solution to your problem,
replace the expression (_first_empty || _last_empty) with (_last_empty
|| _first_empty). If you can explain why that works, then you advance
to the next level in your training!
I can see how that could have worked. Lazy thinking indeed :-) I
wonder if the fact that it doesn't work should be considered a bug?
Just to make sure I changed (broke) my code so that the very last
character would be read (in case there is an almost crazy level of
optimisation in ghc):
_last_empty = (reverse s) !! 0 == '\n'
Still no cigar :(
For a less hackish solution, you need to do a bit more work. Again, this
is untested.
loadAndCheck fn = bracket (openFile fn ReadMode) hClose checkContents
checkContents fh = do { s - hGetContents fh; return $! hasEmpty s }
Note the explicit close, and return $! to ensure that hasEmpty has
done its work before the file is closed.
Ah, `bracket` is a handy function to know!
And it does work!
/M
--
Magnus Therning (OpenPGP: 0xAB4DFBA4)
magnus＠therning．org Jabber: magnus．therning＠gmail．com
http://therning.org/magnus
pgpAG1ZpHktr7.pgp
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Automatic file closing after readFile
Magnus Therning:
Still no cigar :(
Yes, this is a little more subtle than I first thought. Look at liftM
and filterM:
liftM f m1 = do { x1 - m1; return (f x1) }
filterM :: (Monad m) = (a - m Bool) - [a] - m [a]
filterM _ [] = return []
filterM p (x:xs) = do
flg - p x
ys - filterM p xs
return (if flg then x:ys else ys)
In liftM, the result of (f x1) is not forced, and in filterM, flg is not
tested until after xs is traversed. The result is that when filterM runs
the (p x) action, a file is opened, but hasEmpty (and thus readFile) is
not forced until all other files have likewise been opened.
It should suffice to use a more strict version of liftM:
liftM' f m1 = do { x1 - m1; return $! f x1 }
That should also fix the problem with Jules' solution, or alternatively:
readFile' f = do s - readFile f
return $! (length s `seq` s)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Automatic file closing after readFile
Magnus Therning wrote: On Thu, Oct 18, 2007 at 12:05:40 +0100, Jules Bean wrote: Is there some (easy) way to avoid this while still using readFile? readFile' f = do s - readFile f return (length s `seq` s) (and curse the fact that the default readFile is unsafelazy). :( Doesn't work. I'm starting to suspect there is no automatic close of opened files even after they've been completely read. That's odd. Sounds like a bug? (in readFile, I mean) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Automatic file closing after readFile
On Thu, Oct 18, 2007 at 01:16:37PM +0100, Magnus Therning wrote:
On Thu, Oct 18, 2007 at 20:58:45 +1000, Matthew Brecknell wrote:
For a less hackish solution, you need to do a bit more work. Again, this
is untested.
loadAndCheck fn = bracket (openFile fn ReadMode) hClose checkContents
checkContents fh = do { s - hGetContents fh; return $! hasEmpty s }
Note the explicit close, and return $! to ensure that hasEmpty has
done its work before the file is closed.
Ah, `bracket` is a handy function to know!
Note that you almost never want to use the bracket defined in Haskell98,
nor the one in IO.Error. You want the bracket defined in
Control.Exception.
--
David Roundy
Department of Physics
Oregon State University
signature.asc
Description: Digital signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Automatic file closing after readFile
On Thu, Oct 18, 2007 at 09:25:32 -0400, David Roundy wrote:
On Thu, Oct 18, 2007 at 01:16:37PM +0100, Magnus Therning wrote:
On Thu, Oct 18, 2007 at 20:58:45 +1000, Matthew Brecknell wrote:
For a less hackish solution, you need to do a bit more work. Again, this
is untested.
loadAndCheck fn = bracket (openFile fn ReadMode) hClose checkContents
checkContents fh = do { s - hGetContents fh; return $! hasEmpty s }
Note the explicit close, and return $! to ensure that hasEmpty has
done its work before the file is closed.
Ah, `bracket` is a handy function to know!
Note that you almost never want to use the bracket defined in Haskell98,
nor the one in IO.Error. You want the bracket defined in
Control.Exception.
Yes, thankfully that's documented in the Haddock for the only one that
turns up on Hoogle.
/M
--
Magnus Therning (OpenPGP: 0xAB4DFBA4)
magnus＠therning．org Jabber: magnus．therning＠gmail．com
http://therning.org/magnus
pgpS5kB9LvJaR.pgp
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Automatic file closing after readFile
On Thu, Oct 18, 2007 at 22:58:48 +1000, Matthew Brecknell wrote:
Magnus Therning:
Still no cigar :(
Yes, this is a little more subtle than I first thought. Look at liftM
and filterM:
liftM f m1 = do { x1 - m1; return (f x1) }
filterM :: (Monad m) = (a - m Bool) - [a] - m [a]
filterM _ [] = return []
filterM p (x:xs) = do
flg - p x
ys - filterM p xs
return (if flg then x:ys else ys)
In liftM, the result of (f x1) is not forced, and in filterM, flg is
not tested until after xs is traversed. The result is that when filterM
runs the (p x) action, a file is opened, but hasEmpty (and thus
readFile) is not forced until all other files have likewise been
opened.
It should suffice to use a more strict version of liftM:
liftM' f m1 = do { x1 - m1; return $! f x1 }
That did indeed fix it.
Just out of curiosity, how would I go about finding this myself?
(Ideally it'd be an answer other than read the source for the libraries
you are using. :-)
/M
--
Magnus Therning (OpenPGP: 0xAB4DFBA4)
magnus＠therning．org Jabber: magnus．therning＠gmail．com
http://therning.org/magnus
pgpJO22GUwQ7M.pgp
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Announce: generating free theorems, online and offline
On Thu, Oct 18, 2007 at 03:36:01AM -0400, [EMAIL PROTECTED] wrote: (As an aside: The H98 report still list the right-zero law as being a law for MonadPlus, even though most MonadPlus instances don't obey it. That's actually a defect in the report.) All the MonadPlus I can think of (IO,Maybe,[]) satisfy it. Were you thinking of right distribution? Stefan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Proposal: register a package as providing several API versions
On Oct 18, 2007, at 4:57 , Simon Marlow wrote: depend on API versions (including minor versions) that you haven't tested, or (b) use explicit import lists and allow minor version changes only. Incedentally, this reminds me that GHC should have a warning for not using explicit import lists (perhaps only for external package imports). Which reminds me that it would be nice to be able to ask for a list of what imports I need to specify (i.e. what names from the module are actually used). A case in point would be the example of non- monadic I/O I sent to the list the other day: I wanted to specify minimal imports, but couldn't think of a way to do it aside from specifying very small import lists and iteratively adding things as the compile failed. (This may actually already exist and I don't know enough ghc options to do it) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Do you trust Wikipedia?
On Thu, 18 Oct 2007, PR Stanley wrote: Hi Do you trust mathematical materials on Wikipedia? Paul To a first approximation - trust but verify. -- [EMAIL PROTECTED] I think you mean Philippa. I believe Phillipa is the one from an alternate universe, who has a beard and programs in BASIC, using only gotos for control flow. -- Anton van Straaten on Lambda the Ultimate ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Do you trust Wikipedia?
The trustworthy articles on Wikipedia have references that can be checked, and read. The ones without references are not to be trusted.. Dave Barton - Original Message - From: Philippa Cowderoy [EMAIL PROTECTED] To: PR Stanley [EMAIL PROTECTED] Cc: haskell-cafe@haskell.org Sent: Thursday, October 18, 2007 10:28 AM Subject: Re: [Haskell-cafe] Do you trust Wikipedia? On Thu, 18 Oct 2007, PR Stanley wrote: Hi Do you trust mathematical materials on Wikipedia? Paul To a first approximation - trust but verify. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up!
On Thu, 18 Oct 2007, [EMAIL PROTECTED] wrote: Felipe Lessa writes: On 10/17/07, Andrew Coppin [EMAIL PROTECTED] wrote: ... And it frustrates the hell out of me that 100% of the human population consider Haskell to be an irrelevant joke language. ... I feel this way as well, specially because one of the teachers here tell all students that Haskell is the slowest thing ever by comparing Fibonacci sequence implementations between C and Haskell *using Hugs*. We shall thus understand that a teacher who likes Fibonacci, is a representant of of the 100% of the human population. Uh, Jerzy? You might want to consider this a variant of the idiomatic nobody cares, which also isn't quite meant literally. -- [EMAIL PROTECTED] A problem that's all in your head is still a problem. Brain damage is but one form of mind damage. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
