[ ghc-Bugs-1275126 ] configure problems with openGL and openAL
Bugs item #1275126, was opened at 2005-08-28 14:47 Message generated for change (Comment added) made by spanne You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1275126group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build System Group: None Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: configure problems with openGL and openAL Initial Comment: I've been compiling the latest GHC snapshot (6.4.1.20050827) from source and have encountered some annoying problems with the configure script not being as intelligent as it should be. This is on a GNU/Linux system running Debian unstable. Initially I didn't have the openGL GLU headers installed so I got a compile error when the glu.h file wasn't found. I believe that since the GLU library was installed, the configure script assumed that the GLU header file would be there -- or else it didn't check. Installing the GLU header files fixed this. Then I got a weird bug while compiling the openAL support in GHC: ==fptools== make all - --no-print-directory -r; in /home/mvanier/lang/useful/haskell/ghc/ghc-6.4.1.20050827/libraries/OpenAL rm -f Sound/OpenAL/ALC/Context.o; if [ ! -d Sound/OpenAL/ALC/Context_split ]; then mkdir Sound/OpenAL /ALC/Context_split; else /usr/bin/find Sound/OpenAL/ALC/Context_split -name '*.o' -print | xargs rm - f __rm_food; fi; ../../ghc/compiler/ghc-inplace -H16m -O -Wall -fffi -Iinclude '-#include HsOpenAL.h' -cpp -DCALLCON V=ccall -ignore-package OpenAL -O -Rghc-timing -fgenerics -package base -package OpenGL -fgenerics -split-objs-c Sound/OpenAL/ALC/Context.hs -o Sound/OpenAL/ALC/Context.o -ohi Sound/OpenAL/ALC/Co ntext.hi /tmp/ghc27232.hc: In function 's33v_ret': /tmp/ghc27232.hc:553: error: void value not ignored as it ought to be /tmp/ghc27232.hc: In function 's33y_ret': /tmp/ghc27232.hc:595: error: void value not ignored as it ought to be ghc: 60654736 bytes, 14 GCs, 2844362/5655392 avg/max bytes residency (3 samples), 18M in use, 0.00 INIT (0.00 elapsed), 0.18 MUT (0.40 elapsed), 0.09 GC (0.12 elapsed) :ghc make[2]: *** [Sound/OpenAL/ALC/Context.o] Error 1 make[1]: *** [all] Error 1 make: *** [build] Error 1 As a result, I disabled openAL support. Mike Vanier [EMAIL PROTECTED] -- Comment By: Sven Panne (spanne) Date: 2005-08-29 22:26 Message: Logged In: YES user_id=50298 Regarding your GLU header problem: This will only happen if you have GL and GLU libraries installed and a GL header, but no GLU header. This is a rather obscure setup which I've never heard before: It is common that you either have a) no GL/GLU stuff at all (OpenGL ignorant system), b) only GL/GLU libraries (OpenGL *user* system), but no header c) GL/GLU libraries and headers (OpenGL *development* system). To avoid making the autoconf magic even more tricky, I declare your setup to be buggy. :-) Seriously: I think the autotools stuff should handle common differences between platforms, but not each and every obscure private setup, otherwise things get unmaintainable. Regarding the OpenAL problem: This is due to changes in the OpenAL API itself, which are already handled in the HEAD. Furthermore, the OpenAL stuff in the STABLE branch is practically unusable, because it is very incomplete. If you want a working and complete OpenAL binding, you can use the HEAD. I'll make no OpenAL the default in STABLE... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1275126group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1276115 ] Unify.unifyTauTyLists: mismatched type lists!
Bugs item #1276115, was opened at 2005-08-29 15:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1276115group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler Group: 6.4 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Unify.unifyTauTyLists: mismatched type lists! Initial Comment: the following simple code - data List elem = Cons elem List | Nil t1 :: List t1 = Cons 1 Nil - causes (loaded within ghci): ghc-6.4: panic! (the `impossible' happened, GHC version 6.4): Unify.unifyTauTyLists: mismatched type lists! Please report it as a compiler bug to glasgow-haskell-bugs@haskell.org, or http://sourceforge.net/projects/ghc/. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1276115group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1275126 ] configure problems with openGL and openAL
Bugs item #1275126, was opened at 2005-08-28 05:47 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1275126group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build System Group: None Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: configure problems with openGL and openAL Initial Comment: I've been compiling the latest GHC snapshot (6.4.1.20050827) from source and have encountered some annoying problems with the configure script not being as intelligent as it should be. This is on a GNU/Linux system running Debian unstable. Initially I didn't have the openGL GLU headers installed so I got a compile error when the glu.h file wasn't found. I believe that since the GLU library was installed, the configure script assumed that the GLU header file would be there -- or else it didn't check. Installing the GLU header files fixed this. Then I got a weird bug while compiling the openAL support in GHC: ==fptools== make all - --no-print-directory -r; in /home/mvanier/lang/useful/haskell/ghc/ghc-6.4.1.20050827/libraries/OpenAL rm -f Sound/OpenAL/ALC/Context.o; if [ ! -d Sound/OpenAL/ALC/Context_split ]; then mkdir Sound/OpenAL /ALC/Context_split; else /usr/bin/find Sound/OpenAL/ALC/Context_split -name '*.o' -print | xargs rm - f __rm_food; fi; ../../ghc/compiler/ghc-inplace -H16m -O -Wall -fffi -Iinclude '-#include HsOpenAL.h' -cpp -DCALLCON V=ccall -ignore-package OpenAL -O -Rghc-timing -fgenerics -package base -package OpenGL -fgenerics -split-objs-c Sound/OpenAL/ALC/Context.hs -o Sound/OpenAL/ALC/Context.o -ohi Sound/OpenAL/ALC/Co ntext.hi /tmp/ghc27232.hc: In function 's33v_ret': /tmp/ghc27232.hc:553: error: void value not ignored as it ought to be /tmp/ghc27232.hc: In function 's33y_ret': /tmp/ghc27232.hc:595: error: void value not ignored as it ought to be ghc: 60654736 bytes, 14 GCs, 2844362/5655392 avg/max bytes residency (3 samples), 18M in use, 0.00 INIT (0.00 elapsed), 0.18 MUT (0.40 elapsed), 0.09 GC (0.12 elapsed) :ghc make[2]: *** [Sound/OpenAL/ALC/Context.o] Error 1 make[1]: *** [all] Error 1 make: *** [build] Error 1 As a result, I disabled openAL support. Mike Vanier [EMAIL PROTECTED] -- Comment By: Nobody/Anonymous (nobody) Date: 2005-08-29 16:53 Message: Logged In: NO It's not a private setup; Debian has four packages: GL libs, GL headers, GLU libs, GLU headers. It's quite possible to install GL stuff without GLU. Surely it's not too much to check for glu.h as well as gl.h. -- Ross -- Comment By: Sven Panne (spanne) Date: 2005-08-29 13:26 Message: Logged In: YES user_id=50298 Regarding your GLU header problem: This will only happen if you have GL and GLU libraries installed and a GL header, but no GLU header. This is a rather obscure setup which I've never heard before: It is common that you either have a) no GL/GLU stuff at all (OpenGL ignorant system), b) only GL/GLU libraries (OpenGL *user* system), but no header c) GL/GLU libraries and headers (OpenGL *development* system). To avoid making the autoconf magic even more tricky, I declare your setup to be buggy. :-) Seriously: I think the autotools stuff should handle common differences between platforms, but not each and every obscure private setup, otherwise things get unmaintainable. Regarding the OpenAL problem: This is due to changes in the OpenAL API itself, which are already handled in the HEAD. Furthermore, the OpenAL stuff in the STABLE branch is practically unusable, because it is very incomplete. If you want a working and complete OpenAL binding, you can use the HEAD. I'll make no OpenAL the default in STABLE... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1275126group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1276246 ] panic with bad data/class definition.
Bugs item #1276246, was opened at 2005-08-29 19:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1276246group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler (Type checker) Group: 6.4 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: panic with bad data/class definition. Initial Comment: This malformed program causes a panic in ghc-6.4 class SClass a where sFun :: a - SData data SData = SCon SClass email: [EMAIL PROTECTED] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1276246group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Automatically derived instances
just try to compile it with
ghc -fallow-overlapping-instances -Wall --make Main.hs
or inseart sth. like this at the first line:
{-# OPTIONS -fglasgow-exts -fffi -fallow-undecidable-instances
-fallow-overlapping-instances #-}
- marc
Am Montag, 29. August 2005 05:25 schrieb Juan Carlos Arevalo Baeza:
David Menendez wrote:
Juan Carlos Arevalo Baeza writes:
The way Haskell type classes
work, the overlap is determined without looking at the context, so Show
a will overlap with every possible instance for Show, including Show
Int, which is predefined.
Ah. :-P Bummer.
I'm not sure what the official justification for that is, but reason is
to avoid situations like this:
class A t where a :: t
class B t where b :: t
class C t where c :: t
instance A t = C t where c = a
instance B t = C t where c = b
instance A Char where a = 'a'
instance B Char where b = 'b'
What should c :: Char evaluate to?
Right. Ambiguity. But as long as there's no ambiguity, there's no
reason to be this restrictive. Oh, well.
JCAB
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] ANNOUNCE: ghc-src version 0.2.0
On Wed, 2005-08-24 at 00:29 +0200, Lemmih wrote: On 8/23/05, John Meacham [EMAIL PROTECTED] wrote: On Tue, Aug 23, 2005 at 04:10:51PM +0200, Lemmih wrote: ghc-src 0.2.0 has been released. ghc-src is a Haskell parser with full support for every GHC extension. It is a refactored version of the Haskell parser used internally by GHC and is meant as a replacement for haskell-src-exts, although it might have other uses. The package is cabalized and lives under Langauge.Haskell.GHC.* in the module hierarchy. Darcs repo: http://scannedinavian.org/~lemmih/ghc-src/ ooh. neat. any chance it could be extended to preserve haddock comments and attach them to the right places? I thought it would be really cool if compilers could use the haddock documentation when printing out error messages and be able to query documentation as well as type info from inside the interpreter. Parsing Haddock comments would be pretty easy. However, compilers probably wont find ghc-src very usable since it has no placeholders for post-parsing information (such as inferred types). However it would be great for replacing the parser that haddock currently uses! This would be a nice thing to do, that is make haddock use this parser, since then it would accept exactly the same language that ghc accepts. When running haddock I often have to fix things where haddock is stricter than ghc's parser. And haddock's current error messages are not very good, they do not give source locations very accurately, unlike ghc which has excelent parser error messages. Duncan ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: ghc-src version 0.2.0
On Tue, Aug 23, 2005 at 04:10:51PM +0200, Lemmih wrote: ghc-src 0.2.0 has been released. ghc-src is a Haskell parser with full support for every GHC extension. It is a refactored version of the Haskell parser used internally by GHC and is meant as a replacement for haskell-src-exts, although it might have other uses. I heard that there is some combinator-based Haskell parser that also is equivalent to GHC's Happy-based one, and is within 10% of its performance. I had thought that I read that GHC might even start using it. Does anybody know if the combinator-based one is available? Thanks, Brian ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] How to use STArray?
Hmmm, no answer on cafe, maybe someone here with a good idea? -- Forwarded Message -- On Thursday 25 August 2005 19:58, Udo Stenzel wrote: [...] you'll need a type signature somewhere to help ghc resolve the overloading of newArray and readArray, which is surprisingly tricky due to the s that must not escape. This works: compute :: Int - Int compute n = runST ( do arr - newArray (-1, 1) n :: ST s (STArray s Int Int) readArray arr 1 ) Hello, I am fighting with a similar problem. I want to use STUArray but without committing to a fixed element type. For instance (this is not my real problem, but it's similar and easier to motivate), here is a function that appends two UArrays: A little helper first copy :: (MArray a e m, IArray b e) = a Int e - Int - b Int e - Int - Int - m () copy dest destix src srcix cnt | cnt = 0 = return () | otherwise = do writeArray dest destix (src ! srcix) copy dest (destix+1) src (srcix+1) (cnt-1) and here is the append function append :: UArray Int e - UArray Int e - Int - UArray Int e append x y low = runSTUArray (do z - newArray_ (low,low+len x+len y) copy z low x (first x) (len x) copy z (low+len x) y (first y) (len y) return z) where len = rangeSize . bounds first = fst . bounds Of course this can't work, because 'copy' needs the MArray and IArray contexts: No instance for (MArray (STUArray s) e (ST s)) arising from use of `copy' at Problem.lhs:31:7-10 [...] No instance for (IArray UArray e) arising from use of `copy' at Problem.lhs:31:7-10 [...] But now, when I add append :: (IArray UArray e, MArray (STUArray s) e (ST s)) = ... I still get the same error message regarding the MArray constraint: No instance for (MArray (STUArray s) e (ST s)) arising from use of `copy' at Problem.lhs:31:7-10 What am I missing? That is, how and where do I have to specify the constraint? Ben ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Who brought the monad to us?
Hi Wolfgang You may want to consider the papers by E. Moggi on Monadic computation (1989, 1990) at http://www.disi.unige.it/person/MoggiE/publications.html and Andrew Gordon's thesis Functional Programming and Input/Output (Sorry, I don't have a URL). Brett Giles [EMAIL PROTECTED] http://pages.cpsc.ucalgary.ca/~gilesb On Mon, 2005-08-29 at 18:20 +0200, Wolfgang Jeltsch wrote: Hello, is it right to say that Philip Wadler was the one who invented monadic I/O or were there others who did so together with Wadler? I need this for my thesis. :-) Best wishes, Wolfgang ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Who brought the monad to us?
Wolfgang, I thing that Eugenio Moggi was the first to combine monads from category theory with the lambda calculus. Check out: Computational Lambda Calculus and Monads, Eugenio Moggi, 1988 http://www.disi.unige.it/person/MoggiE/ It's citeseer page is at: http://citeseer.ist.psu.edu/275817.html Ben. Wolfgang Jeltsch wrote: Hello, is it right to say that Philip Wadler was the one who invented monadic I/O or were there others who did so together with Wadler? I need this for my thesis. :-) Best wishes, Wolfgang ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] How to use STArray?
Benjamin Franksen wrote:
On Thursday 25 August 2005 19:58, Udo Stenzel wrote:
[...] you'll need a type signature somewhere to help ghc resolve
the overloading of newArray and readArray, which is surprisingly
tricky due to the s that must not escape. This works:
compute :: Int - Int
compute n = runST ( do
arr - newArray (-1, 1) n :: ST s (STArray s Int Int)
readArray arr 1
)
I am fighting with a similar problem. I want to use STUArray but
without committing to a fixed element type.
That problem has been addressed in a message
http://www.haskell.org/pipermail/haskell-cafe/2004-July/006400.html
which discussed several solutions. Given below is one of the solutions
adjusted to fit the question of the original poster. His code is
almost unchanged.
It would havebeen nice if the GHC library supported the second
solution, a class Unpackable. Currently there are instances of
MArray (STUArray s) e (ST s)
and
IArray UArray e
for exactly the same set of types `e'. Alas, that condition is not
stated formally, so we cannot infer that MArray (STUArray s) e (ST s)
holds whenever IArray UArray e does.
{-# OPTIONS -fglasgow-exts #-}
module Foo where
import Data.Array.Unboxed
import Data.Array.ST
import Control.Monad.ST
data Allocator m i e = forall a. MArray a e m =
Allocator ((i, i) - m (a i e))
copy :: (MArray a e m, IArray b e) =
a Int e - Int - b Int e - Int - Int - m ()
copy dest destix src srcix cnt
| cnt = 0 = return ()
| otherwise = do
writeArray dest destix (src ! srcix)
copy dest (destix+1) src (srcix+1) (cnt-1)
append :: (IArray UArray e, STUGood e) =
UArray Int e - UArray Int e - Int - UArray Int e
append x y low =
runST (case allcg of Allocator newArray_ -
(do
z - newArray_ (low,low+len x+len y)
copy z low x (first x) (len x)
copy z (low+len x) y (first y) (len y)
unsafeFreeze z))
where
len = rangeSize . bounds
first = fst . bounds
class STUGood e where
allcg::Ix i = Allocator (ST s) i e
instance STUGood Bool where
allcg = Allocator (newArray_:: Ix i = (i,i) - ST s (STUArray s i Bool))
instance STUGood Float where
allcg = Allocator (newArray_:: Ix i = (i,i)- ST s (STUArray s i Float))
-- etc.
test =
append (listArray (1,1) [True]) (listArray (1,1) [False]) 0
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] Re: [Haskell] pros and cons of static typing and side effects ?
Martin Vlk [EMAIL PROTECTED] writes: http://www-i2.informatik.rwth-aachen.de/Staff/Current/michaelw/sttt-ml-haskell.pdf Interesting to see others' experiences, even if they are slightly negative. It contains descriptions of lots of real-world problems and how They are only implementing TRUTH and CWB, no? Among other things it touches on the static typing pros and cons One critique against the paper is that they discuss language features at great length, but conclude that: |However, it turned out in our discussions that none of us were | enthusiastic about the idea of using a functional language for a | future verification tool because of their impoverished environments | compared with mainstream programming languages. I would like to see more discussion of what is impoverished about the environments, and what they consider mainstream programming languages. Certainly the authors could have discussed this in the main part of the paper? | Our impression was that SML and Haskell can play out their | advantages mainly in the prototyping stages of a project, an arena | where both would have to compete with dynamic languages like Lisp or | Smalltalk, or scripting languages like Python (which have faster | turn-aroundcycles due to absence of a compilation phase). I'm not sure the authors are even aware or the existence of interactive environments (e.g. Hugs and GHCi are not mentioned, only Haskell *compilers*). Disclaimer: I just browsed quickly through the paper. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] generics question, logical variables
Frederik, Thanks for the challenge. I didn't get some of the bits about your application scenario though. (What did you mean by the type Pred? Why a list in the result of solve? How did you model typed logical variables? With GADTs, phantoms? ... Perhaps send more code, if you want to discuss this topic more.) So I hope that the attached make sense to you. I do believe so. I have coded a function that converts a term t Maybe a to a term t Id a, where I assume that: - t is the Haskell type that may involve Maybe/Id spots. - Maybe/Id spots for variables are wrapped in a dedicated datatype Spot, - a is the type of the term with regard to some custom type system. - The custom type system is model as a class Term. Here is the conversion function: force :: ( Data (t Maybe a) , Data (t Id a) , Term t Maybe a , Term t Id a ) = t Maybe a - t Id a force = fromJust . tree2data . data2tree This example assumes that all Maybe spots are actually Just values. Clearly, you can do some error handling in case this cannot be assumed. You could also make the Maybe-to-Id conversion part of the traversal that resolves holes. This is not the challenge, the challenge was indeed to traverse over a term and to get the types right when replacing subterms of type Maybe x by subterms of type Id x. The actual type conversion relies on going through the universal Tree datatype. We use Tree Constr as the type of an intermediate value. (We could also use Tree String but this would be more inefficient. BTW, we take here dependency on the invariant that constructors in Constr are polymorphic. So SYB's reflection is nicely generic; compare this with Java.) When encountering spots during trealization, they are converted from Maybies to Ids. Then, a subsequent de-trealization can do its work without any ado. The deep trealization solves the problem of exposing these type changes to the type of gfoldl. (Amazingly, one might say that the type of gfoldl is just not general enough!) I guess I should admit that: - We temporally defeat strong typing. - We make the assumption that all occurrences of Spot are to be converted. - That is, we don't quite track the type parameter for Maybe vs. Id. - This is a bit inefficient because of going through Tree Constr. So I am willing to summarize that this is potentially a sort of a (cool) hack. Code attached. Ralf P.S.: The extension you propose seems to be a major one. Perhaps you could look into the TH code for SYB3 (ICFP 2005) to see whether this can be automated. This sort of discussion calls for kind polymorphism once again. -Original Message- From: [EMAIL PROTECTED] [mailto:haskell-cafe- [EMAIL PROTECTED] On Behalf Of Frederik Eaton Sent: Sunday, August 28, 2005 9:36 PM To: haskell-cafe@haskell.org Subject: [Haskell-cafe] generics question, logical variables Hi all, I'm trying to write something like a generic fmap, or a generic natural transformation. The application is this. I have a typed logical variable library which produces arbitrary terms with values of type Var a, which are references to a value of type Maybe a, and I want to write a solve function which replaces these values with instantiated versions of type Id a where newtype Id a = Id a . Furthermore I want this to be reflected in the type of the generic term: solve :: Pred (t Var) - [t Id] so if I have a type like data Entry k = Entry (k String) (k Int) then I can write some constraint equation with values of type Entry Var, and get back values of type Entry Id - in other words, objects where the unknowns are statically guaranteed to have been filled in. I looked at the generics library. I may be mistaken, but it seems that it doesn't have what I need to do this. The problem isn't the mapping, it's creating a new type which is parameterized by another type. The only options for creating new types are variations on fromConstr :: Data a = Constr - a but what is needed is something like fromConstr1 :: Data1 a = Constr1 - a b With something like that it should be possible to define: gmapT1 :: (forall b . Data1 b = b l - b m) - a l - a m Does this make sense? Here I would be treating all instances of Data as possibly degenerate instances of Data1 (which just might not depend on the type variable). If it seems like a good idea, I would be interested in helping out with the implementation. Frederik -- http://ofb.net/~frederik/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe PseudoFmap.hs Description: PseudoFmap.hs ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Hugs - evaluation statistics
Hello Dusan, Monday, August 29, 2005, 9:55:56 AM, you wrote: Nevertheless, for the other algorithm the expected time complexity ( quite well known in general :-) ) and measured values do no fit together. number of reductions is not exact time statistics. try the following alternative length definition ;) length2 (_:_:_:_:_:_:_:_:_:_:xs) = (length2 xs)+10 length2 (_:xs) = (length2 xs)+1 length2 _= 0 and compare number of reductions for: length [1..5000] length2 [1..5000] -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hugs - evaluation statistics
Well, I know I cannot calculate exact time statistics, but I cen get information about the aproximate behavior - like the algorithm is Theta(n), Theta(n*log(n)), etc. It's quite sufficient, I think. According to your example - I don' know what you want to show, both algorithms are linear in time consumption: [reductions] lengthlength2 l(10) 91 28 l(100) 721 73 l(1000) 7021523 l(5000)35021 2523 For length we get: 7*n+21 For length2 we get: 1/2*n+23 Thus, for both length and length' we get: Theta(n) And in my first e-mail, I wrote I knew it's not exact. But, if I expect behavior like Theta(n^2) and I can't fit it then I'm asking why - now I know answer even for that question (in my case) - I can provide only too small input to test (otherwise out of memory) and thus the curve is not curve-enough and is much closer to line. But new settings for hugs compilation should allowed much higher memory usage and I should get to more usable numbers. :-) Dusan Bulat Ziganshin wrote: Hello Dusan, Monday, August 29, 2005, 9:55:56 AM, you wrote: Nevertheless, for the other algorithm the expected time complexity ( quite well known in general :-) ) and measured values do no fit together. number of reductions is not exact time statistics. try the following alternative length definition ;) length2 (_:_:_:_:_:_:_:_:_:_:xs) = (length2 xs)+10 length2 (_:xs) = (length2 xs)+1 length2 _= 0 and compare number of reductions for: length [1..5000] length2 [1..5000] -- Dusan Kolartel: +420 54 114 1238 UIFS FIT VUT Brno fax: +420 54 114 1270 Bozetechova 2 e-mail: [EMAIL PROTECTED] Brno 612 66 Czech Republic -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell and fuse
See also Jeremy Bobbio's fuse bindings here: http://cvs.haskell.org/darcs/hfuse/ I've been using them on the Halfs, the Haskell Filesystem that I'll be demoing at the Haskell Workshop. David Roundy [EMAIL PROTECTED] writes: (snip) The FuseIO module itself might be rather interesting for other projects (e.g. darcs), or even (one could imagine) as an alternative to the haskell standard IO libraries for filesystem access, since it'd allow you to write a function that is guaranteed by the typesystem to do nothing but read from a filesystem, and it'd also allow writing polymorphic filesystem access/modification code that could be applied outside the IO monad (e.g. to Slurpies). It would also allow one to use treat network objects (e.g. http or ftp) as filesystems. I haven't gotten a chance to really look at this yet, but it sounds really cool. peace, isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pros and cons of static typing and side effects ?
On pondělí 29 srpna 2005 8:57, Ketil Malde wrote: It contains descriptions of lots of real-world problems and how They are only implementing TRUTH and CWB, no? Yes, and lots of real-world situations that they faced during the development. That's what I meant. I would like to see more discussion of what is impoverished about the environments, and what they consider mainstream programming languages. Certainly the authors could have discussed this in the main part of the paper? Please read section 5 in the paper. I'm not sure the authors are even aware or the existence of interactive environments (e.g. Hugs and GHCi are not mentioned, only Haskell *compilers*). I am very sure they are aware of them. Interactive interpreters are simply not enough of a tool for commercial development - more sophisticated tools are necessary. In Haskell we don't even have basic things like code structure visualisation, efficient browsing and fully language-aware editor with typing support etc. This is one of the ways of distinguishing the mainstream languages. Mainstream means that enough people use them for someone to put in the effort to build the tools. vlcak ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Floating point madness
I have looked around the net, and in some reference books and I cannot find a function to convert a Float to a Double directly. Can there truly be no such animal in the Prelude/standard libs? -mdg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Floating point madness
On Mon, 2005-08-29 at 16:59 -0400, Mark Goldman wrote: I have looked around the net, and in some reference books and I cannot find a function to convert a Float to a Double directly. Can there truly be no such animal in the Prelude/standard libs? In the Prelude there is realToFrac :: (Fractional b, Real a) = a - b and (Float - Double) is an instance of this type. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to use STArray?
Benjamin Franksen wrote: append :: (IArray UArray e, MArray (STUArray s) e (ST s)) = ... I believe there must be an MArray instance for every s for this to work. If I understand types correctly (which isn't all that certain), the correct context would be append :: (IArray UArray e, forall s . MArray (STUArray s) e (ST s)) = ... which is illegal. A workaround might be possible by introducing a new class which doesn't need to mention s in the context. I can't see the solution, though. Udo. -- Uncle Ed's Rule of Thumb: Never use your thumb for a rule. You'll either hit it with a hammer or get a splinter in it. signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] generics question, logical variables
Ralf, Thanks for the challenge. Wow, thanks for taking an interest. I'm sorry for my slow response, I've been sick. Ah, I haven't seen your SYB3 yet, I will have to take some time to read it. As for your code example, it looks very interesting, but are you saying that this could turn into an extension of the Data.Generics library, or that this is something I could be implementing in terms of what's already there? What is the 'a' parameter for in force? force :: ( Data (t Maybe a) , Data (t Id a) , Term t Maybe a , Term t Id a ) = t Maybe a - t Id a It seems to result in a lot of bookkeeping, e.g.: data Pair tx ty ax ay ( h :: * - * ) a = Pair (tx h ax) (ty h ay) instance (Term tx v ax, Term ty v ay) = Term (Pair tx ty ax ay) v (ax,ay) The whole purpose of my project is to get something which resembles logical variables in Haskell with minimal syntactic overhead. I didn't get some of the bits about your application scenario though. (What did you mean by the type Pred? Why a list in the result of solve? How did you model typed logical variables? With GADTs, phantoms? ... Perhaps send more code, if you want to discuss this topic more.) What I am trying to do is an extension of a paper by Koen Claessen and Peter Ljunglof: http://citeseer.ist.psu.edu/claessen00typed.html Here is the code I have written: http://ofb.net/~frederik/GenLogVar.hs For the part which I asked for help with, to get around my trouble with generics, I defined a class GenFunctor and an example instance. The intent is that generics should be able to provide this functionality automatically later on, but you can see what the functionality is. However, I am stuck on something else, the program doesn't typecheck because of use of another function I defined, 'cast1'. Maybe you can take a look. I had thought that I would be able to write a generic 'unify' but I get the error: GenLogVar.hs:82:19: Ambiguous type variable `a' in the constraint: `Data a' arising from use of `cast1' at GenLogVar.hs:82:19-23 Probable fix: add a type signature that fixes these type variable(s) This is because I need to do something special when I encounter a Var variable in unification, but the compiler seems to not like the fact that the type argument of the Var data type is not known. I won't have time to work on this much more, but one motivation I had was that if I can get this working, then a possible next step would be to map the logical variable syntax onto SQL database queries, rather than interpreting it directly in Haskell. The mapping would be a bit higher-level than HaskellDB. Haskell algebraic data types themselves would turn into sets of SQL tables. Each constructor would correspond to a table. A value of a type would be a pair (table, index) where table tells you the constructor and index is the primary key into the table. In addition other indices would be specified to exist for querying, and range queries could be done by extending the logical variable semantics, substituting a Range datatype for Maybe in variables. It's probably a lot more complicated than this but I think it would be fun to try. Frederik So I hope that the attached make sense to you. I do believe so. I have coded a function that converts a term t Maybe a to a term t Id a, where I assume that: - t is the Haskell type that may involve Maybe/Id spots. - Maybe/Id spots for variables are wrapped in a dedicated datatype Spot, - a is the type of the term with regard to some custom type system. - The custom type system is model as a class Term. Here is the conversion function: force :: ( Data (t Maybe a) , Data (t Id a) , Term t Maybe a , Term t Id a ) = t Maybe a - t Id a force = fromJust . tree2data . data2tree This example assumes that all Maybe spots are actually Just values. Clearly, you can do some error handling in case this cannot be assumed. You could also make the Maybe-to-Id conversion part of the traversal that resolves holes. This is not the challenge, the challenge was indeed to traverse over a term and to get the types right when replacing subterms of type Maybe x by subterms of type Id x. The actual type conversion relies on going through the universal Tree datatype. We use Tree Constr as the type of an intermediate value. (We could also use Tree String but this would be more inefficient. BTW, we take here dependency on the invariant that constructors in Constr are polymorphic. So SYB's reflection is nicely generic; compare this with Java.) When encountering spots during trealization, they are converted from Maybies to Ids. Then, a subsequent de-trealization can do its work without any ado. The deep trealization solves the problem of exposing these type changes to the type of gfoldl. (Amazingly, one might say that the type of gfoldl is just not general enough!) I guess I should admit that: - We temporally defeat
