Re: [Haskell-cafe] A question about monad laws
Wolfgang Jeltsch-2 wrote: No, I think, it’s the Prelude’s fault to define (==) as “floating point equality”. My bad, I meant IEEE (==) when I said it was our fault. I concur that the Prelude is at fault for using the (==) symbol for FP equality. Even if you don't demand from (==) to be an equivalence, you're giving a pure functional type to an impure operation (e.g because of SNaNs) My point was that since Haskell has a known and established mechanism for delimiting impurity, it seems as a shame not to use it to add some rigour to the myth-ridden, poorly understood floating point world. We need good FP for FP =) - Ariel J. Birnbaum -- View this message in context: http://www.nabble.com/A-question-about-%22monad-laws%22-tp15411587p16044986.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ackermann Function Memoization, GHC Weird Output or Bug?
Smaller example of this behavior: array ((0,0),(1,1)) [((1,1),6)] ! (0,3) 6 -- Eric Mertens ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A question about monad laws
ajb-2 wrote: Define: f = g = \x - f x = g So you're either not taking (=) as primitive or you're stating the additional property that there exists (=) such that f = g === (= g) . f (from which you can easily show that (f . g) = h === (f = h) . g ). A presentation of the monad laws based on (=) (I prefer (=) since it meshes better with (.) ) should (IMHO) regard (=) as primitive and state its needed properties whence one can derive all other formulations (Note that he Identity law then requires the existence of return as another primitive). That done, you define (=), fmap and the rest in terms of (=) : (=) = flip (= id) -- I like to put it as (= g) = (g = id) fmap f = (return . f) = id - Ariel J. Birnbaum -- View this message in context: http://www.nabble.com/A-question-about-%22monad-laws%22-tp15411587p16045123.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A question about monad laws
G'day all. Quoting askyle [EMAIL PROTECTED]: So you're either not taking (=) as primitive or you're stating the additional property that there exists (=) such that f = g === (= g) . f (from which you can easily show that (f . g) = h === (f = h) . g ). If you wanted to prove that bind is natural, you would need to define bind, no? Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ackermann Function Memoization, GHC Weird Output or Bug?
Here's the bug:
{-# INLINE safeIndex #-}
safeIndex :: Ix i = (i, i) - Int - i - Int
safeIndex (l,u) n i = let i' = unsafeIndex (l,u) i
in if (0 = i') (i' n)
then i'
else error Error in array index
unsafeIndex here is just a function which transforms indices into Int
indices into the flat array and does no checking of validity. Then
safeIndex simply checks if the result is nonnegative and less than the
size of the array. Whoops! The actual test to see if the index was
valid in the first place didn't actually get performed!
- Cale
On 14/03/2008, Eric Mertens [EMAIL PROTECTED] wrote:
Smaller example of this behavior:
array ((0,0),(1,1)) [((1,1),6)] ! (0,3)
6
--
Eric Mertens
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Some clarity please! (was Re: [Haskell-cafe] Re: (flawed?) benchmark : sort)
Hi On 14 Mar 2008, at 03:48, Roman Leshchinskiy wrote: Adrian Hey wrote: I would ask for any correct Eq instance something like the law: (x==y) = True implies x=y (and vice-versa) which implies f x = f y for all definable f which implies (f x == f y) = True (for expression types which are instances of Eq). This pretty much requires structural equality for concrete types. For abstract types you can do something different provided functions which can give different answers for two equal arguments are not exposed. How do you propose something like this to be specified in the language definition? The report doesn't (and shouldn't) know about abstract types. Why not? Why shouldn't there be at least a standard convention, if not an abstype-like feature for establishing an abstraction barrier, and hence determine the appropriate observational equality for an abstract type? So you can either require your law to hold everywhere, which IMO isn't a good idea, or you don't require it to hold. From the language definition point of view, I don't see any middle ground here. Why not demand it in the definition, but allow unsafe leaks in practice? As usual. Why are you so determined that there's nothing principled to do here? People like to say Haskell's easy to reason about. How much of a lie would you like that not to be? Also, when you talk about definable functions, do you include things like I/O? What if I want to store things (such as a Set) on a disk? If the same abstract value can have multiple representations, do I have to convert them all to some canonical representation before writing them to a file? Canonical representations are not necessary for observational congruence. Representation hiding is enough. This might be rather slow and is, IMO, quite unnecessary. From a more philosophical points of view, I'd say that the appropriate concept of equality depends a lot on the problem domain. It's certainly true that different predicates may respect different equivalence relations. The equivalence relation you call equality should be the finest of those, with finer representational distinctions abstracted away. What that buys you is a class of predicates which are guaranteed to respect equality without further ado... Personally, I quite strongly disagree with restricting Eq instances in the way you propose. I have never found much use for strict structural equality (as opposed to domain-specific equality which may or may not coincide with the structural one). ...which is how we use equality when we think. I certainly don't think strict structural equality should be compulsory. In fact, for Haskell's lazy data structures, you rather need lazy structural simulation if you want to explain why cycle x = cycle xx What would be so wrong with establishing a convention for saying, at each given type (1) this is the propositional equivalence which we expect functions on this type to respect (2) here is an interface which respects that equivalence (3) here are some unsafe functions which break that equivalence: use them at your own risk ? Why is it pragmatically necessary to make reasoning difficult? I'm sure that wise folk out there have wise answers to that question which they don't consider to be an embarrassment. When representation-hiding is bliss, 'tis folly to be wise. All the best Conor ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] HFuse: ls fails in HelloFS
Hello, I've installed the HFuse package from hackage and am playing with the HelloFS example in the System/Posix/HFuse directory. The problem that I encounter is that listing the directory doesn't work: % ghc --make HelloFS.hs [1 of 1] Compiling Main ( HelloFS.hs, HelloFS.o ) Linking HelloFS ... % mkdir bla % ./HelloFS bla % cd bla % cat hello Hello World, HFuse! % ls ls: cannot open directory .: Function not implemented Here's the relevant output from strace: open(., O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x8) = -1 ENOSYS (Function not implemented) write(2, ls: , 4ls: ) = 4 write(2, cannot open directory ., 23cannot open directory .) = 23 write(2, : Function not implemented, 26: Function not implemented) = 26 Some system information: - Debian unstable - Linux 2.6.24 - Fuse 2.7.3 - GHC 6.8.2 - HFuse 0.1 Any ideas? Thanks, Georg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: (flawed?) benchmark : sort
Dan Weston wrote: 6.3.2 (The Ord Class): The Ord class is used for totally ordered datatypes. This *requires* that it be absolutely impossible in valid code to distinguish equivalent (in the EQ sense, not the == sense) things via the functions of Ord. The intended interpretation of these functions is clear and can be taken as normative: forall f . (compare x y == EQ and (f x or f y is defined)) == f x == f y) Thanks Dan. I didn't grasp the significance of this at first, but I believe you are correct. But maybe it should be = not == in the last line? forall f . (compare x y == EQ and (f x or f y is defined)) == f x = f y) So assuming your (and my) logic is correct, the existing report text does indeed settle the original dispute that sparked this thread. Essentially you can't have 2 distinct values that compare equal, so if they do then they must be indistinguishable? Is that right? So there is no need for the sort on a list of elements whose type is an instance of Ord to be stable as the difference between the results of a stable and unstable sort cannot be observable for any (correct) Ord instance (assuming the the instances compare method was used to perform the sort). So if we have a compare method on this type we can establish the == method: x == y = case compare x y of EQ - True _ - False and from this it follows that (x == y) = True implies x and y are indistingushable. So I believe for types that are instances of both Eq and Ord, this settles the question of what (x == y) = True implies. So now I'm wondering what about types that are instances of Eq but not of Ord? Well from para. 6.3.1 The Eq class provides equality (==) and inequality (/=) methods. Well I guess assuming that saying two values are equal is another way of saying they are indistinguishable then I think it's pretty clear what the report is saying. This interpretation also ensures consistency between Eq/Ord instances and Eq only instances. Assuming this is all correct, I think I can sleep easier now I can forget about all this things being equal and not equal at the same time craziness, at least for Eq/Ord instances that are compliant with the standard (which are the only ones I care about). I think anyone wanting standard classes with different mathematical properties should define them, stick them in Hackage and propose them for Haskell-prime (if that's still happening?) Regards -- Adrian Hey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Problem making a program in ghc
Hello Sterling, Friday, March 14, 2008, 7:06:24 AM, you wrote: yes, it's another question. my own program also writes to logfile and it got lock-free only when i've switched to using my own IO routines This answer may be way off base, but if differences appear between ghci and compiled versions, I've often found its as simple as remembering to compile with the -threaded flag. The ghci runtime is threaded by default, as I understand it, while compiled binaries are not, and IO operations will block in very different fashions (i.e. in their own thread, or stalling the entire app) depending on the runtime. Regards, sterl. On Mar 13, 2008, at 3:47 PM, Adam Langley wrote: web application), I have a log that confirms that the response arrives correctly. I hate to see any requests for help go unanswered here, but this one might be tough. I think you need to give some more information, otherwise the suggestions are going to be very general. Can you put the Haskell source code on a website somewhere and link to it. Since it's a network service, an example request and reply might be good to include. In general, you should check that you are correctly flushing your connection. If you are using Handles to interface to the network, they can buffer the response. hFlush[1] may need to be called when you have finished generating it. [1] http://haskell.org/ghc/docs/latest/html/libraries/base/System- IO.html#v%3AhFlush AGL -- Adam Langley [EMAIL PROTECTED] http://www.imperialviolet.org ___ Haskell-Cafe mailing list ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] all threads are blocked by recvFrom
Hello, I have a problem with building multithreaded UDP server. If main thread is waiting for new request in recvFrom all other threads are blocked too. I've checked every variant with forkIO,forkOS,-threaded etc, nothing's helped. After reading GHC docs I've understood this is happened becouse foreign function call from recvFrom (network library) is marked to be unsefe, so it's execution blocks every other thread. How can I resolve it? Thank you. Vitaliy. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] FFI newbie question
I am trying to figure out how to pass array of String (char **) from C to Haskell? I have read the FFI examples, but most of them are centered on calling C from Haskell. I have read in the mailing list, it is rare to call Haskell from C, but my requirement is such that I am going to write Haskell library that needs to be called from C. Also, I read that the linking in FFI needs to be done through ghc. However, I have an existing Make system that uses gcc to do the linking, so what extra steps I need to do make gcc do the linking instead? Anurag ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A question about monad laws
Am Donnerstag, 13. März 2008 21:10 schrieben Sie: Not to be picky, but where did you hear that (==) established an equivalence relation? I think that’s the way it should be according to most Haskeller’s opinion. It might be true that the Haskell 98 report doesn’t say so but I think that many library types and functions (Data.Set stuff, for example) rely on this. A future standard should state laws an instance has to obey for every class it introduces. […] Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Some clarity please! (was Re: [Haskell-cafe] Re: (flawed?) benchmark : sort)
Conor McBride wrote: Hi On 14 Mar 2008, at 03:48, Roman Leshchinskiy wrote: Adrian Hey wrote: I would ask for any correct Eq instance something like the law: (x==y) = True implies x=y (and vice-versa) which implies f x = f y for all definable f which implies (f x == f y) = True (for expression types which are instances of Eq). This pretty much requires structural equality for concrete types. For abstract types you can do something different provided functions which can give different answers for two equal arguments are not exposed. How do you propose something like this to be specified in the language definition? The report doesn't (and shouldn't) know about abstract types. Why not? Why shouldn't there be at least a standard convention, if not an abstype-like feature for establishing an abstraction barrier, and hence determine the appropriate observational equality for an abstract type? Adrian's original question/proposal was about the language report. I'm only pointing out that all other considerations aside, it's not clear how to distinguish between the implementation part of the ADT and everything else in the report. So you can either require your law to hold everywhere, which IMO isn't a good idea, or you don't require it to hold. From the language definition point of view, I don't see any middle ground here. Why not demand it in the definition, but allow unsafe leaks in practice? As usual. Why are you so determined that there's nothing principled to do here? People like to say Haskell's easy to reason about. How much of a lie would you like that not to be? I'm not sure what you mean here. Should the report say something like a valid Eq instance must ensure that x == y implies f x == f y for all f? Probably not, since this requires structural equality which is not what you want for ADTs. Should it be for all f which are not part of the implementation of the type? That's a non-requirement if the report doesn't specify what the implementation is. So what should it say? Unsafe leaks are ok as long as they are rarely used. If you have to resort to unsafe leaks to define an ADT, then something is wrong. Also, when you talk about definable functions, do you include things like I/O? What if I want to store things (such as a Set) on a disk? If the same abstract value can have multiple representations, do I have to convert them all to some canonical representation before writing them to a file? Canonical representations are not necessary for observational congruence. Representation hiding is enough. I beg to disagree. If the representation is stored on the disk, for instance, then it becomes observable, even if it's still hidden in the sense that you can't do anything useful with it other than read it back. Actually, we don't even need the disk. What about ADTs which implement Storable, for instance? What would be so wrong with establishing a convention for saying, at each given type (1) this is the propositional equivalence which we expect functions on this type to respect (2) here is an interface which respects that equivalence (3) here are some unsafe functions which break that equivalence: use them at your own risk My (probably erroneous) understanding of the above is that you propose to call (==) propositional equivalence and to require that for every type, we define what that means. To be honest, I don't quite see how this is different from saying that the meaning of (==) should be documented for every type, which I wholeheartedly agree with. But the unsafe bit really doesn't make sense to me. As an example, consider the following data type: data Expr = Var String | Lam String Expr | App Expr Expr The most natural notion of equality here is probably equality up to alpha conversion and that's what I usually would expect (==) to mean. In fact, I would be quite surprised if (==) meant structural equality. Should I now consider the Show instance for this type somehow unsafe? I don't see why this makes sense. Most of the time I probably don't even want to make this type abstract. Are the constructors also unsafe? Why? To summarise my views on this: an Eq instance should define a meaningful equivalence relation and be documented. Requiring anything beyond that just doesn't make sense to me. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FFI newbie question
On Fri, Mar 14, 2008 at 09:54:11PM +0800, Verma Anurag-VNF673 wrote: I am trying to figure out how to pass array of String (char **) from C to Haskell? I have read the FFI examples, but most of them are centered on calling C from Haskell. I have read in the mailing list, it is rare to call Haskell from C, but my requirement is such that I am going to write Haskell library that needs to be called from C. here is a simple example. the first argument is the number of strings, the second is the pointer. The same code will work whether you are calling C from haskell or vice versa. getargs :: Int - (Ptr CString) - IO [String] getArgs argc argv = do let f n = peekElemOff argv n = peekCString mapM f [0 .. fromIntegral argc - 1] John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: all threads are blocked by recvFrom
Rebuilding of the network package with changed safety helped but I don't think this is the solution. BTW accept is declared as safe. What is the reason of declaring recvFrom as unsafe? I think this breaks highly required feature. Apparently it's impossible to make concurrent server for non connection based protocols. 2008/3/14, Vitaliy Akimov [EMAIL PROTECTED]: Hello, I have a problem with building multithreaded UDP server. If main thread is waiting for new request in recvFrom all other threads are blocked too. I've checked every variant with forkIO,forkOS,-threaded etc, nothing's helped. After reading GHC docs I've understood this is happened becouse foreign function call from recvFrom (network library) is marked to be unsefe, so it's execution blocks every other thread. How can I resolve it? Thank you. Vitaliy. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: all threads are blocked by recvFrom
On Fri, Mar 14, 2008 at 7:43 AM, Vitaliy Akimov [EMAIL PROTECTED] wrote: Rebuilding of the network package with changed safety helped but I don't think this is the solution. BTW accept is declared as safe. What is the reason of declaring recvFrom as unsafe? I think this breaks highly required feature. Apparently it's impossible to make concurrent server for non connection based protocols. I assume that you're binding the libc function directly here: In that case, you need to have the RTS manage sleeping your thread for you. You should make the socket non-blocking and handle the EAGAIN and EWOULDBLOCK cases by calling threadWaitRead[1] to block the current Haskell thread only, until the fd is readable. Note that threadWaitRead is GHC only. If you download the source to network-bytestring[2], you can see a very similar pattern in the code for send and recv in there. Alternatively, you can use the functions in Network.Socket, which should work fine. [1] http://haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent.html#v%3AthreadWaitRead [2] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/network-bytestring-0.1.1.2 -- Adam Langley [EMAIL PROTECTED] http://www.imperialviolet.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: all threads are blocked by recvFrom
I assume that you're binding the libc function directly here: I'm using Network.Socket. Sory if it's not clear from my previous posts. In that case, you need to have the RTS manage sleeping your thread for you. You should make the socket non-blocking and handle the EAGAIN and EWOULDBLOCK cases by calling threadWaitRead[1] to block the current Haskell thread only, until the fd is readable. Note that threadWaitRead is GHC only. If you download the source to network-bytestring[2], you can see a very similar pattern in the code for send and recv in there. Thanks, but I haven't managed to find a way of setting a socket into non blocking mode without using FFI directly (and I haven't found solution in network-bytestring too). How can I make this? The only way I've found is making handle by socketToHandle then reading by hGetBufNonBlocking. But this way seems not suited for non-connection based sockets. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)
Am Samstag, 2. Februar 2008 14:54 schrieben Sie: On Feb 1, 2008 10:32 PM, Wolfgang Jeltsch wrote: Am Freitag, 1. Februar 2008 13:00 schrieb Alfonso Acosta: […] To make it friendlier for the end user I thought about defining aliases for lets say the first 1 numbers using Template Haskell. That could even make error reports friendlier (not sure to what point though). What do you think? I have no clear opinion about that at the moment. Maybe it's okay to use the representation directly. This way, we don't introduce a dependeny on the Template Haskell language extension (which is only supported by GHC), and the actual representation will occur in error messages anyway whenever the message shows a computed number. Well, my EDSL already makes extensive use of TH. So, being selfish, it wouldn't be a problem for me (or any other GHC user) and I think it would make the library much more usable. Hello again, I have a feedback from my Grapefruit co-developer about those aliases in the type-level package. He told me that on his machine, building this package took about 15 minutes, obviously because the machine ran out of RAM. He also told me that the generated object code was very large, and that loading the documentation page generated by Haddock took very long. And he made a very good point: Who needs aliases for *all* numbers until, say, 1? Who needs to hard-code the vector length 8247 in his code? I think that in practice, you only need very few numbers hard-coded. So it might be better to export a function for letting the package user generate the necessary aliases himself. I even think that it is probably sensible to drop the alias thing completely, at least if you have vector lengths in mind. What vector lengths will appear as fixed in a real world program? 1000? I think, usually you have only sizes like 2 or 3 hard-coded, for vectors in the mathematical sense. And their representation is already very short: D2, D3, … Remember that computed numbers are not shown as aliases in error messages, only numbers that directly appear in your code. My co-author also mentioned that he doesn’t see much use for octal and hexadecimal notation. So I propose to drop alias support from type-level or at least let the package user do the necessary generation. […] Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)
On Fri, Mar 14, 2008 at 5:30 PM, Wolfgang Jeltsch [EMAIL PROTECTED] wrote: I have a feedback from my Grapefruit co-developer about those aliases in the type-level package. He told me that on his machine, building this package took about 15 minutes, obviously because the machine ran out of RAM. He also told me that the generated object code was very large, and that loading the documentation page generated by Haddock took very long. Fair point, it akes quite some time in my machine too (not 15minutes though) And he made a very good point: Who needs aliases for *all* numbers until, say, 1? Who needs to hard-code the vector length 8247 in his code? If I remember correctly aliases are generated until decimal 5000, which might me really long anyway. I think that in practice, you only need very few numbers hard-coded. So it might be better to export a function for letting the package user generate the necessary aliases himself. I even think that it is probably sensible to drop the alias thing completely, at least if you have vector lengths in mind. What vector lengths will appear as fixed in a real world program? 1000? I think, usually you have only sizes like 2 or 3 hard-coded, for vectors in the mathematical sense. And their representation is already very short: D2, D3, … Remember that computed numbers are not shown as aliases in error messages, only numbers that directly appear in your code. My co-author also mentioned that he doesn't see much use for octal and hexadecimal notation. So I propose to drop alias support from type-level or at least let the package user do the necessary generation. I think that removing aliases completely is not a good idea. How about generating much lower aliases for decimals (lets say until 1000), droping the other bases, and exporting a function to extended the alias range at will? (that function could perfectly include the other bases as well). Something called extendAliases would do. I don't have the time to work on it now, but if you send me a patch I'd be happy to apply it. It should be something simple to do. All the Template Haskell machinery is already coded. […] Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] File I/O question
On Mar 12, 2008, at 4:07 PM, Andrew Coppin wrote: I'm trying to read the file from Notepad.exe while my Haskell program is still running - which takes about an hour. I'm not a Windows user, but... Is it possible that Notepad tries to write-lock by default (since it's an editor), and fails? Put another way, have you tried other ways of reading the file? Heck, copying the file should be a read-only action. Can you copy it during the runtime, and open the copy? -johnnn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: all threads are blocked by recvFrom
On Fri, Mar 14, 2008 at 8:51 AM, Vitaliy Akimov [EMAIL PROTECTED] wrote: I assume that you're binding the libc function directly here: I'm using Network.Socket. Sory if it's not clear from my previous posts. Then everything should Just Work(tm). You might need to paste in code in order to figure out why this wouldn't be so. See [1] for an example which works for me. It starts a thread which prints working... once a second and, in another thread, listens for UDP packets on port 4112. I can use `nc -u 127.0.0.1 4112` to get this: working... working... (testing\n,8,127.0.0.1:36179) working... working... (testing two\n,12,127.0.0.1:36179) working... [1] http://hpaste.org/6362 -- Adam Langley [EMAIL PROTECTED] http://www.imperialviolet.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Specification for Eq?
Roman Leshchinskiy wrote: Should the report say something like a valid Eq instance must ensure that x == y implies f x == f y for all f? Probably not, since this requires structural equality which is not what you want for ADTs. Should it be for all f which are not part of the implementation of the type? That's a non-requirement if the report doesn't specify what the implementation is. So what should it say? for all exported f (except functions whose names are prefixed with 'unsafe') While not perfect, I think that this is a reasonable specification of observational equality for ADTs. (Whether all Eq instance should behave that way is another question.) Note that if the ADT abstraction would be done via existential types instead of namespace control, we could honestly say for all f. If the representation is stored on the disk, for instance, then it becomes observable, even if it's still hidden in the sense that you can't do anything useful with it other than read it back. The trick here is to blame any observable differences on the nondeterminism of the IO monad serialize :: MyADT - IO String It only guarantees to print out a random representation. Of course, in reality, serialize just prints the internal representation at hand, but we may not know that. As an example, consider the following data type: data Expr = Var String | Lam String Expr | App Expr Expr The most natural notion of equality here is probably equality up to alpha conversion and that's what I usually would expect (==) to mean. In fact, I would be quite surprised if (==) meant structural equality. Should I now consider the Show instance for this type somehow unsafe? I don't see why this makes sense. Most of the time I probably don't even want to make this type abstract. Are the constructors also unsafe? Why? Thanks for throwing in an example :) And a good one at that. So, alpha-equivalence is a natural Eq instance, but not an observational equivalence. Are there other such good examples? On the other hand, I'm not sure whether the Prelude functions like nub make sense / are that useful for alpha-equivalence. Furthermore, Expr is not an Ord instance. (Of course, one could argue that Var String is the wrong way or a very unsafe way to implement stuff with names. For instance, name generation needs a monad. There are alternatives like De Bruijn indices and even representations based on parametric polymorphism. But I think that this doesn't touch the issue of alpha-conversion being a natural Eq instance.) Regards, apfelmus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: all threads are blocked by recvFrom
On Fri, Mar 14, 2008 at 10:13 AM, Adam Langley [EMAIL PROTECTED] wrote: See [1] for an example which works for me. (If you're on Windows, you probably need to wrap main in withSocketsDo) AGL -- Adam Langley [EMAIL PROTECTED] http://www.imperialviolet.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Space leak - help needed
On Thu, Mar 13, 2008 at 4:50 PM, Krzysztof Kościuszkiewicz
[EMAIL PROTECTED] wrote:
Retainers are thunks or objects on stack that keep references to
live objects. All retainers of an object are called the object's
retainer set. Now when one makes a profiling run, say with ./jobname
+RTS -p -hr, the graph refernces retainer sets from jobname.prof. My
understanding is that it is the total size of all objects retained by
retainer sets being plotted, correct?
Yes, all retainer sets are being profiled. However, you can FILTER the
retainer sets profiled to those containing certain cost-centres. This
is a key point because it allows you to divide-and-conquer when
tracking down a retainer leak. That is, if you filter to a certain
cost-centre and the retainer graph is flat, you know that cost-centre
is not involved. For example, if you have a cost-centre annotation
like {-# SCC leaky #-} in your code, you can filter the retainer set
like this:
Leaky.exe +RTS -hr -hCleaky -RTS
Review the documentation for other options.
About decoding the sets from jobname.prof - for example in
SET 2 = {MAIN.SYSTEM}
SET 16 = {Main.CAF, MAIN.SYSTEM}
SET 18 = {MAIN.SYSTEM, Main.many1,Main.list,Main.expr,Main.CAF}
{...} means it's a set, and ccN,...,cc0 is the retainer cost centre
(ccN) and hierarchy of parent cost centres up to the top level (cc0)?
My understanding is that SET 18 above refers to objects that are
retained by exactly two specified cost centres, right?
The docs say
An object B retains object A if (i) B is a retainer object and (ii)
object A can be reached by recursively following pointers starting
from object B, but not meeting any other retainer objects on the way.
Each live object is retained by one or more retainer objects,
collectively called its retainer set ...
That says to me that SET18 above is the set of all objects which are
retained by those two call stacks, and only those call stacks. The
individual .. items aren't call stacks but I think they refer to
where the retaining object (B in the paragraph) was itself retained,
so they are like call stacks. My intuition is very fuzzy here.
Finally, what is the MAIN.SYSTEM retainer?
I think that is everything else - any object created in the runtime
system that is not directly attributable to something being profiled.
Maybe it is objects from libraries that were not compiled with
profiling? I imagine objects created by the GHC primitives would fall
in this category too.
Since someone else found your space leak, does the retainer profiling
advice point to it? I'd like to know if it is actually accurate or
not! I've only applied it in some very limited situations.
Justin
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] File I/O question
John Melesky wrote: On Mar 12, 2008, at 4:07 PM, Andrew Coppin wrote: I'm trying to read the file from Notepad.exe while my Haskell program is still running - which takes about an hour. I'm not a Windows user, but... Is it possible that Notepad tries to write-lock by default (since it's an editor), and fails? Notepad successfully opens the log file of another script I'm running, so that's not the issue. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Type system
Haskell has an expressive and powerful type system - which I love. It also has a seemingly endless list of weird and obscure type system extensions. And there are various things you can do in Haskell which *require* some pretty serious type system hackery. And yet, none of this happens in any other programming language I've met. Take Java for example. In Java, a type is just an identifier. It has no further structure than that. It does have the added semantics that it refers to that class *or any subclass*, but that's about it. Even taking an extreme example like Eiffel [which supports generics], complex types are extremely rare. And yet they commonly pop up in Haskell. Can anybody put their finger on precisely why that is? Is it because Haskell is used by more PhDs? Is it because Haskell actually allows you to implement constructs that are impossible in other languages? Is it because Haskell really provides greater type safety? Is it something else? Not trying to suggest that either system is superior, I'm just curios as to the origin of the difference... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ackermann Function Memoization, GHC Weird Output or Bug?
Hello,
It seems this bug has already been submitted:
http://hackage.haskell.org/trac/ghc/ticket/2120
Thanks for the help.
__
Donnie Jones
On 3/14/08, Cale Gibbard [EMAIL PROTECTED] wrote:
Here's the bug:
{-# INLINE safeIndex #-}
safeIndex :: Ix i = (i, i) - Int - i - Int
safeIndex (l,u) n i = let i' = unsafeIndex (l,u) i
in if (0 = i') (i' n)
then i'
else error Error in array index
unsafeIndex here is just a function which transforms indices into Int
indices into the flat array and does no checking of validity. Then
safeIndex simply checks if the result is nonnegative and less than the
size of the array. Whoops! The actual test to see if the index was
valid in the first place didn't actually get performed!
- Cale
On 14/03/2008, Eric Mertens [EMAIL PROTECTED] wrote:
Smaller example of this behavior:
array ((0,0),(1,1)) [((1,1),6)] ! (0,3)
6
--
Eric Mertens
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Gtk2hs
Just a short one... gtk2hs won't build on my [Linux] laptop. What's the best channel for seeking help with this? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Gtk2hs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew Coppin wrote: | Just a short one... gtk2hs won't build on my [Linux] laptop. What's the | best channel for seeking help with this? The #haskell (on freenode) isn't bad. You'll probably get help pretty quick here, it's known to be very user friendly. The subset #gentoo-haskell is good too, especially if you're using Gentoo Linux. You'll find both me and one of the gkt2hs maintainers (dcoutts) in both channels. Gtk2Hs also has mailing lists, see http://www.haskell.org/gtk2hs/development/ Note that there is pretty much the same people you're talking to no matter which method you pick :) Or... we can just continue here.. Which version of ghc and gtk2hs? Did you get an error message? Cheers, ~ Lennart Kolmodin -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH2uAT4txYG4KUCuERAjCrAKCC4HMw0b5vuhLxKhm5jyUIIB8ybACdFenO EqXbl/H8xpdjqMDimfbgpes= =5Du+ -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type system
On Fri, Mar 14, 2008 at 2:50 PM, Andrew Coppin [EMAIL PROTECTED] wrote: Haskell has an expressive and powerful type system - which I love. It also has a seemingly endless list of weird and obscure type system extensions. And there are various things you can do in Haskell which *require* some pretty serious type system hackery. Well, there wouldn't be much point to a type system extension if you could do just as well without it. And yet they commonly pop up in Haskell. Can anybody put their finger on precisely why that is? It's because Haskell is, among other things, a research language. Part of its stated purpose is providing a basis for experimenting with type systems and implementation strategies and so forth. When Haskell 98 was written, higher-ranked polymorphism wasn't considered practical, and no one had invented multi-parameter type classes yet. Even type classes started out as an experiment, and then they were extended to constructor classes (e.g., classes like Monad where the parameter is a type constructor, not a ground type). Eventually, the most successful extensions will be rolled into the next Haskell standard. The same thing happens in Java. Generics (what we call type constructors) were available in various extended Javas before being added to the main standard. The Haskell process is just a lot slower because we're doing things very few have done before. -- Dave Menendez [EMAIL PROTECTED] http://www.eyrie.org/~zednenem/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)
Am Freitag, 14. März 2008 17:46 schrieben Sie: […] I think that removing aliases completely is not a good idea. How about generating much lower aliases for decimals (lets say until 1000), I don’t think, this is a good idea. Like nobody will need an alias for 8247, nobody will need an alias for 824. The main point is that it is unnecessary to have a continuous range of numbers for which aliases exist. If you need aliases, you need them for “outstanding” values. Maybe you need aliases for all powers of 2 up to a certain number. Or aliases for all square numbers. Therefore I think that if we want aliases then we should let the user and only the user generate them. This has also the interesting consequence that the type-level package doesn’t need the Template Haskell language extension anymore. After all, using the template-haskell package doesn’t imply that you have to have a TH-enabled compiler, as far as I know. droping the other bases, That’s a good idea. and exporting a function to extended the alias range at will? I’d rather propose something like this: $(numAliasDecls [2 ^ n | n - 0..16]) So that numAliasDecls has a type like [Int] - [Decl]. (that function could perfectly include the other bases as well). Maybe. […] I don't have the time to work on it now, but if you send me a patch I'd be happy to apply it. It should be something simple to do. All the Template Haskell machinery is already coded. Okay, I could send you a patch realizing my above ideas but would like to hear your opinion first. […] Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Gtk2hs
Don Stewart wrote: andrewcoppin: Just a short one... gtk2hs won't build on my [Linux] laptop. What's the best channel for seeking help with this? Discuss it on the gtk2hs list, with a full error log. Thanks. I'll go look at that. (Who knows, maybe somebody already solved this one...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] thanks for your feedback concerning tech documentation.
Thanks. I was encouraged by this response I got. I'm ready to go. Since I'm trapped in the space-time continuum like most people, I can't do it all at once. I would like to. Anything that supports haskell is okay by me. My first area of interest is HAppS. I wrote some e-mail to them yesterday, but have yet to hear anything. Should I belt out some e-mail to specific people? By the looks of things, the traffic on that list is pretty slow right now. Michael Litchard ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type system
On Fri, Mar 14, 2008 at 11:50 AM, Andrew Coppin [EMAIL PROTECTED] wrote: Haskell has an expressive and powerful type system - which I love. It also has a seemingly endless list of weird and obscure type system extensions...And yet, none of this happens in any other programming language I've met. Have you ever programmed in C++? Many of the exotic things that can be done in the Haskell type system can also be carried out in the C++ type system - ranging from factoring integers at compile time to implementing highly optimised array and matrix DSLs. The difference between C++ and Haskell is that in C++ these techniques are highly ad hoc. In the Haskell world people are a lot more conservative and so only allow type system shenanigans if they are supported by some theory that allows us to reason nicely about them. As a side effect, each type system extension is relatively small and controlled. So when you see lots of Haskell type system extensions it looks like a big complicated system, but that's just an illusion that results from it being broken down into reasonable pieces. Read some of the source code for the Boost C++ template libraries (especially the template metaprogramming library) to see how complex the C++ type system really is. -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type system
dpiponi: On Fri, Mar 14, 2008 at 11:50 AM, Andrew Coppin [EMAIL PROTECTED] wrote: Haskell has an expressive and powerful type system - which I love. It also has a seemingly endless list of weird and obscure type system extensions...And yet, none of this happens in any other programming language I've met. Have you ever programmed in C++? Many of the exotic things that can be done in the Haskell type system can also be carried out in the C++ type system - ranging from factoring integers at compile time to implementing highly optimised array and matrix DSLs. The difference between C++ and Haskell is that in C++ these techniques are highly ad hoc. In the Haskell world people are a lot more conservative and so only allow type system shenanigans if they are supported by some theory that allows us to reason nicely about them. As a side effect, each type system extension is relatively small and controlled. So when you see lots of Haskell type system extensions it looks like a big complicated system, but that's just an illusion that results from it being broken down into reasonable pieces. Read some of the source code for the Boost C++ template libraries (especially the template metaprogramming library) to see how complex the C++ type system really is. As Manuel says, in C++ type level programming was an accident, in Haskell, it was by design. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: (flawed?) benchmark : sort
On 2008-03-14, Conor McBride [EMAIL PROTECTED] wrote: Hi On 13 Mar 2008, at 23:33, Aaron Denney wrote: On 2008-03-13, Conor McBride [EMAIL PROTECTED] wrote: For a suitable notion of = on quotients, and with a suitable abstraction barrier at least morally in place, is that really too much to ask? I really think it is. I don't think the case of equivalent for this purpose, but not that purpose can be ignored. Sure. But use the right tools for the job. So what are the right tools then? Why is a typeclass not the right tool? Now, it may be the case that fooBy functions are then the right thing, but it's not clear to me at all that this is true. And if the fooBy option works, then why would the foo option fail for equivalence classes? It seems reasonable to construct quotients from arbitrary equivalences: if fooBy works for the carrier, foo should work for the quotient. Of course, if you want to expose the representation for some other legitimate purpose, then it wasn't equality you were interested in, so you should call it something else. I'm perfectly happy calling it Equivalence. -- what should a sort algorithm do in such a situation? Not care. Produce a resulting list where for any [..., x, ..., y, ...] in the result, y = x implies x = y. Vacuously satisfied in the case of incomparable elements. In the case of a total order, that gives you y = x implies x = y (and everything in between), but for a preorder, you put less in, you get less out. That's a workable definition, but I don't know if I'd call it a sort, precisely. The standard unix tool tsort (for topological sort, a bit of a misnomer) does this. Will that do? Unfortunately, one can't just reuse the standard algorithms. One might think that one could reuse any standard algorithm by munging the comparison so that incomparable gets mapped to equivalent, but the following two chains shows that's not possible: a - b - c - d a - e - d Instead, it seems that one has to use actual graph algorithms, which are both more complicated to reason about, and have worse performance. If a sort can't support the standard sort on this key technique, and don't munge everything for two keys that compare equal, something is wrong. And I don't think sort is that special a case. Instances, rather than explicit functions, are nice because they let us use the type system to ensure that we never have incompatible functions used when combining two data structures, or pass in a function that's incompatible with the invariants already in a data structure built with another function. So we surely do need an equivalence relation typeclass. And there are Eq instances that aren't quite equality, but are equivalences, and work with almost all code that takes Eq instances. The only time treating equalities as equivalences won't work is when we need to coalesce equivalent elements into one representative, and the choice of representative matters. (If it doesn't matter, we can just pick arbitrarily). If it does matter, a simple biasing scheme usually isn't going to be sufficient -- we really do need a coalescing function. So, do we mark equivalencies as special, or observational equality as special? Which is the tagging class, and which has the methods? I think it's pretty clear that the way to go is have (==) and (/=) live in Equiv, and have Equal be a tagging class. An equivalence is not a special type of equality, but equality is a special type of equivalence. Given all that, I think current Eq as Equivalence makes sense, and we need to add an Equal class for things where we truly can't tell equivalent elements apart. -- Aaron Denney -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Type system
Andrew Coppin wrote: Haskell has an expressive and powerful type system - which I love. It also has a seemingly endless list of weird and obscure type system extensions. And there are various things you can do in Haskell which *require* some pretty serious type system hackery. And yet, none of this happens in any other programming language I've met. Take Java for example. In Java, a type is just an identifier. It has no further structure than that. It does have the added semantics that it refers to that class *or any subclass*, but that's about it. Even taking an extreme example like Eiffel [which supports generics], complex types are extremely rare. And yet they commonly pop up in Haskell. Can anybody put their finger on precisely why that is? I think this is at least partly because Haskell takes being a (typed) functional language very serious. With OO languages, such as Java or Eiffel, you can swipe a lot of the complexity under the stateful object carpet. Functional programs explicitly operate on values, however complex their types may be... and thus themselves become values with even more complex types... I found this paper http://www.eecs.usma.edu/webs/people/okasaki/pubs.html#jfp98 quite illuminating (it uses SML, not Haskell, which rather confirms my point). Cheers Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type system
Am Freitag, 14. März 2008 19:50 schrieb Andrew Coppin: […] Is it because Haskell is used by more PhDs? Is it because Haskell actually allows you to implement constructs that are impossible in other languages? Is it because Haskell really provides greater type safety? Is it something else? Haskell’s type system gives you greater type safety, i.e., it allows to statically check certain properties which cannot be statically checked in other languages. It also improves code reuse in certain cases. For example, the Control.Monad module works for all monads (lists, I/O actions, etc.) which is only possible because of constructor classes, at least, if you don’t want to introduce dynamic typing. […] Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: (flawed?) benchmark : sort
On 2008-03-14, Robert Dockins [EMAIL PROTECTED] wrote: Blah, blah, blah, its all in the documentation. The point is that making loose assumptions about the meaning of the operations provided by Eq and Ord complicates things in ways that can't be made to go away. Thanks. All of these seem to me to be a case of Well, it's arbitrary, so we don't guarantee anything but that we did something consistent. Which seems perfectly reasonable, and not a problem at all. -- Aaron Denney -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Type system
Don Stewart wrote: As Manuel says, in C++ type level programming was an accident, in Haskell, it was by design. Was it, really? I was laways under teh impression that Oleg-style type system tricks were not in the least anticipated back when Haskell acquired type classes... Cheers Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: (flawed?) benchmark : sort
On 2008-03-10, Dan Weston [EMAIL PROTECTED] wrote: However, the report text is normative: 6.3.2 (The Ord Class): The Ord class is used for totally ordered datatypes. This *requires* that it be absolutely impossible in valid code to distinguish equivalent (in the EQ sense, not the == sense) things via the functions of Ord. The intended interpretation of these functions is clear and can be taken as normative: forall f . (compare x y == EQ and (f x or f y is defined)) == f x == f y) That depends a great deal on your definitions. Is the (=) in the set theory structure equality, or is it merely a binary relation with the appropriate properties? If we take the result of the compare function being EQ to mean structural equality, that throws out the possibility of even safe semantic equality, and no interesting data structures can be made instances of Ord. That's less than useful. Certainly, for the domain of /just the ordering comparisons/, yes, equal elements are equal, and cannot be distinguished, but that just means cannot be distinguished by the provided binary relations. -- Aaron Denney -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Type system
No, Haskell wasn't designed with type level programming in mind. In fact it took a few years before any serious type level programming was done. And lo and behold, the type level has an untyped logic language. -- Lennart On Fri, Mar 14, 2008 at 9:41 PM, Ben Franksen [EMAIL PROTECTED] wrote: Don Stewart wrote: As Manuel says, in C++ type level programming was an accident, in Haskell, it was by design. Was it, really? I was laways under teh impression that Oleg-style type system tricks were not in the least anticipated back when Haskell acquired type classes... Cheers Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type system
Hi Andrew, Andrew Coppin wrote: Haskell has an expressive and powerful type system - which I love. It also has a seemingly endless list of weird and obscure type system extensions. And there are various things you can do in Haskell which *require* some pretty serious type system hackery. And yet, none of this happens in any other programming language I've met. Take Java for example. In Java, a type is just an identifier. It has no further structure than that. It does have the added semantics that it refers to that class *or any subclass*, but that's about it. Even taking an extreme example like Eiffel [which supports generics], complex types are extremely rare. There are a lot of Java extensions in various directions (Multimethods, Mixins, Virtual Classes, Aspects, Effect Typing). Some extensions have been included into the official Java Language (Anonymous Classes, Generics). Other extensions have lead to the creation of new languages different from, but related to Java (Scala). A lot of research teams, both academic and industrial, are working on new extensions of the Java Language. Such extensions may come as libraries, preprocessors or compilers, they may reuse, extend or substitute the run time system. From my limited view, the Java research community seems to be bigger then the Haskell research community. But I may be wrong here, and the meaning of a big community isn't clear at all, so that's not the point. Clearly, Haskell feels like a research language, and Haskell hacking is like pushing the border into unexplored territory, while Java feels like a lot of boilerplate without actual content, and Java development is like taking care of paperwork. Why is this the case? I see four reasons all working together: First, Java is designed for the software industry, while Haskell avoids success at all cost. This means that we have 90% research people working with Haskell, and 0.01% research people working with Java, *even if there are more Java researchers as Haskell researchers*. It's the absence of non-researchers which makes Haskell a research language, not the abundance of researchers. Second, Java extensions tend to be incompatible with each other, since they typically consist of an modified compiler, while Haskell extensions tend to get integrated into GHC or lost forever. With GHC as de-facto standard compiler, we have a number of extensions available for every productive Haskell system. Third, the theoretical base of pure functional languages is relatively clear and easy to understand, while the theoretical base of imperative object-oriented languages is still widely unexplored and hard to grasp. This means that formal, scientific papers about Haskell are more likely to be user-understandable then formal, scientific papers about Java. Ever seen one of the formal calculi proposed as semantic core of the Java language? Fourth, Haskell is just better. (Had to include this one to avoid being victim to a flame war). But hey, it is my personal opinion too. Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Type system
Yeah, I should clarify, this quote came up in relation to ATs, which are designed speifically to make type programming easier (unlike MPTCs and FDs, where it was an Olegian accident) lennart: No, Haskell wasn't designed with type level programming in mind. In fact it took a few years before any serious type level programming was done. And lo and behold, the type level has an untyped logic language. -- Lennart On Fri, Mar 14, 2008 at 9:41 PM, Ben Franksen [EMAIL PROTECTED] wrote: Don Stewart wrote: As Manuel says, in C++ type level programming was an accident, in Haskell, it was by design. Was it, really? I was laways under teh impression that Oleg-style type system tricks were not in the least anticipated back when Haskell acquired type classes... Cheers Ben ___ Haskell-Cafe mailing list [EMAIL PROTECTED] [3]http://www.haskell.org/mailman/listinfo/haskell-cafe References Visible links 1. mailto:[EMAIL PROTECTED] 2. mailto:Haskell-Cafe@haskell.org 3. http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: (flawed?) benchmark : sort
Note that even if you wanted Eq to mean observational equality, you
still can't perform that kind of reordering or 'sort' optimizations
without running into trouble. for a not contrived at all example:
data Id = Id { idIdent :: Int, idFreeVarCache :: [Id] }
instance Eq Id where
x == y = idIdent x == idIdent y
now, this type represents an identifier in a language that is annotated
with the free variables it contains. Note that the Eq instance really
does declare observational equality here, the free var cache is only a
copy of what is in the definition of the Id. now consider the id for the
simple
v1 = v1
all of the following are observationally the same
x = Id 1 [x]
x = Id 1 [Id 1 [x]]
x = Id 1 [Id 1 [Id 1 [Id 1 ...
now, this is just fine, there is no way for a program to tell the
difference between them, but the difference is very important! the
second wastes space and the third is an honest to goodness space leak.
One has to rely on the fact Set.insert really replaces its element, max
x y where x == y is always y and other such things to reasonably reason
about the space usage of haskell programs, something that is hard enough
as it is without basics like 'sort' trying to be clever.
So, even if a == b always meant observational equality, specifying bias
is still very important. Even if you document it as 'unspecified' that
is fine (though it limits the use of said library), but it is part of
the API.
For the record I also always thought of 'Eq' as an arbitrary equality
relationship and 'Ord' as a compatible total ordering. It is not even
clear whether structural equality is meaningful for a lot of types, even
though they might have a 'natural' equality relationship.
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] deconstruction of the list/backtracking applicative functor?
Is there a known deconstruction of the list/backtracking applicative functor (AF)? If I decompose the list type into pieces (Maybe, product, composition), I think I can see where the ZipList AF comes from, but not the list/backtracking AF. Is there some construction simpler than lists (non-recursive) that introduces cross products? Thanks, - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HFuse: ls fails in HelloFS
Excerpts from Georg Neis's message of Fri Mar 14 06:38:02 -0500 2008: Hello, I've installed the HFuse package from hackage and am playing with the HelloFS example in the System/Posix/HFuse directory. As far as I know, the package uploaded onto hackage is merely a cabal-ised version of the old(er) HFuse which I don't believe has been maintained in quite a while. The only recent work I know of on the project is that of Will Thompsons'. A darcs repository can be located here: http://www.willthompson.co.uk/darcs/hfuse/ I've tested it on 6.8 and it works fine (Will has 6.6 I believe,) and the HelloFS example should work, but it is still under development (notably I believe him mentioning that the BindFS example has a deadlock issue at the moment.) Testing out that version might yield better results. I would recommend contacting him on the matter, since he seems to be the only person in this project currently. Sorry I couldn't have been more help. -- It was in the days of the rains that their prayers went up, not from the fingering of knotted prayer cords or the spinning of prayer wheels, but from the great pray-machine in the monastery of Ratri, goddess of the Night. Roger Zelazny ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
