[GHC] #844: panic on conflicting patterns in TH splice
#844: panic on conflicting patterns in TH splice
-+--
Reporter: guest |Owner:
Type: bug | Status: new
Priority: normal|Milestone:
Component: Template Haskell | Version: 6.4.2
Severity: minor | Keywords:
Os: Unknown | Difficulty: Unknown
Architecture: Unknown |
-+--
The definition
{{{
g c c = undefined
}}}
gives a nice error message:
Conflicting definitions for `c'
In the definition of `g'
.
However, when trying to splice in the analogous function
{{{
foo = sequence
[
funD (mkName f)
[
clause
[varP $ mkName c,varP $ mkName c]
(normalB $ [| undefined |])
[]
]
]
}}}, the compiler panics:
ghc-6.4.2: panic! (the `impossible' happened, GHC version 6.4.2):
SrcLoc.srcSpanStartLine
. It would be nice if ghc gave an error message just like the non-TH case.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/844
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: [GHC] #840: GHC on loosing its handles takes 100% CPU
It happens all the time to me that GHC doesn't die properly on windows. Every so often I have to kill a few straggling ghc processes. They all spin consuming 100% CPU when this happens. -- Lennart On Aug 2, 2006, at 10:09 , Bulat Ziganshin wrote: Hello GHC, Wednesday, August 2, 2006, 4:33:09 PM, you wrote: #840: GHC on loosing its handles takes 100% CPU import System.Process main = runInteractiveCommand ghc When run terminates immediately, as expected, but leaves an instance of ghc running. The ghc process takes up 100% of the CPU time, and seemingly does nothing. well, i have similar problem: there are only 256 megs on my machine and sometimes when ghc compilation uses more than 200 megs and starts trashing memory, i tries to stop it by hitting Ctrl-C. in this situation it's rather typical that i got back my console (and rerun ghc) but old GHC process don't killed and continue to compile program. i can investigate it further but don't know what to do. at least it seems that memory trashing is required to uncover this problem. i also should note that i run ghc --make from the .cmd file so there is a whole stack of processes runned. may be i just kill higher-level ghc (or even cmd) and lower-level ghc still continue to do it's job? i'm not sure.. -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #844: panic on conflicting patterns in TH splice
#844: panic on conflicting patterns in TH splice
---+
Reporter: guest | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: Template Haskell |Version: 6.4.2
Severity: minor | Resolution:
Keywords:| Os: Unknown
Difficulty: Unknown | Architecture: Unknown
---+
Comment (by guest):
{{{
foo = sequence
[
funD (mkName f)
[
clause
[varP $ mkName c,varP $ mkName c]
(normalB $ [| undefined |])
[]
]
]
}}}, the compiler panics:
ghc-6.4.2: panic! (the `impossible' happened, GHC version 6.4.2):
SrcLoc.srcSpanStartLine
. It would be nice if ghc gave an error message just like the non-TH case.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/844
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: [GHC] #844: panic on conflicting patterns in TH splice
#844: panic on conflicting patterns in TH splice
---+
Reporter: guest | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: Template Haskell |Version: 6.4.2
Severity: minor | Resolution:
Keywords:| Os: Unknown
Difficulty: Unknown | Architecture: Unknown
---+
Comment (by guest):
(continued)
{{{
foo = sequence
[
funD (mkName f)
[
clause
[varP $ mkName c,varP $ mkName c]
(normalB $ [| undefined |])
[]
]
]
}}}
, the compiler panics:
ghc-6.4.2: panic! (the `impossible' happened, GHC version 6.4.2):
SrcLoc.srcSpanStartLine
. It would be nice if ghc gave an error message just like the non-TH case.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/844
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: [GHC] #840: GHC on loosing its handles takes 100% CPU
I'm not doubting that it's genuine -- but can anyone make a reproducible test case? Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of Lennart Augustsson | Sent: 04 August 2006 13:47 | To: Bulat Ziganshin | Cc: GHC; glasgow-haskell-bugs@haskell.org | Subject: Re: [GHC] #840: GHC on loosing its handles takes 100% CPU | | It happens all the time to me that GHC doesn't die properly on windows. | Every so often I have to kill a few straggling ghc processes. They | all spin consuming 100% CPU when this happens. | | -- Lennart | | On Aug 2, 2006, at 10:09 , Bulat Ziganshin wrote: | | Hello GHC, | | Wednesday, August 2, 2006, 4:33:09 PM, you wrote: | | #840: GHC on loosing its handles takes 100% CPU | | import System.Process | main = runInteractiveCommand ghc | | When run terminates immediately, as expected, but leaves an instance | of ghc running. The ghc process takes up 100% of the CPU time, and | seemingly does nothing. | | well, i have similar problem: there are only 256 megs on my machine | and sometimes when ghc compilation uses more than 200 megs and starts | trashing memory, i tries to stop it by hitting Ctrl-C. in this | situation it's rather typical that i got back my console (and rerun | ghc) but old GHC process don't killed and continue to compile program. | i can investigate it further but don't know what to do. at least it | seems that memory trashing is required to uncover this problem. i also | should note that i run ghc --make from the .cmd file so there is a | whole stack of processes runned. may be i just kill higher-level ghc | (or even cmd) and lower-level ghc still continue to do it's job? i'm | not sure.. | | -- | Best regards, | Bulatmailto:[EMAIL PROTECTED] | | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs | | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #840: GHC on loosing its handles takes 100% CPU
But as long as it's Haskell code consuming all those CPU cycles, it can't be all bad? :) If any of you are running into this while invoking ghci.exe, you may want to play with using ghc.exe --interactive instead to see if that improves matters. Not using ghci.exe avoids a layer of sub-process'ery and console event handling nonsense; a culprit, perhaps? --sigbjorn - Original Message - From: Lennart Augustsson [EMAIL PROTECTED] To: Bulat Ziganshin [EMAIL PROTECTED] Cc: GHC [EMAIL PROTECTED]; glasgow-haskell-bugs@haskell.org Sent: Friday, August 04, 2006 05:46 Subject: Re: [GHC] #840: GHC on loosing its handles takes 100% CPU It happens all the time to me that GHC doesn't die properly on windows. Every so often I have to kill a few straggling ghc processes. They all spin consuming 100% CPU when this happens. -- Lennart On Aug 2, 2006, at 10:09 , Bulat Ziganshin wrote: Hello GHC, Wednesday, August 2, 2006, 4:33:09 PM, you wrote: #840: GHC on loosing its handles takes 100% CPU import System.Process main = runInteractiveCommand ghc When run terminates immediately, as expected, but leaves an instance of ghc running. The ghc process takes up 100% of the CPU time, and seemingly does nothing. well, i have similar problem: there are only 256 megs on my machine and sometimes when ghc compilation uses more than 200 megs and starts trashing memory, i tries to stop it by hitting Ctrl-C. in this situation it's rather typical that i got back my console (and rerun ghc) but old GHC process don't killed and continue to compile program. i can investigate it further but don't know what to do. at least it seems that memory trashing is required to uncover this problem. i also should note that i run ghc --make from the .cmd file so there is a whole stack of processes runned. may be i just kill higher-level ghc (or even cmd) and lower-level ghc still continue to do it's job? i'm not sure.. -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #845: irrefutable pattern matching on unboxed tuple causes panic
#845: irrefutable pattern matching on unboxed tuple causes panic --+- Reporter: Jason McCarty [EMAIL PROTECTED] |Owner: Type: bug| Status: new Priority: normal |Milestone: Component: Compiler | Version: 6.4.2 Severity: normal | Keywords: Os: Linux | Difficulty: Unknown Architecture: x86| --+- Compiling the following program with -fglasgow-exts main = case (# (), () #) of ~(# _, _ #) - return () causes GHC to fail with the message ghc-6.4.2: panic! (the `impossible' happened, GHC version 6.4.2): dsLExpr: tuple pattern: return @ () GHC.Base.() The equivalent (I think) expression main = let (# _, _ #) = (# (), () #) in return () compiles without complaint. This is GHC version 6.4.2 on i386 Debian with a 2.6.17.6 Linux kernel. I didn't test with any other unboxed types. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/845 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: [GHC] #821: implicit parameters and type synonyms
#821: implicit parameters and type synonyms -+-- Reporter: [EMAIL PROTECTED] | Owner: Type: support request | Status: closed Priority: normal | Milestone: Component: Compiler|Version: 6.5 Severity: normal | Resolution: fixed Keywords: | Os: Unknown Difficulty: Unknown | Architecture: Unknown -+-- Changes (by simonpj): * resolution: = fixed * status: new = closed Comment: Thanks for a useful report. It alerted me to a shortcoming in our boxy type inference paper (on my home page). GHC now supports impredicative polymorphism, but that had inadvertently made things worse here, as you pointed out. Fortunately, it was easily fixed, by using pre-subsumption in the main subsumption check as well as in smart-app. We'd missed that before. Test tc205 checks this case now. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/821 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: GHC 6.4.3 is stalled
I just realised I sent the following only to [EMAIL PROTECTED], not glasgow-hasell-users: Simon Marlow wrote: Just a quick note to say thanks for all the offers of help on 6.4.3 - it's very encouraging to see so many people willing to offer their time and machines. The state of play so far: On FreeBSD, reports suggest that there's are one or possibly two problems exposed by the threaded RTS. The timeout program in the testsuite sometimes hangs, and GHC itself may hang when linked against the threaded RTS. This looks like a tricky one, so I'm going to try to look into it myself. I've installed FreeBSD 6.1 on an old laptop and I'm currently building 6.4.2 on it. On MacOS X / PPC, we have a crashing stage2 when linked against the threaded RTS. Gregory Wright is trying to reproduce the problem on a smaller scale (with something other than GHC). The timeout hanging problem apparently happens on MacOS X/Intel too (according to Joel Reymont). If I find the cause on FreeBSD, we can test the fix on MacOS X/Intel. I have an update on FreeBSD. I built the CVS 6.4 branch on a fresh install of FreeBSD, and ran the testsuite: OVERALL SUMMARY for test run started at Thu 3 Aug 2006 09:42:30 BST 1365 total tests, which gave rise to 4157 test cases, of which 0 caused framework failures 583 were skipped 3505 expected passes 46 expected failures 2 unexpected passes 21 unexpected failures Unexpected passes: cholewo-eval(optasm) ffi009(optasm) Unexpected failures: arith011(opt) barton-mangler-bug(normal,opt,ghci,threaded) cabal01(normal) galois_raytrace(ghci) ioref001(normal,threaded) joao-circular(normal,opt,optasm,threaded) newtype(opt) queryfdoption01(normal,opt,optasm,threaded) rn.prog006(normal) seward-space-leak(ghci) signals002(threaded) Some of those failures are probably due to running out of memory on this laptop (which only has 128M + 256M swap, I should have given it more swap). But I don't see any evidence of hanging timeout processes and stage2 apparently works fine. That means the problem only shows up on a dual proc/dual core (Gregory reported seeing this on a dual proc build of FreeBSD). Greg - can you give me SSH access to your box, and I'll take a look? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4.3 is stalled
Hi Simon, I'll set up ssh access to a dual processor FreeBSD box. It should be ready by later today (I'll send a note). Best, Greg On Aug 4, 2006, at 8:08 AM, Simon Marlow wrote: I just realised I sent the following only to [EMAIL PROTECTED], not glasgow-hasell-users: Simon Marlow wrote: Just a quick note to say thanks for all the offers of help on 6.4.3 - it's very encouraging to see so many people willing to offer their time and machines. The state of play so far: On FreeBSD, reports suggest that there's are one or possibly two problems exposed by the threaded RTS. The timeout program in the testsuite sometimes hangs, and GHC itself may hang when linked against the threaded RTS. This looks like a tricky one, so I'm going to try to look into it myself. I've installed FreeBSD 6.1 on an old laptop and I'm currently building 6.4.2 on it. On MacOS X / PPC, we have a crashing stage2 when linked against the threaded RTS. Gregory Wright is trying to reproduce the problem on a smaller scale (with something other than GHC). The timeout hanging problem apparently happens on MacOS X/Intel too (according to Joel Reymont). If I find the cause on FreeBSD, we can test the fix on MacOS X/Intel. I have an update on FreeBSD. I built the CVS 6.4 branch on a fresh install of FreeBSD, and ran the testsuite: OVERALL SUMMARY for test run started at Thu 3 Aug 2006 09:42:30 BST 1365 total tests, which gave rise to 4157 test cases, of which 0 caused framework failures 583 were skipped 3505 expected passes 46 expected failures 2 unexpected passes 21 unexpected failures Unexpected passes: cholewo-eval(optasm) ffi009(optasm) Unexpected failures: arith011(opt) barton-mangler-bug(normal,opt,ghci,threaded) cabal01(normal) galois_raytrace(ghci) ioref001(normal,threaded) joao-circular(normal,opt,optasm,threaded) newtype(opt) queryfdoption01(normal,opt,optasm,threaded) rn.prog006(normal) seward-space-leak(ghci) signals002(threaded) Some of those failures are probably due to running out of memory on this laptop (which only has 128M + 256M swap, I should have given it more swap). But I don't see any evidence of hanging timeout processes and stage2 apparently works fine. That means the problem only shows up on a dual proc/dual core (Gregory reported seeing this on a dual proc build of FreeBSD). Greg - can you give me SSH access to your box, and I'll take a look? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] thread-local variables
As for the subject under discussion (thread local state), I am personally sceptical about it. Why do we need it? Are we talking about safety or just convenience/API elegance? I've never encountered a situation where I've needed thread local state, (but this does not necessarily make it evil:-) OK. What if all Haskell processes, all over the world, were made into threads in the same large process? There are a lot of things that are currently global state - as in, process-global - which would have to become non-global in some way - pretty much all interaction with the world: file IO, networking, command line arguments, system environment, etc. You, Einar, and others seem to be arguing that the only way to make these things non-global should be to either make them explicit arguments to functions, or to have them appear explicitly in the type of the application's primary monad. For instance, this simple program: main :: IO () main = do putStrLn Hello world might, in Adrian Hey and Einar Karttunen's world, become: newMain host environment program_args network_config locale terminal_settings stdin stdout stderr = do hPutStrLn stdout (defaultEncoding locale) Hello world Now, some people might find this second version delightfully explicit, but I'd have doubts about whether such people are actually trying to get things done, or whether they see the language as an end in itself. As for me, I prefer the first version - it saves reading and typing, and is perfectly clear, and I have work to do. Maybe I'm misunderstanding your position - maybe you think that I should use lots of different processes to segregate global state into separate contexts? Well, that's nice, but I'd rather not. For instance, I'm writing a server - and it's just not efficient to use a separate process for each request. And there are some things such as database connections, current user id, log files, various profiling data, etc., that I would like to be thread-global but not process-global. Or maybe you think that certain types of global state should be privileged - for instance, that all of the things which are arguments to 'newMain' above are OK to have as global state, but that anything else should be passed as function arguments, thus making thread-localization moot. I disagree with this - I am a proponent of extensibility, and think that the language should make as few things as possible built-in. I want to define my own application-specific global state, and, additionally, I want to have it thread-global, not process-global. You asked for an example, but, because of the nature of this topic, it would have to be a very large example to prove my point. Thread-local variables are things that only become really useful in large programs. Instead, I've asked you to put yourself in my shoes - what if the bits of context that you already take for granted in your programs had to be thread-local? How would you cope, without thread-local variables, in such a situation? But I would say that I think I would find having to know what thread a particular bit of code was running in in order to grok it very strange, I agree that it is important to have code which is easy to understand. Usually, functions run in the same thread as their caller, unless they are passed to something with the word 'fork' in the name. That's a good rule of thumb that is in fact sufficient to let you understand the code I write. Also, if that's too much to remember, then since I'm only proposing and using non-mutable thread-local state (i.e. it behaves like a MonadReader), and since I'm not passing actions between threads as Einar is, then you can forget about the 'fork' caveat. I think the code would in fact be more difficult to grok, if all of the things which I want to be thread-local were instead passed around as parameters, a la 'newMain'. This is simply because, in that scenario, there would much more code to read, and it would be very repetitive. If I used special monads for my state, then the situation would be only slightly better - a single monad would not suffice, and I'd be faced with a plethora of 'lift' functions and redefinitions of 'catch', as well as long type signatures and a crowded namespace. unless there was some obvious technical reason why the thread local state needed to be thread local (can't think of any such reason right now). Some things are not immediately obvious. If you don't like to think of reasons, then just take my word for it that it would help me. A facility for thread-local variables would be just another of many facilities that programmers could choose from when designing their code. I'm not asking you to change the way you program - I don't care how other people program. I trust them to know what is best for their particular application. It's none of my business, anyway. Since Simon Marlow said that he had been considering a thread-local variable facility, I merely wanted to voice my support:
Re: [Haskell] thread-local variables
On 04.08 17:29, Frederik Eaton wrote: might, in Adrian Hey and Einar Karttunen's world, become: newMain host environment program_args network_config locale terminal_settings stdin stdout stderr = do hPutStrLn stdout (defaultEncoding locale) Hello world Actually I have implemented network-libraries, and I don't remember them requiring such things ;-) I think our main difference is that when designing concurrent applications in Haskell I frequently use monadic actions as callbacks invoked in distant unrelated threads. Threading behind the API is seen by me as mostly an implementation issue as long as the service guarantees don't change. You seem to use threads in a much more constrained fashion (my own interpretation) which results in us seeing TLS from very different perspectives. Maybe I'm misunderstanding your position - maybe you think that I should use lots of different processes to segregate global state into separate contexts? Well, that's nice, but I'd rather not. For instance, I'm writing a server - and it's just not efficient to use a separate process for each request. And there are some things such as database connections, current user id, log files, various profiling data, etc., that I would like to be thread-global but not process-global. I have done many servers in Haskell. Usually I have threads allocated to specific tasks rather than specific requests. What guarantees do your code have that all the relevant parameters are already initialized - and how can an user of the code know which TLS variables need to be initialized? If it is documented maybe it could be done at the level of an implicit parameter? Or maybe you think that certain types of global state should be privileged - for instance, that all of the things which are arguments to 'newMain' above are OK to have as global state, but that anything else should be passed as function arguments, thus making thread-localization moot. I disagree with this - I am a proponent of extensibility, and think that the language should make as few things as possible built-in. I want to define my own application-specific global state, and, additionally, I want to have it thread-global, not process-global. This can cause much fun with the FFI. If we change e.g. stdout to thread specific what should be do before each foreign call? Same with the other things that are related to the OS process in question. A thread is a context of execution while a process is a context for resources. Would you like to have multiple Haskell processes inside one OS process? I don't consider these very different: 1) use one thread from a pre-allocated pool to do a task 2) fork a new thread to do the task With TLS they are vastly different. You asked for an example, but, because of the nature of this topic, it would have to be a very large example to prove my point. Thread-local variables are things that only become really useful in large programs. Instead, I've asked you to put yourself in my shoes - what if the bits of context that you already take for granted in your programs had to be thread-local? How would you cope, without thread-local variables, in such a situation? I have been using an application specific monad (newtyped transformer) and a clean set of functions so that the implementation is not hardcoded and can be changed easily. Thus I haven't had the same difficulties as you. I don't think many of the process global resources would make sense on a per-thread basis and I am not against all global state. But I would say that I think I would find having to know what thread a particular bit of code was running in in order to grok it very strange, I agree that it is important to have code which is easy to understand. Usually, functions run in the same thread as their caller, unless they are passed to something with the word 'fork' in the name. That's a good rule of thumb that is in fact sufficient to let you understand the code I write. Also, if that's too much to remember, then since I'm only proposing and using non-mutable thread-local state (i.e. it behaves like a MonadReader), and since I'm not passing actions between threads as Einar is, then you can forget about the 'fork' caveat. The only problem appears when someone uses two libraries one written by me and an another written by you and wonders why is my program failing in mysterious ways. I think the code would in fact be more difficult to grok, if all of the things which I want to be thread-local were instead passed around as parameters, a la 'newMain'. This is simply because, in that scenario, there would much more code to read, and it would be very repetitive. If I used special monads for my state, then the situation would be only slightly better - a single monad would not suffice, and I'd be faced with a plethora of 'lift' functions and redefinitions of 'catch', as well as long type signatures and a crowded namespace. As
[Haskell-cafe] a bunch of newbie questions
what's the difference between data and co-data exactly? or between inductive data types and co-inductive data types? can you give me some reference points that explain these? (read 56)::Integer does it in fact pass the type (Integer) to the function (read)? I guess what we want is for the (Integer) implementation of the (read) function to evaluate, not really to cast the value of (read) function to (Integer). in the regex libraries, (~=) cast this way results in completely different things altogether, should type classes have namespaces associated with them? somewhat like Integer.read 56? this way of selecting the intended implementation, does it work without trouble with multiparameter type classes as well? theoretically is it possible to do a strictness analysis without any help from the programmer? thanks a bunch in advance. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] a bunch of newbie questions
Imam Tashdid ul Alam wrote: what's the difference between data and co-data exactly? or between inductive data types and co-inductive data types? In Haskell there is no such difference, as inductive and coinductive types coincide in the semantic setting in which Haskell is usually interpreted. If there were a difference, that is, if we interpret Haskell minus general recursion in a somewhat simpler semantic setting, then data types would contain inly finite values, whereas codata types could also contain infinite values. can you give me some reference points that explain these? Papers by Uustalu and Vene might be a good start. Watch out for corecursion and coalgebras. (read 56)::Integer does it in fact pass the type (Integer) to the function (read)? No, it just says that the result of read should be an Integer. I guess what we want is for the (Integer) implementation of the (read) function to evaluate, not really to cast the value of (read) function to (Integer). Exactly. And that's what is happening. Based on the information provided when giving the result type. in the regex libraries, (~=) cast this way results in completely different things altogether, should type classes have namespaces associated with them? somewhat like Integer.read 56? I don't think that we need this. this way of selecting the intended implementation, does it work without trouble with multiparameter type classes as well? Yes, as long as enough type information is provided for the typechecker to decide what is the correct instance to use. One way of reducing the amount of information needed is using functional dependencies. theoretically is it possible to do a strictness analysis without any help from the programmer? Yes, such analyses exist, and are implemented in GHC, for example. They are just approximative, and cannot be exact by computability reasons. Ciao, Janis. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RE: ANN: System.FilePath 0.9
On Sat, Jul 29, 2006 at 05:35:30PM -0700, Andrew Pimlott wrote: On Sat, Jul 29, 2006 at 02:59:06AM +0200, Udo Stenzel wrote: Andrew Pimlott wrote: Second, foo is just as good a directory as foo/ to the system ...unless you have both (think Reiser4) or you want to create the file (I think, but I'm not sure). However, what's the point in being ambiguous when we can be explicit? Sometimes there is a difference, libraries and tools shouldn't gloss over that without consideration. As I said, it's one of those line-drawing exercises. But your points are well taken, and maybe the trailing delimiter should be part of the model. (My criterion has been whether any filesystem operations require the trailing delimiter. It sounds like with reiser4fs they might.) Actually, I just read in LWN that that part of reiser4 has been dropped. On the other hand, it was only dropped after considerable debate, and people using an older version of reiser4 still have the strange file-as-directory semantics. -- David Roundy http://www.darcs.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] a bunch of newbie questions
Mark T.B. Carroll wrote:
Janis Voigtlaender [EMAIL PROTECTED] writes:
(snip)
Yes, as long as enough type information is provided for the
typechecker to decide what is the correct instance to use.
(snip)
I've always been a little surprised when this doesn't happen more
widely for things other than instances. For instance, when
IntMap.size, Map.size and Set.size (or whatever) are all in scope as
size, it should be fairly obvious what (size x) is about once we've
inferred, for other reasons, that x is an IntMap. Similarly with
records, if we had field names that cause functions for extracting
the value of those fields, where we used the same field name in two
different record types, I figure that there's usually no ambiguity
because we can usually infer the type of the object to which the
'extractor' is being applied.
Am I just not seeing the big picture, or would people not find this
use of type information to resolve such ambiguities as nice as I
would, or is it harder to do that than I'm expecting?
I think this is because in Haskell the only way to overload function names
is to use type classes and instances just as the one and only way to qualify
an identifier is by using modules. This has the advantage that different
concerns are clearly separated out and dealt with in exactly one place by
one concern-specific mechanism.
Perhaps the basic problem is that (size) really belongs in a type class and
IntMap, Set, Map etc were created before anyone bothered to try and factor
their portions of common functionality into type classes. This factoring is
a non-trivial problem however (as you can see from the various posts on the
subject of sequences) since the design space is not nearly as well
understood as basic mathematical objects like monoids, monads etc and
without a mathematical foundation it is difficult to design a type class
factoring with any confidence.
For record fields, I suggested a while back that the compiler could
automatically create the relevant type classes and instances eg:
data Point i = Point {x :: i}
would ensure that a global typeclass was created if not already present:
class (.x) a b | a - b where
(.x) :: a - b
and would also create an instance for that type:
instance (.x) (Point i) i where
(.x) (Point k) = k
where .x is parsed as a single lexeme and treated as a postfix operator
ie:
-- no space between '.' and fieldname
exp .x or exp.x === (.x) exp
but
exp . x === (.) exp x -- composition
To refer to a particular field name directly you could use:
g = ((.x) :: Point a - a)
but I also thought it might be nice to have a special syntax to make things
less clunky eg:
g = Point^x
(It could not be written as Point.x because Point is not a module name,
unless you wanted to destroy the very simple rule that Foo.xyz qualifies xyz
by the module Foo)
In any case with the trivial syntactic sugar above it would already be
possible to use the same record names in multiple types simultaneously. I
think the reason there was no positive feedback about this idea before is
that unfortunately it looks as if the record system is to be extended to
deal with subtyping or horrible anonymous records such as {x=5} that don't
have an explicit value constructor in front of them instead of just
concentrating on making the existing system (which I really like apart from
the lack of field name overloading and dot access syntax) more usable as
above.
For value constructors, a change in the type inference algorithm would be
needed if they were to be resolved based on their types so you could write
eg:
data Location = Left | Right | Up | Down
data Hand = Left | Right
foo :: Location - Hand
foo Left = Left
foo Up = Left
foo Right = Right
foo Down = Right
and again there could be a syntax like Location^Left as a less clunky
alternative to (Left::Location) in cases where ambiguity needs to be
resolved explicitly eg if someone didn't want to write a top level type
signature for their function.
Imho this would make life a lot easier because you could concentrate on
names that are appropriate to the type without having to know about all the
other types you'd want to use unqualified in the same scope.
Regards, Brian.
--
Logic empowers us and Love gives us purpose.
Yet still phantoms restless for eras long past,
congealed in the present in unthought forms,
strive mightily unseen to destroy us.
http://www.metamilk.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] a bunch of newbie questions
Hello Mark, Friday, August 4, 2006, 3:03:54 PM, you wrote: I've always been a little surprised when this doesn't happen more widely for things other than instances. For instance, when IntMap.size, Map.size and Set.size (or whatever) are all in scope as size, it should be fairly obvious what (size x) is about once we've inferred, for other reasons, that x is an IntMap. Similarly with records, if we had this is called ad-hoc polymorphism which is not supported by Haskell. instead Haskell supports parametric polymorphism via type classes. i'm not a language lawyer ;) but thinks that difference between C++ which supports former and Haskell that supports later is the following: C++ can infer only result type based on arguments type while Haskell can infer in _both_ directions. i can imagine C++ type inferring algorithm, with a little imagination i even can think about Haskell's algorithm :) but two-way type inferring together with ad-hoc polymorphism make me a little nervous :) how about, for example, two ad-hoc-polymorphic functions: f (g x)? or dozens of such calls enclosed? how error messages should be generated: it may be Int::f with Char::g or Char::f with Bool::g or ... or ... or ... ? one more cause is that Haskell was defined by scientists, not practical programmers, and scientists prefer to use more systematic ways to do the same things nevertheless, there is no principal differences. in many cases you can define type classes, include your ad-hoc polymorphic functions into these classes and sleep easy. in particular, as Brian already said, there is a proposal to use automatically generated type classes for record fields -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] a bunch of newbie questions
Bulat Ziganshin wrote: this is called ad-hoc polymorphism which is not supported by Haskell. instead Haskell supports parametric polymorphism via type classes. I think you are wrong here Bulat. In fact, I think a) Haskell supports parametric polymorphism, e.g. id :: t - t id x = x b) Haskell supports ad-hoc polymorphism via type classes Martin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Why Not Haskell?
Hello All, I'm wondering why I can't find any commercial Haskell applications on the Internet. Is there any reason for this? I can think of the following possibilities only: 1) Haskell is too slow for practical use, but the benchmarks I found appear to contradict this. 2) Input and output are not good enough, in particular for graphical user interfacing and/or data base interaction. But it seems there are several user interfaces and SQL and other data base interfaces for Haskell, even though the tutorials don't seem to cover this. 3) Haskell is not scaleable for commercial use. This looks unlikely to me, but could this be a factor? 4) Haskell is open source and licensing restrictions forbid commercial applications. I haven't seen any such restrictions, but is this a problem for the standard modules? Are there other reasons why there seem to be just a few thousand (hundred?) Haskell programmers in the world, compared to the 3 million Java programmers and x million C/C++ programmers? The reason I ask is that in the early nineties I wrote a data mining /machine learning program. This was not a commercial success and since then I've been working as a free lance IT journalist. As such I covered the O'Reilly European Open Source Convention in Amsterdam last year and there I heard of Haskell. I became interested and started learning from the available free tutorials and Hugs. As an aside, I'd like to thank all those people. I really appreciate their work and I'd like to single out Hal Daume III's 'Yet Another Haskell Tutorial', while not diminishing the other authors in any way. Meanwhile I kept working on a data mining algorithm in my spare time and finally I came up with something that appears to work. While I was learning Haskell, I thought, why not try this part of the algorithm as a Haskell exercise. I could easily test it in Hugs. To my own surprise, after only a few weeks of this, I had a working prototype of my algorithm, printed out on less than 3 pages, using only standard functions in the Prelude. So, I'm really impressed by the power of Haskell, and I'm just a beginner. Now I'm trying to come up with a business model for my algorithm and to avoid the mistakes I made 10 years ago. There is a lot of difference between a prototype and a working tool, and then there is a lot of difference between a working tool and a successful commercial application. Probably it doesn't make much sense to try and develop a tool in C++ or even Java, but if I have to go on my own on this, maybe Haskell could be feasible, both for fun and profit. So, that's the background of my question (while introducing myself to the Cafe at the same time). Why hasn't Haskell made it into the business world (yet), after being available for 15 years, or is this the wrong question? Many thanks for your comments, Hans van Thiel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] a bunch of newbie questions
Martin Percossi wrote: Bulat Ziganshin wrote: this is called ad-hoc polymorphism which is not supported by Haskell. instead Haskell supports parametric polymorphism via type classes. I think you are wrong here Bulat. In fact, I think a) Haskell supports parametric polymorphism, e.g. id :: t - t id x = x b) Haskell supports ad-hoc polymorphism via type classes Sometimes a distinction is made between ad-hoc polymorphism of the kind you'd get in C++ with method overloading, and restricted parametric polymorphism as in Monad m = ie: 1) id :: t - t -- Unrestricted parametric polymorphism 2) foo :: Monad m = m a -- Restricted parametric polymorphism for (m) and unrestricted for (a) 3) bar :: Int - Int - String bar :: Char - Bool The only way to describe this is ad-hoc polymorphism, and the fact that any function is of the form A - B means regardless of the arity of the overloaded functions it can also be supported by typeclasses (*) eg: class Bar a b where bar :: a - b instance Bar Int (Int - String) where ... instance Bar Char Bool where ... And a function or value in scope can be making use of unrestricted, restricted, and ad-hoc polymorphism at the same time eg: zap :: Monad m = Char - m a zap :: Int - String - a String class Zap a b where zap :: a - b instance Monad m = Zap Char (m a) where ... instance Zap Int (String - a String) where ... (*) But there's one exception: you can't use typeclasses to resolve overloadings between values and functions because non-function values don't have a type of the form A - B: cool :: Int cool :: Char - String class Cool -- Ooops! fundamental problem encountered ;-) Regards, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why Not Haskell?
On Fri, 4 Aug 2006, Hans van Thiel wrote: ... Are there other reasons why there seem to be just a few thousand (hundred?) Haskell programmers in the world, compared to the 3 million Java programmers and x million C/C++ programmers? I can think of several other possible reasons - 6. Instability - available for 15 years, you say, but does the Haskell of 15 years ago support today's programs? Does standard Haskell even support today's programs? 7. Some difficult concepts, at a level that goes way beyond the commonly used languages. 8. Problems with evaluation model and space that other languages don't have to deal with. 9. Missing libraries and more, I suppose. I'm not saying any of these are necessarily compelling reasons not to use Haskell, but altogether, maybe another way to look at it is that it's really a strong statement when people decide to bet their livelihood on Haskell software development - it isn't the safe choice, and it means someone finds the reasons for it very compelling. Donn Cave, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why Not Haskell?
Hans van Thiel wrote: Hello All, I'm wondering why I can't find any commercial Haskell applications on the Internet. Is there any reason for this? I can think of the following possibilities only: 1) Haskell is too slow for practical use, but the benchmarks I found appear to contradict this. 2) Input and output are not good enough, in particular for graphical user interfacing and/or data base interaction. But it seems there are several user interfaces and SQL and other data base interfaces for Haskell, even though the tutorials don't seem to cover this. 3) Haskell is not scaleable for commercial use. This looks unlikely to me, but could this be a factor? 4) Haskell is open source and licensing restrictions forbid commercial applications. I haven't seen any such restrictions, but is this a problem for the standard modules? I wonder, how many languages have you seen commercial applications written in? I suppose you mean the sort of applications that might be sold in stores. I think a more interesting question around Haskell is what it takes to succeed in writing an application in a relatively uncommon language, what aspects of popularity are actually useful, and how you can compensate. What languages have gotten big without being the main language for a popular operating system, or pushed really hard by a big company? Then there are moderately popular languages like perl and Python, but are there lots of commercial application even in those? Brandon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why shouldn't variable names be capitalized?
On Aug 4, 2006, at 1:12 PM, Martin Percossi wrote: Hi, I'm wondering what the rationale was for not allowing capitalized variable names (and uncapitalized type names and constructors). I can only think of two arguments, and IMHO both of them are bad: 1. Enforces a naming convention. Fine - but my view is that this doesn't belong in the language definition (it belongs in the user's coding standards). I get annoyed, for example, that when I write code that manipulates matrices and vectors, I can't refer to the matrices with capital letters as is common in the literature. This is occasionally irritating. And to anyone who says that it's good to enforce naming consistency, I have this to say: Any language that requires me to learn about category theory in order to write imperative code should treat me like an adult when it comes to the naming of variables as well. ;-) 2. It makes it easier to write the compiler. I don't think I need to explain why this is bad... Eh? I'm not convinced this is a bad reason. It obviously needs to be balanced against other competing factors, but ease of implementation should always a consideration when designing a language. 3. It removes a whole class of possible ambiguities from the language. You the programmer (and the compiler, as an added bonus) can always identify the syntactic class of an identifier from _purely local_ context. Suppose I remove the case restriction. Is the following a pattern match or a function definition? Is M a variable or a data constructor? let f x M = z M in You can't tell! Worse, it could change depending on what identifiers are in scope. It could happen that you import a module and it silently causes your function definition to change to a pattern match. The situation is similar with type classes and type variables. You could magically end up with an instance declaration that is less polymorphic than you expect (if you have extensions turned on). I imagine that someone is just itching to sort me out. Do your worst! ;-) Thx Martin Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why shouldn't variable names be capitalized?
Martin Percossi wrote: Hi, I'm wondering what the rationale was for not allowing capitalized variable names (and uncapitalized type names and constructors). I can only think of two arguments, and IMHO both of them are bad: I'm not so sure about variable names and constructors, but the type syntax just wouldn't work without a lexical distinction between type names and type variables. Is (Int - Int) supposed to be polymorphic with a type variable named Int, or is it talking about a type Int? Perhaps you'd be happier reserving names beginning with apostrophes for variables? I think case is a bit easier to see - subattentive visual processing, and all that. Mostly, case is used so you know what basic sort of thing some object is, without reviewing everything in scope. Mathematicians use typesetting similarly to tell basic kinds of things appart. Imagine a mathematician complaining that he was forced to learn category theory to get a degree, and people still don't let him use letter with an arrow over it to denote a scalar quantity. It's just that ascii is more restricted, so we don't have things like fonts, greek letters, and accents. Lexical syntax is the least important kind of linguistic freedom. Brandon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why shouldn't variable names be capitalized?
Ok, you asked for it, so here's my worst :-) 1) Here's what the History of Haskell has to say about this: Namespaces were a point of considerable discussion in the Haskell Committee. We wanted the user to have as much freedom as possible, while avoiding any form of ambiguity. So we carefully defined a set of lexemes for each namespace that were orthogonal when they needed to be, and overlapped when context was sufficient to distinguish their meaning. As an example of overlap, capitalised names such as Foo can, in the same lexical scope, refer to a type constructor, a data constructor, and a module, since whenever the name Foo appears, it is clear from context to which entity it is referring. As an example of orthogonality, we designed normal variables, infix operators, normal data constructors, and infix data constructors to be mutually exclusive. We adopted from Miranda the convention that data constructors are capitalised while variables are not; and added a similar convention for infix constructors, which in Haskell must start with a colon. ... The key point here is that we wanted data constructors to be orthogonal to formal parameters. For example, in: foo x y = ... We know that x and y are formal parameters, whereas if they were capitalized we'd know that they were constructors. Some of us had had experience with ML where this distinction is not made, and we didn't like that. There are surely other ways to achieve this, but captilization was one of the least painful, as we saw it. 2) Note that this is not a compiler issue -- the compiler won't have much problem either way -- but it is a readability issue. 3) I suspect that you are mostly kidding, but Haskell doesn't require you to know any category theory to write imperative code! I hope this helps, -Paul Martin Percossi wrote: Hi, I'm wondering what the rationale was for not allowing capitalized variable names (and uncapitalized type names and constructors). I can only think of two arguments, and IMHO both of them are bad: 1. Enforces a naming convention. Fine - but my view is that this doesn't belong in the language definition (it belongs in the user's coding standards). I get annoyed, for example, that when I write code that manipulates matrices and vectors, I can't refer to the matrices with capital letters as is common in the literature. And to anyone who says that it's good to enforce naming consistency, I have this to say: Any language that requires me to learn about category theory in order to write imperative code should treat me like an adult when it comes to the naming of variables as well. ;-) 2. It makes it easier to write the compiler. I don't think I need to explain why this is bad... I imagine that someone is just itching to sort me out. Do your worst! ;-) Thx Martin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why Not Haskell?
Hans van Thiel wrote: I'm wondering why I can't find any commercial Haskell applications on the Internet. Is there any reason for this? Of course. Corporations are conservative to the point of being boneheaded. So to avoid risk, they all went on the internet and said, Gee, I can't find any commercial Haskell applications on the Internet. There must be a reason for that, so I better use something else. Are there other reasons why there seem to be just a few thousand (hundred?) Haskell programmers in the world, compared to the 3 million Java programmers and x million C/C++ programmers? Yah. 2.995 million programmer-wannabes were too lazy to think for themselves and choose what everybody uses. Probably it doesn't make much sense to try and develop a tool in C++ or even Java, but if I have to go on my own on this, maybe Haskell could be feasible, both for fun and profit. It never makes sense to limit yourself to only one programming language, even if it happens to be Haskell. There's always the FFI, should it turn out that some part is better done in C or assembly or Fortran or whatever comes to mind. Udo. -- The two most abundant things in the universe are hydrogen and stupidity. -- Harlan Ellison signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why Not Haskell?
Hans van Thiel wrote: Hello All, I'm wondering why I can't find any commercial Haskell applications on the Internet. Is there any reason for this? I'm actually working on a Haskell program which I hope to release as a commercial application. The biggest problem I'm encountering is the lack of a really solid collections library that's as well thought out as C++ STL because although there are several competing collections libraries, each allowing fast development of powerful code, they all have various faults and limitations and I hate the idea of my code resting on half-baked foundations. I'm also a rabid perfectionist (and extremely fussy with regard to code aesthetics) when it comes to these kind of things so perhaps it's my fault. Perhaps it's also because Haskell raises your expectations regarding what a good program should be like, so it's easy to get lost in abstraction. Eg last week all I needed was an equivalent of the C++ std::vector but I've wasted the whole of this week trying to create the perfect factoring of collection classes to try and avoid having concrete types everywhere and to be a foundation for all the uses of collection types in my program, and now I'm totally lost in a miasma of undecidable instances and difficult decisions. I can think of the following possibilities only: 1) Haskell is too slow for practical use, but the benchmarks I found appear to contradict this. I think it's fast enough. There's also a very good foreign function interface if you need to get the full speed of C for some inner loop. And a bonus is that as more and more people use it, it's likely that more effort will be done to make it faster. 2) Input and output are not good enough, in particular for graphical user interfacing and/or data base interaction. But it seems there are several user interfaces and SQL and other data base interfaces for Haskell, even though the tutorials don't seem to cover this. You just need to check the licences for the various bindings and also the licences for the C libs they're bound to so you don't end up with a GPL infested program. WxWidgets uses LGPL with the linking exception so it should be 100% safe and easy to use (http://wxhaskell.sourceforge.net/license.html ). Gtk2Hs uses the LGPL according to http://haskell.org/gtk2hs/overview/ but it does not appear to admit the linking exception though this is not insurmountable - it just means you need to supply an object file of your code along with your exe (and if you use Unix there's no trouble at all because the lib is linked dynamically iirc) 3) Haskell is not scaleable for commercial use. This looks unlikely to me, but could this be a factor? It can be difficult to know how to organise a large program in Haskell if you're used to OOP but I don't think there are any limits on scalability per se - GHC is itself an example of a very large Haskell program that's widely used on many platforms. 4) Haskell is open source and licensing restrictions forbid commercial applications. I haven't seen any such restrictions, but is this a problem for the standard modules? You can discover the licensing situation by downloading the GHC source (or source for whatever distro you're using) and looking in the directories for each package. For example the base package uses a BSD-style licence and HaXml uses LGPL with the exception to allow static linking. It would be good if this info was also on the wiki somewhere but if it is I can't find it, or if there was a tool to identify or gather together the various licenses and create a composite license (eg including the list of the names of all contributors who want to be mentioned) to distribute with your app (a free lawyer implemented in Haskell together with its own self-generated license!!!). If you're going to release your app on Windows using GHC you'll need to prepare an object file to distribute along with your exe to satisfy the annoying LGPL linking restriction imposed by the GMP library that's currently part of the statically linked runtime, but this shouldn't be an obstacle once you've written the appropriate batch file to generate it. (There's a thread on the ghc users mailing list indicating that GMP might be removed from GHC at some point which would make life even easier - see http://www.haskell.org/pipermail/glasgow-haskell-users/2006-August/010665.html ) [snip] Why hasn't Haskell made it into the business world (yet), after being available for 15 years, or is this the wrong question? This might just be because computers were too slow in the past to run programs written in such high level languages as Haskell, so everyone had to use low-level languages like C and C++ (people even now still spend sleepless nights debating whether or not to use a virtual function in a C++ class because of the extra indirection it requires). Also, the bottom line imho is that Haskell is a difficult language to
Re: [Haskell-cafe] Why shouldn't variable names be capitalized?
Paul Hudak wrote: Ok, you asked for it, so here's my worst :-) You're too gentle! I was expecting some serious community flagellation for my heretical remarks! 1) Here's what the History of Haskell has to say about this: Namespaces were a point of considerable discussion in the Haskell Committee. We wanted the user to have as much freedom as possible, while avoiding any form of ambiguity. So we carefully defined a set of lexemes for each namespace that were orthogonal when they needed to be, and overlapped when context was sufficient to distinguish their meaning. As an example of overlap, capitalised names such as Foo can, in the same lexical scope, refer to a type constructor, a data constructor, and a module, since whenever the name Foo appears, it is clear from context to which entity it is referring. As an example of orthogonality, we designed normal variables, infix operators, normal data constructors, and infix data constructors to be mutually exclusive. We adopted from Miranda the convention that data constructors are capitalised while variables are not; and added a similar convention for infix constructors, which in Haskell must start with a colon. ... The key point here is that we wanted data constructors to be orthogonal to formal parameters. For example, in: foo x y = ... We know that x and y are formal parameters, whereas if they were capitalized we'd know that they were constructors. Some of us had had experience with ML where this distinction is not made, and we didn't like that. There are surely other ways to achieve this, but captilization was one of the least painful, as we saw it. I agree that naming can be abused. But I think it should be *me*, the programmer, or in the limit ghc, the glorious compiler (but only because of unresolvable ambiguities), who decides it -- not *you*, the language implementor!!! ;-) 2) Note that this is not a compiler issue -- the compiler won't have much problem either way -- but it is a readability issue. Ok - that's what I suspected - contrary to some of the other replies which seem to imply that it would cause big problems in the compiler. While I have never written a compiler of anything near the complexity of haskell (I just about managed an awk-like language! ;-), you still feel that it shouldn't be that difficult to handle these cases. 3) I suspect that you are mostly kidding, but Haskell doesn't require you to know any category theory to write imperative code! True again - but I think you understood the general gist. I hope this helps, -Paul It does, thanks for your time. And now I will stop complaining! ;-) Martin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why shouldn't variable names be capitalized?
On Fri, 4 Aug 2006, Martin Percossi wrote: I agree that naming can be abused. But I think it should be *me*, the programmer, or in the limit ghc, the glorious compiler (but only because of unresolvable ambiguities), who decides it -- not *you*, the language implementor!!! ;-) The ML constructor/variable ambiguity introduces a nasty maintenance headache: what if you upgrade to a new version of a library which introduces a new constructor which happens to be the same as a variable you have been using? Suddenly the meaning of your functions changes! Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ FISHER: WEST OR NORTHWEST 4 OR 5 BECOMING VARIABLE 3 OR 4. FAIR. MODERATE OR GOOD. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why Not Haskell?
On Fri, 4 Aug 2006, Udo Stenzel wrote: Hans van Thiel wrote: I'm wondering why I can't find any commercial Haskell applications on the Internet. Is there any reason for this? Of course. Corporations are conservative to the point of being boneheaded. So to avoid risk, they all went on the internet and said, Gee, I can't find any commercial Haskell applications on the Internet. There must be a reason for that, so I better use something else. Or maybe they're more clever than you imagine, and they all have rooms full of Haskell programmers sworn to secrecy, trying to get a jump on the competition. Wouldn't it be funny if it turned out that the Python stuff at Google was just a side-show, and Haskell was really the big development language all along? (Not true, I'm sure - you could sort of stand a chance of starting a secret Python development project, but Haskell I doubt.) Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why Not Haskell?
On Fri, 4 Aug 2006, Brian Hulley wrote: 4) Haskell is open source and licensing restrictions forbid commercial applications. I haven't seen any such restrictions, but is this a problem for the standard modules? You can discover the licensing situation by downloading the GHC source (or source for whatever distro you're using) and looking in the directories for each package. For example the base package uses a BSD-style licence and HaXml uses LGPL with the exception to allow static linking. A license which requires programmers to disclose their sources shouldn't be a problem for a commercial application. Which C hacker would or could steal code from it? :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] a bunch of newbie questions
Hello Brian, Friday, August 4, 2006, 8:50:25 PM, you wrote: class Bar a b where bar :: a - b (*) But there's one exception: you can't use typeclasses to resolve overloadings between values and functions because non-function values don't have a type of the form A - B: cool :: Int cool :: Char - String class Cool -- Ooops! fundamental problem encountered ;-) class Cool a where cool :: a instance Cool Int instance Cool (Char - String) ? -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why Not Haskell?
Hello Hans, Friday, August 4, 2006, 8:17:42 PM, you wrote: 1) Haskell is too slow for practical use, but the benchmarks I found appear to contradict this. it's an advertisement :D just check yourself 2) Input and output are not good enough, in particular for graphical user interfacing and/or data base interaction. But it seems there are several user interfaces and SQL and other data base interfaces for Haskell, even though the tutorials don't seem to cover this. i've seen a paper which lists 7 (as i remember) causes of small Haskell popularity, including teaching, libraries, IDEs and so on. may be someone will give us the url i personally think that Haskell in its current state is appropriate for system programming Are there other reasons why there seem to be just a few thousand (hundred?) Haskell programmers in the world, compared to the 3 million Java programmers and x million C/C++ programmers? i once analyzed why C++ and not Eiffel or Modula-2 becomes the language of 90's. my conclusion was what C and C++ becomes a tandem at the late 80's - C raised popularity because it had OOP successor while C++ becomes popular because it had imperative predecessor. Pascal, Modula-2 or Eiffel was great languages, but they don't form such tandems. So, now we have 3 million of Java programmers just because C was a great tool for writing DOS apps :) Now I'm trying to come up with a business model for my algorithm and to avoid the mistakes I made 10 years ago. There is a lot of difference between a prototype and a working tool, and then there is a lot of difference between a working tool and a successful commercial application. Probably it doesn't make much sense to try and develop a tool in C++ or even Java, but if I have to go on my own on this, maybe Haskell could be feasible, both for fun and profit. if speed isn't critical, if you don't need to use many libs, don't need help from RAD tools in developing UI of your program - you can use Haskell, imho -- 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] Why Not Haskell?
Hello Jason, Friday, August 4, 2006, 10:01:31 PM, you wrote: 15. OO is now tried and true in industry. I would say it's far from optimal but people do know they can build large applications (say ~100k lines of C++). it's medium size. GHC is larger :) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] fast image processing in haskell?
Hello,
I am attempting to process images captured from a webcam. My aim is to
do so, in real time, at the frame rate of the camera. I'm using GHC
6.4.2 with -O3.
A frame consists of ~100k 24bit colour values.
The webcam is interfaced through FFI bindings to some C++ -- these are
all labelled 'unsafe'. The image is passed to Haskell as a Ptr Word8.
To blit this to the screen (via Gtk2Hs) I do the following:
data Cam = Cam { snap_width :: !Int
, snap_height :: !Int
, snap_bytespp :: !Int
, snap_size:: !Int
, cam_img :: Ptr Word8
, cam_obj :: ForeignPtr ()
}
do (PixbufData _ dst _) - (pixbufGetPixels pixbuf :: IO (PixbufData Int Word8))
copyBytes dst (cam_img cam)
This achieves the desired throughput (25-29fps.) However, I am at a
bit of a loss how to do something similar for preprocessing the data
in Haskell before blitting the data (whilst also retaining some
semblance of functional programming...)
Currently, I have:
cam_snap cam f x
= do let loop (r:g:b:rest) n x = f r g b n x = loop rest (n+3)
loop _ _ x= return x
px - peekArray (snap_size cam) (cam_img cam)
loop px 0 x
cam_snap2 cam f x
= let loop ptr n x
| n = snap_size cam
= return x
| otherwise
= do let ptrs = scanl plusPtr ptr [1,1]
[r,g,b] - mapM peek ptrs
f r g b n x = loop (ptr `plusPtr` 3) (n+3)
in loop (cam_img cam) 0 x
do ...
let sum_px r g b _ (sr,sg,sb) = return (sr+r,sg+g,sb+b)
sum - cam_snap (cam ui) sum_px (0.0,0.0,0.0)
print sum
cam_snap only processes at 5 fps, whereas cam_snap2 operates at 6fps.
Any suggestions?
Thanks.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] a bunch of newbie questions
Bulat Ziganshin wrote: Hello Brian, Friday, August 4, 2006, 8:50:25 PM, you wrote: class Bar a b where bar :: a - b (*) But there's one exception: you can't use typeclasses to resolve overloadings between values and functions because non-function values don't have a type of the form A - B: cool :: Int cool :: Char - String class Cool -- Ooops! fundamental problem encountered ;-) class Cool a where cool :: a instance Cool Int instance Cool (Char - String) ? Yes thanks - someone else pointed this out to me off-list as well. I think that mental block must have been caused by watching too many episodes of Star Trek yesterday! Ok I give up, there's just no excuse... ;-) Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] REALLY simple STRef examples
Chad
| x = runST $ return (1::Int)
This code looks simple, but it isn't. Here are the types:
runST :: forall a. (forall s. ST s a) - a
($) :: forall b c. (b-c) - b - c
return 1 :: forall s. ST s Int
To typecheck, we must instantiate
b with (forall s. ST s Int)
c with Int
In H-M that's impossible, because you can't instantiate a type variable
(b) with a polytype (forall s. ST s Int). GHC will now let you do that
(a rather recent change), but in this case it's hard to figure out that
it should do so. Equally plausible is to instantiate b with (ST s'
Int), where s' is a unification variable.
One way to make this work is to look at $'s first argument first. Then
it's clear how to instantiate b. Then look at the second argument. But
if you look at the second argument first, matters are much less clear.
GHC uses an algorithm that is insensitive to argument order, so it can't
take advantage of the left-to-right bias of this example.
It's unfortunate that such a simple-looking piece of code actually
embodies a rather tricky typing problem! Of course there is no problem
if you don' use the higher order function $. Use parens instead
x = runST (return 1)
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
| Chad Scherrer
| Sent: 19 July 2006 23:02
| To: haskell-cafe@haskell.org
| Subject: [Haskell-cafe] REALLY simple STRef examples
|
| I've looked around at the various STRef examples out there, but still
| nothing I write myself using this will work. I'm trying to figure out
| how the s is escaping in really simple examples like
|
| x = runST $ return 1
|
| y = runST $ do {r - newSTRef 1; readSTRef r}
|
| Neither of these works in ghci - they both say
|
| interactive:1:0:
| Inferred type is less polymorphic than expected
| Quantified type variable `s' escapes
| Expected type: ST s a - b
| Inferred type: (forall s1. ST s1 a) - a
| In the first argument of `($)', namely `runST'
| In the definition of `it':
|...
|
| I thought maybe I needed to replace 1 with (1 :: Int) so the state
| representation didn't force the type, but it still gives the same
| result.
|
| Can someone point me to the simplest possible runST example that
| actually works? Thanks!
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why shouldn't variable names be capitalized?
Martin Percossi wrote: Paul Hudak wrote: foo x y = ... We know that x and y are formal parameters, whereas if they were capitalized we'd know that they were constructors. I agree that naming can be abused. But I think it should be *me* ... Oh, you like to decide lexical ambiguities. Well, I suppose you know a bit of C++. So what do you think this is: * int *foo ; It's the declaration of a pointer to 'int' named 'foo', isn't it? now what's this: * x * y ; *Obviously* this mulplies x and y and throws the result away, doesn't it? Now look more closely. Do you see it? Or does it get more blurred the closer you look? We don't have this problem in Haskell, and in a sane world, C++ shouldn't have it either. If you find second-guessing the programmer funny, try to write a parser for C++. You will have so much fun, it's almost impossible to describe. Udo. -- Even if you're on the right track, you'll get run over if you just sit there. -- Will Rogers signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Type hackery help needed!
Hi fellow Haskelleers, I have a tricky problem that I just can't seem to solve. The problem is one of unresolved overloading, much like the (show . read) issue, but unlike that particular problem I feel there should be a solution to the one I'm wrestling with. I've tried to strip away all the unnecessary bits so the following will be a bit abstract, but it shows the gist of the problem. I have two overloaded functions - one I call 'build' that creates values from subparts, and one I call 'embed' that turns values into a form appropriate to call 'build' on. What they really represent is creating values of some XML tree structure, with embed making sure that the children are of the right type. Conceptually, we could imagine that these two functions to be defined as class Build x c | x - c, c - x where build :: String - [c] - x class Embed a b where embed :: a - b They would be used together as in e.g. p c = build p [embed c] This works pretty well, the fundep x - c tells me what b should be, assuming I infer a proper type for the result of the composition. The type of p is then p :: (Embed a c, Build x c) = a - x where the c in the middle is determined by x via the fundep. My problems arise because I want to start nesting these to form tree structures, as in tree = p (p foo) Expanding the definition of p, the argument to the outer call to build is now embed $ build p [embed foo] :: (Embed String c, Build x c, Embed x x1) = x1 Through the fundep on the outer build I can infer what x1 should be, but there's no way I can infer x (without inserting an explicit type signature which is out of the question). This problem is probably unsolvable in general, but for my particular problem there are some restrictions that makes me feel there should be a clever way of working with classes and fundeps to make this all work out. I just can't seem to find one. These are the rules that the setup must obey: * A value of any type should be embeddable inside a build expression of any result type, i.e. a - b or b - a cannot hold on Embed in general. * The exception to the above is that if an expression using 'build' is embedded inside an outer 'build', as in 'tree' above, the inner build should have the same result type as the outer build (in a sense forming b - a only for types instantiating Build). In other words, children of an xml element must be of the same type as their parent, even before the call to embed. * However, it would be nice, but probably not crucial, if by using explicit type signatures where I want to, I could actually embed values of other xml types than the outer one I am embedding them in, and letting embed convert them to xml of the correct type. I suspect this cannot be. The types of build and embed are negotiable, and certainly the type classes, as long as the two can be used together in roughly the same way as indicated above. The calls to build and embed will be autogenerated by a preprocessor from a HSP-style XML syntax, e.g. p% c %/p == build p [embed c] and for this reason any solution *must* be syntactically expressible as expressions on a form similar to the above, but those expressions can be arbitrarily convoluted. For instance in my failed attempts so far I have used let expressions around build to form self-recursive versions to pass a type down through the evaluation, as in p c = let x = build p [embed x c] in x This is an ok solution syntactically, if only it solved the problem, I still can't see how to propagate it to the next level of build. :-( Is there anyone out there with the proper type class fu who can see a way out for me? Is this even possible to do at all? If yes, tell me please, and if not, I would be most interested in seeing why it cannot work. Any and all comments are welcome. Thanks for reading this long :-) /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] fast image processing in haskell?
Jeff Briggs wrote:
Hello,
I am attempting to process images captured from a webcam. My aim is to
do so, in real time, at the frame rate of the camera. I'm using GHC
6.4.2 with -O3.
A frame consists of ~100k 24bit colour values.
The webcam is interfaced through FFI bindings to some C++ -- these are
all labelled 'unsafe'. The image is passed to Haskell as a Ptr Word8.
To blit this to the screen (via Gtk2Hs) I do the following:
data Cam = Cam { snap_width :: !Int
, snap_height :: !Int
, snap_bytespp :: !Int
, snap_size:: !Int
, cam_img :: Ptr Word8
, cam_obj :: ForeignPtr ()
}
do (PixbufData _ dst _) - (pixbufGetPixels pixbuf :: IO (PixbufData Int
Word8))
copyBytes dst (cam_img cam)
This achieves the desired throughput (25-29fps.) However, I am at a
bit of a loss how to do something similar for preprocessing the data
in Haskell before blitting the data (whilst also retaining some
semblance of functional programming...)
Currently, I have:
cam_snap cam f x
= do let loop (r:g:b:rest) n x = f r g b n x = loop rest (n+3)
loop _ _ x= return x
px - peekArray (snap_size cam) (cam_img cam)
loop px 0 x
cam_snap2 cam f x
= let loop ptr n x
| n = snap_size cam
= return x
| otherwise
= do let ptrs = scanl plusPtr ptr [1,1]
[r,g,b] - mapM peek ptrs
f r g b n x = loop (ptr `plusPtr` 3) (n+3)
in loop (cam_img cam) 0 x
do ...
let sum_px r g b _ (sr,sg,sb) = return (sr+r,sg+g,sb+b)
sum - cam_snap (cam ui) sum_px (0.0,0.0,0.0)
print sum
cam_snap only processes at 5 fps, whereas cam_snap2 operates at 6fps.
Any suggestions?
I suggest trying something, using /usr/bin/ghc -O3 -optc-O3 like this:
{-# OPTIONS_GHC -funbox-strict-fields #-}
import Foreign
import Control.Monad
data Cam = Cam { snap_width :: !Int
, snap_height :: !Int
, snap_bytespp :: !Int
, snap_size:: !Int
, cam_img :: Ptr Word8
, cam_obj :: ForeignPtr ()
}
type F = Word8 - Word8 - Word8 - Int - Int - Int
{-# INLINE cam_snap_3 #-}
cam_snap_3 :: Cam - F - Int - IO Int
cam_snap_3 cam f x =
let end = snap_size cam
loop ptr n x | ptr `seq` n `seq` x `seq` False = undefined
| n = end = return x
| otherwise = do
r - peek ptr
g - peek (advancePtr ptr 1)
b - peek (advancePtr ptr 2)
loop (advancePtr ptr 3) (n+3) (f r g b n x)
in loop (cam_img cam) 0 x
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why shouldn't variable names be capitalized?
Martin Percossi wrote: Hi, I'm wondering what the rationale was for not allowing capitalized variable names (and uncapitalized type names and constructors). I can only think of two arguments, and IMHO both of them are bad: 1. Enforces a naming convention. Fine - but my view is that this doesn't belong in the language definition (it belongs in the user's coding standards). If everyone uses the same coding standards it's easier to understand other people's code. Also, if you're working in a team you'd usually have to agree to adhere to someone else's idea of how to name identifiers which you might find really irritating, whereas with Haskell there is at least some global common ground that has already been established so there would be less reasons to get irritated with actual people! ;-) I get annoyed, for example, that when I write code that manipulates matrices and vectors, I can't refer to the matrices with capital letters as is common in the literature. But you also can't write things like: v' = M v in a general purpose programming language and expect it to be interpreted as v' = M * v. And to anyone who says that it's good to enforce naming consistency, I have this to say: Any language that requires me to learn about category theory in order to write imperative code should treat me like an adult when it comes to the naming of variables as well. ;-) But it does! Haskell realises that as an adult you are more interested in getting as much feedback about the correctness of your program as possible, rather than glossing over possible errors to maintain an illusory world where the lure of extra choices magnifies childish whimsy! ;-) 2. It makes it easier to write the compiler. I don't think I need to explain why this is bad... Why would you say this? If it's easier to write the compiler the chances are: a) The compiler will have a simpler and cleaner design a1) There will be less bugs in the compiler a2) It is easier to modify so more language improvements can be explored b) More people will be motivated to write or modify compilers or other language-processing tools leading to improvements in the language and better development environments I imagine that someone is just itching to sort me out. Do your worst! ;-) The extra coding confidence you gain by having a fixed capitalisation rule probably allows you to feel more relaxed when coding so I would not be surprised if the capitalisation rule leads to health benefits and therefore a feeling of peace, well-being, and goodwill towards other coders because either one is in agreement or else there is a common enemy namely the rule that cannot be changed! ;-) All we can do is pity those poor C++ souls locked in an abyss of inflated personality, case conflicts, chronic anxiety, and bug ridden code... Best regards, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why shouldn't variable names be capitalized?
There are two places where confusion could arise if you didn't have the case distinction in Haskell: pattern matching (does a name refer to a constructor or not) and type expressions (is it a type variable or not). In Haskell the distinction is made by case, but this is far from the only choice. There are other ways to mark what is a variable and what is not. I don't necessarily think that Haskell did it the best way, but then this is a minor syntactic issue. Changing the case of variables is a pretty low price to pay to solve this problem. -- Lennart On Aug 4, 2006, at 13:12 , Martin Percossi wrote: Hi, I'm wondering what the rationale was for not allowing capitalized variable names (and uncapitalized type names and constructors). I can only think of two arguments, and IMHO both of them are bad: 1. Enforces a naming convention. Fine - but my view is that this doesn't belong in the language definition (it belongs in the user's coding standards). I get annoyed, for example, that when I write code that manipulates matrices and vectors, I can't refer to the matrices with capital letters as is common in the literature. And to anyone who says that it's good to enforce naming consistency, I have this to say: Any language that requires me to learn about category theory in order to write imperative code should treat me like an adult when it comes to the naming of variables as well. ;-) 2. It makes it easier to write the compiler. I don't think I need to explain why this is bad... I imagine that someone is just itching to sort me out. Do your worst! ;-) Thx Martin ___ 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] Why Not Haskell?
G'day all. Quoting Udo Stenzel [EMAIL PROTECTED]: Uh, this one's wrong. Does C++ of 15 years ago support today's programs? C++ of _today_ doesn't support today's programs in some cases. Just ask the Boost developers about the various workarounds they still have to deal with. No. C++ of 10 years ago probably does, but the compiler will crash. Even compiling a fully conforming ISO C++ standard library generally requires a compiler from at most three years ago. Generally speaking, any C++ application that was written 10 years ago and hasn't been rewritten avoids large parts of the standard library precisely because it was so poorly supported, and what was supported was poorly implemented. (That's why Qt looks like it does.) Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Monad Imparative Usage Example
Thanks All
This is about my tries to understand monads and handling state - as
you perfectly know - is one of them. I have understood a little about
monads but that knowledge does not satidfy me. Again Thankyou
On 8/2/06, Duncan Coutts [EMAIL PROTECTED] wrote:
On Wed, 2006-08-02 at 13:26 +0330, Kaveh Shahbazian wrote:
Haskell is the most powerfull and interesting thing I'v ever
encountered in IT world. But with an imparative background and lack of
understanding (because of any thing include that maybe I am not that
smart) has brought me problems. I know this is an old issue. But
please help it.
Question : Could anyone show me a sample of using a monad as a
statefull variable?
For example see this code in C# :
//
public class Test
{
int var;
static void Fun1() { var = 0; Console.Write(var); }
static void Fun2() { var = var + 4; Console.Write(var); }
static void Main() { Fun1(); Fun2(); var = 10; Console.Write(var
= + var.ToString()); }
}
//
I want to see this code in haskell.
As other people have noted, you probably don't want to to see this code
in Haskell. It's possible to translate stateful code in a 1-1 style but
that's not really the point. You'll not get much of the advantages of
the language if you do that.
You can certainly use console IO etc but for your object containing
mutable state, well in a functional style you'd simply not do that and
solve the problem in a different way.
That's why you see the code people have suggested as translations are
bigger than the code you started with, because the language is not
naturally imperative.
So the trick is to solve your problem in Haskell, not translate your
imperative solution to Haskell.
Duncan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
