[Haskell-cafe] Do you want to maintain bindings-DSL?
Hi, bindings-DSL[1] is a stable and reliable macro package for FFI. It just got a new tutorial and its repository is now in git. If no one else wants to maintain it, I'll still be looking at issue reports and fixing possible problems, but I've not been actively using Haskell for some time, and won't add anything new or make plans for future changes. The original idea behind bindings-DSL was to build a wide set of community maintained raw bindings to interesting C libraries, on which Haskell programmers could safely depend when creating their own higher level packages. Although that idea never really took off, bindings-DSL itself got some popularity, probably because it makes instancing Storable easy. If you want to take maintenance, you have some options. You could just kill the bindings-* idea and add some flexibility to new macros, which I always avoided to enforce consistency. Or you could keep the original goal, and maybe add a mailing list and a web page where users could request new libraries and discuss solutions to trick issues. A possible plan for version 2 is to be independent of hsc2hs, and use a new syntax instead of C macros. Thanks. Best, Maurício [1]: http://bitbucket.org/mauricio/bindings-dsl ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Do combinatorial algorithms have a matroid strucutre XOR non-matroid structure?
On Thu, Jul 11, 2013 at 03:39:02PM -0700, KC wrote: I ask this on this mailing list because there are quite a few mathematically oriented people here. If you accept the Law of Excluded Middle, everything either has a matroid structure, or not. On the other hand, if you do not accept it, then there may be some combinatorial algorithms which have neither (because we have not found a matroid structure, or proved one does not exist). Either way, I do not understand the point of your question. -Brent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Do combinatorial algorithms have a matroid strucutre XOR non-matroid structure?
I ask this on this mailing list because there are quite a few mathematically oriented people here. Casey -- -- Regards, KC ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] do vs. pattern matching
I'm a somewhat experienced coder but I am relatively new to Haskell. I've got a question about whether a usage of do notation is idiomatic, or whether it's better to use pattern matching. I've got two functions which take an input and return Maybe SomeType. If either returns Nothing, I also want to return Nothing. If they both return something, then I'll return something unrelated. With do notation, I can write something like this: do foo - callFoo x bar - callBar x return (baz) Alternatively, there's a straightforward pattern match. After binding foo, bar in a couple of where clauses: case (foo,bar) of (Just x, Just y) - baz _- Nothing So which approach is more idiomatic, do you think? Thanks, - Matthew ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do vs. pattern matching
The do notation in this instance yields a nice advantage: if you want to switch to a different monad to encapsulate failure you will meely need to swap out the type signature and your function will need no further work. On Aug 4, 2012 7:35 AM, Matthew wonderzom...@gmail.com wrote: I'm a somewhat experienced coder but I am relatively new to Haskell. I've got a question about whether a usage of do notation is idiomatic, or whether it's better to use pattern matching. I've got two functions which take an input and return Maybe SomeType. If either returns Nothing, I also want to return Nothing. If they both return something, then I'll return something unrelated. With do notation, I can write something like this: do foo - callFoo x bar - callBar x return (baz) Alternatively, there's a straightforward pattern match. After binding foo, bar in a couple of where clauses: case (foo,bar) of (Just x, Just y) - baz _- Nothing So which approach is more idiomatic, do you think? Thanks, - Matthew ___ 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] do vs. pattern matching
Also if you don't need foo and bar you can write: callFoo callBar return baz //Johan On Aug 4, 2012 8:36 AM, Matthew wonderzom...@gmail.com wrote: I'm a somewhat experienced coder but I am relatively new to Haskell. I've got a question about whether a usage of do notation is idiomatic, or whether it's better to use pattern matching. I've got two functions which take an input and return Maybe SomeType. If either returns Nothing, I also want to return Nothing. If they both return something, then I'll return something unrelated. With do notation, I can write something like this: do foo - callFoo x bar - callBar x return (baz) Alternatively, there's a straightforward pattern match. After binding foo, bar in a couple of where clauses: case (foo,bar) of (Just x, Just y) - baz _- Nothing So which approach is more idiomatic, do you think? Thanks, - Matthew ___ 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] do vs. pattern matching
On Fri, Aug 3, 2012 at 11:34 PM, Matthew wonderzom...@gmail.com wrote: I'm a somewhat experienced coder but I am relatively new to Haskell. I've got a question about whether a usage of do notation is idiomatic, or whether it's better to use pattern matching. I've got two functions which take an input and return Maybe SomeType. If either returns Nothing, I also want to return Nothing. If they both return something, then I'll return something unrelated. With do notation, I can write something like this: do foo - callFoo x bar - callBar x return (baz) Alternatively, there's a straightforward pattern match. After binding foo, bar in a couple of where clauses: case (foo,bar) of (Just x, Just y) - baz _- Nothing So which approach is more idiomatic, do you think? The short answer is to write a one liner using (=) and (), unless you need to bind more than one value to a variable. In that case, you should use an applicative interface, if available and otherwise possible, and finally do-notation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do vs. pattern matching
On Sat, Aug 4, 2012 at 7:05 AM, Alexander Solla alex.so...@gmail.com wrote: On Fri, Aug 3, 2012 at 11:34 PM, Matthew wonderzom...@gmail.com wrote: I'm a somewhat experienced coder but I am relatively new to Haskell. I've got a question about whether a usage of do notation is idiomatic, or whether it's better to use pattern matching. I've got two functions which take an input and return Maybe SomeType. If either returns Nothing, I also want to return Nothing. If they both return something, then I'll return something unrelated. With do notation, I can write something like this: do foo - callFoo x bar - callBar x return (baz) Alternatively, there's a straightforward pattern match. After binding foo, bar in a couple of where clauses: case (foo,bar) of (Just x, Just y) - baz _- Nothing So which approach is more idiomatic, do you think? The short answer is to write a one liner using (=) and (), unless you need to bind more than one value to a variable. In that case, you should use an applicative interface, if available and otherwise possible, and finally do-notation. Aha. I'd forgotten all about . Thanks, everyone! I'm going with callFoo callBar return baz. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do vs. pattern matching
On Sat, Aug 4, 2012 at 7:05 AM, Alexander Solla alex.so...@gmail.com wrote: On Fri, Aug 3, 2012 at 11:34 PM, Matthew wonderzom...@gmail.com wrote: ... With do notation, I can write something like this: do foo - callFoo x bar - callBar x return (baz) ... The short answer is to write a one liner using (=) and (), unless you need to bind more than one value to a variable. In that case, you should use an applicative interface, if available and otherwise possible, and finally do-notation. But the longer answer would be, it depends! Right? The `do' notation is clear and easy to follow; it's low maintenance - even if you have nothing to bind right now, if that comes up in the future, it will drop right into that `do' block; it's classic Haskell that doesn't need any explaining to (hardly) anyone. Maybe it's your last choice, maybe it's my first. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Do type classes have a partial order?
Is there a partial order on Haskell type classes?If so, does it induce any quasi-order relation on types named in the instances?In the example below types C and D have the same operation fThanks,Patdata C = C deriving Showdata D = D deriving Showclass A t where f::t-t f t = t instance A C whereinstance A D whereclass A t = B t whereinstance B C whereinstance B D where ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Do type classes have a partial order?
It seems like you would, going by semantics of System F, where types with type variables name a certain subset of types, = constraints further restrict the types of the same shape (are they an independent kind of restriction?), so typeclass declarations with/without = specify a partial order over types because the subset relation is. On Mon, Nov 14, 2011 at 3:47 AM, Patrick Browne patrick.bro...@dit.ie wrote: Is there a partial order on Haskell type classes? If so, does it induce any quasi-order relation on types named in the instances? In the example below types C and D have the same operation f Thanks, Pat data C = C deriving Show data D = D deriving Show class A t where f::t-t f t = t instance A C where instance A D where class A t = B t where instance B C where instance B D where ___ 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] do-re-mi
On 25/08/2011 02:59 AM, Albert Y. C. Lai wrote: do, a block, a monad block rec, a knot tied in the block mu, a name that calls itself (mu is pronounced as me in modern Greek) forM_, a long long list to run SO, a state aborting threads (SO is stack overflow) la, a state to follow SO T's, tranformers of monads that will bring us back to do That's genius! :-D ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] do-re-mi
do, a block, a monad block rec, a knot tied in the block mu, a name that calls itself (mu is pronounced as me in modern Greek) forM_, a long long list to run SO, a state aborting threads (SO is stack overflow) la, a state to follow SO T's, tranformers of monads that will bring us back to do ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do-re-mi
On 25 August 2011 11:59, Albert Y. C. Lai tre...@vex.net wrote: do, a block, a monad block rec, a knot tied in the block mu, a name that calls itself (mu is pronounced as me in modern Greek) forM_, a long long list to run SO, a state aborting threads (SO is stack overflow) la, a state to follow SO T's, tranformers of monads that will bring us back to do _Someone_ appears to have too much spare time on their hands... :p -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Do exist globally available hosting project services?
Dear haskellers, I was reading the terms of service of the Haskell Community Server and found this statement: Users residing in countries on the United States Office of Foreign Assets Control sanction list, including Cuba, Iran, Libya, North Korea, Sudan and Syria, may not post or access CONTENT available through OUR services. I wonder whether there is a solution for hosting projects which does not discriminate people by their place of residence. http://code.haskell.org http://www.patch-tag.com https://github.com all seem to be ruled under USA laws. Would anybody recommend an alternative? Best, Facundo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Do exist globally available hosting project services?
2011/5/7 Facundo Domínguez facundoming...@gmail.com: Dear haskellers, I was reading the terms of service of the Haskell Community Server and found this statement: Users residing in countries on the United States Office of Foreign Assets Control sanction list, including Cuba, Iran, Libya, North Korea, Sudan and Syria, may not post or access CONTENT available through OUR services. I wonder whether there is a solution for hosting projects which does not discriminate people by their place of residence. http://code.haskell.org http://www.patch-tag.com https://github.com all seem to be ruled under USA laws. Would anybody recommend an alternative? See the Countries Blocked column here: http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] $ do?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/15/10 02:36 , Roman Cheplyaka wrote:
Regarding the rationale, I'm not so sure and I'd like to hear an
explanation from someone competent. But I assume it has something
to do with the fact that if you supply a 'do' argument, you cannot
supply any more arguments (because 'do' extends to the right as far as
possible). Not that I'm convinced that it is a valid reason to prohibit
such construct.
Hm? do {...} would work, as would using indentation per usual layout rules
(the next argument would be indented no farther than the do). It'd
certainly be more confusing to read, though.
- --
brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon university KF8NH
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk0SsvUACgkQIn7hlCsL25XM6wCcDvu9G3fc9M5Vv6d2EKZ64X8t
k7YAn0hvoyq0KpmAAEyAD4HIWX8HsMTY
=11UF
-END PGP SIGNATURE-
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Do we need Monad fail (or MonadFail)?
Monads seem to use fail in one of three ways: -Regular monads leave it at the default definition of error -MonadPlus sometimes redefines it to mzero -IO redefines it to failIO Are there any other definitions of fail? If not, does the special case of IO really need a class-level definition, or could there be another way of dealing with failed pattern matches? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Do we need Monad fail (or MonadFail)?
I'd love for the compiler to give an error (or maybe just a warning) in the case that I have a pattern match in a monad that just blows up (throws an exception) on a pattern match failure. Currently there's no way to know the behavior of failed pattern match failures without looking at the instance for the current monad. And what if you're writing monad agnostic (higher-order polymorphism?) code? If there were a MonadFail class, you could explicitly codify that you expect a monad to NOT crash your program in the case of a pattern match. For example: someFunction :: (MonadState m, MonadFail m) = a - m a someFunction arg = do [x,y,z] - action arg return z Of course one of the laws for MonadFail would be that fail never throws an exception. The compiler couldn't exactly enforce it, but we're used to expecting sane instances that obey laws. I think IO would be the exception (no pun intended) to this and be an instance of MonadFail, but just throw an exception on fail. Since you can only catch exceptions in the IO monad, this sounds reasonable to me. --Jonathan On Tue, Dec 21, 2010 at 2:49 AM, John Smith volderm...@hotmail.com wrote: Monads seem to use fail in one of three ways: -Regular monads leave it at the default definition of error -MonadPlus sometimes redefines it to mzero -IO redefines it to failIO Are there any other definitions of fail? If not, does the special case of IO really need a class-level definition, or could there be another way of dealing with failed pattern matches? ___ 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] Do we need Monad fail (or MonadFail)?
On Tue, Dec 21, 2010 at 08:31:08AM -0700, Jonathan Geddes wrote: I'd love for the compiler to give an error (or maybe just a warning) in the case that I have a pattern match in a monad that just blows up (throws an exception) on a pattern match failure. You will be interested to know that everything you ask for already was in Haskell ages ago: http://www.cs.auckland.ac.nz/references/haskell/haskell-report-1.4-html/exps.html#do-expressions They decided to get rid of it in Haskell 98, for reasons that someone else can probably explain. Lauri ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Do we need Monad fail (or MonadFail)?
everything you ask for already was in Haskell ages ago: those were the days ... where the method in Functor method was called map, and zero was a method of, guess what, MonadZero... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Do we need Monad fail (or MonadFail)?
I'd be really interested in learning the rationale behind those changes. I'm sure it wasn't done for capricious or arbitrary reasons, but I can't help but see it as a step back. --Jonathan Geddes (sent from android mobile) On Dec 21, 2010 8:47 AM, Lauri Alanko l...@iki.fi wrote: On Tue, Dec 21, 2010 at 08:31:08AM -0700, Jonathan Geddes wrote: I'd love for the compiler to give... You will be interested to know that everything you ask for already was in Haskell ages ago: http://www.cs.auckland.ac.nz/references/haskell/haskell-report-1.4-html/exps.html#do-expressions They decided to get rid of it in Haskell 98, for reasons that someone else can probably explain. Lauri ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org ... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] $ do?
Am 15.12.2010 08:36, schrieb Roman Cheplyaka: * Jonathan Geddes geddes.jonat...@gmail.com [2010-12-14 19:59:14-0700] Quick question: Why do I need the $ in the following bits of code? main = withSocketsDo $ do --do something with sockets foo = fromMaybe 0 $ do --do something in the maybe monad I don't see (after admittedly only a minute or so thinking about it) where any grammar ambiguities would be if 'do' had an implicit $ in front of it: foo = fromMaybe 0 do --do something in maybe Though now that I've written it down, that is hard for me to visually parse at a glance. I'm still curious though. Hi Jonathan, it's not clear whether you ask how this implies from the standard or what the rationale of such syntax is. Regarding the former, there are two distinct syntactic categories in Haskell: lexp and aexp. aexp produces all the constructs that can be used as function arguments and does not include do expressions. lexp is more broad and produces do expressions as well. Next look at these productions to see the difference between function application and operator application (sections 3.3 and 3.4 of 2010 report): fexp→ [fexp] aexp infixexp → lexp qop infixexp Regarding the rationale, I'm not so sure and I'd like to hear an explanation from someone competent. But I assume it has something to do with the fact that if you supply a 'do' argument, you cannot supply any more arguments (because 'do' extends to the right as far as possible). Not that I'm convinced that it is a valid reason to prohibit such construct. I made such a proposal 3 years ago, without much feedback. http://www.haskell.org/pipermail/haskell-cafe/2007-July/028203.html Of course, you can supply more arguments, because do, let and case will be terminated by layout. This is not true for \ (lambda) and if-then-else, though. HTH Christian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] $ do?
From: Roman Cheplyaka r...@ro-che.info Sent: Wed, December 15, 2010 1:36:55 AM * Jonathan Geddes geddes.jonat...@gmail.com [2010-12-14 19:59:14-0700] Quick question: Why do I need the $ in the following bits of code? main = withSocketsDo $ do --do something with sockets foo = fromMaybe 0 $ do --do something in the maybe monad I don't see (after admittedly only a minute or so thinking about it) where any grammar ambiguities would be if 'do' had an implicit $ in front of it: foo = fromMaybe 0 do --do something in maybe Though now that I've written it down, that is hard for me to visually parse at a glance. I'm still curious though. Hi Jonathan, it's not clear whether you ask how this implies from the standard or what the rationale of such syntax is. Regarding the former, there are two distinct syntactic categories in Haskell: lexp and aexp. aexp produces all the constructs that can be used as function arguments and does not include do expressions. lexp is more broad and produces do expressions as well. Next look at these productions to see the difference between function application and operator application (sections 3.3 and 3.4 of 2010 report): fexp→ [fexp] aexp infixexp → lexp qop infixexp Regarding the rationale, I'm not so sure and I'd like to hear an explanation from someone competent. But I assume it has something to do with the fact that if you supply a 'do' argument, you cannot supply any more arguments (because 'do' extends to the right as far as possible). Not that I'm convinced that it is a valid reason to prohibit such construct. Years ago, I built GHC with a modified grammar including do and lambdas as aexp. It seemed to work. There were certainly conflicts reported by Happy, but examples seemed to work nicely and I couldn't think of any actual ambiguity. Brandon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] $ do?
Quick question: Why do I need the $ in the following bits of code? main = withSocketsDo $ do --do something with sockets foo = fromMaybe 0 $ do --do something in the maybe monad I don't see (after admittedly only a minute or so thinking about it) where any grammar ambiguities would be if 'do' had an implicit $ in front of it: foo = fromMaybe 0 do --do something in maybe Though now that I've written it down, that is hard for me to visually parse at a glance. I'm still curious though. --Jonathan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] $ do?
* Jonathan Geddes geddes.jonat...@gmail.com [2010-12-14 19:59:14-0700] Quick question: Why do I need the $ in the following bits of code? main = withSocketsDo $ do --do something with sockets foo = fromMaybe 0 $ do --do something in the maybe monad I don't see (after admittedly only a minute or so thinking about it) where any grammar ambiguities would be if 'do' had an implicit $ in front of it: foo = fromMaybe 0 do --do something in maybe Though now that I've written it down, that is hard for me to visually parse at a glance. I'm still curious though. Hi Jonathan, it's not clear whether you ask how this implies from the standard or what the rationale of such syntax is. Regarding the former, there are two distinct syntactic categories in Haskell: lexp and aexp. aexp produces all the constructs that can be used as function arguments and does not include do expressions. lexp is more broad and produces do expressions as well. Next look at these productions to see the difference between function application and operator application (sections 3.3 and 3.4 of 2010 report): fexp→ [fexp] aexp infixexp → lexp qop infixexp Regarding the rationale, I'm not so sure and I'd like to hear an explanation from someone competent. But I assume it has something to do with the fact that if you supply a 'do' argument, you cannot supply any more arguments (because 'do' extends to the right as far as possible). Not that I'm convinced that it is a valid reason to prohibit such construct. -- Roman I. Cheplyaka :: http://ro-che.info/ Don't worry what people think, they don't do it very often. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Do expression definition
Hello.
http://www.haskell.org/onlinereport/exps.html#sect3.14 a obscure (to me) note
which says
As indicated by the translation of do, variables bound by let have fully
polymorphic types while those defined by - are lambda bound and are thus
monomorphic.
What actually does it mean?
And, also, would it make any difference if
do {p - e; stmts} = let ok p = do {stmts}
ok _ = fail ...
in e = ok
is redefined as e = (\p - do {stmts})?
Thanks, Alexander
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Do expression definition
On Mon, 13 Sep 2010, Alexander Kotelnikov wrote:
Hello.
http://www.haskell.org/onlinereport/exps.html#sect3.14 a obscure (to me) note
which says
As indicated by the translation of do, variables bound by let have fully polymorphic
types while those defined by - are lambda bound and are thus monomorphic.
What actually does it mean?
It means that variables bound by let, may be instantiated to different
types later.
And, also, would it make any difference if
do {p - e; stmts} = let ok p = do {stmts}
ok _ = fail ...
in e = ok
is redefined as e = (\p - do {stmts})?
It would not make a difference because the (=)-expression is what the
do-expression is expanded to.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Do expression definition
2010/9/13 Henning Thielemann lemm...@henning-thielemann.de: It means that variables bound by let, may be instantiated to different types later. Can you give an example, please? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Do expression definition
On Mon, Sep 13, 2010 at 8:21 AM, Alexander Kotelnikov sa...@myxomop.com wrote:
And, also, would it make any difference if
do {p - e; stmts} = let ok p = do {stmts}
ok _ = fail ...
in e = ok
is redefined as e = (\p - do {stmts})?
This is the magic that allows pattern-match failure in a do expression
to return a normal result. Notice that fail and not error is
called - each Monad has its own fail method, so that for example:
uncons :: [a] - Maybe (a, [a])
uncons xs = do { (x:xs) - return xs; return (x, xs) }
evaluates to Nothing rather than causing an exception when xs is empty.
That this implementation detail ends up in the Monad class is regarded
by many as untidy, though.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Do I need to roll my own?
I'm looking at iteratee as a way to replace my erroneous and really inefficient lazy-IO-based backend for an expect like Monad DSL I've been working for about 6 months or so now on and off. The problem is I want something like: expect some String send some response to block or perhaps timeout, depending on the environment, looking for some String on an input Handle, and it appears that iteratee works in a very fixed block size. While a fixed block size is ok, if I can put back unused bytes into the enumerator somehow (I may need to put a LOT back in some cases, but in the common case I will not need to put any back as most expect-like scripts typically catch the last few bytes of data sent before the peer is blocked waiting for a response...) Otherwise, I'm going to want to roll my own iteratee style library where I have to say NotDone howMuchMoreIThinkINeed so I don't over consume the input stream. Does that even make any sense? I'm kind of brainstorming in this email unfortunately :-) Dave ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Do I need to roll my own?
David Leimbach leim...@gmail.com writes:
to block or perhaps timeout, depending on the environment, looking for
some String on an input Handle, and it appears that iteratee works
in a very fixed block size. While a fixed block size is ok, if I can
put back unused bytes into the enumerator somehow (I may need to put a
LOT back in some cases, but in the common case I will not need to put
any back as most expect-like scripts typically catch the last few
bytes of data sent before the peer is blocked waiting for a
response...)
See IterGV from the iteratee lib:
http://hackage.haskell.org/packages/archive/iteratee/0.3.1/doc/html/Data-Iteratee-Base.html#t%3AIterGV
The second argument to the Done constructor is for the portion of the
input that you didn't use. If you use the Monad instance, the unused
input is passed on (transparently) to the next iteratee in the chain.
If you use attoparsec-iteratee
(http://hackage.haskell.org/packages/archive/attoparsec-iteratee/0.1/doc/html/Data-Attoparsec-Iteratee.html),
you could write expect as an attoparsec parser:
{-# LANGUAGE OverloadedStrings #-}
import Control.Applicative
import Control.Monad.Trans (lift)
import Data.Attoparsec hiding (Done)
import Data.Attoparsec.Iteratee
import qualified Data.ByteString as S
import Data.ByteString (ByteString)
import Data.Iteratee
import Data.Iteratee.IO.Fd
import Data.Iteratee.WrappedByteString
import Data.Word (Word8)
import System.IO
import System.Posix.IO
expect :: (Monad m) = ByteString
- IterateeG WrappedByteString Word8 m ()
expect s = parserToIteratee (p return ())
where
p = string s | (anyWord8 p)
dialog :: (Monad m) =
IterateeG WrappedByteString Word8 m a -- ^ output end
- IterateeG WrappedByteString Word8 m ()
dialog outIter = do
expect login:
respond foo\n
expect password:
respond bar\n
return ()
where
respond s = do
_ - lift $ enumPure1Chunk (WrapBS s) outIter = run
return ()
main :: IO ()
main = do
hSetBuffering stdin NoBuffering
hSetBuffering stdout NoBuffering
enumFd stdInput (dialog output) = run
where
output = IterateeG $ \chunk -
case chunk of
(EOF _)- return $ Done () chunk
(Chunk (WrapBS s)) - S.putStr s
hFlush stdout
return (Cont output Nothing)
Usage example:
$ awk 'BEGIN { print login:; fflush(); system(sleep 2); \
print password:; fflush(); }' | runhaskell Expect.hs
foo
bar
N.B. for some reason enumHandle doesn't work here w.r.t buffering, had
to go to POSIX i/o to get the proper buffering behaviour.
G
--
Gregory Collins g...@gregorycollins.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Do I need to roll my own?
On Wed, Mar 31, 2010 at 12:02 PM, Gregory Collins
g...@gregorycollins.netwrote:
David Leimbach leim...@gmail.com writes:
to block or perhaps timeout, depending on the environment, looking for
some String on an input Handle, and it appears that iteratee works
in a very fixed block size. While a fixed block size is ok, if I can
put back unused bytes into the enumerator somehow (I may need to put a
LOT back in some cases, but in the common case I will not need to put
any back as most expect-like scripts typically catch the last few
bytes of data sent before the peer is blocked waiting for a
response...)
See IterGV from the iteratee lib:
http://hackage.haskell.org/packages/archive/iteratee/0.3.1/doc/html/Data-Iteratee-Base.html#t%3AIterGV
The second argument to the Done constructor is for the portion of the
input that you didn't use. If you use the Monad instance, the unused
input is passed on (transparently) to the next iteratee in the chain.
If you use attoparsec-iteratee
(
http://hackage.haskell.org/packages/archive/attoparsec-iteratee/0.1/doc/html/Data-Attoparsec-Iteratee.html
),
you could write expect as an attoparsec parser:
{-# LANGUAGE OverloadedStrings #-}
import Control.Applicative
import Control.Monad.Trans (lift)
import Data.Attoparsec hiding (Done)
import Data.Attoparsec.Iteratee
import qualified Data.ByteString as S
import Data.ByteString (ByteString)
import Data.Iteratee
import Data.Iteratee.IO.Fd
import Data.Iteratee.WrappedByteString
import Data.Word (Word8)
import System.IO
import System.Posix.IO
expect :: (Monad m) = ByteString
- IterateeG WrappedByteString Word8 m ()
expect s = parserToIteratee (p return ())
where
p = string s | (anyWord8 p)
dialog :: (Monad m) =
IterateeG WrappedByteString Word8 m a -- ^ output end
- IterateeG WrappedByteString Word8 m ()
dialog outIter = do
expect login:
respond foo\n
expect password:
respond bar\n
return ()
where
respond s = do
_ - lift $ enumPure1Chunk (WrapBS s) outIter = run
return ()
main :: IO ()
main = do
hSetBuffering stdin NoBuffering
hSetBuffering stdout NoBuffering
enumFd stdInput (dialog output) = run
where
output = IterateeG $ \chunk -
case chunk of
(EOF _)- return $ Done () chunk
(Chunk (WrapBS s)) - S.putStr s
hFlush stdout
return (Cont output Nothing)
Usage example:
$ awk 'BEGIN { print login:; fflush(); system(sleep 2); \
print password:; fflush(); }' | runhaskell Expect.hs
foo
bar
N.B. for some reason enumHandle doesn't work here w.r.t buffering, had
to go to POSIX i/o to get the proper buffering behaviour.
That's pretty neat actually. I'm going to have to incorporate timeouts
into something like that (and attoparsec-iteratee doesn't install for me for
some reason, I'll try again today).
That leads me to another question in another thread I'm about to start.
Dave
G
--
Gregory Collins g...@gregorycollins.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Do I need to roll my own?
On Wed, Mar 31, 2010 at 12:24 PM, David Leimbach leim...@gmail.com wrote:
On Wed, Mar 31, 2010 at 12:02 PM, Gregory Collins g...@gregorycollins.net
wrote:
David Leimbach leim...@gmail.com writes:
to block or perhaps timeout, depending on the environment, looking for
some String on an input Handle, and it appears that iteratee works
in a very fixed block size. While a fixed block size is ok, if I can
put back unused bytes into the enumerator somehow (I may need to put a
LOT back in some cases, but in the common case I will not need to put
any back as most expect-like scripts typically catch the last few
bytes of data sent before the peer is blocked waiting for a
response...)
See IterGV from the iteratee lib:
http://hackage.haskell.org/packages/archive/iteratee/0.3.1/doc/html/Data-Iteratee-Base.html#t%3AIterGV
The second argument to the Done constructor is for the portion of the
input that you didn't use. If you use the Monad instance, the unused
input is passed on (transparently) to the next iteratee in the chain.
If you use attoparsec-iteratee
(
http://hackage.haskell.org/packages/archive/attoparsec-iteratee/0.1/doc/html/Data-Attoparsec-Iteratee.html
),
you could write expect as an attoparsec parser:
{-# LANGUAGE OverloadedStrings #-}
import Control.Applicative
import Control.Monad.Trans (lift)
import Data.Attoparsec hiding (Done)
import Data.Attoparsec.Iteratee
import qualified Data.ByteString as S
import Data.ByteString (ByteString)
import Data.Iteratee
import Data.Iteratee.IO.Fd
import Data.Iteratee.WrappedByteString
import Data.Word (Word8)
import System.IO
import System.Posix.IO
expect :: (Monad m) = ByteString
- IterateeG WrappedByteString Word8 m ()
expect s = parserToIteratee (p return ())
where
p = string s | (anyWord8 p)
dialog :: (Monad m) =
IterateeG WrappedByteString Word8 m a -- ^ output end
- IterateeG WrappedByteString Word8 m ()
dialog outIter = do
expect login:
respond foo\n
expect password:
respond bar\n
return ()
where
respond s = do
_ - lift $ enumPure1Chunk (WrapBS s) outIter = run
return ()
main :: IO ()
main = do
hSetBuffering stdin NoBuffering
hSetBuffering stdout NoBuffering
enumFd stdInput (dialog output) = run
where
output = IterateeG $ \chunk -
case chunk of
(EOF _)- return $ Done () chunk
(Chunk (WrapBS s)) - S.putStr s
hFlush stdout
return (Cont output Nothing)
Usage example:
$ awk 'BEGIN { print login:; fflush(); system(sleep 2); \
print password:; fflush(); }' | runhaskell Expect.hs
foo
bar
N.B. for some reason enumHandle doesn't work here w.r.t buffering, had
to go to POSIX i/o to get the proper buffering behaviour.
That's pretty neat actually. I'm going to have to incorporate timeouts
into something like that (and attoparsec-iteratee doesn't install for me for
some reason, I'll try again today).
worked fine today...
That leads me to another question in another thread I'm about to start.
And that other thread is not going to happen, because I realized I was just
having issues with non-strict vs strict evaluation :-) It makes perfect
sense now...
gist is:
timeout (10 ^ 6) $ return $ sum [1..]
and
timeout (10 ^ 6) $! return $ sum [1..]
will not timeout, and will hang while
timeout (10 ^ 6) $ return $! sum [1..]
does timeout... and everything in the Haskell universe is nice and
consistent.
Dave
Dave
G
--
Gregory Collins g...@gregorycollins.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do we need types?
I'd say we don't really need subclasses. I mean, what's the difference:
class Eq a where (==) :: a - a - Bool
instance Eq a = Eq (Maybe a) where
Nothing == Nothing = True
Just x == Just y = x == y
_ == _ = False
sort :: Eq a = [a] - [a]
or
data Eq a = Eq {eq :: a - a - Bool}
eqMaybe :: Eq a - Eq (Maybe a)
eqMaybe e = Eq {eq = eqM} where
eqM Nothing Nothing = True
eqM (Just x) (Just y) = eq e x y
eqM _ _ = False
sort :: Eq a - [a] - [a]
Replacing classes with types, we only lose one thing: the compiler won't deduce
the right instances for us. I'll trade it for the ability to abstract over
them. After all, we CAN deduce the right
instances by hand, it's just a finite amount of work (not very big, in my
experience).
Pasqualino Titto Assini wrote:
Hi, just a silly question (or maybe more than one):
In Haskell we have data types (Integer,[a],...) as well as type
classes (Num, Ord...).
But, if we have type classes do we still need types?
Why shouldn't the objects that we process be defined only by their
'interfaces' (assuming that a type class is a kind of interface)?
Maybe the real question is: are type classes a more primitive concept
than data types?
And if so, in a language that had only type classes what would a data
declaration like the following map to:
data List a = Cons a (List a) | Nil
And what about pattern matching? Would that still be possible, and
what form would it take?
And finally, would having only type classes make the type system any simpler?
Thanks,
titto
___
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] do we need types?
s/subclasses/classes/
Sorry for the confusion.
Miguel Mitrofanov wrote:
I'd say we don't really need subclasses. I mean, what's the difference:
class Eq a where (==) :: a - a - Bool
instance Eq a = Eq (Maybe a) where
Nothing == Nothing = True
Just x == Just y = x == y
_ == _ = False
sort :: Eq a = [a] - [a]
or
data Eq a = Eq {eq :: a - a - Bool}
eqMaybe :: Eq a - Eq (Maybe a)
eqMaybe e = Eq {eq = eqM} where
eqM Nothing Nothing = True
eqM (Just x) (Just y) = eq e x y
eqM _ _ = False
sort :: Eq a - [a] - [a]
Replacing classes with types, we only lose one thing: the compiler won't
deduce the right instances for us. I'll trade it for the ability to
abstract over them. After all, we CAN deduce the right
instances by hand, it's just a finite amount of work (not very big, in
my experience).
Pasqualino Titto Assini wrote:
Hi, just a silly question (or maybe more than one):
In Haskell we have data types (Integer,[a],...) as well as type
classes (Num, Ord...).
But, if we have type classes do we still need types?
Why shouldn't the objects that we process be defined only by their
'interfaces' (assuming that a type class is a kind of interface)?
Maybe the real question is: are type classes a more primitive concept
than data types?
And if so, in a language that had only type classes what would a data
declaration like the following map to:
data List a = Cons a (List a) | Nil
And what about pattern matching? Would that still be possible, and
what form would it take?
And finally, would having only type classes make the type system any
simpler?
Thanks,
titto
___
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] do we need types?
This reminds me of an email posted to this list long ago
by Luke Palmer, describing a use of records-as-interfaces
in Agda.
--
Jason Dusek
-- Forwarded message --
From: Luke Palmer lrpal...@gmail.com
Date: 2009/12/29
Subject: Re: [Haskell-cafe] Alternatives to type classes.
To: Jason Dusek jason.du...@gmail.com
Cc: haskell haskell-cafe@haskell.org
On Tue, Dec 29, 2009 at 6:22 PM, Jason Dusek jason.du...@gmail.com wrote:
Consider the real numbers. They are a group. We have an
identity element `0', inverses and closure under the associative
operation `+'.
Group+ = (+, 0, -1 * _)
They are another group, too -- the group with `*':
Group* = (*, 1, 1 / _)
Ignoring 0 for sake of discussion.
This seems like a real problem with the whole notion of
typeclasses -- we can't really say a set/type is its
extension with some new operations.
One road to go on this is to make every extension of the set
with new ops a different type; but that seems really horribly
inconvenient. I wonder what approaches have been tried here?
I consider typeclasses a happy notational medium. They are not
perfect, they miss some cases, but they are pretty good.
For full generality at the expense of some verbosity, I like Agda's
solution pretty well. Agda allows you to open a record into a
scope.
record Group (a : Set) where
field
_+_ : a - a - a
-_ : a - a
0 : a
conj : {a : Set} - Group a - a - a - a
conj g x y = x + y + (-x)
where open g
Maybe I even got the syntax right :-P
The cool thing is that you can use this for the invariant-keeping
property of typeclasses, too. Eg. Data.Map relies on the fact that
there is at most one Ord instance per type. By parameterizing the
module over the Ord record, we can do the same:
record Ord (a : Set) where ...
module MapMod (a : Set) (ord : Ord a) where
Map : b - Set
Map = ...
insert : {b : Set} - a - b - Map b - Map b
insert = ...
...
So we have the liberty of being able to use different Ord instances,
but different Ord instances give rise to different Map types, so we
can not violate any invariants.
You can do something similar in Haskell using an existential type,
although it is very inconvenient:
data Ord a = ...
data MapMod map a b = MapMod { empty :: map a b, insert :: a - b -
map a b - map a b, ... }
withMap :: Ord a - (forall map. MapMod map a b - z) - z
withMap ord f = f ( {- implement MapMod here, using ord for ordering }- )
Then you could use maps on different Ords for the same type, but they
could not talk to each other.
Some syntax sugar could help the Haskell situation quite a lot.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do we need types?
On Fri, Feb 26, 2010 at 04:23:52PM +0300, Miguel Mitrofanov wrote:
I'd say we don't really need subclasses. I mean, what's the difference:
class Eq a where (==) :: a - a - Bool
instance Eq a = Eq (Maybe a) where
Nothing == Nothing = True
Just x == Just y = x == y
_ == _ = False
sort :: Eq a = [a] - [a]
or
data Eq a = Eq {eq :: a - a - Bool}
eqMaybe :: Eq a - Eq (Maybe a)
eqMaybe e = Eq {eq = eqM} where
eqM Nothing Nothing = True
eqM (Just x) (Just y) = eq e x y
eqM _ _ = False
sort :: Eq a - [a] - [a]
Replacing classes with types, we only lose one thing: the compiler won't
deduce the right instances for us. I'll trade it for the ability to abstract
over them. After all, we CAN deduce the right
instances by hand, it's just a finite amount of work (not very big, in my
experience).
But then we would lose the invarient that there is a unique pairing
between a type and a given class. for instance, you would no longer be
able to implement things like Set and Map,
For instance if you called the two following functions with different
ord arguments, you would suddenly break all the invarients of what 'Set'
means.
insert :: Ord a - a - Set a - Set a
member :: Ord a - a - Set a - Bool
The unique correspondence between types and classes (i.e. no local
instances) is a main _feature_ of type classes. Often when people think
they need local instances, they are just applying type classes when they
should be using a different idiom, such as the one you mention.
John
--
John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Do you need Windows USB in Haskell?
Hi Mauricio, 2009/12/5 Maurício CA mauricio.antu...@gmail.com: Problem is: I don't have a Windows machine where I could test this. So, if you need USB in windows, please keep in touch. I wouldn't ask you to write any code, but I need to know what builds and what doesn't. I don't need usb and I can't say I'm a windows user, but I'd be glad to test it since I have it on a virtual machine. In my case, installation fails on bindings-common. Is there something I need to do first? I do have mingw32 and msys installed, if that's necessary. Log attached. Take care, Paulo c:\tools\haskell-platform\2009.2.0.2\bin\ghc.exe --numeric-version looking for package tool: ghc-pkg near compiler in c:\tools\haskell-platform\2009.2.0.2\bin found package tool in c:\tools\haskell-platform\2009.2.0.2\bin\ghc-pkg.exe c:\tools\haskell-platform\2009.2.0.2\bin\ghc-pkg.exe --version c:\tools\haskell-platform\2009.2.0.2\bin\ghc.exe --supported-languages Reading installed packages... c:\tools\haskell-platform\2009.2.0.2\bin\ghc-pkg.exe dump --global Reading available packages... Resolving dependencies... selecting usb-0.2.0.1 (hackage) and discarding bindings-libusb-0.0.1, 0.0.2, 0.0.3, 0.0.4, 0.0.5, 0.0.6, 0.0.7, 1.0, 1.1, 1.2, 1.4, text-0.1, 0.2, 0.3, 0.4, usb-0.1, 0.1.0.1 and 0.2 selecting bindings-libusb-1.3 (hackage) and discarding bindings-common-0.1, 0.1.1, 0.1.2, 0.1.3, 0.1.4, 0.2, 0.2.1, 0.2.2, 0.2.3, 0.2.4, 0.2.5, 0.2.6, 1.0, 1.1, 1.2, bindings-posix-0.0.1, 0.0.2, 1.0, 1.0.1 and 1.1 selecting bindings-posix-1.2 (hackage) selecting text-0.5 (installed or hackage) selecting ghc-prim-0.1.0.0 (installed) selecting rts-1.0 (installed) selecting bytestring-0.9.1.4 (installed or hackage) and discarding bytestring-0.9, 0.9.0.1, 0.9.0.2, 0.9.0.3, 0.9.0.4, 0.9.1.0, 0.9.1.1, 0.9.1.2, 0.9.1.3 and 0.9.1.5 selecting bindings-common-1.3.4 (hackage) and discarding bindings-common-1.3, 1.3.1, 1.3.2 and 1.3.3 selecting base-3.0.3.1 (installed) and 4.1.0.0 (installed) and discarding syb-0.1.0.0 and 0.1.0.1 selecting integer-0.1.0.1 (installed) selecting syb-0.1.0.1 (installed) In order, the following would be installed: bindings-common-1.3.4 (new package) bindings-posix-1.2 (new package) bindings-libusb-1.3 (new package) usb-0.2.0.1 (new package) bindings-common-1.3.4 has already been downloaded. Extracting C:\Documents and Settings\tanimoto\Application Data\cabal\packages\hackage.haskell.org\bindings-common\1.3.4\bindings-common-1.3.4.tar.gz to C:\DOCUME~1\tanimoto\LOCALS~1\Temp\bindings-common-1.3.43288... Configuring bindings-common-1.3.4... Dependency base =3 5 ==3.0.3.1: using base-3.0.3.1 Using Cabal-1.6.0.3 compiled by ghc-6.10 Using compiler: ghc-6.10.4 Using install prefix: C:\Program Files\Haskell Binaries installed in: C:\Program Files\Haskell\bin Libraries installed in: C:\Program Files\Haskell\bindings-common-1.3.4\ghc-6.10.4 Private binaries installed in: C:\Program Files\Haskell\bindings-common-1.3.4 Data files installed in: C:\Program Files\Haskell\bindings-common-1.3.4 Documentation installed in: C:\Program Files\Haskell\doc\bindings-common-1.3.4 Using alex version 2.3.1 found on system at: c:\tools\haskell-platform\2009.2.0.2\extralibs\bin\alex.exe Using ar found on system at: c:\MinGW\bin\ar.exe No c2hs found No cpphs found No ffihugs found Using gcc version 3.4.5 found on system at: c:\tools\haskell-platform\2009.2.0.2\gcc.exe Using ghc version 6.10.4 found on system at: c:\tools\haskell-platform\2009.2.0.2\bin\ghc.exe Using ghc-pkg version 6.10.4 found on system at: c:\tools\haskell-platform\2009.2.0.2\bin\ghc-pkg.exe No greencard found Using haddock version 2.4.2 found on system at: c:\tools\haskell-platform\2009.2.0.2\bin\haddock.exe Using happy version 1.18.4 found on system at: c:\tools\haskell-platform\2009.2.0.2\extralibs\bin\happy.exe No hmake found Using hsc2hs version 0.67 found on system at: c:\tools\haskell-platform\2009.2.0.2\bin\hsc2hs.exe No hscolour found No hugs found No jhc found Using ld found on system at: c:\tools\haskell-platform\2009.2.0.2\gcc-lib\ld.exe No nhc98 found Using pkg-config version 0.23 found on system at: c:\tools\gtk2hs\0.10.1\bin\pkg-config.exe Using ranlib found on system at: c:\MinGW\bin\ranlib.exe Using strip found on system at: c:\MinGW\bin\strip.exe Using tar found on system at: C:\msys\1.0\bin\tar.exe c:\tools\haskell-platform\2009.2.0.2\gcc.exe -Bc:\tools\haskell-platform\2009.2.0.2\gcc-lib -Ic:\tools\haskell-platform\2009.2.0.2\include\mingw C:\DOCUME~1\tanimoto\LOCALS~1\Temp\3288.c -o C:\DOCUME~1\tanimoto\LOCALS~1\Temp\3288 -Bc:\tools\haskell-platform\2009.2.0.2\gcc-lib -Ic:\tools\haskell-platform\2009.2.0.2\include\mingw -D__GLASGOW_HASKELL__=610 -Isrc -I. -D_ISOC99_SOURCE -Ic:\tools\haskell-platform\2009.2.0.2\base-4.1.0.0\include -Ic:\tools\haskell-platform\2009.2.0.2/include Creating dist\build (and its parents) Creating dist\build\autogen (and its parents) Preprocessing library bindings-common-1.3.4... Creating dist\build\Bindings\C (and its parents)
[Haskell-cafe] Do you need Windows USB in Haskell?
Hi, I keep this direct binding to libusb-1.0.x: http://hackage.haskell.org/package/bindings-libusb on top of which Bas maintains a nice USB library: http://hackage.haskell.org/package/usb Work has been done to support libusb-1.0.x in Windows. So, as long as my bindings-libusb works properly with that, Bas' as well as any other library based on it will work too. Problem is: I don't have a Windows machine where I could test this. So, if you need USB in windows, please keep in touch. I wouldn't ask you to write any code, but I need to know what builds and what doesn't. Best, Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Do I have this right? Remembering Memoization!
I agree with what you meant, but not quite with what you said. To be pedantic: import Debug.Trace foo :: Int foo = trace Foo (bar 12) bar :: Int - Int bar x = trace Bar x main :: IO () main = foo `seq` foo `seq` return () main prints Foo\nBar\n showing that the bar is only evaluated once, because foo is already evaluated, even though it is referenced twice. So attempting to evaluate foo again just returns the same result. baz :: Int - Int baz x = trace Baz (bar x) correct :: IO () correct = baz 10 `seq` baz 11 `seq` return () Though, as you said, call, you probably meant foo was a function, and correct prints Baz\nBar\nBaz\nBar\n like you had indicated. But pedantically even the function: quux :: Int - Int quux x = trace Quux (bar 12) optmain :: IO () optmain = quux 10 `seq` quux 11 `seq` return () might print only once if GHC at the optimization level selected recognizes that quux doesn't depend on its argument and rewrote your code with more sharing. -Edward Kmett On Sun, Sep 13, 2009 at 7:45 PM, Mark Wotton mwot...@gmail.com wrote: On 14/09/2009, at 9:28 AM, Casey Hawthorne wrote: Do I have this right? Remembering Memoization! For some applications, a lot of state does not to be saved, since initialization functions can be called early, and these functions will remember - (memoize) their results when called again, because of lazy evaluation? You don't get memoisation for free. If you define a variable once in a where block, it's true that you'll evaluate it at most once, but if you repeatedly call a function foo that then calls bar 12 each time, bar 12 will be evaluated once per foo call. Cheers Mark ___ 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] Do I have this right? Remembering Memoization!
But pedantically even the function: quux :: Int - Int quux x = trace Quux (bar 12) optmain :: IO () optmain = quux 10 `seq` quux 11 `seq` return () might print only once if GHC at the optimization level selected recognizes that quux doesn't depend on its argument and rewrote your code with more sharing. Well to be specific, it depends on how you define function, quux :: Int - Int quux = trace Quux bar will print Quux once under the naive semantics. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Do I have this right? Remembering Memoization!
Do I have this right? Remembering Memoization! For some applications, a lot of state does not to be saved, since initialization functions can be called early, and these functions will remember - (memoize) their results when called again, because of lazy evaluation? -- Regards, Casey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Do I have this right? Remembering Memoization!
On 14/09/2009, at 9:28 AM, Casey Hawthorne wrote: Do I have this right? Remembering Memoization! For some applications, a lot of state does not to be saved, since initialization functions can be called early, and these functions will remember - (memoize) their results when called again, because of lazy evaluation? You don't get memoisation for free. If you define a variable once in a where block, it's true that you'll evaluate it at most once, but if you repeatedly call a function foo that then calls bar 12 each time, bar 12 will be evaluated once per foo call. Cheers Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Do you understand posix well?
I've beeing writing a low-level binding to posix that can be usefull if you want to use posix but has no time to learn FFI: http://hackage.haskell.org/package/bindings-posix However, my understandment of posix is barely nothing, and I see that many of its functionality is enabled or disabled by macros, and I don't know which ones are related to what functionality. So, if you know about that: would you be able to list all macros (or at least most important ones, if there are too many) that enable all (or most) of posix? In exchange, you get a posix binding that is actually comprehensive :) Thanks, Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] do nmergeIO or mergeIO preserve order?
do nmergeIO or mergeIO preserve order? or not preserve order? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do nmergeIO or mergeIO preserve order?
Although it is not formally specified, my intuition for the specification is that order is preserved within each of the lists. Luke On Tue, Mar 10, 2009 at 2:50 PM, Anatoly Yakovenko aeyakove...@gmail.comwrote: do nmergeIO or mergeIO preserve order? or not preserve order? ___ 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] do nmergeIO or mergeIO preserve order?
Hmm, yea, actually that makes sense. What i am looking for is something that maps over a list and returns the list in order which the values are evaluated. looks like i can implement that pretty easily with unamb. On Tue, Mar 10, 2009 at 2:33 PM, Luke Palmer lrpal...@gmail.com wrote: Although it is not formally specified, my intuition for the specification is that order is preserved within each of the lists. Luke On Tue, Mar 10, 2009 at 2:50 PM, Anatoly Yakovenko aeyakove...@gmail.com wrote: do nmergeIO or mergeIO preserve order? or not preserve order? ___ 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] do nmergeIO or mergeIO preserve order?
I think nmergeIO . map (:[]) should do the trick. Luke On Tue, Mar 10, 2009 at 3:41 PM, Anatoly Yakovenko aeyakove...@gmail.comwrote: Hmm, yea, actually that makes sense. What i am looking for is something that maps over a list and returns the list in order which the values are evaluated. looks like i can implement that pretty easily with unamb. On Tue, Mar 10, 2009 at 2:33 PM, Luke Palmer lrpal...@gmail.com wrote: Although it is not formally specified, my intuition for the specification is that order is preserved within each of the lists. Luke On Tue, Mar 10, 2009 at 2:50 PM, Anatoly Yakovenko aeyakove...@gmail.com wrote: do nmergeIO or mergeIO preserve order? or not preserve order? ___ 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] do nmergeIO or mergeIO preserve order?
i think this would still force me to evailuate the whole list, right? i would want something that pipes the results into a channel that i can lazyly read as the results are available. On Tue, Mar 10, 2009 at 2:44 PM, Luke Palmer lrpal...@gmail.com wrote: I think nmergeIO . map (:[]) should do the trick. Luke On Tue, Mar 10, 2009 at 3:41 PM, Anatoly Yakovenko aeyakove...@gmail.com wrote: Hmm, yea, actually that makes sense. What i am looking for is something that maps over a list and returns the list in order which the values are evaluated. looks like i can implement that pretty easily with unamb. On Tue, Mar 10, 2009 at 2:33 PM, Luke Palmer lrpal...@gmail.com wrote: Although it is not formally specified, my intuition for the specification is that order is preserved within each of the lists. Luke On Tue, Mar 10, 2009 at 2:50 PM, Anatoly Yakovenko aeyakove...@gmail.com wrote: do nmergeIO or mergeIO preserve order? or not preserve order? ___ 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] do nmergeIO or mergeIO preserve order?
Oh, you're right. Here are some thoughts. You want the list you get back to only contain values in WHNF. This differs from mergeIO co., which are simply evaluating the spine of the list, and don't even look at the values. I would also consider it bad style to be fully polymorphic in this case, as you require polymorphic seq, which is evil (though I don't have the space to argue this right now :-). Unamb would be bad style, also, since your semantics are nondeterministic and so you wouldn't meet the precondition. Surely your result would have to be in IO. (amb would be okay) Here is how I would do it: chooseIO :: [IO a] - IO [a] chooseIO xs = do chan - newChan let eval io = forkIO (io = writeChan chan) forkIO $ mapM_ eval xs getChanContents chan (The list never ends in this case, even when xs is finite. I think it's possible to make the result finite with the argument is, and maintain good GC properties, but it would take some care) The reason I take a list of [IO a] is to avoid polymorphic seq; the elements of the list have built in what it means to evaluate them. This also buys you more flexibility (but also fewer guarantees...). For the working Haskeller, it is safe to avoid all this pedantic zealotry... I'm just being a purist. Luke On Tue, Mar 10, 2009 at 5:31 PM, Anatoly Yakovenko aeyakove...@gmail.comwrote: i think this would still force me to evailuate the whole list, right? i would want something that pipes the results into a channel that i can lazyly read as the results are available. On Tue, Mar 10, 2009 at 2:44 PM, Luke Palmer lrpal...@gmail.com wrote: I think nmergeIO . map (:[]) should do the trick. Luke On Tue, Mar 10, 2009 at 3:41 PM, Anatoly Yakovenko aeyakove...@gmail.com wrote: Hmm, yea, actually that makes sense. What i am looking for is something that maps over a list and returns the list in order which the values are evaluated. looks like i can implement that pretty easily with unamb. On Tue, Mar 10, 2009 at 2:33 PM, Luke Palmer lrpal...@gmail.com wrote: Although it is not formally specified, my intuition for the specification is that order is preserved within each of the lists. Luke On Tue, Mar 10, 2009 at 2:50 PM, Anatoly Yakovenko aeyakove...@gmail.com wrote: do nmergeIO or mergeIO preserve order? or not preserve order? ___ 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] do nmergeIO or mergeIO preserve order?
I would also consider it bad style to be fully polymorphic in this case, as you require polymorphic seq, which is evil (though I don't have the space to argue this right now :-). Unamb would be bad style, also, since your semantics are nondeterministic and so you wouldn't meet the precondition. Surely your result would have to be in IO. (amb would be okay) what do you mean by fully polymorphic? Here is how I would do it: chooseIO :: [IO a] - IO [a] chooseIO xs = do chan - newChan let eval io = forkIO (io = writeChan chan) forkIO $ mapM_ eval xs getChanContents chan Cool, thanks, thats basically what iw as thinking to. Anatoly ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do you have to use fix with forkio?
Derek Elkins wrote: Both are poorish style. reader - forkIO $ forever $ do (nr', line) - readChan; when (nr /= nr') $ putStrLn hdl line This is fine assuming you always want to re-enter the loop. If you want to loop conditionally (which is most often the case), forever isn't going to work, unless you use exceptions. Martijn. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do you have to use fix with forkio?
On Sat, 2009-03-07 at 23:12 +0100, Martijn van Steenbergen wrote: Derek Elkins wrote: Both are poorish style. reader - forkIO $ forever $ do (nr', line) - readChan; when (nr /= nr') $ putStrLn hdl line This is fine assuming you always want to re-enter the loop. If you want to loop conditionally (which is most often the case), forever isn't going to work, unless you use exceptions. If you are doing something else, use something else. This makes it clear that you -aren't- going to break out (non-exceptionally), i.e. the control flow is more obvious in this code than in the other versions. By your logic 'map' would be bad because not everything is a map, of course, this is precisely why using map, when applicable, is good. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do you have to use fix with forkio?
Derek Elkins wrote: If you are doing something else, use something else. This makes it clear that you -aren't- going to break out (non-exceptionally), i.e. the control flow is more obvious in this code than in the other versions. Oh yes, of course! I wasn't saying forever is bad; in fact I agree with you that it's the best solution in this case. I just wanted to note that forever isn't always a good substitute for fix $ \loop -, without implying that was what you were suggesting. Martijn. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do you have to use fix with forkio?
Two questions: a) This chat server implementation doesn't actually close the connection as a real one would need to do. If you use forever is there a way to end the loop so as to end the connection? b) In Section 5 of this paper: http://www.cs.yale.edu/~hl293/download/leak.pdf Comparing the definition of eSF and e reveals that the primary difference is in the fixed-point operators they use. e uses Haskell’s built-in fixed-point operator, which is equivalent to the standard: fix f = f (fix f) eSF, on the other hand, is defined in terms of the loop combinator, which ties the loop tighter than the standard fixed-point operator. In particular, note in Figure 6 that loop computes the value-level fixed point as z, but re-uses itself in the continuation part. This is the key to avoiding the space leak. My reading is that the fix operator, at least in some cases, causes space leak. Where as the arrow's loop, which uses let model, doesn't have this issue. Question: Do I need to worry about space leak if I am using the fix to instead of the let? Thanks Daryoush 2009/3/5 Luke Palmer lrpal...@gmail.com On Thu, Mar 5, 2009 at 6:27 PM, Donn Cave d...@avvanta.com wrote: Quoth Jonathan Cast jonathancc...@fastmail.fm: You can certainly use let: reader - forkIO $ let loop = do (nr', line) - readChan chan' when (nr /= nr') $ hPutStrLn hdl line loop in loop But the version with fix is clearer (at least to people who have fix in their vocabulary) and arguably better style. Would you mind presenting the better style argument? To me, the above could not be clearer, so it seems like the version with fix could be only as clear, at best. I like using fix when it's simple rather than let, because it tells me the purpose of the binding. eg., when I see let foo = ... Where ... is fairly long, I'm not sure what the purpose of foo is, or what its role is in the final computation. It may not be used at all, or passed to some modifier function, or I don't know what. Whereas with: fix $ \foo - ... I know that whatever ... is, it is what is returne, and the purpose of foo is to use that return value in the expression itself. I know that it's a simple matter of scanning to the corresponding in, but let can be used for a lot of things, where as fix $ \foo is basically only for simple knot-tying. Now, that doesn't say anything about the use of fix without an argument (passed to an HOF) or with a tuple as an argument or many other cases, which my brain has not chunked nearly as effectively. I think fix is best with a single, named argument. Luke ___ 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] do you have to use fix with forkio?
Personally I would not use fix. I don't think it improves readability. -- Lennart 2009/3/5 Daryoush Mehrtash dmehrt...@gmail.com: In this chat server implementation http://www.haskell.org/haskellwiki/Implement_a_chat_server forkIO is used with fix as in: reader - forkIO $ fix $ \loop - do (nr', line) - readChan chan' when (nr /= nr') $ hPutStrLn hdl line loop Do you have to use fix? Or is there a way to write this with a let? -- Daryoush ___ 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] do you have to use fix with forkio?
2009/3/6 Daryoush Mehrtash dmehrt...@gmail.com: Two questions: a) This chat server implementation doesn't actually close the connection as a real one would need to do. If you use forever is there a way to end the loop so as to end the connection? Yes, throw an exception and catch it from outside the forever. b) In Section 5 of this paper: http://www.cs.yale.edu/~hl293/download/leak.pdf Comparing the definition of eSF and e reveals that the primary difference is in the fixed-point operators they use. e uses Haskell’s built-in fixed-point operator, which is equivalent to the standard: fix f = f (fix f) eSF, on the other hand, is defined in terms of the loop combinator, which ties the loop tighter than the standard fixed-point operator. In particular, note in Figure 6 that loop computes the value-level fixed point as z, but re-uses itself in the continuation part. This is the key to avoiding the space leak. My reading is that the fix operator, at least in some cases, causes space leak. Where as the arrow's loop, which uses let model, doesn't have this issue. Question: Do I need to worry about space leak if I am using the fix to instead of the let? the definition of fix in Data.Function[1] actually uses let: fix :: (a - a) - a fix f = let x = f x in x [1] http://darcs.haskell.org/packages/base/Data/Function.hs Thanks Daryoush 2009/3/5 Luke Palmer lrpal...@gmail.com On Thu, Mar 5, 2009 at 6:27 PM, Donn Cave d...@avvanta.com wrote: Quoth Jonathan Cast jonathancc...@fastmail.fm: You can certainly use let: reader - forkIO $ let loop = do (nr', line) - readChan chan' when (nr /= nr') $ hPutStrLn hdl line loop in loop But the version with fix is clearer (at least to people who have fix in their vocabulary) and arguably better style. Would you mind presenting the better style argument? To me, the above could not be clearer, so it seems like the version with fix could be only as clear, at best. I like using fix when it's simple rather than let, because it tells me the purpose of the binding. eg., when I see let foo = ... Where ... is fairly long, I'm not sure what the purpose of foo is, or what its role is in the final computation. It may not be used at all, or passed to some modifier function, or I don't know what. Whereas with: fix $ \foo - ... I know that whatever ... is, it is what is returne, and the purpose of foo is to use that return value in the expression itself. I know that it's a simple matter of scanning to the corresponding in, but let can be used for a lot of things, where as fix $ \foo is basically only for simple knot-tying. Now, that doesn't say anything about the use of fix without an argument (passed to an HOF) or with a tuple as an argument or many other cases, which my brain has not chunked nearly as effectively. I think fix is best with a single, named argument. Luke ___ 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] do you have to use fix with forkio?
On Fri, Mar 6, 2009 at 1:48 AM, Daryoush Mehrtash dmehrt...@gmail.comwrote: Question: Do I need to worry about space leak if I am using the fix to instead of the let? If you need to worry about a space leak with fix, you need to worry about it with let. The reason arrows can tie the loop tighter is more about the nature of recursion in streams; an arrow sees that prior values of a signal are not used, whereas value recursion is much less restricted. If, for example, the arrow were a kleisli arrow over the list monad, this would not be possible. With the definition fix f = let x = f x in x, you should not see any performance difference, other than the standard HOF penalty if there is not enough inlining... but that should not be asymptotic anyway. Luke Thanks Daryoush 2009/3/5 Luke Palmer lrpal...@gmail.com On Thu, Mar 5, 2009 at 6:27 PM, Donn Cave d...@avvanta.com wrote: Quoth Jonathan Cast jonathancc...@fastmail.fm: You can certainly use let: reader - forkIO $ let loop = do (nr', line) - readChan chan' when (nr /= nr') $ hPutStrLn hdl line loop in loop But the version with fix is clearer (at least to people who have fix in their vocabulary) and arguably better style. Would you mind presenting the better style argument? To me, the above could not be clearer, so it seems like the version with fix could be only as clear, at best. I like using fix when it's simple rather than let, because it tells me the purpose of the binding. eg., when I see let foo = ... Where ... is fairly long, I'm not sure what the purpose of foo is, or what its role is in the final computation. It may not be used at all, or passed to some modifier function, or I don't know what. Whereas with: fix $ \foo - ... I know that whatever ... is, it is what is returne, and the purpose of foo is to use that return value in the expression itself. I know that it's a simple matter of scanning to the corresponding in, but let can be used for a lot of things, where as fix $ \foo is basically only for simple knot-tying. Now, that doesn't say anything about the use of fix without an argument (passed to an HOF) or with a tuple as an argument or many other cases, which my brain has not chunked nearly as effectively. I think fix is best with a single, named argument. Luke ___ 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] do you have to use fix with forkio?
In this chat server implementation http://www.haskell.org/haskellwiki/Implement_a_chat_server forkIO is used with fix as in: reader - forkIO $ http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:. fix $ http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:. \loop - do (nr', line) - readChan chan' when (nr /= http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:/= nr') $ http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:. hPutStrLn hdl line loop Do you have to use fix? Or is there a way to write this with a let? -- Daryoush ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do you have to use fix with forkio?
On Thu, 2009-03-05 at 15:36 -0800, Daryoush Mehrtash wrote: In this chat server implementation http://www.haskell.org/haskellwiki/Implement_a_chat_server forkIO is used with fix as in: reader - forkIO $ fix $ \loop - do (nr', line) - readChan chan' when (nr /= nr') $ hPutStrLn hdl line loop Do you have to use fix? Or is there a way to write this with a let? You can certainly use let: reader - forkIO $ let loop = do (nr', line) - readChan chan' when (nr /= nr') $ hPutStrLn hdl line loop in loop But the version with fix is clearer (at least to people who have fix in their vocabulary) and arguably better style. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do you have to use fix with forkio?
On Thu, 2009-03-05 at 16:12 -0800, Jonathan Cast wrote: On Thu, 2009-03-05 at 15:36 -0800, Daryoush Mehrtash wrote: In this chat server implementation http://www.haskell.org/haskellwiki/Implement_a_chat_server forkIO is used with fix as in: reader - forkIO $ fix $ \loop - do (nr', line) - readChan chan' when (nr /= nr') $ hPutStrLn hdl line loop Do you have to use fix? Or is there a way to write this with a let? You can certainly use let: reader - forkIO $ let loop = do (nr', line) - readChan chan' when (nr /= nr') $ hPutStrLn hdl line loop in loop But the version with fix is clearer (at least to people who have fix in their vocabulary) and arguably better style. Both are poorish style. reader - forkIO $ forever $ do (nr', line) - readChan; when (nr /= nr') $ putStrLn hdl line ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do you have to use fix with forkio?
Quoth Jonathan Cast jonathancc...@fastmail.fm: You can certainly use let: reader - forkIO $ let loop = do (nr', line) - readChan chan' when (nr /= nr') $ hPutStrLn hdl line loop in loop But the version with fix is clearer (at least to people who have fix in their vocabulary) and arguably better style. Would you mind presenting the better style argument? To me, the above could not be clearer, so it seems like the version with fix could be only as clear, at best. Thanks, Donn cave PS - granted that forever is a fine alternative to either, I suppose it doesn't affect the style comparison above. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do you have to use fix with forkio?
On Thu, Mar 5, 2009 at 6:27 PM, Donn Cave d...@avvanta.com wrote: Quoth Jonathan Cast jonathancc...@fastmail.fm: You can certainly use let: reader - forkIO $ let loop = do (nr', line) - readChan chan' when (nr /= nr') $ hPutStrLn hdl line loop in loop But the version with fix is clearer (at least to people who have fix in their vocabulary) and arguably better style. Would you mind presenting the better style argument? To me, the above could not be clearer, so it seems like the version with fix could be only as clear, at best. I like using fix when it's simple rather than let, because it tells me the purpose of the binding. eg., when I see let foo = ... Where ... is fairly long, I'm not sure what the purpose of foo is, or what its role is in the final computation. It may not be used at all, or passed to some modifier function, or I don't know what. Whereas with: fix $ \foo - ... I know that whatever ... is, it is what is returne, and the purpose of foo is to use that return value in the expression itself. I know that it's a simple matter of scanning to the corresponding in, but let can be used for a lot of things, where as fix $ \foo is basically only for simple knot-tying. Now, that doesn't say anything about the use of fix without an argument (passed to an HOF) or with a tuple as an argument or many other cases, which my brain has not chunked nearly as effectively. I think fix is best with a single, named argument. Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Do I need an account to report build of Hacakge packages?
On Fri, 2008-11-21 at 16:12 -0800, Ahn, Ki Yung wrote: I am just curious about how cabal report works. I recently figured out that there is a report command in cabal and it reports the reports generated by --build-reports option when building a package. Is this because I don't have an account on Hackage yet, or because of some other reasons? It's a feature that exists in the client that has no corresponding implementation on the server-side yet. There is a new hackage-server in development that can accept build reports uploaded by cabal report. And if I make an account, where how I put that information in cabal config file? You only need an account for uploading packages. If you do not want to have to enter your user name or password interactively when you run cabal upload then you can put them in the config file: username: password: You can use one field without the other field and cabal upload will prompt for the one you did not supply. So you don't need to save your password in the config file. I've looked into the cabal config file and tried to change this myself before, but it wasn't very self explanatory to me. For instance, I tried to make the build-reports on by default, deleting haskell comment like double dashes -- and put True flag after the colon, but keep getting parse error from cabal. I looked up the manual but it says that the config file is self explanatory, which isn't to me at all. Are there any documentations on this available anywhere? There is some problems in the config file parsing code it seems. The config file parsing code is derived automatically from the command line parsing code but imperfectly at the moment. For example --build-reports is a boolean value flag but with no argument and these do not seem to be converted correctly into config file fields. === error messages when I tried to report the build log === [EMAIL PROTECTED]:~$ cabal report Yes. The current hackage server does not support uploading build reports. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Do I need an account to report build of Hacakgepackages?
You only need an account for uploading packages. If you do not want to have to enter your user name or password interactively when you run cabal upload then you can put them in the config file: username: password: That sounds like a very bad idea, and should not be encouraged! Any compromised uploader machine with stored passwords can be used to upload compromising code, which will propagate to all downloaders. One bad-apple package installed unwittingly on one uploader machine with stored passwords could compromise all of Haskell land. Claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Do I need an account to report build of Hacakgepackages?
On Sat, 2008-11-22 at 15:11 +, Claus Reinke wrote: You only need an account for uploading packages. If you do not want to have to enter your user name or password interactively when you run cabal upload then you can put them in the config file: username: password: That sounds like a very bad idea, and should not be encouraged! Any compromised uploader machine with stored passwords can be used to upload compromising code, which will propagate to all downloaders. One bad-apple package installed unwittingly on one uploader machine with stored passwords could compromise all of Haskell land. We've got bigger security issues than this. I'd welcome someone to spend some time implementing some of the obvious and sensible ideas we've discussed to improve the situation. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Do I need an account to report build of Hacakgepackages?
On Sat, Nov 22, 2008 at 03:11:34PM -, Claus Reinke wrote: You only need an account for uploading packages. If you do not want to have to enter your user name or password interactively when you run cabal upload then you can put them in the config file: username: password: That sounds like a very bad idea, and should not be encouraged! Agreed. However... Any compromised uploader machine with stored passwords can be used to upload compromising code, which will propagate to all downloaders. It doesn't really matter whether a compromised machine stores a password or not. If you upload anything using a compromised machine, the attacker has the opportunity to learn your password. Also, Hackage doesn't use SSL/TLS, so compromising a machine isn't necessary for learning Hackage passwords. -- Antti-Juhani Kaijanaho, Jyväskylä, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Do I need an account to report build ofHacakgepackages?
Any compromised uploader machine with stored passwords can be used to upload compromising code, which will propagate to all downloaders. It doesn't really matter whether a compromised machine stores a password or not. If you upload anything using a compromised machine, the attacker has the opportunity to learn your password. True. But storing the password means that the owner doesn't need to initiate an upload, nor does the attacker need to capture keypresses, listen on connections, identify uploads/logins/passwords in the captured date, or do anything at all non-trivial, platform-specific or persistent (propagation could ignore the owner's machine). Also, Hackage doesn't use SSL/TLS, so compromising a machine isn't necessary for learning Hackage passwords. As Duncan says, an overall security review would be good, the sooner, the better. But that shouldn't prevent incremental improvements whereever they are found. One just needs to keep in mind that they make attacks harder/less likely, not impossible. Encouraging all users to keep an eye on the obvious holes may also make it more likely that the less obvious holes are noticed and addressed. Claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Do I need an account to report build of Hacakge packages?
I am just curious about how cabal report works.
I recently figured out that there is a report command in cabal and it
reports the reports generated by --build-reports option when building a
package.
Is this because I don't have an account on Hackage yet, or because of
some other reasons?
And if I make an account, where how I put that information in cabal
config file?
I've looked into the cabal config file and tried to change this myself
before, but it wasn't very self explanatory to me. For instance, I
tried to make the build-reports on by default, deleting haskell comment
like double dashes -- and put True flag after the colon, but keep
getting parse error from cabal. I looked up the manual but it says that
the config file is self explanatory, which isn't to me at all. Are
there any documentations on this available anywhere?
=== error messages when I tried to report the build log ===
[EMAIL PROTECTED]:~$ cabal report
Sending:
POST http://hackage.haskell.org/buildreports HTTP/1.1
Content-Type: text/plain
Content-Length: 281
Accept: text/plain
Creating new connection to hackage.haskell.org
Received:
HTTP/1.1 404 Not Found
Date: Fri, 21 Nov 2008 23:52:14 GMT
Server: Apache/2.2.3 (Debian)
Alternates: {HTTP_NOT_FOUND.html.var 1 {type text/html} {charset
iso-8859-2} {language cs} {length 745}}, {HTTP_NOT_FOUND.html.var 1
{type text/html} {charset iso-8859-1} {language de} {length 766}},
{HTTP_NOT_FOUND.html.var 1 {type text/html} {charset iso-8859-1}
{language en} {length 611}}, {HTTP_NOT_FOUND.html.var 1 {type
text/html} {charset iso-8859-1} {language es} {length 759}},
{HTTP_NOT_FOUND.html.var 1 {type text/html} {charset iso-8859-1}
{language fr} {length 771}}, {HTTP_NOT_FOUND.html.var 1 {type
text/html} {charset iso-8859-1} {language ga} {length 813}},
{HTTP_NOT_FOUND.html.var 1 {type text/html} {charset iso-8859-1}
{language it} {length 692}}, {HTTP_NOT_FOUND.html.var 1 {type
text/html} {charset iso-2022-jp} {language ja} {length 749}},
{HTTP_NOT_FOUND.html.var 1 {type text/html} {charset euc-kr} {language
ko} {length 703}}, {HTTP_NOT_FOUND.html.var 1 {type text/html}
{charset iso-8859-1} {language nl} {length 688}},
{HTTP_NOT_FOUND.html.var 1 {type text/html} {charset iso-8859-2}
{language pl} {length 707}}, {HTTP_NOT_FOUND.html.var 1 {type
text/html} {charset iso-8859-1} {language pt-br} {length 753}},
{HTTP_NOT_FOUND.html.var 1 {type text/html} {charset iso-8859-1}
{language ro} {length 689}}, {HTTP_NOT_FOUND.html.var 1 {type
text/html} {charset iso-8859-5} {language sr} {length 716}},
{HTTP_NOT_FOUND.html.var 1 {type text/html} {charset iso-8859-1}
{language sv} {length 722}}, {HTTP_NOT_FOUND.html.var 1 {type
text/html} {charset iso-8859-9} {language tr} {length 755}}
Vary: accept-language,accept-charset
Content-Length: 418
Content-Type: text/html; charset=iso-8859-1
cabal: Unrecognised response from server.
[EMAIL PROTECTED]:~$ cabal --version
cabal-install version 0.6.0
using version 1.6.0.1 of the Cabal library
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] do like notation works fine when using ghc head
There is also the combinator approach of Text.Html, which
gives you a syntax similar to (3) but without abusing do:
(rootElt ! [xmlns http://www.w3.org/1999/xhtml;,
lang en-US xml:lang en-US]) $ concatXml
[head $ title $ text minimal
,body $ concatXml
[h1 $ text minimal
,div $ text $ args passed to this program: ++ (show args)
]
]
Keep in mind that my library tries to do real DTD type checking.
This means that
body, h1, div
all have different types. So they can't easily be put into a list.
And yes: I care about each character I have to type less :-)
About IO (). IO was just a poor man example to show that you can nest
arbitrary monads. Have a look at the WASH library to see in which
wonderful ways this can be used..
One working snippet from the testXHTML.hs sample file provided by the
lib:
#include vxmldos.h
tDo $ runHtmlDoc $ vdo
head $ title $ text text
body $ vdo
script $ X.type text/javascript text
document.writeln('hi');
h2 $ text That's a headline, hello and how do you do?
-- br e eg a br/ is not allowed here
div $ vdo
onclick alert('clicked');
styleA color:#F79
text text within the div
div e
return That's nice, isn't it?
vxmldos.h defines a vdo cpp macro which expands to
let ; in $ do
where ... rebinds =, , lift to make this work (in with ghc head)
The library can now cope with fancy dts such as (a*)* etc as well
If you still find bugs let me know.
The more interesting part starts now: figuring out how do build a nice
HTML library on top of this all.
Sincerly
Marc Weber
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] do and ifthenelse indentation in GHC
http://hackage.haskell.org/trac/haskell-prime/wiki/DoAndIfThenElse says (and my memory seems to agree) that GHC has been changed to accept things like readnums f n = do eof - hIsEOF f if eof then return n else do l - hGetLine f readnums f (n + read l) where the `then' and `else' are aligned with the `if' rather than being slightly more indented as the Haskell 98 standard requires. Yet, when I try it with GHCi 6.8.2 I get an error: Prelude :load /home/monnier/tmp/foo.hs [1 of 1] Compiling Main ( /home/monnier/tmp/foo.hs, interpreted ) /home/monnier/tmp/foo.hs:6:18: parse error (possibly incorrect indentation) Failed, modules loaded: none. Prelude Does anybody know what's up with that? Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] do construct in wxhaskell
hi, im working ona project, and im having problem loading some code in wxhaskell: onOpen :: Frame a - TextCtrl b - MenuItem c - StatusField - IO () onOpen f sw mclose status = do mbfname - fileOpenDialog f False True Open image fileTypescase (mbfname) of (Nothing) - return () (Just (fname)) - do fileContent - readFile fname set sw [text := fileContent] set mclose [enabled := True] set status [text := fname] return () i keep getting the error : the last statement in a 'do' construct must be an expression. ive tried rearranging it many times, but i still get the same error. any help would be greatly appreciated. _ Connect to the next generation of MSN Messenger http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-ussource=wlmailtagline___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do construct in wxhaskell
The indentation is not right; all the statements after the 'do' keyword need to start exactly at the same column. In particular, the 'f' in fileContent and 's' in set should be one below the other. And the 'return ()' also seems to be displaced; perhaps you want that also exactly below the last 'set' if it's the part of the last case. Hope it helps Abhay 2008/4/12 Jodi-Ann Prince [EMAIL PROTECTED]: hi, im working ona project, and im having problem loading some code in wxhaskell: onOpen :: Frame a - TextCtrl b - MenuItem c - StatusField - IO () onOpen f sw mclose status = do mbfname - fileOpenDialog f False True Open image fileTypes case (mbfname) of (Nothing) - return () (Just (fname)) - do fileContent - readFile fname set sw [text := fileContent] set mclose [enabled := True] set status [text := fname] return () i keep getting the error : the last statement in a 'do' construct must be an expression. ive tried rearranging it many times, but i still get the same error. any help would be greatly appreciated. -- Connect to the next generation of MSN Messenger Get it now! http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-ussource=wlmailtagline ___ 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] Do real programs need IO? (was IO is a bad example for Monads)
On Dec 9, 2007 10:07 AM, Daniel Fischer [EMAIL PROTECTED] wrote: Interactive programmes without using IO? Cool :) And how! I think you misunderstood Lennart. Thanks for checking. In this case, I think I understood Lennart fine and that he was saying what you're saying. Would you deny that any useful programme has to do at least some of the following: -accept programme arguments at invocation -get input, be it from a keyboard, mouse, reading files, pipes... -output a result or state info, to the monitor, a file, a pipe... === If by programme, you mean the code I write, then I'm happy to deny that my programme has to do these things. Examples below. If you include a stateful RTS, then no I don't deny it. I think Lennart was referring to that, you HAVE to know a little IO to write programmes, at least getArgs, getLine, putStr(Ln), readFile, writeFile, appendFile. And therefore some use of the IO monad has to be taught relatively early. Explicit imperative programming is just one way to deal with input output, not the only way. As proof, see FRP, Pan, or TV programs, which contain uses of none of these functions. (Nor could they, as these libraries are functional, having IO-free types and semantics.) Moreover, use of imperative programming sacrifices some of the semantic simplicity composability that makes FP so appealing. That's why I'd like to see this belief in its necessity dispelled. That said, I don't think the existing functional (non-IO) approaches to interaction are quite there yet with the flexibility of imperative programming. It will take more work to get them there, and that work is mostly likely to be pursued by people who doubt the necessity of IO for writing real programs. In that sense, Lennart's and your statements are self-fulfilling prophechies, as are mine. BTW, if you haven't seen it already, please check out http://haskell.org/haskellwiki/TV . The TV (tangible values) approach includes a simple algebra of interfaces (input/output) and keeps separable from the core computation. The separability allows the interface parts to be composed in parallel with the core part. For instance, when two function-valued TVs are composed, the interfaces are peeled off, so that the core functions can be composed directly. The output half of one interface and the matching input half of the other are discarded. The remaining input and output halves are recombined into a new interface, which is used as the interface of the composed TV. The core interface algebra can be used for text stream i/o, GUIs, and many other possible styles of information passing. I mention TV, because it's an example of combining the purity composability I love about FP with the usability a real app. For more about this combination, please see my Google tech talk Tangible Functional Programming: a modern marriage of usability and composability ( http://conal-elliott.blogspot.com/2007/11/tangible-functional-programming-modern.html). That talk focus on end-user composability, but the essential points apply as well to explicit programming. As I mentioned before, TV (a) is currently less flexible than imperative/IO programming, and (b) has the composability, guaranteed safety, and amenability to reasoning of pure functional programming. Cheers, - Conal Am Sonntag, 9. Dezember 2007 18:31 schrieb Conal Elliott: IO is important because you can't write any real program without using it. Ouch! I get awfully discouraged when I read statements like this one. The more people who believe it, the more true it becomes. If you want to do functional programming, instead of imperative programming in a functional language, you can. For instance, write real, interactive programs in FRP, phooey, or TV. And if you do, you'll get semantic simplicity, powerful simpler reasoning, safety and composability. - Conal On Dec 8, 2007 1:26 AM, Lennart Augustsson [EMAIL PROTECTED] wrote: [...] IO is important because you can't write any real program without using it. So why not teach enough of it to get people off the ground straight away? People who hang around long enough to do some more Haskell programming will run into the other monads sooner or later. But IO is an unavoidable step to writing Haskell programs. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Do real programs need IO? (was IO is a bad example for Monads)
Conal, I think TV etc. is fantastic stuff, but that mean that we cannot, say, invoke an external program in Haskell until someone has figured out a composable library for this? I sincerely hope someone will, but the only way we have right now is the ugly IO monad. -- Lennart On Dec 9, 2007 7:26 PM, Conal Elliott [EMAIL PROTECTED] wrote: On Dec 9, 2007 10:07 AM, Daniel Fischer [EMAIL PROTECTED] wrote: Interactive programmes without using IO? Cool :) And how! I think you misunderstood Lennart. Thanks for checking. In this case, I think I understood Lennart fine and that he was saying what you're saying. Would you deny that any useful programme has to do at least some of the following: -accept programme arguments at invocation -get input, be it from a keyboard, mouse, reading files, pipes... -output a result or state info, to the monitor, a file, a pipe... === If by programme, you mean the code I write, then I'm happy to deny that my programme has to do these things. Examples below. If you include a stateful RTS, then no I don't deny it. I think Lennart was referring to that, you HAVE to know a little IO to write programmes, at least getArgs, getLine, putStr(Ln), readFile, writeFile, appendFile. And therefore some use of the IO monad has to be taught relatively early. Explicit imperative programming is just one way to deal with input output, not the only way. As proof, see FRP, Pan, or TV programs, which contain uses of none of these functions. (Nor could they, as these libraries are functional, having IO-free types and semantics.) Moreover, use of imperative programming sacrifices some of the semantic simplicity composability that makes FP so appealing. That's why I'd like to see this belief in its necessity dispelled. That said, I don't think the existing functional (non-IO) approaches to interaction are quite there yet with the flexibility of imperative programming. It will take more work to get them there, and that work is mostly likely to be pursued by people who doubt the necessity of IO for writing real programs. In that sense, Lennart's and your statements are self-fulfilling prophechies, as are mine. BTW, if you haven't seen it already, please check out http://haskell.org/haskellwiki/TV . The TV (tangible values) approach includes a simple algebra of interfaces (input/output) and keeps separable from the core computation. The separability allows the interface parts to be composed in parallel with the core part. For instance, when two function-valued TVs are composed, the interfaces are peeled off, so that the core functions can be composed directly. The output half of one interface and the matching input half of the other are discarded. The remaining input and output halves are recombined into a new interface, which is used as the interface of the composed TV. The core interface algebra can be used for text stream i/o, GUIs, and many other possible styles of information passing. I mention TV, because it's an example of combining the purity composability I love about FP with the usability a real app. For more about this combination, please see my Google tech talk Tangible Functional Programming: a modern marriage of usability and composability ( http://conal-elliott.blogspot.com/2007/11/tangible-functional-programming-modern.html). That talk focus on end-user composability, but the essential points apply as well to explicit programming. As I mentioned before, TV (a) is currently less flexible than imperative/IO programming, and (b) has the composability, guaranteed safety, and amenability to reasoning of pure functional programming. Cheers, - Conal Am Sonntag, 9. Dezember 2007 18:31 schrieb Conal Elliott: IO is important because you can't write any real program without using it. Ouch! I get awfully discouraged when I read statements like this one. The more people who believe it, the more true it becomes. If you want to do functional programming, instead of imperative programming in a functional language, you can. For instance, write real, interactive programs in FRP, phooey, or TV. And if you do, you'll get semantic simplicity, powerful simpler reasoning, safety and composability. - Conal On Dec 8, 2007 1:26 AM, Lennart Augustsson [EMAIL PROTECTED] wrote: [...] IO is important because you can't write any real program without using it. So why not teach enough of it to get people off the ground straight away? People who hang around long enough to do some more Haskell programming will run into the other monads sooner or later. But IO is an unavoidable step to writing Haskell programs. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe
Re: [Haskell-cafe] Do real programs need IO? (was IO is a bad example for Monads)
I think your real point is that some things we still haven't figured out how to express functionally. Right? I would certainly agree with that part. Perhaps you exaggerating when you wrote IO is important because you can't write any real program without using it. Cheers, - Conal On Dec 9, 2007 12:14 PM, Lennart Augustsson [EMAIL PROTECTED] wrote: Conal, I think TV etc. is fantastic stuff, but that mean that we cannot, say, invoke an external program in Haskell until someone has figured out a composable library for this? I sincerely hope someone will, but the only way we have right now is the ugly IO monad. -- Lennart On Dec 9, 2007 7:26 PM, Conal Elliott [EMAIL PROTECTED] wrote: On Dec 9, 2007 10:07 AM, Daniel Fischer [EMAIL PROTECTED] wrote: Interactive programmes without using IO? Cool :) And how! I think you misunderstood Lennart. Thanks for checking. In this case, I think I understood Lennart fine and that he was saying what you're saying. Would you deny that any useful programme has to do at least some of the following: -accept programme arguments at invocation -get input, be it from a keyboard, mouse, reading files, pipes... -output a result or state info, to the monitor, a file, a pipe... === If by programme, you mean the code I write, then I'm happy to deny that my programme has to do these things. Examples below. If you include a stateful RTS, then no I don't deny it. I think Lennart was referring to that, you HAVE to know a little IO to write programmes, at least getArgs, getLine, putStr(Ln), readFile, writeFile, appendFile. And therefore some use of the IO monad has to be taught relatively early. Explicit imperative programming is just one way to deal with input output, not the only way. As proof, see FRP, Pan, or TV programs, which contain uses of none of these functions. (Nor could they, as these libraries are functional, having IO-free types and semantics.) Moreover, use of imperative programming sacrifices some of the semantic simplicity composability that makes FP so appealing. That's why I'd like to see this belief in its necessity dispelled. That said, I don't think the existing functional (non-IO) approaches to interaction are quite there yet with the flexibility of imperative programming. It will take more work to get them there, and that work is mostly likely to be pursued by people who doubt the necessity of IO for writing real programs. In that sense, Lennart's and your statements are self-fulfilling prophechies, as are mine. BTW, if you haven't seen it already, please check out http://haskell.org/haskellwiki/TV . The TV (tangible values) approach includes a simple algebra of interfaces (input/output) and keeps separable from the core computation. The separability allows the interface parts to be composed in parallel with the core part. For instance, when two function-valued TVs are composed, the interfaces are peeled off, so that the core functions can be composed directly. The output half of one interface and the matching input half of the other are discarded. The remaining input and output halves are recombined into a new interface, which is used as the interface of the composed TV. The core interface algebra can be used for text stream i/o, GUIs, and many other possible styles of information passing. I mention TV, because it's an example of combining the purity composability I love about FP with the usability a real app. For more about this combination, please see my Google tech talk Tangible Functional Programming: a modern marriage of usability and composability ( http://conal-elliott.blogspot.com/2007/11/tangible-functional-programming-modern.html). That talk focus on end-user composability, but the essential points apply as well to explicit programming. As I mentioned before, TV (a) is currently less flexible than imperative/IO programming, and (b) has the composability, guaranteed safety, and amenability to reasoning of pure functional programming. Cheers, - Conal Am Sonntag, 9. Dezember 2007 18:31 schrieb Conal Elliott: IO is important because you can't write any real program without using it. Ouch! I get awfully discouraged when I read statements like this one. The more people who believe it, the more true it becomes. If you want to do functional programming, instead of imperative programming in a functional language, you can. For instance, write real, interactive programs in FRP, phooey, or TV. And if you do, you'll get semantic simplicity, powerful simpler reasoning, safety and composability. - Conal On Dec 8, 2007 1:26 AM, Lennart Augustsson [EMAIL PROTECTED] wrote: [...] IO is important because you can't write any real program without using it. So why not teach enough
Re: [Haskell-cafe] Do real programs need IO? (was IO is a bad example for Monads)
Am Sonntag, 9. Dezember 2007 21:29 schrieb Conal Elliott: I think your real point is that some things we still haven't figured out how to express functionally. Right? That's my point, at least. Currently, AFAIK, the only way to get input and produce output is via the IO monad, so it is de facto necessary for all 'real' programmes, it need not remain so (though I cannot imagine how to functionally express 'readFile Data.txt = print . performAwfullyCoolFunctionalStuff' - surprise me :). Read IO is important as a description of current affairs, not as a claim of the inherent grandeur of it. Cheers, Daniel I would certainly agree with that part. Perhaps you exaggerating when you wrote IO is important because you can't write any real program without using it. Cheers, - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Do real programs need IO? (was IO is a bad example for Monads)
Thanks for the clarification. AFAIK, the only way to get input and produce output is via the IO monad Now you know something different, don't you? FRP, Pan, TV. Also Grapefruit, functional forms, and others I'm not thinking of or don't know about. As for your example, mixing the IO with the functional, as you have interferes with composing the result. I can think of two alternatives. One is to move reading printing from the definition to the uses, as with Unix stream filters. Still convenient, and much more flexible. Of course, Unix programs were written in C and so use explicit I/O instead of lazy functional streams. (Though Doug McIlroy, who invented Unix pipes, knew that pipes were equivalent to coroutines and to lazy evaluation. See my modern marriage talk (the video I mentioned) for more about Unix and TV.) A second alternative is to use TV to explicitly capture the interface (I/O), which could look like this: coolTV :: TV (String - String) coolTV = tv (olambda (fileIn Data.txt) defaultOut) performAwfullyCoolFunctionalStuff where tv :: Output src snk a - a - TV src snk a The type parameters src snk are for various interface styles. Then coolTV can then be used on *either* side of a TV-style pipe, resulting in the removal of the reading or writing half. And yes, there are *some* uses of IO for which I'd be hard pressed at this point to offer you an alternative. Which is a far cry from IO being necessary for all real programs, even today. Given this state of affairs, I'd prefer the Haskell community to point newbies away from IO and toward purely functional programming for things like UIs and graphics and help them change their way of thinking. Let's also admit that we haven't yet figured out how to apply our functional paradigm as flexibly or broadly as we'd like, and so meanwhile we have thi monadic IO trick that let's them write nicely factored imperative code that can call into the functional pieces. Regards, - Conal On Dec 9, 2007 12:54 PM, Daniel Fischer [EMAIL PROTECTED] wrote: Am Sonntag, 9. Dezember 2007 21:29 schrieb Conal Elliott: I think your real point is that some things we still haven't figured out how to express functionally. Right? That's my point, at least. Currently, AFAIK, the only way to get input and produce output is via the IO monad, so it is de facto necessary for all 'real' programmes, it need not remain so (though I cannot imagine how to functionally express 'readFile Data.txt = print . performAwfullyCoolFunctionalStuff' - surprise me :). Read IO is important as a description of current affairs, not as a claim of the inherent grandeur of it. Cheers, Daniel I would certainly agree with that part. Perhaps you exaggerating when you wrote IO is important because you can't write any real program without using it. Cheers, - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Do real programs need IO? (was IO is a bad example for Monads)
Maybe I'm exaggerating, but it's true for 96% of all programs. (96% is with a :-)) I did not express anything that was meant to be a perpetual truth, only best practice at the moment. For a living I write programs that are almost without interaction with the outside world. Still, I need a to spend 1% of the code doing IO related stuff and it's very important that I can do it. The other 99% are just pure computations. But that I think that validates rather than invalidates my point. -- Lennart On Dec 9, 2007 8:29 PM, Conal Elliott [EMAIL PROTECTED] wrote: I think your real point is that some things we still haven't figured out how to express functionally. Right? I would certainly agree with that part. Perhaps you exaggerating when you wrote IO is important because you can't write any real program without using it. Cheers, - Conal On Dec 9, 2007 12:14 PM, Lennart Augustsson [EMAIL PROTECTED] wrote: Conal, I think TV etc. is fantastic stuff, but that mean that we cannot, say, invoke an external program in Haskell until someone has figured out a composable library for this? I sincerely hope someone will, but the only way we have right now is the ugly IO monad. -- Lennart On Dec 9, 2007 7:26 PM, Conal Elliott [EMAIL PROTECTED] wrote: On Dec 9, 2007 10:07 AM, Daniel Fischer [EMAIL PROTECTED] wrote: Interactive programmes without using IO? Cool :) And how! I think you misunderstood Lennart. Thanks for checking. In this case, I think I understood Lennart fine and that he was saying what you're saying. Would you deny that any useful programme has to do at least some of the following: -accept programme arguments at invocation -get input, be it from a keyboard, mouse, reading files, pipes... -output a result or state info, to the monitor, a file, a pipe... === If by programme, you mean the code I write, then I'm happy to deny that my programme has to do these things. Examples below. If you include a stateful RTS, then no I don't deny it. I think Lennart was referring to that, you HAVE to know a little IO to write programmes, at least getArgs, getLine, putStr(Ln), readFile, writeFile, appendFile. And therefore some use of the IO monad has to be taught relatively early. Explicit imperative programming is just one way to deal with input output, not the only way. As proof, see FRP, Pan, or TV programs, which contain uses of none of these functions. (Nor could they, as these libraries are functional, having IO-free types and semantics.) Moreover, use of imperative programming sacrifices some of the semantic simplicity composability that makes FP so appealing. That's why I'd like to see this belief in its necessity dispelled. That said, I don't think the existing functional (non-IO) approaches to interaction are quite there yet with the flexibility of imperative programming. It will take more work to get them there, and that work is mostly likely to be pursued by people who doubt the necessity of IO for writing real programs. In that sense, Lennart's and your statements are self-fulfilling prophechies, as are mine. BTW, if you haven't seen it already, please check out http://haskell.org/haskellwiki/TV . The TV (tangible values) approach includes a simple algebra of interfaces (input/output) and keeps separable from the core computation. The separability allows the interface parts to be composed in parallel with the core part. For instance, when two function-valued TVs are composed, the interfaces are peeled off, so that the core functions can be composed directly. The output half of one interface and the matching input half of the other are discarded. The remaining input and output halves are recombined into a new interface, which is used as the interface of the composed TV. The core interface algebra can be used for text stream i/o, GUIs, and many other possible styles of information passing. I mention TV, because it's an example of combining the purity composability I love about FP with the usability a real app. For more about this combination, please see my Google tech talk Tangible Functional Programming: a modern marriage of usability and composability ( http://conal-elliott.blogspot.com/2007/11/tangible-functional-programming-modern.html). That talk focus on end-user composability, but the essential points apply as well to explicit programming. As I mentioned before, TV (a) is currently less flexible than imperative/IO programming, and (b) has the composability, guaranteed safety, and amenability to reasoning of pure functional programming. Cheers, - Conal Am Sonntag, 9. Dezember 2007 18:31 schrieb Conal Elliott: IO is important because you can't write any real program without
[Haskell-cafe] do notation strangeness
Hello!
I see from http://www.haskell.org/haskellwiki/Monads_as_computation#Do_notation
that
do { v - x ; stmts }
= x = \v - do { stmts }
However, look at this GHCi session:
Prelude let return' = return :: a - Maybe a
Prelude do {1 - return 1; return' ok}
Just ok
Prelude return 1 = \1 - return' ok
Just ok
Prelude do {1 - return 3; return' ok}
Nothing
Prelude return 3 = \1 - return' ok
*** Exception: interactive:1:13-30: Non-exhaustive patterns in lambda
Hmmm... let's try with IO:
Prelude let return' = return :: a - IO a
Prelude do {1 - return 1; return' ok}
ok
Prelude return 1 = \1 - return' ok
ok
Prelude do {1 - return 3; return' ok}
*** Exception: user error (Pattern match failure in do expression at
interactive:1:4)
Prelude return 3 = \1 - return' ok
*** Exception: interactive:1:13-30: Non-exhaustive patterns in lambda
Oh! What about lists?
Prelude let return' = return :: a - [a]
Prelude do {1 - return 1; return' ok}
[ok]
Prelude return 1 = \1 - return' ok
[ok]
Prelude do {1 - return 3; return' ok}
[]
Prelude return 3 = \1 - return' ok
*** Exception: interactive:1:13-30: Non-exhaustive patterns in lambda
Something seems wrong to me here. What am I missing?
Thanks!
--
Felipe.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do notation strangeness
On Sat, Dec 08, 2007 at 02:59:16PM -0200, Felipe Lessa wrote:
Hello!
I see from
http://www.haskell.org/haskellwiki/Monads_as_computation#Do_notation
that
do { v - x ; stmts }
= x = \v - do { stmts }
However, look at this GHCi session:
Prelude let return' = return :: a - Maybe a
Prelude do {1 - return 1; return' ok}
Just ok
Prelude return 1 = \1 - return' ok
Just ok
Prelude do {1 - return 3; return' ok}
Nothing
Prelude return 3 = \1 - return' ok
*** Exception: interactive:1:13-30: Non-exhaustive patterns in lambda
What seems confusing to you?
\1 - foo
is the same as
\x - case x of {1 - foo;}
When this function is evaluated with parameter different from 1, Haskell
fails to find matching pattern for x and exception occurs.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do notation strangeness
On Sat, Dec 08, 2007 at 03:28:58PM -0200, Felipe Lessa wrote:
On Dec 8, 2007 3:12 PM, Ilya Tsindlekht [EMAIL PROTECTED] wrote:
On Sat, Dec 08, 2007 at 02:59:16PM -0200, Felipe Lessa wrote:
Prelude do {1 - return 3; return' ok}
Nothing
Prelude return 3 = \1 - return' ok
*** Exception: interactive:1:13-30: Non-exhaustive patterns in lambda
What seems confusing to you?
\1 - foo
is the same as
\x - case x of {1 - foo;}
When this function is evaluated with parameter different from 1, Haskell
fails to find matching pattern for x and exception occurs.
The problem is that with the do notation it doesn't raise an
exception. In the example you quoted,
Yes, I have already understood it from your reply to the original
poster.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] do... error
hi
test :: Parser (Char,Char) test = do x - item item
y - item return (x,y)
How come this brings an error saying that after do {} it must end with an
expression.
Ryan
_
Get free emoticon packs and customisation from Windows Live.
http://www.pimpmylive.co.uk___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do... error
On Dec 8, 2007, at 21:38 , Ryan Bloor wrote: test :: Parser (Char,Char) test = do x - item item The second and subsequent lines are indented too much, so are read as a continuation of the first; which, starting with x - , is not an expression. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do... error
On Dec 8, 2007, at 21:40 , Brandon S. Allbery KF8NH wrote: On Dec 8, 2007, at 21:38 , Ryan Bloor wrote: test :: Parser (Char,Char) test = do x - item item The second and subsequent lines are indented too much, so are read as a continuation of the first; which, starting with x - , is not an expression. I neglected to say the proper indentation: test = do x - item item -- note, indented to match the token after the do y - item return (x,y) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do... error
On Dec 9, 2007 12:42 AM, Brandon S. Allbery KF8NH [EMAIL PROTECTED] wrote:
I neglected to say the proper indentation:
test = do x - item
item -- note, indented to match the token after
the do
y - item
return (x,y)
That is the best thing to do. If you don't like the identation rule,
you may also use explicit semicolons as in
test = do {x - item;
item;
y - item;
return (x,y)}
or maybe
test = do {x - item; item; y - item; return (x,y)}
or even
test = do { x -
item; item
; y - item ; return
(x,y)}
Of course, in the last example you lost all the legibility of your
code, but it compiles =).
HTH,
--
Felipe.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do... error
On Dec 9, 2007 1:01 AM, Ryan Bloor [EMAIL PROTECTED] wrote: But what is the right way to indent...? It is so annoying, why does it matter so much! :( You may read http://en.wikibooks.org/wiki/Haskell/Indentation which tries to explain in a very simple language. -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] do
Hi I've probably asked about the do construct, if that's the right label. Unfortunately I'm still not quite sure of its role and more specifically its syntax. Something to do with generators perhaps? A description plus some examples would be most gratefully received. Thanks, Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do
On Dec 3, 2007 6:55 AM, PR Stanley [EMAIL PROTECTED] wrote: Hi I've probably asked about the do construct, if that's the right label. Unfortunately I'm still not quite sure of its role and more specifically its syntax. Something to do with generators perhaps? A description plus some examples would be most gratefully received. Probably one should understand how to use monads before worrying about the do-notation. Here are some references: http://haskell.org/haskellwiki/Books_and_tutorials#Using_monads http://en.wikibooks.org/wiki/Haskell/Understanding_monads Section 2.5 of http://haskell.org/haskellwiki/Learning_Haskell Hope this helps. -- Denis ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do
Probably one should understand how to use monads before worrying about
the do-notation. Here are some references:
I don't totally agree. You can teach monads to beginners just fine
using the do-notation. Unsuprisingly its very much like teaching
monads using bind. You describe a two line do-block as the basic
building block for combining two actions into a single action:
do {
result1 - act1
expr involving result1 building an act
}
show that you can nest them (expr can be another do block)
do {
result1 - act1
do {
result2 - act2
expr involving result1 and result2 building an act
}
}
and how the do-notation doesn't require you to start a new do-block
for nesting of do's and let's
do {
result1 - act1
let val1 - expr resulting in a pure value
result2 - act2
expr involving result1 and result2 building an act
}
Then you can describe pattern matching and fail...
I've had debates about what should be taught, and obviously not
everyone agrees, but at the least, its possible and reasonable
and understandable to teach do-notation first.
Denis
Tim Newsham
http://www.thenewsh.com/~newsham/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do
On 03 Dec 2007, at 13:25 , Tim Newsham wrote:
Probably one should understand how to use monads before worrying
about
the do-notation. Here are some references:
I don't totally agree. You can teach monads to beginners just fine
using the do-notation. Unsuprisingly its very much like teaching
monads using bind. You describe a two line do-block as the basic
building block for combining two actions into a single action:
do {
result1 - act1
expr involving result1 building an act
}
By teaching = and return first in the context of monads, I think it
encourages seeing 'do' primarily as syntactic sugar, instead of some
mysterious construct in its own right. This lets you apply
everything you know about programming in pure, functional, typed
programming (e.g. Haskell, SML, etc.) to monads, by seeing the type
signature of = and return. This, in turn, lets you conclude that
monads are not mysterious at all, but simply a few operations whose
types work in concert. This doesn't mean you understand them, but it
removes certain potential confusions.
If you learn 'do' first, there is a tendency to think of using
monads and using do as synonymous, which they are not; and of
thinking that 'do' is performing some sort of magic on your types
(i.e. that you couldn't straightforwardly emulate 'do' with other
operations).
When you're first learning monads, you're constantly suspicious of
the mysterious, because of their name, their reputation, and their
putative generality and power. (I say 'putative' because when you're
learning you don't yet know that it's true. =])
I've had debates about what should be taught, and obviously not
everyone agrees, but at the least, its possible and reasonable
and understandable to teach do-notation first.
I don't think I can conclude that there are *no* reasons to teach the
do-notation first. I just think that it is more instructive to teach
it later.
Please understand I'm a relative newbie in Haskell, so I would
appreciate any comments on what I said above. I'm still trying to
learn. =]
-Denis
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do
On Dec 3, 2007 1:09 PM, Denis Bueno [EMAIL PROTECTED] wrote: I don't think I can conclude that there are *no* reasons to teach the do-notation first. I just think that it is more instructive to teach it later. It's standard in mathematics teaching, when introducing a mathematical structure X, to ensure that students have the knowledge to understand an example of X before they see the definition of X. So students won't study groups before they've met the integers, they won't study fields before they've met the rationals, and they won't study topology until they're familiar with the real line. Not just met them either, usually they've usually completely internalised the examples before moving onto the general structure. The problem with monads is that students have never knowingly met an example of a monad before. If you teach them do-notation for IO without monads, and they get completely familiar with it (which (1) I claim is easy: http://sigfpe.blogspot.com/2007/11/io-monad-for-people-who-simply-dont.html and (2) is inevitable if they want to see the output of their programs) then when they come to learning about monads in general they'll have an example they don't even have to think about. The more adventurous ones may even discover some of the monad laws for themselves if they experiment with nested do's like in Tim Newsham's examples (and think them so obvious they hardly need to be graced with the name law). -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] do/if/then/else confusion
Another newbie question, but I can't seem to find any answers on the web... Can someone tell me what's wrong with this? import qualified System.Posix.Directory as PD readdirAll :: PD.DirStream - IO [String] readdirAll d = do dir - PD.readDirStream d if dir == then return [] else rest - readdirAll d return (dir:rest) Compiling with GHC 6.6.1 gives me the not-very-useful message Parse error in pattern, pointing to the i of if. I've tried all kinds of alternative indentations (including indenting the else more), bracketings etc, but nothing helps. Thanks David -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do/if/then/else confusion
On Nov 1, 2007, at 13:47 , David Carter wrote: else rest - readdirAll d You need another do here to use the - syntax. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do/if/then/else confusion
David Carter wrote:
readdirAll :: PD.DirStream - IO [String]
readdirAll d =
do dir - PD.readDirStream d
if dir ==
then return []
else rest - readdirAll d
return (dir:rest)
Compiling with GHC 6.6.1 gives me the not-very-useful message Parse
error in pattern, pointing to the i of if. I've tried all kinds of
You've worked out the answer, and that's fine. You also said later in
the thread that the error message isn't very good. (Which I agree with)
Perhaps it might help to understand why you do, in fact, get that
strange message. It might illuminate why it's quite so hard to get good
error messages in haskell :-( [*]
When you reach the i in if, ghc knows that you are in a do
expression. A do expression is a sequence of statements separated by
semicolons (or layout, standing in for semicolons). When we decode the
layout, everything indented further is part of the same statement. So
in particular, your code parses as
do {
dir - PD.readDirStream d ;
if dir == then return [] else rest - readdirAll d return (dir:rest);
}
The first statement in the do block is fine.
The second is the problem. Now statements are of two basic forms. They
either have binders, or not. They are either
foo - expr
or simply
expr
Since the second line contains the magic -, it must be the former. So
what you have is 'if dir == then return [] else rest' being the
'foo', i.e. the bit before the -.
Now what is *supposed* to come before - is a pattern (normally a
variable name, which is a simple case of a pattern). if is a keyword
which is not permitted to be a variable name or part of a pattern.
Hence parse error in pattern.
Not sure if that is at all edifying, but it was an interesting exercise
to write it...
Jules
* there are two reasons it's really hard to write a haskell compiler
with good error messages. (1) the layout rule. (2) the use of exotic
type system tricks like type classes to achieve elegant syntax. I don't
mean to say that the developers of haskell compilers shouldn't keep
trying though!
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Do you trust Wikipedia?
On Fri, 2007-10-19 at 02:45 +0200, [EMAIL PROTECTED] wrote: PR Stanley writes: One of the reasons I'm interested in Wikipedia and Wikibook is because you're more likely to find Latex source code used for typesetting the maths. Latex is the one and only 100% tool right now. A lot of publishers use Latex but try to get anything from them in electronic form. I don't understand you. WHAT YOU WANT? 1. Many articles in Wikipedia typeset math formulae as *images*, you don't really see the LaTeX sources. Some formulae are typed through plain HTML. 2. MOST journal publishers who recommend LaTeX give you the appropriate .cls files. Kluwer, Journal of Functional Programming, etc. Sometimes the attached manuals contain formulae. Whom did you ask, and what did you want? 3. LaTeX is NOT the one and only one. Texts which should be printed, OK, I format in LaTeX. Presentations on screen, my lectures, seminars, etc. I format in MathML, and I show using Mozilla, etc., standard navigator. Of course, making MathML by hand is like eating oysters with shells. I recommend then the script of Peter Jipsen http://www1.chapman.edu/~jipsen/mathml/asciimath.html which permits you to write your formulae intuitively, and fast. And reasonably well, although the comparison with LaTeX would be difficult. This is my problem with XML --- the syntax is so verbose, people are driven to *author* in anything but XML. TeX can be authored directly, by a real person, using a standard text editor. Infinitely superior to XML. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Do you trust Wikipedia?
Henning Thielemann [EMAIL PROTECTED] writes: Most proofs in mathematics use intuitive arguments, most proofs are not formalized enough in order to be checked by machines. Ok, this can be considered a deficiency of machine provers. But in the history there were famous proofs which turned out to be wrong. Remember the first proof of the four color theorem of Alfred Kempe (cited from, you guess it, wikipedia :-) http://en.wikipedia.org/wiki/Four_color_theorem ) Or remember the first trial of Andrew Wile to prove the Taniyama-Shimura-Weil conjecture for Fermat's last theorem. It is generally hard to show that a proof is incorrect if the statement is correct. You completely misunderstand the goal and nature of Wikipedia. The goal is not truth, but verifiability. It is not Wikipedia's job to determine whether a mathematical proof is correct, but merely if it is accepted by the mathematical community. Truth has absolutely nothing to do with it. Wikipedia is a source-based encyclopedia, and when executed properly, its articles will reflect the biases of its sources. This should be mainstream, learned opinion in the field. See http://en.wikipedia.org/wiki/WP:V -- Doug Quale ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Do you trust Wikipedia?
Paul Brown wrote: On 10/17/07, PR Stanley [EMAIL PROTECTED] wrote: Do you trust mathematical materials on Wikipedia? I trust most of them to not be wrong, but I don't trust them to be right. Mathematical concepts are bit like binary search -- getting the flavor right isn't that difficult, but being concise, complete, and correct is very difficult even for experts. In non-mathematics books that I've read (econometrics, operations research, etc.), some of the bits of exposition on fundamentals (multi-var calc, stats/probability, etc.) are not wrong but not quite right. For lay purposes, wikipedia is probably fine, and any resource *that people use* that makes an effort to educate and inform on mathematical concepts deserves some thanks and support. My $0.02. I'd probably agree with most of that. I read a fair bit of stuff on Wikipedia. Some articles are really quite interesting, some are far too vague to comprehend, some are just explained badly, and a fair few are near-empty stubs. It's pot luck. Do I trust the material to be correct? Well, let me put it this way: If I read something from Wikipedia that's wrong, what's the worst that could happen? It's not like I'm going to *use* this information for anything important, so... ;-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Do you trust Wikipedia?
On Fri, 19 Oct 2007, Jules Bean wrote: [EMAIL PROTECTED] wrote: *PLEASE*, show me untrustworthy Wikipedia pages. Any article on a disputed territory or open political dispute. Most articles on a controversial philosophy. Many articles on living people. Articles on controversal topics like HIV/AIDS, climate change, economics, generally things which are called conspiracy theory by enough people. You find many authors which forget good scientific style if the topic is presented in a way which contradicts to their view. Neutral point of view just means Biased view which is shared by enough people. Fortunately, articles on mathematics have several virtues which make them less likely to subject to the problems which plague the above. There is a notion of objective proof, Most proofs in mathematics use intuitive arguments, most proofs are not formalized enough in order to be checked by machines. Ok, this can be considered a deficiency of machine provers. But in the history there were famous proofs which turned out to be wrong. Remember the first proof of the four color theorem of Alfred Kempe (cited from, you guess it, wikipedia :-) http://en.wikipedia.org/wiki/Four_color_theorem ) Or remember the first trial of Andrew Wile to prove the Taniyama-Shimura-Weil conjecture for Fermat's last theorem. It is generally hard to show that a proof is incorrect if the statement is correct. there is a wide peer-reviewed literature which can be used as references, Do referees actually check every proof? there are a disproportionate number of wikipedians with mathematical ability to catch errors. Wikipedia contains the same abuse of notation as all the mathematical literature. I just like to recall the function f(x). Or see the German part of Wikipedia where people have decided to restrict the category Mathematical Function to functions with real and complex parameters and values. (http://de.wikipedia.org/wiki/Kategorie:Mathematische_Funktion) In conclusion I would not trust Wikipedia. But this holds for the rest of the world, too. Scientists must always have a basic stock of scepticism, especially for well known and widely accepted facts/believes. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
