[GHC] #708: Error: Data.Generics / Cast
#708: Error: Data.Generics / Cast --+- Reporter: [EMAIL PROTECTED] |Owner: Type: bug| Status: new Priority: normal |Milestone: Component: Compiler | Version: 6.4.1 Severity: normal | Keywords: Os: Windows| Difficulty: Unknown Architecture: x86| --+- Hi, I am using Data.Generics and type classes to be able to compare values on their most inner type. Doing this a compiler bug occurred. I have tried to find a minimum example that crashed. The example I found may be not as minimal as you would like, though. I can not track down the exact source of the error, but the error occurs only when using the function mycast. when '''both''' implementations of mycast are removed no error occurs. I hope I made the problem clear enough, otherwise, feel free to contact me. source of the bug-example: [http://wwwhome.cs.utwente.nl/~rorijerj/Test.hs] -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/708 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] #709: Fixup too large error with -fasm on PowerPC
#709: Fixup too large error with -fasm on PowerPC
---+
Reporter: simonmar|Owner:
Type: bug | Status: new
Priority: low |Milestone:
Component: Compiler (NCG) | Version: 6.4.1
Severity: minor | Keywords:
Os: Multiple| Difficulty: Difficult (1 week)
Architecture: powerpc |
---+
The native code generator on PowerPC can sometimes generate code that
doesn't pass the assembler. The error is Fixup too large from the
assembler.
Workaround is to use {{{-fvia-C}}}.
Wolfgang Thaller says this: Conditional branches on the PowerPC only have
16 bits for the displacement. I have been reluctant to fix this so far
because it means either slowing down all conditional branches or actually
checking the size of the generated code before deciding what branch
instructions to use, which I'm afraid would add an additional pass to the
NCG.
--
Ticket URL: http://cvs.haskell.org/trac/ghc/ticket/709
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] #711: shutdownHaskell() does not return allocated memory
#711: shutdownHaskell() does not return allocated memory -+-- Reporter: [EMAIL PROTECTED] |Owner: Type: bug | Status: new Priority: normal|Milestone: Component: Compiler | Version: 6.5 Severity: normal| Keywords: Os: Multiple | Difficulty: Easy (1 hr) Architecture: Unknown | -+-- Calling shutdownHaskell() doesn't actually return the memory allocated. This can be very bad when loading and unloading DLLs many times. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/711 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
darcs: internal error: update_fwd: unknown/strange object 57
Trying to get the sources as instructed on the developer wiki: /usr/local/bin/darcs get --partial http://darcs.haskell.org/ghc This is the GHC darcs repostory (HEAD branch) For more information, visit the GHC developer wiki at http://hackage.haskell.org/trac/ghc ** darcs: internal error: update_fwd: unknown/strange object 57 Please report this as a bug to glasgow-haskell-bugs@haskell.org, or http://www.sourceforge.net/projects/ghc/ I get this error using a version of darcs I downloaded from darwinports: /opt/local/bin/darcs --version 1.0.5 (release) and a precompiled binary which I downloaded from http://cbis.anu.edu.au/misc/darcs/ /usr/local/bin/darcs --version 1.0.6 (stable branch) I am using MAC OS X 10.4 David F. Place mailto:[EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Missing Folder in ghc?
Ashley Yakeley wrote: Lemmih wrote: Did you run 'sh darcs-all get'? Oh, that wasn't in the README. Thanks. The instructions for getting GHC by darcs are here: http://cvs.haskell.org/trac/ghc/wiki/GhcDarcs It looks like you expected to build GHC by grabbing the darcs repo and reading the README file - that isn't a route I anticipated :-) I'll make sure the README gets updated at some point. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re[2]: factorial: let's get ahead of jhc! :)
Hello Simon,
Friday, February 24, 2006, 7:18:30 PM, you wrote:
1) add for/if/while to the C-- statement types list (data CmmStmt)
SM Please don't extend the C-- data type - it's very small and simple
SM because that makes it easy to manipulate and reason about.
SM I don't see why you need to, either: you can already express for, if and
SM while in C-- using conditional branches. I don't think gcc cares
SM whether you write your code using labels and goto or while/for/if, it
SM generates the same code either way.
i tested gcc (3.4.2, included in ghc 6.4.1) and my tests show that gcc
unroll loops only when a loop variable modified directly. This loop
unrolls:
loop: ...
i=i-1;
if(i1) goto loop;
and this loop don't unrolls:
loop: ...
x=i-1;
i=x;
if(i1) goto loop;
but using of while/goto don't matters. i attached fac.c that shows
this - here only fac() and fac3() are unrolled
2) implement recognizer for such simple STG functions (leaf unboxed
procedures recognizer)
3) implement the translation itself
SM By all means try this. What you want is to compile recursive functions
SM like this:
SMf() {
SM x = arg1;
SM y = arg2;
SML:
SM ... body of f, with args mapped to x y,
SM and recursive calls jumping to L passing args in x y.
SM}
SM It's quite hard to do this as a C-- to C-- optimisation, at least
SM without implementing a lot of other optimisations that we don't already
SM have. I was hoping that gcc would do it for us, if we compile code like
SM this:
SMf() {
SML:
SM ... body of f ...
SM goto L;
SM}
SM but sadly it doesn't do the whole job. (see cmmLoopifyForC in
SM cmm/CmmOpt.hs, which I added today).
SM So you might try the hacky way of doing this transformation at a higher
SM level, when generating the C-- in the first place. Putting the args in
SM temporaries is the easy bit; generating different code for the recursive
SM call will be more tricky.
i just downloaded fresh sources. cmmLoopifyForC may be not what we
need. the whole idea of transformation is to move f() parameters to
local variables, and then update contents of these local variables and
perform `goto` on each recursive call. why cmmLoopifyForC is not good
for this? only because before processing by this function the code
should look like this:
f() {
x = arg1;
y = arg2;
L:
... body of f, with args mapped to x y,
x = newarg1;
y = newarg2
jump f();
}
what is just not proper code, especially if xy is local f()
variables. so to use this function we should start from generating
improper code and anyway we should change STG-C-- code generation
i think that the discussed optimization can be done in another way:
1) in function mkFunEntryCode add check that f() is a leaf unboxed
function
2) if it's true then replace call to bindArgsToStack with generation
of x=sp[0]; y=sp[4]; L: assignments and bind corresponding args to
xy (instead of binding them to sp[0]/sp[4])
3) in cgTailCall function check that it's a self-recursive call and
in this case generate sequence x=newarg1; y=newarg2; goto L instead
of jump f(). i think that this check will require adding info about
f() to the FCode monad. so, the whole story should look like this:
CgClosure.lhs:
- ; bindArgsToStack stk_args
+ ; if isLeafUnboxedFunction cl_info body
+ then do local_args - makeNewLocals (length stk_args) -- generate xy
locals
+ generateLoads local_args stk_args-- generate x=sp[0];
y=sp[4] assignments
+ lbl - generateNewLabel -- generate L:
+ bindStkArgstoLocals local_args stk_args -- bind arguments to
xy local variables
+ modifyFCodeState (Just cl_info) lbl -- put in FCode monad
state info about
+ -- now-processed leaf
function and label
+ -- marking start of
its self-recursive cycle
+ else do bindArgsToStack stk_args
+ modifyFCodeState Nothing undefined
CgTailCall.lhs:
- = do { fun_info - getCgIdInfo fun
+ = do { fun_info - getCgIdInfo fun
+; (optimized_fun, lbl) - getFromFCodeState--
optimized_fun/=Nothing only if we
+ -- process leaf
unboxed function
- else -- Normal case, fun is boxed
+ else if (Just fun == optimized_fun) then
+ do generateAssignments-- generate x=newarg1; y=newarg2
+ generateGoto lbl -- generate goto L
+ else -- Normal case, fun is boxed
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
fac.c
Description: Binary data
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?
Did you try to link the DLL statically (i.e. via import library) and
remove the call to shutdownHaskell() ?
It worked for me (I am using Visual Studio 7, though).
Cheers,
Cyril
___
I wrapped up some Haskell modules in a Win32 DLL.
Loading the DLL dynamically (with LoadLibrary) works fine. However,
whether I actually use the library or not, the program (an application
with MFC GUI) crashes upon termination.
To find the reason for the crash, I added a new function for unloading
the DLL using FreeLibrary. FreeLibrary works fine, however the program
crashes when it returns to the main event loop. Interestingly, when I
reload the library (FreeLibrary followed by LoadLibrary) the program
continues working. However, every reload cycle causes the virtual size
of the process to increase by about 300K and the fourth reload fails
with the error message getMBlock: VirtualAlloc failed with: 8 (appears
in a message window) accompanied by many repetitions of the message
Timer proc: wait failed -- error code: 6 (appears on stderr) and
followed by the message getMBlocks: misaligned block returned (again
in a message window). Then the programm crashes.
Development takes place on Windows XP Professional using MS Visual
Studio 6.0 SP 5 and ghc 6.4.1. There are no references from the C++ side
to the Haskell heap. I build the DLL using the command
ghc --mk-dll -optdll--def -optdllFoo.def -o Foo.dll Foo.o Foo_stub.o
dllMain.c
dllMain.c looks as follows:
#include windows.h
#include Rts.h
extern void __stginit_EUzu3820zu85(void);
static char* args[] = { ghcDll, NULL };
/* N.B. argv arrays must end with NULL */
BOOL
STDCALL
DllMain(HANDLE hModule, DWORD reason, void* reserved) {
if (reason == DLL_PROCESS_ATTACH) {
/* By now, the RTS DLL should have been hoisted in, but we need
to start it up. */
startupHaskell(1, args, __stginit_Foo);
return TRUE;
} else if (reason == DLL_PROCESS_DETACH) {
shutdownHaskell();
}
return TRUE;
}
I played around with hs_exit instead of shutdownHaskell, I moved
initialization and clean-up from DllMain to my library loader, nothing
helps. Even doing no clean-up whatsoever does not change the behaviour.
Any ideas?
Michael
--
Message: 2
Date: Wed, 01 Mar 2006 12:06:27 -0800
From: Ashley Yakeley [EMAIL PROTECTED]
Subject: Re: Missing Folder in ghc?
To: glasgow-haskell-users@haskell.org
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Simon Marlow wrote:
The configure script has mis-detected your GHC version somehow. Could
you look through the output of configure, and see what it says about
GHC?
Nothing special:
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
Canonicalised to: i386-unknown-linux
checking for path to top of build tree...
/home/ashley/Projects/Collected/Haskell/ghc
checking for ghc... /usr/bin/ghc
checking version of ghc... 6.4
checking for nhc... no
checking for nhc98... no
checking for hbc... no
Also look in mk/config.mk, at the value of GhcCanonVersion.
GHC = /usr/bin/ghc
GhcDir = $(dir $(GHC))
GhcVersion = 6.4
GhcMajVersion = 6
GhcMinVersion = 4
GhcPatchLevel = 0
# Canonicalised ghc version number, used for easy (integer) version
# comparisons. We must expand $(GhcMinVersion) to two digits by
# adding a leading zero if necessary:
ifneq $(findstring $(GhcMinVersion), 0 1 2 3 4 5 6 7 8 9)
GhcCanonVersion = $(GhcMajVersion)0$(GhcMinVersion)
else
GhcCanonVersion = $(GhcMajVersion)$(GhcMinVersion)
endif
Maybe you switched GHC versions but didn't reconfigure?
I think the problem is that I called autoconf etc. before I called
darcs-all get, but not after. Calling autoreconf fixed the problem.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
--make keep going?
is there an option to get ghc to keep going if it encounters an error building a file with --make? as in, I'd like it to continue compiling as much as it can only skipping what actually depends on the file that failed rather than completly aborting everything. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Missing Folder in ghc?
Simon Marlow wrote: It looks like you expected to build GHC by grabbing the darcs repo and reading the README file - that isn't a route I anticipated :-) I'll make sure the README gets updated at some point. Thanks. Now the build process gets stuck here: ==fptools== make all -wr -f Makefile; in /home/ashley/Projects/Collected/Haskell/ghc/libraries/base rm -f GHC/Base.o; if [ ! -d GHC/Base_split ]; then mkdir GHC/Base_split; else /usr/bin/find GHC/Base_split -name '*.o' -print | xargs rm -f __rm_food; fi; ../../ghc/compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude -#include HsBase.h -funbox-strict-fields -ignore-package base -O -Rghc-timing -fgenerics -fgenerics -split-objs-c GHC/Base.lhs -o GHC/Base.o -ohi GHC/Base.hi The compiler just sits and does nothing for hours. It doesn't even use any CPU, it seems to be just waiting for something (in state S+ according to ps). I tried running the command with -H64m, but that didn't help. With -v it gives this: Glasgow Haskell Compiler, Version 6.5, for Haskell 98, compiled by GHC version 6.4 Using package config file: /home/ashley/Projects/Collected/Haskell/ghc/ghc/driver/package.conf.inplace Using package config file: /home/ashley/.ghc/i386-linux-6.5/package.conf package haskell98-1.0 will be ignored due to missing dependencies: base-1.0 package template-haskell-1.0 will be ignored due to missing dependencies: base-1.0 package unix-1.0 will be ignored due to missing dependencies: base-1.0 package Cabal-1.1.4 will be ignored due to missing dependencies: base-1.0 package parsec-2.0 will be ignored due to missing dependencies: base-1.0 package haskell-src-1.0 will be ignored due to missing dependencies: base-1.0 package network-1.0 will be ignored due to missing dependencies: base-1.0 package QuickCheck-1.0 will be ignored due to missing dependencies: base-1.0 package HUnit-1.1 will be ignored due to missing dependencies: base-1.0 package mtl-1.0 will be ignored due to missing dependencies: base-1.0 package fgl-5.2 will be ignored due to missing dependencies: base-1.0 package stm-1.0 will be ignored due to missing dependencies: base-1.0 package readline-1.0 will be ignored due to missing dependencies: base-1.0 Hsc static flags: -static *** Literate pre-processor: /home/ashley/Projects/Collected/Haskell/ghc/ghc/utils/unlit/unlit -h GHC/Base.lhs GHC/Base.lhs /tmp/ghc28900_0.lpp *** C pre-processor: gcc -E -undef -traditional -v -I include -I /home/ashley/Projects/Collected/Haskell/ghc/ghc/includes -D__HASKELL1__=5 -D__GLASGOW_HASKELL__=605 -D__HASKELL98__ -D__CONCURRENT_HASKELL__ -Dlinux_BUILD_OS=1 -Di386_BUILD_ARCH=1 -Dlinux_HOST_OS=1 -Di386_HOST_ARCH=1 -x c /tmp/ghc28900_0.lpp -o /tmp/ghc28900_0.hscpp Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr --with-gxx-include-dir=/usr/include/c++/4.0.2 --enable-shared --with-system-zlib --libexecdir=/usr/lib --enable-nls --without-included-gettext --enable-threads=posix --program-suffix=-4.0 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr --disable-werror --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9) /usr/lib/gcc/i486-linux-gnu/4.0.2/cc1 -E -traditional-cpp -quiet -v -I include -I /home/ashley/Projects/Collected/Haskell/ghc/ghc/includes -D__HASKELL1__=5 -D__GLASGOW_HASKELL__=605 -D__HASKELL98__ -D__CONCURRENT_HASKELL__ -Dlinux_BUILD_OS=1 -Di386_BUILD_ARCH=1 -Dlinux_HOST_OS=1 -Di386_HOST_ARCH=1 /tmp/ghc28900_0.lpp -o /tmp/ghc28900_0.hscpp -mtune=i486 -undef ignoring nonexistent directory /usr/local/include/i486-linux-gnu ignoring nonexistent directory /usr/include/i486-linux-gnu #include ... search starts here: #include ... search starts here: include /home/ashley/Projects/Collected/Haskell/ghc/ghc/includes /usr/local/include /usr/lib/gcc/i486-linux-gnu/4.0.2/include /usr/include End of search list. *** Checking old interface for GHC.Base: *** Parser: *** Renamer/typechecker: *** Desugar: Result size = 2851 *** Simplify: It stops and waits there. This is my machine: $ uname -a Linux rollright 2.6.12-10-386 #1 Mon Feb 13 12:13:15 UTC 2006 i686 GNU/Linux ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Missing Folder in ghc?
On 2-Mar-06, at 7:35 PM, Ashley Yakeley wrote: Thanks. Now the build process gets stuck here: I ran into this yesterday, but didn't have time to look into it; today, ./darcs-all pull seems to have fixed it. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] Re: Implicit Parameters
On Wed, Mar 01, 2006 at 11:53:42AM +, Simon Marlow wrote: something along these lines is likely to be quite straightforward to implement, won't require any changes to the type system, and gives you a useful form of implicit parameters without any of the drawbacks. The main difference from implicit parameters would be that thread-local variables would be restricted to the IO monad. These two paragraphs sound _heavily_ contradictory to me. The point of implicit parameters (fluids or just parameters in Scheme) is that they provide a controlled form of dynamic scoping without introducing any stateful mess. Implicit parameters are useful in plain purely functional code just to make certain values customizable without forcing them to be propagated explicitely everywhere even though default values are ok most of the time. Restricting them to the IO monad would severely undermine their purpose. Now, I wonder whether we really really really need to track implicit parameters in the type system. After all, exceptions, too, introduce a certain amount of impurity yet they work just fine in pure code. Couldn't the same kind of semantic trickery that was used in the imprecise exceptions paper also be applied to Scheme-style parameter objects? Lauri ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Implicit Parameters
Hello Lauri, Thursday, March 2, 2006, 3:25:31 PM, you wrote: LA Now, I wonder whether we really really really need to track implicit LA parameters in the type system. After all, exceptions, too, introduce a there is also another way - allow partial function signatures -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: Keep the present Haskell record system!
On Wed, Mar 01, 2006 at 11:00:41AM +, Malcolm Wallace wrote: Thus, although I agree that none is ready for inclusion in Haskell-prime, I think we do need some mechanism for experimental records to be tried out in real Haskell implementations before the Haskell-double-prime committee starts its work. Perhaps, taking the extensions-layering idea, we could say that the current named-fields are encapsulated as an extension that is part of the standard. Implementations could then introduce a flag to switch off this particular extension (current records) in conjunction with flags to switch on experimental replacements. This would give a certain flexibility for users to play with different systems, and the breaking of compatibility would be explicitly notated, either by the build options, or using a proposal like ticket #94. My suggestion is that we separate out everything from the Report to do with named-field records into something like a self-contained addendum. Whilst still an official part of the language standard, it might also be marked as a possibility for future removal. This would make it clear what parts of the language could be changed (or re-used without conflict) in an alternative records system. Sounds like a good idea to me, if it can be done. We might want to do the same thing with FDs (assuming we come up with a form good enough for Haskell'). There will be a question of how contagious these extensions are, e.g. am I using extension X if I import a module that uses it? ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: relaxed instance rules spec (was: the MPTC Dilemma (pleasesolve))
On Thu, Mar 02, 2006 at 12:03:59PM -, Claus Reinke wrote: The way I interpret FDs implies that they introduce a systematic space leak into the inference process: if any stage in the inference uses *any* constraint with a class which is subject to an FD, that results in an additional bit of information about that class' FD. and we *cannot* throw that bit of information away unless we know that we will never need to refer to it in the remainder of the inference chain. But with the current system you can throw it away, because it's implied by the FDs on the classes in the context. A system where that was not the case would be significantly more complex than the current FDs, which I think disqualifies it for Haskell'. The original FDs have the property that the set of valid ground predicates is determined by the instance declarations alone, and is unaffected by the addition of FDs. The FDs merely imply that some predicates can never be valid, even if other instances are added later, and thus justify type improvement and reduced ambiguity. I think this separation makes them much easier to think about, and we should be cautious about losing it. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
RE: [Haskell-cafe] Template haskell instance checking
Not at the moment, I'm afraid, but it's the kind of question that TH ought to be able to answer. I could offer guidance if someone wanted to implement it. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of | heatsink | Sent: 02 March 2006 00:55 | To: haskell-cafe@haskell.org | Subject: [Haskell-cafe] Template haskell instance checking | | Is there a way, in template haskell, to find out what instance declarations | exist? I'm not trying to accomplish anything specific right now, but I can | see two potential uses for this. One is to emit compile-time error messages | from TH code which would be more informative than the typechecker's output. | The other is to produce TH functions that conditionally generate code | depending on the instances satisfied by their arguments. | | I offer the following as a motivational example. Suppose you want to write | an extensible library to handle files for, e.g., image data: | | class FileFormat a where | formatName :: a - String | read :: Handle - IO a | write :: Handle - a - IO () | | instance FileFormat TheStandardFormat where | | class (FileFormat a, FileFormat b) = Convert a b where | convert :: a - b | | Now it would be nice to generate instances of (Convert a TheStandardFormat, | Convert TheStandardFormat b) = Convert a b _except_ where there is an | explicit definition for (Convert a b). AFAIK, there's no way to do this at | present, but it seems like something that could be computed in TH. | | --heatsink | | | ___ | 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] conditional code, was: Template haskell instance checking
heatsink wrote: Is there a way, in template haskell, to find out what instance declarations exist? I'm not trying to accomplish anything specific right now, but I can see two potential uses for this. One is to emit compile-time error messages from TH code which would be more informative than the typechecker's output. The other is to produce TH functions that conditionally generate code depending on the instances satisfied by their arguments. Apologies for becoming off-topic now, I've got nothing against template haskell (TH), on the contrary, it is a great device to increase genericity. But I want to warn about conditional code, because this may become a nightmare to maintain. I.e. we (at Bremen) have (few) bits in TH that check if we run under windows or unix (but no one knows if the windows part is still working). Furthermore we support a few older (still recent) ghc versions with conditional code (like ghc itself can be bootstrapped with different older version). Plugging in various libraries using Cabal is a nice feature, but imagine if you would start to program depending on the currently installed packages (and visible instances)! (Fortunately, this would be hard to do currently.) So (despite cabal and the desire for a minimal kernel) I hope that ghc will continue to supply a large number of more or less standard packages or modules that can safely be expected to exist in (almost) every installation. (Therefore I've suggested to keep Data.Set and Data.Map in the base package, but another standard package may be fine, too). Otherwise truly application specific 3rd party cabal packages may all come with their own Prelude extensions rather than reusing increasingly solidified Haskell basics (that are hopefully not disputed too much by the design of Haskell-Prime). If you agree with me, great, ignore this posting. Respectfully Christian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Layout rule (was Re: PrefixMap: code review request)
I wrote: I just installed Visual Haskell 0.1, and when I type in the editor, CPU usage rises to about 70% and there's a noticeable delay before each character appears on the screen. This is no longer happening, so I guess I ran afoul of a bug. -- Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Help with Type Class
Am Mittwoch, 1. März 2006 20:20 schrieben Sie: Daniel, data Array i e = Array i i shouldn't the element type appear here? Typo: data Array i e = Array i i [e] --mockup with list Well, the parameter c of CollectionClass has kind (* - *), Array has kind (* - * - *), so it must be instance CollectionClass (Array i) e where ... ... which (I think) was breaking until -fglasgow-exts. Well, Haskell98 doesn't allow multiparameter type classes, so extensions are required. Once that was fixed, this seems to be the preferred way to implement this function. But the element type doesn't really belong in the class, wouldn't class Collection c where toList :: c e - [e] Hmmm... For example, implementing Array and UArray as subclasses of Collection: class Collection c where toList :: c e - [e] instance Collection (Array i) where toList a = ... instance Collection (UArray i) where toList a = ... If Collection is not parameterized on e, then there is no way to make sure that the e in Collection (UArray i):toList is actually unboxable. As with Ah, I see. I didn't think of that. the current IArray implementation, the following works and isn't particularly limiting in flexibility: class Collection c e where toList :: c e - [e] instance Collection (Array i) e where toList a = ... instance Collection (UArray i) Int where --note the Int toList a = ... I understand trying to make Collection as general as possible by removing e, but it look as if doing so makes useful subclasses difficult to implement? Making Collection a single parameter class doesn't increase generality, I believe, but I thought that creating a collection was a property of the type constructor c alone, so the element type didn't really belong to the class. However, the UArray example gives a good reason to include it. -- or perhaps, better class Collection c = ArrayLike c i | c - i where look :: Monad m = i - c e - m e be preferable? ermm... Need to read up on Functional Dependencies... brb... Thus we can declare instance ArrayLike [] Int where look 0 (x:_) = return x ... Thanks for the help. - Alson Cheers, Daniel -- In My Egotistical Opinion, most people's C programs should be indented six feet downward and covered with dirt. -- Blair P. Houghton ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Template haskell instance checking
Is there a way, in template haskell, to find out what instance declarations exist? Not at the moment, I'm afraid, but it's the kind of question that TH ought to be able to answer. I could offer guidance if someone wanted to implement it. I have a concern about how computed class memberships would work. Class membership is global, so creating a class instance is a globally visible side effect of TH code. Once you add the ability for TH code to inspect instances, the side effects mean that the order in which different splices get executed affects the compiler output. This is probably a bad thing. I'm not sure how it could be designed to work nicely; the only approach I can think of at the moment is to give splice evaluation a dataflow execution semantics that causes splices to execute and possibly reexecute at the appropriate times. I'd like to hear if anyone else has ideas on how to solve this problem. .tian: I think that's a good point in general about conditional code generation. I wasn't thinking about conditional generation based on compile-time settings, but rather reusable TH library functions that inspect the class memberships of their arguments. Of course, this can be used for good or evil :) --heatsink ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Credit Card Authorization code
I am looking for Haskell code that does credit card authorization? e.g. paypal website pro does not supply a Haskell lib. Does anyone know where to find something like this? -ALex- __ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Layout rule (was Re: PrefixMap: code reviewrequest)
Brian Hulley wrote: [snip] So any solutions welcome :-) Thank to everyone who replied to my queries about this whole layout issue. One other thing I've been wanting to ask (not to change! :-)) for a while is: how is the following acceptable according to the rules in the Haskell98 report where where is one of the lexemes, which when followed by a line more indented than the line the layout-starting-lexeme is on, should start an implicit block: module M where data T = .-- not indented! According to my understanding of the layout algorithm, the above code would have to be written: module M where data T = Can anyone shed some light on what the formal rule is that allows the first (and very useful) way of laying out code to be ok? Thanks, Brian. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Layout rule (was Re: PrefixMap: code reviewrequest)
Layout only applies when something is less indented than previous lines, I believe... e.g. do c - getContents filename putStrLn blah or do x - getContents filename putStrLn ok works fine but do c - blahAction putStrLn blah obviously won't work Jared. On 3/2/06, Brian Hulley [EMAIL PROTECTED] wrote: Brian Hulley wrote: [snip] So any solutions welcome :-) Thank to everyone who replied to my queries about this whole layout issue. One other thing I've been wanting to ask (not to change! :-)) for a while is: how is the following acceptable according to the rules in the Haskell98 report where where is one of the lexemes, which when followed by a line more indented than the line the layout-starting-lexeme is on, should start an implicit block: module M where data T = .-- not indented! According to my understanding of the layout algorithm, the above code would have to be written: module M where data T = Can anyone shed some light on what the formal rule is that allows the first (and very useful) way of laying out code to be ok? Thanks, Brian. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- http://www.updike.org/~jared/ reverse )-: ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
