Re: [Vhs-ufpe] problems building GHC from source in Windows
Starting with a completely fresh tree indeed solved the problem. Finally I was able to compile GHC from source, but I'd like to report that nofib and hood are actually breaking the fptools build. nofib error is: /bin/sh -c ././exp3_8_p +RTS -SC:/TEMP/stats392 -RTS +RTS -H10m -K10m -RTS 8 /dev/null 1 C:/TEMP/runtest392.1 2 C:/TEMP/runtest392.2 3 C:/TEMP/runtest392. 3 ././exp3_8_p +RTS -H10m -K10m -RTS 8 /dev/null expected stdout not matched by reality *** exp3_8.stdout Tue Nov 26 11:46:26 1996 --- C:/TEMP/runtest392.1Thu Feb 26 18:42:44 2004 *** *** 1 ! 6561 --- 1 ! 6561 make[4]: *** [runtests] Error 1 make[3]: *** [all] Error 1 make[2]: *** [all] Error 1 make[1]: *** [all] Error 1 make[1]: Leaving directory `/cygdrive/c/haskell/cvs2/fptools/nofib' make: *** [build] Error 1 hood error is: make[1]: Leaving directory `/cygdrive/c/haskell/cvs2/fptools/hdirect' make[1]: Entering directory `/cygdrive/c/haskell/cvs2/fptools/hood' make[1]: *** No rule to make target `boot'. Stop. make[1]: Leaving directory `/cygdrive/c/haskell/cvs2/fptools/hood' make: *** [build] Error 1 Removing them from my local machine made it possible to proceed. Cheers, -- Andre - Original Message - From: Simon Peyton-Jones [EMAIL PROTECTED] To: Andre Santos [EMAIL PROTECTED]; Andre W B Furtado [EMAIL PROTECTED] Cc: GHC bugs [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, February 23, 2004 8:23 AM Subject: RE: [Vhs-ufpe] problems building GHC from source in Windows [redirecting to ghc-bugs] I have seen this before. Things are going wrong when you use the newly built compiler to compile the run-time system. (This is the first RTS file it compiles, right?) Trouble is, I can't remember what was wrong. I hope you configured with --with-gcc=c:/mingw/bin/gcc as specified?Is this a completely clean build, starting with autoreconf, in a tree with no old files lying around in it? (If not, start a completely fresh tree -- I do have a vague memory that make clean didn't make clean enough...) Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-users- | [EMAIL PROTECTED] On Behalf Of Andre Santos | Sent: 22 February 2004 07:10 | To: Andre W B Furtado | Cc: glasgow-haskell-users; [EMAIL PROTECTED] | Subject: Re: [Vhs-ufpe] problems building GHC from source in Windows | | Hi Andre, | | are you sure you have a ../../ghc/compiler/ghc-inplace file/compiler? | You need to have compiled the ghc/compiler directory to have that. | | If you are only building a different rts you should have used | make HC=your-ghc-compiler otherwise it will try to use | the inplace one (which is the usual/standard behaviour). | | Andre. | | Andre W B Furtado wrote: | | I was trying to build GHC in my Windows XP, using Cygwin, following the | steps in the building guide. I'm stuck in the following error when executing | make in fptools: | | creating libgmp.la | (cd .libs rm -f libgmp.la ln -s ../libgmp.la libgmp.la) | make[6]: Leaving directory `/cygdrive/c/haskell/cvs/fptools/ghc/ghc/rts/gmp' | make[5]: Leaving directory `/cygdrive/c/haskell/cvs/fptools/ghc/ghc/rts/gmp' | ../../ghc/compiler/ghc-inplace -H16m -O -O2 -static-c Apply.hc -o | Apply.o | make[3]: *** [Apply.o] Error 1 | make[2]: *** [all] Error 1 | make[2]: Leaving directory `/cygdrive/c/haskell/cvs/fptools/ghc/ghc' | make[1]: *** [build] Error 1 | make[1]: Leaving directory `/cygdrive/c/haskell/cvs/fptools/ghc' | make: *** [build] Error 1 | | Any suggestions? | Thanks, | -- Andre | | ___ | Vhs-ufpe mailing list | [EMAIL PROTECTED] | http://noronha.cin.ufpe.br/mailman/listinfo/vhs-ufpe | | ___ | Glasgow-haskell-users mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
locating package.conf II
Hi, In July 2003, a discussion in this list named locating package.conf (http://www.haskell.org/pipermail/glasgow-haskell-users/2003-July/005511.htm l) concluded that make install on Windows is not supported. Has this evolved since then? Thanks, -- Andre ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-904512 ] hiding does not follow haskell report
Bugs item #904512, was opened at 2004-02-25 20:15 Message generated for change (Comment added) made by simonpj You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=904512group_id=8032 Category: Compiler Group: 6.0.1 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: hiding does not follow haskell report Initial Comment: Email: [EMAIL PROTECTED] As understand hiding from the Haskell report, it should hide only the unqualified name and not the qualified name, e.g., hide head but not Prelude.head (or List.head). This is not the case with ghc 6.0.1: [EMAIL PROTECTED]:/bug-2111 cat Main.hs module Main where import Prelude hiding (head) main = do print (Prelude.head [0..]) head head = print head [EMAIL PROTECTED]:/bug-2112 ghc --version The Glorious Glasgow Haskell Compilation System, version 6.0.1 [EMAIL PROTECTED]:/bug-2113 ghc -fglasgow-exts -o Main --make Main Chasing modules from: Main Compiling Main ( Main.hs, ./Main.o ) Main.hs:5: Variable not in scope: `Prelude.head#039; [EMAIL PROTECTED]:/bug-2114 ghc -o Main --make Main Chasing modules from: Main Compiling Main ( Main.hs, ./Main.o ) Main.hs:5: Variable not in scope: `Prelude.head#039; [EMAIL PROTECTED]:/bug-2115 runhugs Main 0 head as expected. -- Comment By: Simon Peyton Jones (simonpj) Date: 2004-02-26 12:38 Message: Logged In: YES user_id=50165 Quite right! Thus bug has been there for ages, but no one (including us) noticed. I'm going to fix the HEAD. It turns out to be more awkward to fix the 6.2 branch, so I'll let it lie. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=904512group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Generics missing Data instances...
There appears to be no instance for Double values in the Generics.Basic Also no instance for Ptr. am I not importing the right file, or does this need to be fixed? Regards, Keean Schupke. PS. This is with ghc-6.2 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Generics... no Tuples 2 either...
I've been frustrated by the same lack of instances; as a stopgap, here's one for a three-tuple. The pattern is pretty clear and can easily be extended to whatever size you'd like. tupCon = mkConstr 1 (,,) Prefix instance (Data a, Data b, Data c) = Data (a, b ,c) where gfoldl k z (a, b, c) = ((z (,,) `k` a) `k` b) `k` c toConstr _ = tupCon fromConstr _ = (undefined, undefined, undefined) dataTypeOf _ = mkDataType [tupCon] MR K P SCHUPKE [EMAIL PROTECTED] writes: Any chance of Data instances for tuples of size greater than 2... One of the nice things about generics is you can use them by deriving Data on your datatypes - of course this doesn't work if you all of a sudden have to put a load of boiler-plate in just to use tuples... Regards, Keean Schupke ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] Re: Data.Set whishes
I have always wondered why the module system is not used at all in these conventions. I mean, the function names seem to come straight from the Haskell 1.2 days when there was no module system! I used the module system in this way in the first version of the HGL (http://haskell.org/graphics/). For example, fonts, colours, etc all provided three operations 'create', 'delete' and 'select' instead of 'createFont', 'createColor', etc. If (as was common), you imported several of these modules, you would use 'Font.create', 'Color.create', etc. All seemed very clean. I deliberately switched away from this in the second release because it wasn't working very well. The problem is that most users don't want to have to write: import Font import Color import Window [about 10 such modules in total] they just want to write: import Graphics where the Graphics module imports Font, Color, Window, etc and re-exports them. The problem is that you can't use any of the 'create' functions if you import Graphics since any reference to 'Graphics.create' would be ambiguous. Haskell's module system provides a way for a module to merge multiple modules into one but provides no way to eliminate any ambiguities this may create. If we want to be able to use names like 'create' instead of 'createFont', we need to change the module system. The obvious fix would have some of the flavour of the ML module system where a module can export a structured list of names instead of exporting a flat list of names. -- Alastair Reid ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: [Haskell] performance tuning Data.FiniteMap
| But in managing this tradeoff, what is faster: | * constructing/destructing e.g. 16 trees (for a 65000 item table) | * 2 memcpy of 256 item arrays (perhaps after you primop?) | | If the later is not dramatically slower than I | will bias towards more arrayness. I doubt the latter is dramatically slower, but you'd have to experiment to find out. And GHC is not doing as well as it should on arrays just now. (One of the things on our to-do list.) Might vary between implementations too. Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Per-type function namespaces (was: Data.Set whishes)
David Bergman [EMAIL PROTECTED] writes: | The idea that I've been throwing around is to be able to define a | separate namespace for each type; a function can either belong in a | global (default) namespace, or belong in a particular type's | namespace. So, in the above example, instead of writing addToFM fm | ..., we could instead associate an 'add' function with the FiniteMap | type, so we could write fm.add ... instead. Provided that fm's type | is monomorphic, it should be possible to call the 'correct' add | function; if we defined another 'add' function that's associated with | the Set type, that will only get called if the 'x' in x.add is of | type :: Set. So, like OO languages which inherently give separate | namespaces to their different objects, here we give separate | namespaces to different | (monomorphic) types. In this case, if one simply writes add instead | of x.add, the compiler throws an error, because there is no 'add' | function defined in the default namespace; add is only defined when a | programmer writes x.add where x :: FiniteMap or x :: | Set[1]. | | This overloading by namespace is usually called either ADL | (Argument-Dependent Lookup) or Koenig Lookup (especially in C++.) Actually in C++, it is called argument dependent name lookup, and that is the way the C++ definition text calls it. As Andy Koenig has himself pointed out, he did not invent that rule. He mentionned it when the C++ committee was solving a name look-up problem posed by namespaces to operator functions. That name look-up rule was later generalized to non-operator to cover the function-call syntax -- which is what is most known today and referred to above. This ends my C++ hour on Haskell list :-) -- Gaby ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] regular expression syntax - perl ain't got nothin on haskell
On Tue, Feb 24, 2004 at 05:24:41PM -, Simon Marlow wrote: [Graham Klyne wrote:] I recently ran into some problems porting some Haskell code to Windows because it used the Text.Regex library, which is dependent on a Unix-only system. Text.Regex works fine on Windows, at least on GHC. It seems that Hugs doesn't make it available, perhaps because it requires an auxiliary C regex engine, which we provide as part of GHC. It may be that this code isn't as portable as the rest of Hugs, which is why they don't provide it, but I'll let the Huge folks comment on that. It looks possible. The only awkwardness I can see is telling the Hugs package converter where to find regex.h ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Per-type function namespaces (was: Data.Set whishes)
I've had an idea stewing in my head to do with per-type function namespaces, that the current module namespace discussion reminded me about. The problem is that there is a limited namespace for functions, so that if you define a new data type, it is unwise to call functions which work on that data type a very generic name such as 'add'. An example of this is Data.FiniteMap and Data.Set: both data types define a function to add things to their respective data types. addToFM :: Ord key = FiniteMap key elt - key - elt - FiniteMap key elt addToSet :: Ord a = Set a - a - Set a So at the moment, many Haskellers will append the type name to the function to indicate that it only works on that particular data type. In this respect, Haskell is at a disadvantage vs most object-oriented languages, because in them, you can write x.add, and the type system will perform object-oriented polymorphism for you and call the correct add method, no matter if x is a FiniteMap or a Set. Writing addToFM fm ... or addToSet set ... is surely a lot more inconvenient than writing fm.add or set.add, no? The idea that I've been throwing around is to be able to define a separate namespace for each type; a function can either belong in a global (default) namespace, or belong in a particular type's namespace. So, in the above example, instead of writing addToFM fm ..., we could instead associate an 'add' function with the FiniteMap type, so we could write fm.add ... instead. Provided that fm's type is monomorphic, it should be possible to call the 'correct' add function; if we defined another 'add' function that's associated with the Set type, that will only get called if the 'x' in x.add is of type :: Set. So, like OO languages which inherently give separate namespaces to their different objects, here we give separate namespaces to different (monomorphic) types. In this case, if one simply writes add instead of x.add, the compiler throws an error, because there is no 'add' function defined in the default namespace; add is only defined when a programmer writes x.add where x :: FiniteMap or x :: Set[1]. There are a number of means by which the x in x.add can be communicated to the actual function: it's similar to the hidden 'self' or 'this' variable that's present when you invoke a method on an object in OO. Perhaps x is passed to the function as its first parameter, or maybe it could be its last parameter, or even an arbitrary parameter (where the parameter it's passed as could be defined in the type signature of the function). Perhaps 'self' or 'this' could be an implicit parameter. Any one of them will work just fine, I think. However, this scheme is only for functions which have such a 'primary' data type to be associated with, such as FiniteMap or Set. For functions which are truly polymorphic (such as ==), you still leave them in the default namespace. Perhaps it's sensible to even make it a requirement that functions in the default namespace must be polymorphic: if they are monomorphic, they are associated with operating on a specific data type, so they should belong in a type-specific namespace. You then still guarantee that such commonly-used polymorphic functions cannot be 'hijacked' to have stupid type signatures; i.e. == is always guaranteed to be :: Eq a - a - Bool. Anyhow, feedback is more than welcome; I would certainly welcome this addition if it's feasible. It feels inferior to be typing in 'addToFM foo' all the time when our OO brethren type the simpler and more succinct 'foo.add', especially given that Haskell's type system is far more powerful! 1. I haven't thought hard enough about whether it would be possible to have the same function name in both the 'default' namespace as well as in per-type namespaces, but my gut feeling says it should be OK. -- % Andre Pang : trust.in.love.to.save ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Per-type function namespaces (was: Data.Set whishes)
I've had an idea stewing in my head to do with per-type function namespaces, that the current module namespace discussion reminded me about. The problem is that there is a limited namespace for functions, so that if you define a new data type, it is unwise to call functions which work on that data type a very generic name such as 'add'. [..] The idea that I've been throwing around is to be able to define a separate namespace for each type; a function can either belong in a global (default) namespace, or belong in a particular type's namespace. This feature would seem to be in competition with type classes; could you elaborate on the relative advantages and disadvantages? The type class story has the advantage of being well understood and quite effective, but there are certainly some limitations too. --KW 8-) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Haskell job (OH, USA)
Aetion Technologies LLC seeks another high-quality programmer. Development is mostly in Haskell, with some Java, mostly under Linux. An ideal candidate is excellent at acquiring, applying, and writing about new knowledge. Additional background in disciplines like mathematics, science, engineering, etc. is also attractive. Aetion's main customers are in defense and finance, so we prefer to hire people who can likely get a security clearance, and who do not object to developing military applications. Telecommuting isn't really an option, but Columbus, Ohio is a nice enough city, and the work tends to be varied and interesting - more challenging than mundane. Although we work to build useful software, a lot of our activities are at the leading edge of research, keeping us far ahead of competitors. The vacancy has not yet been advertised more formally through the usual HR channels. Aetion is most definitely an equal-opportunity employer. It would be fine to direct questions and resumes directly to me; I can pass them on to the right people where necessary. -- Mark ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Per-type function namespaces (was: Data.Set whishes)
On 27/02/2004, at 3:47 AM, Keith Wansbrough wrote: I've had an idea stewing in my head to do with per-type function namespaces, that the current module namespace discussion reminded me about. The problem is that there is a limited namespace for functions, so that if you define a new data type, it is unwise to call functions which work on that data type a very generic name such as 'add'. [..] The idea that I've been throwing around is to be able to define a separate namespace for each type; a function can either belong in a global (default) namespace, or belong in a particular type's namespace. This feature would seem to be in competition with type classes; could you elaborate on the relative advantages and disadvantages? The type class story has the advantage of being well understood and quite effective, but there are certainly some limitations too. I don't think type classes can solve the problem I'm trying to tackle. As an example of why, check out the types of FiniteMap and Set's 'add' functions: addToFM :: Ord key = FiniteMap key elt - key - elt - FiniteMap key elt addToSet :: Ord a = Set a - a - Set a Note that the type of addToFM takes in two parameters (besides the FiniteMap itself): a key and an element, whereas the type of addToSet only takes in one parameter, which is the thing to add. So, how can you come up with a type class which provides a polymorphic 'add' function, considering you don't even know how many parameters each data type's individual add function uses? Even if you could define such a type class (which I don't think is possible), you then have one less function in the namespace to use, which is another problem. For example, say I'm writing the Data.Complex module; there's a function in that module phase :: RealFloat a = Complex a - a. So, how do you put this phase function into a type class? Perhaps you could abstract away from the RealFloat and Complex bits, so you have a phase function which is generalised to work over a Num and an arbitrary data type instead; e.g. class Phase c where phase :: Num a = c a - a. But what happens if, say, somebody adds a Moon data type, and they want to write a phase function which returns the phase of such a moon? Phases of the moon certainly aren't Nums, nevermind the fact that you probably want to supply your moon phase's function with some sort of date as an extra parameter, which means the Phase type class isn't flexible enough. Type classes are designed to provide a type-consistent interface to functions which perform different behaviour, unifying them as one function like + or == -- but it's designed to work for arbitrary types. What I'm after is an interface for a function which may change depending on a primary type it's working with, which is almost the opposite to type classes. -- % Andre Pang : trust.in.love.to.save ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Per-type function namespaces (was: Data.Set whishes)
I think that this is a problem that can be solved with a simple convention change, rather than a language extension - instead of appending type names, I think it would be much better if modules simply used the short, convenient, common names and expected the user to import them qualified where overlap is a problem - in short, do exactly what DData does. It's slightly more verbose than OO-style: Map.add map key value instead of map.add(key, value); but I don't think that what OO does is a good language design target. Another random thought: what you describe sounds awfully similar to typeclasses, just with a single function in each typeclass. Abe [EMAIL PROTECTED] writes: I've had an idea stewing in my head to do with per-type function namespaces, that the current module namespace discussion reminded me about. The problem is that there is a limited namespace for functions, so that if you define a new data type, it is unwise to call functions which work on that data type a very generic name such as 'add'. An example of this is Data.FiniteMap and Data.Set: both data types define a function to add things to their respective data types. addToFM :: Ord key = FiniteMap key elt - key - elt - FiniteMap key elt addToSet :: Ord a = Set a - a - Set a So at the moment, many Haskellers will append the type name to the function to indicate that it only works on that particular data type. In this respect, Haskell is at a disadvantage vs most object-oriented languages, because in them, you can write x.add, and the type system will perform object-oriented polymorphism for you and call the correct add method, no matter if x is a FiniteMap or a Set. Writing addToFM fm ... or addToSet set ... is surely a lot more inconvenient than writing fm.add or set.add, no? The idea that I've been throwing around is to be able to define a separate namespace for each type; a function can either belong in a global (default) namespace, or belong in a particular type's namespace. So, in the above example, instead of writing addToFM fm ..., we could instead associate an 'add' function with the FiniteMap type, so we could write fm.add ... instead. Provided that fm's type is monomorphic, it should be possible to call the 'correct' add function; if we defined another 'add' function that's associated with the Set type, that will only get called if the 'x' in x.add is of type :: Set. So, like OO languages which inherently give separate namespaces to their different objects, here we give separate namespaces to different (monomorphic) types. In this case, if one simply writes add instead of x.add, the compiler throws an error, because there is no 'add' function defined in the default namespace; add is only defined when a programmer writes x.add where x :: FiniteMap or x :: Set[1]. There are a number of means by which the x in x.add can be communicated to the actual function: it's similar to the hidden 'self' or 'this' variable that's present when you invoke a method on an object in OO. Perhaps x is passed to the function as its first parameter, or maybe it could be its last parameter, or even an arbitrary parameter (where the parameter it's passed as could be defined in the type signature of the function). Perhaps 'self' or 'this' could be an implicit parameter. Any one of them will work just fine, I think. However, this scheme is only for functions which have such a 'primary' data type to be associated with, such as FiniteMap or Set. For functions which are truly polymorphic (such as ==), you still leave them in the default namespace. Perhaps it's sensible to even make it a requirement that functions in the default namespace must be polymorphic: if they are monomorphic, they are associated with operating on a specific data type, so they should belong in a type-specific namespace. You then still guarantee that such commonly-used polymorphic functions cannot be 'hijacked' to have stupid type signatures; i.e. == is always guaranteed to be :: Eq a - a - Bool. Anyhow, feedback is more than welcome; I would certainly welcome this addition if it's feasible. It feels inferior to be typing in 'addToFM foo' all the time when our OO brethren type the simpler and more succinct 'foo.add', especially given that Haskell's type system is far more powerful! 1. I haven't thought hard enough about whether it would be possible to have the same function name in both the 'default' namespace as well as in per-type namespaces, but my gut feeling says it should be OK. -- % Andre Pang : trust.in.love.to.save ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Per-type function namespaces (was: Data.Set whishes)
On 27/02/2004, at 8:28 AM, Abraham Egnor wrote: I think that this is a problem that can be solved with a simple convention change, rather than a language extension - instead of appending type names, I think it would be much better if modules simply used the short, convenient, common names and expected the user to import them qualified where overlap is a problem - in short, do exactly what DData does. It's slightly more verbose than OO-style: Map.add map key value instead of map.add(key, value); but I don't think that what OO does is a good language design target. This is exactly what was discussed in the thread before I barged in with per-type function namespaces, and it's not a good solution because of what Alastair has mentioned. It's also not a good solution because I still have to type Map.add map instead of map.add: the type system already knows that map of type Map, so why should I have to qualify it even more by sticking a module name in front, and also encode the type name into my function because the module/namespace system isn't good enough to deal with this issue? I also agree that what OO does is not a good language design target, but I do think that leverage type system to make programming nicer for you is a good design target :). We're using a form of hungarian notation for function names, which is necessary because of a global namespace; OO people abolished this a long time ago. Another random thought: what you describe sounds awfully similar to typeclasses, just with a single function in each typeclass. It's not the same as a single-function type class, for the reasons that I pointed out to Keith Wansbrough in an earlier email. -- % Andre Pang : trust.in.love.to.save ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: [Haskell] Per-type function namespaces (was: Data.Set whishes)
Mr. Ozone wrote: [snip] So at the moment, many Haskellers will append the type name to the function to indicate that it only works on that particular data type. In this respect, Haskell is at a disadvantage vs most object-oriented languages, because in them, you can write x.add, and the type system will perform object-oriented polymorphism for you and call the correct add method, no matter if x is a FiniteMap or a Set. Writing addToFM fm ... or addToSet set ... is surely a lot more inconvenient than writing fm.add or set.add, no? Yes. But, you are refering to overloading, no? And, not subtype polymorphism (which is what I denote with object-oriented polymorphism)? Just to make things clear in my mind. The idea that I've been throwing around is to be able to define a separate namespace for each type; a function can either belong in a global (default) namespace, or belong in a particular type's namespace. So, in the above example, instead of writing addToFM fm ..., we could instead associate an 'add' function with the FiniteMap type, so we could write fm.add ... instead. Provided that fm's type is monomorphic, it should be possible to call the 'correct' add function; if we defined another 'add' function that's associated with the Set type, that will only get called if the 'x' in x.add is of type :: Set. So, like OO languages which inherently give separate namespaces to their different objects, here we give separate namespaces to different (monomorphic) types. In this case, if one simply writes add instead of x.add, the compiler throws an error, because there is no 'add' function defined in the default namespace; add is only defined when a programmer writes x.add where x :: FiniteMap or x :: Set[1]. This overloading by namespace is usually called either ADL (Argument-Dependent Lookup) or Koenig Lookup (especially in C++.) So, you have thought of automatically, but implicitly, introduce a namespace for each data type, and then have Haskell employ Koenig Lookup, to decide which function an expression is refering to? You realize, of course, that mere intranamespacial parameter type lookup (regular overloading) would achieve the same effect, without the (implicit) namespaces? The core problem in Haskell is to bypass the generics, i.e., make sure that a certain definition is used for a certain type, or combination of types. This can only be done by class instances, as of now, but there have been discussions of non-class overloading. There are a number of means by which the x in x.add can be communicated to the actual function: it's similar to the hidden 'self' or 'this' variable that's present when you invoke a method on an object in OO. Perhaps x is passed to the function as its first parameter, or maybe it could be its last parameter, or even an arbitrary parameter (where the parameter it's passed as could be defined in the type signature of the function). Perhaps 'self' or 'this' could be an implicit parameter. Any one of them will work just fine, I think. Again, I think you are confusing the runtime dispatching subtype polymorpism from overloading. Overloading would do what you want, while the subtype polymorphism could (still) be handled by class, and instances of classes, the Generic Programming way. /David ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: [Haskell] performance tuning Data.FiniteMap
Is fixing GHC arrays a big research job or is it something that someone can straightforwardly handle if my site actually gets enough traffic to warrant it? -Alex- On Thu, 26 Feb 2004, Simon Peyton-Jones wrote: | But in managing this tradeoff, what is faster: | * constructing/destructing e.g. 16 trees (for a 65000 item table) | * 2 memcpy of 256 item arrays (perhaps after you primop?) | | If the later is not dramatically slower than I | will bias towards more arrayness. I doubt the latter is dramatically slower, but you'd have to experiment to find out. And GHC is not doing as well as it should on arrays just now. (One of the things on our to-do list.) Might vary between implementations too. Simon _ S. Alexander Jacobson mailto:[EMAIL PROTECTED] tel:917-770-6565 http://alexjacobson.com ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Regular Expressions - take 2
I went ahead and implemented Perl Compatable Regular Expression support as well as a module which uses template haskell to check regular expressions at runtime. The full set of modules is RRegex - PCRE if available, else Posix, (compatable with Text.Regex) RRegex.PCRE- Perl compatable regular expressions RRegex.Posix - posix regular extensions (compatable with Text.Regex.Posix) RRegex.TH - template haskell compile-time checked regular expressions RRegex.Syntax - perl like overloaded matching syntax Along the way, I extende the Posix interface, as the one in Text.Regex.Posix was lacking in several key ways. among the more interesting changes are ability to use (?options) syntax with posix expressions all of PCRE goodness. which is a lot. much better error messages (compile-time when using TH) example: Fail: user error (PCRE Regular Expression Error: [a-z_A-Z]+\(.*); ^ unmatched parentheses) notice it points out the exact spot of the error. ability to pull out offset,length integer pairs, rather than extracting the substrings all the =~ stuff mentioned in my previous email. see the sort-of homepage here: http://haskell.org/hawiki/RegexSyntax and haddock documentation here: http://repetae.net/john/computer/haskell/hsregex/hsregex/docs/index.html John -- --- John Meacham - California Institute of Technology, Alum. - [EMAIL PROTECTED] --- ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: [Haskell] Per-type function namespaces (was: Data.Set whishes)
Gabriel wrote: | This overloading by namespace is usually called either ADL | (Argument-Dependent Lookup) or Koenig Lookup (especially in C++.) Actually in C++, it is called argument dependent name lookup, and that is the way the C++ definition text calls it. As Andy Koenig has himself pointed out, he did not invent that rule. He mentionned it when the C++ committee was solving a name look-up problem posed by namespaces to operator functions. That name look-up rule was later generalized to non-operator to cover the function-call syntax -- which is what is most known today and referred to above. This ends my C++ hour on Haskell list :-) Yeah! Get back to that dark corner where people solve real problems! ;-) /David ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Per-type function namespaces
Peter Strand [EMAIL PROTECTED] writes: That is, a function is looked up in the namespaces of its arguments as well as in the normal places. So add fm k v where fm :: FiniteMap, x :: Int, v :: String would look for add in the modules where FiniteMap, Int and String was defined. I suppose partial application would complicate things a bit here -- you don't necessarily know what the arguments are. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Per-type function namespaces (was: Data.Set whishes)
On Fri, 27 Feb 2004 [EMAIL PROTECTED] wrote: On 27/02/2004, at 1:13 PM, [EMAIL PROTECTED] wrote: 1) now I have to manually declare a class definition for every single function, and I have to declare it in advance before any module defines that function (most serious problem; see below), 2) I then have to declare instances of that type class for every function I define, 3) the type signature for phase reveals no clues about how to use that function. Declaring a type class instance is really no problem. You just need to write an instance Class (Type) instead of function :: Type on the line before the function declaration. The type on phase itself wouldn't provide much information, but the list of instances in each module defines would be informative. Something like :info wouldn't be much help without modification. So unfortunately, this is hardly a scalable solution. The entire reason I came up with the idea is because if we use type classes to implement this sort of overloading, we have to know every single possible function that any module author will ever create, and declare classes for those functions in advance. This is fine if you're declaring truly polymorphic functions which are designed from the start to be totally general, but it is not designed for functions which may do vastly different things and may contain totally different type signatures, but share the same name because that would be a sensible thing to do. (e.g. the phase function mentioned above.) In the paper Object-Oriented Style Overloading for Haskell, Mark Shields and Simon Peyton-Jones. One of the things they propose is adding method constraints to the type system which (as far as I can tell) basically amounts to generating a type class for each funtion name, and letting you write constraints like (foo :: Int - Int) on your function. They would set up the type classes like class Has_foo a where foo :: a, which can causes problems if your argument and return value are polymorphic under a class constraint rather than concrete types. Making the method classes implicitly closed would probably help here. (closed classes are another suggestion). While making that closed world assumption it would probably be nice if it only selected between the versions of the function that were actually in scope at the moment (so these would act kind of like methods that overload if you import several of them, rather than conflicting like normal). As long as we are integrating these special type classes into the language we can make sure things like error messages and ghci give decent information, maybe listing all the different types the function is imported at, and where each version is defined. With the per-type namespace separation I'm advocating, you do not need to know and declare in advance that each function will be overloaded, you simply write a FiniteMap.add function and a Set.add function, and you get a simpler form of namespace separation (or overloading) based on the first parameter that's passed to it. It is a solution which is more _flexible_ than requiring type class definitions, and it is better than having hungarian notation for functions. In fact, I think that, right now, if we replaced the current namespace separation offered by the hierarchical module system, and instead only had this sort of per-type namespace separation, things would still be better! How much of the structure of the first paramater would you look at? Could you an implementation for pairs that depended on the actual types in the pair? I think you should try to take advantage of the existing type class machinery as much as possible here, even if what you want are not exactly (standard) type classes. I realise my idea isn't very general in that it only allows this namespace lookup/overloading based on the type of a single argument parameter, and I think it would be possible with a bit more thinking to generalise it to work based on multiple arguments (e.g. via argument-dependent lookup, or whatnot). But even in its current form, I honestly think it offers far more flexibility and would lead to cleaner APIs than is currently possible. Read the paper and see if you think something like that might be useful. In any case, I think there's a decent chance that something useful for this would also be useful for building interfaces to object-oriented libraries, and vicea versa. I think there's probably something that covers both cases nicely and uniformly. Brandon -- % Andre Pang : trust.in.love.to.save ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Per-type function namespaces (was: Data.Set whishes)
On 27/02/2004, at 1:13 PM, [EMAIL PROTECTED] wrote:
For example, say I'm writing the Data.Complex module; there's a
function in that module phase :: RealFloat a = Complex a - a. So,
how do you put this phase function into a type class? Perhaps you
could abstract away from the RealFloat and Complex bits, so you have a
phase function which is generalised to work over a Num and an
arbitrary data type instead; e.g. class Phase c where phase :: Num a
= c a - a. But what happens if, say, somebody adds a Moon data
type, and they want to write a phase function which returns the phase
of such a moon? Phases of the moon certainly aren't Nums, nevermind
the fact that you probably want to supply your moon phase's function
with some sort of date as an extra parameter, which means the Phase
type class isn't flexible enough.
Here's the code that does exactly as you wish:
{-# OPTIONS -fglasgow-exts #-}
import qualified Complex
class Phase a b | a - b where
phase:: a - b
instance (RealFloat a) = Phase (Complex.Complex a) a where
phase = Complex.phase
data MoonPhase = P1 | P2 | P3 | P4 deriving Show
instance Phase Int MoonPhase where
phase x = if x `mod` 4 == 0 then P1 else P4
instance Phase MoonPhase (Int-Int) where
phase P1 x = x
phase P2 x = x+1
main = do
putStrLn $ show $ phase ( (1.0::Float) Complex.:+
(1.0::Float))
putStrLn $ show $ phase (0::Int)
putStrLn $ show $ phase P1 (2::Int)
Very, very nice Oleg :). I'm glad to know that we can achieve such
things using the existing type class mechanisms already. However, this
still doesn't solve the problem, because:
1) now I have to manually declare a class definition for every single
function, and I have to declare it in advance before any module defines
that function (most serious problem; see below),
2) I then have to declare instances of that type class for every
function I define,
3) the type signature for phase reveals no clues about how to use that
function.
So unfortunately, this is hardly a scalable solution. The entire
reason I came up with the idea is because if we use type classes to
implement this sort of overloading, we have to know every single
possible function that any module author will ever create, and declare
classes for those functions in advance. This is fine if you're
declaring truly polymorphic functions which are designed from the start
to be totally general, but it is not designed for functions which may
do vastly different things and may contain totally different type
signatures, but share the same name because that would be a sensible
thing to do. (e.g. the phase function mentioned above.)
With the per-type namespace separation I'm advocating, you do not need
to know and declare in advance that each function will be overloaded,
you simply write a FiniteMap.add function and a Set.add function, and
you get a simpler form of namespace separation (or overloading) based
on the first parameter that's passed to it. It is a solution which is
more _flexible_ than requiring type class definitions, and it is better
than having hungarian notation for functions. In fact, I think that,
right now, if we replaced the current namespace separation offered by
the hierarchical module system, and instead only had this sort of
per-type namespace separation, things would still be better!
I realise my idea isn't very general in that it only allows this
namespace lookup/overloading based on the type of a single argument
parameter, and I think it would be possible with a bit more thinking to
generalise it to work based on multiple arguments (e.g. via
argument-dependent lookup, or whatnot). But even in its current form,
I honestly think it offers far more flexibility and would lead to
cleaner APIs than is currently possible.
--
% Andre Pang : trust.in.love.to.save
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Per-type function namespaces (was: Data.Set whishes)
Hello!
So, how can you come up with a type class which provides a polymorphic
'add' function, considering you don't even know how many parameters
each data type's individual add function uses?
Very easily: every Haskell function takes only one
argument. Always. Ever.
For example, say I'm writing the Data.Complex module; there's a
function in that module phase :: RealFloat a = Complex a - a. So,
how do you put this phase function into a type class? Perhaps you
could abstract away from the RealFloat and Complex bits, so you have a
phase function which is generalised to work over a Num and an
arbitrary data type instead; e.g. class Phase c where phase :: Num a
= c a - a. But what happens if, say, somebody adds a Moon data
type, and they want to write a phase function which returns the phase
of such a moon? Phases of the moon certainly aren't Nums, nevermind
the fact that you probably want to supply your moon phase's function
with some sort of date as an extra parameter, which means the Phase
type class isn't flexible enough.
Here's the code that does exactly as you wish:
{-# OPTIONS -fglasgow-exts #-}
import qualified Complex
class Phase a b | a - b where
phase:: a - b
instance (RealFloat a) = Phase (Complex.Complex a) a where
phase = Complex.phase
data MoonPhase = P1 | P2 | P3 | P4 deriving Show
instance Phase Int MoonPhase where
phase x = if x `mod` 4 == 0 then P1 else P4
instance Phase MoonPhase (Int-Int) where
phase P1 x = x
phase P2 x = x+1
main = do
putStrLn $ show $ phase ( (1.0::Float) Complex.:+ (1.0::Float))
putStrLn $ show $ phase (0::Int)
putStrLn $ show $ phase P1 (2::Int)
You can evaluate a phase of a complex number, get a phase of the moon
corresponding to some integer, and even convert a phase of the moon to
a time (given another integer as a reference time). Whereas the first
two functions take one argument, the latter phase takes two
arguments. The class Phase takes the classical first-argument
overloading. Other overloading schemes are possible (e.g., the ones
that overload based on the result -- something that C++ just can't do:
e.g., Read). If we need to evaluate phases of Saturn moons (and we
overload on the first argument), we can resolve the overloading using
newtype:
newtype SaturnTime a = ST a
instance Phase (SaturnTime Int) (Int - MoonPhase) where
phase x moon_index = P1
newtypes add no run-time overhead, and actually help in making the
code more explicit.
Regarding Koening lookup: as I read in DDJ, it's just a hack! First
the committee added the namespaces, and then realized that using
operators like became hugely inconvenient. So Koening came up with
a hack. Shouldn't a language be designed in a more systematic way?
Speaking of the language design, November 2003 issue of Dr.Dobbs
J. has an interesting article: C++ Compilers and ISO Conformance [by
Brian A. Malloy, James F. Power and Tanton H. Gibbs, pp. 54-60].
Here's a summary. C++ standard has been ratified by the ISO Committee
in September 1998. There is no conformance suite however. So, we
cannot tell how well a particular compiler complies with a
standard. The authors of an article decided to create an approximate
conformance suite -- from the examples given in the standard
itself. It's a hard job -- the examples aren't meant to be a compiled
code, so some declarations and other pieces have to be filled in. The
result cannot be considered a truly compliance suite because not all
features of the language are illustrated in examples, and the
distribution of the examples is uneven. Nevertheless, it's a start.
The authors of the article have tested several compilers. The bottom
line -- after five years, no single compiler fully complies with the
standard. The best compiler, from the Edison Group (a three-person
company) fails only 2 tests. Intel's compiler fails three. Visual C++
7.1 from Microsoft fails 12. Gcc 3.3 fails 26. The latter number shows
that a wide community participation and OpenSource do not necessarily
lead to a better product. Gcc 3.3 is also one of the slowest
compilers.
But there is worse news for C++. C++ Language Standard consists of 776
pages, describing C++ language and the C++ core library. At present,
411 points in the C++ language part and 402 points in the library
part have been identified as questionable or outright erroneous. 93
language issues have been already acknowledged as errors. That is,
EVERY page of the standard, on average, contains some issue! The
committee obviously didn't bother to check their examples. Well, even
now there isn't a compiler that complies with the standard -- whatever
the compliance may mean.
Not only programmers don't know what some C++
rules mean. Not only compiler writers are puzzled. Even the committee
itself obviously doesn't know how _many_ features are supposed to
work. Can you imagine more shoddy work?
Incidentally, here's one questionable example
Re: [Haskell] Re: Data.Set whishes
Alastair Reid [EMAIL PROTECTED] wrote: Haskell's module system provides a way for a module to merge multiple modules into one but provides no way to eliminate any ambiguities this may create. If we want to be able to use names like 'create' instead of 'createFont', we need to change the module system. The obvious fix would have some of the flavour of the ML module system where a module can export a structured list of names instead of exporting a flat list of names. i'm not familiar with ml's module system so i don't know if my suggestion is the same or similar, but could a good solution be to allow modules to be exported as qualified modules? for example module Graphics ( module Font qualified, module Color qualified, module Window qualified, ... ) where ... chris moline ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Per-type function namespaces
[EMAIL PROTECTED] wrote: I've had an idea stewing in my head to do with per-type function namespaces, . The idea that I've been throwing around is to be able to define a separate namespace for each type; a function can either belong in a global (default) namespace, or belong in a particular type's namespace. So, in the above example, instead of writing addToFM fm ..., we could instead associate an 'add' function with the FiniteMap type, so we could write fm.add ... instead. Provided that fm's type is monomorphic, it should be possible to call the 'correct' add function; if we defined another 'add' function that's associated with the Set type, that will only get called if the 'x' in x.add is of type :: Set. So, like OO languages which inherently give separate namespaces to their different objects, here we give separate namespaces to different (monomorphic) types. In this case, if one simply writes add instead of x.add, the compiler throws an error, because there is no 'add' function defined in the default namespace; add is only defined when a programmer writes x.add where x :: FiniteMap or x :: Set[1]. Wouldn't something like Koenig Lookup in C++ solve this problem as well, without the need for a new (strange) syntax? That is, a function is looked up in the namespaces of its arguments as well as in the normal places. So add fm k v where fm :: FiniteMap, x :: Int, v :: String would look for add in the modules where FiniteMap, Int and String was defined. However, both of these methods means that we have to know the types of the arguments to be able to resolve names, probably forcing us to write a lot more type signatures than otherwise. It feels a bit like we're just trading one problem for another.. (lots of qualified names vs. lots of type signatures). But it might be worth it.. Would Koenig lookup (or something similar) be feasable in Haskell? Or would it just lead to unnecessary complexity? Name lookup in C++ is not exactly simple, so it might be a bad place to borrow ideas from.. ;) /Peter ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Per-type function namespaces (was: Data.Set whishes)
[EMAIL PROTECTED] writes: addToFM :: Ord key = FiniteMap key elt - key - elt - FiniteMap key elt addToSet :: Ord a = Set a - a - Set a So, how can you come up with a type class which provides a polymorphic 'add' function, considering you don't even know how many parameters each data type's individual add function uses? Why, by chea^H^H^Hurrying, of course: class Collection a b | a - b where add :: a - b - a instance Collection Set a where add = addToSet instance Collection FiniteMap k e where add fm (k,e) = addToFM fm k e But I take your point, this could be hard to do in the general case. E.g. 'delete' would probably only want a key. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] Outstanding context : (Num b, Random b)
Hi, I am very new to haskell. Could anyone please explain why these two things are not equivalent: m2 = do a - (drawInt 1 10) print a drawInt :: Int - Int - IO Int drawInt x y = getStdRandom (randomR (x,y)) m1 = do b - getStdRandom (randomR (1,10)) print b the second one produces *** Binding : m1 *** Outstanding context : (Num b, Random b) in Hugs. thanks horsh ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Outstanding context : (Num b, Random b)
horsh wrote: I am very new to haskell. Could anyone please explain why these two things are not equivalent: m2 = do a - (drawInt 1 10) print a drawInt :: Int - Int - IO Int drawInt x y = getStdRandom (randomR (x,y)) m1 = do b - getStdRandom (randomR (1,10)) print b the second one produces *** Binding : m1 *** Outstanding context : (Num b, Random b) In Haskell, numeric literals are overloaded. 1 could be an Int, Integer, Rational, Float etc. randomR can use any of Int, Integer, Float or Double, but it needs to know which. Adding an explicit type signature to one of the literals will eliminate the error, e.g.: m1 = do b - getStdRandom (randomR (1,10 :: Int)) print b -- Glynn Clements [EMAIL PROTECTED] ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Outstanding context : (Num b, Random b)
horsh [EMAIL PROTECTED] writes: Could anyone please explain why these two things are not equivalent: One of them has a type signature? -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
