Re: [GHC] #2362: allow full import syntax in GHCi
#2362: allow full import syntax in GHCi -+-- Reporter: Isaac Dupree |Owner: Type: feature request | Status: new Priority: high |Milestone: 6.12.1 Component: Compiler | Version: 6.8.2 Severity: normal| Resolution: Keywords: ghci, import | Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Comment (by simonmar): related: #3217 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2362#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2442: Heuristics to improve error messages for badly referenced things
#2442: Heuristics to improve error messages for badly referenced things -+-- Reporter: batterseapower|Owner: simonpj Type: feature request | Status: new Priority: high |Milestone: 6.12.1 Component: Compiler | Version: 6.9 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by simonmar): * owner: = simonpj -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2442#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2798: Enable rec keyword when RecursiveDo is enabled?
#2798: Enable rec keyword when RecursiveDo is enabled? -+-- Reporter: nominolo |Owner: Type: task | Status: new Priority: high |Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: minor | Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Comment (by simonmar): We (Simon Simon) think the ideal state of affairs would be: * Allow `rec` in `do` (as Ross intended) * Deprecate `mdo` as far as flags go, there are two options: * have the existing `RecursiveDo` flag enable the new `rec` syntax, and deprecate the use of `mdo`. Eventually `mdo` would be removed as a keyword. * Define a new extension, e.g. `DoRec` for the new `rec` keyword, and deprecate the old `RecursiveDo` extension. The second approach has the benefit that we can identify obsolete code on Hackage without trying to compile it, but it means having two similarly- named extensions which could lead to confusion. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2798#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1876: Complete shared library support
#1876: Complete shared library support -+-- Reporter: simonmar |Owner: duncan Type: task | Status: new Priority: high |Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: normal| Resolution: Keywords:| Difficulty: Difficult (1 week) Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by simonmar): * owner: = duncan -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1876#comment:28 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] #1924: Rewrite the handling of values we get from ./configure
#1924: Rewrite the handling of values we get from ./configure -+-- Reporter: igloo |Owner: igloo Type: bug | Status: new Priority: high |Milestone: 6.12.1 Component: Build System | Version: 6.8.1 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by simonmar): * owner: = igloo -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1924#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2189: hSetBuffering stdin NoBuffering doesn't work on Windows
#2189: hSetBuffering stdin NoBuffering doesn't work on Windows ---+ Reporter: FalconNL|Owner: Type: bug | Status: new Priority: normal |Milestone: 6.12.1 Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: hsetbuffering buffering buffer | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | ---+ Changes (by simonmar): * priority: high = normal -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2189#comment:26 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] #2451: New signal-handling API
#2451: New signal-handling API -+-- Reporter: simonmar |Owner: simonmar Type: proposal | Status: new Priority: high |Milestone: 6.12.1 Component: libraries/unix| Version: 6.8.3 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by simonmar): * owner: = simonmar -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2451#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2578: ld: atom sorting error for ... on OS X
#2578: ld: atom sorting error for ... on OS X -+-- Reporter: igloo |Owner: igloo Type: bug | Status: new Priority: high |Milestone: 6.12.1 Component: Compiler | Version: 6.9 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: MacOS X Architecture: Unknown/Multiple | -+-- Changes (by simonmar): * owner: = igloo -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2578#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2793: CLDouble is nothing like a long double
#2793: CLDouble is nothing like a long double -+-- Reporter: jedbrown |Owner: igloo Type: bug | Status: new Priority: high |Milestone: 6.12.1 Component: libraries/base| Version: 6.11 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by simonmar): * owner: = igloo Comment: Let's just remove it. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2793#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] #2925: Linker mmap failure on FreeBSD/x86_64
#2925: Linker mmap failure on FreeBSD/x86_64 ---+ Reporter: simonmar|Owner: simonmar Type: bug | Status: new Priority: high|Milestone: 6.12.1 Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: FreeBSD Architecture: x86_64 (amd64) | ---+ Changes (by simonmar): * owner: = simonmar -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2925#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] #2978: Add support for more characters to UnicodeSyntax
#2978: Add support for more characters to UnicodeSyntax -+-- Reporter: porges|Owner: simonmar Type: feature request | Status: new Priority: high |Milestone: 6.12.1 Component: Compiler | Version: 6.10.1 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by simonmar): * owner: = simonmar -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2978#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] #1346: bootstrap from HC files
#1346: bootstrap from HC files -+-- Reporter: simonmar |Owner: igloo Type: bug | Status: new Priority: high |Milestone: 6.12.1 Component: Build System | Version: 6.6.1 Severity: normal| Resolution: Keywords:| Difficulty: Moderate (1 day) Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by simonmar): * owner: = igloo -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1346#comment:20 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3132: x86 code generator generates bad FPU register names
#3132: x86 code generator generates bad FPU register names ---+ Reporter: int-e |Owner: benl Type: bug | Status: new Priority: high|Milestone: 6.12.1 Component: Compiler (NCG) | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86 | ---+ Changes (by simonmar): * owner: = benl * cc: benl (added) Comment: Ben, would you care to look at this one? (if not, please just unassign yourself) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3132#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] #1346: bootstrap from HC files
#1346: bootstrap from HC files -+-- Reporter: simonmar |Owner: igloo Type: bug | Status: closed Priority: high |Milestone: 6.12.1 Component: Build System | Version: 6.6.1 Severity: normal| Resolution: fixed Keywords:| Difficulty: Moderate (1 day) Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by igloo): * status: new = closed * resolution: = fixed Comment: Porting to a new platform is now working again: http://hackage.haskell.org/trac/ghc/wiki/Building/Porting Doing a non-bootstrapping build from HC files isn't something that we plan to support, especially given that the registerised via-C way will be disappearing. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1346#comment:21 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2798: Enable rec keyword when RecursiveDo is enabled?
#2798: Enable rec keyword when RecursiveDo is enabled? -+-- Reporter: nominolo |Owner: Type: task | Status: new Priority: high |Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: minor | Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Comment (by duncan): I don't think I'd bother with changing the extension name. We can discover deprecated stuff on hackage automatically by other (more general) means. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2798#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3253: validate failure (GCC warning)
#3253: validate failure (GCC warning) --+- Reporter: isaacdupree|Owner: simonmar Type: bug| Status: reopened Priority: high |Milestone: 6.12.1 Component: libraries/process | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86| --+- Changes (by simonmar): * priority: normal = high -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3253#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] #3265: Type operators can be defined without the TypeOperators extension flag
#3265: Type operators can be defined without the TypeOperators extension flag -+-- Reporter: nibro |Owner: simonpj Type: bug | Status: new Priority: normal|Milestone: Component: Compiler | Version: 6.10.2 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by simonpj): * owner: = simonpj * difficulty: = Unknown -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3265#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] #3138: Returning a known constructor: GHC generates terrible code for cmonad
#3138: Returning a known constructor: GHC generates terrible code for cmonad
-+--
Reporter: simonpj |Owner:
Type: run-time performance bug | Status: new
Priority: normal|Milestone: 6.12 branch
Component: Compiler | Version: 6.10.1
Severity: normal| Resolution:
Keywords:| Difficulty: Unknown
Testcase:| Os: Unknown/Multiple
Architecture: Unknown/Multiple |
-+--
Comment (by augustss):
I expect the code to be the same as the code for
{{{
main = do
rs - newIORef 0
ri - newIORef 0
writeIORef ri 1
let loop = do
i - readIORef ri
if i 1e3 then do
s - readIORef s
writeIORef rs (s + 1/i)
writeIORef ri (i+1)
loop
else
return ()
loop
s - readIORef rs
putStrLn $ Almost infinity is ++ show s
}}}
Because that's what the code does. Getting that far would require
specializing the recursive while function (why doesn't ghc specialize
recursive functions?).
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3138#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] #3138: Returning a known constructor: GHC generates terrible code for cmonad
#3138: Returning a known constructor: GHC generates terrible code for cmonad
-+--
Reporter: simonpj |Owner:
Type: run-time performance bug | Status: new
Priority: normal|Milestone: 6.12 branch
Component: Compiler | Version: 6.10.1
Severity: normal| Resolution:
Keywords:| Difficulty: Unknown
Testcase:| Os: Unknown/Multiple
Architecture: Unknown/Multiple |
-+--
Comment (by augustss):
A first thing to look at is the fact that there's still dictionaries in
the code.
There's no unresolved overloading in Inf.hs, so all dictionaries should be
gone.
To avoid the disturbing recursive while function, try this code instead:
{{{
inf = runE $ do
s - auto 0
i - auto 0
i =: 1
if1 ((i :: E m Double) = 1e3) $ do
s += 1/i
i += 1
retrn s
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3138#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] #3256: Extra EOT from NoBuffering mode in emacs
#3256: Extra EOT from NoBuffering mode in emacs
-+--
Reporter: judah |Owner:
Type: bug | Status: closed
Priority: normal|Milestone: 6.10.4
Component: Compiler | Version: 6.10.3
Severity: normal| Resolution: invalid
Keywords:| Difficulty: Unknown
Testcase:| Os: Linux
Architecture: Unknown/Multiple |
-+--
Changes (by simonmar):
* status: new = closed
* resolution: = invalid
Comment:
As far as I can tell, this is not a bug in GHC. The same behaviour can be
replicated with a C program:
{{{
#include termios.h
#include unistd.h
#include stdlib.h
main()
{
char buf[1024];
struct termios termios;
int r;
tcgetattr(0,termios);
termios.c_lflag = ~ECHO;
termios.c_lflag = ~ICANON;
termios.c_cc[VMIN] = 1;
termios.c_cc[VTIME] = 0;
tcsetattr(0,TCSANOW,termios);
do {
r = read(0, buf, 1024);
write(1, buf, r);
} while (r != 0);
exit(0);
}
}}}
If you paste a line of 255 x's to the C program in emacs, you'll see a
`^D` character inserted in the output, in exactly the same way as with the
Haskell program. This appears to be something that emacs is doing when
stdin has ICANON unset.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3256#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] #2793: CLDouble is nothing like a long double
#2793: CLDouble is nothing like a long double -+-- Reporter: jedbrown |Owner: igloo Type: bug | Status: new Priority: high |Milestone: 6.12.1 Component: libraries/base| Version: 6.11 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Comment (by jedbrown): I personally don't have a problem with that, but some people care a lot about quad precision, mostly for very ill-conditioned problems or in order to get away with a numerically unstable method. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2793#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] #3247: GHCI segfaults when per-thread stack size is larger than max stack size
#3247: GHCI segfaults when per-thread stack size is larger than max stack size ---+ Reporter: earthy |Owner: simonmar Type: bug | Status: new Priority: normal |Milestone: 6.12.1 Component: Runtime System | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Os: MacOS X Architecture: x86 | ---+ Comment (by simonmar): dup of #3156 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3247#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] #3247: GHCI segfaults when per-thread stack size is larger than max stack size
#3247: GHCI segfaults when per-thread stack size is larger than max stack size ---+ Reporter: earthy |Owner: simonmar Type: bug | Status: closed Priority: normal |Milestone: 6.12.1 Component: Runtime System | Version: 6.10.2 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Easy (1 hr) Testcase: | Os: MacOS X Architecture: x86 | ---+ Changes (by simonmar): * status: new = closed * resolution: = duplicate -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3247#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
[GHC] #3268: implement the Cabal ${pkgroot} spec extension
#3268: implement the Cabal ${pkgroot} spec extension
-+--
Reporter: duncan| Owner:
Type: feature request | Status: new
Priority: normal| Component: Package system
Version: 6.10.2| Severity: normal
Keywords:| Testcase:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
-+--
See the proposal for relative paths in installed package descriptions:
http://www.haskell.org/pipermail/libraries/2009-May/011772.html
Basically it amounts to replacing ghc's current `$topdir` and
`$httptopdir` with variables that are interpreted relative to the package
db file itself rather than relative to where ghc is installed (though for
the global package db these coincide).
The open question is how tools discover the location of the package dbs.
The proposed spec extension does not specify this, but perhaps it should
specify an extension to (the hypothetical) `hc-pkg` system to discover the
default set of package dbs and their paths.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3268
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] #3269: Stop using PackedString in template-haskell; drop packedstring as a bootlib
#3269: Stop using PackedString in template-haskell; drop packedstring as a bootlib ---+ Reporter: simonmar | Owner: Type: proposal | Status: new Priority: normal| Milestone: Not GHC Component: None |Version: 6.10.2 Severity: normal| Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ---+ The `packedstring` library has been superseded by the `bytestring` and `text` libraries, yet we are still shipping it with GHC for only one reason: it is used in the representations of three types in `template- haskell`. The proposal is that we * make the types `ModName`, `PkgName`, and `OccName` from `Language.Haskell.TH.Syntax` into abstract newtypes (an API change) * change their representation from `PackedString` to `String` * drop the `packedstring` library from the bootlibs that GHC ships with Relevant discussions: * [http://www.haskell.org/pipermail/libraries/2008-November/010960.html] -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3269 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] #3270: Stop using PackedString in template-haskell; drop packedstring as a bootlib
#3270: Stop using PackedString in template-haskell; drop packedstring as a bootlib ---+ Reporter: simonmar | Owner: Type: proposal | Status: new Priority: normal| Milestone: Not GHC Component: None |Version: 6.10.2 Severity: normal| Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ---+ The `packedstring` library has been superseded by the `bytestring` and `text` libraries, yet we are still shipping it with GHC for only one reason: it is used in the representations of three types in `template- haskell`. The proposal is that we * make the types `ModName`, `PkgName`, and `OccName` from `Language.Haskell.TH.Syntax` into abstract newtypes (an API change) * change their representation from `PackedString` to `String` * drop the `packedstring` library from the bootlibs that GHC ships with Relevant discussions: * [http://www.haskell.org/pipermail/libraries/2008-November/010960.html] -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3270 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] #3269: Stop using PackedString in template-haskell; drop packedstring as a bootlib
#3269: Stop using PackedString in template-haskell; drop packedstring as a bootlib -+-- Reporter: simonmar |Owner: Type: proposal | Status: closed Priority: normal|Milestone: Not GHC Component: None | Version: 6.10.2 Severity: normal| Resolution: duplicate Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by simonmar): * status: new = closed * resolution: = duplicate -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3269#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] #2798: Enable rec keyword when RecursiveDo is enabled?
#2798: Enable rec keyword when RecursiveDo is enabled? -+-- Reporter: nominolo |Owner: Type: task | Status: new Priority: high |Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: minor | Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Comment (by isaacdupree): my feeling is to prefer `DoRec` -- it sounds more mnemonic to me; and it seems unpleasant for an extension to have two substantially different parsings that might conflict with existing code (if 'rec' is a variable name somewhere). e.g. how will haskell-src[-exts] deal with it after the Summer-of-Code effort? But I don't really mind either way. (P.S. do we have a way to mark extension-flags deprecated?) -Isaac -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2798#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2798: Enable rec keyword when RecursiveDo is enabled?
#2798: Enable rec keyword when RecursiveDo is enabled? -+-- Reporter: nominolo |Owner: Type: task | Status: new Priority: high |Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: minor | Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Comment (by isaacdupree): so if you want your code to compile on pre-6.12 you can: - just use `mdo` - use `rec` and enable `Arrows` also (I guess this hack could be, but shouldn't be, sanctioned by Cabal.. among other things, Arrows also introduces `proc` as a keyword, so it's not harmless) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2798#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3270: Stop using PackedString in template-haskell; drop packedstring as a bootlib
#3270: Stop using PackedString in template-haskell; drop packedstring as a bootlib -+-- Reporter: simonmar |Owner: Type: proposal | Status: new Priority: normal|Milestone: Not GHC Component: None | Version: 6.10.2 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by guest): * cc: gwe...@gmail.com (added) Comment: This change has my support. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3270#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: [HOpenGL] renderString not working in ghci
[ Reprise of an old GHCi problem, GHC HQ read on please... ] Am Mittwoch, 20. Mai 2009 09:24:14 schrieb Matthijs Kooijman: I've been playing around with GLUT (latest version from hackage, on Debian) a bit yesterday and am having some troubles with renderString. It works fine when I compile a binary using ghc, but when running from ghci I get an error similar to the following (I don't have the actual error at hand atm). freeglut(interactive): font 0xsomething not found From looking at the freeglut code, it seems this means that the font pointer passed in does not match the address of any of the font variables in the library. I'm not completely sure how the linking works in ghci, but it appears that something goes wrong with dynamic linking? Is this a known problem, or does anyone have any pointers where to debug this? After thinking about this for a while, I got a déjà vu feeling and browsed through old mails, and there it was, the thread about the arcane, dark corners of dynamic linking and position independent code, where (almost) no man has gone before: ;-) http://www.haskell.org/pipermail/cvs-ghc/2007-September/038458.html I think that we finally came to the conclusion that we *have* to compile code with -fPIC on some platforms, including x86_64, but looking at the verbose output of the build step of the GLUT package on x86_64, one can see that there is nothing PIC-related at all. Adding --ghc-option=-fPIC to Cabal's build step for the GLUT package makes ARBOcclude.hs (and renderString in general) work again. So my questing is: Is this a bug in GHC, i.e. should it always use -fPIC implicitly? Or is this a bug in my GLUT package's .cabal file? I have a tendency to believe the former possibility... Or asked the other way round: Is there a reason why -fPIC is not the default for GHC? Cheers, S. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [HOpenGL] renderString not working in ghci
On Mon, 2009-06-01 at 20:05 +0200, Sven Panne wrote: [ Reprise of an old GHCi problem, GHC HQ read on please... ] Am Mittwoch, 20. Mai 2009 09:24:14 schrieb Matthijs Kooijman: I've been playing around with GLUT (latest version from hackage, on Debian) a bit yesterday and am having some troubles with renderString. It works fine when I compile a binary using ghc, but when running from ghci I get an error similar to the following (I don't have the actual error at hand atm). freeglut(interactive): font 0xsomething not found From looking at the freeglut code, it seems this means that the font pointer passed in does not match the address of any of the font variables in the library. I'm not completely sure how the linking works in ghci, but it appears that something goes wrong with dynamic linking? Is this a known problem, or does anyone have any pointers where to debug this? After thinking about this for a while, I got a déjà vu feeling and browsed through old mails, and there it was, the thread about the arcane, dark corners of dynamic linking and position independent code, where (almost) no man has gone before: ;-) http://www.haskell.org/pipermail/cvs-ghc/2007-September/038458.html I don't know how the problem reported in that message is related to the renderString problem (which I do not understand), but the behaviour you see there is not terribly surprising. It's an artefact of the way dynamic linking works and should not generally cause any problems. The only case where it should make a difference is if code is assigning any meaning to the address of functions, eg to compare them for identity. In that case going via a thunk will make a difference. Is that what freeglut is doing do you think? I think that we finally came to the conclusion that we *have* to compile code with -fPIC on some platforms, including x86_64, but looking at the verbose output of the build step of the GLUT package on x86_64, one can see that there is nothing PIC-related at all. Adding --ghc-option=-fPIC to Cabal's build step for the GLUT package makes ARBOcclude.hs (and renderString in general) work again. So my questing is: Is this a bug in GHC, i.e. should it always use -fPIC implicitly? I rather suspect it's freeglut doing something dubious with comparing function pointers. Or is this a bug in my GLUT package's .cabal file? I have a tendency to believe the former possibility... Or asked the other way round: Is there a reason why -fPIC is not the default for GHC? On most platforms -fPIC imposes some overhead and so it is only used when it's advantageous or necessary. On most platforms code that will live in a shared library should or must be compiled with -fPIC. x86-64 is one of the few architectures where the overhead is relatively low. Duncan ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #698: GHC's internal memory allocator never releases memory back to the OS
#698: GHC's internal memory allocator never releases memory back to the OS -+-- Reporter: guest |Owner: igloo Type: bug | Status: new Priority: low |Milestone: 6.12 branch Component: Runtime System| Version: 6.4.1 Severity: normal| Resolution: Keywords:| Difficulty: Moderate (1 day) Testcase: N/A | Os: Linux Architecture: Unknown/Multiple | -+-- Changes (by asklinge): * cc: asklingenb...@gmail.com (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/698#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [HOpenGL] renderString not working in ghci
Am Montag, 1. Juni 2009 22:48:56 schrieb Duncan Coutts:
I don't know how the problem reported in that message is related to the
renderString problem (which I do not understand), but the behaviour you
see there is not terribly surprising. It's an artefact of the way
dynamic linking works and should not generally cause any problems.
The word generally is a problem in itself. ;-) The main point is that GHCi'l
dynamic linker behaves differently from the system's dynamic linker, so this
is a very good reason to consider this a bug. It might not surface very often,
but it is nevertheless a different behaviour a.k.a. bug.
The only case where it should make a difference is if code is assigning
any meaning to the address of functions, eg to compare them for
identity. In that case going via a thunk will make a difference. Is that
what freeglut is doing do you think?
It is not about the address of functions, it is about data addresses. Here is
the relevant snippet from GLUT's/freeglut's header file for non-Windows
platforms:
--
/*
* I don't really know if it's a good idea... But here it goes:
*/
extern void* glutStrokeRoman;
extern void* glutStrokeMonoRoman;
extern void* glutBitmap9By15;
...
/*
* Those pointers will be used by following definitions:
*/
# define GLUT_STROKE_ROMAN ((void *) glutStrokeRoman)
# define GLUT_STROKE_MONO_ROMAN ((void *) glutStrokeMonoRoman)
# define GLUT_BITMAP_9_BY_15 ((void *) glutBitmap9By15)
...
--
As you can see, GLUT's fonts are represented by the addresses of global
variables. This might not be the nicest way to do this, but it has to be done
for binary compatibility reasons and there is *nothing* dubious about this.
Note that e.g. we are very lucky that errno is a macro for a function call
on all platforms for which -fPIC is relevant, otherwise we would have the same
problem with it, too.
The GLUT Haskell package uses a simple C wrapper around these macros:
--
void*
hs_GLUT_marshalBitmapFont(int fontID)
{
switch (fontID) {
case 0 : return GLUT_BITMAP_8_BY_13;
case 1 : return GLUT_BITMAP_9_BY_15;
case 2 : return GLUT_BITMAP_TIMES_ROMAN_10;
case 3 : return GLUT_BITMAP_TIMES_ROMAN_24;
case 4 : return GLUT_BITMAP_HELVETICA_10;
case 5 : return GLUT_BITMAP_HELVETICA_12;
case 6 : return GLUT_BITMAP_HELVETICA_18;
}
return (void*)0;
}
--
For reasons explained in great length in the mail thread quoted, GHCi's linker
doesn't link the wrapper correctly on some platforms when -fPIC is not used
for its compilation.
I rather suspect it's freeglut doing something dubious with comparing
function pointers.
The only one doing dubious things is GHCi's dynamic linker... ;-)
On most platforms -fPIC imposes some overhead and so it is only used
when it's advantageous or necessary. On most platforms code that will
live in a shared library should or must be compiled with -fPIC. x86-64
is one of the few architectures where the overhead is relatively low.
So my question is again: Why is -fPIC not the default for GHC on x86_64? If we
don't want the overhead, that's OK (any benchmark numbers?), but then GHC's
documentation should really contain a big, fat warning that GHCi's dynamic
linker gets cases like the one above wrong.
Cheers,
S.
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3132: x86 code generator generates bad FPU register names
#3132: x86 code generator generates bad FPU register names
---+
Reporter: int-e |Owner: nobody
Type: bug | Status: new
Priority: high|Milestone: 6.12.1
Component: Compiler (NCG) | Version: 6.11
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Os: Unknown/Multiple
Architecture: x86 |
---+
Changes (by benl):
* owner: benl = nobody
Comment:
The cmm code for the failing program contains the following:
{{{
if (_c1Wu::I32 = 1) goto c1Wx;
_s1Ba::F64 = r1tw_closure;
_s1Nk::F64 = %MO_F_Sub_W64(D1, _s1Ba::F64);
_s1Nl::F64 = %MO_F_Mul_W64(F64[Sp + 12], _s1Nk::F64);
}}}
Note that r1tw_closure is not a F64.
Here is a test-case that fails -dcmm-lint as well as -dstg-lint when
compiled with -O2.
{{{
module Spring where
import Data.Array.Unboxed
type Arr= UArray Int Double
step :: Double - Int - Arr - Arr
step h sz y = listArray (0, 0) []
}}}
{{{
ghc-stage1: panic! (the 'impossible' happened)
(GHC version 6.11.20090514 for i386-unknown-linux):
*** Stg Lint ErrMsgs: in Stg2Stg ***
no location info:
[in body of lambda with binders s{v sGe} [lid]
:: ghc-prim:GHC.Prim.State#{(w) tc 32q}
s{tv awN} [tv]]
In a function application, function type doesn't match arg types:
Function type:
forall s{tv axt} [tv] i{tv axu} [tv].
(base:GHC.Arr.Ix{tc 2i} i{tv axu} [tv]) =
(i{tv axu} [tv], i{tv axu} [tv])
- base:GHC.ST.ST{tc r65}
s{tv axt} [tv]
(array-0.2.0.1:Data.Array.Base.STUArray{tc r6}
s{tv axt} [tv] i{tv axu} [tv]
ghc-prim:GHC.Types.Double{(w) tc 3u})
Arg types:
predbase:GHC.Arr.Ix{tc 2i} ghc-prim:GHC.Types.Int{(w) tc 3J}
(ghc-prim:GHC.Types.Int{(w) tc 3J},
ghc-prim:GHC.Types.Int{(w) tc 3J})
ghc-prim:GHC.Prim.State#{(w) tc 32q} s{tv awN} [tv]
Expression:
array-0.2.0.1:Data.Array.Base.newArray_8{v ra} [gid]
base:GHC.Arr.$f14{v r9} [gid]
main:Spring.lvl1{v r8} [gid]
s{v sGe} [lid]
}}}
I'm not sure how to read the STG code, but it looks like something in the
libs has been messed up, which has then been inlined.
Perhaps validate should be compiling with all the lint options turned on?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3132#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 - force library search order
On 29/05/2009 15:19, John Lask wrote: - Original Message - From: Duncan Coutts duncan.cou...@worc.ox.ac.uk To: John Lask jvl...@hotmail.com Sent: Friday, May 29, 2009 8:09 PM Subject: Re: [Haskell-cafe] ghc - force library search order On Fri, 2009-05-29 at 18:08 +1000, John Lask wrote: I need to force a library to be searched for unresolved symbols after all other libraries have been searched, and I would rather not resort to constructing the linker command line directly. Is there a way to do this? i.e. I want for example -lfoo to appear after all other haskell libraries and before system libraries (for example -lmsvcrt) once ghc has constructed the link command. i.e. how is it possible to coerce ghc into respecting dependencies between the libraries. GHC does a good job in general with native libraries, but there are allways corner cases. I have a feeling this is not possible, but it dosn't hurt to ask. No, there's currently no way to inject flags that come *after* the linker flags for the packages on the linker command line. It might help if you describe at a higher level what it is you're trying to do. There might be a better way to achieve it. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc - force library search order
I hav a module that depends upon (binds to) the microsoft uuid.lib (libuuid.a) this is a static library which exports some labels such as IID_IPersistFile. I was playing around with trying to get it to work both with normal compiling via ghc and to dynamically load in ghci. As we know, ghci can't load static libraries and so was not able to resolve the linkage. I therefore decided to directly incorporate the objects of (libuuid.a) into the haskell .a and ghci .o file (ghci) . To do this I needed to ject --whole-archive libuuid.a --no-whole-archive (or alternatively the list of objects) into the link command at an appropriate point to enable the resolution of the linkage. I have achieved my goal but only by constructing the list of objects to link entirely manually, constructing both the .a and .o for the haskell library manually. I am not satisfied with this solution as it is fragile wrt changes in the module structure of the library I have constructed. jvl - Original Message - From: Simon Marlow marlo...@gmail.com To: John Lask jvl...@hotmail.com Cc: glasgow-haskell-users@haskell.org Sent: Monday, June 01, 2009 9:15 PM Subject: Re: ghc - force library search order On 29/05/2009 15:19, John Lask wrote: - Original Message - From: Duncan Coutts duncan.cou...@worc.ox.ac.uk To: John Lask jvl...@hotmail.com Sent: Friday, May 29, 2009 8:09 PM Subject: Re: [Haskell-cafe] ghc - force library search order On Fri, 2009-05-29 at 18:08 +1000, John Lask wrote: I need to force a library to be searched for unresolved symbols after all other libraries have been searched, and I would rather not resort to constructing the linker command line directly. Is there a way to do this? i.e. I want for example -lfoo to appear after all other haskell libraries and before system libraries (for example -lmsvcrt) once ghc has constructed the link command. i.e. how is it possible to coerce ghc into respecting dependencies between the libraries. GHC does a good job in general with native libraries, but there are allways corner cases. I have a feeling this is not possible, but it dosn't hurt to ask. No, there's currently no way to inject flags that come *after* the linker flags for the packages on the linker command line. It might help if you describe at a higher level what it is you're trying to do. There might be a better way to achieve it. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] The speed, size and dependability of programming languages
Hello haskell, Interesting blog post comparing speed and expressiveness of many languages: http://gmarceau.qc.ca/blog/2009/05/speed-size-and-dependability-of.html -- Best regards, Bulat mailto:bulat.zigans...@gmail.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Reminder: Haskell Implementers' Workshop CFT deadline in 2 weeks
Please consider submitting a talk proposal for the Haskell Implementers' Workshop. I'm pretty excited about this meeting - it promises to be a lively and enjoyable day. The deadline for submissions is a couple of weeks away, all you have to do is write an abstract: Call for Talks ACM SIGPLAN Haskell Implementers' Workshop http://haskell.org/haskellwiki/HaskellImplementorsWorkshop Edinburgh, Scotland, September 5, 2009 The workshop will be held in conjunction with ICFP 2009 http://www.cs.nott.ac.uk/~gmh/icfp09.html Important dates Proposal Deadline: 15 June 2009 Notification: 3 July 2009 The Haskell Implementers Workshop is a new workshop to be held alongside ICFP 2009 this year in Edinburgh, Scotland. There will be no proceedings; it is an informal gathering of people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure. This new workshop reflects the growth of the user community: there is a clear need for a well-supported tool chain for the development, distribution, deployment, and configuration of Haskell software. The aim is for this workshop to give the people involved with building the infrastructure behind this ecosystem an opportunity to bat around ideas, share experiences, and ask for feedback from fellow experts. We intend the workshop to have an informal and interactive feel, with a flexible timetable and plenty of room for ad-hoc discussion, demos, and impromptu short talks. Scope and target audience - We feel it's important to clearly distinguish the Haskell Implementers Workshop from the other Haskell-related workshops co-located with ICFP 2009. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementers' Workshop will have no proceedings - although we will aim to make slides and talk videos available with the consent of the speakers. DEFUN aims to teach how functional programming techniques can be applied in practice. In the Haskell Implementors' Workshop we hope to study the underlying technology that drives this application development. We want to bring together anyone interested in the nitty gritty details necessary to turn a text file into a deployed product. Having said that, members of the wider Haskell community are more than welcome to attend the workshop - we need your feedback to keep the Haskell ecosystem thriving. The scope covers any of the following topics (but there may be some we've missed, so by all means submit a proposal even if it doesn't fit exactly into one of these buckets): * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and Tools for development or deployment Talks - At this stage we'd like to invite proposals from potential speakers for a relatively short (20-30 min) talk. Please submit a talk title and abstract of no more than 200 words to simon...@microsoft.com. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. We also plan to invite a number of speakers from the community. Organizers -- * Duncan Coutts - co-chair (Well-Typed LLP) * Atze Dijkstra (Utrecht University) * Roman Leshchinskiy (University of New South Wales) * Simon Marlow - co-chair (Microsoft Research) * Bryan O'Sullivan (Linden Lab) * Wouter Swierstra (Chalmers University of Technology) ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] The speed, size and dependability of programming languages
Thanks for the link. I find the expressiveness results odd. How can SML/NJ be among the least expressive languages, while MLTON and OCAML are among the most expressive? How is Smalltalk less expressive than Java? Why are Prolog and Mercury among the least expressive? I think it's a combination of 1) the expressiveness measure is too simplistic, measuring number of lines alone, or counting comments, and 2) the problem set is skewed toward number-crunching, which is not (say) Prolog's strong suit. On Mon, Jun 1, 2009 at 1:18 AM, Bulat Ziganshin bulat.zigans...@gmail.comwrote: Hello haskell, Interesting blog post comparing speed and expressiveness of many languages: http://gmarceau.qc.ca/blog/2009/05/speed-size-and-dependability-of.html -- Best regards, Bulat mailto:bulat.zigans...@gmail.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] The speed, size and dependability of programming languages
lists: I think it's a combination of 1) the expressiveness measure is too simplistic, measuring number of lines alone, or counting comments It isn't measuring lines of code, it is measuring the Gzip compression Also, there's a few bogons in the data (it was graphed against 2005-6 results, and includes programs that produce the wrong output, and programs where the are duplicate entires per language). -- Don ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] The speed, size and dependability of programming languages
On Mon, Jun 1, 2009 at 1:58 PM, Lyle Kopnicky li...@qseep.net wrote: Why are Prolog and Mercury among the least expressive? Well, I don't know about SML/NJ, since I don't see anything obviously wrong at http://shootout.alioth.debian.org/gp4/benchmark.php?test=alllang=smlnjlang2=ghcbox=1 But as for Prolog - I can't help but think of a quote I saw in a recent paper in LtU, which went something like 'Our first prototype was written in Prolog, but when we realized that we were using none of the logic programming features, we decided to rewrite in Haskell.' -- gwern ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re[2]: [Haskell] The speed, size and dependability of programming languages
Hello Lyle, Monday, June 1, 2009, 9:58:14 PM, you wrote: Thanks for the link. I find the expressiveness results odd. How can SML/NJ be among the least expressive languages, while MLTON and OCAML are among the most expressive? optimization tricks? How is Smalltalk less expressive than Java? libraries? Why are Prolog and Mercury among the least expressive? programming style? -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] The speed, size and dependability of programming languages
gwern0: On Mon, Jun 1, 2009 at 1:58 PM, Lyle Kopnicky li...@qseep.net wrote: Why are Prolog and Mercury among the least expressive? Well, I don't know about SML/NJ, since I don't see anything obviously wrong at http://shootout.alioth.debian.org/gp4/benchmark.php?test=alllang=smlnjlang2=ghcbox=1 There's one thing wrong: Last Updated: Tue Mar 20 18:02:38 PDT 2007 Don't use the gp4 results: they're obsolete. Use the u32, u64, u32q or u64q results. -- Don ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Data.Generics.gzip3 anyone?
Is there a Scrap Your Boilerplate guru out there who could whip up a three argument version of gzip for me? ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] The speed, size and dependability of programming languages
Instead of GZip metrics for code size, maybe a good measure of imperative language code size would be the cyclomatic complexity metric. It would also be interesting to see results for Fortran, Java, C++, etc. across a range of old and newer compilers. Can one measure cyclomatic complexity for functional languages? However: From: http://en.wikipedia.org/wiki/Software_metric Modern software development practitioners are likely to point out that naive and simplistic metrics can cause more harm than good. ALSO: one is often more interested in Software Quality factors * 4.1.1 Understandability * 4.1.2 Completeness * 4.1.3 Conciseness * 4.1.4 Portability * 4.1.5 Consistency * 4.1.6 Maintainability * 4.1.7 Testability * 4.1.8 Usability * 4.1.9 Reliability * 4.1.10 Structuredness * 4.1.11 Efficiency * 4.1.12 Security Which seem only to be qualitatively metricable and not quantitatively metricable. Benchmarks of any type only seem to be applicable to your program if your program is fairly similar to the benchmark. -- Regards, Casey ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Data.Generics.gzip3 anyone?
On Mon, Jun 1, 2009 at 8:20 PM, David Fox da...@seereason.com wrote: Is there a Scrap Your Boilerplate guru out there who could whip up a three argument version of gzip for me? This can be done of course (untested but type-checked code follows). Left wondering what the scenario might be :-) Ralf import Prelude hiding (GT) import Data.Generics -- As originally defined: Twin map for transformation gzipWithT2 :: GenericQ (GenericT) - GenericQ (GenericT) gzipWithT2 f x y = case gmapAccumT perkid funs y of ([], c) - c _ - error gzipWithT2 where perkid a d = (tail a, unGT (head a) d) funs = gmapQ (\k - GT (f k)) x -- For three args now gzipWithT3 :: GenericQ (GenericQ (GenericT)) - GenericQ (GenericQ (GenericT)) gzipWithT3 f x y z = case gmapAccumT perkid funs' z of ([], c) - c _ - error gzipWithT3 where perkid a d = (tail a, unGT (head a) d) funs' = case gmapAccumQ perkid' funs y of ([], q) - q _ - error gzipWithT3 where perkid' a d = (tail a, unGQ (head a) d) funs = gmapQ (\k - (GQ (\k' - GT (f k k' x ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Data.Generics.gzip3 anyone?
Thank you! What I have in mind is three way merging - you have two
revisions based on the same original value, and you need to decide whether
they can be merged automatically or they need to be merged by a user. You
only have a real conflict when both revisions differ from the original and
from each other.
Here is the completed exercise.
For comparison, the two args versions are shown up-front.
There is gzipWithM3 needed for gzip3, and gzip3 itself.
I also made it so that the top-level gzip functions have the
appropriate polymorphism.
Say same type for the args rather than independent polymorphism.
{-# LANGUAGE RankNTypes #-}
import Prelude hiding (GT)
import Data.Generics
-- As originally defined: Twin map for transformation
gzipWithT2 :: GenericQ (GenericT) - GenericQ (GenericT)
gzipWithT2 f x y = case gmapAccumT perkid funs y of
([], c) - c
_ - error gzipWithT2
where
perkid a d = (tail a, unGT (head a) d)
funs = gmapQ (\k - GT (f k)) x
-- As originally defined: Twin map for transformation
gzipWithM2 :: Monad m = GenericQ (GenericM m) - GenericQ (GenericM m)
gzipWithM2 f x y = case gmapAccumM perkid funs y of
([], c) - c
_ - error gzipWithM
where
perkid a d = (tail a, unGM (head a) d)
funs = gmapQ (\k - GM (f k)) x
-- As originally defined: generic zip
gzip2 ::
(forall x. Data x = x - x - Maybe x)
- (forall x. Data x = x - x - Maybe x)
gzip2 f = gzip2' f'
where
f' :: GenericQ (GenericM Maybe)
f' x y = cast x = \x' - f x' y
gzip2' :: GenericQ (GenericM Maybe) - GenericQ (GenericM Maybe)
gzip2' f x y =
f x y
`orElse`
if toConstr x == toConstr y
then gzipWithM2 (gzip2' f) x y
else Nothing
-- For three args now
gzipWithT3 ::
GenericQ (GenericQ (GenericT))
- GenericQ (GenericQ (GenericT))
gzipWithT3 f x y z =
case gmapAccumT perkid funs z of
([], c) - c
_ - error gzipWithT3
where
perkid a d = (tail a, unGT (head a) d)
funs = case gmapAccumQ perkid' funs' y of
([], q) - q
_ - error gzipWithT3
where
perkid' a d = (tail a, unGQ (head a) d)
funs' = gmapQ (\k - (GQ (\k' - GT (f k k' x
gzipWithM3 :: Monad m
= GenericQ (GenericQ (GenericM m))
- GenericQ (GenericQ (GenericM m))
gzipWithM3 f x y z =
case gmapAccumM perkid funs z of
([], c) - c
_ - error gzipWithM3
where
perkid a d = (tail a, unGM (head a) d)
funs = case gmapAccumQ perkid' funs' y of
([], q) - q
_ - error gzipWithM3
where
perkid' a d = (tail a, unGQ (head a) d)
funs' = gmapQ (\k - (GQ (\k' - GM (f k k' x
gzip3 ::
(forall x. Data x = x - x - x - Maybe x)
- (forall x. Data x = x - x - x - Maybe x)
gzip3 f = gzip3' f'
where
f' :: GenericQ (GenericQ (GenericM Maybe))
f' x y z = cast x = \x' - cast y = \y' - f x' y' z
gzip3' ::
GenericQ (GenericQ (GenericM Maybe))
- GenericQ (GenericQ (GenericM Maybe))
gzip3' f x y z =
f x y z
`orElse`
if and [toConstr x == toConstr y, toConstr y == toConstr z]
then gzipWithM3 (gzip3' f) x y z
else Nothing
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Data.Generics.gzip3 anyone?
On Mon, Jun 1, 2009 at 3:40 PM, Ralf Laemmel rlaem...@gmail.com wrote:
Thank you! What I have in mind is three way merging - you have two
revisions based on the same original value, and you need to decide
whether
they can be merged automatically or they need to be merged by a user.
You
only have a real conflict when both revisions differ from the original
and
from each other.
Here is the completed exercise.
For comparison, the two args versions are shown up-front.
There is gzipWithM3 needed for gzip3, and gzip3 itself.
I also made it so that the top-level gzip functions have the
appropriate polymorphism.
Say same type for the args rather than independent polymorphism.
{-# LANGUAGE RankNTypes #-}
import Prelude hiding (GT)
import Data.Generics
-- As originally defined: Twin map for transformation
gzipWithT2 :: GenericQ (GenericT) - GenericQ (GenericT)
gzipWithT2 f x y = case gmapAccumT perkid funs y of
([], c) - c
_ - error gzipWithT2
where
perkid a d = (tail a, unGT (head a) d)
funs = gmapQ (\k - GT (f k)) x
-- As originally defined: Twin map for transformation
gzipWithM2 :: Monad m = GenericQ (GenericM m) - GenericQ (GenericM m)
gzipWithM2 f x y = case gmapAccumM perkid funs y of
([], c) - c
_ - error gzipWithM
where
perkid a d = (tail a, unGM (head a) d)
funs = gmapQ (\k - GM (f k)) x
-- As originally defined: generic zip
gzip2 ::
(forall x. Data x = x - x - Maybe x)
- (forall x. Data x = x - x - Maybe x)
gzip2 f = gzip2' f'
where
f' :: GenericQ (GenericM Maybe)
f' x y = cast x = \x' - f x' y
gzip2' :: GenericQ (GenericM Maybe) - GenericQ (GenericM Maybe)
gzip2' f x y =
f x y
`orElse`
if toConstr x == toConstr y
then gzipWithM2 (gzip2' f) x y
else Nothing
-- For three args now
gzipWithT3 ::
GenericQ (GenericQ (GenericT))
- GenericQ (GenericQ (GenericT))
gzipWithT3 f x y z =
case gmapAccumT perkid funs z of
([], c) - c
_ - error gzipWithT3
where
perkid a d = (tail a, unGT (head a) d)
funs = case gmapAccumQ perkid' funs' y of
([], q) - q
_ - error gzipWithT3
where
perkid' a d = (tail a, unGQ (head a) d)
funs' = gmapQ (\k - (GQ (\k' - GT (f k k' x
gzipWithM3 :: Monad m
= GenericQ (GenericQ (GenericM m))
- GenericQ (GenericQ (GenericM m))
gzipWithM3 f x y z =
case gmapAccumM perkid funs z of
([], c) - c
_ - error gzipWithM3
where
perkid a d = (tail a, unGM (head a) d)
funs = case gmapAccumQ perkid' funs' y of
([], q) - q
_ - error gzipWithM3
where
perkid' a d = (tail a, unGQ (head a) d)
funs' = gmapQ (\k - (GQ (\k' - GM (f k k' x
gzip3 ::
(forall x. Data x = x - x - x - Maybe x)
- (forall x. Data x = x - x - x - Maybe x)
gzip3 f = gzip3' f'
where
f' :: GenericQ (GenericQ (GenericM Maybe))
f' x y z = cast x = \x' - cast y = \y' - f x' y' z
gzip3' ::
GenericQ (GenericQ (GenericM Maybe))
- GenericQ (GenericQ (GenericM Maybe))
gzip3' f x y z =
f x y z
`orElse`
if and [toConstr x == toConstr y, toConstr y == toConstr z]
then gzipWithM3 (gzip3' f) x y z
else Nothing
Oh, thank goodness!
-david
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] (Pre-) Announce: Data.GDS 0.1.0
Hello, all, I'm hereby announcing Data.GDS, a small module to write and (eventually -- that's part of the pre) read GDS files. For those of you not in the semiconductor biz, GDS-II is one of the classic formats of the industry. It's perhaps ever so slightly obsolete at this point, as the OASIS format is in the process of displacing it, but there are still huge numbers of designs in GDS format, and lots and lots of tools deal with it. Since I'm a sad sick weirdo(*), I spent a perfectly nice sunny NorCal day hacking up this initial version of this module. It is to the point where it can generate a GDS file of your devising, although your specification of it still has to be at a very low level. It would be, and eventually will be, nicer to specify things at a higher level of abstraction. Also, it will eventually be nice to be able to read GDS files, returning an array of GDSRecord. I know how to do that, and I plan to, but I haven't got there yet. This ought to already be properly cabalized, and there's a small test program included; run it, save the output somewhere, and compare that with the sample GDS file which I also included in the tarball. If you examine the GDS file itself, you will see that, although it is small, it does in fact contain vital bits of design which will no doubt enable the biz to continue Moore's law for at least another century or so. Once I've implemented the reader, I'll upload this to hackage; in the meantime, if any of you are especially interested in what the rest of the interface to this should look like, I'm happy to hear your suggestions! Uwe (*) In point of fact, I am neither sad nor sick; I am in fact mostly happy healthy. The reason I wasn't out taking a long walk today was because, alas, I dinged one achilles tendon a few days ago, and wanted to let it heal a bit... as to the weirdo charge, I beg you, gentle readers, avert your eyes while I plead no contest! :-) gds-0.1.0.tar.gz Description: GNU Zip compressed data ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Umlauts in command line arguments
Hello Gwern, Monday, June 1, 2009, 4:35:25 AM, you wrote: GHC mangles UTF by default. You probably want to use one of the utf8 packages; eg. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/utf8-string or http://hackage.haskell.org/cgi-bin/hackage-scripts/package/utf8-light (Neither of them seems to allow for accessing *arguments* rather than stdin/stdout, but you could probably do something with the encoding/decoding functions.) in order to get proper unicode handling, one should ask win api directly for cmdline: myGetArgs = do alloca $ \p_argc - do p_argv_w - commandLineToArgvW getCommandLineW p_argc argc - peek p_argc argv_w - peekArray (i argc) p_argv_w mapM peekTString argv_w == tail foreign import stdcall unsafe windows.h GetCommandLineW getCommandLineW :: LPTSTR foreign import stdcall unsafe windows.h CommandLineToArgvW commandLineToArgvW :: LPCWSTR - Ptr CInt - IO (Ptr LPWSTR) -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] iota
Hi all, I was looking for an APL-style iota function for array indices. I noticed range from Data.Ix which, with a zero for the lower bound (here (0,0)), gives the values I need: let (a,b) = (2,3) index ((0,0),(a-1,b-1)) [(0,0),(0,1),(0,2),(1,0),(1,1),(1,2)] However, I need the results as a list of lists rather than a list of tuples; and my input is a list of integral values. I ended up writing the following function instead. The function isn't long, but longer than I first expected. Did I miss a simpler approach? iota :: (Integral a) = [a] - [[a]] iota is = let count = product is tups = zip (tail $ scanr (*) 1 is) is buildRepList (r,i) = genericTake count $ cycle $ [0..i-1] = genericReplicate r lists = map buildRepList tups in transpose lists length $ iota [2,3,4] 24 Thanks, Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] problem with inf-haskell + ghci?
Hello all I recently found strange problem in use of inf-haskell + ghci on my Mac OS X Tyger. I haven't used inf-haskell for a some time, and several days ago i found, that it stopped to work - when I run C-c C-l (load file) it signal error, and when I perform C-c C-b (start interpreter) it load it, but entering of any text in it, leads to message: Leaving GHCi. Process haskell finished In terminal ghci works fine, but I couldn't find why ghci terminates when it called from Emacs. May be somebody had such problem with ghci? P.S. I use Carbon Emacs 22 + ghc 6.10.1 installed from macports -- With best wishes, Alex Ott, MBA http://alexott.blogspot.com/http://xtalk.msk.su/~ott/ http://alexott-ru.blogspot.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Bool as type class to serve EDSLs.
On Jun 1, 2009, at 12:17 AM, Henning Thielemann wrote: On Thu, 28 May 2009, Bulat Ziganshin wrote: i use another approach which imho is somewhat closer to interpretation of logical operations in dynamic languages (lua, ruby, perl): [...] The absence of such interpretations and thus the increased type safety was one of the major the reasons for me to move from scripting languages to Haskell. Do you argue that overloading logical operations like this in Haskell sacrifices type safety? Could programs go wrong [1] that use such abstractions? [1]: Robin Milner. A theory of type polymorphism in programming. J. Comput. Syst. Sci., 17:348–375, 1978. -- Underestimating the novelty of the future is a time-honored tradition. (D.G.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] iota
The iota function you're looking for can be a whole lot simpler if you know about monads (list monad in particular) and sequence. For lists, sequence has the following behaviour: sequence [xs1,xs2, ... xsn] = [[x1,x2, ... , xn] | x1 - xs1, x2 - xs2, ... , xn - xsn] Using this, you can reduce your iota function to a powerful one-liner: iota = sequence . map (enumFromTo 0 . pred) Kind regards, Raynor Vliegendhart On 6/1/09, Paul Keir pk...@dcs.gla.ac.uk wrote: Hi all, I was looking for an APL-style “iota” function for array indices. I noticed “range” from Data.Ix which, with a zero for the lower bound (here (0,0)), gives the values I need: let (a,b) = (2,3) index ((0,0),(a-1,b-1)) [(0,0),(0,1),(0,2),(1,0),(1,1),(1,2)] However, I need the results as a list of lists rather than a list of tuples; and my input is a list of integral values. I ended up writing the following function instead. The function isn’t long, but longer than I first expected. Did I miss a simpler approach? iota :: (Integral a) = [a] - [[a]] iota is = let count = product is tups = zip (tail $ scanr (*) 1 is) is buildRepList (r,i) = genericTake count $ cycle $ [0..i-1] = genericReplicate r lists = map buildRepList tups in transpose lists length $ iota [2,3,4] 24 Thanks, Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] RE: iota
That is quite spectacular. I revised my knowledge of sequence with a little function, akin to sequence [xs1,xs2]: seq2 xs1 xs2 = do x1 - xs1 x2 - xs2 return [x1,x2] seq2 [0,1] [0,1,2] [[0,0],[0,1],[0,2],[1,0],[1,1],[1,2]] I like your point-free style too; and that's a nice use of pred. Many thanks, Paul The iota function you're looking for can be a whole lot simpler if you know about monads (list monad in particular) and sequence. For lists, sequence has the following behaviour: sequence [xs1,xs2, ... xsn] = [[x1,x2, ... , xn] | x1 - xs1, x2 - xs2, ... , xn - xsn] Using this, you can reduce your iota function to a powerful one-liner: iota = sequence . map (enumFromTo 0 . pred) Kind regards, Raynor Vliegendhart From: Paul Keir Sent: 01 June 2009 10:01 To: haskell-cafe@haskell.org Subject: iota Hi all, I was looking for an APL-style iota function for array indices. I noticed range from Data.Ix which, with a zero for the lower bound (here (0,0)), gives the values I need: let (a,b) = (2,3) index ((0,0),(a-1,b-1)) [(0,0),(0,1),(0,2),(1,0),(1,1),(1,2)] However, I need the results as a list of lists rather than a list of tuples; and my input is a list of integral values. I ended up writing the following function instead. The function isn't long, but longer than I first expected. Did I miss a simpler approach? iota :: (Integral a) = [a] - [[a]] iota is = let count = product is tups = zip (tail $ scanr (*) 1 is) is buildRepList (r,i) = genericTake count $ cycle $ [0..i-1] = genericReplicate r lists = map buildRepList tups in transpose lists length $ iota [2,3,4] 24 Thanks, Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GUI and background processing
Greetings, fellow haskellers. Currently I'm writing some kind of web crawler in haskell with gtk2hs gui. All network operations are run in separate thread, but sometimes input from user is needed. Afaik, gtk2hs is not thread safe, so I came up with following: I create two mvars, A and B, one for question, one for answer. Worker thread puts question in A and blocks trying to take B. Gui thread checks for question by polling with tryTakeMVar. Then question is ready, it asks user and puts his answer into B. Worker awakens and continues processing. Also, for progress report, I use a Chan which is written to by worker and is read by polling by gui thread. This scheme works, but I don't like it. All these mvars and chans create too much clutter, and polling looks rather ugly too. Is there a better way for implementing similar patterns of interaction? Best regards, Dmitry. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GUI and background processing
Hello Dmitry, Monday, June 1, 2009, 4:24:36 PM, you wrote: All network operations are run in separate thread, but sometimes input from user is needed. Afaik, gtk2hs is not thread safe, so I came up with look for postGUISync and postGUIASync -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Trouble with types
Hi, I tried this code: --- f, g :: a - a (f, g) = (id, id) --- Hugs: OK GHC: Couldn't match expected type `forall a. a - a' against inferred type `a - a' In the expression: id In the expression: (id, id) In a pattern binding: (f, g) = (id, id) What does mean this error message? And what of them (Hugs, GHC) is correct? Thanks Vladimir ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Trouble with types
Am Montag 01 Juni 2009 14:44:37 schrieb Vladimir Reshetnikov: Hi, I tried this code: --- f, g :: a - a (f, g) = (id, id) --- Hugs: OK GHC: Couldn't match expected type `forall a. a - a' against inferred type `a - a' In the expression: id In the expression: (id, id) In a pattern binding: (f, g) = (id, id) What does mean this error message? And what of them (Hugs, GHC) is correct? http://www.haskell.org/ghc/docs/latest/html/users_guide/bugs-and-infelicities.html Section 12.1.1.4, Declarations and bindings GHC's typechecker makes all pattern bindings monomorphic by default; this behaviour can be disabled with -XNoMonoPatBinds. See Section 7.1, “Language options”. Hugs is correct, it's a known infelicity in GHC which can be disabled. Thanks Vladimir ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Bool as type class to serve EDSLs.
On Mon, Jun 1, 2009 at 3:06 AM, Sebastian Fischer s...@informatik.uni-kiel.de wrote: On Jun 1, 2009, at 12:17 AM, Henning Thielemann wrote: On Thu, 28 May 2009, Bulat Ziganshin wrote: i use another approach which imho is somewhat closer to interpretation of logical operations in dynamic languages (lua, ruby, perl): [...] The absence of such interpretations and thus the increased type safety was one of the major the reasons for me to move from scripting languages to Haskell. Do you argue that overloading logical operations like this in Haskell sacrifices type safety? Could programs go wrong [1] that use such abstractions? If I understand your point correctly, you are suggesting that such programs are still type safe. I agree with the claim that such features are detrimental in practice though. Instead of lumping it with type safety, then what do we call it? I think I've heard of languages that do such conversions as weakly typed. Really the issue is with implicit conversions, right? Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Missing a Deriving?
I went back and tried to convert the YAHT example to Monad, importing Monad,
commenting out all but the data descriptions and the searchAll function, and
finally replacing success, failure, augment, and combine in the searchAll
function with return, fail, =, and mplus.
*Main let g = Graph [(1,'a'),(2,'b'),(3,'c'),(4,'d')]
[(1,2,'p'),(2,3,'q'),(1,4,'r'),(4,3,'s')]
*Main searchAll g 1 3 :: [[Int]]
[[1,2,3],[1,4,3]]
*Main searchAll g 1 3 :: Maybe [Int]
Just [1,2,3]
*Main searchAll g 3 1 :: Maybe [Int]
Nothing
*Main searchAll g 3 1 :: [[Int]]
[]
All good so far, but then tried to convert Failable from Computation to Monad
instance Monad Failable where
return = Success
fail = Fail
= (Success x) f = f x
= (Fail s) _ = Fail s
mplus (Fail _) y = y
mplus x _ = x
and got the following error.
Prelude :l graph5
[1 of 1] Compiling Main ( graph5.hs, interpreted )
graph5.hs:34:4: parse error on input `='
Failed, modules loaded: none.
Prelude
Complete code follows.
Michael
=
import Monad
data Failable a = Success a | Fail String deriving (Show)
data Graph v e = Graph [(Int,v)] [(Int,Int,e)]
{-
class Computation c where
success :: a - c a
failure :: String - c a
augment :: c a - (a - c b) - c b
combine :: c a - c a - c a
instance Computation Maybe where
success = Just
failure = const Nothing
augment (Just x) f = f x
augment Nothing _ = Nothing
combine Nothing y = y
combine x _ = x
instance Computation Failable where
success = Success
failure = Fail
augment (Success x) f = f x
augment (Fail s) _ = Fail s
combine (Fail _) y = y
combine x _ = x
-}
instance Monad Failable where
return = Success
fail = Fail
= (Success x) f = f x
= (Fail s) _ = Fail s
mplus (Fail _) y = y
mplus x _ = x
{-
instance Computation [] where
success a = [a]
failure = const []
augment l f = concat (map f l)
combine = (++)
searchAll g@(Graph vl el) src dst
| src == dst = success [src]
| otherwise = search' el
where search' [] = failure no path
search' ((u,v,_):es)
| src == u = (searchAll g v dst `augment`
(success . (u:)))
`combine` search' es
| otherwise = search' es
-}
searchAll g@(Graph vl el) src dst
| src == dst = return [src]
| otherwise = search' el
where search' [] = fail no path
search' ((u,v,_):es)
| src == u = (searchAll g v dst =
(return . (u:)))
`mplus` search' es
| otherwise = search' es
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to implement this? A case for scoped record labels?
On Sun, May 31, 2009 at 06:20:23PM -0700, Iavor Diatchki wrote: and so on. It is a bit verbose, but you only have to do it once for your protocol, and then you get the nice overloaded interface. This also seems like the kind of thing perfectly suited to Template Haskell. Especially if the records might end up being modified, fields added, etc., having some TH code to regenerate all the necessary classes and instances from some compact description could be a big win, and probably not too hard to code either. -Brent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] MySQL, CouchDB, and Haskell
Dear Group, I've spent the last few days trying to convert a bunch of mysql tables into couchdb using haskell, and I've documented my efforts, in case anyone else intends to wander in similar waters. The tutorial is at: http://maztravel.com/haskell/mySqlToCouchDB.html comments welcome here at the list or to me privately at nadine.and.henry -AT- pobox.com Best wishes, Henry Laxen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Missing a Deriving?
Am Montag 01 Juni 2009 19:02:36 schrieb michael rice: All good so far, but then tried to convert Failable from Computation to Monad instance Monad Failable where return = Success fail = Fail = (Success x) f = f x = (Fail s) _ = Fail s mplus (Fail _) y = y mplus x _ = x and got the following error. Prelude :l graph5 [1 of 1] Compiling Main ( graph5.hs, interpreted ) graph5.hs:34:4: parse error on input `=' Failed, modules loaded: none. Prelude When you use an operator in prefix position, you must enclose it in parentheses, like you must enclose a function in backticks if you use it infix. So the definition of (=) should read (=) (Success x) f = f x (=) (Fail s) _ = Fail s or, defining it in infix position, (Success x) = f = f x (Fail s) = _ = Fail s Complete code follows. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Bool as type class to serve EDSLs.
Do you argue that overloading logical operations like this in Haskell sacrifices type safety? Could programs go wrong [1] that use such abstractions? If I understand your point correctly, you are suggesting that such programs are still type safe. I agree with the claim that such features are detrimental in practice though. Instead of lumping it with type safety, then what do we call it? I think I've heard of languages that do such conversions as weakly typed. Really the issue is with implicit conversions, right? Isn't it merely a matter of balance? In order for typed programs not to go wrong, one has to define right and wrong, and devise a type system that rules out anything that might go wrong, usually at the expense of some programs that might go right. Advanced type system features like overloading take that unused space and devise ways to redirect code that would go wrong (in simpler systems) to go right in useful new ways (eg: adding two functions or matrices or .. does not have to be wrong, there are interpretations in which all of these make perfect sense, and Haskell can express many of them). What is happening then is that more and more of the previously wrong space is filled up with meaningful ways of going right, until nearly every syntactically valid program goes somewhere. That can make for an extremely expressive and powerful language, but it renders the naive notion of going wrong or right rather meaningless: wrong just means we haven't figured out a meaningful way to interpret it, and going right can easily be a far cry from where you wanted it to go. Claus PS. this problem can be made worse if the implicit conversions aren't consistent, if small twitches in source code can lead to grossly different behaviour. There is a fine line between advanced and uncontrollable, and opinions on what side of the line any given definition is on can differ. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: new version of uu-parsinglib
And rename empty to fail? You managed to confuse me since I always use pSucceed to recognise the empty string. Doaitse On 1 jun 2009, at 01:21, Ross Paterson wrote: On Sun, May 31, 2009 at 09:40:38PM +0200, S. Doaitse Swierstra wrote: A new version of the uu-parsinglib has been uploaded to hackage. It is now based on Control.Applicative where possible. Be warned that functions like some and many will be redefined in the future. Perhaps we should make some and many methods of Alternative, * and * methods of Applicative and $ a method of Functor, all with the current definitions as defaults. (John Meacham was also asking for the first of these.) ___ 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] Re: Error message reform (was: Strange type errorwith associated type synonyms)
I once thought, that error messages must be configurable by libraries, too. This would be perfect for EDSLs that shall be used by non-Haskellers. Yes, that is a problem. But I have no idea how to design that. There was some work in that direction in the context of the Helium project. See the publication lists of Bastiaan Heeren and Jurriaan Hage: http://people.cs.uu.nl/bastiaan/#Publications http://www.cs.uu.nl/research/techreps/aut/jur.html Claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Missing a Deriving?
Got it. Thanks! Michael --- On Mon, 6/1/09, Daniel Fischer daniel.is.fisc...@web.de wrote: From: Daniel Fischer daniel.is.fisc...@web.de Subject: Re: [Haskell-cafe] Missing a Deriving? To: haskell-cafe@haskell.org Date: Monday, June 1, 2009, 1:51 PM Am Montag 01 Juni 2009 19:02:36 schrieb michael rice: All good so far, but then tried to convert Failable from Computation to Monad instance Monad Failable where return = Success fail = Fail = (Success x) f = f x = (Fail s) _ = Fail s mplus (Fail _) y = y mplus x _ = x and got the following error. Prelude :l graph5 [1 of 1] Compiling Main ( graph5.hs, interpreted ) graph5.hs:34:4: parse error on input `=' Failed, modules loaded: none. Prelude When you use an operator in prefix position, you must enclose it in parentheses, like you must enclose a function in backticks if you use it infix. So the definition of (=) should read (=) (Success x) f = f x (=) (Fail s) _ = Fail s or, defining it in infix position, (Success x) = f = f x (Fail s) = _ = Fail s Complete code follows. Michael ___ 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] Bool as type class to serve EDSLs.
Do you argue that overloading logical operations like this in Haskell sacrifices type safety? Could programs go wrong [1] that use such abstractions? If I understand your point correctly, you are suggesting that such programs are still type safe. My asking was really meant as a question to find out what Henning meant when he talked about type safety. I agree with the claim that such features are detrimental in practice though. I also feel uncomfortable about such features, but the problem seems to be different from type safety. Maybe it is more about predictability. For example, if '1 + 23 = 24' and '1 + 23 = 123' this can lead to confusion although using overloading this could be done in Haskell. That the compiler is able to figure out a correct instantiation of an overloaded operation does not mean that it is easy for the programmer too. And if it is not, programs are hard to understand. Instead of lumping it with type safety, then what do we call it? I think I've heard of languages that do such conversions as weakly typed. Really the issue is with implicit conversions, right? Isn't it merely a matter of balance? In order for typed programs not to go wrong, one has to define right and wrong, and devise a type system that rules out anything that might go wrong, usually at the expense of some programs that might go right. I had in mind causes a run-time error as definition of goes wrong. But this simple view may well be inaccurate. Advanced type system features like overloading take that unused space and devise ways to redirect code that would go wrong (in simpler systems) to go right in useful new ways (eg: adding two functions or matrices or .. does not have to be wrong, there are interpretations in which all of these make perfect sense, and Haskell can express many of them). What is happening then is that more and more of the previously wrong space is filled up with meaningful ways of going right, until nearly every syntactically valid program goes somewhere. That can make for an extremely expressive and powerful language, but it renders the naive notion of going wrong or right rather meaningless: wrong just means we haven't figured out a meaningful way to interpret it, and going right can easily be a far cry from where you wanted it to go. I (think I) agree with you. Overloading could give a meaning to almost everything. Not necessarily a sensible one, and judgements about what is sensible seem to differ among different people. Regardless of whether a specific overloading is *sensible*, wanting it to be *predictable* seems like a reasonable requirement which may be easier to agree on. Cheers, Sebastian -- Underestimating the novelty of the future is a time-honored tradition. (D.G.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Checking a value against a passed-in constructor?
Hi, (Relatively new to Haskell here ..) So I have the following: data MyVal = Atom String | Bool Bool And I want to do something like this check :: (Bool - MyVal) - MyVal - True check f (f x) = True check _ _ = False What that means is I want to pass a MyVal constructor and a MyVal, and return True if the second argument was constructed with the first. More generally, I'd like to be able to do genCheck :: (* - MyVal) - MyVal - True genCheck f (f x) = True genCheck _ _ = False So that I can pass in _any_ MyVal constructor and let the function just check if the second argument was constructed with the first, without caring which constructor it is. What is the preferred way to do this, since neither of those functions compile? Cheers, - Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Checking a value against a passed-in constructor?
Hi Dan, On Mon, Jun 1, 2009 at 8:39 PM, Dan Cook danielkc...@gmail.com wrote: Hi, (Relatively new to Haskell here ..) So I have the following: data MyVal = Atom String | Bool Bool And I want to do something like this check :: (Bool - MyVal) - MyVal - True check f (f x) = True check _ _ = False You may be confusing yourself here on one point. The type 'Bool' is already defined by the prelude, but the data constructor is not. So you are able to create a data constructor for MyVal that is called Bool and contains a Bool. I think this distinction is leading to the next probem I see. Type signatures have to contain types and not values in Haskell. 'True' is a value so it can't be placed in the type signature. The type of True is Bool. So I think you meant to ask about: check :: (Bool - MyVal) - MyVal - Bool Now if you define this function the first parameter can be any function Bool - MyVal, not just the data constructors of MyVal. Also, the type of Atom :: String - MyVal so you can't even pass it to 'check'. What that means is I want to pass a MyVal constructor and a MyVal, and return True if the second argument was constructed with the first. More generally, I'd like to be able to do genCheck :: (* - MyVal) - MyVal - True genCheck f (f x) = True genCheck _ _ = False So that I can pass in _any_ MyVal constructor and let the function just check if the second argument was constructed with the first, without caring which constructor it is. This strikes me as a job for template haskell, but the use of TH is beyond what I can explain :) What is the preferred way to do this, since neither of those functions compile? My preferred way, is just to define isAtom and isBool both with type MyVal - Bool and use them where I need them. There are a number of tools to generate such things like DrIFT, TH, and maybe some others? I hope that helps, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Missing a Deriving?
Still stumped. Maybe and [] are in the same MonadPlus monad, but how do I make
monad Failable understand mplus?
I'm now getting this error upon loading:
Prelude :l graph5
[1 of 1] Compiling Main ( graph5.hs, interpreted )
graph5.hs:36:4: `mplus' is not a (visible) method of class `Monad'
Failed, modules loaded: none.
Prelude
Complete code follows.
Michael
=
import Monad
data Failable a = Success a | Fail String deriving (Show)
data Graph v e = Graph [(Int,v)] [(Int,Int,e)]
{-
class Computation c where
success :: a - c a
failure :: String - c a
augment :: c a - (a - c b) - c b
combine :: c a - c a - c a
instance Computation Maybe
where
success = Just
failure = const Nothing
augment (Just x) f = f x
augment Nothing _ = Nothing
combine Nothing y = y
combine x _ = x
instance Computation Failable where
success = Success
failure = Fail
augment (Success x) f = f x
augment (Fail s) _ = Fail s
combine (Fail _) y = y
combine x _ = x
-}
instance Monad Failable where
return = Success
fail = Fail
(=) (Success x) f = f x
(=) (Fail s) _ = Fail s
mplus (Fail _) y = y
mplus x _ = x
{-
instance Computation [] where
success a =
[a]
failure = const []
augment l f = concat (map f l)
combine = (++)
searchAll g@(Graph vl el) src dst
| src == dst = success [src]
| otherwise = search' el
where search' [] = failure no path
search' ((u,v,_):es)
| src == u = (searchAll g v dst `augment`
(success . (u:)))
`combine` search'
es
| otherwise = search' es
-}
searchAll g@(Graph vl el) src dst
| src == dst = return [src]
| otherwise = search' el
where search' [] = fail no path
search' ((u,v,_):es)
| src == u = (searchAll g v dst =
(return . (u:)))
`mplus` search'
es
| otherwise = search' es
-Inline Attachment Follows-
___
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] Missing a Deriving?
mplus is a method of class MonadPlus, so you need to write it in a
separate instance from the one for Monad, e.g.
instance MonadPlus Failable where
mplus = ...
-Ross
On Jun 1, 2009, at 9:28 PM, michael rice wrote:
Still stumped. Maybe and [] are in the same MonadPlus monad, but how
do I make monad Failable understand mplus?
I'm now getting this error upon loading:
Prelude :l graph5
[1 of 1] Compiling Main ( graph5.hs, interpreted )
graph5.hs:36:4: `mplus' is not a (visible) method of class `Monad'
Failed, modules loaded: none.
Prelude
Complete code follows.
Michael
=
import Monad
data Failable a = Success a | Fail String deriving (Show)
data Graph v e = Graph [(Int,v)] [(Int,Int,e)]
{-
class Computation c where
success :: a - c a
failure :: String - c a
augment :: c a - (a - c b) - c b
combine :: c a - c a - c a
instance Computation Maybe where
success = Just
failure = const Nothing
augment (Just x) f = f x
augment Nothing _ = Nothing
combine Nothing y = y
combine x _ = x
instance Computation Failable where
success = Success
failure = Fail
augment (Success x) f = f x
augment (Fail s) _ = Fail s
combine (Fail _) y = y
combine x _ = x
-}
instance Monad Failable where
return = Success
fail = Fail
(=) (Success x) f = f x
(=) (Fail s) _ = Fail s
mplus (Fail _) y = y
mplus x _ = x
{-
instance Computation [] where
success a = [a]
failure = const []
augment l f = concat (map f l)
combine = (++)
searchAll g@(Graph vl el) src dst
| src == dst = success [src]
| otherwise = search' el
where search' [] = failure no path
search' ((u,v,_):es)
| src == u = (searchAll g v dst `augment`
(success . (u:)))
`combine` search' es
| otherwise = search' es
-}
searchAll g@(Graph vl el) src dst
| src == dst = return [src]
| otherwise = search' el
where search' [] = fail no path
search' ((u,v,_):es)
| src == u = (searchAll g v dst =
(return . (u:)))
`mplus` search' es
| otherwise = search' es
-Inline Attachment Follows-
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Missing a Deriving?
Hi Ross,
I thought of that, but return, fail, and = became not visible when I
changed the instance declaration from Monad to MonadPlus.. Can Failable be in
two instance declarations, one for Monad (giving it return, fail, and =) and
one for MonadPlus (giving it mplus)?
Michael
--- On Mon, 6/1/09, Ross Mellgren rmm-hask...@z.odi.ac wrote:
From: Ross Mellgren rmm-hask...@z.odi.ac
Subject: Re: [Haskell-cafe] Missing a Deriving?
To: michael rice nowg...@yahoo.com
Cc: haskell-cafe Cafe haskell-cafe@haskell.org
Date: Monday, June 1, 2009, 9:33 PM
mplus is a method of class MonadPlus, so you need to write it in a separate
instance from the one for Monad, e.g.
instance MonadPlus Failable where mplus = ...
-Ross
On Jun 1, 2009, at 9:28 PM, michael rice wrote:
Still stumped. Maybe and [] are in the same MonadPlus monad, but how do I make
monad Failable understand mplus?
I'm now getting this error upon loading:
Prelude :l graph5
[1 of 1] Compiling Main ( graph5.hs, interpreted )
graph5.hs:36:4: `mplus' is not a (visible) method of class `Monad'
Failed, modules loaded: none.
Prelude
Complete code follows.
Michael
=
import Monad
data Failable a = Success a | Fail String deriving (Show)
data Graph v e = Graph [(Int,v)] [(Int,Int,e)]
{-
class Computation c where
success :: a - c a
failure :: String - c a
augment :: c a - (a - c b) - c b
combine :: c a - c a - c a
instance Computation Maybe where
success = Just
failure = const Nothing
augment (Just x) f = f x
augment Nothing _ = Nothing
combine Nothing y = y
combine x _ = x
instance Computation Failable where
success = Success
failure = Fail
augment (Success x) f = f x
augment (Fail s) _ = Fail s
combine (Fail _) y = y
combine x _ = x
-}
instance Monad Failable where
return = Success
fail = Fail
(=) (Success x) f = f x
(=) (Fail s) _ = Fail s
mplus (Fail _) y = y
mplus x _ = x
{-
instance Computation [] where
success a = [a]
failure = const []
augment l f = concat (map f l)
combine = (++)
searchAll g@(Graph vl el) src dst
| src == dst = success [src]
| otherwise = search' el
where search' [] = failure no path
search' ((u,v,_):es)
| src == u = (searchAll g v dst `augment`
(success . (u:)))
`combine` search' es
| otherwise = search' es
-}
searchAll g@(Graph vl el) src dst
| src == dst = return [src]
| otherwise = search' el
where search' [] = fail no path
search' ((u,v,_):es)
| src == u = (searchAll g v dst =
(return . (u:)))
`mplus` search' es
| otherwise = search' es
-Inline Attachment Follows-
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Missing a Deriving?
Oh I wasn't clear -- you need multiple instance declarations for a
given type (Failable, for example), one for each type class you're
implementing.
That is,
instance Monad Failable where
return = ...
...
instance MonadPlus Failable where
mplus = ...
...
-Ross
On Jun 1, 2009, at 9:40 PM, michael rice wrote:
Hi Ross,
I thought of that, but return, fail, and = became not visible
when I changed the instance declaration from Monad to MonadPlus..
Can Failable be in two instance declarations, one for Monad (giving
it return, fail, and =) and one for MonadPlus (giving it mplus)?
Michael
--- On Mon, 6/1/09, Ross Mellgren rmm-hask...@z.odi.ac wrote:
From: Ross Mellgren rmm-hask...@z.odi.ac
Subject: Re: [Haskell-cafe] Missing a Deriving?
To: michael rice nowg...@yahoo.com
Cc: haskell-cafe Cafe haskell-cafe@haskell.org
Date: Monday, June 1, 2009, 9:33 PM
mplus is a method of class MonadPlus, so you need to write it in a
separate instance from the one for Monad, e.g.
instance MonadPlus Failable where
mplus = ...
-Ross
On Jun 1, 2009, at 9:28 PM, michael rice wrote:
Still stumped. Maybe and [] are in the same MonadPlus monad, but
how do I make monad Failable understand mplus?
I'm now getting this error upon loading:
Prelude :l graph5
[1 of 1] Compiling Main ( graph5.hs, interpreted )
graph5.hs:36:4: `mplus' is not a (visible) method of class `Monad'
Failed, modules loaded: none.
Prelude
Complete code follows.
Michael
=
import Monad
data Failable a = Success a | Fail String deriving (Show)
data Graph v e = Graph [(Int,v)] [(Int,Int,e)]
{-
class Computation c where
success :: a - c a
failure :: String - c a
augment :: c a - (a - c b) - c b
combine :: c a - c a - c a
instance Computation Maybe where
success = Just
failure = const Nothing
augment (Just x) f = f x
augment Nothing _ = Nothing
combine Nothing y = y
combine x _ = x
instance Computation Failable where
success = Success
failure = Fail
augment (Success x) f = f x
augment (Fail s) _ = Fail s
combine (Fail _) y = y
combine x _ = x
-}
instance Monad Failable where
return = Success
fail = Fail
(=) (Success x) f = f x
(=) (Fail s) _ = Fail s
mplus (Fail _) y = y
mplus x _ = x
{-
instance Computation [] where
success a = [a]
failure = const []
augment l f = concat (map f l)
combine = (++)
searchAll g@(Graph vl el) src dst
| src == dst = success [src]
| otherwise = search' el
where search' [] = failure no path
search' ((u,v,_):es)
| src == u = (searchAll g v dst `augment`
(success . (u:)))
`combine` search' es
| otherwise = search' es
-}
searchAll g@(Graph vl el) src dst
| src == dst = return [src]
| otherwise = search' el
where search' [] = fail no path
search' ((u,v,_):es)
| src == u = (searchAll g v dst =
(return . (u:)))
`mplus` search' es
| otherwise = search' es
-Inline Attachment Follows-
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Missing a Deriving?
I didn't know I could do that. Works fine. Output below. Thanks!
This is some pretty neat stuff, and I've only scratched the surface.
Michael
===
[mich...@localhost ~]$ ghci
GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
Prelude :l graph5
[1 of 1] Compiling Main ( graph5.hs, interpreted )
graph5.hs:37:9:
Warning: No explicit method nor default method for `mzero'
In the instance declaration for `MonadPlus Failable'
Ok, modules loaded: Main.
*Main let g = Graph [(1,'a'),(2,'b'),(3,'c'),(4,'d')]
[(1,2,'p'),(2,3,'q'),(1,4,'r'),(4,3,'s')]
*Main searchAll g 1 3 :: Failable [Int]
Success [1,2,3]
*Main searchAll g 3 1 :: Failable [Int]
Fail no path
*Main searchAll g 1 3 :: Maybe [Int]
Just [1,2,3]
*Main searchAll g 3 1 :: Maybe [Int]
Nothing
*Main searchAll g 1 3 :: [[Int]]
[[1,2,3],[1,4,3]]
*Main searchAll g 3 1 :: [[Int]]
[]
*Main
--- On Mon, 6/1/09, Ross Mellgren rmm-hask...@z.odi.ac wrote:
From: Ross Mellgren rmm-hask...@z.odi.ac
Subject: Re: [Haskell-cafe] Missing a Deriving?
To: michael rice nowg...@yahoo.com
Cc: haskell-cafe Cafe haskell-cafe@haskell.org
Date: Monday, June 1, 2009, 9:43 PM
Oh I wasn't clear -- you need multiple instance declarations for a given type
(Failable, for example), one for each type class you're implementing.
That is,
instance Monad Failable where return = ... ...
instance MonadPlus Failable where mplus = ... ...
-Ross
On Jun 1, 2009, at 9:40 PM, michael rice wrote:
Hi Ross,
I thought of that, but return, fail, and = became not visible when I
changed the instance declaration from Monad to MonadPlus.. Can Failable be in
two instance declarations, one for Monad (giving it return, fail, and =) and
one for MonadPlus (giving it mplus)?
Michael
--- On Mon, 6/1/09, Ross Mellgren rmm-hask...@z.odi.ac wrote:
From: Ross Mellgren rmm-hask...@z.odi.ac
Subject: Re: [Haskell-cafe] Missing a Deriving?
To: michael rice nowg...@yahoo.com
Cc: haskell-cafe Cafe haskell-cafe@haskell.org
Date: Monday, June 1, 2009, 9:33 PM
mplus is a method of class MonadPlus, so you need to write it in a separate
instance from the one for Monad, e.g.
instance MonadPlus Failable where mplus = ...
-Ross
On Jun 1, 2009, at 9:28 PM, michael rice wrote:
Still stumped. Maybe and [] are in the same MonadPlus monad, but how do I make
monad Failable understand mplus?
I'm now getting this error upon loading:
Prelude :l graph5
[1 of 1] Compiling Main ( graph5.hs, interpreted )
graph5.hs:36:4: `mplus' is not a (visible) method of class `Monad'
Failed, modules loaded: none.
Prelude
Complete code follows.
Michael
=
import Monad
data Failable a = Success a | Fail String deriving (Show)
data Graph v e = Graph [(Int,v)] [(Int,Int,e)]
{-
class Computation c where
success :: a - c a
failure :: String - c a
augment :: c a - (a - c b) - c b
combine :: c a - c a - c a
instance Computation Maybe where
success = Just
failure = const Nothing
augment (Just x) f = f x
augment Nothing _ = Nothing
combine Nothing y = y
combine x _ = x
instance Computation Failable where
success = Success
failure = Fail
augment (Success x) f = f x
augment (Fail s) _ = Fail s
combine (Fail _) y = y
combine x _ = x
-}
instance Monad Failable where
return = Success
fail = Fail
(=) (Success x) f = f x
(=) (Fail s) _ = Fail s
mplus (Fail _) y = y
mplus x _ = x
{-
instance Computation [] where
success a = [a]
failure = const []
augment l f = concat (map f l)
combine = (++)
searchAll g@(Graph vl el) src dst
| src == dst = success [src]
| otherwise = search' el
where search' [] = failure no path
search' ((u,v,_):es)
| src == u = (searchAll g v dst `augment`
(success . (u:)))
`combine` search' es
| otherwise = search' es
-}
searchAll g@(Graph vl el) src dst
| src == dst = return [src]
| otherwise = search' el
where search' [] = fail no path
search' ((u,v,_):es)
| src == u = (searchAll g v dst =
(return . (u:)))
`mplus` search' es
| otherwise = search' es
-Inline Attachment Follows-
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Missing a Deriving?
graph5.hs:37:9:
Warning: No explicit method nor default method for `mzero'
In the instance declaration for `MonadPlus Failable'
This warning is saying you didn't finish the declaration.
Try something like
instance MonadPlus Failable where
mplus (Fail _) y = y
mplus x _ = x
mzero = Fail mzero
Also, I'd use import Control.Monad instead of import Monad.
-- ryan
On Mon, Jun 1, 2009 at 7:03 PM, michael rice nowg...@yahoo.com wrote:
I didn't know I could do that. Works fine. Output below. Thanks!
This is some pretty neat stuff, and I've only scratched the surface.
Michael
===
[mich...@localhost ~]$ ghci
GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
Prelude :l graph5
[1 of 1] Compiling Main ( graph5.hs, interpreted )
graph5.hs:37:9:
Warning: No explicit method nor default method for `mzero'
In the instance declaration for `MonadPlus Failable'
Ok, modules loaded: Main.
*Main let g = Graph [(1,'a'),(2,'b'),(3,'c'),(4,'d')]
[(1,2,'p'),(2,3,'q'),(1,4,'r'),(4,3,'s')]
*Main searchAll g 1 3 :: Failable [Int]
Success [1,2,3]
*Main searchAll g 3 1 :: Failable [Int]
Fail no path
*Main searchAll g 1 3 :: Maybe [Int]
Just [1,2,3]
*Main searchAll g 3 1 :: Maybe [Int]
Nothing
*Main searchAll g 1 3 :: [[Int]]
[[1,2,3],[1,4,3]]
*Main searchAll g 3 1 :: [[Int]]
[]
*Main
--- On Mon, 6/1/09, Ross Mellgren rmm-hask...@z.odi.ac wrote:
From: Ross Mellgren rmm-hask...@z.odi.ac
Subject: Re: [Haskell-cafe] Missing a Deriving?
To: michael rice nowg...@yahoo.com
Cc: haskell-cafe Cafe haskell-cafe@haskell.org
Date: Monday, June 1, 2009, 9:43 PM
Oh I wasn't clear -- you need multiple instance declarations for a given
type (Failable, for example), one for each type class you're implementing.
That is,
instance Monad Failable where
return = ...
...
instance MonadPlus Failable where
mplus = ...
...
-Ross
On Jun 1, 2009, at 9:40 PM, michael rice wrote:
Hi Ross,
I thought of that, but return, fail, and = became not visible when I
changed the instance declaration from Monad to MonadPlus.. Can Failable be
in two instance declarations, one for Monad (giving it return, fail, and
=) and one for MonadPlus (giving it mplus)?
Michael
--- On Mon, 6/1/09, Ross Mellgren rmm-hask...@z.odi.ac wrote:
From: Ross Mellgren rmm-hask...@z.odi.ac
Subject: Re: [Haskell-cafe] Missing a Deriving?
To: michael rice nowg...@yahoo.com
Cc: haskell-cafe Cafe haskell-cafe@haskell.org
Date: Monday, June 1, 2009, 9:33 PM
mplus is a method of class MonadPlus, so you need to write it in a separate
instance from the one for Monad, e.g.
instance MonadPlus Failable where
mplus = ...
-Ross
On Jun 1, 2009, at 9:28 PM, michael rice wrote:
Still stumped. Maybe and [] are in the same MonadPlus monad, but how do I
make monad Failable understand mplus?
I'm now getting this error upon loading:
Prelude :l graph5
[1 of 1] Compiling Main ( graph5.hs, interpreted )
graph5.hs:36:4: `mplus' is not a (visible) method of class `Monad'
Failed, modules loaded: none.
Prelude
Complete code follows.
Michael
=
import Monad
data Failable a = Success a | Fail String deriving (Show)
data Graph v e = Graph [(Int,v)] [(Int,Int,e)]
{-
class Computation c where
success :: a - c a
failure :: String - c a
augment :: c a - (a - c b) - c b
combine :: c a - c a - c a
instance Computation Maybe where
success = Just
failure = const Nothing
augment (Just x) f = f x
augment Nothing _ = Nothing
combine Nothing y = y
combine x _ = x
instance Computation Failable where
success = Success
failure = Fail
augment (Success x) f = f x
augment (Fail s) _ = Fail s
combine (Fail _) y = y
combine x _ = x
-}
instance Monad Failable where
return = Success
fail = Fail
(=) (Success x) f = f x
(=) (Fail s) _ = Fail s
mplus (Fail _) y = y
mplus x _ = x
{-
instance Computation [] where
success a = [a]
failure = const []
augment l f = concat (map f l)
combine = (++)
searchAll g@(Graph vl el) src dst
| src == dst = success [src]
| otherwise = search' el
where search' [] = failure no path
search' ((u,v,_):es)
| src == u = (searchAll g v dst `augment`
(success . (u:)))
`combine` search' es
| otherwise = search' es
-}
searchAll g@(Graph vl el) src dst
| src == dst = return [src]
| otherwise = search' el
where search' [] = fail no path
search' ((u,v,_):es)
| src == u = (searchAll g v dst =
(return . (u:)))
`mplus`
Re: [Haskell-cafe] Checking a value against a passed-in constructor?
On 2 Jun 2009, at 3:39 pm, Dan Cook wrote: Hi, (Relatively new to Haskell here ..) So I have the following: data MyVal = Atom String | Bool Bool And I want to do something like this check :: (Bool - MyVal) - MyVal - True check f (f x) = True check _ _ = False What that means is I want to pass a MyVal constructor and a MyVal, and return True if the second argument was constructed with the first. Yeek. Why do you want to do _that_? You could quite easily determine whether two values were constructed with the _same_ constructor: check (Atom _) (Atom _) = True check (Bool _) (Bool _) = True check __= False and instead of passing in a constructor pass in an example of a term constructed by that constructor. So instead of check Atom foo, do check (Atom undefined) foo instead of check Bool bar, do check (Bool undefined) bar Another approach is to write a boolean function for each constructor, e.g., is_atom (Atom _) = True is_atom _= False is_bool (Bool _) = True is_bool _= False and pass one of these instead of a constructor: check :: (MyVal - Bool) - MyVal - Bool check f x = f x which makes the check function itself pointless. More generally, I'd like to be able to do genCheck :: (* - MyVal) - MyVal - True genCheck f (f x) = True genCheck _ _ = False So that I can pass in _any_ MyVal constructor and let the function just check if the second argument was constructed with the first, without caring which constructor it is. There are some very high-powered things you can do in Haskell these days which would let you get closer to this than most people would be happy reading. We can use the same idea of passing an example. So given data Biffo x y z = Ping x | Pong y z | Pang x y z you can easily write check (Ping _) (Ping _) = True check (Pong _ _) (Pong _ _) = True check (Pang _ _ _) (Pang _ _ _) = True check __= False called as check (Ping undefined) foo or check (Pong undefined undefined) bar or check (Pang undefined undefined undefined) or much better, go the Boolean function route: is_ping (Ping _) = True is_ping _= False is_pong (Pong _ _) = True is_pong _ = False is_pang (Pang _ _ _) = True is_pang _= False and use one of these functions whenever you want something you can use to check for a particular constructor. There are various meta-programming (Scrap Your Boilerplate, Template Haskell) approaches you can use to automate some of these. The first step is the step backwards where you ask why am I trying to do this? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Possible Haskell Project
My family and I are moving in the coming months. My wife will be attending a new school in the fall. Among the many hassles of moving are locating and transferring medical records to new doctors and clinics. During our time in Minnesota, we've visited several clinics and hospitals, so our medical data is spread across a dozen different networks. Collecting this data is a chore. And reciting it to every new medical provider is frustrating, especially knowing someone else has already typed this stuff into the computer. For obvious reasons, there are many software companies competing in the Electronic Health Record (EHR) industry. I haven't spent much time researching the field, but I have to imagine there is no shortage of bloated standards and next to nil interoperability. With President Obama pushing for electronic health records, this could be an opportunity for the Haskell community to deliver a common framework that the US, and maybe the rest of the world, could build upon -- a longshot I realize. At the core, the fundamental problem is not that complicated. It's just storing and retrieving a person's various health events: checkups, prescriptions, procedures, test results, etc. The main technical challenges are database distribution and patient security. Both are fun problems, and our friends at Galios continue to show how effective Haskell is at building secure systems. Any thoughts? Ideas? -Tom BTW, Anyone looking to rent a house in Eden Prairie, MN? A Haskell employer is just 4 miles down the road (Eaton). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Possible Haskell Project
On Mon, Jun 1, 2009 at 11:18 PM, Tom Hawkins tomahawk...@gmail.com wrote: My family and I are moving in the coming months. My wife will be attending a new school in the fall. Among the many hassles of moving are locating and transferring medical records to new doctors and clinics. During our time in Minnesota, we've visited several clinics and hospitals, so our medical data is spread across a dozen different networks. Collecting this data is a chore. And reciting it to every new medical provider is frustrating, especially knowing someone else has already typed this stuff into the computer. For obvious reasons, there are many software companies competing in the Electronic Health Record (EHR) industry. I haven't spent much time researching the field, but I have to imagine there is no shortage of bloated standards and next to nil interoperability. With President Obama pushing for electronic health records, this could be an opportunity for the Haskell community to deliver a common framework that the US, and maybe the rest of the world, could build upon -- a longshot I realize. At the core, the fundamental problem is not that complicated. It's just storing and retrieving a person's various health events: checkups, prescriptions, procedures, test results, etc. The main technical challenges are database distribution and patient security. Both are fun problems, and our friends at Galios continue to show how effective Haskell is at building secure systems. Any thoughts? Ideas? -Tom A good place to start is http://en.wikipedia.org/wiki/HL7 , which is a not-for-profit organization which tries to define interfacing standards between medical devices and medical records providers. I haven't worked much with their standards so I don't know how useful they'd be. I think they might be geared towards vendor-to-vendor interop. As for the legacy of people who thought it wasn't complex: http://histalk.blog-city.com/guest_article__repeat_after_me_healthcare_data_models_matter.htm I don't agree with everything the guy wrote, but it's an interesting article. As for knowing how to use the data once you've got it, there were some recent news articles about the Google personal-health-record (PHR) importing billing codes and trying to use them to reconstruct a clinical history to not-so-great effect. And I would say that the security problem is more than a technical problem - the big security issue in medical record interchange is privacy. What data can flow between healthcare organizations? What information can individual organizations restrict access to? How can we get the patient's input in how their data can move between healthcare organizations? Should we? And how should data move to organizations that are both providers and payors? Does it matter? Maybe I'm drifting a bit far afield from Haskell ... Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Trouble with types
Hi Daniel, Could you please explain what does mean 'monomorphic' in this context? I thought that all type variables in Haskell are implicitly universally quantified, so (a - a) is the same type as (forall a. a - a) Thank you, Vladimir On 6/1/09, Daniel Fischer daniel.is.fisc...@web.de wrote: Am Montag 01 Juni 2009 14:44:37 schrieb Vladimir Reshetnikov: Hi, I tried this code: --- f, g :: a - a (f, g) = (id, id) --- Hugs: OK GHC: Couldn't match expected type `forall a. a - a' against inferred type `a - a' In the expression: id In the expression: (id, id) In a pattern binding: (f, g) = (id, id) What does mean this error message? And what of them (Hugs, GHC) is correct? http://www.haskell.org/ghc/docs/latest/html/users_guide/bugs-and-infelicities.html Section 12.1.1.4, Declarations and bindings GHC's typechecker makes all pattern bindings monomorphic by default; this behaviour can be disabled with -XNoMonoPatBinds. See Section 7.1, “Language options”. Hugs is correct, it's a known infelicity in GHC which can be disabled. Thanks Vladimir ___ 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
