Is GPH available for users today ?
Hello, I am very interesting by GPH working on Linux/i386 cluster. I performed many attempts to grasp/build this beautiful thing last years (!), all with negative results :-( Reasons were different: or binaries were compiled for old glibc, or something unsuccesful was happened during source compilation. Or simply some MP libraries were missing in distribution. I hope the reason is only my hard fortune (:-), and rest of world is happy running GPH. Or simply today GHC with GPH .rpm is available somewhere and i can join to happy world. I even agree to spent two nights (not more, please) hacking GHC to build GPH. Can anybody show me a way ? Thanks in advance, Vladimir.
Re: ghc graphics library
simonpj writes: > Alastair Reid is, I believe, actively working on updating his graphics > library (from which SOEGraphics was originally derived), to work with > the current version of GHC. > > What I don't know is when he expects to be done. > > Alastair? What's the status? I don't think there's much work needed to get it working - but I'm having trouble finding time to work on it or predicting when I'll get back to it. Apart from making sure that the GreenCard interfaces to Win32 and X11 work with GHC, the main task is making sure that the library works in the presence of GHC's preemptive multitasking instead of Hugs' cooperative multitasking. Things are made harder by the fact that the Win32 version shares hardly any code with the Xlib version (so knowing which platform people care most about would be useful). A cleanup pass over the Win32 code (to eliminate most of the differences) would also help - but takes more time in the short term. Alastair
RE: ghc graphics library
Ameet, Stephen, Alastair Reid is, I believe, actively working on updating his graphics library (from which SOEGraphics was originally derived), to work with the current version of GHC. What I don't know is when he expects to be done. Alastair? What's the status? Simon Hi, My name is Ameet Talwalkar and I'm working for Paul Hudak this summer. We're trying to use GHC, but we're using a graphics library (SOEGraphics) that only runs under Hugs. Thus, I'm looking for another Graphics library which I could use that is GHC compatible. I am only using simple animations in my programs, and thus only need a basic graphics package that draws colored circles, polygons, and lines, and was hoping that you might have an idea as to what graphics library I should use. Thanks a lot for your time. Ameet Talwalkar | -Original Message- | From: Stephen Alden Elliott [mailto:[EMAIL PROTECTED]] | Sent: 27 June 2000 19:10 | To: GHC Mailing List | Subject: ghc graphics library | | | Can anyone recommend a good graphics library that compiles | simply under | GHC and can do simple things like line drawing and window manipulating | ver easily? | | -stephen |
Re: Method contexts
Wed, 28 Jun 2000 04:36:01 -0700, Simon Peyton-Jones <[EMAIL PROTECTED]> pisze:
> Why can't you have
>
> class Eq a => Member c a | c -> a where member :: Eq a => c -> a -> Bool
>
> OK, so then sequences require Eq on elements, but since Member is a
> superclass of sequence, every sequence has a member method,
> and so a must be in Eq anyway.
Only the member method requires Eq, others do not.
My example was unnecessarily complicated:
class Sequence s a where
single :: a -> s a
member :: Eq a => s a -> a -> Bool
instance Sequence [] a where
single x= [x]
member xs x = x `elem` xs
Everything is well defined and as generic as it should, only GHC does
not like it.
Why the element type is in the class head? Because not all sequences
are fully polymorphic:
newtype PS a = PS PackedString
instance Sequence PS Char where
single x= packString [x]
member xs x = x `elemPS` xs
An issue independent of this problem. Another possibility is:
class Sequence s a | s -> a where
single :: a -> s
member :: Eq a => s -> a -> Bool
instance Sequence [a] a where ...
instance Sequence PackedString Char ...
It has the advantage that PackedString does not require an artificial
argument, but a disadvantage is that Sequence cannot contain map that
changes the type of the element. With the previous approach it can,
although not as naturally as a class of fully polymorphic sequences:
class Sequence s a where
...
map :: Sequence s b => (a -> b) -> s a -> s b
Although this type is not symmetric wrt. a and b as seen from inside
(when we define instances) and could be written in the opposite way,
it is symmetric outside.
A definition for polymorphic sequences is not problematic and
can depend on particular implementation of both input and output
value. Unfortunately it's not that easy for PackedString:
instance Sequence PS char where
...
map = ... -- We must provide a function of the type
-- Sequence PS b => (Char -> b) -> PS Char -> PS b
Even if we know that it will be used only for b = Char, because
otherwise the result is not a Sequence and cannot be used in any
interesting way, the definition must be polymorphic wrt. b and we
can only use generic methods to construct the result.
The only way to use mapPS :: (Char -> Char) -> PackedString -> PackedString
through the common map interface is by {-# RULES #-} or unsafeCoerce#.
The overall situation looks a bit ugly. Any ideas?
If we could live without PackedString being a Sequence, we could make
it nice and symmetric by having only fully polymorphic sequences.
It would lead to simpler contexts needed for particular pieces of code.
If only we had local universal quantification in contexts...
class Sequence s where
single :: a -> s a
member :: Eq a => s a -> a -> Bool
I want to reuse member for collections. Collections are not fully
polymorphic, so even if we define a class of collections over type
constructors instead of over applied types:
class Coll c a where
insert :: a -> c a -> c a
member :: c a -> a -> Bool
and want to move member to a common superclass, it must be constrained
by the type of elements, because individual collection instances can
require arbitrary restrictions on it (e.g. Ord a):
class Member c a where
member :: Eq a => c a -> a -> Bool
class Member c a => Coll c a where
insert :: a -> c a -> c a
For sequences it cannot have any restrictions other than Eq, because
being a sequence cannot depend on the element type:
class (forall a. Member s a) => Sequence s where
single :: a -> s a
Ah, is that possible?
In fact most classes will constrain applied types instead of type
constructors, because the type is not always the last argument of the
collection type. Classes will constrain type constructors only when
needed for cases like map, i.e. sequence elements and association
map values.
class Lookup c k a | c -> k a where
(!) :: c -> k -> a
lookupMaybe :: c -> k -> Maybe a
-- Or maybe: (!?) :: c -> k -> Maybe a -- :-)
-- Variant with constrained element types:
class Lookup (s a) Int a => Sequence s a where ...
class Lookup c a a => Coll c a where ...
class Lookup (m v) k v => AssocMap m k v where ...
-- Variant with fully polymorphic classes:
class (forall a. Lookup (s a) Int a) => Sequence s where ...
classLookup c a a => Coll c a where ...
class (forall v. Lookup (m v) k v) => AssocMap m k where ...
Functional dependencies are really important in this case.
--
__("< Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/GCS/M d- s+:-- a23 C+++$ UL++>$ P+++ L++>$ E-
^^W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y?
RE: Method contexts
Why can't you have
class Eq a => Member c a | c -> a where member :: Eq a => c -> a -> Bool
OK, so then sequences require Eq on elements, but since Member is a
superclass of sequence, every sequence has a member method,
and so a must be in Eq anyway. Puzzled
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
| Sent: 27 June 2000 14:30
| To: [EMAIL PROTECTED]
| Subject: Method contexts
|
|
| The restriction that a method context must constrain at least one
| type variable that is quantified there has biten me:
|
|
| class Member c a | c -> a where member :: Eq a => c -> a -> Bool
| class Member (s a) a => Sequence s a where single :: a -> s a
|
| instance Member [a] a where member s a = elem a s
| instance Sequence [] a where single x = [x]
|
|
| I cannot move the constraint to the class context because it would
| force Eq a on all Sequence methods. I cannot have class Member c
| (where c has kind *->*) because it is used differently in
| other places.
|
| Hugs does accept the above definitions.
|
| Could this restriction be removed in ghc please?
|
| --
| __("< Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
| \__/GCS/M d- s+:-- a23 C+++$ UL++>$ P+++ L++>$ E-
| ^^W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
| QRCZAK5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-
|
|
Re: perl frontend for ghc
Wed, 28 Jun 2000 02:36:04 -0700, Simon Marlow <[EMAIL PROTECTED]> pisze:
> But fortunately now we have, and if you look at the current CVS
> HEAD you'll see the new driver, written (almost) entirely in Haskell.
Written in Haskell when we consider a compiler which is needed to
compile it, but it's still written in Perl when we consider the
style:-)
--
__("< Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/GCS/M d- s+:-- a23 C+++$ UL++>$ P+++ L++>$ E-
^^W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-
RE: perl frontend for ghc
> I hope this isn't a FAQ, but AFAIR this hasn't been asked in the past: > > Are there plans to replace the ghc frontend (driver), which > is currently > written in perl, by a version implemented in Haskell? > > I know that perl is nice for fiddling with command line > options, but on > the other hand, it's a very chaotic programming language. So, > are there > any reasons beyond speed and/or the simple fact that nobody > did port the > frontend to Haskell? Well, until recently it was for the simple reason that we just hadn't got around to it. But fortunately now we have, and if you look at the current CVS HEAD you'll see the new driver, written (almost) entirely in Haskell. There are still a few scripts written in Perl, most notably the assembly mangler which we don't intend to rewrite in Haskell. But at least now you can run GHC on a Perl-free machine as long as you only use the native code generator and don't need to do 'make depend'. In due course some of the remaining Perl scripts will be removed and their functionality absorbed by either the driver or the compiler itself. Cheers, Simon
