Re: ghc fails hello world on ppc
I forgot to say that the version is 6.0.1. So... can anyone else reproduce this? Is there a stable version of the compiler which I should be using instead? Is there anything I can do to help fix this bug? I've been playing around with PPC Linux a bit on the weekend, and I can't reproduce the problem on my Gentoo installation. The GHC 5.04.3 binary package provided on the GHC download page seems to work perfectly. 5.04.3 works for me too. Were you implying that your Gentoo installation was 6.0.1? If so, then I should probably notify the Debian people that the problem is likely with their build (although I can't imagine what would cause it). Frederik No, I didn't want to imply that, sorry for being unclear. I downloaded the 5.04.3 binary, which worked fine. I didn't try 6.0.1, but then I checked out the CVS version. That didn't compile out of the box, but it didn't take long fix the problems. I also ported the registerised compilation stuff and the native code generator over from Mac OS X. That means that GHC 6.2 (to be released soon) should compile on PowerPC Linux and work a lot faster than previous PowerPC Linux ports. Cheers, Wolfgang ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Instances which worked in ghc6.0.1 don't work for developmentsnapshot 6.3.20031201
For ghc6.0.1 on Linux # ghc Test1.hs -c -fglasgow-exts -fallow-undecidable-instances -fallow-overlapping-instances # ghc Test2.hs -c -fglasgow-exts -fallow-undecidable-instances -fallow-overlapping-instances works. But for ghc6.3.20031201 the second compilation produces the message: Test2.hs:6: No instance for (FormValue (Maybe [Char])) arising from use of `isFormValue' at Test2.hs:6 In the definition of `is': is = isFormValue (Just ) Oddly enough the compilation works if you do it in one step using # ghc --make Test2.hs -fglasgow-exts -fallow-undecidable-instances -fallow-overlapping-instances module Test1 where class FormValue value where isFormValue :: value - () isFormValue _ = () class FormTextField value instance FormTextField String instance FormTextField value = FormTextFieldIO value class FormTextFieldIO value instance FormTextFieldIO value = FormValue value instance FormTextFieldIO value = FormTextFieldIO (Maybe value)module Test2 where import Test1 is :: () is = isFormValue (Just )___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc fails hello world on ppc
I forgot to say that the version is 6.0.1. So... can anyone else reproduce this? Is there a stable version of the compiler which I should be using instead? Is there anything I can do to help fix this bug? I've been playing around with PPC Linux a bit on the weekend, and I can't reproduce the problem on my Gentoo installation. The GHC 5.04.3 binary package provided on the GHC download page seems to work perfectly. 5.04.3 works for me too. Were you implying that your Gentoo installation was 6.0.1? If so, then I should probably notify the Debian people that the problem is likely with their build (although I can't imagine what would cause it). Frederik No, I didn't want to imply that, sorry for being unclear. I downloaded the 5.04.3 binary, which worked fine. I didn't try 6.0.1, but then I checked out the CVS version. That didn't compile out of the box, but it didn't take long fix the problems. I also ported the registerised compilation stuff and the native code generator over from Mac OS X. That means that GHC 6.2 (to be released soon) should compile on PowerPC Linux and work a lot faster than previous PowerPC Linux ports. Excellent, thanks. Frederik ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: import modules from a different directory
Anybody has the experience of importing a module from a different directory?In my code, i need to import a module that is not in the current directory. How can I do that in GHC? GHC-specific questions are best asked on [EMAIL PROTECTED] (where I've sent this followup). You'll find the -i option to GHC will do what you want. Documentation is here: http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compilation.html#OPTIONS-FINDING-IMPORTS Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
forkProcess type changed?
For the development snapshot 6.3.20031201, System.Posix.forkProcess has the type IO () - IO System.Posix.Types.ProcessID. In 6.0.1 it has type IO () - IO (Maybe System.Posix.Types.ProcessID). Is this change intentional, and if so how are you supposed to test after the fork if this is the parent or child process? ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: forkProcess type changed?
For the development snapshot 6.3.20031201, System.Posix.forkProcess has the type IO () - IO System.Posix.Types.ProcessID. In 6.0.1 it has type IO () - IO (Maybe System.Posix.Types.ProcessID). Is this change intentional, and if so how are you supposed to test after the fork if this is the parent or child process? Yes, this is intentional. It turned out to be far too difficult to implement forkProcess as it was previously defined (problems with what happens when the current thread returns in the child process was one difficulty, IIRC). The previous implementation had some serious bugs. See the docs for the new version here: http://www.haskell.org/ghc/docs/6.2/html/libraries/unix/System.Posix.Pro cess.html#v%3AforkProcess Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: forkProcess type changed?
On Thu, Dec 11, 2003 at 04:44:37PM +0100, George Russell wrote: In 6.0.1 it has type IO () - IO (Maybe System.Posix.Types.ProcessID). Isn't it rather IO (Maybe System.Posix.Types.ProcessID) ? Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: forkProcess type changed?
George Russell wrote: For the development snapshot 6.3.20031201, System.Posix.forkProcess has the type IO () - IO System.Posix.Types.ProcessID. In 6.0.1 it has type IO () - IO (Maybe System.Posix.Types.ProcessID). Is this change intentional, and if so how are you supposed to test after the fork if this is the parent or child process? The following example should explain everything: Old Version: do mbPid - forkProcess case mbPid of Nothing - putStrLn Child Just pid - putStrLn $ Parent of ++ show pid New Version: do pid - forkProcess (putStrLn Child) putStrLn $ Parent of ++ show pid Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: type classes, superclass of different kind
Robert Will wrote: Note that in an OO programming language with generic classes ... (We shouldn't make our functional designs more different from the OO ones, than they need to be.) why should *we* care :-) more often than not, OO design is resticted and misleading. you see how most OO languages jump through funny hoops (in this case, generics) because they just lack proper higher-order types. good luck with your library. but make sure you study existing (FP) designs, e. g. Chris Okasaki's Edison: http://www.eecs.usma.edu/Personnel/okasaki/pubs.html#hw00 -- -- Johannes Waldmann, Tel/Fax: (0341) 3076 6479 / 6480 -- -- http://www.imn.htwk-leipzig.de/~waldmann/ - ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: type classes, superclass of different kind
Robert Will wrote: Now I would like to have Collection to be a superclass of Map yielding the following typing reduce :: (Map map a b) = ((a, b) - c) - c - map a b - c Note that in an OO programming language with generic classes (which is in general much less expressive than real polymorphism), I can write class MAP[A, B] inherit COLLECTION[TUPLE[A, B]] which has exactly the desired effect (and that's what I do in the imperative version of my little library). There seems to be no direct way to achieve the same thing with Haskell type classes (or any extension I'm aware of). Here is a quesion for the most creative of thinkers: which is the design (in proper Haskell or a wide-spread extension) possibly include much intermediate type classes and other stuff, that comes nearest to my desire? I don't know if I qualify as the most creative of thinkers, but I have a small library of ADSs that you may want to look at, it's at http://www.dtek.chalmers.se/~d00nibro/algfk/ I recall having much the same problem as you did, my solution was to make maps (or Assoc as I call them) depend on tuple types, i.e. (somewhat simplified): class (Collection c (k,v), Eq k) = Assoc c k v where lookup :: k - c (k,v) - v [...many more member functions here...] This means that the type constructors for maps and collections have the same kind (* - *), which makes it possible for me to say that an Assoc is actually also a Collection. A lot more info to be found off the link. I believe this question to be important and profound. (We shouldn't make our functional designs more different from the OO ones, than they need to be.) If I err, someone will tell me :- No need to recreate all the stupid things the OO world has come up with, better to do it correctly right away... ;) /Niklas Broberg, d00nibro[at]dtek.chalmers.se _ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: type classes, superclass of different kind
--- Robert Will [EMAIL PROTECTED] wrote:
-- Here
-- is a quesion for the
-- most creative of thinkers: which is the design
(in
-- proper Haskell or a
-- wide-spread extension) possibly include much
-- intermediate type classes and
-- other stuff, that comes nearest to my desire?
Hello,
I've often wondered the same thing. I've found that
one can simulate several OO paradigms. Note that
these aren't particularly elegant or simple.
Using Data Constructors:
data Shape = Rectangle {topLeft :: (Int, Int),
bottomRight :: (Int,Int) }
| Circle {center :: (Int,Int), radius ::
Int }
This allows you have a list of shapes
shapeList :: [Shape]
shapeList = [ Rectangle (-3,3) (0,0), Circle (0,0) 3
]
When you want member functions, you need to specialize
the function for
all the constructors.
height :: Shape - Int
height (Rectangle (a,b) (c,d)) = b - d
height (Circle _ radius) = 2 * radius
Disadvantages:
1) When a new Shape is needed, one needs to edit the
original Shape source
file.
2) If a member function is not implemented for a shape
subclass, it will lead
to a run-time error (instead of compile-time).
Advantages:
1) Simple Syntax
2) Allows lists of Shapes
3) Haskell98
Example: GHC's exception types
http://www.haskell.org/ghc/docs/latest/html/base/Control.Exception.html
Using Classes
Classes can be used to force a type have specific
functions to act upon it.
From our previous example:
class Shape a where
height :: a - Int
data Rectangle = Rectangle {topLeft :: (Int, Int),
bottomRight :: (Int,Int) }
data Circle = Circle {center :: (Int,Int), radius ::
Int }
instance Shape Circle where
height (Circle _ radius) = 2 * radius
instance Shape Rectangle where
height (Rectangle (a,b) (c,d)) = b - d
In this case, something is a shape if it specifically
has the member
functions associated with Shapes (height in this
case).
Advantages
1) Simple Syntax
2) Haskell98
3) Allows a user to easily add Shapes without
modifying the original source.
4) If a member function is not implemented for a shape
subclass, it will lead
to a compile-time error.
Disadvantages:
1) Lists of Shapes not allowed
Example: Haskell 98's Num class.
http://www.haskell.org/ghc/
Classes with Instance holder.
There have been a few proposals of ways to get around
the List of Shapes
problem with classes. The Haskell98 ways looks like
this
data ShapeInstance = ShapeInstance { ci_height ::
Int }
toShapeInstance :: (Shape a) = a - ShapeInstance
toShapeInstance a = ShapeInstance { ci_height =
(height a) }
instance Shape ShapeInstance where
height (ShapeInstance ci_height) = ci_height
So when we want a list of shapes, we can do
shapeList = [ toShapeInstance (Circle (3,3) 3),
toShapeInstance (Rectangle (-3,3)
(0,0) ) ]
Of course this also has it's disadvantages. Everytime
a new memeber function is added, it must be noted in
the ShapeInstance declaration, the toShapeInstance
function, and the instance Shape ShapeInstance
declaration.
Using a haskell extention, we can get a little better.
Existentially quantified data constructors gives us
this:
data ShapeInstance = forall a. Shape a =
ShapeInstance a
instance Shape ShapeInstance where
height (ShapeInstance a) = height a
shapeList = [ ShapeInstance (Circle (3,3) 3),
ShapeInstance (Rectangle (-3,3) (0,0)
) ]
The benefits of this method are shorter code, and no
need to update the ShapeInstance declaration every
time a new member function is added.
Records extention
A different kind of inheritance can be implemented
with enhanced haskell
records. See
http://research.microsoft.com/~simonpj/Haskell/records.html
and
http://citeseer.nj.nec.com/gaster96polymorphic.html
for in depth explinations. I'm not sure if these have
been impemented or not, but it would work as follows.
The inheritance provided by the above extentions is
more of a data inheritance
than a functional inheritance. Lets say all shapes
must have a color parameter:
type Shape = {color :: (Int,Int,Int)}
type Circle = Shape + { center :: (Int,Int), radius
:: (Int) }
type Rectangle = Shape + { topLeft :: (Int,Int),
bottomRight :: (Int, Int) }
So now we can reference this color for any shape by
calling .color.
getColor :: (a : Shape ) - a - (Int,Int,Int)
getColor a = a.color
I'm not sure how the records extention could be used
with Classes with instance
holders to provide an even more plentiful OO
environment.
So I'll conclude this email with the observation that
Haskell supports some
OO constructs although not with the most elegance.
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: type classes, superclass of different kind
On Thu, 11 Dec 2003, Robert Will wrote: Hello, As you will have noticed, I'm designing a little library of Abstract Data Structuresm here is a small excerpt to get an idea: class Collection coll a where ... (+) :: coll a - coll a - coll a reduce :: (a - b) - b - coll a - b ... class Map map a b where ... (+) :: map a b - map a b - map a b at :: map a b - a - b ... Note that the classes don't only share similar types, they also have similar algebraic laws: both + and + are associative, and neither is commutative. Now I would like to have Collection to be a superclass of Map yielding the following typing reduce :: (Map map a b) = ((a, b) - c) - c - map a b - c Functional dependencies will do this. class Collection coll a | coll - a where ... (+) :: coll - coll - coll reduce :: (a - b - b) - b - coll - b ... class (Collection map (a,b)) = Map map a b | map - a b where ... (+) :: map - map - map at :: map - a - b Now you make instances like instance Collection [a] a where (+) = (++) reduce = foldr instance (Eq a) = Map [(a,b)] a b where new + old = nubBy (\(x,_) (y,_) - x == y) (new ++ old) at map x = fromJust (lookup x map) Note that in an OO programming language with generic classes (which is in general much less expressive than real polymorphism), I can write class MAP[A, B] inherit COLLECTION[TUPLE[A, B]] which has exactly the desired effect (and that's what I do in the imperative version of my little library). This isn't exactly the same thing. In the OO code the interface collections must provide consists of a set of methods. A particular type, like COLLECTION[INTEGER] is the primitive unit that can implement or fail to implement that interface. In the Haskell code you require a collection to be a type constructor that will give you a type with appropriate methods no matter what you apply it to (ruling out special cases like extra compace sequences of booleans and so on). A map is not something that takes a single argument and makes a collection, so nothing can implement both of your map and collection interfaces. The solution is simple, drop the spurrious requirement that collections be type constructors (or that all of our concrete collection types were created by applying some type constructor to the element type). The classes with functional dependencies say just that, our collection type provides certain methods (involving the element types). Collections were one of the examples in Mark Jones' paper on functional dependencies (Type Classes with Functional Dependencies, linked from the GHC Extension:Functional Dependencies section of the GHC user's guide). There seems to be no direct way to achieve the same thing with Haskell type classes (or any extension I'm aware of). Here is a quesion for the most creative of thinkers: which is the design (in proper Haskell or a wide-spread extension) possibly include much intermediate type classes and other stuff, that comes nearest to my desire? I believe this question to be important and profound. (We shouldn't make our functional designs more different from the OO ones, than they need to be.) If I err, someone will tell me :- What problems do objects solve? They let you give a common interface to types with the same functionality, so you can make functions slightly polymorphic in any argument type with the operations your code needs. They organize your state. Then let you reuse code when you make a new slightly different type. Am I missing anything here? I think type classes are a much better solution than inheritance for keeping track of which types have which functionality. (at least the way interface by inheritance works in most typed and popular object oriented languages.) Inheritance only really works for notions that only involve the type doing the inheriting, or are at least heavly centered around that type. I don't think Functor can be represented as an interface, or at least not a very natural one. Most langauges I know of (see Nice for an exception) also require you to declare the interface a class supports when you declare it, which is really painful when you want your code to work with types that were around before you were, like defining a class to represent marshallable values for interface/serialization code. Are there any advantages to inheritance for managing interfaces? Maybe it takes a few minutes less to explain the first time around. It's probably easier to implement. Beyond that, I see nothing. Any creative thinkers want to try this? (An answer here would motivate an extension to the type class system, of course). Brandon Robert ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
GreenCard (How to Marshell Int64)
Hello:
I am using GreenCard to
import some C code into Haskell. The code I want to import uses
"long" in a lot of places. I tried to write my own DIS for it
andIalso write a very simple test program. However,the DIS
does not workproperly. My program and test result are as following:
--
module TLong where
import Foreign.GreenCard
type Long = Int64%dis long x = int64 x
%dis int64 x = %%Int64 ({HsInt64}
x)
%fun tslong :: Long - Long%call (long
a1)%code long a2;% a2 =
a1;% printf("the long integer is %d the original is
%d \n", a2, a1);%result (long
(a2))--
.
TLongtslong 1
the long integer is -1073752653 the original is
-10173752653
-4611732526480752641
--
I know it is caused
by my DIS, butI have no idea what is the right way to do it. Does anyone
know the right way to do it?
Best Regards
Liwen
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: Preventing/handling space leaks
L.S., On Wed, 10 Dec 2003 09:49:54 -0800, Iavor S. Diatchki [EMAIL PROTECTED] wrote: hello, Henk-Jan van Tuyl wrote: : : So far I have seen only one rule for Good Coding Practice in Haskell: Do Not Use n+k Patterns. I hope someone can give some directions, how to avoid known pitfalls (especially Space Leaks). not that i am a big fan of n+k patterns but why are they bad coding practise? 1) It takes no effort, once you are use to it, to code without n+k patterns; on the other hand, when you often use these patterns, you might spend hours debugging an endless looping program. If you are working under high pressure in a large project, chances are, that the testing departement will find your bug and write a bug report (or worse, the customer might find it). Report handling and bug solving costs an enormous amount of money. This has resulted in the clean room approach for software design: prevent bugs rather than solve them. See also Finnagle's Law. 2) It is likely, that n+k patterns dissapear in the next Haskell standard. If you don't like to rewrite, test and debug all your software every few years, don't use any language/compiler features that are likely to dissapear. This is another thing that might cost companies a lot of money. -- Best regards, Henk-Jan van Tuyl ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: import modules from a different directory
moved to haskell-cafe Hi, You can give GHC with -iPath a directory where to look for modules. With -v you see where GHC actually looks for libraries. Cheers, Georg On Thu, 11 Dec 2003 15:59:04 +0800 (GMT-8), Wang Meng [EMAIL PROTECTED] wrote: Hi All, Anybody has the experience of importing a module from a different directory?In my code, i need to import a module that is not in the current directory. How can I do that in GHC? -W-M- @ @ | \_/ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
bugs from n+k patterns (was: Re: Preventing/handling space leaks)
hi, first here is why i think n+k patterns are problematic; 1) they lead to some parsing awkwardness (e.g. when n+k pattern bindings are involved, but those don'treally make much sense anyways) 2) in haskell as it is, patterns are associated with algebraic datatypes, and n+k patterns may erronously suggest that all numbers are such for the rest, apologies if i appear to be ranting :-) Henk-Jan van Tuyl wrote: 1) It takes no effort, once you are use to it, to code without n+k patterns; this does not seem like a good argument. there are many other features like that in haskell. for example, going by that we could remove lambda abstractions (i am not saying we should) on the other hand, when you often use these patterns, you might spend hours debugging an endless looping program. how do n+k patterns lead to looping programs? If you are working under high pressure in a large project, chances are, that the testing departement will find your bug and write a bug report (or worse, the customer might find it). Report handling and bug solving costs an enormous amount of money. This has resulted in the clean room approach for software design: prevent bugs rather than solve them. See also Finnagle's Law. i find this reasoning backward. i agree (of course!) that we should write programs without bugs. i find it strange that people often motivate that, by telling me that bugs cost a lot of money for some company. if companies happened to make money out of bugs (and some do), would it then be ok to write buggy software? i guess it all comes down to what one takes as primary -- writing good software, or making money. 2) It is likely, that n+k patterns dissapear in the next Haskell standard. If you don't like to rewrite, test and debug all your software every few years, don't use any language/compiler features that are likely to dissapear. This is another thing that might cost companies a lot of money. i didn't know anyone is working on a next haskell standard. have n+k patterns been made obsolete? -iavor -- == | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | == ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: bugs from n+k patterns (was: Re: Preventing/handling space leaks)
On Thu, 11 Dec 2003 06:23:51 -0800 Iavor S. Diatchki [EMAIL PROTECTED] wrote: ... Henk-Jan van Tuyl wrote: ... 2) It is likely, that n+k patterns dissapear in the next Haskell standard. If you don't like to rewrite, test and debug all your software every few years, don't use any language/compiler features that are likely to dissapear. This is another thing that might cost companies a lot of money. i didn't know anyone is working on a next haskell standard. have n+k patterns been made obsolete? I don't know of any other feature that has had this, Many people feel that n+k patterns should not be used. These patterns may be removed or changed in future versions of Haskell., said about it in the (online) Report (3.17.2). Obviously, the second sentence is vacuous; anything can be removed or changed in future versions of Haskell, but the intent seems clear (and is somewhat self-fulfilling). ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: bugs from n+k patterns (was: Re: Preventing/handling space leaks)
The n+k pattern issue inspired endless debates on the Haskell committee and this feature was considered for removal in nearly every iteration of the Haskell report. We all agreed that n+k is extremely ad-hoc but that certain programs can be expressed slightly more elegantly using them. Unfortunately n+k doesn't match against negative numbers, so let n+1 = ... in n ... is not the same as let n = in (n-1) ... Of course n+k was designed for natural numbers but these are not a separate numeric type so you get a certain amount of confusion. One proposal was to make naturals a distinct type and restrict n+k to only naturals. The syntactic issues surrounding n+k are truely awful and I still have to look at the report to remember what happens with these: n+1 = 2 (n+1) = 2 A lot of people would have been happy to replace n+k by some view-like mechanism that gives the user control over the meaning of n+k but we never managed to get views into the report. John ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
