[GHC] #1320: FAQ item for running GHCi on WinXP x64 using DEP
#1320: FAQ item for running GHCi on WinXP x64 using DEP --+- Reporter: guest| Owner: Type: task | Status: new Priority: low | Milestone: Component: GHCi |Version: 6.6.1 Severity: normal | Keywords: DEP, XP, x64, amd64, windows Difficulty: Unknown | Os: Windows Testcase: | Architecture: x86_64 (amd64) --+- Hi, I don't know if this is a bug or not, but here is what I have witnessed: In order to get ghci to run on Windows XP x64, I needed to add ghci.exe to the data execution prevention exception list. Before making this exception, running ghci.exe would pop open my debugger with an access violation. Data Execution Prevention restricts the OS from executing any code that has been marked in memory as 'data'. I presume that the interpreter is taking in some strings, doing some processing on that data; then treating it as executable code and trying to run it. That sounds like a reasonable thing to do, and I don't know if there is a way to prevent it from triggering DEP. If this isn't a bug, perhaps you will consider this exception as a FAQ entry. -- Chris Messer ([EMAIL PROTECTED]) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1320 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] #1321: GHCi stdout bug when base package is not optimised
#1321: GHCi stdout bug when base package is not optimised
---+
Reporter: simonmar | Owner:
Type: bug | Status: new
Priority: normal| Milestone: 6.8
Component: Compiler |Version: 6.7
Severity: normal| Keywords:
Difficulty: Unknown | Os: Unknown
Testcase:| Architecture: Unknown
---+
Reported by Igloo:
The problem from a couple of weeks ago, where ghci's hFlush command
seems to be flushing a different stdout to the one that expressions
evaluated by ghci write to, happens with a quickest build:
{{{
SRC_HC_OPTS = -H64m -Onot -fasm
GhcStage1HcOpts = -O -fasm
GhcStage2HcOpts = -Onot -fasm
GhcLibHcOpts= -Onot -fasm
GhcLibWays =
SplitObjs = NO
}}}
but not if libraries are optimised:
{{{
SRC_HC_OPTS = -H64m -Onot -fasm
GhcStage1HcOpts = -O -fasm
GhcStage2HcOpts = -Onot -fasm
GhcLibHcOpts= -O -fasm
GhcLibWays =
SplitObjs = NO
}}}
ghci004 is an example of a failing test (no output is printed if
libraries are not optimised).
This seems completely illogical to me. I'd have expected such a bug
would be caused by optimisation meaning stdout gets inlined somewhere or
something. Very curious!
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1321
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] #1320: FAQ item for running GHCi on WinXP x64 using DEP
#1320: FAQ item for running GHCi on WinXP x64 using DEP -+-- Reporter: guest |Owner: Type: task | Status: closed Priority: low |Milestone: Component: GHCi | Version: 6.6.1 Severity: normal| Resolution: duplicate Keywords: DEP, XP, x64, amd64, windows | Difficulty: Unknown Os: Windows | Testcase: Architecture: x86_64 (amd64)| -+-- Changes (by simonmar): * resolution: = duplicate * status: new = closed Comment: I'm assuming this is a duplicate of #885, which is fixed in 6.6.1. I'm also guessing that you marked the bug as 6.6.1 because that's the default, not that it actually happens on 6.6.1. If this is wrong and you still see the bug with 6.6.1, please re-open this ticket. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1320 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] #1317: add warning for the Prelude being imported implicitly
#1317: add warning for the Prelude being imported implicitly +--- Reporter: Isaac Dupree |Owner: Type: feature request | Status: new Priority: normal |Milestone: Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | +--- Comment (by simonpj): Seems plausible to me, and should be easy to implement, so feel free to submit a patch. The guidelines are here; http://hackage.haskell.org/trac/ghc/wiki/WorkingConventions#Howtosubmitapatchforanewfeature. Thanks Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1317 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] #1313: HEAD gives warnings about code that it generates itself
#1313: HEAD gives warnings about code that it generates itself +--- Reporter: igloo|Owner: simonpj Type: bug | Status: closed Priority: normal |Milestone: 6.8 Component: Compiler (Type checker) | Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | +--- Changes (by simonpj): * resolution: = fixed * status: new = closed Comment: I believe I have fixed this. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1313 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] #1306: GHC generates warning about internally generated functions
#1306: GHC generates warning about internally generated functions -+-- Reporter: guest |Owner: Type: bug | Status: closed Priority: normal|Milestone: Component: Compiler | Version: 6.7 Severity: normal| Resolution: fixed Keywords:| Difficulty: Unknown Os: Windows | Testcase: Architecture: Unknown | -+-- Changes (by simonpj): * resolution: = fixed * status: new = closed Comment: Dup of #1313 (well, to be fair, #1313 is dup of this). Anyway, it's fixed. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1306 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] #1308: Type signature in warning is wrong
#1308: Type signature in warning is wrong
-+--
Reporter: guest |Owner:
Type: bug | Status: new
Priority: normal|Milestone:
Component: Compiler | Version: 6.7
Severity: normal| Resolution:
Keywords:| Difficulty: Unknown
Os: Windows | Testcase:
Architecture: Unknown |
-+--
Comment (by simonpj):
Not obviously. `autoChart` falls under the Dreaded Monomorphism
Restriction, so its inferred type is ''not'' `forall t. Monad t = ...`.
It's not obvious what to report here. I originally added a remark to
highlight the MR point. Would that help? Something like:
{{{
Warning: Definition but no type signature for `autoChart'
Inferred type: autoChart :: t View
NB: autoChart is monomorphic in type variable t
}}}
In Trac #1256 Isaac wants to omit the `forall` in the displayed inferred
type; but that would mean there was no way to distinguish `autoChart :: t
View` from `autoChard :: forall t. t View`, which is presumably the way
Lennart read it.
Advice welcome. The issue is what is most comprehensible; implementing it
is probably easy!
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1308
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] #1256: GHC warns about omitting type signatures; would be more helpful if it supplied inferred type signature
#1256: GHC warns about omitting type signatures; would be more helpful if it supplied inferred type signature +--- Reporter: guest|Owner: Type: feature request | Status: closed Priority: low |Milestone: 6.8 Component: Compiler | Version: 6.6 Severity: minor| Resolution: fixed Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | +--- Comment (by simonpj): See #1308 for why omitting the `forall` is far from a no-brainer. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1256 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] #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request
#1311: newtypes of unboxed types disallowed - documentation bug and/or feature request +--- Reporter: Isaac Dupree |Owner: Type: feature request | Status: new Priority: low |Milestone: _|_ Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | +--- Changes (by simonpj): * milestone: = _|_ * priority: normal = low * type: bug = feature request Comment: I can't see any reason this would be impossible in principle, but my brain is too small to figure out all the ramifications of dropping the newtypes are always boxed assumption that GHC currently makes. So for now I have simply added the restriction to the user manual, and I'll leave this suggestion as a feature request. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1311 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] #1310: confusing error message when trying to give a type-signature to an imported symbol
#1310: confusing error message when trying to give a type-signature to an
imported
symbol
-+--
Reporter: Isaac Dupree |Owner:
Type: bug | Status: closed
Priority: normal|Milestone:
Component: Compiler | Version: 6.6.1
Severity: normal| Resolution: fixed
Keywords:| Difficulty: Unknown
Os: Unknown | Testcase:
Architecture: Unknown |
-+--
Changes (by simonpj):
* resolution: = fixed
* status: new = closed
Comment:
Good point. I've improved the error messages. For imports:
{{{
Foo.hs:4:11:
Misplaced type signature: putStrLn :: String - IO ()
You cannot give a type signature for an imported value
}}}
For locals:
{{{
Foo.hs:4:11:
Misplaced type signature: p :: String - IO ()
The type signature must be given where `p' is declared
}}}
Thanks for the suggestion
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1310
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] #1204: Associated types don't work with record updates
#1204: Associated types don't work with record updates +--- Reporter: [EMAIL PROTECTED] |Owner: Type: bug | Status: closed Priority: normal |Milestone: 6.8 Component: Compiler (Type checker) | Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Records.hs Architecture: Unknown | +--- Changes (by simonpj): * resolution: = fixed * testcase: = Records.hs * status: new = closed Comment: Good bug repoort. I have finally found a moment to fix it. Should work now. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1204 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] #1308: Type signature in warning is wrong
#1308: Type signature in warning is wrong -+-- Reporter: guest |Owner: Type: bug | Status: new Priority: normal|Milestone: Component: Compiler | Version: 6.7 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Os: Windows | Testcase: Architecture: Unknown | -+-- Comment (by Isaac Dupree): Given inferred monomorphic type `Inferred type: autoChart :: t View`, I think it would be desirable to (additionally) report the type as if the M-R didn't apply, to be informative and in case this is the signature that the user wants to add. Also it would be helpful to report the actual type GHC decides upon (unless there's a type error?). I assume that GHC knows what 't' becomes after applying M-R. Now, is it useful to report `autoChart :: monomorphic t. t View`? As far as I know, it is easy to see what this could be, just based on the fully polymorphic type, especially if a specific example - the actual monomorphic type GHC has chosen - is shown as well. Hmm... is it even possible to pretend that one thing (e.g. `autochart`) is polymorphic (as suggested above), in the presence of other things falling under the monomorphism restriction? Or are there some cases where it still might not be clear what to report? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1308 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: Error compiling GHC/Num.lhs
Bas van Dijk wrote: However the build now crashes when running Haddock on Cabal: ... ifBuildable/ifBuildable Cabal setup/Setup haddock Preprocessing library Cabal-1.1.7... Running Haddock for Cabal-1.1.7... Warning: cannot use package base-2.1: ghc-pkg failed dist/build/tmp/Distribution/PreProcess.hs:Distribution/PreProcess.hs: 115:1: parse error in doc string: [TokSpecial '/',TokString build,TokSpecial ''] make[1]: *** [doc.library.Cabal] Error 1 make[1]: Leaving directory `/home/bas/development/haskell/ghc/libraries' make: *** [stage1] Error 2 Thanks, I think I've fixed this one now. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Error compiling GHC/Num.lhs
On 5/2/07, Simon Marlow [EMAIL PROTECTED] wrote:
Thanks, I think I've fixed this one now.
You did indeed, thanks!
Now I get another error when compiling main/GHC.hs:
../compiler/stage1/ghc-inplace -H64m -Onot -fasm -optc-march=athlon64
-opta-march=athlon64 -istage2/utils -istage2/basicTypes
-istage2/types -istage2/hsSyn -istage2/prelude -istage2/rename
-istage2/typecheck -istage2/deSugar -istage2/coreSyn
-istage2/specialise -istage2/simplCore -istage2/stranal
-istage2/stgSyn -istage2/simplStg -istage2/codeGen -istage2/main
-istage2/profiling -istage2/parser -istage2/cprAnalysis
-istage2/ndpFlatten -istage2/iface -istage2/cmm -istage2/nativeGen
-istage2/ghci -Istage2 -DGHCI -package template-haskell
-DGHCI_TABLES_NEXT_TO_CODE -threaded -package readline -DUSE_READLINE
-cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser -package
unix -package Cabal -ignore-package lang -recomp -Rghc-timing -Onot
-fasm -H16M '-#include cutils.h' -package-name ghc-6.7.20070502
-fgenerics-c main/GHC.hs -o stage2/main/GHC.o -ohi
stage2/main/GHC.hi
main/GHC.hs:2223:50:
Couldn't match expected type `InteractiveContext'
against inferred type `[Name]'
In the sixth argument of `ResumeHandle', namely `names'
In the expression:
ResumeHandle
breakMVar statusMVar final_names final_ic resume_ic names
In the definition of `res':
res = ResumeHandle
breakMVar statusMVar final_names final_ic resume_ic names
main/GHC.hs:2230:54:
Couldn't match expected type `InteractiveContext'
against inferred type `[Name]'
In the `hsc_IC' field of a record
In the second argument of `writeIORef', namely
`hsc_env {hsc_IC = final_ic}'
In the expression: writeIORef ref (hsc_env {hsc_IC = final_ic})
main/GHC.hs:2270:26:
Constructor `ResumeHandle' should have 7 arguments, but has been given 6
In the pattern:
ResumeHandle breakMVar
statusMVar
final_names
final_ic
resume_ic
names
In the definition of `resume':
resume (Session ref)
(res@(ResumeHandle breakMVar
statusMVar
final_names
final_ic
resume_ic
names))
= do hsc_env - readIORef ...
writeIORef ... (...)
ghc: 119216100 bytes, 25 GCs, 6699552/13740056 avg/max bytes
residency (4 samples), 27M in use, 0.00 INIT (0.00 elapsed), 0.49 MUT
(0.54 elapsed), 0.33 GC (0.34 elapsed) :ghc
make[2]: *** [stage2/main/GHC.o] Error 1
make[2]: Leaving directory `/home/bas/development/haskell/ghc/compiler'
make[1]: *** [stage2] Error 2
make[1]: Leaving directory `/home/bas/development/haskell/ghc'
make: *** [bootstrap2] Error 2
regards,
Bas van Dijk
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Error compiling GHC/Num.lhs
Bas van Dijk wrote: On 5/2/07, Simon Marlow [EMAIL PROTECTED] wrote: Thanks, I think I've fixed this one now. You did indeed, thanks! Now I get another error when compiling main/GHC.hs: ../compiler/stage1/ghc-inplace -H64m -Onot -fasm -optc-march=athlon64 -opta-march=athlon64 -istage2/utils -istage2/basicTypes -istage2/types -istage2/hsSyn -istage2/prelude -istage2/rename -istage2/typecheck -istage2/deSugar -istage2/coreSyn -istage2/specialise -istage2/simplCore -istage2/stranal -istage2/stgSyn -istage2/simplStg -istage2/codeGen -istage2/main -istage2/profiling -istage2/parser -istage2/cprAnalysis -istage2/ndpFlatten -istage2/iface -istage2/cmm -istage2/nativeGen -istage2/ghci -Istage2 -DGHCI -package template-haskell -DGHCI_TABLES_NEXT_TO_CODE -threaded -package readline -DUSE_READLINE -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser -package unix -package Cabal -ignore-package lang -recomp -Rghc-timing -Onot -fasm -H16M '-#include cutils.h' -package-name ghc-6.7.20070502 -fgenerics-c main/GHC.hs -o stage2/main/GHC.o -ohi stage2/main/GHC.hi main/GHC.hs:2223:50: Couldn't match expected type `InteractiveContext' against inferred type `[Name]' In the sixth argument of `ResumeHandle', namely `names' In the expression: ResumeHandle breakMVar statusMVar final_names final_ic resume_ic names In the definition of `res': res = ResumeHandle breakMVar statusMVar final_names final_ic resume_ic names I believe this one is now fixed, sorry about that. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC -O2 and unsafePerformIO
Hi
I have a program (below) which when compiled with -O2 gives the result:
H:\work\supero\charcounttype log.txt | diff.exe
i am here
109
done
The process tried to write to a nonexistent pipe.
And when compiled with -O0 gives:
H:\work\supero\charcounttype log.txt | diff
i am here
109
i am here
111
done
The process tried to write to a nonexistent pipe.
It tries to read two characters, so I really do want two characters to
appear. I have tried NOINLINE, but with no effect. Any suggestions?
Thanks
Neil
---
-- The program
import System.IO.Unsafe
import System.IO
import Data.Word
import Debug.Trace
main = p_System_IO_hGetChar 1 `seq` p_System_IO_hGetChar 2 `seq` putStrLn done
{-# NOINLINE wrapIO #-}
wrapIO x = unsafePerformIO (x = return)
foreign import ccall stdio.h getchar getchar :: IO Word8
{-# NOINLINE p_System_IO_hGetChar #-}
p_System_IO_hGetChar h = trace i am here $
wrapIO (getchar = \c - print c return (if c == (-1) then 0
else chr_ c))
chr_ = fromEnum
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC -O2 and unsafePerformIO
Hello Neil,
Wednesday, May 2, 2007, 7:00:05 PM, you wrote:
{-# NOINLINE wrapIO #-}
wrapIO x = unsafePerformIO (x = return)
-fno-cse ? it's usual company for unsafePerformIO+NOINLINE :)
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC -O2 and unsafePerformIO
Hi Bulat,
Wednesday, May 2, 2007, 7:00:05 PM, you wrote:
{-# NOINLINE wrapIO #-}
wrapIO x = unsafePerformIO (x = return)
-fno-cse ? it's usual company for unsafePerformIO+NOINLINE :)
No luck, alas. A slightly tweaked version, which is slightly simpler
and still gives the same behaviour is below.
Thanks
Neil
--
main = p_System_IO_hGetChar undefined `seq` p_System_IO_hGetChar 12
`seq` putStrLn done
foreign import ccall stdio.h getchar getchar :: IO Word8
{-# NOINLINE p_System_IO_hGetChar #-}
p_System_IO_hGetChar h = trace i am here $
unsafePerformIO (getchar = \c - print c return (if c ==
(-1) then 0 else chr_ c))
chr_ = fromEnum
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC -O2 and unsafePerformIO
Hi
Thanks to dcoutts, I have now come up with an answer. I don't
understand why it works now, but not before. I do remember than
browsing either Core or STG is not a fun thing to do...
p_System_IO_hGetChar h = trace i am here $
unsafePerformIO $ getCharIO h
{-# NOINLINE getCharIO #-}
getCharIO h = do
c - getchar
print c
return $ if c == (-1) then 0 else chr_ c
Thanks
Neil
On 5/2/07, Neil Mitchell [EMAIL PROTECTED] wrote:
Hi Bulat,
Wednesday, May 2, 2007, 7:00:05 PM, you wrote:
{-# NOINLINE wrapIO #-}
wrapIO x = unsafePerformIO (x = return)
-fno-cse ? it's usual company for unsafePerformIO+NOINLINE :)
No luck, alas. A slightly tweaked version, which is slightly simpler
and still gives the same behaviour is below.
Thanks
Neil
--
main = p_System_IO_hGetChar undefined `seq` p_System_IO_hGetChar 12
`seq` putStrLn done
foreign import ccall stdio.h getchar getchar :: IO Word8
{-# NOINLINE p_System_IO_hGetChar #-}
p_System_IO_hGetChar h = trace i am here $
unsafePerformIO (getchar = \c - print c return (if c ==
(-1) then 0 else chr_ c))
chr_ = fromEnum
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Error compiling GHC/Num.lhs
On 5/2/07, Simon Marlow [EMAIL PROTECTED] wrote: I believe this one is now fixed, sorry about that. No problem. I'm now able to successfully make GHC. Thanks about that! However 'make install' fails: $ make install ... ifBuildable/ifBuildable base setup/Setup install copy directory 'dist/doc/html/base' to '/home/bas/share/ghc/doc/html/base'. ... copy dist/build/HSbase-2.1.o to /home/bas/lib/base-2.1/ghc-6.7.20070502/HSbase-2.1.o Registering base-2.1... Reading package info from .installed-pkg-config ... done. ghc-pkg: /home/bas/lib/base-2.1/ghc-6.7.20070502/include doesn't exist or isn't a directory (use --force to override) make[1]: *** [install.library.base] Error 1 make: *** [install] Error 1 The directory: /home/bas/lib/base-2.1/ghc-6.7.20070502/include indeed does not exists. What can be the problem? regards, Bas van Dijk ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC -O2 and unsafePerformIO
On Wed, 2007-05-02 at 16:33 +0100, Neil Mitchell wrote:
Hi
Thanks to dcoutts, I have now come up with an answer. I don't
understand why it works now, but not before.
main = p_System_IO_hGetChar 1
`seq` p_System_IO_hGetChar 2
`seq` putStrLn done
This is fine (though note that p_System_IO_hGetChar 1 is a constant) the
real problem is here:
{-# NOINLINE p_System_IO_hGetChar #-}
p_System_IO_hGetChar h = trace i am here $
unsafePerformIO $
getchar = \c -
print c
return (if c == (-1) then 0 else chr_ c)
You've tried to trick ghc into always calling this by passing a dummy
'h' parameter. Then 'h' is never used in the body. Note however that the
whole body of this function is a constant and so ghc can (and at -O2
does) float it out as a CAF. This means you get the side effects of
p_System_IO_hGetChar at most once.
The solution of course is to use a full data dependency like IO or ST
uses.
I do remember than browsing either Core or STG is not a fun thing to
do...
So yeah, we see the above CAFs and let floating by looking at the core.
We could do with a prettier pretty printer for core, I agree.
Duncan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: recent Windows installer for ghc head?
Thanks for the pointer. I get failures (below) when I try to make install. Does anyone have a suggestion? - Conal bash-3.2$ ./configure checking build system type... i686-pc-cygwin checking host system type... i686-pc-cygwin checking target system type... i686-pc-cygwin Which we'll further canonicalise into: i386-unknown-cygwin32 checking for perl... /cygdrive/c/Perl/bin/perl checking if your perl works in shell scripts... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether ln -s works... yes checking for sed... /usr/bin/sed checking for gcc... gcc checking for C compiler default output file name... a.exe checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... .exe checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking version of gcc... 3.4.4 checking how to run the C preprocessor... gcc -E configure: creating ./config.status config.status: creating Makefile Configuration done, ready to either 'make install' or 'make in-place'. (see README and INSTALL files for more info.) bash-3.2$ make in-place make config-pkgs bindir=`pwd`/bin/i386-unknown-cygwin32 libdir=`pwd`/lib/i386-unknown-cygwin32 datadir=`pwd`/share make[1]: Entering directory `/cygdrive/c/ghc/ghc-6.7.20070404' Configuring ghc, version 6.7.20070404.20070404, on i386-unknown-cygwin32 ... Creating a configured version of ghcprof .. /bin/sh: line 5: bin/i386-unknown-cygwin32/ghcprof: No such file or directory /bin/sh: line 6: bin/i386-unknown-cygwin32/ghcprof: No such file or directory /bin/sh: line 7: bin/i386-unknown-cygwin32/ghcprof: No such file or directory /bin/sh: line 8: bin/i386-unknown-cygwin32/ghcprof: No such file or directory /bin/sh: line 9: bin/i386-unknown-cygwin32/ghcprof: No such file or directory /bin/sh: line 10: bin/i386-unknown-cygwin32/ghcprof: No such file or directory /bin/sh: line 11: bin/i386-unknown-cygwin32/ghcprof: No such file or directory /bin/sh: line 12: bin/i386-unknown-cygwin32/ghcprof: No such file or directory chmod: cannot access `bin/i386-unknown-cygwin32/ghcprof': No such file or directory Done. Creating a configured version of ghc-asm .. /bin/sh: line 5: lib/i386-unknown-cygwin32/ghc-asm: No such file or directory /bin/sh: line 6: lib/i386-unknown-cygwin32/ghc-asm: No such file or directory /bin/sh: line 7: lib/i386-unknown-cygwin32/ghc-asm: No such file or directory /bin/sh: line 8: lib/i386-unknown-cygwin32/ghc-asm: No such file or directory /bin/sh: line 9: lib/i386-unknown-cygwin32/ghc-asm: No such file or directory /bin/sh: line 10: lib/i386-unknown-cygwin32/ghc-asm: No such file or directory /bin/sh: line 11: lib/i386-unknown-cygwin32/ghc-asm: No such file or directory /bin/sh: line 12: lib/i386-unknown-cygwin32/ghc-asm: No such file or directory chmod: cannot access `lib/i386-unknown-cygwin32/ghc-asm': No such file or directory Done. Creating a configured version of ghc-split .. /bin/sh: line 5: lib/i386-unknown-cygwin32/ghc-split: No such file or directory /bin/sh: line 6: lib/i386-unknown-cygwin32/ghc-split: No such file or directory /bin/sh: line 7: lib/i386-unknown-cygwin32/ghc-split: No such file or directory /bin/sh: line 8: lib/i386-unknown-cygwin32/ghc-split: No such file or directory /bin/sh: line 9: lib/i386-unknown-cygwin32/ghc-split: No such file or directory /bin/sh: line 10: lib/i386-unknown-cygwin32/ghc-split: No such file or directory /bin/sh: line 11: lib/i386-unknown-cygwin32/ghc-split: No such file or directory /bin/sh: line 12: lib/i386-unknown-cygwin32/ghc-split: No such file or directory chmod: cannot access `lib/i386-unknown-cygwin32/ghc-split': No such file or directory Done. Creating a configured version of package.conf .. Can't open lib/i386-unknown-cygwin32/package.conf: No such file or directory. make[1]: Leaving directory `/cygdrive/c/ghc/ghc-6.7.20070404' Finished configuring..to use, add /cygdrive/c/ghc/ghc-6.7.20070404/bin/i386-unknown-cygwin32 to your PATH. bash-3.2$ On 5/1/07, Simon Peyton-Jones [EMAIL PROTECTED] wrote: Following the snapshot distribution link on GHC's download page yields this http://www.haskell.org/ghc/dist/current/dist/ghc-6.7.20070404-i386-unknown-mingw32.tar.bz2 That seems to be a tar bundle for Windows; it's not an msi but if you unpack it you should be able to run it just fine. Simon *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Conal Elliott *Sent:* 27 April 2007 20:03 *To:* glasgow-haskell-users@haskell.org *Subject:* recent Windows installer for ghc head? I'd like to try out the new improved combination of type classes and GADTs, which I understand is only in head. Is there a recent working windows installer for head? Thanks, - Conal
Re: recent Windows installer for ghc head?
Thanks for the pointer. I get failures (below) when I try to make install. Does anyone have a suggestion? - Conal if you are talking about the good old-fashioned snapshots, there shouldn't be any configuration or install, just untar where you need it? claus bash-3.2$ ./configure checking build system type... i686-pc-cygwin checking host system type... i686-pc-cygwin checking target system type... i686-pc-cygwin Which we'll further canonicalise into: i386-unknown-cygwin32 checking for perl... /cygdrive/c/Perl/bin/perl checking if your perl works in shell scripts... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether ln -s works... yes checking for sed... /usr/bin/sed checking for gcc... gcc checking for C compiler default output file name... a.exe checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... .exe checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking version of gcc... 3.4.4 checking how to run the C preprocessor... gcc -E configure: creating ./config.status config.status: creating Makefile Configuration done, ready to either 'make install' or 'make in-place'. (see README and INSTALL files for more info.) bash-3.2$ make in-place make config-pkgs bindir=`pwd`/bin/i386-unknown-cygwin32 libdir=`pwd`/lib/i386-unknown-cygwin32 datadir=`pwd`/share make[1]: Entering directory `/cygdrive/c/ghc/ghc-6.7.20070404' Configuring ghc, version 6.7.20070404.20070404, on i386-unknown-cygwin32 ... Creating a configured version of ghcprof .. /bin/sh: line 5: bin/i386-unknown-cygwin32/ghcprof: No such file or directory /bin/sh: line 6: bin/i386-unknown-cygwin32/ghcprof: No such file or directory /bin/sh: line 7: bin/i386-unknown-cygwin32/ghcprof: No such file or directory /bin/sh: line 8: bin/i386-unknown-cygwin32/ghcprof: No such file or directory /bin/sh: line 9: bin/i386-unknown-cygwin32/ghcprof: No such file or directory /bin/sh: line 10: bin/i386-unknown-cygwin32/ghcprof: No such file or directory /bin/sh: line 11: bin/i386-unknown-cygwin32/ghcprof: No such file or directory /bin/sh: line 12: bin/i386-unknown-cygwin32/ghcprof: No such file or directory chmod: cannot access `bin/i386-unknown-cygwin32/ghcprof': No such file or directory Done. Creating a configured version of ghc-asm .. /bin/sh: line 5: lib/i386-unknown-cygwin32/ghc-asm: No such file or directory /bin/sh: line 6: lib/i386-unknown-cygwin32/ghc-asm: No such file or directory /bin/sh: line 7: lib/i386-unknown-cygwin32/ghc-asm: No such file or directory /bin/sh: line 8: lib/i386-unknown-cygwin32/ghc-asm: No such file or directory /bin/sh: line 9: lib/i386-unknown-cygwin32/ghc-asm: No such file or directory /bin/sh: line 10: lib/i386-unknown-cygwin32/ghc-asm: No such file or directory /bin/sh: line 11: lib/i386-unknown-cygwin32/ghc-asm: No such file or directory /bin/sh: line 12: lib/i386-unknown-cygwin32/ghc-asm: No such file or directory chmod: cannot access `lib/i386-unknown-cygwin32/ghc-asm': No such file or directory Done. Creating a configured version of ghc-split .. /bin/sh: line 5: lib/i386-unknown-cygwin32/ghc-split: No such file or directory /bin/sh: line 6: lib/i386-unknown-cygwin32/ghc-split: No such file or directory /bin/sh: line 7: lib/i386-unknown-cygwin32/ghc-split: No such file or directory /bin/sh: line 8: lib/i386-unknown-cygwin32/ghc-split: No such file or directory /bin/sh: line 9: lib/i386-unknown-cygwin32/ghc-split: No such file or directory /bin/sh: line 10: lib/i386-unknown-cygwin32/ghc-split: No such file or directory /bin/sh: line 11: lib/i386-unknown-cygwin32/ghc-split: No such file or directory /bin/sh: line 12: lib/i386-unknown-cygwin32/ghc-split: No such file or directory chmod: cannot access `lib/i386-unknown-cygwin32/ghc-split': No such file or directory Done. Creating a configured version of package.conf .. Can't open lib/i386-unknown-cygwin32/package.conf: No such file or directory. make[1]: Leaving directory `/cygdrive/c/ghc/ghc-6.7.20070404' Finished configuring..to use, add /cygdrive/c/ghc/ghc-6.7.20070404/bin/i386-unknown-cygwin32 to your PATH. bash-3.2$ On 5/1/07, Simon Peyton-Jones [EMAIL PROTECTED] wrote: Following the snapshot distribution link on GHC's download page yields this http://www.haskell.org/ghc/dist/current/dist/ghc-6.7.20070404-i386-unknown-mingw32.tar.bz2 That seems to be a tar bundle for Windows; it's not an msi but if you unpack it you should be able to run it just fine. Simon *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Conal Elliott *Sent:* 27 April 2007 20:03 *To:* glasgow-haskell-users@haskell.org *Subject:* recent Windows installer for ghc head? I'd like to try out the new improved
Re: Error compiling GHC/Num.lhs
[Note: Sorry if this is a duplicate. I originally sent the patches inline in the mail, but the resulting mail grew rather big and is awaiting moderators approval now. (moderators: no need to approve it)] Bas van Dijk wrote: On 5/2/07, Simon Marlow [EMAIL PROTECTED] wrote: I believe this one is now fixed, sorry about that. No problem. I'm now able to successfully make GHC. Thanks about that! However 'make install' fails: $ make install ... ifBuildable/ifBuildable base setup/Setup install copy directory 'dist/doc/html/base' to '/home/bas/share/ghc/doc/html/base'. ... copy dist/build/HSbase-2.1.o to /home/bas/lib/base-2.1/ghc-6.7.20070502/HSbase-2.1.o Registering base-2.1... Reading package info from .installed-pkg-config ... done. ghc-pkg: /home/bas/lib/base-2.1/ghc-6.7.20070502/include doesn't exist [...] I'm sorry, that's my fault. I have two patches that should fix this: One for libraries/Cabal, http://int-e.home.tlink.de/haskell/Cabal-fix-installIncludeFiles.patch and another for libraries/base: http://int-e.home.tlink.de/haskell/base-install-includes.patch The semantics for the includes: and install-includes: fields in cabal files has changed; the patch against base adds an install-includes field to the base.cabal file that uses the new semantics. I was going to send this patch in now anyway. I'm afraid I missed the interaction of the install directory and the package registration, and obviously I didn't test this properly. So I revert the behaviour back to always creating the include directory. Bertram ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] Haskell fast (?) arrays
Federico Squartini wrote: Thanks for the hints. It's a pity that (as far as I know) no one has written a tutorial on those techniques, because I think it would be appreciated. Some of them are quite involved and learning them just by reading code is very time consuming. There's the Performance section of the Haskell wiki: http://haskell.org/haskellwiki/Performance Some of the techniques are described there, but by no means all. It's a good place to put knowledge that you acquire while doing these experiments, though. FWIW I vaguely recall there was a performance problem with initialising IOUArrays that we haven't got around to fixing yet. If you can narrow down the test case, then please submit a bug report. Cheers, Simon ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
FW: [Haskell-cafe] RE:Cross-over from Haskell.org [Haskell] Re: Newbie: what are the advantages of Haskell?
These Haskell lists seems to have a problem of having to many elitist pricks on it admittedly I am probably in this category as well so I will help you guys and by eliminating one prick and remove myself from the list good luck with the rest of them Troy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 01, 2007 5:35 PM To: Taillefer, Troy (EXP) Subject: Re: [Haskell-cafe] RE:Cross-over from Haskell.org [Haskell] Re: Newbie: what are the advantages of Haskell? Taillefer, Troy (EXP) wrote: I really dislike Perl as a programming language but I have to strongly disagree about your statements about CPAN and the quality of its contents. Consider Sturgeon's Law: 90% of everything is crap. It's true of CPAN, too, which is only a stand in for any large collection of libraries. We don't gain anything from wrapping or reimplementing the crap, therefore, if you like some particular library, you should ask for *that* library, nor for more libraries in general. no need to get all touchy-feely about this. Perl is popular so it must have some merit. So is Crack. I still won't smoke it, though. I don't subscribe to the flawed reasoning that Perl Hackers just don't know any better or that they are dumb, or intellectual inferior in some way. Well, I didn't make that point in the mail you're replying to, but I subscribe to it. Perl *is* unadultered crap, it *is* a bad idea carried to perfection, a shoddy language that teaches bad habits, rewards stupidity and encourages you to attack every problem with the same blunt old tool, the regex, and most Perl Hackers, those who voluntarily use it to solve actual problem, *are* in fact dumb, don't want to know any better and are resistant to education. Perl is in every way the opposite of Haskell, and I happen to like Haskell. Imitating Perl is even worse than imitating C++. ...but I don't even wan't to discuss this, neither in private nor on a mailing list. If you want to argue, ask Google for Erik Naggum; nothing more needs to be said about it. ... I am pro choice. And I *choose* to belittle Perl Hackers as much as I want. If that stops anyone from using Perl, it's their *choice*. And you can *choose* to hate me for belittling you, jackass. Political Correctness is even more misguided than Perl. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: refactoring, catamorphism, termination of programs
Dear Stefan, thanks for your comment. E.g. the Coq papers define its elimination constructs either as a catamorphism, or as a combination of casefix, where the recursive calls are appropriately restricted to pass subterms as arguments. if we replace the subterm ordering by some other well-founded ordering on terms, and let a tool look for this ordering, then we get the classical approach (that is used for term rewriting systems). my point is that most (Haskell) programs don't require this because they are (or should be) just primitive recursive functions (catamorphisms) over data structures, and in fact they should be presented as such (explicit recursion should be replaced by the catamorphism), and I want a tool to do that replacement. Sure, this will not solve all Haskell termination problems. I just want to see how many are left (e.g. from the functions in the Prelude, or in my programs). If you want to contribute further to the discussion, then please do so via http://groups.google.com/group/fp-termination (I don't want to clutter the haskell mailing list, but I want to have the discussion in some public place.) Best regards, -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- http://www.imn.htwk-leipzig.de/~waldmann/ --- ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: refactoring, catamorphism, termination of programs
On 2 May 2007, at 12:18, Johannes Waldmann wrote: If you want to contribute further to the discussion, then please do so via http://groups.google.com/group/fp-termination (I don't want to clutter the haskell mailing list, but I want to have the discussion in some public place.) Isn't Haskell Cafe exactly the place for that discussion? (As opposed to the Haskell mailing list.) Good luck with the discussion. Someone mentioned DrHylo; that's built on the work of Hu, Onoue and others from Tokyo on a system called Hylo: http://www.ipl.t.u-tokyo.ac.jp/~onoue/hylo/ See also Alberto Pardo's HFusion: http://www.fing.edu.uy/inco/proyectos/fusion/ Jeremy [EMAIL PROTECTED] Oxford University Computing Laboratory,TEL: +44 1865 283508 Wolfson Building, Parks Road, FAX: +44 1865 283531 Oxford OX1 3QD, UK. URL: http://www.comlab.ox.ac.uk/oucl/people/jeremy.gibbons.html ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] refactoring, catamorphism, termination of programs
Hi Jahannes, I don't want to make a big research project out of this, rather I think of quickly putting together a prototype that proves the concept. I figure it could be distilled from some existing refactoring suite, or be manufactured from existing building blocks. Well, HaRe -- the Haskell refactorer -- offers a full API for building transformations and refactorings for the full Haskell 98 standard. http://www.cs.kent.ac.uk/projects/refactor-fp/hare.html A new release will hopefully be released very soon (even in the next few days) which will be compatible with ghc-6.6.1. The releases on our refactoring page currently only work with GHC-6.4.*. E.g. Language.Haskell.* from the ghc libs, and perhaps Typing Haskell in Haskell? http://citeseer.ist.psu.edu/424440.html HaRe also uses the GHC API and type checker, with parts of the HaRe API extended to retrieve type information from GHC on abritrary expressions and functions. Kind regards, Chris. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re[2]: [Haskell] Haskell fast (?) arrays
Hello Federico, Tuesday, May 1, 2007, 7:23:45 PM, you wrote: Thanks for the hints. It's a pity that (as far as I know) no one has written a tutorial on those techniques, except for me :) - http://haskell.org/haskellwiki/Modern_array_libraries -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re[2]: [Haskell] Haskell fast (?) arrays
Hello Donald, Wednesday, May 2, 2007, 7:38:25 AM, you wrote: Here's an improved version, using Foreign.Marshal.Array. I spent about 2 minutes inspecting the core, as well. i think that using just the ! on array arguments should be enough. there is nothing magic in usafeReadArray calls, they should be the same as peek -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Newbie: fix
Hello, could someone please explain why fix is necessary here: fix (\f l - if null l then [] else let (s,e) = break (==' ') l in s:f (drop 1 e)) Source: http://www.haskell.org/haskellwiki/Blow_your_mind Thanks. phiroc ---BeginMessage--- Hello, could someone please explain why fix in necessary here: fix (\f l - if null l then [] else let (s,e) = break (==' ') l in s:f (drop 1 e)) Source: http://www.haskell.org/haskellwiki/Blow_your_mind Thanks. phiroc ---End Message--- Hello, could someone please explain why fix in necessary here: fix (\f l - if null l then [] else let (s,e) = break (==' ') l in s:f (drop 1 e)) Source: http://www.haskell.org/haskellwiki/Blow_your_mind Thanks. phiroc ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Applications and libraries
Hello, the Haskell homepage contains a link “Applications and libraries” but the page it links to is called “Libraries and tools”. Since the title “Applications and libraries” is better (A tool is an application and the page is also about non-tool applications.), I changed its name. I had to discover that there are lots of subpages of “Libraries and tools”. Is it okay to rename these too? Best wishes, Wolfgang ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Newbie: fix
On 02/05/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hello, could someone please explain why fix is necessary here: fix (\f l - if null l then [] else let (s,e) = break (==' ') l in s:f (drop 1 e)) Source: http://www.haskell.org/haskellwiki/Blow_your_mind Because you're writing a recursive function. If you just had: if null l then [] else let (s,e) = break (==' ') l in s:XXX (drop 1 e) Then what goes in place of 'XXX'? There's no name for this particular bit of code, so you can't call it. Using fix allows you to attach a name to an arbitrary expression so that you can call it recursively. The following would work exactly the same: words :: String - [String] words l = if null l then [] else let (s,e) = break (==' ') l in s:words (drop 1 e) -- -David House, [EMAIL PROTECTED] ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANN: HDBC 1.1.0
Hi, I'm pleased to announce the 1.1.0 release of HDBC and the three primary backends. The big news is an API change, implemented by Peter Thiemann, that transforms the primary connection object from a record to a typeclass. This allows database backends to define their own private functions that provide access to database-specific features. The Sqlite3 backend uses this capability to provide control over its locking mechanism. HDBC can be downloaded from http://software.complete.org/hdbc The backends are available from the index at http://software.complete.org/ -- John ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Applications and libraries
Yes. I often do this when people miss the guidelines. After renaming, some links become redirects, but people usually clean those up eventually. (It can be done by clicking on the What links here on the WIKI page and then changing the links it finds.) On Wed, 2007-05-02 at 17:55 +0200, Wolfgang Jeltsch wrote: Hello, the Haskell homepage contains a link “Applications and libraries” but the page it links to is called “Libraries and tools”. Since the title “Applications and libraries” is better (A tool is an application and the page is also about non-tool applications.), I changed its name. I had to discover that there are lots of subpages of “Libraries and tools”. Is it okay to rename these too? Best wishes, Wolfgang ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell -- Brett G. Giles Grad Student - Formal Methods [EMAIL PROTECTED] http://pages.cpsc.ucalgary.ca/~gilesb ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: Polymorphic strict fields
Iavor Diatchki wrote: Notice, furthermore, that the behavior of such constructors may be a bit unexpected when combined with overloading. Consider, for example, the following declarations: data T = T !(forall a. Eq a = a) test = seq (T undefined) True In GHC 6.6 ``test`` evaluets to ``True`` because ``undefined`` is converted to a function that expects its implict evidence argument. It's the same with functions: myseq :: (forall a. Eq a = a) - b - b myseq = seq myseq undefined True == True -- Ashley Yakeley ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
[Haskell-cafe] ANN: FileManip 0.1, an expressive file manipulation library
The FileManip package provides expressive functions and combinators for searching, matching, and manipulating files. It provides three modules. System.FilePath.Find lets you search a filesystem hierarchy efficiently: find always (extension ==? .rb) = mapM_ remove System.FilePath.GlobPattern lets you perform glob-style pattern matching, without going through a regexp engine: foo.c ~~ *.c == True System.FilePath.Manip lets you rename files procedurally, edit files in place, or save old copies as backups: modifyWithBackup (. bak) (unlines . map (takeWhile (/= ',')) . lines) myPoorFile.csv ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: FileManip 0.1, an expressive file manipulation library
Bryan O'Sullivan wrote: The FileManip package provides expressive functions and combinators for searching, matching, and manipulating files. As seems to be my habit, I forgot something important, namely where to get FileManip from. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/FileManip-0.1 Online docs: http://darcs.serpentine.com/filemanip/dist/doc/html/FileManip/ Darcs repo: darcs get http://darcs.serpentine.com/filemanip ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: FileManip 0.1, an expressive file manipulationlibrary
The FileManip package provides expressive functions and combinators for searching, matching, and manipulating files. hi Brian, i'm a fan of find | xargs, so a portable haskell replacement unencumbered by viral licenses would be very welcome. i have no intention to participate in yet-another-licencing-discussion, i would just like to ask whether those limitations of your offering are an accident or intended? claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal, lib and exe in one
Duncan Coutts wrote: On Tue, 2007-05-01 at 22:29 +0100, Magnus Therning wrote: So if foo.hs is in test-src and Foo/Bar.hs is in src then I think you just need: hs-source-dirs: test-src, src No, that's not enough, I also have to add the following lines to make the executable compile and link: extensions: ForeignFunctionInterface c-sources: csrc/ptrace.c That is, I end up compiling the library a second time! Can't I get the executable to link against the library that was just created? I was just expecting to not have to repeat myself in the cabal file. Not such a strange thing to expect from a build system, I think :-) Yes this is an interesting question about what it means to have programs in the same cabal package as an executable. Currently having a executable and a library inside a cabal package is not the same thing as having a library package and separate package that contains only that executable. The difference is that when the executable is in the same cabal package it merely has access to the same modules, it doesn't 'depend' on that library package exactly. So for example it can access modules which are not exposed by the library and indeed it can compile those same modules with completely different build flags. So currently those modules will be built twice. It's not clear to me that this is the right meaning, or indeed that we should allow multiple entries in a single .cabal file. I think it might be better to just have multiple .cabal files (possibly in the same directory). Then we could be explicit and state that an executable depends on the library or if we want to use different build flags, or use modules that are not exposed by the lib then we can do that and only in that case do we build those modules twice. Right at the front of the Cabal docs it says: However having both a library and executables in a package does not work very well; if the executables depend on the library, they must explicitly list all the modules they directly or indirectly import from that library. IMO we shouldn't allow both a library and an exe in the same package. I think I argued against this originally, and my understanding is that doing this is deprecated, although perhaps not visibly enough. Whenever the question of what to do about lib+exe packages arises, the discussion tends to spiral out of control into what we should do about collections of packages in general. For now, the simple story is that each package should have either a single library or a single executable (even multiple executables in a package is questionable; if they share some code it shoud be in a package). Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: FileManip 0.1, an expressive file manipulationlibrary
On Wed, 2007-05-02 at 09:59 +0100, Claus Reinke wrote: The FileManip package provides expressive functions and combinators for searching, matching, and manipulating files. hi Brian, i'm a fan of find | xargs, so a portable haskell replacement unencumbered by viral licenses would be very welcome. i have no intention to participate in yet-another-licencing-discussion, i would just like to ask whether those limitations of your offering are an accident or intended? http://hackage.haskell.org/cgi-bin/hackage-scripts/package/FileManip-0.1 Apparently it's under the *L*GPL not the GPL, so it's not the viral license that you were thinking of perhaps? Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hugs/nhc getting progressively slower
Hi Could we have a collective thought, and decide whether we wish to either kill off all compilers that don't start with a G, or could people at least do minimal benchmarking on Hugs? I'm not quite sure what the solution is, but it probably needs some discussion. I don't think doing minimal benchmarking on hugs will help at all unless we are prepared to act on it and I'm pretty sure anything we do to improve hugs performance will be detrimental to the GHC performance. #ifdef? Malcolm has a ByteString implementation that runs much faster under nhc, and I suspect would also run faster under Hugs. Why not have a big #ifdef around the difference? With hugs/yhc/nhc I assume the optimisation technique is simply to minimise the number of primitive reduction steps. This is really totally different. I don't see any obvious way of reconciling the two in a single implementation of an interface. Having totally different implementations of an interface for different Haskell systems is an option though it has obvious disadvantages. I can see that two implementations are undesirable, but at the moment people have a choice: to write fast GHC and slow Hugs (ByteString), or to write slow GHC and fast Hugs (String). If we could make ByteString the right answer always, then I think its a much nicer choice. For the particular case of ByteString, type ByteString=String means you roughly import Data.List - not that much additional work or maintenance. So I don't know what to do. We're not stopping out quest for high performance idiomatic code because it doesn't play nicely with interpreters. Indeed, and you shouldn't! Your quest for nice idiomatic code has saved countless programmers from low-level IO prodding, and for that we salute you! However, if you could at least give a nod in the direction of Hugs, even if you get to 50% slower than before, it keeps Hugs at least useable with the new API's. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: FileManip 0.1, an expressive filemanipulationlibrary
i'm a fan of find | xargs, so a portable haskell replacement unencumbered by viral licenses would be very welcome. i have no intention to participate in yet-another-licencing-discussion, i would just like to ask whether those limitations of your offering are an accident or intended? http://hackage.haskell.org/cgi-bin/hackage-scripts/package/FileManip-0.1 Apparently it's under the *L*GPL not the GPL, so it's not the viral license that you were thinking of perhaps? no, i browsed the license file before asking my question (no non-restrictive license needs to be longer than a page). if i wanted to use that library for anything i want to distribute, my only chance to avoid the source re-distribution and advertising clauses would be dynamic linking - the same reasons why some of us a looking forward to the gmp replacement. i'd rather roll my own find than look at the sources under the current license, which may or may not have been the author's intention when choosing that particular license. hence my question. similarly for the unix dependency - it could be inherent in the design, or an accident of the author's current platform. soapbox titleplatform-independent haskelling/title if i may take this opportunity for a message to other haskell authors: haskell makes it possible to write portable code. there are some cases where platform dependencies are unavoidable, and where one might write code for one platform, hoping that others add the branches for their platforms. there are even fewer cases where the functionality provided does not apply to other platforms. but for the majority of code, the trick is simply not to use platform-specific tricks. a small price to pay for not being exclusive. /soapbox ;-) claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 'Proper' use of the State monad
On Mon, 30 Apr 2007, Denis Volk wrote: Hello all, I am trying to make a (turn-based) game in Haskell and need to pass around quite a bit of information, so using the State monad seems most appropriate. My question is, which is a better idea: The famous Why functional programming matters contains an example for game programming. In this paper the complete tree of all possible games is constructed lazily, but only selected branches are visited. http://www.math.chalmers.se/~rjmh/Papers/whyfp.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: FileManip 0.1, an expressive filemanipulationlibrary
On Wed, 2007-05-02 at 12:00 +0100, Claus Reinke wrote: i'm a fan of find | xargs, so a portable haskell replacement unencumbered by viral licenses would be very welcome. i have no intention to participate in yet-another-licencing-discussion, i would just like to ask whether those limitations of your offering are an accident or intended? http://hackage.haskell.org/cgi-bin/hackage-scripts/package/FileManip-0.1 Apparently it's under the *L*GPL not the GPL, so it's not the viral license that you were thinking of perhaps? no, i browsed the license file before asking my question (no non-restrictive license needs to be longer than a page). if i wanted to use that library for anything i want to distribute, my only chance to avoid the source re-distribution and advertising clauses would be dynamic linking Ah ok. Well remember that we will be getting dynamic linking in future and the solution at the moment with static linking is to distribute static libraries to allow the user to relink. This allows closed source apps and complies with the LGPL. Of course if you simply don't like licenses longer than a page there's not much anyone can do to help :-) Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
FW: [Haskell-cafe] RE:Cross-over from Haskell.org [Haskell] Re: Newbie: what are the advantages of Haskell?
These Haskell lists seems to have a problem of having to many elitist pricks on it admittedly I am probably in this category as well so I will help you guys and by eliminating one prick and remove myself from the list good luck with the rest of them Troy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 01, 2007 5:35 PM To: Taillefer, Troy (EXP) Subject: Re: [Haskell-cafe] RE:Cross-over from Haskell.org [Haskell] Re: Newbie: what are the advantages of Haskell? Taillefer, Troy (EXP) wrote: I really dislike Perl as a programming language but I have to strongly disagree about your statements about CPAN and the quality of its contents. Consider Sturgeon's Law: 90% of everything is crap. It's true of CPAN, too, which is only a stand in for any large collection of libraries. We don't gain anything from wrapping or reimplementing the crap, therefore, if you like some particular library, you should ask for *that* library, nor for more libraries in general. no need to get all touchy-feely about this. Perl is popular so it must have some merit. So is Crack. I still won't smoke it, though. I don't subscribe to the flawed reasoning that Perl Hackers just don't know any better or that they are dumb, or intellectual inferior in some way. Well, I didn't make that point in the mail you're replying to, but I subscribe to it. Perl *is* unadultered crap, it *is* a bad idea carried to perfection, a shoddy language that teaches bad habits, rewards stupidity and encourages you to attack every problem with the same blunt old tool, the regex, and most Perl Hackers, those who voluntarily use it to solve actual problem, *are* in fact dumb, don't want to know any better and are resistant to education. Perl is in every way the opposite of Haskell, and I happen to like Haskell. Imitating Perl is even worse than imitating C++. ...but I don't even wan't to discuss this, neither in private nor on a mailing list. If you want to argue, ask Google for Erik Naggum; nothing more needs to be said about it. ... I am pro choice. And I *choose* to belittle Perl Hackers as much as I want. If that stops anyone from using Perl, it's their *choice*. And you can *choose* to hate me for belittling you, jackass. Political Correctness is even more misguided than Perl. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: FW: [Haskell-cafe] RE:Cross-over from Haskell.org [Haskell] Re: Newbie: what are the advantages of Haskell?
no need to get all touchy-feely about this. Perl is popular so it must have some merit. So is Crack. I still won't smoke it, though. I don't subscribe to the flawed reasoning that Perl Hackers just don't know any better or that they are dumb, or intellectual inferior in some way. most Perl Hackers, those who voluntarily use it to solve actual problem, *are* in fact dumb, don't want to know any better and are resistant to education. If you want to argue, ask Google for Erik Naggum; nothing more needs to be said about it. I *choose* to belittle Perl Hackers as much as I want. If that stops anyone from using Perl, it's their *choice*. And you can *choose* to hate me for belittling you, jackass. Ummm... Udo? Just what the fuck did you hope to accomplish with this kind of talk? Seriously, if you're channeling Erik Naggum, please stop. One socially-maladjusted-to-the-point-of-psychosis individual as a language advocate is more than enough. It's likely two too many, in fact. Reply as you see fit to bolster your ego. -- Michael T. Richter [EMAIL PROTECTED] (GoogleTalk: [EMAIL PROTECTED]) I can see computers everywhere - except in the productivity statistics! (Robert Solow) signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: FileManip 0.1, an expressive filemanipulationlibrary
Hi no, i browsed the license file before asking my question (no non-restrictive license needs to be longer than a page). if i wanted to use that library for anything i want to distribute, my only chance to avoid the source re-distribution and advertising clauses would be dynamic linking Ah ok. Well remember that we will be getting dynamic linking in future and the solution at the moment with static linking is to distribute static libraries to allow the user to relink. This allows closed source apps and complies with the LGPL. Remember than Yhc and Hugs both don't link the code together, so you can have more freedom with licenses. Of course, distributing your closed source app under Hugs isn't that sensible... Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Bloom Filter
Hi Andrew, Thanks for the comments, it really helps to have someone else's opinion on my code. I'll be applying what you've said as soon as I get a chance and I'm sure I'll have some more questions then. I'll certainly look more closely at the Set interface and try and duplicate all the parts which make sense. I've been using Darcs for a while with non-haskell projects as well as this project, however it seems that cabal strips out the darcs meta-data when making up a distribution tar file. Is there an option to have it include the darcs stuff? it seems like it could be quite useful and I can't really see a downside. If you're interested the Darcs repository is at: http://www.almostobsolete.net/bloom/ Tom On 5/1/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: G'day. Quoting tom [EMAIL PROTECTED]: I'm pretty new to Haskell, I've been working on a Bloom filter[1] implementation as a learning exercise. Excellent! Sounds like a fun test. I'd really appreciate it if someone more experienced would comment on the code. I'm sure there's plenty of places where I'm doing things in silly or overly complex ways. Sure. All in all, very well done. It works, and it looks pretty efficient. My quibbles are mostly stylistic or syntactic in nature. Please understand that the relative triviality of my quibbles is a sign that there are really no major problems. This is not a criticism, but more an advertisement: What are you using for source control here? Darcs is nice, and as a bonus, it's trivially browsable from a web browser, which saves downloading and unpacking. General comments: You overuse parentheses. A lot. Definitions like this: ary = (listArray (0, wordc-1) (repeat 0)) don't need parentheses around them, and just add to the general noise level. And (.. ((size b)-1)) is much more cleanly expressed as (.. (size b - 1)). Rather than carrying around a hash function, it might be better to use a type class: class BloomHash k where bloomHash :: k - [Word8] In wordsize: You don't need to hard-code this. You can use: wordsize = bitSize (undefined::Word32) -- Or Int, of course! bitSize is defined in Data.Bits. In splitup: I got a bit confused by the local binding names. It's usual, especially in generic code, to use xs, ys etc for a list of x and y. Something like this might be more idiomatic: splitup n xs = let (xs1, xs2) = splitAt n xs in xs1 : splitup n xs2 In indexes: (fromIntegral $ x `div` wordsize, fromIntegral $ x .. (wordsize-1)) Seems intuitively wasteful. Either use divMod or bit operations. Similarly, (hashfunc b) key is the same as hashfunc b key. But even better is: split bytecount . hashfunc b $ key That makes it obvious that it's a pipeline of functions applied to the key. This looks cool: bytes2int = foldr ((. (256 *)) . (+)) 0 . (map toInteger) but I'm not smart enough to parse it. This is both more readable and shorter: bytes2int = foldr (\x r - r*256 + fromInteger x) 0 Integer log2's are probably better done using integers only, or at least abstracted out into a separate function. In bloom: Function guards are your friends! This: bloom hf sz hc = if condition then b else error Badness is almost always better expressed as: bloom hf sz hc | condition = b | otherwise = error Badness You can now inline b. (I can see why you put it in a where clause; now you don't have to.) wordc, again, only needs integral arithmetic: wordc = ceiling ((fromIntegral a) / (fromIntegral b :: Double)) is more or less: wordc = (a+b-1) `div` b And drop the parentheses around the definition of ary. In add: Try to use function names that are close to names in existing libraries, like Data.Set. insert sounds better here. Also, rather than this: add :: Bloom a - a - Bloom a a better argument order is this: insert :: a - Bloom a - Bloom a That way, you can use it with foldr. In test: Again, probably misnamed. Data.Set calls this member. And again, arguably the wrong argument ordering. Once again, well done. Cheers, Andrew Bromage ___ 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] ANN: FileManip 0.1, an expressive filemanipulationlibrary
On May 2, 2007, at 7:00 , Claus Reinke wrote: my question. similarly for the unix dependency - it could be inherent in the design, or an accident of the author's current platform. The Haskell libraries don't currently provide a platform-independent way to do most file tests. I discovered this while working on the file test operators in Pugs: aside from some very basic tests, everything interesting requires the POSIX hierarchy (hence the unix package). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon university KF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal, lib and exe in one
On Wed, May 02, 2007 at 10:08:41 +0100, Simon Marlow wrote: [..] IMO we shouldn't allow both a library and an exe in the same package. I think I argued against this originally, and my understanding is that doing this is deprecated, although perhaps not visibly enough. Whenever the question of what to do about lib+exe packages arises, the discussion tends to spiral out of control into what we should do about collections of packages in general. For now, the simple story is that each package should have either a single library or a single executable (even multiple executables in a package is questionable; if they share some code it shoud be in a package). So, you are saying that I should split my library and its test app(s) into separate packages? That would also mean that I have to install the library before compiling and running the tests, right? Hmmm, if that's the case then I have to say that cabal won't suit me very well. Are there any options to cabal? /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] http://therning.org/magnus pgpogh7Z2G1Yr.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Hugs/nhc getting progressively slower
Hello Neil, Wednesday, May 2, 2007, 2:48:16 PM, you wrote: the right answer always, then I think its a much nicer choice. For the particular case of ByteString, type ByteString=String means you roughly import Data.List - not that much additional work or maintenance. then Binary library want to access ByteString at low level, imports Data.ByteString.Base and discovers that all great low-level functions defined there can't work with lists :) btw, i has the same problem with my Streams/AltBinary lib. once i missed one INLINE pragma and got 200x slower computation even with ghc -O2! -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: FileManip 0.1, an expressive file manipulationlibrary
Claus Reinke wrote: i have no intention to participate in yet-another-licencing-discussion, i would just like to ask whether those limitations of your offering are an accident or intended? I didn't use the LGPL by accident. However, I might be amenable to persuasion, perhaps more so if you climb down from that thing that looks awfully like a high horse from here. b ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: FileManip 0.1, an expressive filemanipulationlibrary
Claus Reinke wrote: if i wanted to use that library for anything i want to distribute, my only chance to avoid the source re-distribution and advertising clauses would be dynamic linking I believe that the magical protective properties of dynamic linking amount to no more than folklore. So you might not want to bet your proprietary farm on that distinction without first seeking legal advice. the unix dependency - it could be inherent in the design, or an accident of the author's current platform. Unfortunately, the standard libraries do not provide portable ways to check file status. Much of what's currently in the unix library would in fact compile and work fine on Windows, and could usefully be moved from unix to a more portable posix library. Regarding your soapbox, the FileManip library uses Neil Mitchell's new filepath library for precisely the purpose of portable file name handling. b ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Displaying infered type signature of 'offside' functions
Simon Peyton-Jones wrote: | I like the strong static type system of Haskell for various | reasons. One reason is, that it makes easier to understand new | code. I.e. when I read code I type ':t foo' in ghci/hugs from | time to time, to check my own idea of the type signature, if it | is not included in the source code. The principal difficulties here are to do with what do we want rather the implementation challenges. 1. Should the compiler print the type of every declaration? Should GHCi allow you to ask the type of a local decl? IMO, ghci should definitely allow you to ask. This comes up for me every time that I write any haskell code (and in general I end up hoisting local definitions to the top level, which is a real pain if there is local scope, data or type, to hoist with it). 2. How should the variables be identified? There may be many local bindings for 'f', so you can't say just :t f. Ditto if dumping all local bindings. I think this is a hard question. I was imagining some kind of hierarchical system like foo.f, in the case that f is locally defined inside foo. (Yes I know we can't easily use '.' for that). There might be might be multiple fs inside the definition of foo; indeed there might even be multiple fs nested inside each other. I suspect the happy medium, rather than a formal way of accessing every possible position, is a contextually intelligent system which allows the user to disambiguate. So 'foo.f' will show all the fs inside foo if there are, say, fewer than 5, or otherwise ask for more guidance. 3. Do you want all locally-bound variables (including those bound by lambda or case), or just letrec/where bound ones? I think 'all', myself, but there are a lot of them. All, I think. (It's very common in multiple cases for the same name to be used repeatedly at the same type; this could be conveniently indicated concisely, perhaps). 4. (This is the trickiest one.) The type of a function may mention type variables bound further out. Consider f :: [a] - Int f xs = let v = head xs in ... The type of 'v' is simply 'a'. Not 'forall a. a', but rather 'if xs:[a] then *that* a!' In general there may also be existential type variables bound by an enclosing pattern match too. I think you're going to have to give the type context, in such cases. (a :: *) |- v : a ... possibly with some way to access information about where the binding site for 'a' is. These are all user-interface issues. If some people would like to thrash out a design, and put it on the Wiki, I think there is a good chance that someone (possibly even me) would implement it That would be a good idea; my comments above do not a design make though. Can anyone else elaborate further? Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: FileManip 0.1, an expressive file manipulationlibrary
i have no intention to participate in yet-another-licencing-discussion, i would just like to ask whether those limitations of your offering are an accident or intended? I didn't use the LGPL by accident. However, I might be amenable to persuasion, perhaps more so if you climb down from that thing that looks awfully like a high horse from here. no horses here, apart from hobby-horses;-) some people write closed software, some people write freed software, some people write free software. authors choose their licenses, potential users use or stay away. the somewhat pained tone of that email was because this was a library i might have liked to use, hindered by two all too typical issues. licensing is a question i don't want to be drawn into again. it was predictable that some would be tempted to restart that thread (it has been a recurring topic not just in haskell land, but many haskellers have shown themselves flexible enough to converge, on bsd-style short-and-sweet, with about two exceptions -readline and gmp- remaining out of haskellers' control in the main libraries, and more under similar external constraints in gui contexts:-), but as for myself, i only wanted an answer to base my decision on, such as the one you've just given. portability is another matter, because here it has proven a lot easier to avoid non-portable features from the word go than to write for one's most familiar platform first, then worry about porting. where that is not yet possible or easy, those limitations need to be raised, so that they can be worked on, filepath being a recent example. don't put me on a high horse just because i'd prefer another license and am terribly tired of the discussion that tends to raise (i've been there on all sides for hugs/ghc/../programatica/hare/.. !-). claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal, lib and exe in one
I think Simon is right, and not just from a Haskell point of view. Allowing a package to contain a both a library and an executable makes the behavior of the package system less obvious. That's not to say that it can't behave correctly, but that it can't behave both correctly and in a way that is easy to understand. Yes, it makes installation of an executable package more complicated if you have to install its library package as well. But making this simple should be handled by a layer above the cabal package files (Hackage?). In my experience, the best packaging systems distinguish between dependency assurance and dependency satisfaction. For example, the Debian packaging system has two layers. dpkg deals with package files, installing a single package, and assuring that dependencies are met prior to installation. apt-get retrieves packages from repositories with their pre-reqs (based on the dependency) and invokes dpkg on the retrieved packages. I know the problem is not identical to the one cabal is trying to solve, but I think there is a great deal to be learned by looking at the Debian packaging system and its conventions. In any event, solid naming conventions could go a long way to making this obvious. If foo has a useful exposed library, but primarily consists of an executable, dividing it into foo-bin and foo-lib could serve to clarify. I would propose that, since the bulk of existing packages seem to be libraries, we use a naming convention to distinguish packages that build executables and leave the names of library packages unannotated. -r On May 2, 2007, at 2:08 AM, Simon Marlow wrote: Duncan Coutts wrote: On Tue, 2007-05-01 at 22:29 +0100, Magnus Therning wrote: So if foo.hs is in test-src and Foo/Bar.hs is in src then I think you just need: hs-source-dirs: test-src, src No, that's not enough, I also have to add the following lines to make the executable compile and link: extensions: ForeignFunctionInterface c-sources: csrc/ptrace.c That is, I end up compiling the library a second time! Can't I get the executable to link against the library that was just created? I was just expecting to not have to repeat myself in the cabal file. Not such a strange thing to expect from a build system, I think :-) Yes this is an interesting question about what it means to have programs in the same cabal package as an executable. Currently having a executable and a library inside a cabal package is not the same thing as having a library package and separate package that contains only that executable. The difference is that when the executable is in the same cabal package it merely has access to the same modules, it doesn't 'depend' on that library package exactly. So for example it can access modules which are not exposed by the library and indeed it can compile those same modules with completely different build flags. So currently those modules will be built twice. It's not clear to me that this is the right meaning, or indeed that we should allow multiple entries in a single .cabal file. I think it might be better to just have multiple .cabal files (possibly in the same directory). Then we could be explicit and state that an executable depends on the library or if we want to use different build flags, or use modules that are not exposed by the lib then we can do that and only in that case do we build those modules twice. Right at the front of the Cabal docs it says: However having both a library and executables in a package does not work very well; if the executables depend on the library, they must explicitly list all the modules they directly or indirectly import from that library. IMO we shouldn't allow both a library and an exe in the same package. I think I argued against this originally, and my understanding is that doing this is deprecated, although perhaps not visibly enough. Whenever the question of what to do about lib +exe packages arises, the discussion tends to spiral out of control into what we should do about collections of packages in general. For now, the simple story is that each package should have either a single library or a single executable (even multiple executables in a package is questionable; if they share some code it shoud be in a package). Cheers, Simon ___ 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] Displaying infered type signature of 'offside' functions
Jules Bean [EMAIL PROTECTED] wrote,
concerning the problem of getting at the types of local definitions:
Simon Peyton-Jones wrote:
The principal difficulties here are to do with what do we want
rather the implementation challenges.
1. Should the compiler print the type of every declaration? Should GHCi
allow you to ask the type of a local decl?
IMO, ghci should definitely allow you to ask. This comes up for me every
time that I write any haskell code (and in general I end up hoisting
local definitions to the top level, which is a real pain if there is
local scope, data or type, to hoist with it).
2. How should the variables be identified? There may be many local
bindings for 'f', so you can't say just :t f. Ditto if dumping all
local bindings.
I think this is a hard question. I was imagining some kind of
hierarchical system like foo.f, in the case that f is locally defined
inside foo. (Yes I know we can't easily use '.' for that). There might
be might be multiple fs inside the definition of foo; indeed there might
even be multiple fs nested inside each other.
I just wanted to contribute a PRACTICAL TRICK I use:
* If the local definition is a pattern binding
f = ...
then I just add
f :: Ordering
* If the local definition is a, say binary, function binding
f p1 p2 = ...
then I just add
f :: Float - Double - Ordering
(Type does not matter for the number of function arrows you need to put;
only the syntactic arity of the bindings matters here.)
This relies on the fact that the types Float, Double, and Ordering
very rarely occur in my code --- pick your own.
Now the compiler gives you wonderful error messages
``cannot match type `x y z' against Ordering'' ---
so you replace ``Ordering'' with ``x y z''.
If there are type variables in ``x y z''
that come from the context,
take care that you have
{-# LANGUAGE ScopedTypeVariables #-}
at the beginning of your module
(after the {-# OPTIONS ...#-} line,
which should, as a matter of style,
NOT contain -fglasgow-exts
)
and the necessary ``forall ty1 ty2 ...'' in front of your the type
in the type signature of the enclosing definition.
At the cost of a re-compilation, this works wonderfully for me,
and is much less painful than hoisting AND exporting local definitions.
But even I still have some wishes open:
* It would be nice if this worked inside the do-notation, too:
do x :: Ordering
x - m
(This is curently a syntax error.)
* It would be nice if {-# LANGUAGE ScopedTypeVariables #-}
brought in no other extensions,
and if GHC would recommend
the appropriate LANGUAGE pragmas instead of -fglasgow-exts
when it determines that the user might have wanted some extension.
(What is the right Language.Extension for GADTs?)
Wolfram
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Displaying infered type signature of 'offside' functions
On 2 May 2007 16:16:57 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: * It would be nice if this worked inside the do-notation, too: do x :: Ordering x - m (This is curently a syntax error.) I think the following works with -fglasgow-exts: do (x :: Ordering) - m -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Displaying infered type signature of 'offside' functions
* It would be nice if this worked inside the do-notation, too: do x :: Ordering x - m (This is curently a syntax error.) I think the following works with -fglasgow-exts: do (x :: Ordering) - m I know, but it is not as nice! ;-) Wolfram ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Any Haskellers in Chicagoland?
I'd love to post an ANN: Chicago Haskell user group, but i want to make sure there's more than one of me. -johnnn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Displaying infered type signature of 'offside' functions
[EMAIL PROTECTED] wrote: Jules Bean [EMAIL PROTECTED] wrote, concerning the problem of getting at the types of local definitions: Simon Peyton-Jones wrote: The principal difficulties here are to do with what do we want rather the implementation challenges. 1. Should the compiler print the type of every declaration? Should GHCi allow you to ask the type of a local decl? IMO, ghci should definitely allow you to ask. This comes up for me every time that I write any haskell code (and in general I end up hoisting local definitions to the top level, which is a real pain if there is local scope, data or type, to hoist with it). 2. How should the variables be identified? There may be many local bindings for 'f', so you can't say just :t f. Ditto if dumping all local bindings. I think this is a hard question. I was imagining some kind of hierarchical system like foo.f, in the case that f is locally defined inside foo. (Yes I know we can't easily use '.' for that). There might be might be multiple fs inside the definition of foo; indeed there might even be multiple fs nested inside each other. I just wanted to contribute a PRACTICAL TRICK I use: * If the local definition is a pattern binding f = ... then I just add f :: Ordering * If the local definition is a, say binary, function binding f p1 p2 = ... then I just add f :: Float - Double - Ordering (Type does not matter for the number of function arrows you need to put; only the syntactic arity of the bindings matters here.) This relies on the fact that the types Float, Double, and Ordering very rarely occur in my code --- pick your own. Why not just declare a type you don't use? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Displaying infered type signature of 'offside' functions
On Wed, May 02, 2007 at 04:16:57PM -, [EMAIL PROTECTED] wrote: Now the compiler gives you wonderful error messages ``cannot match type `x y z' against Ordering'' --- so you replace ``Ordering'' with ``x y z''. You could just use a rigid type variable: foo :: a foo = ... (What is the right Language.Extension for GADTs?) There is none. Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: FW: [Haskell-cafe] RE:Cross-over from Haskell.org [Haskell] Re: Newbie: what are the advantages of Haskell?
G'day all. Quoting Michael T. Richter [EMAIL PROTECTED]: Ummm... Udo? Just what the fuck did you hope to accomplish with this kind of talk? Guys, could we keep it civil on the list, please? And for the record: http://www.perl.com/pub/2000/12/advocacy.html Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: FW: [Haskell-cafe] RE:Cross-over from Haskell.org [Haskell] Re: Newbie: what are the advantages of Haskell?
ajb: G'day all. Quoting Michael T. Richter [EMAIL PROTECTED]: Ummm... Udo? Just what the fuck did you hope to accomplish with this kind of talk? Guys, could we keep it civil on the list, please? And for the record: http://www.perl.com/pub/2000/12/advocacy.html I'd like to second Andrew here. This is really not appropriate for a Haskell list -- in fact, its pretty much a first I think :/ Please keep it friendly guys ! -- Don P.S. we have some other resources on actively building and maintaining a community here: http://haskell.org/haskellwiki/Protect_the_community ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
