Re: [Haskell-cafe] How to write a pure String to String function in Haskell FFI to C++
On 2 Jun 2013, at 16:48, Brandon Allbery allber...@gmail.com wrote: On Sun, Jun 2, 2013 at 7:22 PM, Ting Lei tin...@gmail.com wrote: In particular, I wanted to avoid having an IO in the return type because introducing the impurity (by that I mean the IO monad) for this simple task is logically unnecessary. All examples involing Anything that comes into or goes out of a Haskell program is in IO, period. If you have an FFI function which is guaranteed to not change anything but its parameters and those only in a pure way, then you can use unsafeLocalState to hide the IO; but claiming that when it's not true can lead to problems ranging from incorrect results to core dumps, so don't try to lie about it. a C string I have seen so far involve returning an IO something or Ptr which cannot be converted back to a pure String. Haskell String-s are *not* C strings. Not even slightly. C cannot work with Haskell's String type directly at all. Some kind of marshaling is absolutely necessary; there are functions in Foreign.Marshal.String that will marshal Haskell String-s to and from C strings. (String is a linked list of Char, which is also not a C char; it is a constructor and a machine word large enough to hold a Unicode codepoint. And because Haskell is non-strict, any part of that linked list can be an unevaluated thunk which requires forcing the evaluation of arbitrary Haskell code elsewhere to reify the value; this obviously cannot be done in the middle of random C code, so it must be done during marshalling.) I'm not convinced that that's obvious – though it certainly requires functions (that go through the FFI) to grab each character at a time. Thanks Tom Davie ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Calling OpenGL functions from multiple threads
Just for reference – glX functions are not OpenGL functions at all, they're
also not extensions to OpenGL, so I'd be very surprised if they could be got at
from the Haskell GL bindings. glX is instead a library for creating OpenGL
contexts (and working with them) for X11.
As the Haskell bindings for OpenGL are for OpenGL, not X windows, they don't
support this call. Though another package (not sure which, because it doesn't
apply on my platform) may well include it.
Bob
if (*ra4 != 0xffc78948) { return false; }
On 12 Feb 2012, at 03:03, Clark Gaebel wrote:
Do the OpenGL bindings on Hackage expose anything like glXMakeCurrent [1]? I
need to use OpenGL functions from multiple threads (note: not at once, I
protect it with an MVar), but that's forbidden in extension-less OpenGL.
Thanks,
- clark
[1] http://www.talisman.org/opengl-1.1/Reference/glXMakeCurrent.html
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll: Do you want a mascot?
Yes
Reasoning:
Haskell has the image of being unfriendly, assenine, filled with crazy symbols,
and the dreaded MATHS! A mascot would say you know what, this is fun!
if (*ra4 != 0xffc78948) { return false; }
On 23 Nov 2011, at 19:40, Alexander Bernauer wrote:
Yes
PS: Why not using Doodle for the poll?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A Mascot
On 22 Nov 2011, at 15:40, Karol Samborski wrote: And what about a cat? The cat is associated with elegance and a kind of magic. Please take a look: http://origami.bieszczady.pl/images/kot.png My biggest criticism of the more recent ones is simply not to get carried away with magic haskell expressions, no matter how simple you think they are. The job of a mascot is to make people think aww, cute, I should clearly look into something with such a cute mascot, I suspect the response here would be more like the standard Haskell holy crap, crazy letters and symbols, get away from me! Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] bitSize
That's reasonably believable – streaming units on current CPUs can execute
multiple floating point operations per cycle.
if (*ra4 != 0xffc78948) { return false; }
On 30 Aug 2011, at 02:30, Richard O'Keefe wrote:
On 29/08/2011, at 10:32 PM, Maciej Marcin Piechotka wrote:
According to random side (http://gruntthepeon.free.fr/ssemath/) not so
new computers can compute 15.5 milions of serial logarithms per second
(62 millions in total). I'd say that overhead of Integer might be much
bigger then cost of logarithm.
That's floating-point logarithms, not Integer logarithms.
Single-precision floats, at that.
The code in question does not link at optimisation level 4.
At least some of the benchmark results are impossible to believe:
benching cephes_sinf ..
- 12762.3 millions of vector evaluations/second
- 0 cycles/value on a 2000MHz computer
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Automatic Reference Counting
Hi guys, Apple recently announced a new static analysis in Clang called ARC (Automatic Reference Counting). The idea is to provide what GC provides (zero memory management code by the programmer), but not to incur the runtime penalty of having to have the GC run. It seems to be extremely effective in objective-C land. I was wondering if any of the compiler gurus out there could comment on the applicability of this kind of analysis to Haskell. Dropping the GC and hence stopping it blocking all threads and killing parallel performance seems like nirvana. The one major problem that's still left with ARC is that it does not solve the retain cycle problem of reference counting. Programmers must insert a weak keyword to break cycles in their data graphs. Could even this analysis be automated statically? Could we put up with a language extension that added this annotation? I'd love to hear some comments from people more-experienced-than-I on this. Thanks Tom Davie ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Automatic Reference Counting
On 2 Jul 2011, at 17:18, Thomas Schilling wrote: Reference counting usually has much higher overheads than garbage collection and is tricky to parallise. It's main advantage is quicker release of memory. I believe the main feature of ARC is that the user does not need to manually keep reference counts up to date. I heard from people using CPython (which uses reference counting) as a library from C that it's very easy to accidentally forget to update the reference count correctly. With ARC the compiler takes care of it, so there's less opportunity for mistakes. ARC also optimizes away redundant reference updates within a function (Haskell functions are usually small, so I don't know how well that would work). Apple's claim is that their optimiser works globally and can optimise away redundant reference updates across functions too. It's interesting that you cite that GC is both faster and lower memory overhead – Apple's stated reasons for implementing this were that GC was both too slow and too memory intensive to use sensibly on iDevices and that ARC was both faster and less memory intensive. Tom Davie ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Automatic Reference Counting
On 2 Jul 2011, at 17:52, Chris Smith wrote: On Sat, 2011-07-02 at 17:35 +0100, Thomas Davie wrote: It's interesting that you cite that GC is both faster and lower memory overhead – Apple's stated reasons for implementing this were that GC was both too slow and too memory intensive to use sensibly on iDevices and that ARC was both faster and less memory intensive. This is a little more complex that just better or worse. The speed and memory overhead of reference counting depend on what percentage of your data structures are pointers, and of your program is performing pointer updates. Presumably, iOS developers would try to avoid a lot of small heap allocations, and instead use packed data structures with in-place updates to larger contiguous blocks of memory. In that case, it's possible that reference counting is much faster and reduces memory usage compared to garbage collection. This is certainly not the case in a typical functional language, though. When asking about memory usage, you also want to distinguish between hot memory usage (how much memory is actively used and so we want it to fit in cache) and overall memory usage (total heap size, even though a lot of it may be swapped out to disk on a desktop). Garbage collection typically increases the overall heap size, but is better than reference counting when it comes to reducing the size of the hot area of memory. So basically, I wouldn't call Apple's claims unusual when they are made for iOS and Objective C (though garbage collection is too slow to use sensibly on iDevices is definitely pushing the ridiculous side of things), but I also wouldn't expect their rather specific environment to carry over to general purpose computing, or especially to Haskell. Thanks, that's a great explanation :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Python is lazier than Haskell
On 29 Apr 2011, at 10:42, Ben Lippmeier wrote: On 29/04/2011, at 6:08 PM, Malcolm Wallace wrote: On 29 Apr 2011, at 05:38, Ben Lippmeier b...@ouroborus.net wrote: Laziness at the value level causes space leaks, This is well-worn folklore, but a bit misleading. :-) Like permanent markers in the hands of children causes suffering. It's not a tautology, but an overgeneralisation that holds more often than not. I completely disagree, like Malcolm Wallace, space leaks in my code have *more often* been to do with being too strict than being too non-strict. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Python is lazier than Haskell
On 27 Apr 2011, at 10:30, Henning Thielemann wrote: I like to apply for the quote of the week. :-) If Haskell is great because of its laziness, then Python must be even greater, since it is lazy at the type level. Dynamically typed languages only check types if they have to, that is if expressions are actually computed. Does this prove that laziness at type level as in Python is a great thing or does this prove that laziness at the value level as in Haskell is a bad thing or does this prove nothing? Hope for controversial discussion ... To add to the points various other people have made... 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. The hope being that this speeds up the calculation of the result after the overhead of laziness is taken into account. Computing types lazily does not do this – it means that instead of computing the types at compile time and doing *nothing* at runtime, we now do some computation at runtime. Not only that but we introduce more bugs. So laziness in computation takes us from doing *all* computation to doing a subset at runtime. laziness in typing takes us from doing *no* computation to doing a subset of all at runtime. Doesn't look quite so rosy now does it :) Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] bug in Prelude.words?
On 28 Mar 2011, at 17:20, malcolm.wallace wrote: Consider an HTML page with that sentence displayed on it. If you ask the viewer of the page how many words are in the sentence, then surely you will get the answer 3? But what about the author? Surely there is no reason to use a non-breaking space unless they intend it to mean that the characters before and after it belong to the same logical unit-of-comprehension? I'm not sure that a logical unit-of-comprehension is the same as a word though. As an aside – in publishing non-breaking spaces are commonly used for other purposes too, for example forcing a word onto a certain line to stop a space river appearing in a paragraph. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type problem
Because applying f to the list is not the same thing is applying bind to the list and f. Bob On 26 Feb 2011, at 20:17, michael rice wrote: Why? Shouldn't this work for any type a? Michael == f :: [a] - [a] f l = do x - l return x == *Main :r [1 of 1] Compiling Main ( test.hs, interpreted ) Ok, modules loaded: Main. *Main f abcde abcde *Main f [1,2,3,4,5] [1,2,3,4,5] *Main abcde = f interactive:1:12: Couldn't match expected type `Char' against inferred type `m b' In the second argument of `(=)', namely `f' In the expression: abcde = f In the definition of `it': it = abcde = f *Main ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ghci command line execution
A while ago I remember someone showing me some tool, I *think* ghci that allowed you to pass it a function of type String - String as an input, and have it simply run that function on stdin (presumably using interact) to achieve useful things like this... $ cat myFile.txt | ghci -e 'unlines . zipWith (\x y - show x ++ ++ y) [1..] . lines' Does anyone know what it was that I saw being used here? Thanks Tom Davie ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] ANNOUNCE: pwstore 1.0 (Secure password storage)
On 7 Feb 2011, at 03:23, Mark Wotton wrote: If you're going to use C anyway, why not bind bcrypt? Better yet, bind the password storage API on platforms where it exists (e.g. keychain access on OS X) Tom Davie ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] Reader monad wrapping State monad
Is the idea here merely an exercise in using the state monad? This can be
easily performed using pure code.
Bob
On 3 Feb 2011, at 19:18, michael rice wrote:
Given the first program, it seems that the unchanging first element of the
tuple could be handled by a Reader monad, leading to the second program,
where b becomes the state, but how do I get the constant a from the Reader
monad?
Michael
==
import Control.Monad.State
type GeneratorState = State (Double,Double)
sqrtST :: GeneratorState Double
sqrtST = do (a,b0) - get
let b1 = (b0**2.0+a)/(2.0*b0)
(if (abs (a-b1**2.0)) 0.01
then
return b1
else do
put (a,b1)
sqrtST)
mySqrt a = let b = a/2.0
in fst ( runState sqrtST (a,b) )
{-
*Main mySqrt 2.0
1.4142135623746899
-}
==
import Control.Monad.Reader
import Control.Monad.State
type GeneratorState = State Double
sqrtST :: GeneratorState Double
sqrtST = do b0 - get
let a = ?
b1 = (b0**2.0+a)/(2.0*b0)
(if (abs (a-b1**2.0)) 0.01
then
return b1
else do
put b1
sqrtST)
mySqrt a = let b = a/2.0
in runReaderT (runState sqrtST b) a
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC optimizations and unsafePerformIO - Was: Data.Typeable TypeRep Ord instance.
On 1 Jan 2011, at 12:38, Andreas Baldeau wrote: Thinking about this there might be one problem: Without having looked further into this I think perfomance might not be as expected. Using unsafePerformIO affects ghc's optimzations, doesn't it? So I wonder if it's a good idea (from a performance point of view) to use this. 2010/12/30 Andreas Baldeau andr...@baldeau.net: instance Ord TypeRep where compare t1 t2 = compare (unsafePerformIO (typeRepKey t1)) (unsafePerformIO (typeRepKey t2)) typeRepKey :: TypeRep - IO Int typeRepKey (TypeRep (Key i) _ _) = return i So the question is, if ghc could transform this to simply compare the keys throwing away unsafePerformIO and return. Wouldn't a much better plan simply be to take typeRepKey out of the IO monad? Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is Haskell flagging this?
On 17 Dec 2010, at 21:44, Christopher Done wrote: On 17 December 2010 18:04, michael rice nowg...@yahoo.com wrote: === f :: [Int] - IO [Int] f lst = do return lst main = do let lst = f [1,2,3,4,5] fmap (+1) lst The problem is that you are applying fmap to a type IO a. fmap (+1) (return [1,2,3]) But to achieve the behaviour you expect, you need another fmap: fmap (fmap (+1)) (return [1,2,3]) Which can be more neatly written with Conal's semantic editor cominators as (fmap . fmap) (+1) (return [1,2,3]) Of course, I question why the list is put in the IO monad at all here... surely this would be much better return $ fmap (+1) [1,2,3] Finally, that has the wrong type for main... perhaps you meant to print it out? main :: IO () main = print $ fmap (+1) [1,2,3] Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Serialization of (a - b) and IO a
On 11 Nov 2010, at 08:36, Luke Palmer wrote: On Thu, Nov 11, 2010 at 12:53 AM, Jesse Schalken jesseschal...@gmail.com wrote: I have had a look at hs-plugins, but it is unclear how to derive a simple pair of functions `(a - b) - ByteString` and `ByteString - Either ParseError (a - b)`, for example, from the functionality it provides, if it is possible at all. I guess such a thing requires thorough digging into the depths of GHC, (or maybe even LLVM if an architecture independent representation is sought, but I don't know enough to say.). Perhaps this is more a question for those interested and knowledgable in Haskell compilation (and, to some extent, decompilation). If not Haskell, are there any languages which provide a simple serialization and deserialization of functions? As far as I know, GHC has no support for this. There are issues with the idea that will come out pretty fast, such as: (1) Those cannot be pure functions, because it differentiate denotationally equal functions. So it would have to be at least (a - b) - IO ByteString. I don't think I agree, I didn't see a rule f == g = serialise f == serialise g anywhere. Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocolimplementation
While I agree with the potential benefits, I also worry that you will end up making something that is far less well tested in practice. For widely used and fairly low-level libraries like gnutls, openssl and zlib, I'm just skeptical that the benefits outweigh the risks and costs. Anyway, it's just a feeling. Please do prove me wrong :-) This certainly isn't a proof by a long shot, but my feeling on at least low-level libraries is exactly the reverse of this. C libraries are usually designed to be extremely stateful (this certainly includes openssl), and because of that any Haskell wrapper for them ends up being heavily IO based. The result of this is that any code that incorporates it ends up being trapped in an IO mess to do essentially pure (yes, I know the arguments about IO being pure, you know what I mean) things. It's precisely these libraries that we need not just implemented in a native way, but designed in a pure, beautiful, simple way for Haskell. While I can see your point about potentially introducing new security holes, and producing much less trusted code, I feel having tidy, pure libraries that we can all integrate into our Haskell is a benefit that far outweighs this. Especially when we have nice things like the type system, which can be used to alleviate many of the security worries. Tom Davie___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Generating arbitrary functions with QuickCheck?
On 15 Sep 2010, at 16:29, Matias Eyzaguirre wrote: Hi, I'v been reading a small paper/lesson on writing parser combinators in Haskell, and it seems more or less straightforward. In this case a parser is defined thusly: type Parser a = String - Maybe (a, String) And then it goes on to list some simple parsers, and then starts going on about combinators. I was wondering how one would write quickcheck properties for the items presented in the paper, and the answer seemed fairly straightforward for the actual parsers. But how on earth would you write a test for a combinator? Presumable one would need to make the type an instance of Arbitrary. I see two problems: Firstly, as far as i can tell, one cannot declare a type synonym to be an instance of a type class, thus how would you make it an instance of Arbitrary? The standard solution here is to create a newtype, and generate them instead. Secondly, (and more importantly, or at least more interesting) I can see how one would make a generator for simple compound data types, but how on earth do you make a generator produce functions? With some difficulty, but it can be done. You could for example, select at random, a combinator or axiomatic parser, on selecting a combinator, generate a pair of parsers to hand to it with a slightly lower chance of generating a combinator and stick them together. Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Do expression definition
On 13 Sep 2010, at 10:28, Gleb Alexeyev wrote: On 09/13/2010 12:23 PM, Michael Lazarev wrote: 2010/9/13 Henning Thielemannlemm...@henning-thielemann.de: It means that variables bound by let, may be instantiated to different types later. Can you give an example, please? testOk = let f = id in (f 42, f True) --testNotOk :: Monad m = m (Int, Bool) --testNotOk = do f - return id -- return (f 42, f True) Try uncommenting the 'testNotOk' definition. There's no later here at all. Two seperate definitions in a Haskell program act as if they have always been defined, are defined, and always will be defined, they are not dealt with in sequence (except for pattern matching but that doesn't apply here). Instead, what's going on here is scoping. The f in testOk is a different f to the one in testNotOkay, distinguished by their scope. Finally, this is not how you use a let in a do expression, here's how you should do it: testOk2 :: Monad m = m (Int, Bool) testOk2 = do let f = id return (f 42, f True) Thanks Tom Davie___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On to applicative
On 26 Aug 2010, at 08:01, michael rice wrote: Hmm... it was my understanding that the example was showing how to *avoid* having to create a lot of functions that do the same thing but have different numbers of arguments. From the Wiki page: Anytime you feel the need to define different higher order functions to accommodate for function-arguments with a different number of arguments, think about how defining a proper instance of Applicative can make your life easier. Not so? Very much so – instead of defining liftA2, liftA3 etc like this, just use pure to get things into the applicative, and write * instead of ' ' to apply applicatives and you're done. Don't write liftA3 sumsq (Just 3) (Just 4) (Just 5) Write (pure sumsq) * (pure 3) * (pure 4) * (pure 5) or you can get rid of that first pure with a quick fmap: sumsq $ (pure 3) * (pure 4) * (pure 5) Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Can we come out of a monad?
On 11 Aug 2010, at 12:39, Ertugrul Soeylemez wrote: Martijn van Steenbergen mart...@van.steenbergen.nl wrote: On 8/2/10 7:09, Ertugrul Soeylemez wrote: Given the definition of a Haskell function, Haskell is a pure language. The notion of a function in other languages is not: int randomNumber(); The result of this function is an integer. You can't replace the function call by its result without changing the meaning of the program. I'm not sure this is fair. It's perfectly okay to replace a call randomNumber() by that method's *body* (1), which is what you argue is okay in Haskell. This is not the same. In Haskell you can replace the function call by its /result/, not its body. You can always do that. But the result of an IO-based random number generator is an IO computation, not a value. It's not source code either, and it's not a function body. It's a computation, something abstract without a particular representation. It's still rather papering over the cracks to call this pure though. The IO based computation itself still has a result that you *can't* replace the IO based computation with. The fact that it's evaluated by the runtime and not strictly in haskell may give us a warm fuzzy feeling inside, but it still means we have to watch out for a lot of things we don't normally have to in a very pure[1] computation. Bob [1] Bob's arbitrary definition 1 – very pure computations are ones which can be replaced with their result without changing the behavior of the program *even* if said result is computed in the runtime and not by the Haskel program.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Can we come out of a monad?
On 11 Aug 2010, at 14:17, Ertugrul Soeylemez wrote: There is a fundamental difference between an IO computation's result and a Haskell function's result. The IO computation is simply a value, not a function. That's a rather odd distinction to make – a function is simply a value in a functional programming language. You're simply wrapping up we're talking about haskell functions when we talk about referential transparency, not about IO actions in a way that maintains the warm fuzzy feeling. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Can we come out of a monad?
On 1 Aug 2010, at 11:43, Ertugrul Soeylemez wrote: Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: No, a pure function is one without any side effects. There are no functions with side effects in Haskell, unless you use hacks like unsafePerformIO. Every Haskell function is perfectly referentially transparent, i.e. pure. This is why we badly need a new term, say, io-pure. That means, neither has side effects, nor produces an action that when run by the runtime has side effects. Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] lists of arbitrary depth
On 13 Jul 2010, at 10:11, Shlomi Vaknin wrote: Thank you all for replying! I am really beginning my baby steps in this fascinating language, and was just wondering if it was possible to naturally scan lists with arbitrary lists (aka trees :) ). Trees aren't lists, Trees are trees... Here's how you create one* data Tree a = Leaf | Branch a [Tree a] This roughly says, a tree can be made up of two possible things... First, it could be a leaf, and secondly, it could be a branch with an element at it, and a list of subtrees. Some example trees using this data type: 1) Leaf 2) Branch 5 [] 3) Branch 5 [Leaf] 4) Branch 5 [Branch 10 [], Branch 20 [], Leaf, Branch 50 [Branch 10 [], Leaf]] When you have really strong typing, you also have very well specified types. You don't just use a list as if it were a tree, you declare what a tree is. Bob * In this case an arbitrarily branching tree, we could ofc declare different forms of tree here.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How easy is it to hire Haskell programmers
On 3 Jul 2010, at 03:39, Don Stewart wrote: ivan.miljenovic: Hmm, interesting. Applicative and Traversable are two classes I've never used and don't really understand the purpose of. I have no idea what hsc2hs is. I keep hearing finger trees mentioned, but only in connection to papers that I can't access. So I guess that means that I don't count as a knowledgable Haskell programmer. :-( RWH is free and online, and covers many useful things. There's no excuse :-) Knowing about something /= knowing how to use it. I own and have read RWH, but I've never had to use hsc2hs, or Applicative, etc. Writing libraries that bind to C is a great way to have to use a lot of hsc2hs (or c2hs), so clearly you need to contribute more libraries :-) Alternatively, they're already busy contributing lots of purely functional libraries, instead of doing (still valuable) work getting C cludges working. Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Are you a Haskell expert? [How easy is it to hire Haskell programmers]
On 3 Jul 2010, at 11:04, Brandon S Allbery KF8NH wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/3/10 05:57 , Andrew Coppin wrote: Agreed. So let me rephrase: Why should _every_ Haskell library involve C? ;-) Who says they do, or should? Dons rather implied it... The suggestion is that someone who hasn't used hsc2hs is an inexperienced Haskeller... I'd bet though that there are many *extremely* experienced haskellers who have never once in their life written a C binding. Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Physical equality
On 28 Jun 2010, at 09:38, José Romildo Malaquias wrote: Is there in Haskell a non monadic function of type a - a - Bool which test for physical equality of two values? It would return True if only if both values are the same object in memory. For instance: value1 = good value2 = good eq value1 value2 = False value1 = good value2 = value1 eq value1 value2 = True This simply isn't possible without manually tagging values yourself (or with a library), it would violate referential transparency. Remember, a function, called twice with semantically identical arguments must always return the same value, that isn't true of eq. Even if this weren't an issue, you're relying heavily on the runtime's behaviour here. There's nothing to stop the runtime, in the first example, observing that the two values are identical, and making them both take up the same memory – they are after all immutable, so that's totally safe. There's similarly nothing to stop the runtime, in the second example, arbitrarily copying the the string (although it's probably not a great idea for efficiency). Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: Sum type branches as extended types (as Type!Constructor)
On 3 Jun 2010, at 16:14, Gabriel Riba wrote:
Extending sum types with data constructors would spare runtime errors or
exception control,
when applying functions to inappropriate branches, as in the example ...
data List a = Nil | Cons a (List a) -- List!Nil and List!Cons
-- as extended types
* Actual system, with runtime errors (as in GHC Data.List head) or
exception throwing
hd :: List a - a
hd (Cons x _) - x
hd Nil - error error: hd: empty list -- error or exception throwing
* Proposed system extending types with constructors as Type!Constructor:
User must do pattern matching before applying the constructor-specific
type function.
In ''var @ (Constructor _ _)'' the compiler should append the constructor
to the type as a pair (Type, Constructor) as an extended type for ''var''
No need for runtime errors or exception control
hd :: List!Cons a - a
hd (Cons x _) = x
using it:
headOf :: List a - Maybe a
headOf list = case list of
li @ (Cons _ _) - Just hd li -- extTypeOf li == ( 'List', 'Cons')
-- should pass typechecker for List!Cons
li @ Nil - Just hd li -- compiler error !!
-- extTypeOf ('List','Nil') don't match
_ - Just hd list -- compiler error !!
-- extTypeOf ('List',Nothing) don't match
Maybe we could take out importance on the number of _ wildcards (constructor
arity) with a syntax like.
li @ (Cons ...)
li @ (Nil ...)
This looks fairly similar to total functional programming, though putting the
onus on the caller to make sure it meets preconditions, rather than the callee
to make sure it's the right type.
In total functional programming we would say
head :: List a - Maybe a
head (Cons x _) = Just x
head Nil = Nothing
We'd then allow the caller to deal with the maybe any way it likes (commonly
with fmap, or with the maybe function).
Bob___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why Either = Left | Right instead of something like Result = Success | Failure
On 27 May 2010, at 15:25, Ionut G. Stan wrote: Hi, I was just wondering if there's any particular reason for which the two constructors of the Either data type are named Left and Right. I'm thinking that something like Success | Failure or Right | Wrong would have been a little better. The reason I guess is that Success/Failure and Right/Wrong are a lot less general than Left/Right. One can use Either for types with two possible valid types contained within, it doesn't only have to be used for types where one is for correct results and the other for erroneous. Of course, there's nothing stopping you implementing your own type :) Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] help with Haskell programming
I'm not certain exactly what you mean, but I *think* you mean: func :: (a - Bool) - (a - Bool) func = (not .) Bob On 18 Apr 2010, at 16:35, Mujtaba Boori wrote: Hello I am kinda newbie in Haskell you can help help me with some programming I am trying to make function like for example func :: (a - Bool) - (a - Bool) this function make calculation and return bool . I want to be able to make bool True when It is False and False when it is True while returning the a. Thank you -- Mujtaba Ali Alboori ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: help with Haskell programming
To do this, you need not just fmap (composition), but also ap, or the combined form, liftA2: func = liftA2 (||) Bob On 18 Apr 2010, at 18:21, Keith Sheppard wrote: Using composition can be tricky with more than one arg. I just want to be sure you're not really looking for something like: func :: (a - Bool) - (b - Bool) - (a - b - Bool) keeping with your given type I think you're looking for something like: func f1 f2 x = (f1 x) || (f2 x) I'm sure there is a nice way to do this with function composition but I still find composition less intuitive than explicit args in cases like this. On Sun, Apr 18, 2010 at 1:00 PM, Mujtaba Boori mujtaba.bo...@gmail.com wrote: Thanks for helping me but I have another problem (sorry for asking) . I tried to figure it out . how about if I want to compare two kind with () (||) for func :: (a - Bool) - (a - Bool) - (a - Bool) I tried some thing like func = ((||) .) This is the annoying part about Haskell . I can not understand composition . On Sun, Apr 18, 2010 at 4:35 PM, Mujtaba Boori mujtaba.bo...@gmail.com wrote: Hello I am kinda newbie in Haskell you can help help me with some programming I am trying to make function like for example func :: (a - Bool) - (a - Bool) this function make calculation and return bool . I want to be able to make bool True when It is False and False when it is True while returning the a. Thank you -- Mujtaba Ali Alboori -- Mujtaba Ali Alboori ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- keithsheppard.name ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: instance Eq (a - b)
Your instances of Finite are not quite right: bottom :: a bottom = doSomethingToLoopInfinitely. instance Finite () where allValues = [(), bottom] instance Finite Nothing where allValues = [bottom] Though at a guess an allValuesExculdingBottom function is also useful, perhaps the class should be class Finite a where allValuesExcludingBottom :: [a] allValues :: Finite a = [a] allValues = (bottom:) . allValuesExcludingBottom Bob On 14 Apr 2010, at 08:01, Ashley Yakeley wrote: Joe Fredette wrote: this is bounded, enumerable, but infinite. The question is whether there are types like this. If so, we would need a new class: class Finite a where allValues :: [a] instance (Finite a,Eq b) = Eq (a - b) where p == q = fmap p allValues == fmap q allValues instance (Finite a,Eq a) = Traversable (a - b) where sequenceA afb = fmap lookup (sequenceA (fmap (\a - fmap (b - (a,b)) (afb a)) allValues)) where lookup :: [(a,b)] - a - b lookup (a,b):_ a' | a == a' = b lookup _:r a' = lookup r a' lookup [] _ = undefined instance Finite () where allValues = [()] data Nothing instance Finite Nothing where allValues = [] -- Ashley Yakeley ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: instance Eq (a - b)
On 14 Apr 2010, at 08:29, Ashley Yakeley wrote: On Wed, 2010-04-14 at 08:13 +0100, Thomas Davie wrote: Your instances of Finite are not quite right: bottom :: a bottom = doSomethingToLoopInfinitely. instance Finite () where allValues = [(), bottom] Bottom is not a value, it's failure to evaluate to a value. But if one did start considering bottom to be a value, one would have to distinguish different ones. For instance, (error ABC) vs. (error PQR). Obviously this is not finite. Certainly bottom is a value, and it's a value in *all* Haskell types. Of note, bottom is very important to this question – two functions are not equal unless their behaviour when handed bottom is equal. We also don't need to distinguish different bottoms, there is only one bottom value, the runtime has different side effects when it occurs at different times though. Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: instance Eq (a - b)
On 14 Apr 2010, at 09:01, Jonas Almström Duregård wrote: But if one did start considering bottom to be a value, one would have to distinguish different ones. For instance, (error ABC) vs. (error PQR). Obviously this is not finite. Nor is it computable, since it must distinguish terminating programs from nonterminating ones (i.e. the halting problem). On a side note, since instance (Finite a, Finite b) = Finite (a - b) should be possible, one can even compare some higher order functions with this approach ;). f,g :: Bool - Int f x = 6 g x = 6 We can in Haskell compute that these two functions are equal, without solving the halting problem. Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: instance Eq (a - b)
On 14 Apr 2010, at 09:08, Jonas Almström Duregård wrote: f,g :: Bool - Int f x = 6 g x = 6 We can in Haskell compute that these two functions are equal, without solving the halting problem. Of course, this is the nature of generally undecidable problems. They are decidable in some cases, but not in general. Well yes, but we already knew that this was true of function equality – we can't tell in general. Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: instance Eq (a - b)
On 14 Apr 2010, at 09:12, Jonas Almström Duregård wrote: f,g :: Bool - Int f x = 6 g x = 6 We can in Haskell compute that these two functions are equal, without solving the halting problem. what about these? f,g :: Bool - Int f x = 6 g x = x `seq` 6 As pointed out on #haskell by roconnor, we apparently don't care, this is a shame... We only care that x == y = f x == g y, and x == y can't tell if _|_ == _|_. It's a shame that we can't use this to tell if two functions are equally lazy (something I would consider part of the semantics of the function). Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: instance Eq (a - b)
On 14 Apr 2010, at 09:17, Ashley Yakeley wrote: Thomas Davie wrote: Certainly bottom is a value, and it's a value in *all* Haskell types. This is a matter of interpretation. If you consider bottom to be a value, then all the laws fail. For instance, (==) is supposed to be reflexive, but undefined == undefined is not True for almost any type. For this reason I recommend fast and loose reasoning: http://www.cs.nott.ac.uk/~nad/publications/danielsson-et-al-popl2006.html It might be nice to have a definition of whether we consider bottom to be a value in Haskell then, because the definition of second and fmap on tuples are different because of this consideration: fmap f (x,y) = (x,f y) second f ~(x,y) = (x,f y) Because we consider that the Functor laws must hold for all values in the type (including bottom). Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: instance Eq (a - b)
On 14 Apr 2010, at 09:25, Ashley Yakeley wrote: Thomas Davie wrote: Because we consider that the Functor laws must hold for all values in the type (including bottom). This is not so for IO, which is an instance of Functor. fmap id undefined is not bottom. It isn't? fPrelude fmap id (undefined :: IO ()) *** Exception: Prelude.undefined Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: instance Eq (a - b)
On 14 Apr 2010, at 09:31, Ashley Yakeley wrote: On Wed, 2010-04-14 at 09:29 +0100, Thomas Davie wrote: It isn't? fPrelude fmap id (undefined :: IO ()) *** Exception: Prelude.undefined ghci is helpfully running the IO action for you. Try this: seq (fmap id (undefined :: IO ())) not bottom Ah, rubbish... I guess this further reinforces my point though – we have a mixture of places where we consider _|_ when considering laws, and places where we don't consider _|_. This surely needs better defined somewhere. For reference, the fmap on tuples which ignores the bottom case for the sake of the laws is useful :(. Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: instance Eq (a - b)
On 14 Apr 2010, at 09:35, Jonas Almström Duregård wrote: what about these? f,g :: Bool - Int f x = 6 g x = x `seq` 6 As pointed out on #haskell by roconnor, we apparently don't care, this is a shame... We only care that x == y = f x == g y, and x == y can't tell if _|_ == _|_. So the facts that (1) f == g (2) f undefined = 6 (3) g undefined = undefined is not a problem? Yeh :( Shame, isn't it. Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: instance Eq (a - b)
On 14 Apr 2010, at 09:39, Ashley Yakeley wrote: Thomas Davie wrote: I guess this further reinforces my point though – we have a mixture of places where we consider _|_ when considering laws, and places where we don't consider _|_. This surely needs better defined somewhere. It's easy: don't consider bottom as a value, and the laws work fine. If it were this easy, then why is our instance of Functor on tuples gimped? Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell.org re-design
On 7 Apr 2010, at 02:53, Ben Millwood wrote: On Wed, Apr 7, 2010 at 2:22 AM, Thomas Schilling nomin...@googlemail.com wrote: I have set a maximum width on purpose so that it doesn't degrade too badly on big screens. I've never really trusted this argument - it's not required that the browser window occupy the entire screen, so why not let the user choose how wide they want their text? Unfortunately, because the majority operating system has such bad window management that all users do make their windows take up the entire screen. :( Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskellers hate GUIs!!
On 2 Apr 2010, at 21:01, Brandon S. Allbery KF8NH wrote: On Apr 2, 2010, at 15:21 , Thomas Schilling wrote: On 2 April 2010 20:15, Brandon S. Allbery KF8NH allb...@ece.cmu.edu wrote: On Apr 2, 2010, at 10:41 , David Leimbach wrote: Having said that, are there any plans to make it really easy to get gtk2hs working on Mac OS X? It's in MacPorts. But that's the variant using X11, no? There now is a Gtk+ framework, BTW, native Cocoa support is now part of the standard Gtk+ distribution. Unfortunately, it still doesn't behave anything like a Cocoa application.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [OT?] Haskell-inspired functions for BASH
Unfortunately though, h4sh seems to be broken, for one, there's no fps package (apparently required), and hsplugins won't build with 6.12.1. Bob On 1 Apr 2010, at 15:41, Jeremy Shaw wrote: How about: http://www.cse.unsw.edu.au/~dons/h4sh.html It brings a lot of familiar Haskell functions to the command-line. And *is* actually written in Haskell ;) - jeremy On Wed, Mar 31, 2010 at 6:05 PM, Patrick LeBoutillier patrick.leboutill...@gmail.com wrote: Hi all, I've been studying Haskell for about a year now, and I've really come to like it. In my daily work I write a lot of BASH shell scripts and I thought I'd try add some of the haskell features and constructs to BASH to make my scripting life a bit easier. So I've been working on a small BASH function library that implements some basic functional programming building blocks. Note: There is no actual Haskell code involved here. I put up the full manpage here: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=24564 Source is here: http://svn.solucorp.qc.ca/repos/solucorp/bashkell/trunk/trunk/ All this is very prototypical, but here is an example of some of the stuff I've got so far (map, filter, foldr): $ ls data 1.txt 2.txt # basic map, argument goes on the command line $ ls -d data/* | map basename 1.txt 2.txt # map with lambda expression $ ls -d data/* | map '\f - basename $f .txt' 1 2 # simple filter, also works with lambda $ ls -d data/* | map basename | filter 'test 1.txt =' 1.txt # sum $ ls -d data/* | map '\f - basename $f .txt' | foldr '\x acc - echo $(($x + $acc))' 0 3 Basically I'm looking for a bit of feedback/info: - Does anyone know if there are already similar projets out there? - Does anyone find this interesting? - Any other comment/suggestion/feedback - Where's a good place to promote such a project? Thanks a lot, Patrick LeBoutillier -- = Patrick LeBoutillier Rosemère, Québec, Canada ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackape package lackage
I'd love to see that map normalised by the population of the country – would be interesting to see where Haskell is popular. Bob On 22 Mar 2010, at 16:22, Don Stewart wrote: We're watching *massive* traffic right now due to HP release. It's not down, just very very busy. For fun, here's a map of who's downloading Haskell: http://imgur.com/flwPF.png 74 countries in 12 hours, and counting. - Don dougal: Hackage seems to be down again. $ cabal update Downloading package list from server 'http://hackage.haskell.org/packages/archive' ^Ccabal: interrupted $ ping -c3 hackage.haskell.org PING abbot.galois.com (69.30.63.204) 56(84) bytes of data. --- abbot.galois.com ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 2012ms ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell-beginners] map question
On 18 Sep 2009, at 04:32, Gregory Propf wrote: Heh, perhaps we should petition to have a new computer key and symbol added to the world's way of writing maths, something like maybe a downward angled slash to mean prefix (-) Such a symbol already exists, but isn't in the ASCII set: (-) (unicode 0x2D) hyphen minus and (‐) (unicode 0x2010) hyphen are not the same as (−) (unicode 0x2200) minus sign notably also, not the same as ‒, –, — and ― (figure dash, en- dash, em-dash and horizontal bar). Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Snow Leopard Breaks GHC
If it is closed, it is fixed in the HEAD. Any ideas how to get hold of a copy of HEAD, when my Haskell compiler currently outputs rubbish? Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: bug in language definition (strictness)
On 6 Aug 2009, at 17:34, Mathias Stearn wrote: On Thu, Aug 6, 2009 at 11:00 AM, Ross Patersonr...@soi.city.ac.uk wrote: There is no stack overflow in the denotational semantics. There is currently no denotational semantics simulator with an infinite stack. Until there is, Haskell programs will have to be executed on lowly physical computers with all the limitations that is implied. Can we please make things work well on them? When writing a document that defines the denotation of values, no. Perhaps when considering operational semantics, but that's an entirely different matter. Bob ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: [Haskell-cafe] ANNOUNCE: The Haskell Platform 2009.2.0.2
I tried the Mac OS X package yesterday, after getting frustrated with random crashes in my broken GHC 6.9 install... It worked flawlessly, and got me set up in minutes. Great job everyone associated with building this installer -- it's now definitely my preferred way of getting GHC on a mac. Bob On 3 Aug 2009, at 02:00, Don Stewart wrote: bugfact: On Mon, Aug 3, 2009 at 1:41 AM, Don Stewart d...@galois.com wrote: * Improvements to crazy popular Windows installer Are you kidding or are indeed many Windows users playing with Haskell these days? No, literally, http://donsbot.wordpress.com/2009/07/26/haskell-platform-progress-report/ From the first few minutes of the release, downloads of the various windows installer were running at many times the rate as that for other platforms (there had until now been no single Haskell package for Windows, after all). This surprised us. By the end of July 2009, 90 days later, there had been: * 114,790 downloads of the Windows installer (!!) * 2,790 installs of the generic unix source tarball (complementing the packages provided on each distro). On June 1, the Mac OSX package went live, complementing the MacPorts GHC version. * 1,300 installs of the Mac OSX package. Since that was published there have been another 13.9k downloads of the Windows installer -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell] Building a library for C users
Hiya all, I'm trying to build a library that can be called from C code. The ghc manual implies that this can be done, but does not specify the compiler options that I need to throw at it, and into which files I should put initialisation/end routines. Does anyone know the magic I need to invoke to get ghc to produce for me (a) a header file, (b) preferably a dynamic library, put a static one if all else fails. Thanks Tom Davie ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] ANN: Leksah 0.6
On 24 Jul 2009, at 15:52, Hamish Mackenzie wrote: Hi, Just a quick note to let people know we released a new version of Leksah this week. Thanks for the help and feedback on the previous version. We have done our best to add the features we thought were most pressing. Please give it a go and let us know what features you would like to see most in the future. http://leksah.org/ __ What's New __ * Integrated GHCi based debugging * Multi-window support (View - Detach) * Improved layout control (drag drop and nesting) * Regular expression find and replace * Grep files in the current package * Improved Mac OS X integration __ Known Bugs and Problems __ * The package editor works only for cabal files without configurations. * MS Windows: The check for external modifications of source files does not work. * MS Windows: Interruption of a background build does not work. * Navigation in Trace history does not work. Mac OSX users can install using Mac Ports as usual or use the provided Intel binary (tested on Leopard only). http://leksah.org/Leksah-0.6.1.0.dmg The new detach feature is great, it makes it much more usable for OS X users, but there's a small problem – if you detach the main source window (from the default config), you end up with a window containing just the package management/documentation stuff, which is great, but I'd like to be able to shrink it down. You can't unfortunately because of the toolbar. Would it be possible to move the toolbar onto the document windows rather than the package window.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Leksah 0.6
On 24 Jul 2009, at 18:01, Hamish Mackenzie wrote: 2009/7/25 Thomas Davie tom.da...@gmail.com: The new detach feature is great, it makes it much more usable for OS X users, but there's a small problem – if you detach the main source window (from the default config), you end up with a window containing just the package management/documentation stuff, which is great, but I'd like to be able to shrink it down. You can't unfortunately because of the toolbar. Would it be possible to move the toolbar onto the document windows rather than the package window. Try this... start with the default layout (rm ~/.leksah/Current.session) click on the Modules tab (make sure it says Modules in the status bar) View - Collapse (this will combine the two panes on the right into one) View - Detach (this will detach them leaving the main toolbar behind) Perfect :) Leksah is looking really rather impressive, I look forward to seeing what else you do with it. Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] what about adding a HIDE pragma ?
On 22 Jul 2009, at 14:53, Bulat Ziganshin wrote: Hello Marc, Wednesday, July 22, 2009, 4:28:49 PM, you wrote: So does it make sense to add this information using pragmas? pragmas shouldn't change program behavior or alter whether program may be compiled of course, LANGUAGE pragmas violate this law, but is considered as bug in Haskell developments rather than welcomed feature Why shouldn't they? I'm not particularly in support of this idea -- it makes it less clear what is being exported by the module, but I don't get your reasoning. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Python vs Haskell in tying the knot
On 17 Jul 2009, at 12:41, Cristiano Paris wrote: Thank you all for your answers and sorry for the delay I'm writing this message but before replying, I wanted to be sure to understand your arguments! Now, I'm starting to get into this tying the knot thing and understand why the Haskell version of fib ties the knot while my Python version does not. It seems all related to the thunk thing, i.e. in the Haskell version the subsequent calls to fib are not actual calls because they all refers to the same thunk, which is evaluated on demand. Now, to confirm my hypothesis, I wrote a slight different version of fib, like follows: fib' n = 1:1:(fib' n) `plus` (tail $ fib' n) where plus = zipWith (+) i.e. I inserted a fictious argument n in the definition of fib'. Now, if I try take 30 $ fib' 100, it takes significntly longer than take 30 fib: specifically, the latter is instantaneous, while the former takes about 5 seconds to complete on my MacBook Pro. Is this an evidence that the tying the knot process is going on in the first version? That's correct More, I've read that a fully lazy language would memoize all functions by default: in this case, even fib' would have been tying the knot. But this is not the case of Haskell. Am I wrong? Memoization is not a feature of lazyness. If you can do it in such a way that you don't waste significant amount of RAM, then it may be a nice optimisation, and an alternative evaluation strategy, but it would not be lazy. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Leaner Haskell.org frontpage
On 15 Jul 2009, at 06:03, Richard O'Keefe wrote: On Jul 10, 2009, at 6:14 PM, Thomas Davie wrote: In my mind, the front page is for nothing more than enticing people to use Haskell for long enough to look at a second page where all the useful stuff is if you are a haskell programmer. I would have thought that a web page should serve its most frequent visitors best. By all means have an enticing paragraph at the top, pointing to a second page, but why make life hard for regular Haskellers visiting their site? Because regular haskellers are perfectly capable of bookmarking http://haskell.org/usefullstuff.html , while newbies will only get what google tells them -- the front page. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What to say about Haskell?
On 14 Jul 2009, at 15:30, Patai Gergely wrote: Hello all, I was asked to give a one-hour 'introductory' seminar on Haskell. The audience is a bunch of very clever people with a wider than usual perspective on programming and mathematics, and my talk should be rather informational than evangelistic. Which topics do you think I should touch by all means given the short time? Lazyness and the many funky things it lets you do -- there's tons of elegant programs that are only possible because of lazyness :) Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RE: Haskell as a first language?
On 14 Jul 2009, at 13:48, Duncan Coutts wrote: On Tue, 2009-07-14 at 03:01 -0700, Michael Vanier wrote: Charles, Haskell is a wonderful language (my favorite language by far) but it is pretty difficult for a beginner. In fact, it is pretty difficult for anyone to learn in my experience, because it has so many advanced concepts that simply don't exist in other languages, and trying to absorb them all at once will likely be overwhelming. As a contrary data-point, at Oxford we teach functional programming (using Haskell) as the first course at the very beginning of the computer science degree. I know several other universities also use FP and Haskell very early on in their CS courses. On the Oxford course about half the students have had significant previous programming experience. There does not appear to be a significant difference in how quickly students with little previous programming experience learn FP compared to those with more programming experience (keep in mind these are young people, not mature students with years of professional programming experience). The point is, it's not at all clear that it's a harder language for beginners. Unfortunately, it rather hard to gather decent evidence about learning on which one could base decisions on the choice of language. What I'd be interested to see is how fast beginners pick up haskell compared to imperative language – is it actually hard to learn, or do we just forget how hard it was to learn a new paradigm when we first learned imperative programming. I guess it's rather hard to establish a metric for how fast the learning occurs though. Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Leaner Haskell.org frontpage
On 9 Jul 2009, at 18:32, Thomas ten Cate wrote: Are there any kind of hard statistics and analytics that we can base this discussion upon? There is always room for improvement, but stumbling around in the dark making blind guesses may not be the best way to go. Although I personally feel that Lenny's proposed page is an improvement, statistics could tell us what actual people actually use the site for. I'm not sure that that's useful. We can (assuming there are statistics) easily find out what the front page *is* used for. But that doesn't necessarily mean that that's what it *should* be used for. In my mind, the front page is for nothing more than enticing people to use Haskell for long enough to look at a second page where all the useful stuff is if you are a haskell programmer. It should include no more than a description of what haskell is, why it's cool, a link to the documentation, a link to a Haskell Platform Dowload and a link to the earlier mentioned second page. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Laziness enhances composability: an example
On 9 Jul 2009, at 14:55, Cristiano Paris wrote: Hi, I'm wondering what a good example of why laziness enhances composability would be. I'm specifically looking for something that can't implemented in Python with iterators (at least not elegantly), but can actually be implemented in Haskell. Pretty much anything that uses tying the knot is very difficult to implement in a non-lazy language without a lot of indirection. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alternative IO
To be honest -- that seems rather nice. Can has in Hackage?
Bob
On 9 Jul 2009, at 15:27, Cristiano Paris wrote:
As a joke, I wrote an instance of Alternative for IO actions:
{-# LANGUAGE ScopedTypeVariables #-}
module Main where
import Control.Applicative
import Control.Exception
instance Alternative IO where
empty = undefined
x | y = handle (\ (_ :: SomeException) - y) x
This would allow to write IO code which failsafes to a value if the
previous computation failed, i.e.:
*Main Control.Applicative undefined | print Hello
Hello
*Main Control.Applicative print Hello | undefined
Hello
It seems a neat way to catch exception in some scenarios. What do
you think? Why is not Alternative IO defined in Control.Applicative?
Thanks,
Cristiano
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Monoid wants a (++) equivalent
On 1 Jul 2009, at 16:46, Edward Kmett wrote: I'm rather fond of the () suggestion, but would be happy with anything better than mappend! ;) I find it rather ugly, it has a lot of connotations of does not equals from other languages. Personally I'm in favor of +, simply because it looks most like a circle with a plus in it. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Monoid wants a (++) equivalent
On 30 Jun 2009, at 22:19, Daniel Fischer wrote: Am Dienstag 30 Juni 2009 20:56:10 schrieb David Leimbach: On Tue, Jun 30, 2009 at 11:54 AM, Brent Yorgey byor...@seas.upenn.edu wrote: On Tue, Jun 30, 2009 at 09:45:45AM -0700, Bryan O'Sullivan wrote: I've thought for a while that it would be very nice indeed if the Monoid class had a more concise operator for infix appending than a `mappend` b. I wonder if other people are of a similar opinion, and if so, whether this is worth submitting a libraries@ proposal over. +1. IIRC Jules Bean has proposed using (+) for this purpose, which I like. It has the advantages of (a) not clashing with any other (common) operators, (b) making more obvious the fact that mappend is not necessarily commutative, and (c) providing the obvious (+) for 'flip mappend' which is sometimes useful. I actually think this proposal is pretty excellent. I actually think your assessment of the proposal is correct. I excellently think your proposal is a correct assessment. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Which one is right?
This looks like Hugs defaulting to a different type to ghci, specifically, Hugs is defaulting to one of the high precission types like CReal or Rational, while ghci is defaulting to Float or Double. Bob On 24 Jun 2009, at 21:03, Linker wrote: Hi,All, Construct a list: [0,0.1..1] || || || || || || ||__ Hugs 98: Based on the Haskell 98 standard ||___|| ||__|| ||__|| __|| Copyright (c) 1994-2005 ||---|| ___|| World Wide Web: http://haskell.org/ hugs || || Bugs: http://hackage.haskell.org/trac/hugs || || Version: September 2006 _ Haskell 98 mode: Restart with command line option -98 to enable extensions Type :? for help Hugs [0,0.1..1] [0.0,0.1,0.2,0.3,0.4,0.5,0.6,0.7,0.8,0.9,1.0] Hugs GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude [0,0.1..1] [0.0,0.1,0.2,0.30004,0.4,0.5,0.6,0.7,0.7999,0.8999,0. ] Prelude Thanks. -- Regards, Linker Lin linker.m@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
No, I think it's extremely useful. It highlights that numbers can both be lazy and strict, and that the so called useless lazy sum, is in fact, useful. Bob On 18 Jun 2009, at 13:29, Keith Sheppard wrote: OK, I think I went off on a tangent that isn't very useful anyway thanks -Keith On Wed, Jun 17, 2009 at 6:32 PM, Lennart Augustssonlenn...@augustsson.net wrote: The creators of Haskell didn't pick any particular representation for numbers. (Well, literals are kind of In..tegers.) You can pick what types you make instances of Num. Some of them are lazy, some of them are strict. On Wed, Jun 17, 2009 at 11:05 PM, Keith Sheppardkeiths...@gmail.com wrote: In lambda calculus numbers are just functions and you evaluate them just like any other function. Haskell could have chosen the same representation for numbers and all evaluation on numbers would be lazy (assuming normal order evaluation). I think that would have been the Purist Lazy way to go. That is not the way the creators of Haskell designed language though... am i missing something? On Wed, Jun 17, 2009 at 4:05 PM, Lennart Augustssonlenn...@augustsson.net wrote: What do you mean by literals are strict? Strictness is a semantic property of functions, and while literals can be overloaded to be functions I don't know what you mean. On Wed, Jun 17, 2009 at 9:50 PM, Keith Sheppardkeiths...@gmail.com wrote: Haskell's numeric literals are strict. You wouldn't want that to change right? It seems to me that having sum and product be strict is consistent with this. -Keith On Wed, Jun 17, 2009 at 11:15 AM, Thomas Davietom.da...@gmail.com wrote: On 17 Jun 2009, at 13:32, Yitzchak Gale wrote: Henk-Jan van Tuyl wrote: reverse maximum minimum Oh yes, please fix those also! import Prelude.Strict? Honestly, these functions are ones that I've *deffinately* used lazy versions of, in fact, in the cases of minimum/maximum I've even used ones that are super-lazy and parallel using unamb. It would be extremely odd to randomly decide most people would want this to be strict based on no knowledge of what they're actually doing. Instead, why don't we stand by the fact that haskell is a lazy language, and that the functions we get by default are lazy, and then write a strict prelude as I suggest above to complement the lazy version. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- keithsheppard.name ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- keithsheppard.name ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- keithsheppard.name ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
On 17 Jun 2009, at 13:32, Yitzchak Gale wrote: Henk-Jan van Tuyl wrote: reverse maximum minimum Oh yes, please fix those also! import Prelude.Strict? Honestly, these functions are ones that I've *deffinately* used lazy versions of, in fact, in the cases of minimum/maximum I've even used ones that are super-lazy and parallel using unamb. It would be extremely odd to randomly decide most people would want this to be strict based on no knowledge of what they're actually doing. Instead, why don't we stand by the fact that haskell is a lazy language, and that the functions we get by default are lazy, and then write a strict prelude as I suggest above to complement the lazy version. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
On 16 Jun 2009, at 05:18, Don Stewart wrote: keithshep: The answer is sometimes (only if you use an optimize flag): You're turning on the strictness analyser. That's enabled with -O or -O2. But sum should be using a tail recursive foldl'. It's a bug in the H98 report, IMO. Not at all, as discussed, there are legitimate uses for a lazy sum, and haskell is a lazy language by default. The only change here needs to be either claus' suggestion of generalizing functions over their application operator, or providing a strict sum'. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need some help with an infinite list
letterCombos = map (:[]) ['a'..'z'] ++ concatMap (\c - map ((c++) . (: [])) ['a'..'z']) letterCombos Not hugely efficient, if you generate the strings in reverse then you can use (c:) rather than ((c++) . (:[])), but that may not be useful to you. Bob On 17 Jun 2009, at 02:28, Günther Schmidt wrote: Hi guys, I'd like to generate an infinite list, like [a, b, c .. z, aa, ab, ac .. az, ba, bb, bc .. bz, ca ...] When I had set out to do this I thought, oh yeah no prob, in a heartbeat. Uhm. Help, pls! Günther PS: I know this should be a no-brainer, sry ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
On 14 Jun 2009, at 12:47, Roman Cheplyaka wrote: * Deniz Dogan deniz.a.m.do...@gmail.com [2009-06-13 16:17:57+0200] I remember needing a non-strict sum at least once, but I do not remember the exact application. We may agree that lazy sum is sometimes (rarely) needed, but then it can be always written as fold. However, in most cases user wants strict sum. So it's not really an excuse. How's this for an excuse - Haskell is a lazy language. It also happens to have support for strictifying things when necessary. The Haskell API is designed to be lazy, like the rest of the language, similarly though, where commonly used, strict versions are provided, like for example foldl'. A much better idea than making sum strict, would simply be to add a sum'. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Logo fun
On 12 Jun 2009, at 10:27, Loup Vaillant wrote: 2009/6/11 Thomas Davie tom.da...@gmail.com: Here's the logo, continuing on the batteries included theme: http://www.cs.kent.ac.uk/people/rpg/tatd2/HaskellBatteries.png I'd sugest a thinner and smaller lambda, or bigger (maybe longer) batteries. The + tip of the batteries should also be colored in gold. Hmm, I'm not sure I agree -- I think the main strength of the original logo is that it's simple, both in terms of all lines being the same width, and in terms of having only two colours used. It means it can be adapted to all sorts of different colour sets (as it is on Haskell.org). Perhaps the correct thing to do here is to make a black/gold version for the haskell platform? I do agree with the earlier comment that the font for the +/- needs to be more bold, if I'd had a vector version, I would have done that. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Logo fun
On 12 Jun 2009, at 11:15, Deniz Dogan wrote: 2009/6/12 Deniz Dogan deniz.a.m.do...@gmail.com: 2009/6/12 Tom Lokhorst t...@lokhorst.eu: There's a SVG version of the logo on the wiki: http://haskell.org/haskellwiki/Thompson-Wheeler_logo I think the biggest problem making the batteries not look like batteries is that they don't look round. For that we need some careful gradenting of them, to make the bottoms of them look shadowed. -- Deniz Dogan Attached is a new version of the same idea with a slight gradient on the batteries and a slightly thicker font for the signs. With various people's ideas taken into account, I've created a new version of my attempt: http://www.cs.kent.ac.uk/people/rpg/tatd2/logo-1.png http://www.cs.kent.ac.uk/people/rpg/tatd2/logo-1.svg I think the yellow/black is easily enough to highlight it as a battery, and saves adding gradients etc, that can become awkward if the logo is ever used in printing. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Logo fun
We had a lot of fun deciding Haskell's new logo, and while I don't agree with the final result, it would be nice if we could now start consistently using it. With that in mind, I realised that the Haskell Platform's logo is totally different, and did a quick mock up of a version reflecting the current Haskell logo. It needs someone with the original vector graphics to have a play and improve it a little bit, but hopefully you'll se a concept you like. Here's the logo, continuing on the batteries included theme: http://www.cs.kent.ac.uk/people/rpg/tatd2/HaskellBatteries.png I'd appreciate comments, suggestions, and possibly either access to the vector version of our current logo, or someone producing a nice version of this. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Function Returning Type?
Op 21 May 2009, om 21:52 heeft Stefan Holdermans het volgende geschreven: Jochem, rationals n = (putStr . unlines . map show) (take n (nub [x % y | y - [1..], x - [1..y], x y])) rationals n :: Integer - [Ratio] I meant Integer - String obviously. Er... what about rationals :: Int - IO () Of note here though, the original type Integer - String is more desirable – the Int/Integer part doesn't matter so much, what matters is the IO type – we can no longer pass the value that rationals generates into another function, because it printed it and dumped it. Lets fix the function instead: rationals :: Int - [Rational] rationals n = take n $ nub [x % y | y - [1..], x - 1..], x y] showLines :: Show a = [a] - String showLines = unlines . map show rationalsS :: Int - String rationalsS = showLines . rationals Now we can chose to use the actual rationals we got out of the function, we can chose to use the string we get back, we can reuse our function for showing multiple showable values, and we can print any of these if we chose :). Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] applicative challenge
On 4 May 2009, at 23:15, Thomas Hartman wrote:
{-# LANGUAGE NoMonomorphismRestriction #-}
import Data.List
import Control.Monad
import Control.Applicative
-- Can the function below be tweaked to quit on blank input,
provisioned in the applicative style?
-- which function(s) needs to be rewritten to make it so?
-- Can you tell/guess which function(s) is the problem just by looking
at the code below?
-- If so, can you explain what the strategy for doing so is?
notQuiteRight = takeWhile (not . blank) $ ( sequence . repeat $
echo )
echo = do
l - getLine
putStrLn l
return l
-- this seems to work... is there a way to make it work Applicatively,
with lifted takeWhile?
seemsToWork = sequenceWhile_ (not . blank) (repeat echo)
sequenceWhile_ p [] = return ()
sequenceWhile_ p (mx:mxs) = do
x - mx
if p x
then do sequenceWhile_ p mxs
else return ()
Conor's already give you a comprehensive explanation of why
Applicative can't be used to do this, but that doesn't mean you can't
use applicative style!
How about...
echo = unlines . takeWhile (not . blank) . lines
seemsToWork = interact echo
Bob
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to understand the fmap here ?
On 5 May 2009, at 11:27, z_axis wrote: The following code snippets is from xmonad: -- Given a window, find the screen it is located on, and compute -- the geometry of that window wrt. that screen. floatLocation :: Window - X (ScreenId, W.RationalRect) --... rr - snd `fmap` floatLocation w Prelude :i fmap class Functor f where fmap :: (a - b) - f a - f b It seems it is different from the definition of fmap ? sincerely! As the type signature of fmap explains, it transforms a function. Specifically, it starts with a function (a - b), and it transforms it to accept an 'a' inside a functor instead of just an a, and return a 'b' inside the same functor instead of just a b. In other words, fmap applies functions inside containers. We can see from floatLocation that it returns a pair inside a container - specifically, an X container. Fmap takes snd, and transforms it to work on values inside the X. So, snd has type (a,b) - b, thus fmap snd has type f (a,b) - f b. In this case, the type it's being applied to is X (ScreenId, W.RationalRect), so f unifies with X, a with ScreenID and b with W.RationalRect. Making snd `fmap` floatLocation w hav the type X W.RationalRect. Finally, the bind into rr there takes it out of the X monad all together, getting you a W.RationalRect. You may want to read this article which explains some of Haskell's abstraciton mechanisms: http://noordering.wordpress.com/2009/03/31/how-you-shouldnt-use-monad/ Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] applicative challenge
I also tried t15 = let grabby = unlines . takeWhile (not . blank) . lines top = (first time: ++) . grabby . (second time: ++) . grabby in interact top but that didn't work either: thart...@ubuntu:~/haskell-learning/lazy-n-strictrunghc sequencing.hs a first time: second time: a b b If someone can explain the subtleties of using interact when you run out of stdio here, it would be nice to incorporate this into Essentially, what's happening here is that interact consumes *all* of standard input, and runs your function on it. This means that as you've realised here, your function must do *all* of the processing of input in one go – but this is good! This means our IO is restricted to one tiny little corner of the program, and we get to write pure Haskell everywhere else :) What's going on with your top function on the other hand is that (.) is not `after` in the sense you're thinking. If you want one grabby to consume some of the input, but not all of it you'd need to return a pair containing the output, and the unconsumed input. where it talks about how using interact is the easy way to approach these types of problems. Not *that* easy though, as this scenario suggests. The key here is that it's more composable than using IO – IO can change all kinds of wierd state, and result in two functions doing totally different things depending on when they're called. This means you can't reliably stick bits of IO code together. With pure functional code though, referential transparency guarentees that you can. Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] ANNOUNCE: Haskell File Manager
On 26 Apr 2009, at 18:24, Michael Dever wrote: Hi, The first release of Haskell File Manager has been uploaded to http://code.haskell.org/haskellfm This is a program for viewing/managing the files on your computer. It has all the common functionality you would expect from your current file manager, copying, moving, deleting, renaming, opening and searching. It is a beta release, so you know what to expect there, and any bugs found can be filed at http://trac.haskell.org/haskellfm . TreeFunctions.hs:24:7: Could not find module `DirectoryTree': Use -v to see a list of the files searched for. Bob ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
On 25 Apr 2009, at 10:51, Daniel Fischer wrote: Am Samstag 25 April 2009 08:48:16 schrieb Thomas Davie: On 24 Apr 2009, at 14:37, Loup Vaillant wrote: 2009/4/23 Miguel Mitrofanov miguelim...@yandex.ru: On 23 Apr 2009, at 12:17, Thomas Davie wrote: Haskell is a very horizontal language, and to limit our horizontal space seems pretty weird. +1. I sometimes use lines up to 200 characters long, when I feel they would be more readable. 200 sounds awfully long. Do you have any example? Sure... arrow :: forall (~) b c d e. ( Arrow (~), Show (d ~ e), Show (c ~ d), Show (b ~ c), Show b, Show c, Show d, Show e, Arbitrary (d ~ e), Arbitrary (c ~ d), Arbitrary (b ~ c), Arbitrary b, Arbitrary c, Arbitrary d, Arbitrary e, EqProp (b ~ e), EqProp (b ~ d), EqProp ((b,d) ~ c), EqProp ((b,d) ~ (c,d)), EqProp ((b,e) ~ (d,e)), EqProp ((b,d) ~ (c,e)), EqProp b, EqProp c, EqProp d, EqProp e) = b ~ (c,d,e) - TestBatch . In all seriousness though, that one got broken, but I do find that I occasionally have lines around 100 characters that just look silly if I break them, this is a good example: filterNonRoots (GCase e bs) = filter ((/= e) ^()^ (not . (`elem` bs))) Not that I'd deny that it can sometimes be more readable to have longer lines*, but in this example, would filterNonRoots (GCase e bs) = filter ((/= e) ^()^ (not . (`elem` bs))) be any less readable in your opinion? Yes – this particular line is mixed in with several other pattern matches, each of which has a similar form, laying it out on one line lets you see the similarities and differences, laying it out on two lines creates visual noise. Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
On 25 Apr 2009, at 21:09, Jason Dusek wrote: There will always be some people who prefer longer lines. The real issue is, how do we deal with the fundamental disagreement here? It's not like we can have both. Also those people who like long lines -- will they all agree to a long line length? Is there a fundamental disagreement here? There are those who are driven by an archaic standard from the width of the terminal screen, and there are those who are driven by the aesthetics of their code. As always, opinions on aesthetics differ slightly, but overall, everyone seems to mostly agree that we should try to keep lines short where possible, but lengthen then when needed. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Cabal's default install location
[Moved from the UHC thread – lets stop treading on those guys toes, they did something very very shiny] On 23 Apr 2009, at 07:02, Richard O'Keefe wrote: It's irrelevant, because I _do_ have root access to my machine, How nice to be you. Since the argument is entirely about people who _don't_, your point it? His point is that that kind of person is not the only kind of person, so to base an argument on what they want is as weak as basing an argument on what he wants. It is clear that the only sensible default is no default. That sounds pretty sensible to me too – much like darcs asks what your email address is the first time you work on a repository, cabal should probably ask the first time you run it do you prefer global or user installs? I think the right question is how many people prefer user installs over system installs, wrt. their hackage packages?. No, because the costs are asymmetric. I think this is a case of not seeing the costs to the other users because you're firmly entrenched in your camp. I would have said originally that the costs are asymmetric too – but that it's a much greater cost for the people who expect all installers to do global installs. So I think that the question asked there is a very valid one. However, I do like the solution of not giving any default. Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Cabal's default install location
The results in the poll seem to have stabilised now, so I'll tell you what happened... For user installs: 103 For global installs: 52 Others: 9 Interesting Ideas: • Claus made the suggestion that there be no default, instead that cabal asks you which you prefer the first time you run, or directs you to the configuration file. • Many users made the suggestion that cabal should install globally when running as root, and for a user when running as a user, possibly also displaying a prominent message about what's going on. Conclusions: -- Most people do indeed want user installs, but a very much not insignificant population want global installs. Perhaps one of these other suggestions is the way forward? Bob p.s. I personally very much like Claus' idea.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
On 23 Apr 2009, at 10:02, Matthijs Kooijman wrote: Some material I've read on typography -- can't find the reference now -- suggests ~65 is the best number of characters per line. The advice was, if your page is larger than that, you should make columns. That fits my observations. In particular, I noticed that your emails were particularly comfortable to read, which might also be partly be caused by the extra indent at the start of your lines, which also seems comfortable. Not sure how applicabable all this is to code, though :-) I think the non-applicable to code observation is very likely true – we'd like to be able to write nice descriptive variable names. In doing this, we probably want them to be more than the 1 or 2 characters that Haskellers traditionally use, maybe of the order of 5-10. Given this, it would seem a shame to only be able to fit 6-13 litterals on a line, that sounds like we'll quickly be having to wrap lines with deffinititions of any significance on them. My personal preference with Haskell is to ignore the 78 character limit, but only when layout otherwise becomes horrible otherwise. Haskell is a very horizontal language, and to limit our horizontal space seems pretty weird. Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Being impure within a 'pure' function
On 22 Apr 2009, at 10:38, Daniel K. wrote: Hello, imagine the following situation: You want to implement e.g. Dijkstra's algorithm to find a shortest path between nodes u and v in a graph. This algorithm relies heavily on mutating arrays, so the type signature would look something like getDistance :: Graph - Node - Node - IO Int Not mutating the underlying arrays would probably result in poor performance. BUT: For a constant graph, the distance between two nodes stays the same all the time, so in fact getDistance should be a pure function! So here is my question: Is there a way to write functions in Haskell that do some IO internally, but that are guaranteed to be side- effect free? Of course one would have to make sure that the array that is mutated inside getDistance must not be accessible from outside the function. Is that possible? If not, wouldn't that be desirable? If not, why not? Either, as Eugene suggested, use the ST monad, as is possible in this case (and much better than the solution I'm proposing), or if you *really* can't get out of using IO, use unsafePerformIO. You will though have to provide several guarantees yourself that the type system would normally provide for you (hence the unsafe part - it should really be verifyItsSafeYourselfPerformIO). Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Cabal's default install location
There seems to be an assumption amongst the community that a user's home directory is the most useful place for cabal to install to by default. A few people have challenged that. I wanted to find out which one most people do actually prefer, so please go and vote on this poll. http://noordering.wordpress.com/2009/04/21/cabals-default-install-location/ It's no more than a straw poll, I don't know how protected it is against ballot stuffing, but I'm pretty confident that Haskellers are trustworthy enough not to play with it that way. I'll tell you all the result next week. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimizing unamb by determining the state of a thunk?
On 20 Apr 2009, at 09:41, Peter Verswyvelen wrote: I was wandering if it would be possible to optimize unamb by checking if a value is already evaluated to head normal form. So f `unamb` g would then be extremely fast if either f or g is already evaluated to head normal form. Maybe using some vacuum tricks? This function would need to be in IO since it is of course not referentially transparent. Really? Is it any less referentially transparent than unamb already is - i.e. it's referentially transparent, as long as the two values really are equal. Although threads are lightweight in Haskell, forking/waiting/killing surely must have more overhead than just checking the thunk of an expression? Of course one could also make unamb a primitive :-) That would be a lovely solution for me. Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimizing unamb by determining the state of a thunk?
On 20 Apr 2009, at 10:57, Peter Verswyvelen wrote: On Mon, Apr 20, 2009 at 10:23 AM, Thomas Davie tom.da...@gmail.com wrote: Really? Is it any less referentially transparent than unamb already is - i.e. it's referentially transparent, as long as the two values really are equal. I think it is. Suppose we call the function hnf :: a - Bool. hnf might return a different result for the same argument, since the evaluation of the argument might be happening on a different thread, so the result of hnf depends on the time when it is evaluated. Or am I missing something here? Sure, so hnf would give us a non-determined result, but I don't think that makes unamb any less referentially transparent – the same value is always returned, and always reduced at least to hnf. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Utrecht Haskell Compiler (UHC) -- first release
On 19 Apr 2009, at 09:52, Duncan Coutts wrote: On Sun, 2009-04-19 at 00:41 +0200, Thomas Davie wrote: Apparently a user install of uuagc and fgl isn't good enough. Fun to know. I've found user installs don't work at all on OS X, various people in #haskell were rather surprised to discover this, so apparently it's not the default behavior on other platforms. Currently, user installs are the default on all platforms except Windows. It really rather makes cabal install rather odd – because it doesn't actually install anything you can use without providing extra options! It should work fine, you'll need to give more details. This has been the result, at least every time I've installed ghc: $ cabal install xyz $ runhaskell Setup.hs configure -- where abc depends on xyz Configuring abc-0.0... Setup.lhs: At least the following dependencies are missing: xyz -any $ sudo cabal install --global xyz $ runhaskell Setup.hs configure Configuring abc-0.0... $ runhaskell Setup.hs build ... Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Utrecht Haskell Compiler (UHC) -- first release
On 19 Apr 2009, at 11:10, Duncan Coutts wrote: On Sun, 2009-04-19 at 10:02 +0200, Thomas Davie wrote: It really rather makes cabal install rather odd – because it doesn't actually install anything you can use without providing extra options! It should work fine, you'll need to give more details. This has been the result, at least every time I've installed ghc: $ cabal install xyz So this does a per-user install. $ runhaskell Setup.hs configure -- where abc depends on xyz This does a global install. Global packages cannot depend on user packages. You have two choices: $ cabal configure because the cabal program does --user installs by default or use $ runhaskell Setup.hs configure --user which explicitly does a --user install. The reason for this confusion is because the original runghc Setup interface started with global installs and we can't easily change that default. On the other hand, per-user installs are much more convenient so that's the sensible default for the 'cabal' command line program. I don't understand what makes user installs more convenient. Certainly, my preference would be for global all the time – I expect something that says it's going to install something to install it onto my computer, like any other installation program does. What is it that makes user installs more convenient in this situation? Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Utrecht Haskell Compiler (UHC) -- first release
I don't understand what makes user installs more convenient. Certainly, my preference would be for global all the time – I expect something that says it's going to install something to install it onto my computer, like any other installation program does. What is it that makes user installs more convenient in this situation? You don't need 'sudo' access for user installs. This means that 'cabal install' works out of the box on every system, without needing admin/root privs (esp. important for students). But students will be used to needing to configure this – in every other installation system out there they need to tell it to install in their user directory. Personally – I find it more convenient to have the install program do what it says it does! Install it! This would save confusion about old tools that do things globally, and not confuse students, because they're all already used to giving extra flags to make install not install things system wide. Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Utrecht Haskell Compiler (UHC) -- first release
On 18 Apr 2009, at 22:44, Antoine Latter wrote: On Sat, Apr 18, 2009 at 9:03 AM, a...@cs.uu.nl wrote: Utrecht Haskell Compiler -- first release, version 1.0.0 The UHC team is happy to announce the first public release of the Utrecht Haskell Compiler (UHC). UHC supports almost all Haskell98 features plus many experimental extensions. The compiler runs on MacOSX, Windows (cygwin), and various Unix flavors. Features: * Multiple backends, including a bytecode interpreter backend and a GRIN based, full program analysing backend, both via C. * Experimental language extensions, some of which have not been implemented before. * Implementation via attribute grammars and other high-level tools. * Ease of experimentation with language variants, thanks to an aspect-oriented internal organisation. Getting started Download -- UHC is available for download as source distribution via the UHC home page: http://www.cs.uu.nl/wiki/UHC Here you will also find instructions to get started. Status of the implementation Like any university project UHC is very much work in progress. We feel that it is mature and stable enough to offer to the public, but much work still needs to be done; hence we welcome contributions by others. UHC grew out of our Haskell compiler project (called Essential Haskell Compiler, or EHC) over the past 5 years. UHC internally is organised as a combination of separate aspects, which makes UHC very suitable to experiment with; it is relatively easy to build compilers for sublanguages, or to generate related tools such as documentation generators, all from the same code base. Extensions to the language can be described separately, and be switched on or of as need arises. Warning --- Although we think that the compiler is stable enough to compile subtantial Haskell programs, we do not recommend yet to use it for any serious development work in Haskell. We ourselves use the GHC as a development platform! We think however that it provides a great platform for experimenting with language implementations, language extensions, etc. Mailing lists - For UHC users and developers respectively: http://mail.cs.uu.nl/mailman/listinfo/uhc-users http://mail.cs.uu.nl/mailman/listinfo/uhc-developers Bug reporting - Please report bugs at: http://code.google.com/p/uhc/issues/list The UHC Team -- Atze Dijkstra, Department of Information and Computing Sciences. /|\ Utrecht University, PO Box 80089, 3508 TB Utrecht, Netherlands. / | \ Tel.: +31-30-2534118/1454 | WWW : http://www.cs.uu.nl/ ~atze . /--| \ Fax : +31-30-2513971 | Email: a...@cs.uu.nl / | ___\ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe After running ./configure on my Intel Mac (running OS 10.5.6 with GHC 6.10), I try to run make uhc and get the following: $ make uhc src/ruler2/files.mk:34: build/ruler2/files-ag-d-dep.mk: No such file or directory src/ruler2/files.mk:35: build/ruler2/files-ag-s-dep.mk: No such file or directory mkdir -p build/shuffle ; \ --module=CDoc -dr -Psrc/shuffle/ -o build/shuffle/CDoc.hs src/ shuffle/CDoc.ag /bin/sh: --module=CDoc: command not found make: Failed to remake makefile `build/ruler2/files-ag-s-dep.mk'. make: Failed to remake makefile `build/ruler2/files-ag-d-dep.mk'. make EHC_VARIANT=`echo install/101/bin/ehc | sed -n -e 's+install/\([0-9_]*\)/bin/ehc.*+\1+p'` ehc-variant src/ruler2/files.mk:34: build/ruler2/files-ag-d-dep.mk: No such file or directory src/ruler2/files.mk:35: build/ruler2/files-ag-s-dep.mk: No such file or directory mkdir -p build/shuffle ; \ --module=CDoc -dr -Psrc/shuffle/ -o build/shuffle/CDoc.hs src/ shuffle/CDoc.ag /bin/sh: --module=CDoc: command not found make[1]: Failed to remake makefile `build/ruler2/files-ag-s-dep.mk'. make[1]: Failed to remake makefile `build/ruler2/files-ag-d-dep.mk'. make EHC_VARIANT_RULER_SEL=((101=HS)).(expr.base patexpr.base tyexpr.base decl.base).(e.int e.char e.var e.con e.str p.str) \ ehc-variant-dflt src/ruler2/files.mk:34: build/ruler2/files-ag-d-dep.mk: No such file or directory src/ruler2/files.mk:35: build/ruler2/files-ag-s-dep.mk: No such file or directory mkdir -p build/shuffle ; \ --module=CDoc -dr -Psrc/shuffle/ -o build/shuffle/CDoc.hs src/ shuffle/CDoc.ag /bin/sh: --module=CDoc: command not found make[2]: Failed to remake makefile `build/ruler2/files-ag-s-dep.mk'. make[2]: Failed to remake makefile `build/ruler2/files-ag-d-dep.mk'. make[1]: *** [ehc-variant] Error 2 make: *** [install/101/bin/ehc] Error 2 This is fairly bewildering. Am I the only one seeing errors like this? This looks like the same error I got – see bug report 1 in the bug
Re: [Haskell-cafe] ANNOUNCE: Utrecht Haskell Compiler (UHC) -- first release
On 19 Apr 2009, at 00:31, Antoine Latter wrote: On Sat, Apr 18, 2009 at 4:38 PM, Thomas Davie tom.da...@gmail.com wrote: This looks like the same error I got – see bug report 1 in the bug database – the configure script reports that you have uuagc even if you don't – cabal install it, reconfigure, and you should be on your way. Second thing to watch for – it depends on fgl, but this isn't caught by the configure script. Apparently a user install of uuagc and fgl isn't good enough. Fun to know. I've found user installs don't work at all on OS X, various people in #haskell were rather surprised to discover this, so apparently it's not the default behavior on other platforms. It really rather makes cabal install rather odd – because it doesn't actually install anything you can use without providing extra options! Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] replicateM should be called mreplicate?
On 7 Apr 2009, at 07:37, David Menendez wrote: On Mon, Apr 6, 2009 at 1:46 PM, Luke Palmer lrpal...@gmail.com wrote: On Mon, Apr 6, 2009 at 11:42 AM, David Menendez d...@zednenem.com wrote: Of course, this suggests that mfix should be fixM, so perhaps a better distinction is that mplus and mfix need to be defined per-monad, whereas filterM and replicateM are generic. Don't you think that is an incidental distinction, not an essential one? It would be like naming our favorite operations mbind and joinM, just because of the way we happened to write the monad class. Fair enough. I only added that comment when I noticed that my explanation for picking replicateM over mreplicate also applied to mfix. Looking through Control.Monad, I see that all the *M functions require Monad, whereas the m* functions require MonadPlus (or MonadFix). Actually, most of the *M functions only require Applicative – they're just written in a time when that wasn't in the libraries. I wonder to what extent that pattern holds in other libraries? I'm not sure how to generalise this pattern, but it's probably worth noting that fmap is fmap, not mapF. I can't see any pattern that it fits into, really I suspect it's a case of what shall we name this and not enough thought about consistant naming as the libraries evolved. Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: Marketing Haskell
On 3 Apr 2009, at 09:25, Benjamin L.Russell wrote: On Fri, 3 Apr 2009 09:09:26 +0200, Jean-Philippe Bernardy jeanphilippe.berna...@gmail.com wrote: On Fri, Apr 3, 2009 at 7:12 AM, Marc A. Ziegert co...@gmx.de wrote: how about an octopus? I could not resist the opportunity to combine two great ideas and give you the haskell octopus logo in attachment. It's a bit rough, but with a bit more polish, what do you think? Nice try, but an octupus has eight arms, not seven. What about the remaining arm? Or is that a logo of two octopi, one with four arms, and the other with three? Oh no, the poor octopi! If it's an octopi, surely it should have 3.1415926... arms? Where's the 0.1415926...? Bob ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Parsing Haskell?
On 1 Apr 2009, at 16:31, Daniel Lincke wrote: Hi Haskellers, I am looking for a parser which can parse Haskell code and build an syntax tree out of it. The syntax tree should be storable in some reasonable file format in order to use it as an input for applications like programm transformation systems. Just a note – the storable syntax tree you're looking for is called a .hs file. You just want a nice interface to your Haskell parser so that said syntax transformers can work easily. You might want to look at how HaRe does it. I believe using Programatica at the moment, because it's the only one that preserves comments and code layout. Bob ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] Re: Darcs - dependencies between repositories (aka forests)
On 29 Mar 2009, at 22:26, Xiao-Yong Jin wrote: Peter Verswyvelen bugf...@gmail.com writes: Mmm, my email was indeed very unclear about my question. A very simple example: suppose a development team is working on a program. This program consist of modules A and B. Each module has it's own Darcs repository. Module A requires B. When a new developer wants to get the source code, he does a darcs get server://program/A, which gives him only the latest version of A. So he manually needs to do darcs get server://program/ B (that B is required is usually discovered after a compilation error, talking to other developers to find out what the dependencies are, or by reading the cabal file). Furthermore it is unclear which version of A required which version of B (so you can't really roll back to old versions). Now assume you don't have 2 modules but dozens... I can't imagine such kind of situation, unless you are really working on a very big project. Really? To me it's almost the way darcs is *meant* to work. Both darcs and cabal work well when you work with micropackages, not one monolithic thing. What Peter is suggesting would make darcs hugely better for dealing with lots of micropackages at the same time that all go together to form a project. If those aforementioned dependency projects are just some modules within your big projects, I think the way to go is actually make them in the same repository. Really? Why should we make a monolithic blob out of what are really completely separate things that can be reused in completely separate places? I can't see the benefit of splitting those small modules to different repositories, apart from not letting other people know your current developing code. As above – they're different packages, that do something different, and can be used in many different places. It's pure coincidence that those packages were first needed for this particular project. So my point of view is that it is a management issue rather than a issue of revision control system. The developers should actually agree upon a proper set of API's before you guys actually start building the modules separately. I don't agree. If it were stable APIs developed by someone else, then yes, it would make sense, but with packages that are built side-by- side with the rest of the project, but are logically distinct, it makes very little sense. Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: One more 'do' pattern
On 28 Mar 2009, at 09:54, Bulat Ziganshin wrote: Hello haskell-prime, as we know, the following code action x y = \v - do can be shortened to following v - action x y but there is one more very popular 'do' pattern, with a 'do' block passed as a parameter: for list $ \element - do ... or bracket createDialog destroyDialog $ \dialog - do ... what about adding one more 'do' sugar that will allow to move variable name to the left, such as for element in list do or with dialog in bracket createDialog destroyDialog do or just element -- for list do dialog -- bracket createDialog destroyDialog do ? In all honesty, I find the idea of adding yet more imperative looking stuff to do notation an appalling idea. We already get problems because people read do notation and think it means execute this in sequence (see threads about lazy IO not doing what's expected for example). As an aside, while these are merely syntactic sugars, I find the idea of attacking the problem with syntax to be somewhat silly as well. This simply adds a special syntax for another couple of cases that crop up occasionally. What do we do when we have another, and another, and another, do we keep just adding more and more syntax? Bob ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Re[2]: One more 'do' pattern
On 28 Mar 2009, at 10:13, Bulat Ziganshin wrote: Hello Thomas, Saturday, March 28, 2009, 12:05:02 PM, you wrote: In all honesty, I find the idea of adding yet more imperative looking stuff to do notation an appalling idea. We already get problems because people read do notation and think it means execute this in sequence (see threads about lazy IO not doing what's expected for example). well, people already have problems understanding haskell, not only 'do' statements As an aside, while these are merely syntactic sugars, I find the idea of attacking the problem with syntax to be somewhat silly as well. This simply adds a special syntax for another couple of cases that crop up occasionally. What do we do when we have another, and another, and another, do we keep just adding more and more syntax? i'm just making industrial programming, with lots of imperative code and 'do' syntax (compared to imperative languages) is somewhat limited. so, what i want to have is better syntax. i don't have any idea whether semantics can be somewhat improved to fix those shortages I'm not sure why industrial programming means programming not in a functional style. It certainly doesn't mean that where I work. Bob ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Re[4]: One more 'do' pattern
On 28 Mar 2009, at 10:24, Bulat Ziganshin wrote: Hello Thomas, Saturday, March 28, 2009, 12:15:37 PM, you wrote: I'm not sure why industrial programming means programming not in a functional style. It certainly doesn't mean that where I work. what kind of problems you are solving? Large GUI applications doing lots of 3D rendering. Bob ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: [Haskell-cafe] The votes are in!
*Launches missiles* Bob (that was my logo) On 24 Mar 2009, at 21:46, Ross Mellgren wrote: Doesn't matter how many times you seq the results, the thunk has been forced. -Ross On Mar 24, 2009, at 4:45 PM, FFT wrote: I demand a recount! The one that launches the missile should have won! 2009/3/24 Eelco Lempsink ee...@lempsink.nl: The results of the Haskell logo competition are in! You can view them at http://www.cs.cornell.edu/w8/~andru/cgi-perl/civs/results.pl? num_winners=1id=E_d21b0256a4fd5ed7algorithm=beatpath Congratulations Jeff Wheeler! I'll set up a page with the results visibile. -- Regards, Eelco Lempsink ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
