RE: Invalid binding names in generated Core code
Excellent point. Now fixed in the HEAD. Thanks for the report.
Simon
| -Original Message-
| From: Tobias Gedell [mailto:[EMAIL PROTECTED]]
| Sent: 22 January 2003 16:56
| To: glasgow-haskell-bugs
| Subject: Invalid binding names in generated Core code
|
| The generation of binding names doesn't seem to work correctly. I have
| generated Core for Base.lhs by standing in the
| .../ghc-5.05.20030119/libraries/base directory and giving the command:
|
| ../../ghc/compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude
| -#include HsBase.h -funbox-strict-fields -package-name base -O
| -Rghc-timing -split-objs -O0-c GHC/Base.lhs -o GHC/Base.o -ohi
| GHC/Base.hi
|
|
|
| What is wrong in Base.hcr is that there are multiple bindings sharing
| the same name. I guess that this has something to do the the
generation
| of unique binding names.
|
|
| Here is an example, where tpl is bound multiple times, line 63 in
Base.hcr:
|
|GHCziBase.zsze :: %forall a . GHCziBase.ZCTEq a -
| a - a - GHCziBase.Bool =
| \ @ a (tpl::GHCziBase.ZCTEq a) -
| %case tpl %of (tpl::GHCziBase.ZCTEq a)
| {GHCziBase.ZCDEq
| (tpl::a - a - GHCziBase.Bool) (tpl::a - a -
GHCziBase.Bool) -
|tpl};
|
|
|
|
| Sincerely,
| 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: Yet another External Core bug
| The attached file (generated by running ghc -fext-core on the Fibheaps | benchmark from the nofib suite) fails to typecheck: | | $ ghc -dcore-lint Fibheaps.hcr | | Couldn't match `#' against `*' | Expected kind: # | Inferred kind: * | When checking kinds in `GHC.Prim.(-) (GHC.Prim.State# s)' I've found what's going on here. Here is the comment from the definition of the type constructor for (-): funTyCon = mkFunTyCon funTyConName (mkArrowKinds [liftedTypeKind, liftedTypeKind] liftedTypeKind) -- You might think that (-) should have type (? - ? - *), and you'd be right -- But if we do that we get kind errors when saying -- instance Control.Arrow (-) -- becuase the expected kind is (*-*-*). The trouble is that the -- expected/actual stuff in the unifier does not go contra-variant, whereas -- the kind sub-typing does. Sigh. It really only matters if you use (-) in -- a prefix way, thus: (-) Int# Int#. And this is unusual. In short, it's really a bug, but not a particularly easy one to fix. Rumination required. But it probably only happens on a few programs, right? S ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: evaluation fault in ghci.
The interactive loop of ghci displays an interesting evaluation fault to do with derived equality. In the attached source file, there is a simple guard which tests some equalities, and basically the same value is given on the left and right of the (==). Yet, it evaluates to False in interactive mode, whereas it (correctly) evaluates to True when compiled. $ ghci ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 5.04.2, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. Loading package haskell98 ... linking ... done. Prelude :l Small Compiling Main ( Small.hs, interpreted ) Ok, modules loaded: Main. *Main main *** Exception: Four.bceFour: precondition fails:arrows not parallel f = E g = E Nice bug. We've fixed it in CVS, but I fear the changes are too large to backport. The workaround is to define your own instance of Eq. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-657462 ] internal error: EVACUATED object entered
Bugs item #657462, was opened at 2002-12-22 11:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=657462group_id=8032 Category: None Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Simon Marlow (simonmar) Summary: internal error: EVACUATED object entered Initial Comment: Submitter: [EMAIL PROTECTED] The compiled program fails with: internal error: EVACUATED object entered! Please report this as a bug to [EMAIL PROTECTED], or http://www.sourceforge.net/projects/ghc/ This happens on FreeBSD 4.7/x86 with at least compiler versions 5.04.1 and 5.05, but not on Mac OS X. Compiling with -O or -fvia-C does not help. -- Comment By: Simon Marlow (simonmar) Date: 2003-01-24 15:26 Message: Logged In: YES user_id=48280 This one is now fixed. -- Comment By: Simon Marlow (simonmar) Date: 2002-12-23 10:21 Message: Logged In: YES user_id=48280 Could you attach the program please? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=657462group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Porting mips-sgi-irix65 [help]
As pointed Michael Weber in a sparc-unknown-linux porting,the key point is gcc on sparc-linux (mips-irix) doesn't mark the beginning of .data(like data_start on i386-linux) . Using etext is definitely wrong here, since .rodata comes afterwards and therefore etext doesn't cover the infotables for static-closures You may be interested to know that recent CVS versions of GHC don't have the requirement that the section boundaries need to be known. You'll undoubtedly find it easier to port newer versions (although in order to bootstrap you might need to start from an older version...). Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Profiling trouble
Hello,
Please help me understanding GHC 5.02.2 profiling output!
Here is the root of my program (Show.hs):
\begin{code}
showData:: BaseVector a = Params - Operator a - String
showData params pot = unlines [Version 3.1,
,
showParams pot params,
tcsdim: ++ tcsDim,
,
conformal energies:,
diagonals,
perturbation matrix:] ++
matrixElements
where
cutStates = {-# SCC showData1 #-} getStates params
tcsDim = {-# SCC showData2 #-} show (length cutStates)
diagonals = {-# SCC showData3 #-} unlines $ map (show .
energy) cutStates
matrixElements = {-# SCC showData4 #-} unlines $ map unwords off
off = {-# SCC showData5 #-} [map (myShow . pot outV)
(take i cutStates)
| (outV,i) - zip cutStates [1..]]
main= do params - option
putStr $ showData params (superPot params)
\end{code}
If I compile it via
ghc -package util -o show --make Show.hs -prof -auto-all
I get in show.prof:
Fri Jan 24 17:46 2003 Time and Allocation Profiling Report (Final)
show +RTS -p -RTS -c 5 -s R -p 0 -t 0 -r 3
total time = 94.54 secs (4727 ticks @ 20 ms)
total alloc = 2,313,980,136 bytes (excludes profiling overheads)
COST CENTRE MODULE %time %alloc
showData1Main86.1 88.5
cutAbove4Tcsa 3.61.5
ncEpsEpsilon 3.33.1
GC GC 2.20.0
vopMode Boson1.51.1
ncVopBoson1.21.0
getStatesTcsa 0.61.2
individual inherited
COST CENTRE MODULE entries %time %alloc %time %alloc
MAIN MAIN 00.0 0.0100.0 100.0
mainMain 00.1 0.0100.0 100.0
[...]
showData Main 10.0 0.0 91.1 91.9
showData5 Main 10.0 0.0 0.3 0.4
myShow Main 94530.3 0.3 0.3 0.3
showData4 Main 10.0 0.1 0.0 0.1
showData3 Main 10.1 0.1 0.1 0.1
showData1 Main 1 86.1 88.5 90.8 91.4
cutAbove Tcsa280.0 0.0 3.6 1.5
cutAbove2 Tcsa 10.0 0.0 0.0 0.0
cutAbove3 Tcsa270.0 0.0 0.0 0.0
cutAbove4 Tcsa283.6 1.5 3.6 1.5
spinSelect Tcsa 10.0 0.0 0.0 0.0
getStatesTcsa 10.6 1.2 1.0 1.4
incrementalBase Fermion 10.3 0.2 0.4 0.2
fermionNumber Fermion 776640.1 0.0 0.1 0.0
allTowers Boson10.0 0.0 0.0 0.0
inModule Boson 170.0 0.0 0.0 0.0
mergeUp Boson60.0 0.0 0.0 0.0
showData2 Main 10.0 0.0 0.0 0.0
[...]
My question: showData1 is a single function call, how can it
still have such a big individual share? Where is the
program spending its time? Sorry if it is a trivial
question, functional profiling is new to me.
Thanks: Feri.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Problem with --split-objs on windoze (when building HOpenGL)
I'm having some difficulties with the --split-objs parameter when building HOpenGL on win xp ine with --disable-split-objs. Tried uninstalling my 'normal' copy of perl upgrading GHC to 5.04.2 but am still getting the same error. Couldn't find anything in the archives, so anyone got any ideas?? $ make Recursively making `all' in lib examples ... PWD = /usr/local/HOpenGL-1.04 make all - --unix; in /usr/local/HOpenGL-1.04/lib rm -f GL_Marshal.o ; if [ ! -d GL_Marshal_split ]; then mkdir GL_Marshal_split; else find GL_Marshal_split -name '*.o' -print | xargs -s 8000 rm -f __rm_food ; fi ; /cygdrive/c/ghc/ghc-5.04.1/bin/ghc -package lang -package-name HOpenGL -i../GL UT -I../GLUT/include -cpp -DCALLCONV=stdcall -split-objs -odir GL_Marshal_split -fglasgow-exts -#include GL/glut.h -O -c GL_Marshal.hs -o GL_Marshal.o Can't locate utf8.pm in @INC (@INC contains: .) at c:\ghc\ghc-5.04.1\ghc-split l ine 50, TMPI line 7. BEGIN failed--compilation aborted, TMPI line 7. make[1]: *** [GL_Marshal.o] Error 1make: *** [all] Error 1 Peter At 01:10 PM 24/01/2003 +0100, Sven Panne wrote: Peter Smith wrote: I'm getting the following error when running make all/make install (make depend worked fine). I'm building on windoze xp home, GHC5.04.1, cygwin. Any ideas? [...] Hmmm, this looks like a GHC/Perl installation problem (GHC uses Perl e.g. for -split-objs). A few questions: * Can you compile and link a simple HelloWorld.hs with -O? * Can you do the same with -O *and* -split-objs? * Does HOpenGL work when configure is called with --disable-split-objs? Cheers, S. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Lazy evaluation alternative
I wonder if I could run an idea I've had by this list. It seems to me you could get some of the desired effects of lazy evaluation by using continuation passing style in code. For example, take this psuedo-code using CPS to represent an infinite data type. Using non-CPS this would be something like: ones = 1 : ones using strict evaluation this would lead to an infinite loop. However using CPS this could be represented as: ones c = c (1 : ones) where c is the continuation. This would not infinite loop as ones is still waiting for the continuation argument. Another example: natural n c = c (n : natural n+1) Again no infinite recursion! What do you think? Please CC me in any reply. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Lazy evaluation alternative
Chris Clearwater wrote: It seems to me you could get some of the desired effects of lazy evaluation by using continuation passing style in code. For example, take this psuedo-code using CPS to represent an infinite data type. Using non-CPS this would be something like: ones = 1 : ones using strict evaluation this would lead to an infinite loop. However using CPS this could be represented as: ones c = c (1 : ones) where c is the continuation. This would not infinite loop as ones is still waiting for the continuation argument. Another example: natural n c = c (n : natural n+1) Hey, Maestro, why don't you check before posting, hm? What is the type of ones? I am afraid you will get a nasty surprise... ... BTW, are you sure there aren't any missing parentheses in the def. of natural? (But they won't help anyway...) Jerzy Karczmarczuk ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Lazy evaluation alternative
I wonder if I could run an idea I've had by this list. It seems to me you could get some of the desired effects of lazy evaluation by using continuation passing style in code. For example, take this psuedo-code using CPS to represent an infinite data type. Using non-CPS this would be something like: ones = 1 : ones using strict evaluation this would lead to an infinite loop. However using CPS this could be represented as: ones c = c (1 : ones) where c is the continuation. This would not infinite loops as ones is still waiting for the continuation argument. Another example: natural n c = c (n : natural n+1) Again no infinite recursion! What do you think? Please CC me in any reply. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Lazy evaluation alternative
fre 2003-01-24 klockan 13.21 skrev Chris Clearwater: I wonder if I could run an idea I've had by this list. It seems to me you could get some of the desired effects of lazy evaluation by using continuation passing style in code. For example, take this psuedo-code using CPS to represent an infinite data type. Yes, you can simulate lazy evaluation. But the point is that we don't want to simulate it, we want it built-in into the language, for optimization purposes. Regards, Martin -- Martin Norbäck [EMAIL PROTECTED] Kapplandsgatan 40 +46 (0)708 26 33 60 S-414 78 GÖTEBORG http://www.dtek.chalmers.se/~d95mback/ SWEDEN OpenPGP ID: 3FA8580B ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Lazy evaluation alternative
On Fri, Jan 24, 2003 at 01:51:57PM +0100, Jerzy Karczmarczuk wrote: Chris Clearwater wrote: It seems to me you could get some of the desired effects of lazy evaluation by using continuation passing style in code. For example, take this psuedo-code using CPS to represent an infinite data type. Using non-CPS this would be something like: ones = 1 : ones using strict evaluation this would lead to an infinite loop. However using CPS this could be represented as: ones c = c (1 : ones) where c is the continuation. This would not infinite loop as ones is still waiting for the continuation argument. Another example: natural n c = c (n : natural n+1) Hey, Maestro, why don't you check before posting, hm? What is the type of ones? I am afraid you will get a nasty surprise... Check what, the type? Or are you refering to the double posting? My first message got rejected as I was not a member of the list so I subscribed and reposted. It seems the moderator put it through anyways. It seems the type would recursive? Is it that a problem? Enlighten me? :) ... BTW, are you sure there aren't any missing parentheses in the def. of natural? (But they won't help anyway...) Yes I am. But the + should be in CPS form anyways to be perfectly correct, so: natural n c = (+) n 1 (\m - c n : (natural m)) Jerzy Karczmarczuk ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Lazy evaluation alternative
On Fri, Jan 24, 2003 at 03:07:48PM +0100, Thomas Johnsson wrote: Yes I am. But the + should be in CPS form anyways to be perfectly correct, so: natural n c = (+) n 1 (\m - c n : (natural m)) I think Jerzy (in his usual polite manner :-) refers to the every group has it's moshez (don't ask :) cons operator, the :, which in a strongly typed language the right argument, the tail, is required to be a list. The function is declared as natural n c = ..., so (natural m) must be a funcion. Well, let's pretend I made my own datatype then that supports the right type class interfaces, and has a function as a tail :) But also, this brings me to another idea! Data structures should be built from lambdas and CPS! For example, a list of integers: 1 : 2 : 3 list = \c - c 1 (\c - c 2 nil) now: natural n c = c n (natural n+1) full blown CPS: natural n c = (+) n 1 (\m - c n (natural m)) so, here (nautral m) _is_ a list just like the above list! Might I guess that you come from the lisp / scheme world? No. :) Regards, -- Thomas ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Lazy evaluation alternative
Chris == Chris Clearwater [EMAIL PROTECTED] writes: Chris But also, this brings me to another idea! Data structures Chris should be built from lambdas and CPS! For example, a list Chris of integers: 1 : 2 : 3 Chris list = \c - c 1 (\c - c 2 nil) How about just: cons hd tl = \ c - c hd tl then we could write the usual accessors: head xs = xs (\ hd tl - hd) tail xs = xs (\ hd tl - tl) This is a very, very old idea. -- Kevin S. Millikin Architecture Technology Corporation Research Scientist Specialists in Computer Architecture (952)829-5864 x. 162 http://www.atcorp.com ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Lazy evaluation alternative
Chris == Chris Clearwater [EMAIL PROTECTED] writes: Chris LIAR. You want to steal my idea for yourself! It's MINE! :) I hate to be the one to break it to you, but we used to routinely show this trick to Intro to CS students. Chris But anyways, it was to show that when a list is defined Chris like that, (natural m) becomes a list itself because it is Chris of the form: \c - c hd tl after partial evaluation. Yes. But it's not the CPS that delays evaluation, it's just the lambda. Switching to a strict language, Scheme, one would write: (define ones (lambda () (cons 1 ones))) Explicitly delaying the evaluation of (cons 1 ones) by putting it under a lambda. We *could* perform the CPS translation, but it's not necessary to delay evaluation, lambda does that all by itself. ones #procedure (ones) (1 . #procedure) (cdr (ones)) #procedure ((cdr (ones))) (1 . #procedure) Of course, if we wanted *lazy* evaluation, we would want to avoid performing the cons more than once if it is demanded more than once. We have to use something other than lambda for that: (define ones (delay (begin (printf forcing...~n) (cons 1 ones ones #procedure (force ones) forcing... (1 . #procedure) (force ones) (1 . #procedure) (cdr (force ones)) #procedure (force (cdr (force ones))) (1 . #procedure) Notice how many times (cons 1 ones) got evaluated. So your trick *is* used to implement lazy evaluation in other languages. It's not very pleasant if you write a lot of lazy code, because you have to explicitly suspend evaluation of values using delay and explicitly demand evaluation using force. Thus, we have lazy languages that make the laziness implicit. -- Kevin S. Millikin Architecture Technology Corporation Research Scientist Specialists in Computer Architecture (952)829-5864 x. 162 http://www.atcorp.com ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Lazy evaluation alternative
Chris Clearwater wrote: On Fri, Jan 24, 2003 at 01:51:57PM +0100, Jerzy Karczmarczuk wrote: Hey, Maestro, why don't you check before posting, hm? What is the type of ones? I am afraid you will get a nasty surprise... Check what, the type? Or are you refering to the double posting?... It seems the type would recursive? Is it that a problem? Enlighten me? :) Whatever some gentlemen impute about my politeness (as below), I don't react to double postings, because such things happen to everybody. Of course I commented the fact that you sent a a Haskell expression to a quite wide audience before attempting to ask :t Hugs or GHCi. Here you are their answers. If: ones c = c (1:ones) then the answers are, GHCi, then Hugs: claz.hs:1: Couldn't match `[a]' against `(t1 - t2) - t' Expected type: [a] Inferred type: (t1 - t2) - t In the second argument of `(:)', namely `ones' In the first argument of `c', namely `(1 : ones)' ** Type checking ERROR claz.hs:1 - Type error in function binding *** Term : ones *** Type : ([a] - b) - b *** Does not match : [a] Now, simply: it costs really nothing to check that, and BTW the result is almost obvious when you look at (1:ones). (Note that Ghci and Hugs give slightly different answers...) You might construct a tree, or just for testing replace (1:ones) by (1,ones), but I suspect that then you will get the infinite recursion in type definition. CPS is delicate... Next posting: On Fri, Jan 24, 2003 at 03:07:48PM +0100, Thomas Johnsson wrote: ... I think Jerzy (in his usual polite manner :-) refers to the every group has it's moshez (don't ask :) cons operator, the :, which in a strongly typed language the right argument, the tail, is required to be a list. ... Well, let's pretend I made my own datatype then that supports the right type class interfaces, and has a function as a tail :) I must confess that I don't know what moshez are, but I won't ask. Thanks to both of you for a new English word I learned. I suspect that the infinite type unification gets in the way anyhow. You can define your 'ones' in, say, Scheme, but this is clumsy, much less transparent than using macros (delay, cons-stream, etc.), or just the lambda-ification, as proposed by Kevin Millikin. It is not even clear *to what* you should apply your continuation. However, Kevin S Millikin is too pessimistic about So your trick *is* used to implement lazy evaluation in other languages. It's not very pleasant if you write a lot of lazy code, because you have to explicitly suspend evaluation of values using delay and explicitly demand evaluation using force. because if macros are there, all the administrative chores can be hidden. Hm. By the way, the fact that Haskell has no macros was a conscious decision, or by default, because nobody needed them? On the other hand, there are languages where the construction and processing of objects representing lazy streams is different, uses *generators* (Smalltalk, Icon, Python); they are not functions, but 'objects' with an internal updateable state and a 'method' next or equivalent. They can also be simulated in Haskell. === I suppose that it would be better to move this thread to haskell-café. Jerzy Karczmarczuk ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Lazy evaluation alternative
On Fri, 24 Jan 2003 09:18:47 -0600 Kevin S. Millikin [EMAIL PROTECTED] wrote: So your trick *is* used to implement lazy evaluation in other languages. It's not very pleasant if you write a lot of lazy code, because you have to explicitly suspend evaluation of values using delay and explicitly demand evaluation using force. In ocaml, there is the lazy module, that does exactly the simulation of lazynes with lambda abstractions. Vince ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Lazy evaluation alternative
On Fri, Jan 24, 2003 at 09:18:47AM -0600, Kevin S. Millikin wrote: Chris == Chris Clearwater [EMAIL PROTECTED] writes: Chris LIAR. You want to steal my idea for yourself! It's MINE! :) I hate to be the one to break it to you, but we used to routinely show this trick to Intro to CS students. Sarcasm, Kevin, sarcasm. :) Chris But anyways, it was to show that when a list is defined Chris like that, (natural m) becomes a list itself because it is Chris of the form: \c - c hd tl after partial evaluation. Yes. But it's not the CPS that delays evaluation, it's just the lambda. Switching to a strict language, Scheme, one would write: (define ones (lambda () (cons 1 ones))) Explicitly delaying the evaluation of (cons 1 ones) by putting it under a lambda. We *could* perform the CPS translation, but it's not necessary to delay evaluation, lambda does that all by itself. The difference is with the CPS way it is implicit. For example take the Y combinator written using both methods (again this is pseduo code, not intended to be real haskell code or run in hugs) Using the lambda way: Y f = f (lazy Y f) Then writing ones would be something like: ones_fix f = 1:(force f) Now the CPS way: Y f c = c (f (Y f)) Now writing ones: ones_fix f c = c 1:f Notice how the CPS way behaves as if it were actually passed itself, while the lambda way behaves as if it were passed itself quoted with lambda. The lambda way seems like a hack while the CPS way feels consistant. And yes, I still realize that a list can't have a function as a tail. Pretend it is a custom datatype with a function as a tail. If you want real code, here is some proof of concept python: Y = lambda f: lambda c: c(f(Y(f))) ones_fix = lambda f: lambda c: c(1, f) def output(hd, tl): print hd, tl Y(ones_fix)(lambda ones: ones(output)) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
hot queue implementation
Does anyone have an implementation of hot (heap on top) priority queues in Haskell (or perhaps ML)? Thanks! - Hal -- Hal Daume III Computer science is no more about computers| [EMAIL PROTECTED] than astronomy is about telescopes. -Dijkstra | www.isi.edu/~hdaume ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
seeking ideas for short lecture on type classes
In a fit of madness, I have agreed to deliver a 50-minute lecture on type classes to an audience of undergraduate students. These students will have seen some simple typing rules for F2 and will have some exposure to Hindley-Milner type inference in the context of ML. I am soliciting advice about * Cool examples of type classes * Papers I could read to explain how to implement type classes, especially if I could show the `dictionary translation' which is then followed by ordinary Hindley-Milner type inference * Any other material on which I might base such a lecture I'm especially in need of a guide to the literature, as the `Haskell bookshelf' at haskell.org is silent on the topic of type classes. Please send me your recommendations. Norman Ramsey ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: seeking ideas for short lecture on type classes
--- Norman Ramsey [EMAIL PROTECTED] wrote: In a fit of madness, I have agreed to deliver a 50-minute lecture on type classes to an audience of undergraduate students. These students will have seen some simple typing rules for F2 and will have some exposure to Hindley-Milner type inference in the context of ML. I am soliciting advice about * Cool examples of type classes * Papers I could read to explain how to implement type classes, especially if I could show the `dictionary translation' which is then followed by ordinary Hindley-Milner type inference * Any other material on which I might base such a lecture I'm especially in need of a guide to the literature, as the `Haskell bookshelf' at haskell.org is silent on the topic of type classes. http://www.research.avayalabs.com/user/wadler/topics/type-classes.html http://www.dcs.qmul.ac.uk/SEL-HPC/Articles/GeneratedHtml/functional.imptype.html http://haskell.readscheme.org/lang_sem.html = Christopher Milton [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: seeking ideas for short lecture on type classes
G'day all. On Fri, Jan 24, 2003 at 06:13:29PM -0500, Norman Ramsey wrote: In a fit of madness, I have agreed to deliver a 50-minute lecture on type classes to an audience of undergraduate students. These students will have seen some simple typing rules for F2 and will have some exposure to Hindley-Milner type inference in the context of ML. Will they have had exposure to more traditional OO programming? If so, it might be useful to note the difference between Haskell type classes and C++/Java/whatever classes, namely that Haskell decouples types and the interfaces that they support. The advantage is that you can extend a type with a new interface at any point, not just when you define the type. Cheers, Andrew Bromage ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Last Call for Papers: Deadline February 7
-- Call for Papers SAS '03 10th Annual International Static Analysis Symposium June 11-13, 2003 : San Diego, California http://www.lix.polytechnique.fr/~radhia/sas03/index.html ACM Federated Computing Research Conference FCRC 2003 http://www.acm.org/sigs/conferences/fcrc/ -- Static Analysis is increasingly recognized as a fundamental tool for high performance implementations and verification systems of programming languages. The series of Static Analysis Symposia has served as the primary venue for presentation of theoretical, practical, and application advances in the area. The 10th International Static Analysis Symposium SAS'03 will be held at the Town and Country Resort Conference Center in San Diego (USA) as part of the Federated Computing Research Conference FCRC 2003. Previous symposia were held in Madrid, Paris, Santa Barbara, Venice, Pisa, Paris, Aachen, Glasgow and Namur. The technical program for SAS'03 will consist of invited lectures, tutorials, panels, presentations of refereed papers, and software demonstrations. Contributions are welcome on all aspects of Static Analysis, including, but not limited to: abstract interpretation, data flow analysis, verification systems, program transformation, abstract domains, optimizing compilers, theoretical frameworks,type inference, abstract model checking, complexity analysis, abstract testing, security analysis, mobile code, hardware systems, distributed systems, embedded systems. Submissions can address any programming paradigm, including concurrent, constraint, functional, imperative, logic and object-oriented programming. Survey papers that present some aspect of the above topics with a new coherence are also welcome. Papers must describe original work, be written and presented in English, and must not substantially overlap with papers that have been published or that are simultaneously submitted to a journal or a conference with refereed proceedings. Submission instructions: All submissions must be performed electronically at http://www.lix.polytechnique.fr/~radhia/sas03/submission.html. Submitted papers should be at most 15 pages excluding bibliography and well-marked appendices. Program committee members are not required to read the appendices, and thus papers should be intelligible without them. Publication: The proceedings will be published by Springer in the Lecture Notes in Computer Science series (see http://www.springer.de/comp/lncs/authors.html for the LNCS Author's Instructions). Thus, adhering to that style already in the submission is strongly encouraged. Papers should be submitted either in PostScript or PDF format and they should be interpretable by Ghostscript or Acrobat Reader. Papers must be printable on either A4 paper or US letter, and preferably on both. Selected papers will be published in a special issue of a journal. Important dates: Deadline for submissions : February 7, 2003. Notification : March 18, 2003. Deadline for reception of the final versions : March 30, 2003. The conference : June 11-13, 2003. Program Committee: Radhia Cousot (Chair) CNRS and Ecole polytechnique, France Alex Aiken University of California, Berkeley, USA Luddy Harrison Intel Corporation, USA Susan Horwitz University of Wisconsin-Madison, USA Andy King University of Kent, UK Giorgio LeviUniversity of Pisa, Italy Michael Lowry NASA Ames Research Center, USA Laurent Mauborgne Ecole normale superieure, France Alan MycroftCambridge University, UK Germán Puebla Technical University of Madrid, Spain Francesco Ranzato University of Padova, Italy Shmuel SagivTel-Aviv University, Israel David Sands Chalmers U. and U. of Goteborg, Sweden Helmut SeidlUniversity of Trier, Germany Mary Lou Soffa University of Pittsburgh, USA Harald Søndergaard University of Melbourne, Australia Contact info: [EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Lazy evaluation alternative
Chris == Chris Clearwater [EMAIL PROTECTED] writes: Chris Sarcasm, Kevin, sarcasm. :) Why is it that those who most need to point out that they were joking are least able to see it in others? Chris The difference is with the CPS way it is implicit. For Chris example take the Y combinator written using both methods Chris (again this is pseduo code, not intended to be real haskell Chris code or run in hugs) That's a funny definition of implicit. All you need to delay evaluation is lambda. You're performing a CPS transformation as a way to insert a lambda in the proper place. BUT THAT'S NOT NECESSARY. Just write the lambda where you want it. You don't need to abstract over a continuation to delay evaluation, you can abstract over anything at all (it doesn't matter what). And you only ever apply the most recent continuation (notice how you could use the identifier c for every one of your continuations?). You don't have to apply c to pass a value to the current continuation, there's alread a way to do that: just return the value. Chris Using the lambda way: Y f = f (lazy Y f) Then writing ones Chris would be something like: ones_fix f = 1:(force f) Chris Now the CPS way: Y f c = c (f (Y f)) Now writing ones: Chris ones_fix f c = c 1:f Your translation is wrong. Here's the correct lambda way (in the same pseudo functional language): Y f = \ () - f (Y f) where I didn't presume any delay or lazy macro. Here's ones_fix: ones_fix f = \ () - 1 : f Compare to: Y f = \ c - c (f (Y f)) ones_fix f = \ c - c (1 : f) Which one seems to be more implicit? Where you abstract over a continuation to delay evaluation, I abstract over anything I feel like. Where you apply a continuation to a value, I just return a value. Where you would pass in a continuation to a CPSed function, I would just apply the result to some suitable token (unless I had zero argument functions) (that is, I would force an expression wherever you would pass a continuation to a CPSed function). You've performed a CPS transformation, but you never do anything *interesting* with the continuation. That might suggest that, whatever you seem to have achieved, it didn't come from the CPS transformation. Chris Notice how the CPS way behaves as if it were actually Chris passed itself, while the lambda way behaves as if it were Chris passed itself quoted with lambda. The lambda way seems Chris like a hack while the CPS way feels consistant. I guess I don't understand. Change \ c - to \ () -. Remove the application of every c. Change occurrences of c in argument position to (). -- Kevin S. Millikin Architecture Technology Corporation Research Scientist Specialists in Computer Architecture (952)829-5864 x. 162 http://www.atcorp.com ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Exeption handling in GHC
You're probably using IO (or System.IO) try. If you want imprecise exceptions (I think that's the right name), you want to use Control.Exception versions of try/catch/bracket/etc. Prelude :m IO Prelude IO :t try forall a. IO a - IO (Either GHC.IOBase.Exception a) Prelude IO try (error a) *** Exception: a Prelude IO :m Control.Exception Prelude Control.Exception try (error a) Prelude Control.Exception it Left a HTH - Hal -- Hal Daume III Computer science is no more about computers| [EMAIL PROTECTED] than astronomy is about telescopes. -Dijkstra | www.isi.edu/~hdaume On Fri, 24 Jan 2003, Sarah Thompson wrote: Hi all, I'm trying to get exception handling working in GHC, but don't seem to be able to make it work. Am I likely to be missing a compiler switch, or something? Cutting things down to basics, I'd have thought that the following expression (typed at the ghci command prompt) should work: try (error x) but the result is *** Exception: x I seem to get the same problem with compiled code. Any ideas anyone? TIA, Sarah ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: Exception handling in GHC
I've noticed some interesting behaviour: Prelude Control.Exception try (return (error e)) Prelude Control.Exception it Right *** Exception: e It would appear that when the result of this function is evaluated, the exception fires during evaluation, after the try is out of scope. I suppose it makes some kind of twisted sense due to lazy evaluation going on, but it is certainly a gotcha. I did notice this: Prelude Control.Exception try (return $! (error e)) Prelude Control.Exception it Left e Seemingly, forcing strict evaluation on the argument of return fixes the problem by making sure that any exception that *can* happen, *does* happen. However, this code from my COM wrapper: --[id(3)] HRESULT XmlQuery([in,string] BSTR query, [out,retval]BSTR* xml); xmlQuery :: String - State - IO String xmlQuery qry (State st) = do db - readIORef st Control.Exception.catch (return $! (XMLDatabase.xmlQuery qry db)) (\ _ - return error description=\Parse error\/) doesn't work. If XMLDatabase.xmlQuery throws an exception, the COM wrapper still terminates the host application (Yes, Sigbjorn - I did apply your patch to HDirect, but it seemed to make no difference). I'm still a bit stuck here! Sarah ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Exception handling in GHC - ThrowCatch.hs (1/1)
In article [EMAIL PROTECTED],
Sarah Thompson [EMAIL PROTECTED] wrote:
I've noticed some interesting behaviour:
Prelude Control.Exception try (return (error e))
Prelude Control.Exception it
Right *** Exception: e
It would appear that when the result of this function is evaluated, the
exception fires during evaluation, after the try is out of scope. I suppose
it makes some kind of twisted sense due to lazy evaluation going on, but it
is certainly a gotcha.
You might be interested in this program to investigate what catches
what. Your example corresponds to the line
Control.Exception.catch MISSED return error
Here's is the full output:
CAUGHT return
CAUGHT return undefined
CAUGHT return Control.Exception.throw
CAUGHT return error
MISSED fail
MISSED error
MISSED Control.Exception.throw
MISSED ioError ErrorCall
MISSED ioError IOException
MISSED undefined
Prelude.catch MISSED return
Prelude.catch MISSED return undefined
Prelude.catch MISSED return Control.Exception.throw
Prelude.catch MISSED return error
Prelude.catch CAUGHT fail
Prelude.catch MISSED error
Prelude.catch MISSED Control.Exception.throw
Prelude.catch MISSED ioError ErrorCall
Prelude.catch CAUGHT ioError IOException
Prelude.catch MISSED undefined
Control.Exception.catch MISSED return
Control.Exception.catch MISSED return undefined
Control.Exception.catch MISSED return Control.Exception.throw
Control.Exception.catch MISSED return error
Control.Exception.catch CAUGHT fail
Control.Exception.catch CAUGHT error
Control.Exception.catch CAUGHT Control.Exception.throw
Control.Exception.catch CAUGHT ioError ErrorCall
Control.Exception.catch CAUGHT ioError IOException
Control.Exception.catch CAUGHT undefined
Control.Exception.finally CAUGHT return
Control.Exception.finally CAUGHT return undefined
Control.Exception.finally CAUGHT return Control.Exception.throw
Control.Exception.finally CAUGHT return error
Control.Exception.finally CAUGHT fail
Control.Exception.finally CAUGHT error
Control.Exception.finally CAUGHT Control.Exception.throw
Control.Exception.finally CAUGHT ioError ErrorCall
Control.Exception.finally CAUGHT ioError IOException
Control.Exception.finally CAUGHT undefined
--
Ashley Yakeley, Seattle WA
-- ghc ThrowCatch.hs -o ThrowCatch ./ThrowCatch
module Main where
{
import qualified Control.Exception;
import Data.IORef;
import Prelude;
safeCatch :: IO () - IO ();
safeCatch f = Control.Exception.catch f (\_ - return ());
type Thrower = IO Bool;
type Catcher = IO Bool - IO () - IO ();
checkCatch :: Catcher - Thrower - IO Bool;
checkCatch catcher thrower = do
{
ref - newIORef False;
safeCatch (catcher thrower (writeIORef ref True));
readIORef ref;
};
data Named a = MkNamed String a;
checkNamedCatch :: Named Catcher - Named Thrower - IO ();
checkNamedCatch (MkNamed cname catcher) (MkNamed tname thrower) = do
{
didCatch - checkCatch catcher thrower;
putStrLn (cname ++ (if didCatch then CAUGHT else MISSED ) ++
tname);
};
checkNamedCatches :: [Named Catcher] - [Named Thrower] - IO ();
checkNamedCatches [] _ = return ();
checkNamedCatches _ [] = return ();
checkNamedCatches [c] (t:tr) = do
{
checkNamedCatch c t;
checkNamedCatches [c] tr;
};
checkNamedCatches (c:cr) ts = do
{
checkNamedCatches [c] ts;
checkNamedCatches cr ts
};
-- throwers
returnThrower :: Named Thrower;
returnThrower = MkNamed return (return True);
returnUndefinedThrower :: Named Thrower;
returnUndefinedThrower = MkNamed return undefined (return undefined);
returnErrorThrower :: Named Thrower;
returnErrorThrower = MkNamed return error (return (error some error));
undefinedThrower :: Named Thrower;
undefinedThrower = MkNamed undefined undefined;
failThrower :: Named Thrower;
failThrower = MkNamed fail (fail some failure);
errorThrower :: Named Thrower;
errorThrower = MkNamed error (error some error);
throwThrower :: Named Thrower;
throwThrower = MkNamed Control.Exception.throw
(Control.Exception.throw (Control.Exception.ErrorCall throw error));
ioErrorErrorCallThrower :: Named Thrower;
ioErrorErrorCallThrower = MkNamed ioError ErrorCall
(ioError (Control.Exception.ErrorCall throw error));
ioErrorIOExceptionThrower :: Named Thrower;
ioErrorIOExceptionThrower = MkNamed ioError IOException
(ioError (Control.Exception.IOException undefined));
returnThrowThrower :: Named Thrower;
returnThrowThrower = MkNamed return Control.Exception.throw
Re: Exception handling in GHC - ThrowCatch.hs (1/1)
I wrote: -- Ashley Yakeley, Seattle WA -- ghc ThrowCatch.hs -o ThrowCatch ./ThrowCatch module Main where Sorry, I was expecting my UA to attach the file rather than append it. But there it is anyway. -- Ashley Yakeley, Seattle WA ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: Exception handling in GHC
On Fri, 24 Jan 2003, Sarah Thompson wrote: I've noticed some interesting behaviour: Prelude Control.Exception try (return (error e)) Prelude Control.Exception it Right *** Exception: e It would appear that when the result of this function is evaluated, the exception fires during evaluation, after the try is out of scope. I suppose it makes some kind of twisted sense due to lazy evaluation going on, but it is certainly a gotcha. I did notice this: Prelude Control.Exception try (return $! (error e)) Prelude Control.Exception it Left e Seemingly, forcing strict evaluation on the argument of return fixes the problem by making sure that any exception that *can* happen, *does* happen. However, this code from my COM wrapper: --[id(3)] HRESULT XmlQuery([in,string] BSTR query, [out,retval]BSTR* xml); xmlQuery :: String - State - IO String xmlQuery qry (State st) = do db - readIORef st Control.Exception.catch (return $! (XMLDatabase.xmlQuery qry db)) (\ _ - return error description=\Parse error\/) doesn't work. If XMLDatabase.xmlQuery throws an exception, the COM wrapper still terminates the host application (Yes, Sigbjorn - I did apply your patch to HDirect, but it seemed to make no difference). Your COM wrapper code probably behaves differently because the error is not evoked at the very top level. Note that `seq` (and hence ($!)) only force evaluation to weak head normal form, which essentially means only enough to determine the top-level constructor. You may need to evaluate more deeply. Check out `DeepSeq` (http://haskell.org/pipermail/haskell/2001-August/001586.html) and/or strategies (http://www.mail-archive.com/haskell@haskell.org/msg09543/Strategies.lhs). I'm still a bit stuck here! Sarah Dean ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: Exception handling in GHC
Your COM wrapper code probably behaves differently because the error is not evoked at the very top level. Note that `seq` (and hence ($!)) only force evaluation to weak head normal form, which essentially means only enough to determine the top-level constructor. You may need to evaluate more deeply. Check out `DeepSeq` (http://haskell.org/pipermail/haskell/2001-August/001586.html) and/or strategies (http://www.mail-archive.com/haskell@haskell.org/msg09543/Strategi es.lhs). DeepSeq fixed it in one go. Brilliant! Many thanks for the help. My COM object now appears to be unreasonably solid regardless of what I throw at it. :) Sarah ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Creating COM objects and passing out pointers to them via a COM interface
Hi again, A slightly harder problem this time. I want to implement something that looks something like the Microsoft XML parser. This is a very COM heavy contraption that provides an interface that looks to client applications like a tree of COM objects that reflects the internal structure of an XML document. The idea is, you start with the document object, make a method call requesting the root node, and have a COM object that wraps that node returned to you. You can then request the children of that node, and their children and siblings, all which involves being passed back interface pointers to COM objects. Effectively, there is one COM object per syntactic item in the XML document. I already have my document object working nicely. This is where the actual database resides. I want to be able to spawn views of this database as COM objects. When I've done this in the past (using ATL mostly, egh), I've used an IDL definition something like HRESULT CreateView([in,string] BSTR query, [out,retval] IDbView **); What's the correct way to implement the necessary Haskell code to create the coclass and return a pointer to it? I fiddled around for ages, but either couldn't get GHC to like the types I was using, or when I finally got it to compile, I found that my test harness was being passed an invalid COM object. This should be simple stuff, so I'm sure someone will have done it! Secondly, it is a nasty, though fairly common trick, if you know your objects are going to be created in the same process space, to allow them some 'behind the scenes' communication. In my case, I'd like to avoid needing to serialise and deserialse the data in a view during creation of these child objects (of which there may be a great many, and which may be created on the fy rather often). Ideally, I'd like to be able to do something like: newView :: String - State - IO State newView db (State st) = do db - readIORef st r - newIORef db -- Insert some kind of COM magic here return (State r) so the database content gets copied within the Haskell environment (lazily, I'd hope), without needing to be serialised and deserialised. Is this feasible? One (messy) approach might be to create a bunch of extra interfaces on the main database object, then create 'thin wrapper' child objects that simply make calls back into the parent object. I'm not so keen on that for various reasons, however. Sarah ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
