RE: confusing error message
Good point. Error message improved, regression test added. Thanks for the suggestion Simon | -Original Message- | From: Dean Herington [mailto:[EMAIL PROTECTED]] | Sent: 05 February 2003 19:14 | To: [EMAIL PROTECTED] | Subject: confusing error message | | buzzard(118)% cat Bug5.hs | import Control.Monad.State | data S = S Int | newtype M a = M (StateT S IO a) | deriving (Monad) | | main = return () | buzzard(119)% ghc -c Bug5.hs | | Bug5.hs:3: | Can't make a derived instance of `Monad M' | (too hard for cunning newtype deriving) | When deriving instances for type `M' | buzzard(120)% ghc --version | The Glorious Glasgow Haskell Compilation System, version 5.04.2 | | | The real problem above is that I forgot to enable extensions. It would | be helpful if the error message indicated that as the problem. | | | ___ | Glasgow-haskell-bugs mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
The boot interface files for TypeRep contain errors
The boot interface files for .../ghc/compiler/types/TypeRep.lhs contain errors. In TypeRep.lhs PredType is defined as: - type PredType = SourceType -- A subtype for predicates - But in the boot files it is exported as a datatype (taken from TypeRep.hi-boot-6): - module TypeRep where data Type data PredType type Kind = Type type SuperKind = Type - When compiling GHC this doesn't matter, the compilation succeeds anyway. The error shows up first when generating external Core for GHC. Since PredType is exported as a datatype it will be refered to by all modules that are using the boot file, but when generating external Core for TypeRep the type PredType will be removed since it is just an alias. Therefore there will be a lot of references to the nonexisting type TypeRep.PredType. The solution is to define PredType as a type in the boot files and add the type SourceType as a datatype. Here are the modified boot files: TypeRep.hi-boot: - _interface_ TypeRep 1 _exports_ TypeRep Type SourceType PredType Kind SuperKind ; _declarations_ 1 data Type ; 1 data SourceType ; 1 type PredType = SourceType; 1 type Kind = Type ; 1 type SuperKind = Type ; - TypeRep.hi-boot-5 - __interface TypeRep 1 0 where __export TypeRep Type SourceType PredType Kind SuperKind ; 1 data Type ; 1 data SourceType ; 1 type PredType = SourceType ; 1 type Kind = Type ; 1 type SuperKind = Type ; - TypeRep.hi-boot-6 - module TypeRep where data Type data SourceType type PredType = SourceType type Kind = Type type SuperKind = Type - Should I commit these changes to the HEAD branch? Regards, Tobias ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
biographical profiling bug
In a fairly recent CVS (I don't have 5.04* easily available to check it): igloo@userpc15:bug$ ghc --make Foo -o Foo -prof -auto-all -O Chasing modules from: Foo Compiling Inflate ( Inflate.lhs, ./Inflate.o ) Compiling Main ( Foo.lhs, ./Foo.o ) Linking ... igloo@userpc15:bug$ ./Foo +RTS -hb Foo: internal error: Invalid object in processHeapClosureForDead(): 17260 Please report this as a bug to [EMAIL PROTECTED], or http://www.sourceforge.net/projects/ghc/ igloo@userpc15:bug$ Source at http://urchin.earth.li/~ian/bug.tar.gz Thanks Ian ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: The boot interface files for TypeRep contain errors
Urk! Good point! Yes, please do commit those changes. Do you have commit permission now? Simon | -Original Message- | From: Tobias Gedell [mailto:[EMAIL PROTECTED]] | Sent: 06 February 2003 13:14 | To: glasgow-haskell-bugs | Subject: The boot interface files for TypeRep contain errors | | The boot interface files for .../ghc/compiler/types/TypeRep.lhs contain | errors. | | | In TypeRep.lhs PredType is defined as: | | - | type PredType = SourceType -- A subtype for predicates | - | | | But in the boot files it is exported as a datatype (taken from | TypeRep.hi-boot-6): | | - | module TypeRep where | | data Type | data PredType | type Kind = Type | type SuperKind = Type | - | | When compiling GHC this doesn't matter, the compilation succeeds anyway. | The error shows up first when generating external Core for GHC. Since | PredType is exported as a datatype it will be refered to by all modules | that are using the boot file, but when generating external Core for | TypeRep the type PredType will be removed since it is just an alias. | Therefore there will be a lot of references to the nonexisting type | TypeRep.PredType. | | | The solution is to define PredType as a type in the boot files and add | the type SourceType as a datatype. | | | Here are the modified boot files: | | TypeRep.hi-boot: | - | _interface_ TypeRep 1 | _exports_ TypeRep Type SourceType PredType Kind SuperKind ; | _declarations_ | 1 data Type ; | 1 data SourceType ; | 1 type PredType = SourceType; | 1 type Kind = Type ; | 1 type SuperKind = Type ; | - | | | TypeRep.hi-boot-5 | - | __interface TypeRep 1 0 where | __export TypeRep Type SourceType PredType Kind SuperKind ; | 1 data Type ; | 1 data SourceType ; | 1 type PredType = SourceType ; | 1 type Kind = Type ; | 1 type SuperKind = Type ; | - | | | TypeRep.hi-boot-6 | - | module TypeRep where | | data Type | data SourceType | type PredType = SourceType | type Kind = Type | type SuperKind = Type | - | | | | Should I commit these changes to the HEAD branch? | | | | Regards, | Tobias | | ___ | Glasgow-haskell-bugs mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: External Core parser bug
I've fixed this one, I believe. Simon | -Original Message- | From: Kirsten Chevalier [mailto:[EMAIL PROTECTED]] | Sent: 07 January 2003 20:27 | To: [EMAIL PROTECTED] | Subject: External Core parser bug | | The attached file was generated by running 'ghc -fext-core' on the Atom | benchmark from the spectral section of the nofib suite, but if I try to | read it back into GHC 5.04.1, I get the following error: | | 2882: Parse error | :-2::GHCziPrim.Floatzh)) | (GHCziBase.zdwZC @ GHCziFloat.Float | (GHCziFloat.zdwFzh (1.0::GHCziP | | -- | Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: The boot interface files for TypeRep contain errors
Urk! Good point! Yes, please do commit those changes. Do you have commit permission now? Yes, I have commit permission now, thanks! I had troubles commiting at first but then I ran cvs update -A and then cvs commit filenames. I hope that was the right way to do it. //Tobias ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Kontakt Lenste yeni yil firsati 1 Kutu Lens 35 Milyon USTELIK ADRESE TESLIM KACIRMAYIN_____6357474__
En ucuz lensler icin lutfen tiklayin. Bir telefonla adrese teslim. http://www.akdenizgoz.com Akdeniz Goz Merkezi Fevzipaþa No:73 Fatih0 212 635 74 74 Listeden cikmak icin [EMAIL PROTECTED]adresine bos mail gonderiniz
Your message to Glasgow-haskell-bugs awaits moderator approval
Your mail to 'Glasgow-haskell-bugs' with the subject Kontakt Lenste yeni yil firsati 1 Kutu Lens 35 Milyon USTELIK ADRESE TESLIM KACIRMAYIN_6357474__ Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: buffering woes
Hal Daume III [EMAIL PROTECTED] writes: Not for me, GHC 5.04.2 (Solaris). here it goes right the first time, but then i have to type two more letters (in this case 'b\n') to get it to respond to hello. Solaris has a slightly bizarre buffering scheme in raw terminal mode, whereby it buffers 4 characters at a time, instead of passing on each character immediately. Try stty -icanon min 1 (or something similar) to fix it? Someone must have failed setting the tty mode. :-) The 4 is (if I remember right) the VMIN value which is stored in the same place as the EOF (^D = 4) character. It has to be set to 0 when placing the tty in raw mode. Bingo. Now fixed, thanks all. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc feature request: core notes
Hal Daume III [EMAIL PROTECTED] writes:
I'm not sure how generally useful this would be, but I would
find it useful to be able to attach notes to core expressions from
the Haskell code. The idea being something along the lines of a
code annotation like a pragma. [...]
Simon Peyton-Jones [EMAIL PROTECTED] writes:
[...] There is an annotation facility in Core, but it's easy for the notes
to be discarded. So if they are conveying important info, it might
easily get lost... and if not, what's it doing there in the first
place. What do you expect to happen to these annotations? [...]
It seems like _scc_ is (almost) exactly what you need here. When used
for profiling, you mark subexpressions you want profiled and ghc takes
care to preserve and propagate them in a semantically meaningful way.
Any _scc_ annotations that ghc chooses to drop can be reported as
bugs :-)
I say almost because what the semantics used when profiling may not
be the right ones for your purposes. (I'm being vague because I don't
know your purposes.)
Naturally, you'd want to be able to use these notes independently of
profiling - which can probably be done with a little preprocessor
hackery. Assuming that the 1st argument to 'NOTE' is a literal string
in the following:
#ifdef TRACK_NOTES
#define NOTE(x,y) (_scc_ NOTE x (y))
#else
#define NOTE(x,y) {- nothing -}
#endif
--
Alastair Reid
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
chains of IORefs
using IORefs, one can construct linked lists in Haskell that resemble one's used in imperative C programming. eg, the following toy code creates a chain of 1000 linked records. import IOExts data Record= RecordNil | Record String Int Chain type Chain = IORef Record main=makeChain [1..1000] makeChain::[Int]-IO Chain makeChain []=newIORef RecordNil makeChain (a:as)=makeChain as= \chain- newIORef (Record data a chain) such structures will be garbage-collected automatically, right? in general terms, please comment on how well GHC supports code that uses such structures. (I have no reason to suspect it would not be well-supported, but it never hurts to verify assumptions before plunging into coding.) now, to turn makeChain into a lazy producer requires adding an IO to the type of Chain, yielding type Chain=IO (IORef Record) please comment on how well GHC would tend to support such a type. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: awaitEval in Concurrent Haskell
Colin [ccing GHC users in case there are other enthusiasts out there] | we briefly discussed the lack in | Concurrent Haskell of any way to set up a data-driven | thread -- one that works on a data structure D without | ever forcing its evaluation, only proceeding with the | computation over D as and when the needed parts get | evaluated by some other thread. | | An example application is assertion-checking in a program that depends | on laziness -- and indeed I am currently supervising a student | project on this topic. Concurrent Haskell looked like | an obvious basis for implementation, but we are stuck | without data-driven threads. | | You did say that it would not take too much work for someone | familiar with the Concurrent Haskell implementation, such as yourself, | to add a suitable primitive for the expression of data-driven threads. | Is there any possibility that you could indeed do this in the near future? It's not entirely obvious what you want here. Ideally you'd be able to say f xs = assert (length xs 10) (...) and have the predicate (length xs 10) evaluated only when xs itself was evaluated. But that means that the evaluations performed by length would have to be suspended somehow. That seems hard, if we are sharing a single copy of length. (Not *all* evaluations performed by these assertion-checking threads must be suspended... they may create thunks of their own.) Next idea is to have a function await :: a - b - b which is rather like 'seq' except that it waits for its first argument to be evaluated, whereas 'seq' evaluates it. Then you could write a new version of 'length' which used await before every case expression. Is that what you had in mind? A bit fragile, isn't it? How to implement 'await'. We thought of three ways: 1. Implement a primitive checkEval :: a - Bool, which tells whether something is evaluated; if not, it yields to other threads, as well as returning False. So now you can have a busy-wait version of await thus: await x y = case checkEval x of True - y False - await x y 2. Implement await directly, by putting the thread in a pool of threads that the scheduler checks at regular intervals. They each just watch a thunk. Still a busy-waiting solution. 3. Do the right thing: implement 'await' by copying the thunk, replacing it by a smart indirection which also points to the non-suspended thread. When the indirection is evaluated, it just puts the suspended thread in the runnable pool before entering the thunk. Actually, this is probably no harder than (2). Now, it's true that it would take Simon or I less time to implement one of these than it would take your student to do, but we have so *many* things to implement, and each takes time. And you will probably change your mind several times about what the right design should be (that's what research is like). So there's a lot to be said for the wading in yourself. What I can promise is that we'd turn around questions rapidly. Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC and C++ (was RE: Creating COM objects and passing out pointers to them via a COM interface)
| 1. A facility to replace the default uncaught exception behaviour for COM | objects and similar shared library code I'm out of my depth here. I think that if those interested in COMish things get a consensus on what would be the Right Thing, and have some idea about implementation, we'd be willing to help fix GHC to do the Right Thing, if it wasn't too hard. | 2. HDirect rolled into the main GHC tree | | 3. A facility within HDirect to create COM objects based on existing | (Haskell) data structures, returning an interface pointer as a return | parameter on a call to an existing COM object. (This was the question Simon | asked if I'd had an answer to - I've attached a copy below for reference). Sounds great -- but Sigbjorn is HDirect supreme so we'll have to see what he says. Simon | -Original Message- | From: Sarah Thompson [mailto:[EMAIL PROTECTED]] | Sent: 04 February 2003 10:34 | To: Simon Peyton-Jones; Sigbjorn Finne | Cc: Daan Leijen; Kevin S. Millikin; Mike Thomas; [EMAIL PROTECTED]; | Haskell-Cafe@Haskell. Org | Subject: Re: GHC and C++ (was RE: Creating COM objects and passing out pointers | to them via a COM interface) | | I'm replying to two threads at the same time and cross posting my reply, | because they are very relevant to each other. I'm sorry if anyone here ends | up seeing this more than once as a consequence. | | [s] | | -- | Sarah | | Did you get this problem sorted out? | | Not directly. I ended up building an 'outer' COM component in C++ that | mapped an MSXML-like interface onto a simpler, internal COM component that | wraps up the Haskell code. This approach seems to work well - I might have | been able to build the necessary wrapper directly in Haskell using HDirect, | but I was becoming aware that I was probably starting to take up an | unreasonable amount of Sigbjorn's time with increasingly detailed questions | and I didn't have time to figure out the necessary intricacies from scratch. | | HDirect seems very good, but I don't think it's currently in quite as stable | a state as the main GHC release. The problems I had in building a version | that works with the current GHC are an example of this. I'm not | complaining - it worked well in the end, but I do think it might be a 'good | thing' to consider rolling HDirect into the main GHC release at some point. | | The other thing that bit me was exception handling, or rather the default | behaviour when an uncaught exception 'falls out' and reaches the top level | of the runtime system. Currently, the functionality appears to be to abort | the current process. Whilst this is probably desirable for a typical | application executable (be that console or GUI based), it is a problem if it | happens inside a COM component. My thinking is quite straightforward on | this. Preferred behaviour should really be for a call to a COM component to | fail returning an error code, rather than abort the calling process. | 'Server-style' applications are usually expected to keep running when minor | faults occur, rather than terminate. HDirect/GHC's current behaviour makes | this difficult to achieve - I managed to successfully catch exceptions, but | the price was needing to use some code based on DeepSeq to force deep strict | evaluation for all state updates. This (seemingly) was the only way I could | stop exceptions from happening in the context of the automatically generated | COM wrapper - passing it a fully evaluated data structure was apparently the | only solution available. However, this does break the advantages of laziness | as applied to the current state of the object - it would be pretty neat, for | example, to be able to define a view of a database as the result of an | expression involving relational algebra combinators, with the query | evaluated one record at a time as the data is pulled back by the client | application. The need for DeepSeq forces strict evaluation, so this benefit | is lost. This is actually more of an issue than it might immediately seem - | many queries don't actually need to retrieve all of a record set before | useful things can be done. A particular example is updating a GUI, where a | list box reflects the results of a query. Lazy evaluation will allow the | screen to start updating more or less immediately even on a query that | returns thousands of records - strict evaluation might incur a delay of a | few seconds (for a very complex query or a large database) before updates | can start happening. | | In an ideal world, what I'd dearly love to see would be an HDirect option | that allows a choice between existing functionality and having calls return | a failure code, or better still allowing a user-supplied handler function to | determine the correct course of action. | | So, to sum up my wish list: | | 1. A facility to replace the default uncaught exception behaviour for COM | objects and similar shared library code | | 2. HDirect rolled into the main GHC tree |
Re: awaitEval in Concurrent Haskell
Simon, Next idea is to have a function await :: a - b - b which is rather like 'seq' except that it waits for its first argument to be evaluated, whereas 'seq' evaluates it. Then you could write a new version of 'length' which used await before every case expression. Is that what you had in mind? A bit fragile, isn't it? Something like await would be enough I think. It would not be necessary to write new versions of all the functions to be data driven, just a single (overloaded) function to convert a demanding function into a data-driven one. Something like this: asEvaluated xs = await xs (case xs of (x:xs) - asEvaluated x : asEvaluated xs [] - []) dataDriven f = f . asEvaluated assert p xs = thread (... dataDriven p xs ...) xs How to implement 'await'. We thought of three ways: 1. Implement a primitive checkEval :: a - Bool, which tells whether something is evaluated; if not, it yields to other threads, as well as returning False. So now you can have a busy-wait version of await thus: await x y = case checkEval x of True - y False - await x y 2. Implement await directly, by putting the thread in a pool of threads that the scheduler checks at regular intervals. They each just watch a thunk. Still a busy-waiting solution. 3. Do the right thing: implement 'await' by copying the thunk, replacing it by a smart indirection which also points to the non-suspended thread. When the indirection is evaluated, it just puts the suspended thread in the runnable pool before entering the thunk. Actually, this is probably no harder than (2). I agree that 2 seems the most straightfoward, and not quite so busy as 1. Unless I am misunderstanding 3 it could lead to problems if scheduling can occur before evaluation of the thunk reaches a normal form. Now, it's true that it would take Simon or I less time to implement one of these than it would take your student to do, but we have so *many* things to implement, and each takes time. And you will probably change your mind several times about what the right design should be (that's what research is like). So there's a lot to be said for the wading in yourself. The formula for implementation time is roughly initiationRites + inherentDifficulty / skillLevel and I am pretty sure we could get by with just the await primitive. So if there is any way you could find an early slot to do a basic implementation of await, it would be much appreciated. What I can promise is that we'd turn around questions rapidly. If we do end up trying to define await for ourselves, which source files should we expect to modify and are there any likely pitfalls in the subsequent rebuilding? Thanks Colin R ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: awaitEval in Concurrent Haskell
Colin [ccing GHC users in case there are other enthusiasts out there] | we briefly discussed the lack in | Concurrent Haskell of any way to set up a data-driven | thread -- one that works on a data structure D without | ever forcing its evaluation, only proceeding with the | computation over D as and when the needed parts get | evaluated by some other thread. I'm not sure whether I understand what you have in mind later on, but this first part sounds so remarkably like something I've seen before, that I'll take my chances. Do you remember Andy Gill's Hood from long ago? Inside its implementation, it had a very similar problem: writing information about an observed structure to some observation trace, but without forcing premature evaluation of the structure under observation. The trick used in Observe.lhs is roughly this (here for (,)): observe label (a,b) = unsafePerformIO $ do sendObservation label (,) return (observe label a,observe label b) with some position information and strictness mangling added, and the whole nicely wrapped into a monad (see Observe.lhs for details). Nothing happens as long as the thing under observation is not inspected by its context. Then, and precisely then, the unsafePerformIO kicks in to record a piece of information and to return the outer part of the thing, wrapping its components into fresh observers. Andy used this to store observations in a list, to be processed at the end of the program run, but you can just as well send the observations during evaluation, e.g., to a concurrent thread (with the usual caveats). In particular, the sequencing of information becoming available was detailed enough to inspire my own GHood;-) With no implementation slot free, something like this might get your student's project unstuck (e.g., replace sendObservation by assert)? After all, my favourite justification for unsafePerformIO is as an extension hook in the runtime system.. Sorry if your intention was something else and I'm just trying to fit a solution to the problem. Even then, you might be able to adapt the trick to your application. Cheers, Claus ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: sockets (ghc-5.04.1)
Volker, I only saw your answer today since it was filed in my Haskell-mailing-list folder. Indeed, I've moved on to import Network.Socket and then duplicated part of my code. One thing that I found annoying was that the Protocol argument of Network.Socket.socket is not well specified. The type Protocol is abstract, but is a member of class Read. However, the Read syntax is nowhere specified. So I tried do sock - socket AF_UNIX Stream (read 0) which works, but I'm sure that more informative strings work, too. -Peter ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Build error
I'm trying to build ghc 5.04.2 from the source distribution (on Linux, RH 7.2), and get the following error ..==fptools== make all -wr;in /usr/local/src/ghc-5.04.2/ghc/rts.../utils/ghc-pkg/ghc-pkg-inplace --update-package rts.conf.inplaceReading package info from stdin... done.Expanding embedded variables...done.warning: can't find GHCi lib `HSrts.o'Saving old package config file... done.Writing new package config file... done/utils/ghc-pkg/ghc-pkg-inplace -f ../driver/package.conf --update-package rts.conf.installedReading package info from stdin... done.Expanding embedded variables...done.warning: can't find GHCi lib `HSrts.o'Saving old package config file... done.Writing new package config file... done.../../ghc/compiler/ghc-inplace -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc-Wcast-align -optc-I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -ldl -O2 -static -package-name rts -O -Rghc-timing -c Adjustor.c -o Adjustor.oghc: 598636 bytes, 2 GCs, 32532/32532 avg/max bytes residency (1 samples), 5M in use, 0.02 INIT (0.01 elapsed), 0.02 MUT (0.04 elapsed), 0.06 GC (0.16 elapsed) :ghcmake[2]: *** [Adjustor.o] Error 1make[1]: *** [all] Error 1make[1]: Leaving directory `/usr/local/src/ghc-5.04.2/ghc'make: *** [all] Error 1 If I use the analogous gcc command, everything works. How can I find out what's going wrong ? Thanks, Robin
Re: Looking for large Haskell programs
Tobias Gedell wrote I'm looking for large haskell programs with more than 15000 lines of code. Does any of you know where I can find such programs? The programs found in the nofib suite are not large enough. The UniForM workbench is currently almost 8 lines (of which 4500 are actually HaXml, so don't really count), and is almost all Haskell. It uses a lot of Glasgow extensions though. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
ICFP 2003 Call for Papers -- deadline extended
The submission deadline for ICFP (the ACM SIGPLAN International Conference on Functional Programming) has been extended by nine days to March 29 (2300 UTC). The 2003 ICFP will be in Uppsala, Sweden on August 25-29, in conjunction with PPDP (Principles and Practice of Declarative Programming). Please take a moment to read the call for papers I've appended below, and see if you have a topic or result you would like to submit to the program committee. See you in Sweden. -Olin Shivers program chairman === Eighth Annual ACM SIGPLAN International Conference on Functional Programming ICFP 2003 Call for Papers (Revised 2003/2/5) Affiliated with PLI 2003 August 25-29, 2003 Uppsala, Sweden http://www-users.cs.york.ac.uk/~colin/icfp2003.html http://www.cc.gatech.edu/icfp03/cfp.html --- * Important dates - Submission deadline 18:00 EST 29 March, 2003 (Thursday) Notification of acceptance rejection 19 May, 2003 Final paper due 16 June, 2003 Conference 25-29 August, 2003 * Scope --- ICFP 2003 seeks original papers on the full spectrum of the art, science, and practice of functional programming. The conference invites submissions on all topics ranging from principles to practice, from foundations to features, and from abstraction to application. The scope covers all languages that encourage programming with functions, including both purely applicative and imperative languages, as well as languages that support objects and concurrency. Topics of interest include, but are not limited to, the following: Foundations formal semantics, lambda calculus, type theory, monads, continuations, control, state, effects. Design Algorithms and data structures, modules and type systems, concurrency and distribution, components and composition, relations to object-oriented and logic programming, multiparadigm programming. Implementation abstract machines, compile-time and run-time optimization, just-in-time compilers, memory management. Interfaces to foreign functions, services, components and low-level machine resources. Transformation and analysis abstract interpretation, partial evaluation, program transformation, theorem proving, specification and verification. Software development techniques for functional programming design patterns, specification, verification and validation, debugging, test generation, tracing and profiling. Applications and domain-specific languages systems programming, scientific and numerical computing, symbolic computing and artificial intelligence, systems programming, databases, graphical user interfaces, multimedia programming, application scripting, system administration, distributed-systems construction, web programming. Practice and experience functional programming in education and industry, ramifications on other paradigms and computing disciplines. Functional pearls elegant, instructive examples of functional programming. Papers in the latter three categories need not necessarily report original research results; they may instead, for example, report practical experience that will be useful to others, re-usable programming idioms, or elegant new ways of approaching a problem. The key criterion for such a paper is that it makes a contribution from which other practitioners can benefit. It is not enough simply to describe a program! * Submission guidelines --- Due date time: Submissions must be filed at the web site by 18:00 EST on Thursday 29 March. Some convenient equivalents to 18:00 EST are New York: 6:00 PM = 18h00 San Francisco: 3:00 PM = 15h00 Chicago: 5:00 PM = 17h00 Paris: Midnight Hong Kong: 7:00 AM (30 March) UTC: 2300 For other time-zones/locations, see http://www.timeanddate.com/worldclock/fixedtime.html Submission URL: http://www.cc.gatech.edu/icfp03/submit Authors should submit a 100-200 word abstract and a full paper by 23:00 Universal Coordinated Time on Thursday, March 29, 2003. Submissions should be no more than 12 pages (including bibliography and appendices) in standard ACM conference format: two columns, nine-point font on a ten-point baseline, with pages 20pc (3.33in) wide and 54pc (9in) tall, with a column gutter of 2pc (0.33in). Detailed formatting guidelines are available at http://www.acm.org/sigs/pubs/proceed/template.html, along with formatting templates or style files for LaTeX, Word Perfect, and Word. You don't need to include categories, keywords, etc., though you are welcome to do so. Also, note that the ACM copyright notice is not required of submissions, only of accepted papers. Authors wishing to
default class methods in sub-classes
Apparently I can't do this (in ghc or hugs -- haven't tried others): class Space a where distance :: a - a - Int subtract :: a - a - a class (Space a) = NormSpace a where norm :: a - Int distance a b = norm (subtract a b) That is, I can't make (or redefine) a default for the superclass method 'distance' in a subclass. I agree that the Haskell'98 definition doesn't claim that this should be allowed, but it seems like something that would be useful. Are there reasons not to allow this (or that I shouldn't want to do this at all)? Apologies if this is well-covered. I couldn't find any mention of it. :-Dylan Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
ICFP 2003 CFP -- minor but critical correction
The submission date, March 29, is a Saturday, *not* a Thursday. Sorry 'bout that. -Olin === Eighth Annual ACM SIGPLAN International Conference on Functional Programming ICFP 2003 Call for Papers (Revised 2003/2/5) Affiliated with PLI 2003 August 25-29, 2003 Uppsala, Sweden http://www-users.cs.york.ac.uk/~colin/icfp2003.html http://www.cc.gatech.edu/icfp03/cfp.html --- * Important dates - Submission deadline 18:00 EST 29 March, 2003 (Saturday) Notification of acceptance rejection 19 May, 2003 Final paper due 16 June, 2003 Conference 25-29 August, 2003 * Scope --- ICFP 2003 seeks original papers on the full spectrum of the art, science, and practice of functional programming. The conference invites submissions on all topics ranging from principles to practice, from foundations to features, and from abstraction to application. The scope covers all languages that encourage programming with functions, including both purely applicative and imperative languages, as well as languages that support objects and concurrency. Topics of interest include, but are not limited to, the following: Foundations formal semantics, lambda calculus, type theory, monads, continuations, control, state, effects. Design Algorithms and data structures, modules and type systems, concurrency and distribution, components and composition, relations to object-oriented and logic programming, multiparadigm programming. Implementation abstract machines, compile-time and run-time optimization, just-in-time compilers, memory management. Interfaces to foreign functions, services, components and low-level machine resources. Transformation and analysis abstract interpretation, partial evaluation, program transformation, theorem proving, specification and verification. Software development techniques for functional programming design patterns, specification, verification and validation, debugging, test generation, tracing and profiling. Applications and domain-specific languages systems programming, scientific and numerical computing, symbolic computing and artificial intelligence, systems programming, databases, graphical user interfaces, multimedia programming, application scripting, system administration, distributed-systems construction, web programming. Practice and experience functional programming in education and industry, ramifications on other paradigms and computing disciplines. Functional pearls elegant, instructive examples of functional programming. Papers in the latter three categories need not necessarily report original research results; they may instead, for example, report practical experience that will be useful to others, re-usable programming idioms, or elegant new ways of approaching a problem. The key criterion for such a paper is that it makes a contribution from which other practitioners can benefit. It is not enough simply to describe a program! * Submission guidelines --- Due date time: Submissions must be filed at the web site by 18:00 EST on Saturday 29 March. Some convenient equivalents to 18:00 EST are New York: 6:00 PM = 18h00 San Francisco: 3:00 PM = 15h00 Chicago: 5:00 PM = 17h00 Paris: Midnight Hong Kong: 7:00 AM (30 March) UTC: 2300 For other time-zones/locations, see http://www.timeanddate.com/worldclock/fixedtime.html Submission URL: http://www.cc.gatech.edu/icfp03/submit Authors should submit a 100-200 word abstract and a full paper by 23:00 Universal Coordinated Time on Saturday, 29 March, 2003. Submissions should be no more than 12 pages (including bibliography and appendices) in standard ACM conference format: two columns, nine-point font on a ten-point baseline, with pages 20pc (3.33in) wide and 54pc (9in) tall, with a column gutter of 2pc (0.33in). Detailed formatting guidelines are available at http://www.acm.org/sigs/pubs/proceed/template.html, along with formatting templates or style files for LaTeX, Word Perfect, and Word. You don't need to include categories, keywords, etc., though you are welcome to do so. Also, note that the ACM copyright notice is not required of submissions, only of accepted papers. Authors wishing to supply additional material to the reviewers beyond the 12-page limit can do so in clearly marked appendices, on the understanding that reviewers are not required to read the appendices. Submissions that do not meet these guidelines will not be considered. The submission deadline and length above are firm. Submissions will be carried out electronically via the Web, at the URL given above. Papers must be submitted in
Re: default class methods in sub-classes
On Wed, Feb 05, 2003 at 09:16:58PM -0800, Dylan Alex Simon wrote: Apparently I can't do this (in ghc or hugs -- haven't tried others): class Space a where distance :: a - a - Int subtract :: a - a - a class (Space a) = NormSpace a where norm :: a - Int distance a b = norm (subtract a b) That is, I can't make (or redefine) a default for the superclass method 'distance' in a subclass. I agree that the Haskell'98 definition doesn't claim that this should be allowed, but it seems like something that would be useful. Are there reasons not to allow this (or that I shouldn't want to do this at all)? No, it's not legal, but it would indeed be useful, even in the Prelude, e.g. defining (==) in Ord, or fmap in Monad. It seems a reasonable idea of subclass, but might be hard to do across module boundaries. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
CFP: APLAS03 - 1st Asian Symp. on Prog. Lang. and Systems
[My apologies if this eventually leads to a double posting, but Atsushi Ohori's original post didn't get through as he does not subscribe to this list.] Call for Papers The First Asian Symposium on Programming Languages and Systems (APLAS03) URL: http://www.jaist.ac.jp/aplas/ Beijing, China. October 27-29, 2003 (Submission deadline: May 27, 2003) Sponsored by the Asian Association for Foundations of Software (AAFS) and Beihang University (Beijing University of Aeronautics and Astronautics). DESCRIPTION: APLAS aims at stimulating programming language research by providing a forum for the presentation of recent results and the exchange of ideas and experience in topics concerned with programming languages and systems. APLAS is based in Asia, but intends to be an international forum that serves the worldwide programming languages community. The APLAS series is sponsored by the Asian Association for Foundation of Software (AAFS), which has recently been founded by Asian researchers in cooperation with many researchers from Europe and the USA. APLAS has been discussed and prepared through informal workshops held in Singapore (2000), Daejeon (2001), and Shanghai (2002). APLAS03 will be the first formal symposium in the series. TOPICS: The symposium is devoted to foundational issues in programming languages and systems, covering the following areas: * semantics and theoretical foundations * type systems and language design * compilers and implementation * program analysis and security * program transformation and calculation * concurrency GENERAL CHAIR: Wei Li National Laboratory of Software Development Environment Beijing University of Aeronautics and Astronautics Beijing, 100083, China E-mail: [EMAIL PROTECTED] PROGRAM CHAIR: Atsushi Ohori (http://www.jaist.ac.jp/~ohori) School of Information Science Japan Advanced Institute of Science and Technology Tatsunokuchi, Ishikawa, 923-1292 JAPAN E-mail: [EMAIL PROTECTED] Tel: +81 761 51 1275, Fax: +81 761 51 1149 PROGRAM COMMITTEE: * Manuel Chakravarty (University of New South Wales, Australia) * Wei Ngan Chin (National University of Singapore, Singapore) * Tyng-Ruey Chuang (Academia Sinica, Taiwan) * Yuxi Fu (Shanghai Jiaotong University, China) * Masahito Hasegawa (Kyoto University, Japan) * Kohei Honda (Queen Mary College, UK) * Zhenjiang Hu (University of Tokyo, Japan) * Peter Lee (Carnegie Mellon University, USA) * Shilong Ma (Beijing University of Aeronautics and Astronautics, China) * Martin Odersky (Ecole Polytechnique de Lausanne, Switzerland) * Atsushi Ohori (JAIST, Japan), Chair * Don Sannella (University of Edinburgh, UK) * Zhong Shao (Yale University, USA) * Kwangkeun Yi (KAIST, Korea) * Taiichi Yuasa (Kyoto University, Japan) IMPORTANT DATES: Submission deadline: May 27, 2003 Notification of acceptance: July 17, 2003 Final paper due: August 17, 2003 Symposium:October 27-29, 2003 PROCEEDINGS AND SUBMISSION PROCEDURE: The proceedings will be published in the Springer-Verlag Lecture Notes in Computer Science series. Final papers will be no more than *15* pages long in the format specified by Springer-Verlag at the URL: http://www.springer.de/comp/lncs/authors.html Prospective authors are invited to submit a 100-200 word abstract and a full paper in English presenting original research. Submitted papers must be unpublished and not submitted for publication elsewhere. Submissions will be carried out electronically via the Web via a link found at the symposium web page http://www.jaist.ac.jp/aplas/ Papers must be submitted in either PDF format, or as PostScript documents that are interpretable by Ghostscript. Those who have difficulty in web-based submission should contact the program chair before the deadline. It is recommended that submissions adhere to the format and length of the proceedings described above. Submissions that are clearly too long may be rejected immediately. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [OT] Teaching Haskell in High School
Hal == Hal Daume, Hal writes: Hal Hi all, Hal Before getting in to this, let me preface my question(s) with a note that Hal I have checked through the Haskell in Education web page and have found Hal various links off there of interest (and I've googled, etc. In Hal short: I've done my homework). Hal That said, I've been in rather close correspondence with my math/computer Hal science teacher from high school. When I first took CS there, they taught Hal Pascal (a year early they had been teaching Scheme). They switched over Hal to VB (alas) recently and have been teaching that for a few years now. Hal The teacher really wants to get away from VB, but is having a somewhat Hal difficult time deciding what to go to. The two most promising options are Hal Haskell and Java. I really recommend looking at the TeachScheme! curriculum and the How to Design Programs curriculum. Here are two URLs: http://www.teach-scheme.org/ http://www.htdp.org/ This works exceptionally well at the High School level (I know that earlier attempts to do this with Scheme failed---this one is very different), and has been extensively applied with great success---also and especially in conjunction with the AP curriculum and/or a course on Java based on the same methodology. There's a wealth of software and material, and the TeachScheme! program offers (mostly free) workshops on this. Haskell just has some terrible properties when it comes to teaching beginners. Among them are the complex and easy-to-get-wrong syntax, the available programming environments which are OK for developers but awful for beginners. There's also a dearth of good textbooks at the level you need. Haskell is very easy to learn (and an excellent choice for a 2nd or 3rd language) when you know Scheme. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: default class methods in sub-classes
Hello, Apparently I can't do this (in ghc or hugs -- haven't tried others): class Space a where distance :: a - a - Int subtract :: a - a - a class (Space a) = NormSpace a where norm :: a - Int distance a b = norm (subtract a b) That is, I can't make (or redefine) a default for the superclass method 'distance' in a subclass. I agree that the Haskell'98 definition doesn't claim that this should be allowed, but it seems like something that would be useful. Are there reasons not to allow this (or that I shouldn't want to do this at all)? Apologies if this is well-covered. I couldn't find any mention of it. the problem is, that to make something instance of NormSpace, you must first have it as instance of Space, i.e. with distance already defined. Then for this to work, the default definition in NormSpace would have to override what user defined, which looks strange. Your problem can be solved in ghc by this (but unfortunately only with -fallow-overlapping-instances -fallow-undecidable-instances (or some simmilar flags)): class HavingSubtract a where -- not sure why generic space should have subtract, subtract :: a - a - a -- but why not class (HavingSubtract a) = Space a where distance :: a - a - Int class (HavingSubtract a) = NormSpace a where norm :: a - Int instance (NormSpace a) = Space a where distance a b = norm (subtract a b) (and there is several more examples in that I would find something like this very useful, but AFAIK there is no clean and elegant way how to do it -- you may do something simmilar using newtypes, but that is totally clumsy). Zdenek _ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [OT] Teaching Haskell in High School
I can't resist jumping in on this one: Haskell just has some terrible properties when it comes to teaching beginners. Among them are the complex and easy-to-get-wrong syntax, the available programming environments which are OK for developers but awful for beginners. There's also a dearth of good textbooks at the level you need. Haskell is very easy to learn (and an excellent choice for a 2nd or 3rd language) when you know Scheme. I have spent many years teaching both Scheme and Haskell to beginners, and I would have to say that Haskell syntax has never been a serious problem, certainly no more than Scheme's parentheses. It is true that there is a lack of good programming environments, although Hugs is pretty easy to use, and things like Helium should be even better. (I won't say much about textbooks since I wrote one that I think is pretty good for beginners :-) Finally, aside from extraneous type error messages (which Helium should do much better at), I claim that Haskell's type system is BETTER for beginners compared to having no type system at all. As for the last point above, I could just as easily say that Scheme is very easy to learn (and an excellent choice for a 2nd or 3rd language) when you know Haskell. Now, having said all this, I will add that I have the greatest respect for the TeachScheme project, and I wish that we had something as well developed for Haskell! -Paul ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: time since the epoch
Simon Peyton-Jones (Mon, Feb 03, 2003 at 10:06:40AM -): | the haskell 98 time library is horribly broken, if you are using ghc, | you can deconstruct the time constructor which has an Integer containing | the number of seconds since epoch... otherwise you can use | ... | I dont supose this could be considered a typo in the haskell 98 report? | it is an embarasing thing for a language to not be able to do... Meanwhile, I suspect there's an opportunity for someone (or a small group) to suggest a new Time library that really does the business, and provide an implementation. If it's sufficiently persuasive, all the implementations will adopt it and it can become a de-facto standard. A sound base for a Time implementation should use TAI (temps atomique international), c.f. http://cr.yp.to/libtai.html. The implementation is important because Time is a weird enough thing that only an expert can implement the spec! -- Stefan Karrmann ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: time since the epoch
Stefan Karrmann [EMAIL PROTECTED] writes: A sound base for a Time implementation should use TAI (temps atomique international), c.f. http://cr.yp.to/libtai.html. I disagree; I think UTC is quite sufficient, and will match the users' expectations much better. (executive summary: UTC is the time on your watch (+/- timezone of course), TAI is behind by a few seconds, and this difference changes each time there's a new leap second). However, the reference above is not to TAI, but to a library called libtai. I don't know anything about this; Stefan, maybe you could tell us some more? --KW 8-) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: time since the epoch
[Keith Wansbrough [EMAIL PROTECTED]] Stefan Karrmann [EMAIL PROTECTED] writes: A sound base for a Time implementation should use TAI (temps atomique international), c.f. http://cr.yp.to/libtai.html. I disagree; I think UTC is quite sufficient, and will match the users' expectations much better. (executive summary: UTC is the time on your watch (+/- timezone of course), TAI is behind by a few seconds, and this difference changes each time there's a new leap second). However, the reference above is not to TAI, but to a library called libtai. I don't know anything about this; Stefan, maybe you could tell us some more? I know it's not really on topic, but for those of us who are ignorant of the details of time standards, does anyone have a pointer to a decent conceptual (i.e., non-software specific) overview of the subject? Leap seconds, etc., are all pretty much new to me, but I am curious. Matt -- Matt Hellige [EMAIL PROTECTED] http://matt.immute.net ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: time since the epoch
I've been running into similar problems, and I've also been pointed to
the TimeExt library that George Russell was talking about. However, in
the end, I had to implement something by myself. Much unfortunately
though, my program relies on an undocumented feature of GHC's
implementation of TimeDiff in the Time library.
John's code illustrates TimeDiff's deficiencies perfectly:
JM the haskell 98 time library is horribly broken, if you are using ghc,
JM you can deconstruct the time constructor which has an Integer containing
JM the number of seconds since epoch... otherwise you can use
JM epoch :: ClockTime
JM epoch = toClockTime $ CalendarTime { ctYear = 1970, ctMonth = January,
JM ctDay = 0, ctHour = 0, ctMin = 0, ctSec = 0, ctTZ = 0, ctPicosec = 0,
JM ctWDay = undefined, ctYDay = undefined, ctTZName = undefined, ctIsDST =
JM undefined}
JM and TimeDiff,
JM unfortunatly you have to condense the TimeDiff to seconds, which is
JM unfeasable...
Ha! After playing with this, I discovered that only the seconds were
set and all other fields remained untouched. At least in ghc's
implementation. Interestingly, TimeDiff derives Eq and Ord, but I'd
better not ask for their implementation...
There is also a more fundamental problem with the TimeDiff data
type. While seconds, minutes, hours, and days are clearly specified
amounts of time, the duration of a month or a year may vary depending
on the reference point where the time difference is applied.
My conclusion is that time differences really should be measured in
seconds and picoseconds.
type TimeDiff = (Integer, Integer)
JM we really should fix the Haskell time library. I propose adding:
JM toRawTime :: ClockTime - (Integer,Integer)
JM fromRawTime :: (Integer,Integer) - ClockTime
JM where the integers are the number of seconds and picoseconds since
JM epoch, these would be enough to make the time library useful.
JM I dont supose this could be considered a typo in the haskell 98 report?
JM it is an embarasing thing for a language to not be able to do...
Hmm, this is underspecified!
As another poster said, (pointing out http://cr.yp.to/libtai, but it
is better to look at http://cr.yp.to/time.html, which has a discussion
on UTC vs TAI vs UNIX time) the official source of time is TAI, so it
is best to base a time library
*on the number of TAI seconds since a reference date*
(which is btw what the libtai is all about).
For compatibility with UNIX time, Arthur David Olson's popular time
library uses an epoch of 1970-01-01 00:00:10 TAI
[http://cr.yp.to/proto/utctai.html].
So this mostly means that you need to set your system clock correctly:-)
Hence, a suitable specification for
JM toRawTime :: ClockTime - (Integer,Integer)
could be number of seconds since reference point, given as a pair
(full seconds, picoseconds). This function *may* involve a time zone
calculation for those that do not run their system clock on TAI (or UTC).
JM fromRawTime :: (Integer,Integer) - ClockTime
with
toRawTime . fromRawTime == id
and
fromRawTime . toRawTime ~~ id
(the internal representation of ClockTime may have less precision,
so the difference would be less than system dependent constant,
which could also be supplied by the library)
Given these two raw ingredients, everything else can be computed
from that. In addition, it would be nice to have parsing functions for
various time and date formats (which is what I ended up writing
myself for the ISO8601 format).
Cheers,
-Peter
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: arrays and lamda terms
I can see how you select an element randomly using the function parameters
(it's cheating actually because lamda calculus will still reduce this it in
steps, so it works for Haskell implementation because it does things
smarter)
As I said, it all depends on how you're counting. But given that the serious
implementations of lambda support one-step reduction of n-ary abstractions
without any problems (think de Bruijn indices, supercombinator reduction,
beta-in-the-large), it may seem overly conservative to restrict counting to
unary abstractions.
One thing I object is, probably I did not understand that part, is that you
still can't seem to access an element with a variable index (index is a
variable instead of a literal constant).
I'm not sure I understand your concern here. The selectors are functions,
but they are also all elements of the same type, so one can compute the
actual selector to use in any given case dynamically, say depending on
runtime user input:
main = do
let a = list2arr5 [1..5::Int]
l - getLine
let s = case read l of { 1 - s5_1; ..; 5 - s5_5 } -- read for selectors
i = list2arr5 12345 -- show for
selectors
putStrLn $ you chose: a[++[i s]++]= ++show (a s) -- variable index..
Collecting all selectors/indices in a list was just a quick way of emulating
the typical for-loop over all array indices..
Perhaps you'd be happier if there were more operations defined on selectors?
Haskellers sometimes think of functions as abstract values that can be applied,
but not computed with, but in lambda that's all one does (it's just that Haskell
doesn't support that style all too well) - as further examples, here are successor
and predecessor (cyclic here; adding out-of-bounds errors instead would be
straightforward):
succ5 = arr5 s5_2 s5_3 s5_4 s5_5 s5_1
pred5 = arr5 s5_5 s5_1 s5_2 s5_3 s5_4
or equality:
eq5_1 = arr5 True False False False False
..
eq5_5 = arr5 False False False False True
(==) = arr5 eq5_1 eq5_2 eq5_3 eq5_4 eq5_5
Cheers,
Claus
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Auto generated instance codes through 'deriving'
Title: Auto generated instance codes through 'deriving' Hello folks, Is there any method with which I can see instances codes generated automatically by using deriving keyword in GHC? Im curious in how GHC generates Read classs instance code for user-defined data type. Any help will be great appreciated. /JongKeun
