Re: [Haskell-cafe] Errors in non-monadic code
jabolo...@google.com : I would like to see more code move away from exceptions and into types like Maybe or Either or other types defined for the particular situation (as some people were suggesting in the beginning of the thread). And the reason for this it is because when you program against types you have to make a decision whether to handle the error or let it bleed through: you can't ignore the choice because you can't ignore the type. On the other hand, with exceptions, you can easily forget to handle the exception if you're not looking at the documentation at the time when you write the code. Tom Ellis: This is/exactly/ the reason to avoid exceptions where possible. I disagree. Types which neutralize some particular conditions (whether you call them exceptional or not is conventional) and propagate Nothing etc. is not a panacea. Some exceptions, e.g. in the traversal of deep structures may be and ARE used as escaping continuations. Calling all that not the right thing to do, or issuing other normative statements is, how would I express it... , is not the right thing to do. Now you can add here some dozen smileys... More seriously, some people like exquisite continuations and will use them. Instead of fighting against exceptions it might be more fruitful to make them more robust, powerful, parametrable and sexy. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Errors in non-monadic code
Le 20/08/2013 00:19, jabolo...@google.com a écrit : If I understand correctly, by escaping continuations you mean that you can easily transfer control between the point where the exception is raised and the exception handler. If this is what you mean, you can achieve the same effect with monadic code by chaining monads together Yes. José, this is mainly the question of efficiency. You don't need to establish contact between the distant stack frames, and you may propagate failures if this happens seldom. But if the escaping continuation is a frequent case, it might be more economic to jump. This is as simple as that. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some philosophy
Kim-Ee Yeoh comments my reading suggestion: Indiscrete Thoughts by Gian-Carlo Rota, published by Birkhäuser in 1997. Available on the Web. [I forgot where] I'm rather fond of Rota's two volumes of musings. For the purpose of furthering the quality of philosophizing, would it not be better served citing the relevant chapters, if not the actual page numbers? As you took note, the book covers a swathe of topics. Shall I also give the line numbers, Kim-Ee? The book of Rota is divided into parts and chapters, with titles. It is not so difficult to find quickly that something may (or not) interest you. What is a relevant chapter in a collection of philosophical essays? You might skip the biographies of some mathematicians, with some unpleasant fragments, if you are not interested. I liked a few others. Part II, Ch. VII: The Pernicious Influence of Mathematics Upon Philosophy is an inspired attack addressed at the analytical philosophers who felt really offended! (This is a reprint from the Journal of Metaphysics, published also in the book 18 Unconventional Essays on the Nature of Mathematics, Springer, ed. by Reuben Hersh. I also recommend it [also on the Web], it is plenty of serious wisdom, although sometimes hard to read.) This chapter deals with the non-philosophical essence of logic, with the philosophical vacuity of formal definitions. Very inspiring. For Rota the question of IDENTITY is more important than that of EXISTENCE. The chapter XII: Syntax, Semantics, and the Problem of the Identity of Mathematical Items (p. 151) begins his presentation of the subject, which continues later. Rota exposes some reasoning based on his favourite philosophical topic, the phenomenology, continuing previous sections. This may not convince you (e.g. if you are an orthodox materialist...), but you might learn something. The chapter about /Fundierung/ (XV, p. 172) in which Rota fights against the reductionism, may give you a headache. But you should survive. Anyway, /a ciascuno il suo/. Jerzy K. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Some philosophy (Was: Alternative name for return)
I have the impression that a nice part of our dispute comes from the fact that despite our ambitions, and a decent /technical/ level of understanding of what we are talking about, most of us are (and I am one of the worst...) -- -- pitiful philosophers... Really bad... Confusing the contents and the function/role of the entities, using ambiguous definitions (and confounding objects with their definitions), et j'en passe. Sigh. I decided to reread some philosophical texts, and I suggest one for your evening reading. Indiscrete Thoughts by Gian-Carlo Rota, published by Birkhäuser in 1997. Available on the Web. Rota was an active *mathematician* and teacher, and the sense of mathematical constructs was very important for him. It is a very refreshing book, you won't be disappointed. (It contains also some personal views of Rota on his fellows mathematicians. And the analysis of the difference between characters who are problem solvers, as contrasted with theoreticians... Rota was a strong personality, full of obsessions, and his ideas on the soundness of formal thinking may not convince you, but you should find them interesting. And you will find inside that for Rota the term should is very important, even if it impossible to define...) Many thanks to Olivier Danvy, who recommended me this book! Jerzy Karczmarczuk Caen, France. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Identity of indiscernibles (Was: Alternative name for return)
Tom Ellis: If I were writing a Haskell compiler I could certainly define 'IO' to be a datatype that would allow me to compare 'putStr c' to itself. The comparison could not be of operational equivalence, but it would still be possible to compare values in IO in a reasonable sense. Would you add to all this: getLine == getLine etc.? Good luck! I suspect that you would have to establish also the equality relation between functions and between infinite streams. And you would end as Giordano Bruno and Jeanne d'Arc. But for different reasons. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Identity of indiscernibles
I am sorry for having mixed-up arguments (but who throws the first stone?...) Jerzy seemed to suggest that the impurity of IO was somehow related to it not supporting very many operations. No, not really. I added First, it is not true that you can do with, say, (printStr Ho! ) whatever you want. In fact, you can do almost nothing with it. You can transport it as such, and you can use it as the argument of (=). after the message of Jake McA. /You can do whatever you want with them/ with no harmful effects in any Haskell expression. This was an additional layer of bikeshedding, not exactly about purity. Or, just a bit: the ONLY real operation on an action, i.e. (=) produces side-effects... Other don't, but -- Again, here my point is that calling pure an entity which is opaque and inert, is meaningless (or redundant if you wish...), this was all. Jerzy K. PS. Tom Ellis: One could simply implement IO as a free monad Interesting. I wonder how. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alternative name for return
Richard A. O'Keefe : Haskell has*trained* my intuition to see 'putStrLn Hi' as a pure value; it's not the thing itself that has effects, but its interpretation by an outer engine, just as my magnetic card key has by itself no power to open doors, but the magnetic reader that looks at the card _does_. I am the last here who would quarrel with Richard O'K., but I firmly believe that such reasoning is a Pandora box. The King, the government, the Pope, etc. have no power, only the interpretation of their decrees by outer agents _does_ things. Saying that the Justice of the country X is lousy is a harmful abuse. Our Justice is good, only its interpretation by some incompetent traitors gave rise to all these calamitous events. You see what I mean?... Are we going to switch now to the Mind-Body dilemma? == BTW. Saying that 5 is a pure value means only that the whole of the underlying system treats it as such. The object 5 couldn't care less. It even doesn't know that in some programming language it is equivalent to an action which puts it on the evaluation stack. That's why for me the purity (while teaching I try to avoid this word) means simply that whatever you do with the object, it won't fire a magic process. As Richard, I do not claim that this is right, but it surely facilitated my teaching of Haskell. My students have already more than enough of my /philosophie de pacotille/... Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alternative name for return
Bardur Arantsson comments the comment of Joe Quinn: On 8/7/2013 11:00 AM, David Thomas wrote: twice :: IO () - IO () twice x = x x I would call that evaluating x twice (incidentally creating two separate evaluations of one pure action description), but I'd like to better see your perspective here. x is only evaluated once, but/executed/ twice. For IO, that means magic. For other types, it means different things. For Identity, twice = id! Your point being? x is the same thing regardless of how many times you run it. What do you mean by the same thing? You cannot compare 'them' in any reasonable sense. This, the impossibility to check putStr c == putStr c, is btw, a refutation of the claim by Tom Ellis that you can do even less with (). The void object is an instance of the Eq and Ord classes. And of Show as well. You make the distinction between evaluate, and execute or run, etc. This is not functional. Your program doesn't run anything, it applies (=) (or equivalent) to an IO (...) object. This is the only practical evaluation of it, otherwise it can be passed (or duplicated as above). But you cannot apply bind twice to the same instance of it (in fact, as I said above, the same instance is a bit suspicious concept...). The running or execution takes place outside of your program. In such a way Richard O'Keefe and I converge... That's why I say that the concept of purity is meaningless in the discussed context. It is a kind of counterfeit notion, inherited from pure functions to something which belongs to two different worlds. Jerzy Karczmarczuk PS. I believe that some impure remarks about the familiarity of X or Y with English do not belong to this forum. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alternative name for return
What about X, Y, Z, ... We have seen this discussion already a long time ago. The terms unit and result have been proposed. And others. Somebody (I forgot who) advocated even the name monad in this context. And this might have continued forever... With all my respect, I see that Haskell reached finally the Noble Domain of Philosophy. I mean, instead of discussing concepts, people begin to discuss names. And since for some, even IO () is a pure value, I suspect that the next round will rekindle the discussion on the word pure... Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alternative name for return
Le 06/08/2013 11:01, J. Stutterheim a écrit : ... So in reply to Jerzy, I do want to encourage the discussion in the Noble Domain of Philosophy and I also want to repeat that I am not proposing to change Haskell or Haskell libraries Jurriën, I taught Haskell for several years. I saw the disgraceful confusion in heads of my students whose previous programming experience was based on Python, and who learned Haskell and Java in parallel. So, I won't claim that names are irrelevant. And return in particular. However, my personal philosophy is the following: accept the fact that words in one language -- formal or natural -- mean something different than in another one. [[In French the word file in computerese is queue in English; this is in fact a French word meaning tail in English, and I have several dozens of such examples... And so what?...]] It is good to choose consciously some good names while elaborating a standard. But getting back to it after several years, is -- for me -- a waste of time. This, unfortunately, pollutes the true philosophy as well. I believe that at least 80% of the progress in the philosophy of religions belongs to the linguistic domain. The anglosaxons corupted the word semantics, used in a pejorative sense: discussion about superficialities, the words, not the concepts, while the true semantics is about the true sense. So, sorry for being sarcastic, or even cynical in my previous post, but I sincerely think that oldies are oldies, let them be, and work more on issues that are still evolving. All the best. Jerzy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alternative name for return
Le 06/08/2013 14:47, Jake McArthur a écrit : ... But IO actions *are* pure values. What side effects do they have? None! /You can do whatever you want with them/ with no harmful effects in any Haskell expression. They only special thing about them is that they have a run function As I said, -- *Now Is The Time* -- [[choose your reference of this Original Expression; perhaps the albums of Alanis Morissette or that of Jeff Lorber...]] ... to discuss the Purity. Go ahead and good luck. Unfortunately I belong to a Cretacean generation, for whom the Referential Transparency means something, so I don't believe you, Jake. I am not saying that you are wrong. I say that calling an action a pure /value/ is almost meaningless. 1. First, it is not true that you can do with, say, (printStr Ho! ) whatever you want. In fact, you can do almost nothing with it. You can transport it as such, and you can use it as the argument of (=). 2. This is the only way you can evaluate your pure value, and because of the monadic chaining, you cannot do it twice, you cannot re-evaluate it. You know all this as well as I do, perhaps better. That's why the purity here is dubious (although, unless I am mistaken, all functional constructs are considered pure by Wadler...). 3. Brandon Albery is (in my eyes) right: what's impure about lifting 5 into Maybe or []? `pure` feels IO-targeted. A list, such as (return 5) in the List/Nondet Monad may be treated as a normal data item. But a IO action, or a IoRef mutable reference -- not really, they are Magic. If you claim that Magic is Pure, I abandon the ring. For me the Magical entities (i.e., the entities which are controlled by some layers UNDER the one YOU control) are impure, since there is no operational definition of purity for them. No side effects? Sure, if you don't do anything with it. Even the most horrible Devil is pure. Unless you call it... Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Probabilistic functional programming with Baysig/BayesHive
Le 09/07/2013 13:53, Tom Nielsen a écrit : Almost everything else -- optimal decisions, categorisation, (...) -- becomes trivial. Optimal decisions trivial? Interesting... And not so frequent... Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (no subject)
Hm... Haskell was /developed/ by teams, but we had BEFORE: hope, miranda, ML ... The heritage is quite important. And individuals (say, Mark Jones) contributed to Haskell constructs. So, the /design/ is not entirely committe based 1. Promise to me, and the rest of the community, that Haskell will always spiritually remain the same clean, consistent programming language as it is now! Yes. Dear Mom, dear Dad! Promise me that you will never die... I wish that for all of you. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] list comprehension doesn't work
MATEUSZ, There is nothing wrong with sending beginner questions to h-café! After all, a FRIENDLY community is for whom? For Simon PJ only? Notice that John got more than a dozen answers, people TRY to help him anyway. == On the other hand, the original requester *should* have thought on: 1. Putting down in a concise, but explicit manner what was for him the expected result. And also: 2. Writing what were the errors signalled by the system. But no, we had just help!, nothing works. This should be avoided, some people are reluctant to analyze situations too obscure, even if one almost-syntax error was clear... Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Looking for portable Haskell or Haskell like language
Christopher Howard: I was wondering if there was perhaps another language very similar to Haskell (but presumably simpler) with a super portable compiler easily built from source, which I could try. I'll admit -- I haven't tried the HUGS compiler for Haskell. The quick description didn't make it sound much more portable than GHC, but I guess I could try it if I heard some good reasons to think it would be more portable. Is the portability which worries you, or the age of your system? Hugs (and Gofer before) are simply sufficiently old... I used them on Red Hat in one of my previous lives. Do you really need to compile your system from sources? There are binaries everywhere. If you want a *simpler* language, perhaps try Miranda? Also a quite ancient language... Or, perhaps a newer one, in some aspects simpler than Haskell (but far from any simplicity): Clean. Perhaps it might help to know what do you need it for... The best Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Yampa integral function
Le 17/04/2013 00:36, felipe zapata a écrit : Hello, I'm trying to write some simulator of physical systems using Yampa. The fundamental idea is to integrate the position and velocity, using the following algorithm: ... ... Nothing to do with Haskell. Where do you get this factor 0.5 in your formula: v = v0 + integral ( 0.5 * force * recip mass) ? With constant acceleration v=v0+a*Dt = 1.01, not 1.05 What is that: let x = x0 + vdt2 ?? Again, a constant acceleration movement gives : x = x0 + v0*Dt + a*Dt^2/2. Yampa or not Yampa, I suspect that your implementation of physics is simply wrong. == In general, even correcting all, you might have reasonable results in some trivial cases, but in general the extrapolating Euler schema is unstable, produces growing errors (e. g. in the oscillating case). Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Yampa integral function
Le 17/04/2013 01:48, Jerzy Karczmarczuk a écrit : With constant acceleration v=v0+a*Dt = 1.01, not 1.05 Gosh, trivial errors seem to be contagious. Of course I meant 1.1, not 1.01. Sorry. JK ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] NaN as Integer value
Franco answers a question : Hello haskellers,is there a reason why Integer doesn't have 'NaN' as value?I think it would be very convenient to be able to handle (1 `div` 0) as regular NaN value and not as exception.Thanks. I think because, if you need NaN like values, `Maybe Int` does the same job without tainting the definition of `Int`. This is not a Haskell problem. For Ints, ALL representations are valid numbers, a NaN is a specific float object, unless I'm mistaken, so the introduction of such an abnormal number would require some serious modifications of the representation. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] education or experience?
Roman Cheplyaka comments a post by Christopher Howard: I'm trying to decide, however; should I go back to school, finish my B.S. and pursue a Masters in CompSci? Or would the time (and money) be better spent aggressively pursuing volunteer work for companies, hoping to eventually get the experience and contacts that lead to a paying job? To be honest, I don't really want to go back to school, because I learn a lot faster (and more economically) on my own. However, I'm not sure which path is the fastest, and safest, approach to an actual paycheck. If you have some money to cover your expenses, consider learning by contributing to open source software. Compared to an academic career, you'll have a more real goal of making good software (instead of publishing papers). Also, this experience will be much more relevant for your future job. Compared to work for companies, you can choose more challenging, interesting and innovative tasks that most companies can offer. And the code quality will often be higher in open source than in companies. Roman For me, opposing experience and education is simply silly. Probably more than 70% of all people would learn much faster on their own than at school. But, learn WHAT? : 1. Probably less than 1% would guess correctly what they SHOULD learn, and 2. in general they will not be able to assess their own knowledge... Learning, for most people, is a social process. If Mr. Howard thinks that he is a kind of Srinivâsa Râmânujan, good luck, but the statistics is against him. With a chance, he will master very well one or two tools, but without a more structured background, the creativity in the domain of software might be severely limited. If a necessity of refactoring his fabulous product means more learning ab ovo, the loss of time might be considerable. Roman: - Christopher Howard seems to be very far from publishing papers; he asks us whether he should complete his B.S. In this context, recommending Open Source seems a bit premature. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Iterations (Was: Re: Darcs fetches too little files)
Le 29/08/2012 23:55, Henk-Jan van Tuyl a écrit : In conclusion: repeating the same thing could give different results. Certainly! My favourite example is : sex. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to select n random words from a file ...
KC: An interesting related problem is if you are only allowed one pass through the data how would you randomly choose one word. Let's choose n items. You must know the length of the sequence, of course, otherwise the 'probability' loses its sense. So, for lists it might not be just one pass... Suppose the length of the sequence be m. Suppose you have a random generator called rg, just a simple function which transforms: seed - seed' , between 0 and 1 Make n and m real to make the typechecker happy. Then the most straightforward solution for lists is: nran l n = nr l m n seed where m = fromIntegral(length(l)) nr [] _ _ _ = [] nr (x:q) m n seed = let seed'=rg seed in ifseed' n/m then x:nr q (m-1) (n-1) seed' else nr q (m-1) n seed' -- = Now, you may make it tail-recursive, use a different random generation protocol, or whatever. I believe that this solution is known for years... Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can Haskell outperform C++?
Roman Cheplyaka: If you're saying that in C an explicit stack should have been used instead of recursion, then it would increase the code complexity while having non-obvious performance benefits. This is a fragment of a bigger message I won't comment. But THIS is a little dubious. You may accuse anything of anything by such vacuous statements as non-obvious performance benefits. If the stack frame allocation policy is lousy (not because of incompetence of the compiler writers, but because of its universalism), then the gain may be quite visible. My favourite examples are the classical flood fill algorithms for filling closed regions in computer graphics, and also some models of percolation (finding paths in rather big graphs). Everything depends on the language used, but I have seen the acceleration by a factor of 5 after having replaced the recursion by explicit stacks + loops. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] adding the elements of two lists
Le 26/03/2012 02:41, Chris Smith a écrit : Of course there are rings for which it's possible to represent the elements as lists. Nevertheless, there is definitely not one that defines (+) = zipWith (+), as did the one I was responding to. What? The additive structure does not define a ring. The multiplication can be a Legion, all different. Over. Jerzy K ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] adding the elements of two lists
Le 26/03/2012 16:31, Chris Smith a écrit : If you were asking about why there is no ring on [a] that defines (+) = zipWith (+), then here's why. By that definition, you have [1,2,3] + [4,5] = [5,7]. But also [1,2,42] + [4,5] = [5,7]. Addition by [4,5] is not one-to-one, so [4,5] cannot be invertible. So, * the addition* is not invertible, why did you introduce rings to this discussion, if the additive group within is already lousy?... OK I see now. You are only interested in the explicitly ambiguous usage of the element-wise addition which terminates at the shortest term... But I don't care about using (+) = zipWith (+) anywhere, outside of a programming model / framework, where you keep the sanity of your data. In my programs I KNEW that the length of the list is either fixed, or of some minimal size (or infinite). Your [4,5] simply does not belong to MY rings, if I decided to keep the other one. Jerzy K. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] adding the elements of two lists
TP : However, it seems it is not possible to do that: --- instance Num [Int] where l1 + l2 = --- Why? Why not?? It is possible. All what has been said by other people is right. But you can do it your way as well, GHC won't protest if you :set -XFlexibleInstances . (Then you might have some other small problems, but nobody is perfect). Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] adding the elements of two lists
Le 26/03/2012 01:51, Chris Smith a écrit : instance (Num a) = Num [a] where xs + ys = zipWith (+) xs ys You can do this in the sense that it's legal Haskell... but it is a bad idea to make lists an instance of Num, because there are situations where the result doesn't act as you would like (if you've had abstract algebra, the problem is that it isn't a ring). More concretely, it's not hard to see that the additive identity is [0,0,0...], the infinite list of zeros. But if you have a finite list x, then x - x is NOT equal to that additive identity! Instead, you'd only get a finite list of zeros, and if you try to do math with that later, you're going to accidentally truncate some answers now and then and wonder what went wrong. In general, most type classes in Haskell are like this... the compiler only cares that you provide operations with certain types, but the type class also carries around additional laws that you should obey when writing instances. Here there's no good way to write an instance that obeys the laws, so it's better to write no instance at all. Sorry, Chris, I disagree quite strongly. You begin badly: the problem is that it isn't a ring. Who told you so? It MIGHT be a ring or not. The real problem is that one should not confuse structural and algebraic (in the classical sense) properties of your objects. 1. You may consider your lists as representants of polonomials. A very decent ring. 2. I used hundred times lists as representants of power series. Infinite, potentially, but often having just finite number of non-zero coefficients, and if those could be divided, the list was not only a ring, but a field. (Doug McIlroy did that as well, and his papers on power series are much better known than mine...) And NO, no truncation problems, if you know how to program correctly. The laziness helps. 3. A very similar stuff to series or polynomials is the usage of lists as differential algebras (uni-variate). I needed not only the numerical instances, but a derivation operator. A ring, a field, *different* from the previous ones. 4. I wanted to have the trajectories - the numerical sequences which were solutions of differential equations, to behave as mathematical objects that could be added, scaled, etc. A vector space, and much more. 5. I used lists as signals which could be added (sound composition), multiplied (modulation), etc. Good rings. Totally different from the previous ones. Whether it would be better to use some specific ADT rather than lists, is a question of style. The fact that - as you say - there's no good way to write an instance that obeys the laws won't disturb my sleep. You know, there is no good way to organise a society where everybody obeys the Law. This is no argument against the organisation of a Society... Thank you. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Are there arithmetic composition of functions?
Richard O'Keefe : You may have no intention of discussing the issue, but it seems to*me* that this will not work in 2012 Haskell compiler mostly conforming to Haskell 2010 because Haskell 2010 says it shouldn't work is a pretty sound position to take. The existence of standards is not an answer concerning their goodness. The numerical properties of objects are orthogonal to their external representation, and often to the possibility of asking whether they are equal. I used Haskell to work with *abstract* vectors in Hilbert space (quantum states). Here, the linearity, the possibility to copute the representants (Dirac brackets : scalar products), etc. is essential. And they are functional objects. In a slightly more abstract than usual approach to differential geometry, the concept of vector is far from a classical data structure. It IS a linear mapping, or, say a differential operator. Again a functional object. There are approaches to stream processing, where streams are functions, and some people would like to add them independently of their instantiations as sequences of numbers. == I think that many people agree that Num was not the best idea... This class combines the addition with the multiplication, which is not explicitly natural, and it has been done probably because of the simplicity of the vision of the Authors : there are integer numbers, there are reals (which ask for a special class with division), and that's it. You cannot compute the exponential [using the standard name] of a power series, unless you declare this series, which may be a list of rational coefficients, a Floating. Thank you. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Are there arithmetic composition of functions?
Richard O'Keefe: class (Eq a, Show a) = Num a where (+) (-) (*) negate abs signum fromInteger where functions are for good reason not members of Eq or Show. This is an old song, changed several times. I have no intention to discuss, but please, Richard O'Keefe: WHICH *GOOD* REASONS?? Thank you. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Theoretical question: are side effects necessary?
KC comments the posting of Donn Cave referring to the soundness of some potential approach of software engineers: Apparently on such solid ground that you hinder their critical thinking skills by answering for them Monsieur KC, do you want to discuss, or just to be cute? In both cases, begin by signing your posts. I will not discuss with an anonymous, and concerning your question about referential transparency, I permit myself to send you to some standard literature. Over. == Chris Smith: When we're talking about different uses of the word function in programming languages, side effects refer to any effect other than evaluating to some result when applied to some argument. For example, in languages like C, printf takes some arguments, and returns an int. When viewed as just a function, that's all there is to it; functions exist to take arguments and produce return values. But C extends the definition of a function to include additional effects, like making Hello world appear on a nearby computer screen. ... And here I disagree. If printf, or whatever explodes an atomic bomb, this is not a side effect. If a procedure executes such a statement: x = x+1, or a[1]=a[2], it IS. And even that, not always ! In Clean, which is as pure as Haskell, there are unique access variables, and it is possible to write (+/-...) # myFile = write myFile Hello World And the point is that WHATEVER happens to the outer world, and the computer file system in particular, there are no side effects within the program. The # construction is a temporal, sequential part of a purely functional expression, exactly as a monadic chain in Haskell, disguised as a do block. There are two distinct file objects, the previous, and the next one, which happen to share the same name, because *the type system* prevents that a computing block refers to both. Either the old, or the new. This is my philosophy. If somebody disagrees, that's alright. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Theoretical question: are side effects necessary?
Ryan Ingram: Other external state is harder to emulate. For example, communication over a network most definitely requires some concept of a 'computation with side effects' since the network's response could change from request to request. In GHC, even IO objects are pure, but they conceptually represent functions that modify the state of reality. I believe I begin to become a sectarian, with some idées fixes not so well shared... It is the third or the fourth time that somebody recently puts the equivalence between the communication with the outer world, and side effects. I contest that very strongly, perhaps a TRUE guru might instruct me. What a computer and the program it runs do to its hard environment has NOTHING to do with side-effects. Even a completely angelic, pure as a Cherub (but real) program will consume some electricity. And so what?! Of course, in classical physics the state of the world changes constantly (in a quantum world it is extremely ambiguous...), but the question of purity of a program - in my opinion - concerns the program, and nothing else. The networking is not expected to break the referential transparency, or does it? Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] If you'd design a Haskell-like language, what would you do different?
John Meacham : The fact that bottom is a value in Haskell is the fundamental thing that differentiates Haskell from other languages and the source of its power. The fact that f _|_ /= _|_ potentially _is_ what it means to be a lazy language. Not treating _|_ as a value would be a huge disservice to anyone learning the language. Sure, it may seem a little strange coming from the imperative world to think of it as a value, but it is by far the oddest concept in Haskell, after all, _functions_ are values in Haskell and people seem to eventually figure that out. Well... Personally I hate thinking about bottom as value. I don't do this. I NEVER teach that. And, I am a lazy guy, almost all my Haskell programs are strongly based on laziness. I'll tell you what I teach, and you might throw some tomatoes... The fundamental thing that differentiates Haskell from other languages and the source of it power - if I might cite you - is that we don't see the difference between an object and the process which creates it. (The difference demands that we speak about the call-by-need, etc...) The bottom, as sin (2*pi), or Text may be seen as processes. Anyway, a lazy list IS a process /par excellence/. The _|_ entity is a process which refuses to give you a value (or does it in a deadly way). Your program manipulates processes. A process in some computational context must do something - or not. The bottom never does anything useful. All this is probably a question of language, of terminology, of preconceptions (of all that, what for God knows which reasons, Americans call just semantics), but I will not forget the day when I thought as you, and I had to explain to 2-nd year students what does it mean: a value which doesn't have a value... Thank you. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mersenne-random and standard random API
Aleksey Khudyakov : I think design of Random type class basically precludes efficient generators with large periods and consequently large state. Look at next function: next :: g - (Int, g) It means that state has to be copied but for efficiency we want to mutate it in place. I consider Random type class a failure and ignore it. P.S. For monte-carlo and thing like that I'd recommend mwc-random it more featureful than mersenne-random and don't rely on global state I am afraid that Aleksey Khudakov confuses a few things. 1. Mersenne Twister, AND congruential generators AND the Marsaglia stuff, all use some kind of seed, all are stateful. There are no miracles. Just look the agressive monadization, the form of defaultSeed, etc. within MWC.hs, before saying that this generator doesn't rely on some global state. 2. In the standard generator stuff the state is stored in IoRefs and is not copied. Did Aleksey ever look inside the sources of these generators? In any case, the seed changes after each generation, and must be stored somewhere. 3. The API question is a conventional one. People who are really unhappy, may make their own interfaces, or give such a mini-project as a students' assignment, instead of weeping that the library is lousy and should be ignored. E. g., I wanted random numers in some purely functional, lazy context, and I didn't want the existing interface ; I manufactured a lazy stream interface, and that was all. Look Ma!: no global state... 4. L'Ecuyer signalled some 15 years ago that MWC generators introduce some bias on the most significant bits (complementary MWC are safer). This is less annoying that the last bits periodicity of simple congruential generators, but for SOME Monte-Carlo it may be harmful. === In general, I believe that saying publicly that some part of the available library is a failure, should be avoided, unless accompanied by some SERIOUS analysis, and - if possible - some constructive suggestions. With my thanks to all people who made those generators however imperfect they are. Only Mister Nobody is perfect. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mersenne-random and standard random API
Aleksey Khudyakov: On 09.02.2012 15:32, Jerzy Karczmarczuk wrote: 1. Mersenne Twister, AND congruential generators AND the Marsaglia stuff, all use some kind of seed, all are stateful. There are no miracles. Just look the agressive monadization, the form of defaultSeed, etc. within MWC.hs, before saying that this generator doesn't rely on some global state. I think you are missing the point here. Surely all PRNG carry some state around. But both StdGen and mwc-random (and likely many others) allow to have many generators at once (for use in different threads) This is irrelevant. I believe that there is a misunderstanding in terminology. When I say global state it means not a local variable in some function. You seem to say one object per programme. This is confirmed by: mersenne-random is just wrapper around vastly impure library (as documentation says) and allows only one genrator per program. This is why I said it uses *global* state In any case, the seed changes after each generation, and must be stored somewhere. No. It doesn't and cannot data StdGen = StdGen Int32 Int32 If generator state is stored in IORef it's not possible to implement `next :: g → (Int,g)'. To do something useful with it one have to go to IO monad but we can't. So state have to be copied. We can't WHAT? Look, all data that change or are created MUST be stored somewhere, don't say dubious things. Your next function is a threading generator, which makes another StdGen, OK, but this is not a copy. This is a creation of a new seed. When I spoke about IORefs, I thought about the global generator, which USES the l'Ecuyer stuff, newStdGen and its friends. The threading becomes implicit. Try, say r=newStdGen r = return . next and you will see, it works, and you don't keep explicitly your seed. From the efficiency point of view all this is comparable. With IOrefs you do not pollute the memory which has to be garbage-collected, but its administration is heavier than the standard heap operations. StdGen with l'Ecuyer two-number seed, or some 600 of the Mersenne, I don't see a conceptual difference. The Marsaglia generator has a global seed quite voluminous as well. ...sometimes it's not possible to implement some algorithms for particular API. For example if PRNG rely on in-place array updates it cannot implement Random type class. No idea what do you mean. In the Random library you will find the generators using IORefs, AND the class Random, with the member random (or randomR, etc.) and you may write getStdRandom random getStdRandom random ... as you wish, getting different results. What's wrong with that? Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
Conal Elliott cites Steve Horne: I look at this World parameter as purely hypothetical, a trick used to gain an intuition. Whereas Jerzy (I think) uses it to claim Haskell is referentially transparent - those differing x and y values come from different worlds, or different world-states. I don't see this interpretation in Jerzy's words, and I'd be very surprised if he had that sort of argument in mind. I don't think either having used the 'World' model as an argument of the referential transparency. The main reason is that I don't know what does it mean, the referential transparency of the real world. There is a philosophical issue involved: the problem of IDENTITY, which is as old as the humanity, and it will survive it... We simply don't know what does it mean: the same... But I disagree quite strongly with the idea of /World parameter as purely hypothetical, a trick used to gain an intuition/. I mentioned the language Clean (no reaction, seems that Haskellians continue to ignore it...) In Clean this IS the IO model. You have such entities as FileSystem, which has the Unique Access property, etc. You can put all that in an equivalent of the IO Monad, constructed within Clean itself, not as a primitive. Jerzy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
Dan Doel : ... Also, the embedded IO language does not have this property. do x- m ; f x x is different from do x- m ; y- m ; f x y and so on. This is why you shouldn't write your whole program with IO functions; it lacks nice properties for working with your code. Sorry, what are you trying to suggest? You show two OBVIOUSLY different pieces of code, and you say that they are different. If, by chance, some newbie reads that and gets the impression that (-) is something equivalent to (=), you are serving the devil. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Are all monads functions?
Yves Parès : all standard Monads are newtypes wrapping functions What about Maybe and [] ? Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (...) Random generators
Bardur Arantsson: Random streams are not referentially transparent, though, AFAICT...? Either way this thread has gone on long enough, let's not prolong it needlessly with this side discussion. Sure. But the discussion on randomness is /per se/ interesting, especially in a functional setting. Anyway, nobody can convince Steve Horne. Perhaps as an unintentional side-effect... But random streams, or rather pseudo-random streals (infinite lazy lists, as the example I gave, the `iterate` of `next`) are as referentially transparent as any Haskell data. Really. What I find really amazing, since I converted my soul from physics to computer since (many, many years ago...) is that most comments about random number generators come from people who don't need them, don't use them, and usually don't care about them... I taught random numbers, and I did some Monte-Carlo calculation in High Energy Physics, when many people here were not born. I *NEVER* used true random numbers, even to initialize a generator, since in the simulation business it is essential that you can repeat the sequence on some other platform, with some other parameters, etc. Of course, they are useful (don't need to convince an ancien physicist... And I lied. I used them, e.g. when I programmed some games for my children.) -- but why should we forget about them? The usual approach(*) is to gather entropy from a truly(**) random source and use that to seed (and perhaps periodically re-seed) a PRNG. So, sorry, I didn't mean really forget, only to change the subject which was irrelevant for the purity (but somehow has shown once more that Steve Horne had strange ideas about random generators). The generator of L'Ecuyer, or Mersenne Twister, or anything, don't care about the entropy. For a typical user, the only interesting thing is that the random streams pass the usual statistical tests : moments, correlation, spectrum... Otherwise it is as deterministic as 1 2 3 4. (For a typical user from my mafia. The mafia of cryptographists has different criteria ; from time to time we shoot ourselves in the coffee-machine corner of our dept.) Thank you for the discussion. You are right, I brake. Jerzy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
Sorry, a long and pseudo-philosophical treatise. Trash it before reading. Heinrich Apfelmus: You could say that side effects have been moved from functions to some other type (namely IO) in Haskell. I have no reason to be categorical, but I believe that calling the interaction of a Haskell programme with the World - a side effect is sinful, and it is a source of semantical trouble. People do it, SPJ (cited by S. Horne) did it as well, and this is too bad. People, when you eat a sandwich: are you doing side effects?? If you break a tooth on it, this IS a side effect, but neither the eating nor digesting it, seems to be one. This term should be used in a way compatible with its original meaning, that something happens implicitly, behind the curtain, specified most often in an informal way (not always deserving to be called operational). If you call all the assignments side effects, why not call - let x = whatever in Something - also a local side-effect? Oh, that you can often transform let in the application of lambda, thus purely functional? Doesn't matter, Steve Horne will explain you that (sorry for the irony): let is a compile-time pure construct ; at execution this is impure, because x got a value. S.H. admits that he reasons within his model, and has problems with others. Everybody has such problems, but I see here something the (true) Frenchies call un dialogue de sourds. For me a Haskell programme is ABSOLUTELY pure, including the IO. The issue is that `bind` within the IO monad has an implicit parameter, the World. In fact, a stream of Worlds, every putWhatever, getLine, etc. passes to a new instance. We do not control this World, we call it imperative (whatever this means, concerning eating a sandwich, or exploding an impure neutron bomb), so we abuse the term side effect as hell! The Haskell sector of the global world, the programme itself is just a function. Pure as the robe of an angel. Simply, you are not allowed by the Holy Scripts to look under this robe. == The rest is a (pure of course) délire. Well, you might not believe me, but philosophically you don't need to imagine the World as imperative. Personally I am a believer in the Quantum Religion. If you accept all them Holy Dogmas of Unitarity, of Linearity, etc., if you believe in the True Quantum Nature of the real world, - then it becomes ... functional. Pure. Without a single trace of any side effects. The problem is that residing inside this world precludes the possibility of considering *observed things* as pure, they are conceptually detached from the stream of the Universe Vectors. They change, so you say: HaHa!! A particle got ASSIGNED a new position! This is an imperative side-effect! - - while from the point of view of an external observer, a common evolution operator transformed both of you, YOU and the particle into a new instance of this sector. OK, I stop here, otherwise the digestion of your sandwiches may produce some side effects. Jerzy Karczmarczuk Caen, France. (William the Conqueror was here. Produced one nice side-effect.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
Le 29/12/2011 18:01, Iustin Pop a écrit : I'm confused as what you mean. And to clarify better my original email: yes, (bar x) always gives you back the same IO action; but the results of said IO action are/can be different when executed. The whole of my point is that it DOESN'T MATTER. (And I believe that Heinrich A. meant the same thing). I asked for the execution trace in order that you see what your function does to the programme itself, not that it attempts to contact the external world, and explode it. You discovered it yourself. The result is an object of type Read a = IO a and this is all. (Well, in order to really execute it, you have to specify the type a anyway). I think that nobody will convince anybody here. Steve Horne continues with his own visions : /if you're using IO actions, your code is not referentially transparent and is therefore impure/ I believe that this statement is doubly erroneous, but I give up. I won't even ask to show me WHERE the ref. transparence is broken. This discussion is a dead loop... Jerzy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
Iustin Pop:: In practice too: bar _ = do s- readFile /tmp/x.txt return (read s) Once you're in a monad that has 'state', the return value doesn't strictly depend anymore on the function arguments. Nice example. PLEASE, show us the trace of its execution. Then, the discussion might be more fruitful Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] On the purity of Haskell /Random generators
The story begins here: Steve Horne: /BTW - why use an IO action for random number generation? There's a perfectly good pure generator. It's probably handy to treat it monadically to sequence the generator state/seed/whatever but random number generation can be completely pure. / === Bardur Arantsson: /*Pseudo* random number generation can of course be pure (though threading the state would be tedious and error-prone). If you want truly random numbers you cannot avoid IO (the monad). / ??? ??? : If seed depends of psudo random event, for example of current systime, we must use IO action. Bardur, Lev, of course you try to be helpful, but you are answering wrong questions. Truly random numbers are very rarely used, forget about them. Standard r. generators (pseudo-random) in Haskell are monadic, because the relevant algorithms are stateful. Congruential, Fibonacci, Mersenne Twister, whatever, is a function, more or less: (newValue,newSeed) = rgen seed The monadic approach serves mainly to hide the seed. Some people prefer to use random streams, no monads, so the question of Steve Horne is not universal. But anyway, even without bind, the user will have to chain the seeds in some way. Still, I dont understand what does S.H. mean by a perfectly good pure generator. Tell more please (unless you just mean a stream, say: str = map fst (iterate (\(v,sd) - rgen sd) (v0,sd0)) ) Jerzy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell /Random generators
Steve Horne : I only meant that there's random number handling support in the Haskell library and, and least judging by type signatures, it's pure functional code with no hint of the IO monad. Look well at those functions, please. Within the RandomGen class you have pure members, such as next (an Int instance of what I called rgen in my previous message. It propagates the seed g ). The algorithmics of the random generation has no particular monadicity in it, as I said, the IO (or State) monad serves to hide the seed. The generator itself should not be confounded with its iterative, sequential usage. If people wanted to do in their programmes just *one* read or write, never repeated, no IO Monad would be necessary. On the other hand, for the IO, you can sequence the World instances explicitly, without any Monads in a pure functional language, this is the style used in Clean. == I am strongly convinced that ALL people who want to understand the functional IO, refs, etc. should learn both, Haskell and Clean. Il might help them to see better the relation between the programme, and its environment. == You say: /random numbers are in principle non-deterministic, not determined by the current state of the outside world/ Sorry, but I haven't a slightest idea what you are talking about. Dybbuks? Jerzy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell /Random generators
Steve Horne : Some code (intended to be loaded into GHCi and played with) -- import System.Random -- randSelect this is a list 5 (mkStdGen 9877087) -- ... module P23 (randSelect) where -- ... randSelect' (x:xs) n l g = let xsLen = (l - 1) (rnd, g') = randomR (0, xsLen) g -- ... I see no IO monad anywhere in there. Of course I'm cheating - providing a constant seed at runtime. The last remark is irrelevant. Normally the seed IS constant, injected once, then updated by the generator iself. I don't know what you are trying to prove. That you don't need monads? Everybody knows this. Look at your own code. In randSelect' you write (rnd, g') = randomR (0, xsLen) g **You don't need monads, because you do your own sequencing and propagating the seed*, g - g'.* Your library internal: randomR :: RandomGen g = (a, a) - g - (a, g) does the same thing, choosing a number within a range, *and propagating g*. (I call it a seed, but it is a Int seed wrapped within a StdGen...) OK, I repeat once more... Monads are useful ONLY to iterate the primitive generator, hiding the seed. The generator itself (the algorithm of Pierre L'Ecuyer or any other comparable) is obviously pure. The monadisation was a design choice of Lennart Augustson, who decided to dump (hide) (StdGen s1 s2) inside an IORef, but nobody is obliged to use it. There are alternatives, such as generating first an infinite random stream, or your own manufacture. So, OK, you have your pure generator. I explain why your question is based on some misunderstanding. All this has NOTHING to do whatsoever with the question of purity or not. Haskell code is pure if you propagate the StdGen yourself, it remains pure when the sequencing uses (=). Here this mythical World which visibly frightens you, reduces to two integers32. Either they propagate in your code, or through the iterate functional, or through the bind. In the last case it is hidden, so it may change, since only ONE instance is accessible. [[Actually, one exercice I gave to my students was to implement an iterable random generator using the State monad. Of course, there were numerous suicides, and the survivors have been isolated in the Arkham asylum, but the world is still there]]. Clean uses unique access variables for the same purpose, and the Clean users usually live normally with them. Jerzy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
Le 30/12/2011 01:44, Steve Horne a écrit : Switching mental models doesn't change the logic any more than switching number bases. Especially when your mental model operates with Dybbuks which do horrible things behind your back... If this is your vision of logic, it is a peculiar one. Either way, at run-time, Haskell is impure. Most people here, some VERY knowledgeable, do not agree with you. /Errare humanum est, perseverare diabolicum/. Either way, since you insist to prove that you DON'T WANT to understand other people view, I wish you good luck. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
Le 28/12/2011 22:45, Steve Horne a écrit : Yes - AT COMPILE TIME by the principle of referential transparency it always returns the same action. However, the whole point of that action is that it might potentially be executed (with potentially side-effecting results) at run-time. Pure at compile-time, impure at run-time. What is only modeled at compile-time is realized at run-time, side-effects included. (...) I hope If convinced you I'm not making one of the standard newbie mistakes. I've done all that elsewhere before, but not today, honest. Sorry, perhaps this is not a standard newbie mistake, but you - apparently - believe that an execution of an action on the real world is a side effect. I don't think it is. Even if a Haskell programme fires an atomic bomb, a very impure one, /*there are no side effects within the programme itself*/. If you disagree, show them. I don't think that speaking about compile-time purity is correct. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell Platform
Dear Gurus, A. Why the Haskell Platform is still based on ghc 7.03? (At least on WinXP) B. Does anybody care about wxHaskell? Thanks. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Decision procedure for foldr/foldl/foldl'?
David Fox reacts to my criticism of his attitude towards the meaning of folds: I'm not trying to avoid learning the differences between the different folds, but I am looking for a mnemonic device that will allow me to proceed more quickly towards my goal. My ultimate goal is to write software, not to understand folds. Just as it is inappropriate for a young officer to even contemplate an overall strategy for winning the war, it would be inappropriate for a general to spend more time than necessary on the minute details of military tactics, as vital as they are. David, cynism or not, you might have found in my post some concrete remarks, about incrementality, about tail-recursion... Not a single comment of your part. No comment addressed to other people who tried also to help you (whether we really help you in such a way is subject to discussion...) I am sorry, but saying that your goal is to write software is not even funny. The relatively modern science of programming evolves for the last 60 years, and the progress in writing software NEVER came out of kitchen recipes, on the contrary ! The laziness is not a trick to avoid computation, but a methodology of ordering the operations, and if you are unable to order them in your head, you won't be able to exploit this or that design pattern. OK, you gather some patterns, and you apply them. Once. And then, you will be helpless, when the need for refactoring arrives. You will never be able to teach those patterns to your younger colleagues. And finally, your last remarks might be less relevant than you wish. A general gets his stars usually after several years of demonstrating that he UNDERSTANDS the minute details of military tactics, so he can consciously choose those who will implement them. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Decision procedure for foldr/foldl/foldl'?
Yves Parès: if *f* is lazy in its second argument, then use foldr. Everything is lazy, you build a very small thunk since nothing is evaluated. In the rare cases where*f *is (also) lazy in its first argument, you can use foldl. ... I have the impression that this is not the most useful advice possible. 1. Nothing is evaluated?? Look, foldr is designed to consume incrementally the list argument, and to produce, also incrementally the result ; it may stop in the middle if f is lazy, but if you organize badly your program, you will pollute your memory. You might wish to process the whole of the list as fast as possible, and then foldr may be dangerous. You may build a veeery big thunk before its reduction. 2. This is not only the issue: f x z versus f z x. foldl is iterative (tail-recursive) and the reduction proceeds until all the source list is consumed. foldl works better with strict functions, not lazy. (of course, unless I am mistaken...) == In general, sorry for the cynism, but when I read: There are times when I would like to find out which to use in the quickest way possible, rather than reading a long explanation of why each one behaves the way it does of David Fox, I compare it with a question of a young army officer, addressed to his elders: Tell me how to win the war in the quickest way possible, rather than boring me with the explanations behind all those complicated strategies. Jerzy Karczmarczuk Caen, Normandy, France (William the Conqueror, who lived here, had a reputation of a strategist who tried to understand his enemies. 350 years later, the French didn't try to understand anything, they just wanted to win the battle of Azincourt as quick as possible). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A Mascot
Do you mind some ... how to say ... offside comments? 1. The Curry Da mascot looks like a penguin disguised as a lamb. I have nothing against penguins ! 2. Da, da, konech'no, mais, Signori und Demoiselles, do you realize that lamb is an English word, and we should think about our multilingual society. with our agneaux and other Karakuls. You will have problems with the translation of the mascot into German, and some may find some analogies with another image: http://www.chrisrusak.com/images/11-013_small.jpg called Ein liebliches Lämmlein zu Tod (after Des Knaben Wunderhorn, in the last part of Mahler 4th Symphony). 3. On the other hand, from the cultural point of view, this is a very good idea, and quite international, everybody knows Lamb Curry (Rogan Josh): http://www.route79.com/food/rogan-josh.htm 4. It is incredible, how this mascot inspired a long, long discussion about the Bottom. Now, Bottom is important ! Most French politicians speak only about that (well, at least one of them doesn't speak, but prefers practical exercises...), but I confess that I am a little lost. Anyway, I learned something. For example, that what is strictly forbidden, is lazily allowed. Best regards Jerzy Karczmarczuk Caen, France. (25 km from the Oldest Comic Strip in the World, 1000 years and progressing) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial/slides on pretty-printing combinators?
Sean Leather: Do you know of any tutorial or slides from a talk on one of the pretty-printing libraries? Sean, if you need info just on Haskell solutions, other people will help you. There is a paper: Linear, bounded, functional pretty-printing by Doaitse Swierstra and Olaf Chitil (and Pretty Printer with Lazy Deques by Olaf, a Functional Pearl if I am not mistaken). BTW, something has been implemented in Scala based on the S. and C. approach. So don't forget about other languages, you may learn something also here: http://caml.inria.fr/pub/docs/manual-ocaml/manual003.html#toc11 OK, these are not slides... Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] German names for kinds and sorts
First of all, my German is Worse than Cakes of my Grandmother... But I spent a big part of my life in France, and I witness a similar bedlam for years, especially because of the fact that English is a particular version of Norman French spoiled by the consumption of hot potatoes, and the modern, scientific French is English distorted by the abuse of the low quality wine, unable to dissolve the cholesterol of the local cheese. Seriously, the French queue is tail in English (or vice-versa), and the English queue is file in French which in English means fichier in French. And you want to propagate the disease with terms like Art, etc.?? If kind is espèce, then species is what? (And avoid to translate payer en espèces...) Russians are good because of their linguistical désinvolture (no good English translation), they just adapted foreign words with the utmost cavalière attitude (as the English say, French don't). But Polish invented their own terminology, which means that when you publish a scientific book in Poland, you quarrel with the reviewers for weeks, believe me! So, even more seriously, I propose to use more often Latin and Greek. Genus, genera, for ... ehm... je n'en sais rien, perhaps kind? (Genesis comes from it). Oh, no... This exists already in English, and is genre in French. Gattung in German pour varier. There have been attempts to use the word phylum, phyla. Anybody knows what happened to it? (Help! In French it is embranchement, which is horrible). Well, in biology we have règne (kingdom) (oder Reich, warum nicht?). Regnum. Sort?? Wonderful! This is a sort of word, whose semantic family cannot be really sorted. Especially with sortir in French. BTW, to sort in English is trier in French; tri, trie, tree. Try everything... == When some years ago we asked our students to write some reports in English, I thought I would spend some months in the Arkham Asylum, with Mr. E. Nygma, and others... Best regards. Jerzy Karczmarczuk Caen, Normandy, France (William the Conqueror started this mess here...). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The best way to call Java from Haskell?
Felipe Almeida Lessa cites and comments: useful libraries that will take infinite time to re-implement in Haskell My brain just exploded. I can't handle infinite-length modules. Don't worry, my friend. Haskell is lazy, so there is no problem in handling those infinite modules. It will just take you an anfinite amount of time before you get any money from such a work. But this is a general problem elsewhere as well. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Off-topic: Mathematics and modesty
Andrew Coppin : I haven't yet found anywhere where I can say when would a chi-squared test be more appropriate than a KS test? and get an informed, knowledgeable answer. (Answers from people who /know/ what they're talking about rather than just /think/ they know.) With all my respect: I think I know several mathematicians who learning that a person asking for help begins with trying to distinguish between knowledgeable, and those who just think they are, will simply - to say it politely - refuse to engage. (There might be some impolite answers as well, but you don't need the details). Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Off-topic: Mathematics
Peter Simons : Now, a person who has profound knowledge of the subject you're asking about is not very likely to do this, because he is probably not going to learn anything in the process. Dedicating time and effort to studying your particular problem is not an appealing prospect. You might be right. You may be dead wrong... Some people like to teach, find some pleasure in explaining things they know, and find a pleasure in trying to be useful. But they might refuse, if they hear: ...if you are a real specialist and you know what you are talking about, tell me what is better, the chi-square test or (...). Knuth admitted that he had learnt a lot while teaching things he already knew. So did Feynman. And Landau. All the best. Jerzy K. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Truly Really Off-topic: (Was: Mathematics)
Now, something really à côté de la plaque... Jack Henahan terminates his useful advice addressed to A. Coppin: Computer science is no more about computers than astronomy is about telescopes. -- Edsger Dijkstra This citation makes me think, and since this became rare, I share it. * It is unsourced, repeated without discernment, and Dijkstra cannot confirm (or deny) it any more. Somehow I cannot believe he said that... * Dijkstra began to study physics, and a physicist would be reluctant to make such puns. Why? o Astronomy, and physics are not only theories of galaxies or superfluids, but also methodologies of data acquisition and data processing. Telescopes evolve with our knowledge of the visible universe, as the accelerators evolve with our knowledge of elementary particles. You have to know where to look! And how to interpret the raw, experimental data. o So, whether you call it Informatique, Datalogi, or whatever, it is */also/* about computers. Do you really think that the algorithmics, the thory of parallel computation, etc., have nothing to do with concrete implementations? * These among you who touched just a bit of astronomy, should know what a horrendous amount of truly astronomical knowledge is necessary to make the telescope work! For example to synchronize it with the earth movement... * This citation seems to be a savant variant of: The Fool Looks At The Finger That Points To The Sky case... OK, if you wish. But I had an occasion to sit near a beautiful girl who pointed her hand and her eyes in the direction of wonderful Zodiac constellations; it was midnight in the mountains. I don't remember the details, but without being a fool, I didn't look at the stars... (Well, actually I was a fool, but it is a long story). Jerzy Karczmarczuk Caen, France ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] partial inheritance
Patrick Browne : I was checking out a paper that said: Type classes allow for partial inheritance, so that penguins can be birds without flying behavior. ... as pointed out by Jerzy my question is silly because can penguins can fly ... No, the question is not silly because of that crazy Adelie tribe. The question is doubtful, because the Haskell type classes is not an object-oriented system of classes, subclasses, etc. When you declare Rationals, you don't inherit the multiplication for them as Numbers. This inheritance you wish may manifest itself when you specify the *instances*. That's why I suggested how you might do that: for some datatypes, say the Emperors, you specify some special flying method (e.g. dummy or bombing), or you don't specify it at all. And the Emperors won't fly. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] partial inheritance
Patrick Browne : For example, if the class Bird has a flying method can we represent Penguins as a sub-class of Bird without a flying method? The silliest - from the pedagogical perspective - answer to any question, is you don't need it. But ... in most cases you really don't need it... When instancing your Bird class you may forget to define the flying methods. Is this unsuitable for you? The compiler will yell, but this is harmless. Jerzy Karczmarczuk PS. Penguins DO fly. http://www.telegraph.co.uk/news/worldnews/1583517/Flying-penguins-found-by-BBC-programme.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Input and output of mathematical expressions
Pedro Vasconcelos comments: Regarding the rendering math formulas on web browsers: you might want to have a look at MathJax (http://www.mathjax.org/). You can use LaTeX or MathML and will work in most browsers (even if when they don't natively support MathML). Don't forget two other (which I have been using for years) LaTeXMathML : http://math.etsu.edu/LaTeXMathML/ jsMath : http://www.math.union.edu/~dpvc/jsMath/ The first needs MathML, obviously, but I won't use browser which ignores it... Thios is one script, fairly readable. The second one is much bigger. Used by Planet Math, integrated into Drupal, etc. I confess I tried to write something which displayed math fromHaskell, I gave even a project of that kind to my student. But the solutions exist already and are known, so... See e.g. http://www.twingly.com/haskell/stories/4013ffd773e942fdb4b9cf2cb7c0089e Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Lazy lists vs generators
Le 11/06/2011 11:06, o...@okmij.org a écrit : The following web page talks about lazy lists and generators http://okmij.org/ftp/continuations/generators.html in (perhaps too) great detail. Oleg, when you mention Icon, you might - perhaps - observe that Griswold didn't introduce the co-expressions (this is their terminology, not generators) out of the air, they have been present as the unevaluated expressions in Snobol4. Icon has been built upon the Snobol4 philosophy, although as language it was very different. Another remark about yield in Python. This is not just a non-deterministic return mechanism, but an expression, which yields a value also for the generator code. It becomes thus a reentrant co-procedure, which goes quite a mileage beyond the lazy list model. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell School of Expression (graphics)
Henk-Jan van Tuyl commenting Andrew Coppin ... (about HOpenGL and H.Platform) ... Uh... yes, you might be right about that. However, AFAIK you still need something with which to create a rendering surface in the first place. (Not sure if HP includes GLUT...) As you can see in the HP documentation at http://lambda.haskell.org/hp-tmp/docs/2011.2.0.0/index.html , both OpenGL and GLUT are present. Or simply download and execute the examples before raising doubts... (the Haskell translation of the NeHe tutorials, etc.) No need for speculation. Now, I have a personal pedagogical comment. A few months ago I gave to some 30 students an assignment (a family of, with freely chosen variants). A long one, to complete in 2 months or more, and the subject was - the implementation, coding and running some nice 3D scenes with HOpenGL. I teach Haskell for years, usually the projects, which should be applied are devoted to some exercices in AI / games, compilation, text processing, graph manipulation, lazy numerics, etc., you know the song. This time I decided to propose something more visual. The results? A true DISASTER! They did something, all of them, and all their realisations were the nec plus ultra of mediocrity... Since my students were as clever and laborious as always, and I didn't drink much vodka during this process, I asked them what happened? The short standard assignments went smoothly as always... The answers (concentrated) were as follows: The OpenGL bindings in Haskell are hardly functional. You make us sweat with generic functional patterns, laziness, exquisite typing, non-determinism monad, parsing tools, etc., and then you throw us into this ugly imperativism ! Nobody liked your assignment, it was no pleasure for us, and our results are the consequence thereof. Where is Haskell?? Of course, we had to execute the typical syntactic gymnastics, but without understanding the functioning of all those variables, and other stuff relevant to the stateful OpenGL engine. Perhaps, if we had before a semester of OpenGL, and at least two months of a true course/tutorial (not your pseudo-tutorial on the Web...) we could be more productive. That's it... I don't want to generalize, but there is a huge work to do in this context. All the best. Jerzy Karczmarczuk Caen, France ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Python is lazier than Haskell
Thomas Davie wrote: This completely misses what laziness gives Haskell – it gives a way of completing a smaller number of computations than it otherwise would have to at run time. (...) Tony Morris continues the ping-pong: This is not what laziness gives us. Rather, it gives us terminating programs that would otherwise not terminate. Next, please... You know, this suggests that you should read the parable of Blind Men and the Elephant. Alright, my turn. I never wanted to write non-terminating programs (what for?), and all my programs executed exactly those instructions they should have executed, not more or less. I see ONE usage of laziness: the possibility to write co-recursive equations, which become algorithms. The possibility to represent processes as data, which makes it easier to reason upon them. Do we really need some dogmatic specification of laziness?... Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Python is lazier than Haskell
Alexander Solla comments my comment : Alright, my turn. I never wanted to write non-terminating programs (what for?), Daemons/servers/console interfaces/streaming clients? Come on, not THIS kind of non-termination. This has little to do with strictness/laziness, I think. Endless loops can be coded in various ways... I see ONE usage of laziness: the possibility to write co-recursive equations, which become algorithms What about infinite lists? There is no need for mutually recursive functions to see the usefulness of a list which never ends, and is computed to the length that your algorithm /acutally/ requires. This is almost EXACTLY what I meant. When I say co-recursive, I do not mean mutually recursive. Rather the extrapolating recursion, not necessarily terminating (lacking the base clause) but finitely progressing, such as the standard definition of the stream of integers, used to scare the beginners... ints = 1 : zipWith (+) (fix (1:)) ints where fix f = f (fix f) Thanks. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] philosophy of Haskell
Alberto G. Corona writes: (...) Desugarize the do notation, after that, desugarize the = and operators down to the function call notation and suddenly everithing lost its magic because it becomes clear that a haskell monad is a sugarization of plain functional tricks. Yep. But, BTW, could you tell me what was the result of the final desugarization and the BASIC sense of the IO monad for you? Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: US Patent for the idea ...
Brian Hulley reports a search similar to : haskell unicode bidirectional revealed a link to a US Patent (7120900) for the idea of implementing the Unicode Bidirectional Algorithm (UAX #9 http://www.unicode.org/reports/tr9) in Haskell, making use, as far as I can tell, of nothing more than the normal approach any functional programmer would use, namely separation of concerns etc. The link is http://www.freepatentsonline.com/7120900.html though I think it would be better if they had just called the website free handcuffs online because that is what it amounts to when people succeed in preventing others from using ideas, especially ideas everyone would easily think up by themselves. Before going further I would like to explicitly state that I would not wish to cast any aspersions upon the people or companies involved in this patent, since it is all too clear to me that these people have acted in a perfectly legal way and are just doing their various jobs: /.../ Comment irrelevant to Haskell, sorry. Everybody does his/her various jobs. But I lost all respect due to people who work in the US Patent Office, when I saw the patent 6,025,810, a patent for an antenna which sends signals faster than light, using some mysterious new dimension. Or the U.S. Patent 6,960,975 for an anti-gravity device. It seems that although it is illegal to break some local regulations, the idea of breaking fundamental physical laws remains perfectly legal. (In some countries...) Somebody finally decided to ridiculise the system. If you want a good laugh, see the patent 6,368,227. The search site is here: http://patft.uspto.gov/netahtml/PTO/srchnum.htm Best regards. Jerzy Karczmarczuk PS. concerning the patent 7120900. The authors appropriate this bi-directional display in Haskell, Erlang, SML, Lisp, Scheme and Miranda. So, please, hurry up, and before they wake up, implement your stuff in Ocaml or Clean. Or better, get a relevant patent yourself. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Num instances for 2-dimensional types
Miguel Mitrofanov rebukes Sönke Hahn, who -: wrote: I used to implement fromInteger n = (r, r) where r = fromInteger n , but thinking about it, fromInteger n = (fromInteger n, 0) seems very reasonable, too. Stop pretending something is a number when it's not. Miguel Mitrofanov, please kindly stop pretending that you KNOW what is a number, and what is not. The numeric classes in standard Haskell are disgraceful, and the idea that if something can be added, it is a number is bad. Vectors are not numbers, but inventing special (+) for all kinds of Abelian additions is awkward. So, people call numbers what they wish, and it is *their* business. I needed to add functions (of course, without Eq nor Show membership), I had to fake... Pairs (a,b) may be numbers in various contexts, for example (value,derivative) in automatic differentiation. Or (mainTerm,otherOrders) in some infinitesimal calculus. Or pairs (scalar, 3vector) for quaternions. The idea of putting fromInteger in the same class, is a design bug (my personal opinion, of course). There are plenty of examples where conversions from integers are legitimate, but no addition or (*)seem natural. Or the other way round ; apparently Sönke Hahn is in that situation, so he fakes... Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] What is a number. (Was: Num instances for 2-dimensional types)
L.A. says: complex numbers are just pairs of numbers. Later : Being a number is in the eye of the beholder. :) Now, the readers of this forum will with horror witness a discussion about the meaning of the word just... American people will call it a discussion about semantics, and we, European will not understand why this word is used in a pejorative context... Just pairs have no natural arithmetic upon them. All the standard set theory will not help in making numbers, unless we inject the notion of equivalence à la Gottlob Frege. And this is surely contextual, but perhaps the eye of the beholder should be somehow objectivized... BTW. the missing term of M.M. is DUAL NUMBERS. Lennart continues : Everyone agrees that the Haskell numeric hierarchy is flawed, but I've yet to see a good replacement. There *are* some mathematical preludes for Haskell. There were attempts to emulate the structures of, say, the C.A.S. Magma in FP (I lost the references...) http://www.haskell.org/haskellwiki/Mathematical_prelude_discussion The problem is, that Haskell is a huge factory, people responsible NOW for its evolution have other priorities. But the story has at least 15 years. Jeroen Fokker did something then, I worked on it at the same period. Now Jacques Carette has his own system, and Sergey Mechveliani another one... But other people don't care, so the efforts are atomized. Please, keep cool. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Convert IO Int to Int
Magnus Therning writes: ptrash wrote: ...am not getting through it. I just want to generate a random number and then compare it with other numbers. Something like r = randomRIO (1, 10) if (r 5) then... else ... You have to do it inside the IO monad, something like myFunc = do r - randomRIO (1, 10 This may continue forever... With nice references to monads, to uns...@#*!, etc. ... We may say, as many tutorials do : this is not what you want! (which I hate ; you are not my conscience, whoever you are...), or just give some code, not always readable... Perhaps I belong to a minority here, but I strongly believe that at THIS level, the first thing to do - unless I am dead wrong - is to explain to our friend ptrash (who could find a less gothic pseudo) that in a pure functional programming, the construction r = whatEver(par1,par2) being a function call, cannot give just a random number, something which is not (intuitively) determined, and changes with every call, despite the constancy of the arguments. For most of us, acquainted with the stuff, it becomes trivial, but if somebody doesn't know that a classical pseudo-random generator modifies a seed, and in such a way involves a side effect, then sending him to the monadic heaven is dangerous. Please, tell him first about random streams, which he can handle without IO. Or, about ergodic functions (hashing contraptions which transform ANY parameter into something unrecognizable). When he says : I know all that, THEN hurt him badly with monads. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Time for a new logo?
Andrew Coppin writes: And who knows category theory? Almost nobody. If you insist on naming stuff after things that nobody will have heard of and which sound highly technical, you're going to seriously limit your potential audience. Speak for yourself, not for almost everybody, or you will going to seriously limit your potential audience (which might be already restricted to those who don't care about seriousness of your statements). ALL mathematicians know CT. All formal papers on Monads touch CT. Well, OK, I know, Monads and you are two different worlds... (Also, coroutines? Seriously? That's hardly an obscure term in programming circles.) Well now, I'm curios. I've been writing computer programs since I was 9 years old. I hold a diploma *and* an honours degree in computer science. And I have never even *heard* of a coroutine. To this day I still don't know what it means. I rather suspect I'm not the only programmer on earth who finds themselves in this position. ;-) If one day I decide to return back to some religion, I will pray for the souls of your teachers. How many microseconds have they spent teaching parallel programming? I suggest that you say goodmorning to Google. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] sound synthesis
Thomas Girod: Recently, I read a few articles about Haskell (and FP in general) and music/sound. I remember an article ranting about how lazy evaluation would be great to do signal processing, but it was lacking real world example. Check (e.g. through Google) what Henning Thielemann wrote about. I can offer you something written not in Haskell, but in Clean (the conversion to Haskell is largely trivial), see e.g. this PADL paper, I have it on-line: http://users.info.unicaen.fr/~karczma/arpap/cleasyn.pdf The task is to generate a sine wave and pipe it to /dev/dsp on my linux box. There is probably a nicer way to make some noise, like using SDL audio API bindings, but I didn't take the time to poke around this yet. I'm wondering how I could convert a [Word16] to ByteString, and how I could use lazy evaluation to generate an infinite sine that stops with the interupt. Infinite sine that stops is a bit contradictory. In my view the solution is the following. You generate your infinite whatever. Sine, Karplus-Strong sound, flute, whatever, you combine all in one infinite stream, and you don't care at all about stopping. [In Clean I used unboxed, spine-lazy, but head-strict lists. The format was floating-point]. THEN, during the conversion, piping, construction of a .wav table (vector) you think about the time-limitation of the stream. I played with static constraints (concrete number of converted samples). If you want to do it dynamically, then, either you know how to interrupt *any* infinite process within Haskell, or you have to learn how to do it... Here people more competent than myself will surely help you. Good luck, and thanks for your interest in a this fabulous field. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] approximating pi
Benjamin L. Russell: Assuming the square had 100 pixels per side, on the average, approximately how many random pixels should be plotted in the square before obtaining a reasonably good estimate of pi? Nothing to do with Haskell... What do you mean by reasonable? This Monte-Carlo procedure is very inefficient anyway. The relative error falls as 1/sqrt(N) where N is the number of samples, so, several hundred thousands of samples may give you just three significant digits. And, at any rate, this has nothing to do with pixels, what, introduce one more source of errors through the truncation of real randoms? Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] approximating pi
Don Stewart writes: Ry Dahl: By picking points randomly from a square one can calculate pi. ... What is the best way to express this algorithm in Haskell? Using a random generator, such as System.Random or System.Random.Mersenne, generate random numbers in your range, testing if they're inside the circle, and loop until your limit condition is reached. The full program is about 10 lines or so, so shouldn't be too hard to work out, once you've worked out how to generate Doubles from System.Random.random Ry Dahl seems to know Ruby. Ruby has also comprehensions. So, why not use 'randoms' to generate an infinite list of them, 'take' some N, and then 'sum' 1 on randoms filtered by the circle condition. I think that you won't need full 10 lines of code... Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Function Precedence
Chris Smith writes: ... So the current (Num thing) is basically: 1. The type thing is a ring 2. ... with signs and absolute values 3. ... along with a natural homomorphism from Z into thing 4. ... and with Eq and Show. If one wanted to be perfectly formally correct, then each of 2-4 could be split out of Num. For example, 2 doesn't make sense for polynomials or n by n square matrices. 4 doesn't make sense for functions. 3 doesn't make sense for square matrices of dimension greater than 1. And, this quirk about 2(x+y) can be seen as an argument for not wanting it in the case of functions, either. I'm not sure I find the argument terribly compelling, but it is there anyway. Why formally correct?? This is *your* vision. I might say that fromInteger makes sense for square matrices, mapping to a multiple of the unity matrix. 4 makes sense for functions on finite domains. The full Ring property requires a unit, which might not be there formally. The absolute value might be a buzzword for norm which *can* be defined for polynomials. In short, Num is a conventional hybrid, and trying to squeeze it into *any* math formal structure is asking for trouble. On the other hand, I have enough time already trying to explain Num, Fractional, Floating, RealFrac, ... to new haskell programmes. ... At least in the U.S., very few computer science students take an algebra course before getting undergraduate degrees. Not only in US. In mathematical terms, the set of functions is a (math) module (generalized vectorspace), not a ring. Well, I agree that functions are modules; but it's hard to agree that they are not rings. After all, it's not too difficult to verify the ring axioms. Oh. What is the function multiplication? You say: (f*g)(x) = f x * g x ?? I agree. But if you say that the multiplication IS the *composition* (for example for the popular implementation of Peano/Church numerals), then I will also agree. So, there isn't any obvious instance for the function multiplication. (The composition works even if neither x nor f x belong to any ring). BTW functions are or are not members of modules/vector spaces depending on the codomain structure, so this requires a constrained instance specification. Fractional, Floating, etc. are also horrible. Why the square root needs to be floating? It can belong to the algebraic number domain. We can continue this ad infinitum. I cared very much about this stuff some 10 years ago, I gave up... I would like, sure, to have the possibility to derive in Haskell some mathematical subsumptions, e.g., that the ring of integers modulo N becomes a field if N is prime. Or, that every additive group is a module over integers. But it seems that we are very far from such a dream. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Function Precedence
Hans Aberg writes: ... But one should also be able to write (f+g)(x). - This does not work in Haskell, because Num requires an instance of Eq and Show. So, declare them, even if they are vacuous. I did it several times, I am still alive, so no need to say this does not work. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Function Precedence
Hans Aberg comments my remark to his observation: But one should also be able to write (f+g)(x). - This does not work in Haskell, because Num requires an instance of Eq and Show. So, declare them, even if they are vacuous. I did it several times, I am still alive, so no need to say this does not work. That is possible, of course - I did that, too. But it means that the syntax and semantics do not work together; an invitation to pitfalls. So this ought to be avoided, except if there are no other workarounds. I am more tolerant. The question - for me - is not an interplay between syntax and semantics, syntax here is irrelevant, the fact that (+) is a popular infix operator plays no role. The calamity comes from the fact that it is not possible to write serious and natural instances of Eq and Show for functions, and that for God knows which reasons, the Num instance demands them ! This requirement is not rational, although intuitive. But I violated it several times, when I needed arithmetic for lazy infinite objects... So, I can't say that this should be avoided. I don't see obvious pitfalls therein. It would be better to write a new Prelude. :-) Oh, yes, our common dream... Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Function Precedence
Paul Stanley writes: Hi If f x = x and g y = y then f g x returns an error because f takes only one argument. Why can't we have function application implemented outwardly (inside-out) etc. Paul, There were already some answers, but it seems that people did not react to the statement that f g x fails. It doesn't, in normal order everything should go smoothly, f g 5 returns 5 = (f g) 5 = g 5, unless I am terribly mistaken... Where did you see an error? Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] function type def
PR Stanley: I know sort of instinctively why it is so but can't think of the formal rationale for it: f g x = g (g x) :: (t - t) - (t - t) First of all - it is not the definition f g x = ... :: (t- ... but the type of the function which might be specified: f :: (t-t)-t-t Then, the answer to: Why not (t - t) - t - (t - t) to take account of the argument x for g? is simple. If t is the type of x, then g must be g :: t-t, you're right. So f :: (t-t) - t - [the type of the result] But this result is of the type t, it is g(g x), not (t-t), it is as simple as that. Perhaps you didn't recognize that - is syntactically a right-associative op, so a-b-c is equivalent to a-(b-c), or (t-t)-t-t equiv. to (t-t)-(t-t) Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Wumpus World
Benjamin L. Russell wrote: Not all students and researchers can afford a Personal License. Can you recommend an alternative, fast Prolog development system under a free licensing agreement, such as GPL/GLPL? You have quite a choice if you relax your licensing requirements: http://www.thefreecountry.com/compilers/prolog.shtml You will find there the GNU-Prolog, whose licensing should be as you wish. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Computational Category Theory in Haskell
Derek Elkins writes: Dan Weston wrote: Has anyone already ported to Haskell the ML code in Rydeheard and Burstall, Computational Category Theory? This isn't very helpful, but I did several years ago, ... You might be interested by: On the expressive power of Constructor Classes by Luc Duponcheel, and Erik Meijer. Available through citeseer. This has been written under Gofer, should thus work for Hugs, and no reason why not under GHC. Very nice paper. (Of course, Rydeheard and Burstall is their first reference). Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Repeated function application
Ben Butler-Cole writes: times :: (a - a) - Int - (a - a) times f 0 = id times f n = f . (times f (n-1)) Am I missing something more general ...I can't help feeling that there must be a way to get rid of the explicit recursion. How would you implement times? Anything against (apart an auxiliary list, and x not curried away) times n f x = (iterate f x)!!n Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Doubting Haskell
Donn Cave writes: On Feb 17, 2008, at 1:12 AM, Colin Paul Adams wrote: And left is not the opposite of correct. That would be incorrect. ... If it's any consolation to those of the left handed persuasion, I guessed it wrong - I have used Either in this way, but Left was Success and Right was Failure. I don't enjoy puns, and mapped to an A/B form it seemed obvious that Success is A. Wee, for those who don't enjoy puns, but feel that the life and everything is one enormous pun, a political reminder. For many years, the world is composed of Leftists and Rightists (let's for the moment forget the normal people). Those from the Left always felt that they were right, and that those from the Right should not be left unpunished, while those from the Right thought that those from the Left should be left to die. Even if it seems right to consider that these deviations should be left to historians, we should not forget that at the beginning of the glorious Soviet country there was a proposal to change the meaning of traffic lights. Red would mean Forward!!. On the other hand, in France nowadays the difference between Right and Left is more or less the same as between Immediate failure and Delayed failure. Choose yourselves which is which. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: A question about monad laws
Jed Brown comments the answer of - -- Roman Leshchinskiy who answers my question concerning the replacement of floating-point numbers: First, when I see the advice use something else, I always ask what, and I get an answer very, very rarely... Well? What do you propose? For Haskell, Rational seems like a good choice. The fact that the standard requires defaulting to Double is quite unfortunate and inconsistent, IMO; the default should be Rational. Float and Double shouldn't even be in scope without an explicit import. There really is no good reason to use them unless you are writing a binding to existing libraries or really need the performance. Here Jed Brown says: Until you need to evaluate a transcendental function. ... It would be killing, wouldn't it?... I would say more. It is known that in randomly taken, usual formulae in physics, engineering, etc., if you start with rationals, *typically* the GCD between numerator and denominator will be small, the reductions of fractions are not very effective. Your rationals explode very fast! If after some reasonable number of operations you get rationals whose num/den have millions of digits, the program becomes *completely useless*, this is not just the questions of performance. Richard O'Keefe said that people speculate about floating-point numbers without knowing them. Well, nobody is perfect... I am a bit disturbed by people, who speculate without ever *needing* fl.p's, and who haven't thus the sensibility. For them this is a kind of game. Well, it isn't. R.L. says: For all practical purposes, the semantics of (==) is not well defined for floating point numbers. That's one of the first things I used to teach my students about floats: *never* compare them for equality. So in my view, your example doesn't fail, it's undefined. That Haskell provides (==) for floats is unfortunate. I disagree, on practical basis. Floating-point numbers are very well defined, we know how the mantissa is represented. If the numbers are normalized, as they should, plenty of low-level iterative algorithms may use the equality - after some operation - to check that the machine- precision convergence has been obtained. On the contrary, the verification that the absolute value between two terms is less than some threshold, may be arbitrary or dubious. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: A question about monad laws
Trialog: Roman Leshchinskiy writes: Richard A. O'Keefe wrote: [EMAIL PROTECTED] wrote: Would you say that *no* typical floating-point software is reliable? With lots of hedging and clutching of protective amulets around the word reliable, of course not. What I *am* saying is that (a) it's exceptionally HARD to make reliable because although the operations are well defined and arguably reasonable they do NOT obey the laws that school and university mathematics teach us to expect them to obey Ints do not obey those laws, either. It is not exceptionally hard to write reliable software using ints. You just have to check for exceptional conditions. That's also the case for floating point. That said, I suspect that 90% of programs that use float and double would be much better off using something else. The only reason to use floating point is performance. I have a bit different perspective... First, when I see the advice use something else, I always ask what, and I get an answer very, very rarely... Well? What do you propose? Then, the problem is not always pathological, in the sense of exceptional conditions. There are touchy points related to the stability of the algorithms for the solution of differential equations. There are doubtful random number generators in Monte-Carlo business. There are ill-conditioned matrices and screwed-up iterative definitions. Algorithms work, work, and ultimately explode or produce rubbish. The laws which get broken are almost respected for a long time, and then we have the Bald Man (Sorites) paradox... RAO'K very wisely says that people should avoid reinventing wheels, and they should use established packages, written by people who know. The problem *here* is that we would like to have something fabulous in Haskell - for example... And there aren't too many experts, who would convert to the Functional Religion just for fun. What is *much worse*, some potential users who could encourage building such packages in the numerical domain, typically don't believe that FP gives anything interesting. At least, this is the opinion of physicists I spoke to recently. Never mind. We shall dance over their cadavers, unless they dance over ours. In both cases we shall be happy. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: A question about monad laws
Yitzchak Gale writes: Jerzy Karczmarczuk wrote: Would you say that *no* typical floating-point software is reliable? It depends on how you define reliable. Floating point intentionally trades accuracy for speed, ... It used to be true - and may still be - that the engineers who implement floating point in the hardware of our CPUs would never fly on commercial airliners. Would you? Would you entrust your country's nuclear arsenal to an automated system that depends on floating point arithmetic? 1. This is not a possible trade-off or not. In scientific/engineering computation there is really no choice, since you have to compute logarithms, trigonometric functions, etc., and some inaccuracy is unavoidable. Of course, one may use intervals, and other extremely costly stuff, but if the stability of the algorithms is well controlled, and in normal case it is (especially if the basic arithmetics has some extra control bits to do the rounding), th issue is far from being mortal. 2. The story about engineering not flying commercial planes is largely anecdotical, and you know that. Repeating it here doesn't change much. 3. Nuclear arsenal is never really entrusted to an automated system, because of reasons much beyond the fl.point inaccuracies. On the other hand, in all those software one has to deal with probabilities, and with imprecise experimental data, so even if for God knows which purpose everything used exact algebraic numbers, or controlled transcendental extensions, the input imprecision would kill all the sense of infinitely precise computations thereupon. 4. The non-reliability of engineering software has many more important reasons, sometimes incredibly stupid, such as the confusion between metric and English units in the Mars Climate Orbiter crash... The Ariane 5 crash was the result not of the floating-point computation but of the conversion to signed 16-bit numers (from a 64bit double). 5. Of course, in the original posting case, the underlying math/logic is discrete, and has no similar inaccuracies, so the two worlds should not be confounded... Here, if some laws get broken, it is the result of bad conventions, which usually can be easily avoided. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A question about monad laws
Deokjae Lee cites: The tutorial All About Monads says that It is up to the programmer to ensure that any Monad instance he creates satisfies the monad laws. The following is one of the laws. (x = f) = g == x = (\v - f v = g) However, this seems to me a kind of mathematical identity. If it is mathematical identity, a programmer need not care about this law to implement a monad. Can anyone give me an example implementation of monad that violate this law ? After three or five reactions to this posting, I think it it is time to generalize. Haskell is not math. Or rather, there is no way to be sure that the *implementation* of some mathematical domains and operations thereupon are fool-proof. Sometimes you break en passant some sacred laws. For example the transitivity of ordering. 52, right? and 85 as well. But, imagine a - little esoteric example of cyclic arithmetic modulo 10, where the shortest distance gives you the order, so 28. A mathematician will shrug, saying that calling +that+ an order relation is nonsense, and he/she will be absolutely right. But people do that... There is a small obscure religious sect of people who want to implement several mathematical entities as functional operators, where multiplication is f. composition. You do it too generically, too optimistically, and then some octonions come and break your teeth. So, people *should care*. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: A question about monad laws
Richard A. O'Keefe comments: [floating point addition is not associative]] And this is an excellent example of why violating expected laws is BAD. The failure of floating point addition to be associative means that there are umpteen ways of computing polynomials, for example, and doing it different ways will give you different answers. This is *not* a good way to write reliable software. [Then we see the scalar product whose value *may* depend on the ev. order] I wonder... Would you say that *no* typical floating-point software is reliable? Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Who started 42, and when?
Martin Lüthi: In the Japanese culture the number 42 has a very special meaning. I realized that while discussing cultural differences with a Japanese. Pronouncing 42 sounds like death or to die. No hotel in Japan has a room 42. After knowing that it is hard to think that Doug Adams was not aware of that meaning. Phil Molyneux: ... it does have a basis in the standard model of physics --- a paper in Phys.Rev. of the early 1970s described the unification of the Electro-Weak and Strong nuclear forces --- the arbitrary constant (of nearly) 42 appears in the calculations. I forget the original paper but if you get hold of Frank Close ``The Cosmic Onion'' a graph reproduces the result. I met Douglas Adams once at a book signing and asked him how he got hold of the Phys.Rev. paper so early. Technically he should have written that ``42 is the answer to life, the universe and everything except for gravity and a few other arbitrary constants'' Bother...! You will discover the third (or the sixth?) moment of the Riemann zeta function which has this 42 in it, and without doubt, you will find something in Talmud and the Pyramides. And the mass of the Galaxy which is 3*10^42. And it takes light 10^(-42) sec. to cross the diameter of a proton, although if I were light, I wouldn'd do such silly thing. Fortunately I am heavy. And at least one of YOU is 42 years old, and I was once. (Yes, the number 1 which is even more magical). Perhaps before claiming before you know really something, because Adams told you so personally, you have a look here. http://groups.google.com/group/alt.fan.douglas-adams/msg/d1064f7b27808692?dm ode=sourcehl=en ... And if you run a non-optimized Haskell program which computes the Fibonacci of 42, then you have to wait so long, that you must build a special Supercomputer for it. It has, BTW. been built, and it is called the haskell-cafe mailing list. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: anybody can tell me the pronuncation of?haskell?
Chung-chieh Shan corrects me: PS. If you think that arigato is a genuine Japanese word, well, check how the appropriately translated word is spelled in Portuguese... I'm not sure what you mean by genuine, but I suspect that whether arigato is genuine does not depend on Portuguese. http://linguistlist.org/issues/12/12-1871.html http://linguistlist.org/issues/12/12-1906.html Yes, it seems that I have been one more victim of this red herring. In the cited issues of the linguistlist there is a nice discussion of that topic. It should be more widely known entre a gente falando portugues. Vou calar a boca... Gomen nasai. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] anybody can tell me the pronuncation of haskell?
Tim Chevalier(*) writes: I think to ease the acceptance of Haskell in the broader world, we should just change the name to Schönfinkel. On the other hand, is better not to try Curry, since the French pronounce it: Queue-rhrhrh. This is for me absolutely inacceptable and scandalous, since thus, they confuse him with Madame Curie, who was Polish, and I am a patriot. And after a few years, people from some Other Respectable Cultures will think that Haskell discovered Radium (for French: Hhhhudiomm). Thank you for this inspiring and awfully useful discussion. Jerzy K. (K is pronounced as K, the name of some heroes of Kafka, who was a Germanophone Czech Jew. Do not confuse his K with another K, by Dino Buzzati, who was Italian). === (*) Pronounced //possibly// as Che Guevara, with Guevara replaced by Valier. Now, Valier is a mountain in Les Pyrenées, (http://www.pyrenees-team.com/pteam/photos/valier/valierg/18) and the first person who climbed it was a bishop. The second one was also a bishop, so perhaps Tim should be careful. Some more messages on this subject, and I will have really to call an ambulance so they can take me away, far from Internet... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] anybody can tell me the pronuncation of haskell?
Tim Chevalier writes: ... I think the usual convention is to pronounce names in the manner of the language that the person who has the name speaks. (Preferably just to pronounce people's names the way they say them.) (The first convention doesn't work with my last name, though the second one does.) Oh, people! I try hard to degenerate this discussion into a pure delirium traemens, and you still keep its serious intellectual contents intact! I bet that you don't even smile, writing your terrible off-topic postings! If you wish so... Tim, there cannot be any USUAL CONVENTION, unless you are conditioned by your anglo-saxon keyboard. There is no truly established way to translate non-standard diacritics. Even without, there are pronunciation variants, look how many versions of Mustapha names there are in the world. Try to transmit my family name to a Japanese, using Katakana (which, being syllabic, gives you many choices...) The information world today is far from a purely oral tradition. I think that the only sane attitude is just let people distort everything as they wish, and don't get nervous. Those distortions are unavoidable, languages are evolving creatures. ... And a good part of English has been established by those Francophone Vikings who won the battle of Hastings in 1066, beginning their campaign from where I usually live and work. ... Not forgetting that before them there were Danish Vikings, coming from the place where I sit now... Arigato gozaimasu. Jerzy Karczmarczuk. PS. If you think that arigato is a genuine Japanese word, well, check how the appropriately translated word is spelled in Portuguese... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] anybody can tell me the pronuncation of haskell?
Tim Chevalier writes: Haskell, stress on the first syllable; the first syllable is like the word has and the second syllable is pronounced with a schwa where the e is written. Sometimes you will hear people stress the second syllable, but that is not Preferred. == Well, unless you are French. Then you don't pronounce H. The remaining letters are pronounced according to the Règlements de l'Académie. On the other hand, the name Chevalier is pronounced as it should be. But, on the other hand, if you are Italian, you should take into account that no word may terminate on a consonant, so you have to add another schwa, or a Sicilian Variant of that at the end. Jerzy Karczmarczuk (pronounced as written) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: The programming language market
Derek Elkins writes: //Discussion about Lisp in Russia, some people not getting younger, Scheme with types, and other bedlam// No language that was ever popular has ever died as far as I can tell. This is one of the persistent truths which has to be carefully interpreted. Languages mutate and give offsprings, bearing sometimes the same name. The original Fortran is undoubtly dead and buried. Long live Fortran! In some cases people defend this thesis with sophism. Algol is dead. No sense in disputing it. So what? It simply was never popular enough... Since the Nature abhorrs vacuum, all niches tend to become non-empty, and for any language, there will be some guys who will play with it. Snobol is alive, APL as well. Perhaps even Simula. When can we say that it is *really* dead? How many users? Languages are alive when people who used them are alive, and we didn't have had time enough to kill all of them, patriarchs... Look, Simon Peyton Jones was born more or less simultaneously with Fortran. And he is not so terribly old, is he? (Welll, perhaps for some of you, but not for me.) Anyway, a language, as any other conceptual structure, can be stored and communicated. You may kill all the working instances, and rekindle it later. It such a way it is difficult to kill a religion, or a political doctrine. But it may die, become useless/unused temporarily. So, you never really know... Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: The programming language market (was Re: [Haskell-cafe] Why functional programming matters
Tim Chevalier/Paul Johnson about cheap computers, expensive programmers This is true only if talking to people in high-income nations. Even in low-income nations, its only false in the short term. If you have skilled programmers with computers and Internet connections then their wages inflate to the world norm. IIRC India is seeing 20%/year wage inflation... It's true that India seems to be going in that direction, but personally I don't feel I have the background or temerity to suggest that it will definitely happen for the rest of the world. The issue is less related to the actual income, but to the global politics, sometimes doctrinal. Not always the invisible hand of market may easily change things, and if a given nation/country has historical strong views on the power of the people, the evolution is different than at your place. India doesn't seem to boast that they are numerous and powerful. Chinese do... We shall see. You may perhaps remember (which you won't, because you are too young) the glorious times when computers became a reality even in Soviet Union. They had at that time plenty of really good mathematicians. But the totalitarian view of the science, plus the nationalistic proudness, made them (the rulers not the scientists...) think and say that with so many good people, there is no need to develop the programming automated tools. They neglected the programming languages. Russia and their satellites became a kind of desert here not only because of economical problems... Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: The programming language market (was Re: [Haskell-cafe] Why functional programming matters
Dipankar Ray writes: I should point out that certain US-trained mathematicans (myself included) are actually quite jealous of the Russian math education system - they produce mathematicians who tend to be excellent... Anyway, no we're older, and we realize that it would have helped our math understanding out quite a bit had we learned more physics, engineering, etc. Or had we learned 19th century mathematics well. The Russian program seems to do this, actually (at least for the sample set of kids that make it to the US). What you're telling me below is that part of this emphasis on old-world mathematics might have come from an arrogance/bias against computers? Interesting - I'll have to think about this. I've often heard from my Eastern European colleagues that they learned almost nothing about computer science back home... === Well, I have the impression, at least I intended to say just the reverse (not the opposite), that the arrogance/bias against computers has been partly justified by a very good level in math. The decision makers confounded the math science with the domain of computation... [[Let's skip the ideological war against cybernetics as the reactionary pseudo-science which would enslave the proletarian class. End of '50, beginning of '60 this was already completely anecdotical, although some bitter aftertaste persisted...]] The stagnation in the development of automatics followed the same pattern. We have good, brave people. Who needs 'em robots... It is an *established fact* that some part of casualties during the struggle to confine Tchernobyl could have been avoided, if the authorities thought more about replacing humans with machines. But not only the authorities, folks themselves rushed to help, and safety measures were not respected as they should have been if a more liberal doctrine, with calculation of risk à l'Américaine, prevailed. And, PLEASE, Artem V. Andreev, before you say plainly again that I am definitely wrong. I didn't invent what I say, and I hope nobody can accuse me of any inimical thoughts against Russians. You say: Not wishing to refute your general point, I can only note that U.S.S.R did have its own school of computer science in general, and of developing programming language implementations in particular. There were Fortran and Algol compilers, there is Refal, after all, which is a purely Soviet invention (and which, for that matter, is still being taught in several Russian universities). So in this particular respect you are definitely wrong. Please compare the size of the country, the achievements in military equipment, cosmic exploration, etc., with what we could have seen in the development of software... An Algol compiler has even been built in my Poland, much smaller and miserable. Nothing to be proud of. My goodness, Refal... You mean the Turchin stuff? OK, OK... Nice guy, *really*. Nice idea. And no consequences... Nothing bad can I say, because I know a tiny bit about the related stuff. The language Snobol (Griswold et al.), was also based on Markov algorithms (and some centuries ago I wrote a small textbook on Snobol, I planned to teach at that time in Poland. I knew that Refal existed, and... I couldn't learn anything more). I wonder how much could do Markov himself (1903 - 1979), - his: Theory of Algorithms was published by the American Mathematical Society Translations in 1960, - if he lived in a more open society, which could *better* exploit the potential of these people. Do you think that I haven't heard about A.P. Yershov? ACM still cites him, his papers on the system ALPHA (JACM 1966), programming of arith. ops. (CACM 1958), etc. Some other names deserve mentioning as well. But what the system did, cannot be defended. This School of computer science gave some theory to the humanity. But no, or almost no software, sorry. I *sincerely* hope that it changed now. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Data constructors versus types
Achim Schneider continues to comment the Lisp history: In fact, it wasn't even meant to be a programming language, just a calculus. There is comprehensive German article (in English), by Herbert Stoyan, on this historical issue: http://www8.informatik.uni-erlangen.de/html/lisp/histlit1.html Stoyan reminds a - currently - not so obvious truth, that something like functional paradigmatics was not so popular at that time, the second half of fifties, beginning of sixties. People reasoned rather in terms of algorithms, and McCarthy was no exception. Let's cite Stoyan: To come back to functional programming, it is an important fact that McCarthy as mathematician was familiar with some formal mathematical languages but did not have a deep, intimate understanding of all their details. McCarthy himself has stressed this fact (23). His aim was to use the mathematical formalismus as languages and not as calculi. This is the root of the historical fact that he never took the Lambda-Calculus conversion rules as a sound basis for LISP implementation. So, I believe it is not so briliant an idea to confound the Church calculus with Lisp! We have also the text of the Master himself, available on-line: http://www-formal.stanford.edu/jmc/history/lisp/lisp.html The chapter on the prehistory: http://www-formal.stanford.edu/jmc/history/lisp/node2.html#SECTION000200 00 begins: My desire for an algebraic list processing language for artificial intelligence work on the IBM 704 computer arose in the summer of 1956 during the Dartmouth Summer Research Project on Artificial Intelligence which was the first organized study of AI. During this meeting, Newell, Shaw and Simon described IPL 2, a list processing language for Rand Corporation's JOHNNIAC... So, sorry, but McCarthy since the very beginning thought about making a usable computer language, not a calculus. When discussing the evolution of FLPL, the *third* point mentions Church for the first time: c. To use functions as arguments, one needs a notation for functions, and it seemed natural to use the -notation of Church (1941). I didn't understand the rest of his book, so I wasn't tempted to try to implement his more general mechanism for defining functions. Church used higher order functionals instead of using conditional expressions. ... See also the article of Paul Graham: http://lib.store.yahoo.net/lib/paulgraham/jmc.ps === Before somebody once more accuses me of pedantry, or says publicly here that I am aggressive towards people: You know that spreading half-truths, and also plain rubbish on Internet is extremely easy. Wherever you look, you find plenty of occasions to err, it suffices to put yourself in a mode of a dead person from the movie The sixth sense of M. Night Shyamalan, with Bruce Willis, and Haley Joel Osment. The boy says to the other main personage (unaware of his own condition) that dead people see only what they WANT to see... And somehow the false information spreads easier than the true one. THIS list, which, independently of the freedom to chat about anything, is still targeted at serious comp. sci. problems, and I think that the fact that somebody is young and inexperienced, is not a justification to make false claims, just because this and that had XXX years less than myself in order to read some easily available texts. Of course, anybody may say dubious truths, I am ashamed of myself, but from time to time I explode. Sorry about this. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Data constructors versus types
Achim Schneider writes: Lisp is actually not really meant to be compiled, but interpreted. The nice thing is that it doesn't need more than a handful of primitives, a list parser and heap manager/garbage collector and evaluator, which all can be implemented in under 1000 lines of C. Things get more involved with get/cc, but then how many C programmers ever heard of setjmp... Would you mind stopping to spread dubious truths? Certainly, Lisp processors started with simple eval/apply interpreters, since they were easy to construct, but compilers, their name is Legion! Look at CMU Common Lisp compiler. GNU CLISP compiler Lisp Works compiler Allegro compiler ... There are also Lisp-C translators. The result is of course compiled. CLiCC, this is a German (Kiel) product. Perhaps not so far from you. Where did you read that Lisp is not meant to be compiled, for goodness' sake!? Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why purely in haskell?
an exception, not the system. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Computer Science Books using Haskell
Don Stewart writes: One textbook on algorithms with a functional approach is by Fethi Rabhi and Guy Lapalme: Algorithms: A functional programming approach published by Addison-Wesley, 235 pages, ISBN 0-201-59604-0 I'd imagine they wouldn't use many OCR unfriendly characters. I perhaps misunderstand this phrase, but if you suggest that it would be useful to snatch the code examples from within the book, I believe that no OCR is needed, they are here: http://www.iro.umontreal.ca/~lapalme/AlgoFP/code.html Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why purely in haskell?
Ben Franksen writes: [EMAIL PROTECTED] wrote: ... Does *MATH* answer the question what is: (0/0)==(0/0) ? Nope! Exactly. So why try to give an answer in Haskell? MATH says: the expression 0/0 is undefined, thus comparing (0/0)==(0/0) is undefined, too. I would expect Haskell to say the same. I don't know whether you are serious, or you are pulling my leg... Let's suppose that it is serious. When math says that something is undefined, in my little brain I understand that there is no answer. NO answer. Is this the undefined you want to have? The bottom non-termination? Now, this is obviously the *worst* possible reaction of the system, the IEEE indefinite is much better, at least you know what had happened. Would you propose the non-termination as the issue of all errors, such as negative argument to the real sqrt, etc? Well, as you wish... But don't write medical software, please... Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why purely in haskell?
Achim Schneider writes: [EMAIL PROTECTED] wrote: When math says that something is undefined, in my little brain I understand that there is no answer. Math doesn't say that something is undefined, but tells you that you did something that's illegal, i.e. impossible, in the system you're working with. Yeah, sure. Thanks God, we have on this list a fellow who gets direct telephone calls from her Majesty the Queen Mathematics. And knows better. Go tell to all people who use the word 'undefined' in math that they are stupid. At least, more stupid than you. http://mathworld.wolfram.com/Undefined.html http://en.wikipedia.org/wiki/Defined_and_undefined http://mathforum.org/library/drmath/view/53336.html http://encarta.msn.com/encyclopedia_761568582/Calculus_(mathematics).html etc. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [newbie question] Memoization automatic in Haskell?
Henning Thielemann writes: Caching is not the default, but you can easily code this by yourself: Define an array and initialize it with all function values. Because of lazy evaluation the function values are computed only when they are requested and then they persist in the array. One should add this most simple case to the Wiki. A posteriori thought, when I reread that... This is a =part= of the story. Whatever you do with the initial calls, if there is no automatic memoization, further calls will be executed normally. The user has to replace his/her calls with the elements of the memo-array. Suppose (sorry for the awful Fibonacci again...) we define fibs = [fib n | n-[0 ..]] fib 0 = 0 fib 1 = 1 fib n = fib(n-1) + fib(n-2) If you try to get fibs!!1000 you will die before anyway. The solution is obviously to replace the recursive definition of fib by fib n = fibs!!(n-1) + fibs!!(n-2) This works well. I had a similar problem in physics, perturbation theory offers often some quite intricate, knotty recurrencies, and the memoization offers a solution for the worse than exponential complexity. But I had to use trees, 2_dim lists of lists, etc. in order to sort the order of the creation of the results appropriately. So, I agree wholeheartly with the statement that memoization is not a blind automaton, it should be used consciously, and adapted to concrete needs. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
