[GHC] #846: upload spam filter
#846: upload spam filter -+-- Reporter: bert |Owner: Type: bug | Status: new Priority: normal|Milestone: Component: Compiler | Version: 6.4.2 Severity: normal| Keywords: Os: Unknown | Difficulty: Unknown Architecture: Unknown | -+-- a href= http://frusemide-furosemide.tttfhs.info frusemide (furosemide)/a a href= http://flomax-tamsulosin.ngvjj.info flomax (tamsulosin)/a a href= http://finasteride-proscar.myjhy.info finasteride (proscar)/a a href= http://evista-osteoporosis.tttfhs.info evista (osteoporosis)/a a href= http://esomeprazole-nexium.ngvjj.info esomeprazole (nexium)/a a href= http://effexor-venlafaxine.myjhy.info effexor (venlafaxine)/a a href= http://crestor-rosuvastatin.tttfhs.info crestor (rosuvastatin)/a a href= http://cozaar-losartan.ngvjj.info cozaar (losartan)/a a href= http://coumadin-warfarin.myjhy.info coumadin (warfarin)/a a href= http://clopidogrel-plavix.tttfhs.info clopidogrel (plavix)/a a href= http://clomid-clomifene.ngvjj.info clomid (clomifene)/a a href= http://cipro-ciprofloxacin.myjhy.info cipro (ciprofloxacin)/a a href= http://celebrex-celecoxib.tttfhs.info celebrex (celecoxib)/a a href= http://carvedilol-coreg.ngvjj.info carvedilol (coreg)/a a href= http://carisoprodol-soma.myjhy.info carisoprodol (soma)/a a href= http://cardura-doxazosin.tttfhs.info cardura (doxazosin)/a a href= http://azithromycin-zithromax.ngvjj.info azithromycin(zithromax)/a a href= http://avapro-irbesartan.myjhy.info avapro (irbesartan)/a a href= http://avandia-rosiglitazone.tttfhs.info avandia (rosiglitazone)/a a href= http://atenolol-tenormin.ngvjj.info atenolol (tenormin)/a a href= http://arava-leflunomide.myjhy.info arava (leflunomide)/a a href= http://amoxicillin-amoxil.tttfhs.info amoxicillin (amoxil)/a a href= http://amlodipine-norvasc.ngvjj.info amlodipine (norvasc)/a a href= http://altace-ramipril.tttfhs.info altace (ramipril)/a a href= http://amaryl-glimepiride.myjhy.info amaryl (glimepiride)/a a href= http://allegra-fexofenadine.ngvjj.info allegra (fexofenadine)/a a href= http://alendronate-fosamax.tttfhs.info alendronate (fosamax)/a a href= http://adalat-nifedipine.ngvjj.info adalat (nifedipine)/a a href= http://generic-actos-diavista.tttfhs.info generic actos (diavista)/a a href= http://aciphex-rabeprazole.ngvjj.info aciphex (rabeprazole)/a -- Ticket URL: http://cvs.haskell.org/trac/ghc/ticket/846 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
Evaluating expressions in Visual Haskell
Hi, I apologize if this question has been asked before, but I couldn't find an FAQ or the answer online. Does Visual Haskell have support for evaluating expressions? I tried a few things (like highlighting an expression, rightclicking, and looking for evaluate option) but couldn't find anything. If this feature is missing, is it planned? Also, what is a good way to do this together with Visual Haskell? I could, of course, open an interpreter in a command window, load appropriate modules, and evaluate expressions from there but is there a more integrated way? Thanks, - Slava Akhmechet ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
default declarations
Hi, apparently ghci doesn't take default declarations into account. Inspired by a question on the hugs-users list I wrote module BoolNum where default (Bool, Rational) instance Num Bool where (+) = (/=) (-) = (/=) (*) = () negate x = x abs x = x signum x = x fromInteger = odd and in hugs, as expected I get BoolNum 1 True but in ghci, it's *BoolNum 1 1, no defaulting apparently takes pkace. Why? Bug or feature ? Cheers, Daniel -- In My Egotistical Opinion, most people's C programs should be indented six feet downward and covered with dirt. -- Blair P. Houghton ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] thread-local variables
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? You could ask the same questions about process-global state, couldn't you? If it is documented maybe it could be done at the level of an implicit parameter? Do you think implicit parameters are better than TLS? 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? If you want to think of it that way, then sure. 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. If you don't consider them different, then you can start using (2) instead of (1). 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. You say many, but the question is are there any. 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. Can you give the API for your library? I have a hard time imagining how it could not be obvious that a thread pool is being used. 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 said before the monadic approach can be quite clean. I haven't used implicit parameters that much, so I won't comment on them. Perhaps you can give an example? As I said, a single monad won't suffice for me, because different libraries only know about different parts of the state.
Re: [Haskell] thread-local variables
On 05.08 14:32, Frederik Eaton wrote: If it is documented maybe it could be done at the level of an implicit parameter? Do you think implicit parameters are better than TLS? Implicit parameters are explicit and the type checker guards that they are not undefined (and thus are safe in the presence of callbacks). I haven't used implicit parameters extensively because I prefer the monadic approach. 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. If you don't consider them different, then you can start using (2) instead of (1). Performance reasons or access to a shared resources. Also 2) would mean in many cases making currently local state global which is not nice. Can you give the API for your library? I have a hard time imagining how it could not be obvious that a thread pool is being used. e.g. various withFooResource :: (Foo - IO a) - IO a can use worker threads. As said before the monadic approach can be quite clean. I haven't used implicit parameters that much, so I won't comment on them. Perhaps you can give an example? As I said, a single monad won't suffice for me, because different libraries only know about different parts of the state. With TLS, one can delimit the scope of parameters by making the references to them module-internal, for instance. With monads, I imagine that I'll need for each parameter (1) a MonadX class, with a liftX member (2) a catchX function (3) a MonadY instance, for each wrapped monad Y (thus the number of such instances will be O(n^2) where n is the number of parameters) That is usually the wrong approach. Newtype something like StateT AppState IO. Use something like: runWithPart :: (AppState - c) - (c - IO a) - AppM a to define nice actions for different parts of the libraries. Usually this is very easy if one uses combinators and high level constructs and messier if it is hard to find the right combinators. If you look at the various web frameworks in Haskell you will notice that most of them live happily with one monad and don't suffer from problems because of that. With TLS, I need (1) a declaration x = unsafePerformIO $ newIOParam ... And don't have any static guarantees that you have done all the proper initialization calls before you use them. In the previous example we were using a lot of libraries using hidden state. How do we guarantee that they have valid values in TLS? Also if we have two pieces of the same per-thread state that we wish to use in one thread (e.g. db-connections) then the TLS approach becomes quite hard. Here is a naive and dirty implementation. The largest problem is that TypeRep is not in Ord. An alternative approach using Dynamic would be possible, but I like the connection between the key and the associated type. http://www.cs.helsinki.fi/u/ekarttun/haskell/TLS/ Not optimized for performance at all. - Einar Karttunen ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] thread-local variables
Sorry to jump into this thread so late. However, I'd like to take a moment to remind everyone that some time ago I put a concrete proposal for thread-local variables on the table. http://article.gmane.org/gmane.comp.lang.haskell.cafe/11010 I believe this proposal addresses the initialization issues that Einar has been discussing. In my proposal, thread-local variables always have some defined value, and they obtain their values at well-defined points. The liked message also gives several use cases that I felt motivated the proposal. -- Rob Dockins Talk softly and drive a Sherman tank. Laugh hard, it's a long way to the bank. -- TMBG ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] thread-local variables
As said before the monadic approach can be quite clean. I haven't used implicit parameters that much, so I won't comment on them. Perhaps you can give an example? As I said, a single monad won't suffice for me, because different libraries only know about different parts of the state. With TLS, one can delimit the scope of parameters by making the references to them module-internal, for instance. With monads, I imagine that I'll need for each parameter (1) a MonadX class, with a liftX member (2) a catchX function (3) a MonadY instance, for each wrapped monad Y (thus the number of such instances will be O(n^2) where n is the number of parameters) That is usually the wrong approach. Newtype something like StateT AppState IO. Use something like: runWithPart :: (AppState - c) - (c - IO a) - AppM a to define nice actions for different parts of the libraries. Usually this is very easy if one uses combinators and high level constructs and messier if it is hard to find the right combinators. If you look at the various web frameworks in Haskell you will notice that most of them live happily with one monad and don't suffer from problems because of that. That doesn't answer the question: What if my application has a need for several different sets of parameters - what if it doesn't make sense to combine them into a single monad? What if there are 'n' layers? Is it incorrect to say that the monadic approach requires code size O(n^2)? With TLS, I need (1) a declaration x = unsafePerformIO $ newIOParam ... And don't have any static guarantees that you have done all the proper initialization calls before you use them. Well, there are a lot of things I don't have static guarantees for. For instance, sometimes I call the function 'head', and the compiler isn't able to verify that the argument isn't an empty list. If I initialize my TLS to 'undefined' then I'll get a similar error message, at run time. For another example, I don't use monadic regions when I do file IO. I can live with that. ... Also if we have two pieces of the same per-thread state that we wish to use in one thread (e.g. db-connections) then the TLS approach becomes quite hard. No harder than the monadic approach, in my opinion. Here is a naive and dirty implementation. The largest problem is that TypeRep is not in Ord. An alternative approach using Dynamic would be possible, but I like the connection between the key and the associated type. http://www.cs.helsinki.fi/u/ekarttun/haskell/TLS/ Not optimized for performance at all. You've redefined 'fork'. If I want a library which works with other libraries, that will not be an option. The original purpose of my posting to this thread was to ask for two standard functions which would let me define thread-local variables in a way which is interoperable with other libraries, to the same extent as 'withArgs' and 'withProgName' are. Frederik -- http://ofb.net/~frederik/ ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Contexts on Data Declarations
Hello, I was just looking at the details of how contexts on datatypes work in Haskell'98 and I noticed the following. The report states that the context on a particular constructor should contain all those predicates that mention only variables that are in the fields of the constructor. This wording does not scale very well to mult-paramater type classes, and indeed Hugs (20050308) and GHC (6.4.1) do different things. Here is an example: class C a b data C a b = T a b = Mk a According to Hugs, Mk :: a - T a b, which follows the report: the constarint is not added because it mentions a variable, b, which is not in the fields of Mk. According to GHC, however, Mk :: C a b = a - T a b, which also makes sense if we interpret the report to mean: all those predicates that constrain a variable in the fields of the constructor. I know that contexts on data types are not a very popular part of the Haskell design, but it would be nice to be consistent. To me it seems that GHC's interpretation is the correct one. -Iavor PS: Appologies if this is fixed in later versions of Hugs, I don't have a newer version at the moment to try it out. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] thread-local variables
Hi Robert, I looked over your proposal. I'm not sure if I'm in favor of introducing a new keyword. It seems unnecessary. Also, note that my proposal differs in that thread local variables are not writable, but can only be changed by calling (e.g. in my API) 'withIOParam'. This is still just as general, because an IORef can be stored in a thread-local variable, but it makes it easier to reason about the more common use case where TLS is used to make IO a Reader; and it makes it easier to share modifiable state across more than one thread. I.e. if modifiable state is stored as 'IOParam (IORef a)' then the default is for the stored 'IORef a' to be shared across all threads; it can only be changed locally for a specified action and any sub-threads using 'withIOParam'; and if some library I use decides to fork a thread behind the scenes, it won't change my program's behavior. I think it is a good idea to have stdin, cwd, etc. be thread-local. I don't understand why the 'TL' monad is necessary, but I haven't read the proposal very carefully. Best, Frederik On Sat, Aug 05, 2006 at 02:18:58PM -0400, Robert Dockins wrote: Sorry to jump into this thread so late. However, I'd like to take a moment to remind everyone that some time ago I put a concrete proposal for thread-local variables on the table. http://article.gmane.org/gmane.comp.lang.haskell.cafe/11010 I believe this proposal addresses the initialization issues that Einar has been discussing. In my proposal, thread-local variables always have some defined value, and they obtain their values at well-defined points. The liked message also gives several use cases that I felt motivated the proposal. -- Rob Dockins Talk softly and drive a Sherman tank. Laugh hard, it's a long way to the bank. -- TMBG ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell -- http://ofb.net/~frederik/ ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] thread-local variables
Here is a naive and dirty implementation. The largest problem is that TypeRep is not in Ord. An alternative approach using Dynamic would be possible, but I like the connection between the key and the associated type. http://www.cs.helsinki.fi/u/ekarttun/haskell/TLS/ Not optimized for performance at all. You've redefined 'fork'. If I want a library which works with other libraries, that will not be an option. The original purpose of my posting to this thread was to ask for two standard functions which would let me define thread-local variables in a way which is interoperable with other libraries, to the same extent as 'withArgs' and 'withProgName' are. I also forgot to mention that if you hold on to a ThreadId, it apparently causes the whole thread to be retained. Simon Marlow explained this on 2005/10/18: m One could argue that getting the parent ThreadId is something that m should be supported natively by forkIO, and I might be inlined to agree. m Unfortunately there are some subtleties: currently a ThreadId is m represented by a pointer to the thread itself, which causes the thread m to be kept alive. This has implications not only for space leaks, but m also for reporting deadlock: if you have a ThreadId for a thread, you m can send it an exception with throwTo at any time, and hence the runtime m can never determine that the thread is deadlocked so it will never get m the NonTermination exception. Perhaps we need two kinds of ThreadId: a m weak one for use in Maps, and a strong one that you can use with m throwTo. But then building a Map in which some elements can be garbage m collected is a bit tricky (it can be done though; see our old Memo table m implementation in fptools/hslibs/util/Memo.hs). So this is another problem with your implementation, and another reason why I want TLS support in the standard libraries. Frederik -- http://ofb.net/~frederik/ ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] Compiling To C And Why Not Compiling To Java Or C#?
1 2 - Maybe this is not a proper question but I think It has a point. Why Not Compiling To Java Or C#? What is the need of implementing a class interoperability between Haskell and other plateforms? Maybe we donot need that. Haskell can be the big infrastructure and code snippets in Java or C# can serve in a monadic wrapper. It looks like that we can scripting Haskell in that languages. For example F# 's target code is ILX (an extension of MSIL for functional languages). But I think interoperablity between languages - like what .NET claims - is totaly pointless. Again think of an infrastructure that has a Haskell core which defines and controls very high level processes. Then there will be a running machine that Haskell is sitting on top of it. This running machine implement haskell in the plateform language. This is what I mean. 3 - And for an OOP style interoperability between languages, I think most usefull is to have a robust standard for Object-Broking. Something like IEC 61850 in new power systems in industry. A tool from siemens can understand what a hitachi high voltage key commands and all of these devices are from different providers with different internal implementations that meets the standard. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compiling To C And Why Not Compiling To Java Or C#?
I do not meant to compile Haskell to MSIL/JVM. I meant to compile Haskell to the Java or C# itself! And GHC will be there for a high performance language (but still O'Caml is better by the time). But Java proves that in enterprise solution, performance is a complex factor of many thing other than speed alone. I love high performance implementation like Haskell. But there must be a way to populize Haskell! Thanks ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Type hackery help needed!
Yes, this will surely do the trick, thanks a lot! :-) I got as far as defining a TypeEq class myself in one of my attempts, trying to trick the inference engine, but now seeing the full ingenuity of the TypeCast class I realize how far from the solution I really was. Again, thanks a million! /Niklas On 8/5/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: 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. It seems you might benefit from local functional dependencies, which are asserted per instance rather than for the whole class. They are explained in http://pobox.com/~oleg/ftp/Haskell/typecast.html Incidentally, that web page's source also gives an illustration of their use: http://pobox.com/~oleg/ftp/Haskell/typecast.hs The page itself is written in HSXML, which had to deal with a similar problem: in HSXML, 'p' is a polyvariadic function, which has to accept as many strings as the user cares to specify -- and in addition, arbitrary HSXML fragments like 'em', 'code', 'cite', etc. The latter are too built by polyvariadic functions. So, at some point I had to force the constraints and tell the functions that their arguments are over and they better give some data structure. Incidentally, that's where [] notation comes in quite handy. The brackets are not just the embellishment; by lucky accident, they actually force the constraints. BTW, the rendering of the above HSXML code checks local file links (and inserts the file sizes into the HTML code, while at it). There is a version of the HSXML rendering that, in addition to formatting Haskell code, passes it to a Haskell system to verify its typing -- and to optionally run it as well. The complete source code for the renderers is http://pobox.com/~oleg/ftp/Haskell/HSXML.tar.gz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Monad Imparative Usage Example
Kaveh Shahbazian wrote: 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 There are many tutorials available from the wiki at http://www.haskell.org/haskellwiki/Books_and_tutorials#Using_Monads and http://www.haskell.org/haskellwiki/Monad Another way is to look at the source code for the State monad and StateT monad transformer, then you can see that the mysterious monad is nothing other than a normal data or newtype declaration together with an instance declaration ie: -- from State.hs newtype State s a = S (s - (a,s)) instance Monad (State s) where return a = S (\s - (a, s)) S m = k = S (\s - let (a, s1) = m s S n= k a in n s1) So if you want to understand what's going on when you write: do x - q p a first step is to remove the syntactic sugar to get: q = (\x - p) and then replace the = with it's definition for the monad you're using. For example with the State monad, (q) must be some expression which evaluates to something of the form S fq where fq is a function with type s - (a,s), and similarly, (\x - p) must have type a -S ( s - (a,s)). If we choose names for these values which describe the types we have: q = S s_as p = a_S_s_as soq = (\x - p) ===S s_as = a_S_s_as ===S (\s0 - let (a1, s1) = s_as s0 S s_a2s2 = a_S_s_as a1 in s_a2s2 s1) If we use State.runState s0 (q = (\x - p)) to execute this composite action, from the source we see that: runState :: s - State s a - (a,s) runState s (S m) = m s so runState s0 (q = (\x - p)) ===runState s0 (S (\s0 - let ... in s_a2s2 s1)) ===(\s0 - let ... in s_a2s2 s1) s0 ===s_a2s2 s1 ===a2s2 -- ie (a2, s2) Anyway I hope I haven't made things more complicated! ;-) The best thing is to just try and work through some examples yourself with pencil and paper and read lots of tutorials until things start clicking into place. 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] Monad Imparative Usage Example
Brian Hulley wrote:
q = (\x - p)
For example with the State monad, (q) must be some expression which
evaluates to something of the form S fq where fq is a function with
type s - (a,s), and similarly, (\x - p) must have type a -S ( s -
(a,s)). If we choose names for these values which describe the types
we have:
q = S s_as
p = a_S_s_as
Sorry I meant:
(\x - p) = a_S_s_as
('p' and 'q' stand for arbitrary expressions that evaluate to monadic
values)
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] Compiling To C And Why Not Compiling To Java Or C#?
On 05/08/06, Kaveh Shahbazian [EMAIL PROTECTED] wrote: But there must be a way to populize Haskell! What for? Regards, Piotr Kalinowski -- Intelligence is like a river: the deeper it is, the less noise it makes ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Monad Imparative Usage Example
Very Thankyou I am starting to feel it. I think about it as a 'context' that wraps some computations, which are handled by compiler environment (please make me correct if I am wrong). Now I think I need to find out how this 'monads' fit in solving problems. And for that I must go through bigger programs to write. Thanks again ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why Not Haskell?
On Aug 4, 2006, at 11:10 PM, Bulat Ziganshin wrote: 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 Is this the paper you are referring to? Philip Wadler. Why no one uses functional languages. ACM SIGPLAN Notices, 33(8):23--27, 1998. http://citeseer.ist.psu.edu/wadler98why.html /Björn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] fast image processing in haskell?
Hello Chris, Saturday, August 5, 2006, 3:47:19 AM, you wrote: in Haskell before blitting the data (whilst also retaining some semblance of functional programming...) the best way to optimize Haskell program (with current technologies) is to rewrite it in strict imperative manner: 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 -- 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] Compiling To C And Why Not Compiling To Java Or C#?
Hello Antonio, Saturday, August 5, 2006, 7:07:17 PM, you wrote: But there must be a way to populize Haskell! What for? On the other hand, individuals that need to belong to an elite, and the RTFM crowd, will experience a further frustration to feed their insecure personality. there is an interesting psychotherapy procedure. if one can't raise some own ability, he can try instead to lower it. such attempts can help to understand how this ability can be raised so i propose opposite game: how can we decrease Haskell popularity? :) -- 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] Compiling To C And Why Not Compiling To Java Or C#?
Hello Kaveh, Saturday, August 5, 2006, 11:52:16 AM, you wrote: I do not meant to compile Haskell to MSIL/JVM. I meant to compile Haskell to the Java or C# itself! for what? btw, there is a jhc compiler (http://repetae.net/john/) that translates Haskell to ANSI C which allows to reach OCaml-level speed -- 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 Kaveh, Saturday, August 5, 2006, 10:16:06 AM, you wrote: 1 - monads : there must be something to make a clear tool for a none-mathematician programmer. (I still have understanding problems with them). http://haskell.org/haskellwiki/IO_inside and All about monads 2 - there must be an easy way to include existing libraries. There are many stable libraries in CPAN for perl, implemented in C for example. And why not to have a system for writing C in haskell? what you mean? Or an easy interface for using these codes without reimplementing haskell identities in C? there is FFI and several tools that easy defining interfaces for C libs. search at libraries and tools haskellwiki pages -- 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 Bjorn, Saturday, August 5, 2006, 6:59:33 PM, you wrote: yes, thank you 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 Is this the paper you are referring to? Philip Wadler. Why no one uses functional languages. ACM SIGPLAN Notices, 33(8):23--27, 1998. http://citeseer.ist.psu.edu/wadler98why.html -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compiling To C And Why Not Compiling To Java Or C#?
On 05/08/06, Antonio Cangiano [EMAIL PROTECTED] wrote: Because we are humans and as such, we generally love to share our passions with other people. From a less sociological standpoint, a larger user base implies faster development of interesting projects, more libraries, books, user groups, conferences, etc... Yes, yes. I'm simply not sure if making changes only to reach more and more people is good. On the other hand, individuals that need to belong to an elite, and the RTFM crowd, will experience a further frustration to feed their insecure personality. I'm afraid I don't understand what you mean. Would you care to elaborate on it? Regards, -- Intelligence is like a river: the deeper it is, the less noise it makes ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Monad Imparative Usage Example
Ooops - more bugs in my explanation... Brian Hulley wrote: -- from State.hs newtype State s a = S (s - (a,s)) I used the source given in ghc-6.4.2\libraries\monads\Monad\State.hs but the version of state monad that comes with the hierarchical libs is in ghc-6.4.2\libraries\mtl\Control\Monad\State.hs - the bits related to the explanation behave in the same way but you might find it interesting to decide which implementation is more readable since mtl uses record syntax and the other version doesn't. q = (\x - p) means that both q and p are expressions that evaluate to monadic values ie values whose type is of the form S (s - (a, s)) So we have: q :: S (s - (a, s)) (\x - p) :: a - S (s - (b, s)) Ooops! I meant: q :: State s a (\x - p) :: a - State s b therefore the *value* of q is of the form S (s - (a,s)) and the value of (\x - p) is of the form (a - S(s - (b, s))) To make the explanation simpler, we can rename the variables in the definition of = to reflect their types: to reflect the structure of their values Apologies for the millions of corrections and re-posts for this explanation - no matter how hard I try to proof read my posts something always slips through... ;-) Regards, Brian. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compiling To C And Why Not Compiling To Java Or C#?
On 8/5/06, Piotr Kalinowski [EMAIL PROTECTED] wrote: Yes, yes. I'm simply not sure if making changes only to reach more and more people is good.These changes are good as long as they possibly add something valuable beside popularity and they don't introduce significant downsides. My point was that the act of striving to increase the popularity of one's favourite language, it is neither a negative nor an unnatural pursuit. I agree though that it should be done intelligently and with a broader aim in mind. I'm afraid I don't understand what you mean. Would you care to elaborate on it?Sure. I meant that among small communities some individuals feel special for being part of these elite groups. It's a way to feel different, better, or something along these lines. Therefore they are afraid of any attempt to considerably increase the popularity of their group, because in their minds they would loose their special status (they can't brag they're Haskell hackers if the rest of the world programs in Haskell as well). Regards,Antonio-- My Ruby blog: http://antoniocangiano.comMy Italian community: http://www.visualcsharp.it ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why Not Haskell?
Henning Thielemann wrote: 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? :-) Hi Henning - Apologies for not replying sooner. I couldn't think what to say! ;-) Disclaimer: the following essay only contains 2 Haskell functions and is not intended to cause offence to farmers... Afaict a license such as GPL allows anyone, even a non-programmer, to just re-distribute whatever application you created because one condition of it is that anyone should be free to share software with anyone else without having to pay anything extra to the people who wrote it, and I think this is essentially based on the notion that software should not be regarded as an ownable or sellable thing. However a potato is sellable, even though farmers have such a great time out in the fields breathing in the fresh misty morning air and watching the beautiful colours of the sunrise, and basically just letting nature take its course with a bit of healthy exercise and free food thrown in for good measure (it might even be some of my personal sweat that evaporates and later falls as rain to nourish their crops). And what makes them think they have a right to own parts of the earth's surface anyway! ;-) While I'd personally like to live in a peaceful society where everything is freely available, the fact is that I have to deal with the situation I find myself in at the moment ie I have to pay money whevener I need food, electricity, gas, internet, petrol, dvds, music, art etc and I absolutely don't agree that everyone else in the world except software developers has the right to earn a living, while we just give everything away because it's so much fun bringing it into existence, or that we should be chastised for trying to charge for our efforts!!! ;-) Also, if we want a better world I can think of other professions to sacrifice (Hint: take 5 p = polit and last p = 'n'). Making complete end-user applications freely available is not always helpful to others, even to the end-users. Consider how a local corner-shop owner would feel if all the large supermarket chains stood outside his door giving away free food. The consumers are very happy! How selfless and beneficient those big supermarkets are! But how long would the corner-shop be able to stay open? And would the supermarkets continue to supply the free food after they'd finally wiped out his business? People no longer meet for a chat at the corner-shop. There is a void in the community. People start to feel alienated. Houses are vandalised. Crime is on the increase. The government claims it needs more powers to prevent it. Perhaps a few people see what's happening but really it's already too late... Of course from a pragmatic point of view it is useful for developers to share parts of their source or coding ideas, since there is clearly too much work for any one person to do, thus BSD and LGPL make a lot of commercial sense, as well as being a nice gesture of fraternity between coders, and a blueprint for the future if we can only find the right strategies to achieve it given our own specific individual circumstances. Therefore I think licenses which enforce a particular strategy or attempt to limit possible business models to further a specific agenda, however well meaning they may appear, are unattractive for commercial development in general, even though some specific niche companies can manage fine under those conditions (eg consultants/ trainers/ contracted developers etc). 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] fast image processing in haskell?
bulat.ziganshin: Hello Chris, Saturday, August 5, 2006, 3:47:19 AM, you wrote: in Haskell before blitting the data (whilst also retaining some semblance of functional programming...) the best way to optimize Haskell program (with current technologies) is to rewrite it in strict imperative manner: Strict, very often, since we get unboxed types out of ghc. Imperative, not always (and will be less so with Data.ByteString -- since we don't need to drop into IO to get peek/poke). -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] REALLY simple STRef examples
Thanks, Simon. I've begun putting together some text describing very
simple STRef examples, as Bulat suggested earlier. I think I know how
to make it work, but I'll still need to work on typing subtleties. I'm
headed to bed now, but I'll go through this in detail when I get a
chance to try to get my head around it.
-Chad
On 8/4/06, Simon Peyton-Jones [EMAIL PROTECTED] wrote:
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!
--
Chad Scherrer
Time flies like an arrow; fruit flies like a banana -- Groucho Marx
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
