Re: [GHC] #398: Xlib Types Not Instances of Anything
#398: Xlib Types Not Instances of Anything
+---
Reporter: jcast | Owner: ross
Type: bug| Status: closed
Priority: normal | Milestone:
Component: libraries (other) |Version: 6.4
Severity: normal | Resolution: fixed
Keywords: | Os: Unknown
Difficulty: Unknown| Architecture: Unknown
+---
Changes (by ross):
* architecture: = Unknown
* resolution: None = fixed
* difficulty: = Unknown
* status: new = closed
* os: = Unknown
Old description:
{{{
The types defined by newtype in Graphics.X11.Xlib.Types
are not instances of any type classes. Ptr, on the
other hand, which these types are synonyms for, is an
instance of Eq, Ord, Show, Typeable, Data, Storable,
and several other classes not relevant to the usage of
pointers in Graphics.X11.Xlib.
}}}
New description:
The types defined by newtype in Graphics.X11.Xlib.Types
are not instances of any type classes. Ptr, on the
other hand, which these types are synonyms for, is an
instance of Eq, Ord, Show, Typeable, Data, Storable,
and several other classes not relevant to the usage of
pointers in Graphics.X11.Xlib.
Comment:
The newtypes will be instances of Eq, Ord, Show, Typeable and Data in the
next major release.
Storable wouldn't be appropriate, as these types are abstract in this API.
--
Ticket URL: http://cvs.haskell.org/trac/ghc/ticket/398
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: cvs commit: fptools/libraries/base/Data IntMap.hs Map.hs Sequence.hs Set.hs fptools/libraries/base/Data/Generics Instances.hs Twins.hs
Simon Peyton Jones wrote: simonpj 2006/01/06 07:51:23 PST Modified files: libraries/base/Data IntMap.hs Map.hs Sequence.hs Set.hs libraries/base/Data/Generics Instances.hs Twins.hs Log: Eta-expand some higher-rank functions. GHC is about to move to *invariant* rather than *contra-variant* in function arguments, so far as type subsumption is concerned. These eta-expansions are simple, and allow type inference to go through with invariance. Why drop contra-variace? Jim ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] A collection of related proposals regarding monads
On 05/01/06, John Meacham [EMAIL PROTECTED] wrote: independent of anything else, giving up error messages on pattern match failures in do notation is not acceptable. so, if the split were to happen, having two methods in MonadZero, one which takes a string argument, would be needed. John Why does that have to be built into the class specification? Already, GHC can give line/column numbers for failed pattern matches in lambdas, it should be able to do the same for failed pattern matches in do-syntax in a similar way. I've never run into a case where I wanted the pattern match failure error message in the form of a String, wrapped in my monad datatype directly. If you were going to go that route, wouldn't a proper data type be preferred anyway, rather than a String? I can't actually do anything with that string other than to display it, since the report doesn't standardise its structure. Further, these cases seem sufficiently rare that if you're interested in catching information about where the pattern match failed, and using it in your program, you'd probably be better off actually handling failure directly, rather than relying on some system built into do-notation. Otherwise, what's wrong with just letting the thing throw an exception with a meaningful error message? The whole reason things switched to this from the way that they were in Haskell 98 is that apparently people found it confusing that refutable pattern matches in their do-blocks were causing these extra MonadZero typeclass constraints. That may be true, though I'm not sure it's really a language problem so much as a teaching problem. Further, pattern matches can switch from being irrefutable to refutable simply by modifing/extending a datatype, and some found it confusing that they now had a bunch of MonadZero errors cropping up after extending their type. Now, I think that this is a bit of a poor example. In reality, you probably want those error messages -- they serve as a major warning that your code is now probably incorrect, as it fails to deal with a potential case in your data type. Improve the error messages in the compiler if it's confusing. (People should be more aware that algebraic data types are not meant to be easily extensible. This is another good reason to want proper records, as they should take care of situations in which one expects data to be extended after the fact.) Does anyone have a real example of a nontrivial use of fail where the string argument was really important and which wouldn't be better served by MonadError, or by just throwing an exception? Usually when I define my monads, I try to ignore 'fail' as much as possible. In most cases, I just leave it completely undefined, as there's no sensible way to embed strings into my type, or even to fail properly at all. Personally, I'd be most happy with just going back to the Haskell 1.4 way of handling do-notation, and I see the reasons for adopting 'fail' in the first place as a bit specious. - Cale ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: ANN: HDBC (Haskell Database Connectivity)
My solution to this when developing a database library for my own use was to define the API in a bracket notation style, and only provide safe functions. The idea is that the function obtains the resource, calls a function passed as an argument, then frees the resource, so all resouces are guaranteed to be freed in the correct order... for example: dbConnectWith :: DbName - (DbHandle - IO Result) - Result dbConnectWith name workFn = do handle - dbConnectTo name workFn handle `finally` dbDisconnect handle In this way you avoid finalizers... and everthing is safe providing you only export the with style functions from the library... Here's an example from the library, the connect function: safeConnect :: (SqlIO m,SqlIfIO m,MonadIO m,MonadPlus m) = SqlDbc - OdbcConnection - (SqlDbc - m a) - m a safeConnect dbc connection doWith = ioBracket ( ioBracket (ioNewCStringLen (odbcDsn connection)) (\(dsnS,_) - ioFree dsnS) (\(dsnS,dsnL) - ioBracket (ioNewCStringLen (odbcUid connection)) (\(uidS,_) - ioFree uidS) (\(uidS,uidL) - ioBracket (ioNewCStringLen (odbcAuth connection)) (\(authS,_) - ioFree authS) (\(authS,authL) - do status - ioSqlConnect dbc dsnS (fromIntegral dsnL) uidS (fromIntegral uidL) authS (fromIntegral authL) ioIfFail status (\s - fail ((showString Bad status returned by sqlConnect ( . shows s) ))) (\_ - ioSqlDisconnect dbc) (\_ - doWith dbc) Keean Chris Kuklewicz wrote: Benjamin Franksen wrote: On Wednesday 04 January 2006 20:13, John Goerzen wrote: Well, yes and no. It would be impossible to garbage collect (and thus finalize) any object for which references to it still exist. Statement handles in HDBC maintain references to the database handle pointers, either directly or indirectly, so I can't see how it is possible for a database handle to be finalized before the statement handle in this situation. Hi John, I fear it /is/ possible. This is a very unfortunate situation and one I had quite some difficulties to understand, when Simon Marlow explained it to me. The problem is that finalization of the statement handle might be delayed indefinitely. The data dependencies between statement and connection handle only ensures that whenever the statement handle is alive, then too is the connection handle. But it does not say anything about what happens in which order after /both/ are dead (garbage). As soon as the connection handle to garbage, too, bothe handles can be finalized in /any/ order. As I pointed out before, this is a very bad thing, because it makes finalizers a whole lot less useful than they could be if an order between finalizations could be specified (directly or indirectly). The arguments against such a solution are mostly: (1) it is difficult to implement efficienty and (2) the programmer could accidentally cause finalizer deadlocks by specifying circular dependencies. Ben This is also mentioned in the documentation: http://www.haskell.org/ghc/docs/6.4.1/html/libraries/base/Foreign-ForeignPtr.html#v%3AtouchForeignPtr touchForeignPtr :: ForeignPtr a - IO () This function ensures that the foreign object in question is alive at the given place in the sequence of IO actions. In particular withForeignPtr does a touchForeignPtr after it executes the user action. Note that this function should not be used to express liveness dependencies between ForeignPtrs. For example, if the finalizer for a ForeignPtr F1 calls touchForeignPtr on a second ForeignPtr F2, then the only guarantee is that the finalizer for F2 is never started before the finalizer for F1. They might be started together if for example both F1 and F2 are otherwise unreachable, and in that case the scheduler might end up running the finalizer for F2 first. In general, it is not recommended to use finalizers on separate objects with ordering constraints between them. To express the ordering robustly requires explicit synchronisation using MVars between the finalizers, but even then the runtime sometimes runs multiple finalizers sequentially in a single thread (for performance reasons), so synchronisation between finalizers could result in artificial deadlock. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Parsing bug in GHC 6.4.1 ?
Hello, The following class definition: class Foo o where (:+) :: o - o - o and even the following function definition: bar f (x,y) = x :+ y are accepted by GHC. However, when I try to create one instance of Foo: instance Foo Int where x :+ y = x + y I get the following error message: Parsing.lhs:7:5: Pattern bindings (except simple variables) not allowed in instance declarations x :+ y = x + y The same error still occurs if I change the infix operator to be (:+:). However, if I define: class Foo3 o where (+) :: o - o - o instance Foo3 Int where x + y = x + y Everything works as expected. The only explanation that I have is that this is a (parsing) bug in GHC... This is probably related to the fact that (:+) :: Int - Int - Int f :+ g = f + g is an invalid definition (it complains that :+ is not a data constructor). I have not tried this code in other Haskell compiler (like Hugs) or even previous versions of GHC. I would be interested to know how do those behave. Cheers, Bruno ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Parsing bug in GHC 6.4.1 ?
On 08/01/06, Bruno Oliveira [EMAIL PROTECTED] wrote: Hello, The following class definition: class Foo o where (:+) :: o - o - o and even the following function definition: bar f (x,y) = x :+ y are accepted by GHC. However, when I try to create one instance of Foo: instance Foo Int where x :+ y = x + y I get the following error message: Parsing.lhs:7:5: Pattern bindings (except simple variables) not allowed in instance declarations x :+ y = x + y The same error still occurs if I change the infix operator to be (:+:). However, if I define: class Foo3 o where (+) :: o - o - o instance Foo3 Int where x + y = x + y Everything works as expected. The only explanation that I have is that this is a (parsing) bug in GHC... This is probably related to the fact that (:+) :: Int - Int - Int f :+ g = f + g is an invalid definition (it complains that :+ is not a data constructor). I have not tried this code in other Haskell compiler (like Hugs) or even previous versions of GHC. I would be interested to know how do those behave. Cheers, Bruno Infix operators which start with a colon are reserved for use as data constructors. Names starting with an uppercase letter are reserved in the same way. You can define a type: data Complex a = a :+ a and write values of type Complex Double like (1.0 :+ pi), but you can't use :+ as the name of an ordinary function. I'm not sure if it's ideal that the class declaration is allowing that type signature to occur, but afaict, the syntax does permit it. - Cale ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Parsing bug in GHC 6.4.1 ?
Bruno Oliveira writes: class Foo o where (:+) :: o - o - o The Haskell report specifies in section 2.4 Identifiers and Operators: An operator symbol starting with a colon is a constructor. Think of ':' as a character that is interpreted as uppercase; you can't use it to start a function or variable name. Peter ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Parsing bug in GHC 6.4.1 ?
On 08/01/06, Bruno Oliveira [EMAIL PROTECTED] wrote:
On 08 Jan 2006 16:37:47 +0100, Peter Simons wrote:
Bruno Oliveira writes:
class Foo o where
(:+) :: o - o - o
The Haskell report specifies in section 2.4 Identifiers and
Operators:
An operator symbol starting with a colon is a constructor.
Think of ':' as a character that is interpreted as uppercase;
you can't use it to start a function or variable name.
Then this declaration should be rejected as invalid, right?
That's why I think this is a parsing bug...
Cheers,
Bruno
Hmm... yeah, it does seem like a parsing bug. The relevant rules from
the report are:
topdecl - ...
| class [scontext =] tycls tyvar [where cdecls]
...
cdecls - { cdecl1 ; ... ; cdecln } (n=0)
cdecl - gendecl
| ...
gendecl - vars :: [context =] type (type signature)
| ...
vars - var1 , ..., varn(n=1)
var - varid | ( varsym )
varsym - ( symbol {symbol | :})reservedop | dashes
So it should not be permitting a type declaration for something
starting with a colon, since symbol does not match colon.
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] New look for haskell.org: MediaWiki
As everyone has noticed during the making Haskell more open discussion, MediaWiki was suggested as a better wiki technology for haskell.org. Ashley Yakeley has generously installed MediaWiki and we would like to migrate the main pages of haskell.org into this wiki. The migration is not complete - only the front page is finished - but I'd like to make this public now so that there's time for comments. In the end, this will allow anyone to come in and fix up the main haskell.org pages - the people, the projects, the help for beginners, whatever you want. Olaf and I will then step back and let the community work directly on the entire site without having to bother us (a big advantage!). This will also impact the old Haskell wiki. Rather than try to automatically convert the old wiki to the new one, we're going to ask the community to come in and do this for us. In particular, the new wiki is under the GNU FDL so the licenses are not necessarily compatible. We will keep the two wikis going side by side for a while but in the long term I hope all content migrates to MediaWiki (we won't be deprecating the Trac stuff - this will stay as is). I believe that MediaWiki is more professional looking and has a nice separation of documentation and discussion that MoinMoin lacks. I hope that this will result in better wiki content and a more organized site. Moving content by hand will give us all a chance to spruce up the existing content as it moves (and get rid of all the ugly CamelCase page names!). I expect that it will take another week or so for the rest of the haskell.org pages to move into the new wiki - at that point we'll flip the switch and take down the old pages (but not the old wiki yet) and change the main page to point into the MediaWiki. Content that isn't being maintained by Olaf and I will stay as before although I hope that more and more pages will move into the wiki and we won't have to give out accounts to people on haskell.org just to host projects. The new wiki isn't yet visible from the front page but you can find it at http://haskell.org/haskellwiki/Haskell For you style sheet gurus, the style sheet itself is also in the wiki at http://haskell.org/haskellwiki/MediaWiki:Quiet.css If anyone wants to help move the main pages over, drop me an email and I'll coordinate things. Feel free to start adding stuff to the new wiki. It won't be visible to the outside world immediately but you can get it ready for the switch over. This isn't a completely done deal - there is still time to object to the whole thing or make suggestions. Nothing will be visible to the outside world until we make the switch later. But I believe this will result in a much better site and also make life a lot easier for Olaf and I. (And I apologize to everyone that's asked for updates to haskell.org recently - I've been avoiding them to concentrate on this!). I'm sure some of the MediaWiki settings still need to be tweaked. Send me mail if something in the configuration of MediaWiki needs to be changed. A big thanks again to Ashley! John ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] New look for haskell.org: MediaWiki
wiki is under the GNU FDL so the licenses are not necessarily compatible. As far as I understand, this means that if I see a sample of code on the haskell wiki, and just want to steal it for my project, I'm not allowed to, unless I also release my code under the GNU FDL? And another point, will this wiki be backed up? I am lead to believe that the existing hawiki isn't, so I keep backups of sections I'm involved with. Thanks Neil ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] New look for haskell.org: MediaWiki
wiki is under the GNU FDL so the licenses are not necessarily compatible. As far as I understand, this means that if I see a sample of code on the haskell wiki, and just want to steal it for my project, I'm not allowed to, unless I also release my code under the GNU FDL? This is something worth debating. Certainly you can ask the author of the code for permission to use it but this is an extra burden. Would be nice to have a special wiki construct to mark content as posessing an extra license. The whole license debate should take place as soon as possible before we get a lot of content in there. I'm not wedded to the FDL. And another point, will this wiki be backed up? I am lead to believe that the existing hawiki isn't, so I keep backups of sections I'm involved with. We back up all of haskell.org except some of the old ghc releases. That shouldn't be a problem. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] New look for haskell.org: MediaWiki
This is something worth debating. Certainly you can ask the author of the code for permission to use it but this is an extra burden. Would be nice to have a special wiki construct to mark content as posessing an extra license. The whole license debate should take place as soon as possible before we get a lot of content in there. I'm not wedded to the FDL. Is there any reason for not putting the content under a do whatever you want with it license (i.e. Public Domain or BSD), and then (if necessary) allowing people to mark certain contributions with additional restrictions? Especially given GHC is released under the BSD. I can't imagine anything anyone would be able to do with the content, which would be bad and would be stopped by something like the FDL. Thanks Neil ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] License for haskell.org content
I believe the scenario that the FDL addresses is that someone (probably Paul Hudak!) borrows massive amounts of stuff from the wiki, adds his own good stuff, and then publishes a nice book or something without having to share his additional contribution. Some people would like to be sure that their contributions can't be exploited in this manner. I'm no license lawyer - the BSD license would work just fine for me personally but we need to generate some overall agreement on this issue since everyone who contributes is potentially affected. John ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] New look for haskell.org: MediaWiki
sön 2006-01-08 klockan 21:12 -0500 skrev John Peterson: wiki is under the GNU FDL so the licenses are not necessarily compatible. As far as I understand, this means that if I see a sample of code on the haskell wiki, and just want to steal it for my project, I'm not allowed to, unless I also release my code under the GNU FDL? This is something worth debating. Certainly you can ask the author of the code for permission to use it but this is an extra burden. Would be nice to have a special wiki construct to mark content as posessing an extra license. The whole license debate should take place as soon as possible before we get a lot of content in there. I'm not wedded to the FDL. Hmm, here's a quick suggestion. The wiki currently says: Content is available under GNU Free Documentation License 1.2. We change this to: All Haskell source code on this page is released into the public domain. All other content is available under GNU Free Documentation License 1.2. Haskell source code could also be a link to an exact definition of what is and what is not to be regarded as Haskell source code, but I think that seems a bit over the top. It might even be reasonable to release everything into the public domain. If nothing else, it means we can change the license later if it ends up being abused (which I personally believe is a rather low risk scenario). Regards, Anders signature.asc Description: Detta är en digitalt signerad meddelandedel ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: License for haskell.org content
In article [EMAIL PROTECTED], Ian Lynagh [EMAIL PROTECTED] wrote: Why not use the GPL, then? FWIW, the GFDL is considered non-free by Debian[1], so that would mean any documentation or anything derived from the wiki couldn't be packaged for Debian. Apart from the issue of code itself on the wiki, that other people have already mentioned, presumably you'd also have licence fun if you try to take surrounding explanatory text to use as haddock docs etc. Let's discuss it on the wiki: http://haskell.org/haskellwiki/HaskellWiki:Community_Portal -- Ashley Yakeley, Seattle WA ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
RE: [Haskell-cafe] x86 code generation going wrong?
From: Chris Kuklewicz [EMAIL PROTECTED]
To: haskell-cafe@haskell.org
Subject: [Haskell-cafe] x86 code generation going wrong?
Date: Sat, 07 Jan 2006 16:18:59 +
Hello,
I need to ask for some help to test x86 code generation.
There is a factor of two runtime difference between the code I am
benchmarking on my OS X powerbook G4 (ghc 6.4.1) and shootout's speed on
a linux x86 machine (ghc 6.4.1).
Could someone else running on x86 test the three versions pasted below
before I think about submitting another one to the shootout?
Here are the tests on P4 2.4 ghz and athlon 64 3000 linux test1-3 in
respective order
of appearance (note:OPTIONS didn't do anything I have to
compile -O2 -fglasgow-exts explicitely, because I've got compile error for
test3.hs )
[EMAIL PROTECTED] ~/haskell/myhaskell] $ time ./test1 sum-file-test-input
400
real0m3.550s
user0m3.440s
sys 0m0.080s
[EMAIL PROTECTED] ~/haskell/myhaskell] $ time ./test2 sum-file-test-input
400
real0m3.708s
user0m3.660s
sys 0m0.060s
[EMAIL PROTECTED] ~/haskell/myhaskell] $ time ./test3 sum-file-test-input
400
real0m3.678s
user0m3.620s
sys 0m0.050s
This is on athlon64 3000 , linux :
[EMAIL PROTECTED] ~]$ time ./test1 sum-file-test-input
400
real0m5.782s
user0m5.724s
sys 0m0.056s
[EMAIL PROTECTED] ~]$ time ./test2 sum-file-test-input
400
real0m5.953s
user0m5.900s
sys 0m0.052s
[EMAIL PROTECTED] ~]$ time ./test3 sum-file-test-input
400
real0m5.403s
user0m5.332s
sys 0m0.072s
Greetings, Bane.
To compile ghc --make filename.hs -o program
To run cat input-file | time ./program
where to save space, the gzip'd input file is at
http://paradosso.mit.edu/~ckuklewicz/sum-file-test-input.gz
-
-- Original version
{-# OPTIONS -O2 #-}
import Char( ord )
main :: IO ()
main = getContents = print . accP 0 0
accP :: Int - Int - String - Int
accP before this [] = before+this
accP before this ('\n':xs) = accP (before+this) 0xs
accP before this ('-' :xs) = accN before this xs
accP before this (x :xs) = accP before (this*10+ord(x)-ord('0')) xs
accN :: Int - Int - String - Int
accN before this [] = before-this
accN before this ('\n':xs) = accP (before-this) 0xs
accN before this (x :xs) = accN before (this*10+ord(x)-ord('0')) xs
-
-- Faster on G4, 2x slower on x86
{-# OPTIONS -O2 -funbox-strict-fields #-}
import GHC.Base
data I = I !Int
main = print . new (I 0) = getContents
new (I i) [] = i
new (I i) ('-':xs) = neg (I 0) xs
where neg (I n) ('\n':xs) = new (I (i - n)) xs
neg (I n) (x :xs) = neg (I (parse x + (10 * n))) xs
new (I i) (x:xs) = pos (I (parse x)) xs
where pos (I n) ('\n':xs) = new (I (i + n)) xs
pos (I n) (x :xs) = pos (I (parse x + (10 * n))) xs
parse c = ord c - ord '0'
-
-- Explicitly unboxed proposal, faster on G4
{-# OPTIONS -fglasgow-exts -O2 #-}
import GHC.Base
main = print . sumFile = getContents
where sumFile = (\rest - newLine rest 0#)
newLine [] rt = (I# rt)
newLine ('-':rest) rt = negLine rest 0#
where negLine ('\n':rest) soFar = newLine rest (rt -# soFar)
negLine ( x :rest) soFar = negLine rest (d2i x +# (10# *#
soFar))
newLine (x:rest) rt = posLine rest (d2i x)
where posLine ('\n':rest) soFar = newLine rest (rt +# soFar)
posLine ( x :rest) soFar = posLine rest (d2i x +# (10# *#
soFar))
d2i (C# c) = (ord# c) -# z
where z = ord# '0'#
-
Thanks,
Chris
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
_
FREE pop-up blocking with the new MSN Toolbar - get it now!
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do {x-[1,2,3]; True - return (odd x); return x}.. why? (do notation, monads, guards)
Hello Marc,
Sunday, January 08, 2006, 3:19:56 AM, you wrote:
MW list2=do { x - [1,2,3]; guard (odd x); return x} -- - provided by xerox
list3 = [ x | x - [1,2,3], odd x]
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] fastest Binary library!
Hello Donald, Sunday, January 08, 2006, 3:43:51 AM, you wrote: and got the (de)serialization speed about 50 mb/s with my 1 ghz cpu. DBS Excellent! How does this compare to NewBinary? ghc's Binary performs 4-6 mb/s in the same situations. if you are asking about features - see readme.txt, it is yet unfinished library docs -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] I/O and utf8
hello i want to read a file encoded in utf8 and at a later time output portions of it on the console. Is there an easy way to do this in haskell? using the standard i/o functions i can read the file but the output gives me \1071 ... instead of the unicode characters. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Is there a notion for identity?
{- Disclaimer: I'm rather new to Haskell and completely new to this board.
I may not use the correct terminology in all cases, but I hope my
intention becomes clear when you have a look at the code-snippets. -}
Hey ho,
Is there any way two find out whether two variables refer to the
same cell? That is I'm looking for a notion of identity (compareable
to == in Java) as opposed to equality (== in Haskell).
The motivation is that I need to find out whether two infinite
structures are identical.
Consider this Haskell implementation of the simple typed lambda calculus
(STLC) with the primitive Type TyUnit and the primitive value TmUnit:
data Type = TyUnit | TyArrow Type Type
deriving (Show,Eq)
data Term = TmUnit | TmVar String | TmAbs String Type Term | TmApp Term Term
deriving Show
{- Context is some LIFO structure which stores Argument-Type bindings: -}
data Context = {- ... -}
ctxEmpty:: Context
addBinding :: Context - String - Type - Context
getBinding :: Context - String - Type
typeof :: Context - Term - Type
typeof _ TmUnit = TyUnit
typeof ctx (TmVar s) = getBinding ctx s
typeof ctx (TmAbs s ty1 t) = let ctx' = addBinding ctx s ty1
ty2 = typeof ctx' t
in TyArrow ty1 ty2
typeof ctx (TmApp t1 t2) = let (TyArrow ttp tte) = typeof ctx t1
tta = typeof ctx t2
{- (1) problem here: -} in if tta==ttp then tte
else error ...
-- eval omitted...
The STLC does not provide a notion for recursion as it stands. My
idea was to simulate recursion by using infinte structures
of type Type.
Consider this definition of the omega-combinator:
omegaType :: Type
omegaType = TyArrow omegaType omegaType
omega, omegaAbs :: Term
omega = TmApp omegaAbs omegaAbs
omegaAbs = TmAbs x omegaType (TmApp (TmVar x) (TmVar x))
Now it would be nice if typeof ctxEmpty omega would return
omegaType. Unfortunately it doesn't. Instead it loops on line
((1)), since omegaType and omegaType will never be compared to
be equal using (==).
If we had a function `sameAddress` we could write
tta `sameAddress` ttp || tta==ttp instead of tta==ttp
in line ((1)). If I interpret the chapter about infinite
lists in the bird book correctly, this should be sound.
omegaType will be represented by a cyclic graph in
the runtime system and will therefore always refer to
the same cell.
The issue becomes a little more complicated if we
consider:
omegaType, omegaType' :: Type
omegaType = TyArrow omegaType omegaType
omegaType' = TyArrow omegaType' omegaType'
omega, omegaAbs, omegaAbs' :: Term
omega = TmApp omegaAbs omegaAbs'
omegaAbs = TmAbs x omegaType (TmApp (TmVar x) (TmVar x))
omegaAbs' = TmAbs x omegaType' (TmApp (TmVar x) (TmVar x))
In this case it wouldn't be clear whether
omegaType `sameAddress` omegaType' should be True
or False, as a clever compiler might detect that
both are identical and make them refer to the same
address (, correct me if I'm wrong). This might
be a reason that there is no `sameAddress`.
My questions are: Is there any way to implement
sameAddress in Haskell? Or is it at least
possible to implement it with GHC using some
compiler-specific notation?
Thanks,
Tim
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do {x-[1,2,3]; True - return (odd x); return x}.. why? (do notation, monads, guards)
On Sun, Jan 08, 2006 at 12:19:40PM +0300, Bulat Ziganshin wrote:
Hello Marc,
Sunday, January 08, 2006, 3:19:56 AM, you wrote:
MW list2=do { x - [1,2,3]; guard (odd x); return x} -- - provided by xerox
list3 = [ x | x - [1,2,3], odd x]
list4= take 2 $ [2*x+1,x-[0..]] ;-)
Hi Bulat..
Thanks for your reply.
Of cause I know this version, too.
My goal has been to understand why the other versions list1,2rewritten
give the same result.. (especially which monadic implementation of =
is used in each case..)
I'm trying to understand this simple example because I want to
understand some other monad examples beeing more complicated..
See my comments of the last post for details..
If something is unclear.. Please tell me..
Some hints like: look at the defintion of Monad xy should be
sufficiant..
Sincerly Marc
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is there a notion for identity?
On Sun, Jan 08, 2006 at 12:43:31PM +0100, Tim Walkenhorst wrote:
{- Disclaimer: I'm rather new to Haskell and completely new to this board.
I may not use the correct terminology in all cases, but I hope my
intention becomes clear when you have a look at the code-snippets. -}
Hey ho,
Is there any way two find out whether two variables refer to the
same cell? That is I'm looking for a notion of identity (compareable
to == in Java) as opposed to equality (== in Haskell).
If you haven't seen this thread already:
Detecting Cycles in Datastructures covering exactly your topic, I
think..
You can use google groups to find it. It's from okt.
Marc
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Avoiding name collisions by using value spaces instead of modules
Hi -
A main problem I've found with Haskell is that within a module, too many
things are put into the same scope. For example
data Tree a b = Leaf a | Node {elem::b, lhs::Tree a b, rhs::Tree a b}
puts Leaf, Node, elem, lhs, and rhs, into the module's namespace,
as well as Tree. This means that if you want another kind of tree in
the same module you've got to try and think of another word for Leaf,
or else prefix every value constructor with some prefix of the tycon to
try and prevent name collisions.
I propose that the above declaration should introduce a *new module* Tree,
as a sub module of the containing module, and Leaf, Node, elem etc will be
put into this module, and not the module containing the data declaration
itself.
Identifiers in this child module could then either be used qualified or
unqualified as long as they don't conflict with anything in the parent
(containing) module, thus in the parent module, we could have:
a = Tree.Leaf 3
b = Node{elem = 6, lhs = Leaf 2, rhs = Leaf 3}
c = Tree.elem b
c = b^elem
where ^ is just a helpful sugar which binds tighter than function
application and can be used anywhere to allow an object oriented way of
thinking where the first arg is put on the left of the function (more on
this later).
Also, we could generalise the GHC GADT style data declarations by allowing
any declarations to appear in the where part, and allow modules to consist
of a single data declaration (ie begin with the keyword data instead of
module) so that the contents of the Data.Set module would instead be
something like:
data Ord a = Set a = where
insert :: Set a - a - Set a
...
This would allow Set to be imported qualified into other modules where we
could refer to the Set type by the single word Set instead of Set.Set (which
I always think looks very strange indeed) ie
module M where
import qualified Data.Set as Set
f :: a - Set a-- no longer need to write a - Set.Set a
In fact, the whole complexity asociated with hiding components of a module
and allowing unqualified imports could be discarded, since the correct
resolution for each identifier would be determined by its typed context,
just as in OOP the resolution is determined by the type of the object.
So to summarise so far, for any value f :: T0 - T1 - ... - Tn, we
construct the tuple (Q0, Q1, ... Qn) where for each i, Qi is obtained from
Ti by ignoring all predicates and quantification and replacing each tyvar by
the symbol '?'.
For example, for
module M where
foo :: forall b. Eq a = Set (Tree a) - Tree ([a],b) - [Tree (a,b)]
we ignore the forall and Eq, and replace tyvars and tuple the results to
get:
M.(Set (Tree ?), Tree ( (,) ( [] ?) ?), [] (Tree ( (,) ? ?))).foo
as the fully qualified reference to the entity we've just declared.
If we call the tuple (Set, ...) the ty-tuple, which specifies a space of
values (ie something that each value is considered to belong to - the
analogue of the object in OOP), then we can define a projection from a space
into a containing space as follows:
1) Let Qi == Ui Si0 Si1 ... Sik be any element of a ty-tuple P. Then we can
form a new ty-tuple P' by replacing Qi by Ui.
2) Let Qi be any element of a ty-tuple P of arity n+1. Then we can form
P' == (Q0, ..., Qi-1, Qi+1, ... Qn) of arity n
In both cases, we can use P' to qualify the identifier to get a value
reference as long as this still has enough information for disambiguating
other uses of the identifier in M.
Applying these transformations of the ty-tuple to the example above,
any of the following could be used as a partial qualification of foo in M:
(Set Tree, Tree ([],?), [Tree]).foo
(Set, Tree, []).foo
Tree.foo
foo
Rule 2 allows us to propagate identifiers back up to their ancestor modules
as long as there are no conflicts along the way.
The type inference algorithm could then be modified (I hope) to use the
top-level annotation for a value declaration to determine the entities that
identifiers refer to, by searching in the appropriate value spaces
determined by the types of the args and return value.
label :: Tree a - Int - (Tree a, Int)
label (Leaf x) i = (Leaf i, i+1)
The identifier Leaf is resolved in the current namespace augmented by the
namespace for module Tree, thus we don't have to explicitly write Tree.Leaf
even though the declaration of label occurs outside the Tree module itself.
(I suggest that top-level type annotations should be mandatory since without
them one just drowns in a sea of TI confusion when there is a type error. By
making them mandatory the TI algorithm could make real use of them to
resolve identifier bindings as in OOP)
Similarly:
foo :: a - Set a
foo x = singleton x
There is no need to say Set.singleton x, because we know that the result of
foo has type Set a therefore we search in the current module augmented by
the contents of
Re: [Haskell-cafe] do {x-[1,2,3]; True - return (odd x); return x}.. why? (do notation, monads, guards)
Am Sonntag, 8. Januar 2006 01:19 schrieb Marc Weber:
Here is a simple program implementing the above function in 4 different
ways.. See my comments to get to know where I have problems:
-- begin test.hs --
module Main where
import IO
import Control.Monad.List
{- list1,2 are both implementations of the same function f=[1,3] ;-)
I've both rewritten with the translation rules for do notation to
better understand what's going on and where the differences are
-}
list1=do { x - [1,2,3]; True - return (odd x); return x}
list2=do { x - [1,2,3]; guard (odd x); return x} -- - provided by xerox
list1rewritten :: [Int]
list1rewritten=let ok x = let ok2 True = do return x --1r1
ok2 _ = fail ok2 --1r2
in return (odd x) = ok2 --1r3
ok _ = fail outer--1r4
in [1,2,3] = ok
{- The outer let .. in = is used to call the inner =
for each element of [1,2,3] (the list Monad causes this)
True - return (odd x): really nice trick...!
if x is odd then line --1r1 is matched the values is returned
otherwiseline --1r2 is matched calling fail
which is implemented as
= [] ignoring the message hence no
element is added but I'm not sure which implementation of = is used in
--lr3:
It should satisfy (Monad m) = m Bool - (Bool - m Int), right ?
Let's figure that out (I use Int, although Integral a = a is the most general
type).
Overall, we have 'ok :: Int - [b]', from the expression '[1,2,3] = ok'.
Now in line 1r3 we see that ok x (since that pattern is irrefutable, there's
no need for line 1r4) is 'return (odd x) = ok2', so by that line alone we
can infer the type 'Monad m = Bool - m c' for ok2. But the result of ok2 is
the result of ok, so we find '[b] === m c', hence in line 1r3, = is used at
type [Bool] - (Bool - [b]) - [b]. Finally, by 1r1 we see that 'b' is the
input-type of ok, i.e. Int, so our type-inference has led to
list1annotated
= let ok :: Int - [Int]
ok x = let ok2 :: Bool - [Int]
ok2 True = return x -- might as well write [x]
ok2 _ = fail ok2
in ((=) :: [Bool] - (Bool - [Int]) - [Int]) (return (odd
x) :: [Bool]) ok2
in ((=) :: [Int] - (Int - [Int]) - [Int]) [1,2,3] ok
Looking at the definition taken from GHC/Base.lhs:
class Monad m where
(=) :: forall a b. m a - (a - m b) - m b
and a sample implementation:
instance Monad [] where
m = k = foldr ((++) . k) [] m
I wonder how a, b (from m a and m b) and m (from class Monad m) are
renated? Can you tell me how the implementation declaration of m a - (...)
- m b differs in these cases: eg: 1. a = Int, b=String 2. the other way
round: a=String b=Int? -}
The difference is not really in the types a, b, but in the monad m.
For [] we have
list = func = concatMap func list,
for Maybe it's
Just x = func = func x
Nothing = func = Nothing
and look at the code for more, I can recommend -- besides the
Control.Monad.Whichevers -- ReadP and Parsec. If you've spent some time
grasping that, you'll become more comfortable with monads.
list2rewritten :: [Int]
list2rewritten = let ok x = guard (odd x) return x
ok _ = fail I think never used?
in [1,2,3] = ok
{- Here ok is feeded with 1,2 and three due to the list Monad again?
So fail will never be called, right?
Exactly.
I also know that guard returns either the monad data type constructor
mzero or return () But how is this used in combintation with return
x::Int to return either [] or [x] ? -}
mzero is not a constructor (as witnessed by the lowercase spelling), but a
special value that 'm a' must contain for a MonadPlus m (and arbitrary a).
One of the laws requested for instances of MonadPlus is
'mzero = f === mzero'. For lists, this is fulfilled, since
concat (map f []) = concat [] = [].
If we evaluate the above ok, we have
ok 1 = guard (odd 1) return 1
= guard True = (\_ - return 1)
= return () = (\_ - return 1)
= [()] = (\_ - return 1)
= concat $ map (\_ - return 1) [()]
= concat $ [return 1]
= concat [[1]]
= [1]
ok 2 = guard (odd 2) return 2
= guard False return 2
= mzero = (\_ - return 2)
= concat $ map (\_ - return 2) []
= concat []
= []
main=do
-- print result of all implementations to show that they are equal
sequence [ print x| x - [[1,3], -- [1,3] should be the result
list1,
list1rewritten,
list2,
list2rewritten ] ]
-- end -
I hope there will be some time when I can say: Monads.. I don't bother
anymore I'm practicing every night while dreaming
Re: [Haskell-cafe] Expanding do notation
Am Samstag, 7. Januar 2006 23:56 schrieben Sie: Daniel, i also included you in crossposting because these letters can also help you understand how run-time compilation works. basically it's a very simple thing: when we can compute at compile time value of some computation, many compilers will do it and substitute expression with its final value. Yes, I thought they did. It's a good and clever thing, but calling that RunTimeCompilation would be a misnomer, wouldn't it? That's rather CompileTimeEvaluation, isn't it? the same can be done at the run-time - as soon as we can compute value of some expression used in program or at least simplify it using our knowing of part of arguments, this can be used to reduce number of computations which program need to perform. say, n - readIO print (factorial n) print (factorial n) here, factorial n can be computed just one time. it's obvious. in this case n - readIO flip mapM [1..100] $ \x - print (x^n) it's not so obvious that when program read value of `n`, it can substitute instead of `x^n` the concrete, faster algorithm, say 'x*x' for n=2. Haskell's ideology of graph reductions makes such run-time optimizations automatically. it it the thing that called run-time compilation on those wiki page. Cool. So let's see if I got it. If I have n - readIO ... mapM_ (func n) list ... in my programme, the runtime system will/might build object code for func n that is then used instead of using the general code for func and supplying both arguments to that? That'd be wow, triple wow! And run-time compilation is a fitting name for that. in KMP algorithm we compile string searched to algorithm that will do the search of this concrete string. another examples from my own practice is compilation of strings representing regular expressions to functions which tests compliance with these regexprs, and compiling list of sorting criterions to compare function (you can find last example at the end of RunTimeCompilation hawiki page) Thanks. Unless I'm grossly mistaken, that made things much clearer. Would somebody add an explanation along these lines to the HaWiki-page (I'm pretty sure, I'm not the only one who didn't understand the wiki-page)? Cheers, Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Expanding do notation
Daniel Fischer wrote: Cool. So let's see if I got it. If I have n - readIO ... mapM_ (func n) list ... in my programme, the runtime system will/might build object code for func n that is then used instead of using the general code for func and supplying both arguments to that? That'd be wow, triple wow! And run-time compilation is a fitting name for that. Well, it's possible to do that. But I don't know of any Haskell implementation that does. Sure, you might get a little bit of that if func is defined suitably, like func 0 = foo func 1 = bar func n = baz Implementations that have the full laziness property will handle one argument at a time to a function, and may do some work with just one argument to func. But it's nothing like having real run-time code generation. -- Lennart ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Avoiding name collisions by using value spaces instead of modules
Am Sonntag, 8. Januar 2006 14:06 schrieb Brian Hulley:
Hi -
A main problem I've found with Haskell is that within a module, too many
things are put into the same scope. For example
data Tree a b = Leaf a | Node {elem::b, lhs::Tree a b, rhs::Tree a b}
puts Leaf, Node, elem, lhs, and rhs, into the module's namespace,
as well as Tree. This means that if you want another kind of tree in
the same module you've got to try and think of another word for Leaf,
or else prefix every value constructor with some prefix of the tycon to
try and prevent name collisions.
I propose that the above declaration should introduce a *new module* Tree,
as a sub module of the containing module, and Leaf, Node, elem etc will be
put into this module, and not the module containing the data declaration
itself.
What speaks against putting the data declaration in a separate module:
module ThisKindOfTrees where
data Tree a b = ...
and then use qualified imports (with a short alias), if you want to use
different kinds of trees in one module?
Yes, more files, but, IMHO, much more readable.
Identifiers in this child module could then either be used qualified or
unqualified as long as they don't conflict with anything in the parent
(containing) module, thus in the parent module, we could have:
a = Tree.Leaf 3
b = Node{elem = 6, lhs = Leaf 2, rhs = Leaf 3}
c = Tree.elem b
You get that by unqualified import.
c = b^elem
where ^ is just a helpful sugar which binds tighter than function
application and can be used anywhere to allow an object oriented way of
thinking where the first arg is put on the left of the function (more on
this later).
'^' is definitely a bad choice, 'cause it's exponentiation (and has a long and
venerable history as symbol therefore).
Also, we could generalise the GHC GADT style data declarations by allowing
any declarations to appear in the where part, and allow modules to consist
of a single data declaration (ie begin with the keyword data instead of
module) so that the contents of the Data.Set module would instead be
something like:
data Ord a = Set a = where
insert :: Set a - a - Set a
...
This would allow Set to be imported qualified into other modules where we
could refer to the Set type by the single word Set instead of Set.Set
(which I always think looks very strange indeed) ie
module M where
import qualified Data.Set as Set
f :: a - Set a-- no longer need to write a - Set.Set
a
import qualified Data.Set as Set
import Data.Set (Set)
does the trick and I prefer it over your suggestions below.
In fact, the whole complexity asociated with hiding components of a module
and allowing unqualified imports could be discarded, since the correct
resolution for each identifier would be determined by its typed context,
just as in OOP the resolution is determined by the type of the object.
So to summarise so far, for any value f :: T0 - T1 - ... - Tn, we
construct the tuple (Q0, Q1, ... Qn) where for each i, Qi is obtained from
Ti by ignoring all predicates and quantification and replacing each tyvar
by the symbol '?'.
For example, for
module M where
foo :: forall b. Eq a = Set (Tree a) - Tree ([a],b) - [Tree (a,b)]
we ignore the forall and Eq, and replace tyvars and tuple the results to
get:
M.(Set (Tree ?), Tree ( (,) ( [] ?) ?), [] (Tree ( (,) ? ?))).foo
as the fully qualified reference to the entity we've just declared.
Looks absolutely horrible to me. What would we gain?
We could have
M.(Set (Tree ?), Tree ( (,) ( [] ?) ?), [] (Tree ( (,) ? ?))).foo
and
M.(Int, Set (Tree ?), Tree ( (,) ( [] ?) ?), [] (Tree ( (,) ? ?))).foo
but why? Do we really want it? I certainly don't.
If we call the tuple (Set, ...) the ty-tuple, which specifies a space of
values (ie something that each value is considered to belong to - the
analogue of the object in OOP), then we can define a projection from a
space into a containing space as follows:
1) Let Qi == Ui Si0 Si1 ... Sik be any element of a ty-tuple P. Then we can
form a new ty-tuple P' by replacing Qi by Ui.
2) Let Qi be any element of a ty-tuple P of arity n+1. Then we can form
P' == (Q0, ..., Qi-1, Qi+1, ... Qn) of arity n
In both cases, we can use P' to qualify the identifier to get a value
reference as long as this still has enough information for disambiguating
other uses of the identifier in M.
Applying these transformations of the ty-tuple to the example above,
any of the following could be used as a partial qualification of foo in M:
(Set Tree, Tree ([],?), [Tree]).foo
(Set, Tree, []).foo
Tree.foo
foo
Rule 2 allows us to propagate identifiers back up to their ancestor modules
as long as there are no conflicts along the way.
The type inference algorithm could then be modified (I hope) to use the
top-level annotation for a value declaration to determine the entities that
Re[7]: [Haskell-cafe] Project postmortem II /Haskell vs. Erlang/
Hello Joel, Thursday, January 05, 2006, 2:01:43 PM, you wrote: JR Could you give us a bit more detail on this? forget about this :) i forget that direct i/o on sockets will block entire app. GHC organizez its own complex non-blocking machinery JR How does using handles involve large memory/CPU pressure? just look at GHC.Handle, .IO, .IOBase modules JR On Jan 5, 2006, at 10:01 AM, Bulat Ziganshin wrote: i also recommend you to try FD from my Binary package instead of Handles because using 1000 Handles may involve a large memory/cpu pressure JR -- JR http://wagerlabs.com/ -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] x86 code generation going wrong?
Hello Branimir,
Sunday, January 08, 2006, 1:57:06 PM, you wrote:
BM of appearance (note:OPTIONS didn't do anything I have to
BM compile -O2 -fglasgow-exts explicitely, because I've got compile error for
BM test3.hs )
use
{-# OPTIONS_GHC -O2 -fglasgow-exts #-}
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Expanding do notation
Hello Lennart,
Sunday, January 08, 2006, 5:45:16 PM, you wrote:
Cool. So let's see if I got it.
If I have
n - readIO
...
mapM_ (func n) list
...
in my programme, the runtime system will/might build object code for
not object code itslef. haskell program in compiled form is a large
tree which nodes contain object code. run-time compilation can
substitute instead of node which computes func n the node which will
compute concrete func 2 value. it is the partial case of
calculation of lazy program by substitution evaluation results
instead of function calls. the key may be just what haskell functions
are curreied, so you can see fucntion f a b as function with two
arguments returning Int, or as function with one argument returning
Int-Int. for example
regexpr - getStrLn
filtered - filterM (match regexpr) lines
with definition
match *= const True
match regexp = \str - ...
when your input is * it will compute {match *} as const True and
pass this argument to the filterM call (to be exact, it will pass
unevaluated thunk {match *}, which will be evaluated to const True
on first use)
func n that is then used instead of using the general code for func and
supplying both arguments to that?
yes. i don't know how to guarantee it. i just define my
time-critical functions as having one arguments. you can see an
example on those hawiki page, another example is my regexpr code:
data RegExpr = RE_End
| RE_Anything
| RE_FromEnd RegExpr
| RE_AnyChar RegExpr
| RE_CharChar RegExpr
| RE_FullRE Regex
is_wildcard s = s `contains_one_of` ?*[
translate_RE re = ^++ (replaceAll * .*
.replaceAll ? .
.replaceAll $ \\$
.replaceAll [[[ [^
.replaceAll ^ \\^
.replaceAll [^ [[[
.replaceAll + \\+
.replaceAll . \\.) re ++$
compile_RE s = case s of
- RE_End
*- RE_Anything
'*':cs - if ('*' `elem` cs) || ('[' `elem` cs)
then RE_FullRE (mkRegex$ translate_RE$ s)
else RE_FromEnd (compile_RE$ reverse$ s)
'[':cs - RE_FullRE (mkRegex$ translate_RE$ s)
'?':cs - RE_AnyChar (compile_RE cs)
c :cs - RE_Char c (compile_RE cs)
match_RE re s = case re of
RE_End- null s
RE_Anything - True
RE_FullRE r - isJust (matchRegex r s)
RE_FromEnd r - match_RE r (reverse s)
RE_AnyChar r - case s of
- False
_:xs - match_RE r xs
RE_Char c r - case s of
- False
x:xs - x==c match_RE r xs
match re {-s-} = match_RE (compile_RE re) {-s-}
third example is the functions used in my program to combine tests for
many regexprs. this also work in run-time compilation manner
-- |Map on functions instead of its' arguments!
map_functions [] x = []
map_functions (f:fs) x = f x : map_functions fs x
all_functions [] = const True
all_functions [f] = f
all_functions fs = and . map_functions fs
any_function [] = const False
any_function [f] = f
any_function fs = or . map_functions fs
That'd be wow, triple wow!
And run-time compilation is a fitting name for that.
more or less :)
LA Well, it's possible to do that. But I don't know of any Haskell
LA implementation that does. Sure, you might get a little bit of
LA that if func is defined suitably, like
LAfunc 0 = foo
LAfunc 1 = bar
LAfunc n = baz
LA Implementations that have the full laziness property will handle
LA one argument at a time to a function, and may do some work with just
LA one argument to func. But it's nothing like having real run-time code
LA generation.
of course, it's just graph reduction. and by explicitly moving last
argument to the right part of function definition i help compiler to
properly optimize such code
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: fastest Binary library!
Thanks Bulat! I'm happy with Erlang for the time being but I'll consider your library for my next IO-intensive Haskell project. On Jan 7, 2006, at 6:08 PM, Bulat Ziganshin wrote: Joel, if you are interested in switchinh to my library - write me. i have ideas about supporting your 150 records using your own DDL. smth like this: -- http://wagerlabs.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Where does memory go?
I compiled a simple one-liner: main = print Blah. This is the GC report: 5,620 bytes allocated in the heap 0 bytes copied during GC 0 collections in generation 0 ( 0.00s) 0 collections in generation 1 ( 0.00s) 1 Mb total memory in use Where did the memory go? What is 5K and what is (more suprisingly) 1Mb? Thanks, Joel -- http://wagerlabs.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Where does memory go?
On Sun, 2006-01-08 at 17:01 +, Joel Reymont wrote: I compiled a simple one-liner: main = print Blah. This is the GC report: 5,620 bytes allocated in the heap 0 bytes copied during GC 0 collections in generation 0 ( 0.00s) 0 collections in generation 1 ( 0.00s) 1 Mb total memory in use Where did the memory go? What is 5K and what is (more suprisingly) 1Mb? At the most coarse level GHC's rts manages memory in 1Mb blocks so the minimum amount of memory that ghc allocates for it's heap is 1Mb. That doesn't mean that it uses all of that 1Mb so the VM system may not need to dedicate the a whole 1Mb of actual RAM. Check with the OS to see how much of each mapped area is actually resident. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Avoiding name collisions by using value spaces instead of modules
- Original Message -
From: Daniel Fischer [EMAIL PROTECTED]
To: Brian Hulley [EMAIL PROTECTED]
Cc: Haskell-cafe haskell-cafe@haskell.org
Sent: Sunday, January 08, 2006 3:47 PM
Subject: Re: [Haskell-cafe] Avoiding name collisions by using value spaces
instead of modules
Am Sonntag, 8. Januar 2006 14:06 schrieb Brian Hulley:
Hi -
A main problem I've found with Haskell is that within a module, too many
things are put into the same scope. For example
data Tree a b = Leaf a | Node {elem::b, lhs::Tree a b, rhs::Tree a b}
snip
I propose that the above declaration should introduce a *new module*
Tree,
as a sub module of the containing module, and Leaf, Node, elem etc will
be
put into this module, and not the module containing the data declaration
itself.
What speaks against putting the data declaration in a separate module:
module ThisKindOfTrees where
data Tree a b = ...
and then use qualified imports (with a short alias), if you want to use
different kinds of trees in one module?
All I'm proposing is that the compiler should do all this painful work for
you, so that you don't need to bother creating a different file that then
needs two import directives to achieve the effect I want. Is there any case
where you would *not* want a type to be declared in its own module?
Yes, more files, but, IMHO, much more readable.
In what way is it more readable?
snip
For example, for
module M where
foo :: forall b. Eq a = Set (Tree a) - Tree ([a],b) - [Tree (a,b)]
we ignore the forall and Eq, and replace tyvars and tuple the results to
get:
M.(Set (Tree ?), Tree ( (,) ( [] ?) ?), [] (Tree ( (,) ? ?))).foo
as the fully qualified reference to the entity we've just declared.
Looks absolutely horrible to me. What would we gain?
We could have
M.(Set (Tree ?), Tree ( (,) ( [] ?) ?), [] (Tree ( (,) ? ?))).foo
and
M.(Int, Set (Tree ?), Tree ( (,) ( [] ?) ?), [] (Tree ( (,) ? ?))).foo
but why? Do we really want it? I certainly don't.
I agree that I would certainly not want to have to write out the fully
qualified name (or superfluously qualified name as you point out with
Int,...), but I think we would gain a great deal from this, because just by
making a declaration in module M, we've effectively created an infinite
number of child modules that the declaration belongs to, without having to
create an infinite number of files and write an infinite number of import
directives in M.
For example, suppose I'm writing a module M that deals with grammar, where
the elements in a grammar rule are parameterised so that rules can be
written using strings but processed as if we'd used ints instead:
data Element a = Terminal a | Nonterminal a | Action a
data Rule a = Rule (Element a) [[Element a]]
Now I want to convert elements and rules from a to Int, so at the moment I
have to write:
convertElement :: Element a - CM (Element Int)
...
convertRule :: Rule a - CM (Rule Int)
for some appropriate monad CM.
Whereas I would have much preferred to use just the word convert in both
cases. It is tremendously annoying to have to suffix everything with the
type name.
In another situation, suppose we have two types T1 and T2, and some function
convert :: T1 - T2
The problem I have is which module (if I used a separate module for T1 and
T2), should I put the convert function in? Essentially I think it belongs to
the space of relations between T1 and T2, hence my idea to use tuple
notation to get a module called (Q1,Q2) eg (Set,Map). But I certainly don't
want the bother of having to create a new file and type import directives
into M every time I want to define a function on some different relation
space.
Really I don't want to have to think about modules at all, since I'd like to
write code that organises itself into modules (using these ty-tuples and
top-down type/identifier-resolution inference) so I can concentrate on typed
values and relations between them without all the module-level plumbing.
snip
you'd havoc because sometimes you've just made an error -- which wouldn't
then be spotted by the type-checker.
I agree this could be a disadvantage - ease of coding is gained but some
kinds of errors cannot be caught so easily.
Finally (apologies for this long post), returning to the use of ^ to
allow
an object oriented way of thinking consider:
insert :: a - Set a - Set a
ps = singleton 3
qs = insert 4 ps
rs = ps^insert 4
When resolving insert used in the binding for rs, the compiler should
see
that we are looking for some function Set Int - Int - Set Int, and
hence
will be looking in the current module augmented by the Set module.
However
the Set module only has a binding for insert with type a - Set a - Set
a.
So the compiler should generate a new function insert' from insert by
moving the first Set a arg to the front.
Automatic permutation of arguments? Has its merits, but goodbye to
type-safety, I believe.
Re: [Haskell-cafe] Avoiding name collisions by using value spaces instead of modules
On 08/01/06, Brian Hulley [EMAIL PROTECTED] wrote: For example, suppose I'm writing a module M that deals with grammar, where the elements in a grammar rule are parameterised so that rules can be written using strings but processed as if we'd used ints instead: data Element a = Terminal a | Nonterminal a | Action a data Rule a = Rule (Element a) [[Element a]] Now I want to convert elements and rules from a to Int, so at the moment I have to write: convertElement :: Element a - CM (Element Int) ... convertRule :: Rule a - CM (Rule Int) for some appropriate monad CM. Whereas I would have much preferred to use just the word convert in both cases. It is tremendously annoying to have to suffix everything with the type name. This is what typeclasses are for. class Convert c where convert :: c a - CM (c Int) - Cale ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Avoiding name collisions by using value spaces instead of modules
- Original Message - From: Cale Gibbard [EMAIL PROTECTED] To: Brian Hulley [EMAIL PROTECTED] Cc: Daniel Fischer [EMAIL PROTECTED]; Haskell-cafe haskell-cafe@haskell.org Sent: Sunday, January 08, 2006 5:54 PM Subject: Re: [Haskell-cafe] Avoiding name collisions by using value spaces instead of modules On 08/01/06, Brian Hulley [EMAIL PROTECTED] wrote: For example, suppose I'm writing a module M that deals with grammar, where the elements in a grammar rule are parameterised so that rules can be written using strings but processed as if we'd used ints instead: data Element a = Terminal a | Nonterminal a | Action a data Rule a = Rule (Element a) [[Element a]] Now I want to convert elements and rules from a to Int, so at the moment I have to write: convertElement :: Element a - CM (Element Int) ... convertRule :: Rule a - CM (Rule Int) for some appropriate monad CM. Whereas I would have much preferred to use just the word convert in both cases. It is tremendously annoying to have to suffix everything with the type name. This is what typeclasses are for. class Convert c where convert :: c a - CM (c Int) Type classes just seem overkill for this kind of thing. All I want is compile time resolution of an overloaded identifier, whereas type classes give all the machinery that would be needed if I wanted runtime ad-hoc polymorphism, with all the attendant verbosity, just so that the compiler can then optimize out the runtime polymorphism behind the scenes for cases like the example above. After all, I just want to write two very simple functions, so the effort to factor into a type class + two instances, also having to include the Convert c in the context whenever I call one of them just seems really painful. Also, the word Convert is now used up as well... Also, when I'm just writing code in an exploratory way, I don't know in advance what the common things are that could be factored out into type classes (except perhaps in very simple examples like that above), so while I'm writing the code for the first time there is still a problem trying to think up different names. Regards, Brian. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Avoiding name collisions by using value spaces instead of modules
On 08/01/06, Brian Hulley [EMAIL PROTECTED] wrote: - Original Message - From: Cale Gibbard [EMAIL PROTECTED] To: Brian Hulley [EMAIL PROTECTED] Cc: Daniel Fischer [EMAIL PROTECTED]; Haskell-cafe haskell-cafe@haskell.org Sent: Sunday, January 08, 2006 5:54 PM Subject: Re: [Haskell-cafe] Avoiding name collisions by using value spaces instead of modules On 08/01/06, Brian Hulley [EMAIL PROTECTED] wrote: For example, suppose I'm writing a module M that deals with grammar, where the elements in a grammar rule are parameterised so that rules can be written using strings but processed as if we'd used ints instead: data Element a = Terminal a | Nonterminal a | Action a data Rule a = Rule (Element a) [[Element a]] Now I want to convert elements and rules from a to Int, so at the moment I have to write: convertElement :: Element a - CM (Element Int) ... convertRule :: Rule a - CM (Rule Int) for some appropriate monad CM. Whereas I would have much preferred to use just the word convert in both cases. It is tremendously annoying to have to suffix everything with the type name. This is what typeclasses are for. class Convert c where convert :: c a - CM (c Int) Type classes just seem overkill for this kind of thing. All I want is compile time resolution of an overloaded identifier, whereas type classes give all the machinery that would be needed if I wanted runtime ad-hoc polymorphism, with all the attendant verbosity, just so that the compiler can then optimize out the runtime polymorphism behind the scenes for cases like the example above. There's no such runtime polymorphism going on there. Barring existential types, everything is always resolved at compile time. Further, I wouldn't consider the polymorphism ad-hoc, so much as it is a restricted form of parametric polymorphism. Further, it's not really that much typing. You type: class Convert c where convert :: c a - CM (c Int) instance Convert Rule where convert (Rule lhs rhss) = ... instance Convert Element where convert (Terminal t) = ... convert (Nonterminal n) = ... convert (Action a) = ... rather than convertRule :: Rule a - CM (Rule Int) convert (Rule lhs rhss) = ... convertElement :: Element a - CM (Element Int) convert (Terminal t) = ... convert (Nonterminal n) = ... convert (Action a) = ... which is 8 lines rather than 6, but, hey, what do you want? You get the convenience of not typing qualifiers everywhere, and restricted parametric polymorphism if you ever need it. After all, I just want to write two very simple functions, so the effort to factor into a type class + two instances, also having to include the Convert c in the context whenever I call one of them just seems really painful. Also, the word Convert is now used up as well... First, you only add the context when the type variable escapes and gets universally quantified (modulo that class restriction). That is, you only end up typing anything extra if you use the convert function in a way which is polymorphic, something that you can't do with your ad-hoc polymorphism, or with modules. Convert is only used up *as the name of a typeclass*, which is a pretty sparse namespace to begin with. Just name the classes after the functions you're generalising, and you'll run out of names at exactly the same time. Secondly, if the functions are really different, and you never plan to use them polymorphically, why the heck would you want to call them the same thing? That's just confusing to anyone that has to read the code later. If you end up qualifying all the uses of them with implicitly declared module names, and all the modules are in (qualified) scope, that's basically the same as adding qualifications to the names in the first place. It's just as bad to end up with a bunch of almost-empty namespaces as it is to end up with one large too-cluttered namespace. Also, when I'm just writing code in an exploratory way, I don't know in advance what the common things are that could be factored out into type classes (except perhaps in very simple examples like that above), so while I'm writing the code for the first time there is still a problem trying to think up different names. Perhaps a thesaurus? :) I'm sorry, but I've always had a really hard time taking this sort of complaint seriously. You *really* can't come up with a unique name? Try adding an adjective, or if that's too much typing, even a (meaningful) single letter prefix/postfix. Some people hate those, but I see no problem with them when used sparingly. In the case of different tree types, you can name one of them RoseTree, and another BinaryTree. If it's still really hard to come up with a name, possibly you shouldn't be naming the thing in the first place. Rather than trying to keep your fingers moving, think about the design a moment longer. Why are you defining it? What function does it serve to the
Re: [Haskell-cafe] x86 code generation going wrong?
Brian Sniffen wrote: The first couldn't even complete on my 2.26 GHz Celeron! It's only got 512 MB of RAM, which may be part of the problem. I should not leak memory but it may be an optimization problem. Try explicitly using ghc -O2 -funbox-strict-fields. Stack space overflow: current size 1048576 bytes. Use `+RTS -Ksize' to increase it. ./test1 sum-file-test-input 25.33s user 2.89s system 18% cpu 2:32.02 total ./test2 sum-file-test-input 4.79s user 0.20s system 94% cpu 5.276 total ./test3 sum-file-test-input 4.46s user 0.14s system 99% cpu 4.623 total -- Brian T. Sniffen [EMAIL PROTECTED]or[EMAIL PROTECTED] http://www.evenmere.org/~bts ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Avoiding name collisions by using value spaces instead of modules
Cale Gibbard wrote: snip Thanks for the illustration - I see another advantage with type classes is that you only need to write the type signature once (in the class declaration) instead of before each instance binding. Secondly, if the functions are really different, and you never plan to use them polymorphically, why the heck would you want to call them the same thing? That's just confusing to anyone that has to read the code later. For example, Data.Map declares: insert :: Ord k = k - a - Map k a - Map k a whereas Data.Set declares: insert :: Ord a = a - Set a - Set a This is an example where type classes can't be applied even though the functions in a sense do the same thing. My system would solve this problem, by allowing the programmer to type d = insert a b c and have the type inference algorithm work out that Data.Map.insert was meant, as long as c or d has been typed as Map p q. But perhaps there is a way to get the signature for Data.Map.insert into the same form as that of Data.Set.insert? Regards, Brian. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is there a notion for identity?
On Sunday 08 January 2006 06:43 am, Tim Walkenhorst wrote:
{- Disclaimer: I'm rather new to Haskell and completely new to this board.
I may not use the correct terminology in all cases, but I hope my
intention becomes clear when you have a look at the code-snippets. -}
Hey ho,
Is there any way two find out whether two variables refer to the
same cell? That is I'm looking for a notion of identity (compareable
to == in Java) as opposed to equality (== in Haskell).
Another poster has already replied with a link to a long answer. The short
answer is no, not really.
An attempted rationale:
The semantics of such an identity operator are unclear. The operator could
be a test for leibenz equality (ie, structural equality, ie replaceability in
all contexts), but such an operator cannot be decidable (proof due to
Church), so that wouldn't help in your situation anyway. The general
usefulness of such an operator is debatable.
We could instead provide an implementation-dependent operation that tests for
identical heap location, but such an operator would give different results
with different Haskell implementations and would be sensitive to
optimizations. That would either be a horribly broken operator or (to fix
the brokeness) greatly constrain the avaliable optimizations and
implementation strategies.
For the problem at hand (involving the STLC), you will not be able to type
omega because omega is a non-normalizing closed term and STLC has the strong
normalization property. You will have to move to a more expressive calculus
to type omega.
Rob Dockins
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] x86 code generation going wrong?
From: Chris Kuklewicz [EMAIL PROTECTED]
To: [EMAIL PROTECTED], Haskell Cafe haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] x86 code generation going wrong?
Date: Sun, 08 Jan 2006 20:33:57 +
Brian Sniffen wrote:
The first couldn't even complete on my 2.26 GHz Celeron! It's only got
512 MB of RAM, which may be part of the problem.
I should not leak memory but it may be an optimization problem.
Try explicitly using ghc -O2 -funbox-strict-fields.
On p4. 2.4 ghz 512mb first example takes about 2.5 mb of ram.
I've compiled explicitelly with -O2, because without optimisations it takes
ridicilously large amount of RAM.
I've changed {# OPTIONS to OPTIONS_GHC as Bulat sugested
but still no effect. Options have to be specified on command line in
order to work.
Greetings, Bane.
_
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] x86 code generation going wrong?
bmaxa:
From: Chris Kuklewicz [EMAIL PROTECTED]
To: [EMAIL PROTECTED], Haskell Cafe haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] x86 code generation going wrong?
Date: Sun, 08 Jan 2006 20:33:57 +
Brian Sniffen wrote:
The first couldn't even complete on my 2.26 GHz Celeron! It's only got
512 MB of RAM, which may be part of the problem.
I should not leak memory but it may be an optimization problem.
Try explicitly using ghc -O2 -funbox-strict-fields.
On p4. 2.4 ghz 512mb first example takes about 2.5 mb of ram.
I've compiled explicitelly with -O2, because without optimisations it takes
ridicilously large amount of RAM.
I've changed {# OPTIONS to OPTIONS_GHC as Bulat sugested
but still no effect. Options have to be specified on command line in
order to work.
Ensure that the {-# OPTIONS ... #-} lines is the *first* line of the
file, and that no comments precede it.
-- Don
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Avoiding name collisions by using value spaces instead of modules
On 08/01/06, Brian Hulley [EMAIL PROTECTED] wrote:
Cale Gibbard wrote:
snip
Thanks for the illustration - I see another advantage with type classes is
that you only need to write the type signature once (in the class
declaration) instead of before each instance binding.
Secondly, if the functions are really different, and you never plan to
use them polymorphically, why the heck would you want to call them the
same thing? That's just confusing to anyone that has to read the code
later.
For example, Data.Map declares:
insert :: Ord k = k - a - Map k a - Map k a
whereas Data.Set declares:
insert :: Ord a = a - Set a - Set a
This is an example where type classes can't be applied even though the
functions in a sense do the same thing. My system would solve this problem,
by allowing the programmer to type d = insert a b c and have the type
inference algorithm work out that Data.Map.insert was meant, as long as c or
d has been typed as Map p q.
But perhaps there is a way to get the signature for Data.Map.insert into the
same form as that of Data.Set.insert?
Regards, Brian.
Well, that's an interesting case, since the types are actually
reasonably different. Prior to these being named the same way, we had
addToSet / addToFM, which didn't require qualified imports. Of course,
with qualified imports, we get the same effect as postfixing, so it's
basically the same thing.
Unifying these two under a single operation is certainly trickier, and
it's a little more questionable that it should be done at all, given
that their types are so different -- below is the closest I could come
to it off-hand.
---
{-# OPTIONS_GHC -fglasgow-exts #-} -- for fundeps/multiparameter classes
import qualified Data.Map as Map
import Data.Map (Map)
import qualified Data.Set as Set
import Data.Set (Set)
class Insert t c a | c a - t where
insert :: t - c a - c a
instance (Ord a) = Insert a Set a where
insert x s = Set.insert x s
instance (Ord k) = Insert (k,a) (Map k) a where
insert (k,v) m = Map.insert k v m
exampleSet = insert 5 $ insert 6 $ Set.empty
exampleMap = insert (1,2) $ insert (2,7) $ Map.empty
Perhaps someone else will have some ideas as to suitable typeclass
magic to allow for the curried form rather than using tuples.
- Cale
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Avoiding name collisions by using value spaces instead of modules
Unifying these two under a single operation is certainly trickier, and
it's a little more questionable that it should be done at all, given
that their types are so different -- below is the closest I could come
to it off-hand.
---
{-# OPTIONS_GHC -fglasgow-exts #-} -- for fundeps/multiparameter classes
import qualified Data.Map as Map
import Data.Map (Map)
import qualified Data.Set as Set
import Data.Set (Set)
class Insert t c a | c a - t where
insert :: t - c a - c a
instance (Ord a) = Insert a Set a where
insert x s = Set.insert x s
instance (Ord k) = Insert (k,a) (Map k) a where
insert (k,v) m = Map.insert k v m
exampleSet = insert 5 $ insert 6 $ Set.empty
exampleMap = insert (1,2) $ insert (2,7) $ Map.empty
Perhaps someone else will have some ideas as to suitable typeclass
magic to allow for the curried form rather than using tuples.
- Cale
Oh, this is a little less general, but simpler to use:
{-# OPTIONS_GHC -fglasgow-exts #-}
import qualified Data.Map as Map
import Data.Map (Map)
import qualified Data.Set as Set
import Data.Set (Set)
class Insert t c | c - t where
insert :: t - c - c
instance (Ord a) = Insert a (Set a) where
insert x s = Set.insert x s
instance (Ord k) = Insert (k,a) (Map k a) where
insert (k,v) m = Map.insert k v m
exampleSet = insert 5 $ insert 6 $ Set.empty
exampleMap = insert (1,2) $ insert (2,7) $ Map.empty
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] x86 code generation going wrong?
From: [EMAIL PROTECTED] (Donald Bruce Stewart)
To: Branimir Maksimovic [EMAIL PROTECTED]
CC: [EMAIL PROTECTED],
[EMAIL PROTECTED],haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] x86 code generation going wrong?
Date: Mon, 9 Jan 2006 11:15:51 +1100
bmaxa:
From: Chris Kuklewicz [EMAIL PROTECTED]
To: [EMAIL PROTECTED], Haskell Cafe haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] x86 code generation going wrong?
Date: Sun, 08 Jan 2006 20:33:57 +
Brian Sniffen wrote:
The first couldn't even complete on my 2.26 GHz Celeron! It's only
got
512 MB of RAM, which may be part of the problem.
I should not leak memory but it may be an optimization problem.
Try explicitly using ghc -O2 -funbox-strict-fields.
On p4. 2.4 ghz 512mb first example takes about 2.5 mb of ram.
I've compiled explicitelly with -O2, because without optimisations it
takes
ridicilously large amount of RAM.
I've changed {# OPTIONS to OPTIONS_GHC as Bulat sugested
but still no effect. Options have to be specified on command line in
order to work.
Ensure that the {-# OPTIONS ... #-} lines is the *first* line of the
file, and that no comments precede it.
Aaah, I didn't knew that. Now this works, thanks!
Greetings, Bane.
_
FREE pop-up blocking with the new MSN Toolbar - get it now!
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Avoiding name collisions by using value spaces instead of modules
Cale Gibbard wrote:
Unifying these two under a single operation is certainly trickier,
and it's a little more questionable that it should be done at all,
given that their types are so different -- below is the closest I
could come to it off-hand.
---
{-# OPTIONS_GHC -fglasgow-exts #-} -- for fundeps/multiparameter
classes import qualified Data.Map as Map
import Data.Map (Map)
import qualified Data.Set as Set
import Data.Set (Set)
class Insert t c a | c a - t where
insert :: t - c a - c a
instance (Ord a) = Insert a Set a where
insert x s = Set.insert x s
instance (Ord k) = Insert (k,a) (Map k) a where
insert (k,v) m = Map.insert k v m
exampleSet = insert 5 $ insert 6 $ Set.empty
exampleMap = insert (1,2) $ insert (2,7) $ Map.empty
Perhaps someone else will have some ideas as to suitable typeclass
magic to allow for the curried form rather than using tuples.
- Cale
Oh, this is a little less general, but simpler to use:
{-# OPTIONS_GHC -fglasgow-exts #-}
import qualified Data.Map as Map
import Data.Map (Map)
import qualified Data.Set as Set
import Data.Set (Set)
class Insert t c | c - t where
insert :: t - c - c
instance (Ord a) = Insert a (Set a) where
insert x s = Set.insert x s
instance (Ord k) = Insert (k,a) (Map k a) where
insert (k,v) m = Map.insert k v m
exampleSet = insert 5 $ insert 6 $ Set.empty
exampleMap = insert (1,2) $ insert (2,7) $ Map.empty
Thanks! I'm impressed. Obviously there is a lot more power in type classes
than I'd thought. I hadn't realised that you could separate the Ord a and
Ord k from the type signature in the class declaration, and put them in
instance declarations like that (for example).
It would be really interesting to see how far one could go in factoring all
the collection type functions/values into type classes.
Best regards,
Brian.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] In for a penny, in for a pound.
Hi All, Regarding the Fannkuch Shootout Entry: If we are willing to specialize flop in the way shown on the wiki, another 8% can be gained by similarly specializing rotate: rotate 2 (x1:x2:xs) = x2:x1:xs rotate 3 (x1:x2:x3:xs) = x2:x3:x1:xs rotate 4 (x1:x2:x3:x4:xs) = x2:x3:x4:x1:xs rotate 5 (x1:x2:x3:x4:x5:xs) = x2:x3:x4:x5:x1:xs rotate 6 (x1:x2:x3:x4:x5:x:6:xs) = x2:x3:x4:x5:x:6:x1:xs rotate 7 (x1:x2:x3:x4:x5:x:6:x7:xs) = x2:x3:x4:x5:x:6:x7:x1:xs rotate 8 (x1:x2:x3:x4:x5:x:6:x7:x8:xs) = x2:x3:x4:x5:x:6:x7:x8:x1:xs rotate 9 (x1:x2:x3:x4:x5:x:6:x7:x8:x9:xs) = x2:x3:x4:x5:x: 6:x7:x8:x9:x1:xs rotate 10 (x1:x2:x3:x4:x5:x:6:x7:x8:x9:x10:xs) = x2:x3:x4:x5:x: 6:x7:x8:x9:x10:x1:xs rotate n (x:xs) = rot' n xs where rot' 1 xs = x:xs rot' n (x:xs) = x:rot' (n-1) xs Cheers, David David F. Place mailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In for a penny, in for a pound.
d: Regarding the Fannkuch Shootout Entry: If we are willing to specialize flop in the way shown on the wiki, another 8% can be gained by similarly specializing rotate: rotate 2 (x1:x2:xs) = x2:x1:xs rotate 3 (x1:x2:x3:xs) = x2:x3:x1:xs ... Cheers, I've updated the proposed entry on the wiki. It now runs 40% faster than Bertram's original entry, and its within 25% of an imperative version I wrote yesterday translating from the currently fastest C version. Note that the imperative version is unoptimised so far though, so there could be room to move here, and it may be worth while translating some of the other C entries, to submit a fast, alongside an elegant entry. Entries that may currently be worth submitting: takfp - http://www.haskell.org/hawiki/TakfpEntry pidigits (currently 2nd!) - http://www.haskell.org/hawiki/PidigitsEntry mandelbrot- http://www.haskell.org/hawiki/MandelbrotEntry harmonic - http://www.haskell.org/hawiki/HarmonicEntry fannkuch (pure and impure) - http://www.haskell.org/hawiki/FannkuchEntry Chris, would you like to submit these? -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Where does memory go?
Hello Joel, Sunday, January 08, 2006, 8:01:00 PM, you wrote: JR I compiled a simple one-liner: main = print Blah. JR5,620 bytes allocated in the heap again, see at the GHC.Handle and so on :) try to find print definition and manually substitute all the code generated by this line. btw, one time i seen 15k raised (stripped) exefile just after adding one line of code to Haskell app -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
