Re: [Haskell-cafe] Software patents covered in GHC?

2011-06-20 Thread Erik de Castro Lopo
Manuel M T Chakravarty wrote:

> In fact, you are better of not to know.  Given that GHC (like all
> non-trivial software) surely infringes on some patents, the damages
> that a patent holder can sue you for are less if you do not know about
> the patents you are infringing on.  IIRC, a plaintiff can triple the
> charges if they can reasonably show that you have been aware of the
> patents that you are infringing on.  Nasty business!

ON the up side, the fact that GHC is Open Source software available
from a public repository and a lot of what is in GHC is published
in papers which are widely and freely available on the internet
means that stuf fthat was in GHC first can never be patented (or
at least can be successfully challenged when it is).

Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Opaque types vs automated instance deriving

2011-06-20 Thread Antoine Latter
On Mon, Jun 20, 2011 at 5:07 PM, Alexey Karakulov  wrote:
> Hi all,
> I encountered a problem when trying to
>
>> derive makeBinary ''DiffTime
>
> with help of derive package. The error was:
>
> Not in scope: data constructor `MkDiffTime'
>
> Which makes a sense, since it's not exported in Data.Time.Clock.
> I bypassed the problem (yes, I'm too lazy to write instances by hands) with
>
>> instance Binary UTCTime where
>>  put =
>> putGeneric
>>  get =
>> getGeneric
>
> But it must be less efficient (and more verbose) than compile-time deriving.
> If there was such a module like Data.Time.Clock.Internal, I could import it
> to get hidden constructors (and maybe I'll have to fork the library for this
> purpose).
>
> OTOH, is it possible to change the derive TH function so it can bypass
> module encapsulation mechanism and access un-exported things?
>

I would benchmark putGeneric/getGeneric against:

> put = put . toRational
> get = fromRational <$> get

It looks like that's what the safecopy package on Hackage uses.

Antoine

> ___
> 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] Haskell *interpreter* on iPad? (Scheme and Ocaml are there)

2011-06-20 Thread Manuel M T Chakravarty
And while we are dreaming, in an iOS port of GHCi (meaning GHCi runs on iOS and 
doesn't just generate code for it), it would be great to make bytecode 
persistent — ie, the bytecode that GHCi currently generates internally to 
interpret programs should be serialized to save and load it.  (Note that iOS 
apps are not allowed to generate binary code, so we wouldn't need the gcc tool 
chain etc, but just have a stripped down GHCi that generates bytecode only.  
All pre-compiled libraries that are part of the GHCi app can of course still be 
native code and load and interact with the interpreter as usual.)

Manuel


Don Stewart:
> Oh, Scheme is trivial to implement, when compared with Haskell. So
> people write it from scratch as a tutorial exercise.
> 
> Haskell isn't trivial to implement from scratch, so instead we port
> existing implementations mostly.
> 
> That means really, porting Hugs or GHC. And you've been pointed at examples.
> 
> I think people are clearly keen for this, now it is a small matter of
> programming talent and will.
> 
> -- Don
> 
> On Sat, Jun 18, 2011 at 3:03 PM, John Velman  wrote:
>> On Sat, Jun 18, 2011 at 10:44:01PM +0400, MigMit wrote:
>> 
>> Well, this is my point.  THERE ARE 3 SCHEME INTERPRETERS in the iPad app
>> store.
>> 
>> They run on factory iPads, not jailbroken.
>> 
>> The GUI for the gambitREPL  (Read, Evaluate, Print, Loop) is just like a
>> console.   Input a scheme expression.  CR. Answer appears, new prompt.
>> 
>> In haskell we need to allow for some way to input layout.  I don't recall
>> how Hugs handles this, if at all.
>> 
>> There are probably 5 or 10 people out there who want to learn functional
>> programming, and they are studying Scheme on their iPads.  Or Ocaml.
>> 
>> I don't forsee doing production programming ON THE IPAD, but experimenting,
>> testing some functions, and, by the way, learning Haskell.
>> 
>> While I'm fantasizing, something like Hugs or ghci with SOE would really be
>> neat.
>> 
>> Sorry for shouting  :-)
>> 
>> John Velman
>> 
>>> Well, Haskell is fun, isn't it? And that's what iPhone is perfect for: fun.
>>> 
>>> Back when I had iPod Touch 1G (jailbroken, of course), I used to run Hugs 
>>> on it. Now I would love to see a Haskell interpreter in the App Store -- 
>>> which, by the way, is possible; as there are Scheme interpreters there, why 
>>> not Haskell?
>>> 
>>> Отправлено с iPhone
>>> 
>>> Jun 18, 2011, в 22:27, Jack Henahan  написал(а):
>>> 
 I suppose you could make a GUI, by why? Given that you'll have to be 
 working on a jailbroken device, anyway, one could just as well use one of 
 the numerous terminal emulators now floating around for jailbroken iOS. 
 That said, the idea of people writing Haskell on phones and iPads and so 
 on makes me just a little bit grinny.
 
 On Jun 18, 2011, at 2:17 PM, Alexander Solla wrote:
 
> 
> 
> On Sat, Jun 18, 2011 at 10:46 AM, John Velman  wrote:
> To further emphasize, I'd like to type in (or paste in) Haskell code and
> have it executed on the iPad.  To reiterate:  Something like Hugs, or ghci
> on the iPad.
> 
> Since the iPhone OS is pretty much OS X for ARM, and GHC apparently now 
> supports cross-compilation, you can compile GHC for iOS.  I guess you 
> could cross compile Hugs with GCC.  Doing so probably isn't trivial, but 
> it should be straightforward.
> 
> I bet you could even use Xcode to make a graphical user interface to GHCi.
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
 
 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe
>> 
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>> 
> 
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Software patents covered in GHC?

2011-06-20 Thread Manuel M T Chakravarty
austin seipp:
> *sigh* CC'ing to the rest of haskell-cafe for completeness. I need to
> change 'reply all' to a default in my email I guess.
> 
> On Mon, Jun 20, 2011 at 12:19 PM, austin seipp  wrote:
>> Hello,
>> 
>> Realistically, there probably is. Considering everything down to
>> linked lists are patented by the USPO, I'd be willing to bet (at least
>> a dollar or two) that there are many patents out there that apply to
>> the code used in GHC. I don't know if you could say anything different
>> about *any* nontrivial software, to be quite honest.
>> 
>> IANAL however, so I won't attempt to claim in what countries these
>> patents apply, nor could I cite you patent numbers (legalese being
>> terse and software patents so seemingly open to interpretation
>> sometimes, it would be hard to narrow down anyway I think.)

In fact, you are better of not to know.  Given that GHC (like all non-trivial 
software) surely infringes on some patents, the damages that a patent holder 
can sue you for are less if you do not know about the patents you are 
infringing on.  IIRC, a plaintiff can triple the charges if they can reasonably 
show that you have been aware of the patents that you are infringing on.  Nasty 
business!

Manuel

>> On Mon, Jun 20, 2011 at 12:10 PM, Shakthi Kannan  
>> wrote:
>>> Hi,
>>> 
>>> I would like to know if there are any software algorithms used in the
>>> Glasgow Haskell Compiler that have been patented? If yes, in which
>>> countries do they apply?
>>> 
>>> Just curious to know.
>>> 
>>> SK
>>> 
>>> --
>>> Shakthi Kannan
>>> http://www.shakthimaan.com
>>> 
>>> ___
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe@haskell.org
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>> 
>> 
>> 
>> 
>> --
>> Regards,
>> Austin
>> 
> 
> 
> 
> -- 
> Regards,
> Austin
> 
> ___
> 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] Job position for haskell/clojure dev. in San Dimas, CA

2011-06-20 Thread Vagif Verdi
Sorry, forgot to mention, and i already got questions about it. No
worker visa sponsorship, no relocation from abroad. US only.


On Jun 20, 2:39 pm, vagif.ve...@gmail.com wrote:
> Anyone interested in full time employment working with haskell and
> clojure in San Dimas, CA (local job only, NO telecommute) please let
> me know.
>
> Regards,
> Vagif Verdi
>
> ___
> Haskell-Cafe mailing list
> Haskell-C...@haskell.orghttp://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] AusHac2011 - The Australasian Haskell Hackathon - July 8-10

2011-06-20 Thread Alex Mason
It's almost that time of year again!

Next month is the second annual AusHac event, at UNSW in Sydney, and you are
invited! But if you want to come, we need to hear from you soon, as we need to
organise access to the university network for you.

If you're an Australian Haskell hacker, enthusiast, newbie or professional, we
would love to see you there. Below is the announcement, if you have any
questions, please just hit reply, and Ivan or I will get back to you.

We would absolutely love to see you there if you can make it, we'd love for
this year to be even more awesome than last year.

-- Alex Mason

--

  Attention all Australasian Haskellers! 

After last year’s fantastic turnout for the first Australian Haskell Hackathon
- AusHac 2010 - we’ve decided to organise another. As it’s rather boring to
have a Hackathon with only two people, we encourage and welcome anyone
interested in Haskell in Australia, New Zealand and surrounding areas (or
further afield if you want!) to come and join us. Last year we had more than
25 Haskellers come from Brisbane, Canberra, Melbourne, Sydney and even two
from as far away as New Zealand.

AusHac 2011 will be held from Friday July 8th until Sunday July 10th, again at
UNSW’s Computer Science building in Sydney. There’s no need to come for the
entire weekend, just for whenever you’re able to.

Last year, people worked on several projects including:

 • Accelerate: a high performance library for array computations using various
backends (CUDA, LLVM, etc.) being written at UNSW.

 • Leksah: the Haskell IDE written in Haskell

 • DDC: the compiler for the Haskell-like language Disciple, which has strict
evaluation by default, region, effect and closure typing and other interesting
language features.

 • Hubris: the Haskell/Ruby bridge for calling Haskell from Ruby and
vice-versa.

 • haskell-mpi: bindings to MPI, the message passing interface used frequently
on high performance super-computers to allow programs to run on many nodes in
parallel with easy communication.

 • There was even some work on LLVM to produce HTML output showing register
allocations (as an aid to those writing new code generators etc.), which has
now been included upstream. This work did not use Haskell, but it did happen
at AusHac 2010.

 • And much more!

This is a great chance to collaborate with others and get feedback on your
work, while having heaps of fun and meeting other Haskellers, to verify they
do actually exist! And don’t worry if you can’t think of a project to work on;
just come along and pitch in with whatever strikes your fancy!

If you’re interested in coming and have a project you’d like to work on, check
out the wikipage http://www.haskell.org/haskellwiki/AusHac2011 where you can
add your project ideas, or just take a look and see what others will be
working on that you can help out with.

People of all skill levels are welcome, from complete beginners to Oleg-level
sage masters. We’re more than happy to help you learn Haskell if you’re just
starting out or help you solve that little niggly bit in your code.

If you’re interested in coming along, fill out our registration form
http://axman6.wufoo.com/forms/aushac-2011-sign-up/. Registration is required
so we know numbers and for you to get access to the university Wifi. Even if
you’re not sure, fill it in to express your interest, obligation free. We’d
rather know we have room for too many people than not enough.

So come along! And if for some reason you don’t enjoy yourself, registration
comes with a money-back guarantee!

Hope to see you there,

-- Alex Mason and Ivan Miljenovic, AusHac organisers

--
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Text report tools?

2011-06-20 Thread Ivan Lazar Miljenovic
On 21 June 2011 04:27, Dmitri O.Kondratiev  wrote:
> Hi,
> I am looking for an easy way to generate text reports.
> For starters I need a very simple report that may contain:
> - Some headers
> - Lists of text strings where each string can include instances of basic
> Haskell types.  Each string should be printed on a separate line (terminated
> with LF).
>
> Do I understand this right that for such simple reports (as above)
> Text.Printf is the main tool?
>
> As a next step, a simple report engine controlled by templates or DSL would
> help.

If you are wanting to output to HTML or something, I suggest using
pandoc as a library or else one of the HTML templating libraries.  If
it's more of a specific format, maybe use a pretty-printing library
directly?

-- 
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] Opaque types vs automated instance deriving

2011-06-20 Thread Alexey Karakulov
Hi all,
I encountered a problem when trying to

> derive makeBinary ''DiffTime

with help of *derive* package. The error was:

Not in scope: data constructor `MkDiffTime'

Which makes a sense, since it's not exported in Data.Time.Clock.
I bypassed the problem (yes, I'm too lazy to write instances by hands) with

> instance Binary UTCTime where
>  put =
putGeneric
>  get =
getGeneric

But it must be less efficient (and more verbose) than compile-time deriving.
If there was such a module like Data.Time.Clock.Internal, I could import it
to get hidden constructors (and maybe I'll have to fork the library for this
purpose).

OTOH, is it possible to change the derive TH function so it can bypass
module encapsulation mechanism and access un-exported things?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Job position for haskell/clojure dev. in San Dimas, CA

2011-06-20 Thread vagif . verdi
Anyone interested in full time employment working with haskell and 
clojure in San Dimas, CA (local job only, NO telecommute) please let 
me know.

Regards,
Vagif Verdi
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Probably type checker error.

2011-06-20 Thread Miguel Mitrofanov
Defaulting. Inferred type of "r" is still polymorphic – r :: E ins outs – but 
type of "x", "nextSum" and "currentSum" is defaulted to "Integer". Try adding 
"default ()" to your program, and you'll see the same error again. Or, if you 
enable NoMonomorphismRestriction (or MonoLocalBinds – I didn't know it works in 
6.12 also), you'll see that the type of "nextSum" etc. is derived as "Num a => 
a".

On 20 Jun 2011, at 17:02, Serguey Zefirov wrote:

> The fact is that (Num a) context works and (ToWires a, Num a) context
> doesn't. At least in 6.12.1.
> 
> This still looks to me like a bug.
> 
> 2011/6/19 Miguel Mitrofanov :
>> Seems like let-generalization is at work here.
>> 
>> Types of all values in the "where" section are inferred basically as if they 
>> are declared at the top level. Therefore, inheritance fails without 
>> NoMonomorphismRestriction.
>> 
>> There is a proposal (from Big Simon) to remove let-generalization: 
>> http://research.microsoft.com/en-us/um/people/simonpj/papers/constraints/let-gen.pdf
>> 
>> On 19 Jun 2011, at 18:26, Serguey Zefirov wrote:
>> 
>>> Right now I write a quite heavy transformation of Haskell source code
>>> and found some strange behaviour of typechecker.
>>> 
>>> Some prerequisites:
>>> -- dummy class. My own class is much bigger, but I
>>> -- could reproduce that behaviour with that class.
>>> class ToWires a
>>> 
>>> -- a type with phantom type arguments.
>>> data E ins outs = E
>>> 
>>> -- a function that relates E and its inputs.
>>> projectInsType :: E ins outs -> ins
>>> projectInsType = error "projectInsType gets evaluated."
>>> 
>>> -- "register" function.
>>> register :: a -> a -> a
>>> register def a = def
>>> 
>>> -- a simple addition.
>>> add2 :: (ToWires a, Num a) => (a,a) -> a
>>> add2 (a,b) = a+b
>>> 
>>> 
>>> First I have a function:
>>> func :: (ToWires a, Num a) => Maybe a -> a
>>> func mbA = currentSum
>>>   where
>>>   x = case mbA of
>>>   Just a -> a
>>>   Nothing -> 0
>>>   nextSum = add2 (x,currentSum)
>>>   currentSum = register 0 nextSum
>>> 
>>> It typechecks and works just fine after some transformation.
>>> 
>>> The transformation I work on transform code into something like that:
>>> func_E :: (ToWires a, Num a) => E (Maybe a) a
>>> func_E = r
>>>   where
>>>   r = E
>>>   -- here we relate mbA and r.
>>>   mbA = projectInsType r
>>>   x = case mbA of
>>>   Just a -> a
>>>   Nothing -> 0
>>>   nextSum = add2 (x,currentSum)
>>>   currentSum = register 0 nextSum
>>> 
>>> Note the absence of input of func in transformed func_E. I relate mbA
>>> with it's proper type using binding "mbA = projectInsType r".
>>> 
>>> Then suddently ghc loses all of the context associated with mbA. And
>>> find type error at the calling of add2.
>>> 
>>> If I drop ToWires from contexts of func_E and add2 types, all works
>>> fine. If I change add2 to simple addition (x + currentSum), all works
>>> fine.
>>> 
>>> Full source code is in attachment.
>>> 
>>> I found it using ghc 6.12.1. I asked colleagues, they told me that the
>>> same error manifests itself in ghc 7.0.3.
>>> 
>>> Should I fill a bug report or maybe I misunderstood something?
>>> ___
>>> 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] Probably type checker error.

2011-06-20 Thread Serguey Zefirov
Thank you very much. I'll try that too.

2011/6/20 David Menendez :
> GHC 6.12 introduces MonoLocalBinds, which disables polymorphic values
> in let statements.
>
> Your original code works for me if I use -XNoMonoLocalBinds
> -XNoMonomorphismRestriction.
>
> On Mon, Jun 20, 2011 at 9:02 AM, Serguey Zefirov  wrote:
>> The fact is that (Num a) context works and (ToWires a, Num a) context
>> doesn't. At least in 6.12.1.
>>
>> This still looks to me like a bug.
>>
>> 2011/6/19 Miguel Mitrofanov :
>>> Seems like let-generalization is at work here.
>>>
>>> Types of all values in the "where" section are inferred basically as if 
>>> they are declared at the top level. Therefore, inheritance fails without 
>>> NoMonomorphismRestriction.
>>>
>>> There is a proposal (from Big Simon) to remove let-generalization: 
>>> http://research.microsoft.com/en-us/um/people/simonpj/papers/constraints/let-gen.pdf
>>>
>>> On 19 Jun 2011, at 18:26, Serguey Zefirov wrote:
>>>
 Right now I write a quite heavy transformation of Haskell source code
 and found some strange behaviour of typechecker.

 Some prerequisites:
 -- dummy class. My own class is much bigger, but I
 -- could reproduce that behaviour with that class.
 class ToWires a

 -- a type with phantom type arguments.
 data E ins outs = E

 -- a function that relates E and its inputs.
 projectInsType :: E ins outs -> ins
 projectInsType = error "projectInsType gets evaluated."

 -- "register" function.
 register :: a -> a -> a
 register def a = def

 -- a simple addition.
 add2 :: (ToWires a, Num a) => (a,a) -> a
 add2 (a,b) = a+b


 First I have a function:
 func :: (ToWires a, Num a) => Maybe a -> a
 func mbA = currentSum
       where
               x = case mbA of
                       Just a -> a
                       Nothing -> 0
               nextSum = add2 (x,currentSum)
               currentSum = register 0 nextSum

 It typechecks and works just fine after some transformation.

 The transformation I work on transform code into something like that:
 func_E :: (ToWires a, Num a) => E (Maybe a) a
 func_E = r
       where
               r = E
               -- here we relate mbA and r.
               mbA = projectInsType r
               x = case mbA of
                       Just a -> a
                       Nothing -> 0
               nextSum = add2 (x,currentSum)
               currentSum = register 0 nextSum

 Note the absence of input of func in transformed func_E. I relate mbA
 with it's proper type using binding "mbA = projectInsType r".

 Then suddently ghc loses all of the context associated with mbA. And
 find type error at the calling of add2.

 If I drop ToWires from contexts of func_E and add2 types, all works
 fine. If I change add2 to simple addition (x + currentSum), all works
 fine.

 Full source code is in attachment.

 I found it using ghc 6.12.1. I asked colleagues, they told me that the
 same error manifests itself in ghc 7.0.3.

 Should I fill a bug report or maybe I misunderstood something?
 ___
 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
>>
>
>
>
> --
> Dave Menendez 
> 
>

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] ANNOUNCEMENT: TinyLaunchbury 1.0.1

2011-06-20 Thread Elliot Stern
Sankel Software is pleased to announce the release of TinyLaunchbury 1.0.1
[1], a small implementation of John Launchbury's natural semantics for
call-by-need.  We hope that is is useful in helping to understand how
call-by-need works.

There is also a new blog post[2], explaining the semantics, the code and why
the semantics are useful to understand.

Elliot Stern
Sankel Software

[1] http://hackage.haskell.org/package/TinyLaunchbury
[2] http://netsuperbrain.com/blog/posts/haskells-evaluation-isnt-magic/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Conditional IO ?

2011-06-20 Thread David Barbour
On Mon, Jun 20, 2011 at 1:33 AM, Dmitri O.Kondratiev wrote:

> Thanks! Everything works, and 'when' is really nice.
> ( I still have only basic monad  knowledge, need more time to spend on
> existing libraries)
>
>
I heavily use 'when' and 'unless'.  ('unless b x' is the same as 'when (not
b) x'.)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Text report tools?

2011-06-20 Thread Gregory Collins
Try http://hackage.haskell.org/package/HStringTemplate.

G

On Mon, Jun 20, 2011 at 2:27 PM, Dmitri O.Kondratiev  wrote:
> Hi,
> I am looking for an easy way to generate text reports.
> For starters I need a very simple report that may contain:
> - Some headers
> - Lists of text strings where each string can include instances of basic
> Haskell types.  Each string should be printed on a separate line (terminated
> with LF).
>
> Do I understand this right that for such simple reports (as above)
> Text.Printf is the main tool?
>
> As a next step, a simple report engine controlled by templates or DSL would
> help.
>
> Thanks!
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>



-- 
Gregory Collins 

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Text report tools?

2011-06-20 Thread Dmitri O.Kondratiev
Hi,
I am looking for an easy way to generate text reports.
For starters I need a very simple report that may contain:
- Some headers
- Lists of text strings where each string can include instances of basic
Haskell types.  Each string should be printed on a separate line (terminated
with LF).

Do I understand this right that for such simple reports (as above)
Text.Printf is the main tool?

As a next step, a simple report engine controlled by templates or DSL would
help.

Thanks!
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Conditional IO ?

2011-06-20 Thread Henk-Jan van Tuyl
On Mon, 20 Jun 2011 10:33:14 +0200, Dmitri O.Kondratiev  
 wrote:



Thanks! Everything works, and 'when' is really nice.
( I still have only basic monad  knowledge, need more time to spend on
existing libraries)



See "A tour of the Haskell Monad functions"[0].

Regards,
Henk-Jan van Tuyl

[0] http://members.chello.nl/hjgtuyl/tourdemonad.html


--
http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
--

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Software patents covered in GHC?

2011-06-20 Thread austin seipp
*sigh* CC'ing to the rest of haskell-cafe for completeness. I need to
change 'reply all' to a default in my email I guess.

On Mon, Jun 20, 2011 at 12:19 PM, austin seipp  wrote:
> Hello,
>
> Realistically, there probably is. Considering everything down to
> linked lists are patented by the USPO, I'd be willing to bet (at least
> a dollar or two) that there are many patents out there that apply to
> the code used in GHC. I don't know if you could say anything different
> about *any* nontrivial software, to be quite honest.
>
> IANAL however, so I won't attempt to claim in what countries these
> patents apply, nor could I cite you patent numbers (legalese being
> terse and software patents so seemingly open to interpretation
> sometimes, it would be hard to narrow down anyway I think.)
>
> On Mon, Jun 20, 2011 at 12:10 PM, Shakthi Kannan  
> wrote:
>> Hi,
>>
>> I would like to know if there are any software algorithms used in the
>> Glasgow Haskell Compiler that have been patented? If yes, in which
>> countries do they apply?
>>
>> Just curious to know.
>>
>> SK
>>
>> --
>> Shakthi Kannan
>> http://www.shakthimaan.com
>>
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
>
>
> --
> Regards,
> Austin
>



-- 
Regards,
Austin

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Software patents covered in GHC?

2011-06-20 Thread Shakthi Kannan
Hi,

I would like to know if there are any software algorithms used in the
Glasgow Haskell Compiler that have been patented? If yes, in which
countries do they apply?

Just curious to know.

SK

-- 
Shakthi Kannan
http://www.shakthimaan.com

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Probably type checker error.

2011-06-20 Thread David Menendez
GHC 6.12 introduces MonoLocalBinds, which disables polymorphic values
in let statements.

Your original code works for me if I use -XNoMonoLocalBinds
-XNoMonomorphismRestriction.

On Mon, Jun 20, 2011 at 9:02 AM, Serguey Zefirov  wrote:
> The fact is that (Num a) context works and (ToWires a, Num a) context
> doesn't. At least in 6.12.1.
>
> This still looks to me like a bug.
>
> 2011/6/19 Miguel Mitrofanov :
>> Seems like let-generalization is at work here.
>>
>> Types of all values in the "where" section are inferred basically as if they 
>> are declared at the top level. Therefore, inheritance fails without 
>> NoMonomorphismRestriction.
>>
>> There is a proposal (from Big Simon) to remove let-generalization: 
>> http://research.microsoft.com/en-us/um/people/simonpj/papers/constraints/let-gen.pdf
>>
>> On 19 Jun 2011, at 18:26, Serguey Zefirov wrote:
>>
>>> Right now I write a quite heavy transformation of Haskell source code
>>> and found some strange behaviour of typechecker.
>>>
>>> Some prerequisites:
>>> -- dummy class. My own class is much bigger, but I
>>> -- could reproduce that behaviour with that class.
>>> class ToWires a
>>>
>>> -- a type with phantom type arguments.
>>> data E ins outs = E
>>>
>>> -- a function that relates E and its inputs.
>>> projectInsType :: E ins outs -> ins
>>> projectInsType = error "projectInsType gets evaluated."
>>>
>>> -- "register" function.
>>> register :: a -> a -> a
>>> register def a = def
>>>
>>> -- a simple addition.
>>> add2 :: (ToWires a, Num a) => (a,a) -> a
>>> add2 (a,b) = a+b
>>>
>>>
>>> First I have a function:
>>> func :: (ToWires a, Num a) => Maybe a -> a
>>> func mbA = currentSum
>>>       where
>>>               x = case mbA of
>>>                       Just a -> a
>>>                       Nothing -> 0
>>>               nextSum = add2 (x,currentSum)
>>>               currentSum = register 0 nextSum
>>>
>>> It typechecks and works just fine after some transformation.
>>>
>>> The transformation I work on transform code into something like that:
>>> func_E :: (ToWires a, Num a) => E (Maybe a) a
>>> func_E = r
>>>       where
>>>               r = E
>>>               -- here we relate mbA and r.
>>>               mbA = projectInsType r
>>>               x = case mbA of
>>>                       Just a -> a
>>>                       Nothing -> 0
>>>               nextSum = add2 (x,currentSum)
>>>               currentSum = register 0 nextSum
>>>
>>> Note the absence of input of func in transformed func_E. I relate mbA
>>> with it's proper type using binding "mbA = projectInsType r".
>>>
>>> Then suddently ghc loses all of the context associated with mbA. And
>>> find type error at the calling of add2.
>>>
>>> If I drop ToWires from contexts of func_E and add2 types, all works
>>> fine. If I change add2 to simple addition (x + currentSum), all works
>>> fine.
>>>
>>> Full source code is in attachment.
>>>
>>> I found it using ghc 6.12.1. I asked colleagues, they told me that the
>>> same error manifests itself in ghc 7.0.3.
>>>
>>> Should I fill a bug report or maybe I misunderstood something?
>>> ___
>>> 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
>



-- 
Dave Menendez 


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Text.CSV questions

2011-06-20 Thread Dmitri O.Kondratiev
On Mon, Jun 20, 2011 at 7:30 PM, Alejandro Serrano Mena
wrote:

> Maybe you can directly distinguish if the parser returned an error (Left)
> or not (Right), instead of using lefts and rights:
>
> import Text.CSV
> import Data.Either
> import System
> import Data.List
>
> main = do
>  [inpFileName] <- getArgs
>  putStrLn ("Parsing "++inpFileName++"...")
>  result <- parseCSVFromFile inpFileName
>  case result of
>Left error -> do print "Parse error: "
>  print error
>Right csv -> print csvL
>  putStrLn "All done."
>
>
Yes, you right, this is better, then printing empty error list.



> 2011/6/17 Dmitri O.Kondratiev 
>
>>
>>
>> On Fri, Jun 17, 2011 at 1:04 PM, Vincent Hanquez  wrote:
>>
>>> On 06/17/2011 10:00 AM, Dmitri O.Kondratiev wrote:
>>>
 Hi,
 I try to parse csv file with Text.CSV, like this:

 import Text.CSV
 import System

 main = do
 [inpFileName] <- getArgs
 putStrLn ("Parsing "++inpFileName++"...")
 let result = parseCSVFromFile inpFileName
 print result


 === As a result I get:

  No instance for (Show
(IO (Either Text.Parsec.Error.ParseError CSV)))
   arising from a use of `print'
  Possible fix:
   add an instance declaration for
   (Show (IO (Either Text.Parsec.Error.ParseError CSV)))

 === Question:
 How to add a Show instance for "(IO (Either Text.Parsec.Error.ParseError
 CSV)))" ?

>>> Hi Dmitri,
>>>
>>> you don't add a show instance for IO, but you "unwrap" the IO Monad first
>>> and then show the result.
>>>
>>> let result = parseCSVFromFile inpFileName
>>>
>>> should be:
>>>
>>> result <- parseCSVFromFile inpFileName
>>>
>>> --
>>> Vincent
>>>
>>
>> Thanks everybody!  This is how I solved it:
>>
>> import Text.CSV
>> import Data.Either
>> import System
>> import Data.List
>>
>>
>> main = do
>>  [inpFileName] <- getArgs
>>  putStrLn ("Parsing "++inpFileName++"...")
>>  result <- parseCSVFromFile inpFileName
>>  let errors = lefts [result]
>>  let csvL = rights [result]
>>  print "CSV list"
>>  print csvL
>>  print "Errors"
>>  print errors
>>  putStrLn "All done."
>>
>>
>> ___
>> 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] Data Flow Programming in FP

2011-06-20 Thread David Barbour
On Mon, Jun 20, 2011 at 7:45 AM, Richard Senington wrote:

> I have recently become interested in Dataflow programming and how it
> related to functional languages.
> I am wondering if the community has any advice on reading matter or other
> directions to look at.
>
> So far I have been looking through the FRP libraries, using Haskell
> functions with lazy lists for co-routines and
> the Essence of Dataflow Programming by Uustalu and Vene where they propose
> using co-monads.
>
> It looks as though Iteratees are also relevant but I have not got round to
> looking at them in detail yet.
>
> Have I missed anything?
>

Arrows are a useful model for dataflow programming. But several FRP models
are arrowized, so you might already have observed this. Which FRP models
have you looked at? (there are several)

I'm developing a model for reactive dataflows in open distributed systems,
called reactive demand programming (RDP). It's basically distributed FRP
with carefully constrained side-effects and signals that model disruption.
The effects model enforces spatial idempotence and commutativity, which
allows developers to perform refactoring and abstraction similar to that in
a pure functional model. That signals model disruption allows 'open'
composition and extension (e.g. runtime plugins). RDP is more composable
than FRP because client-server relationships can be captured as regular RDP
behaviors.

RDP isn't ready for release, yet, but you can read a bit more at my blog:

[1] http://awelonblue.wordpress.com/2011/05/21/comparing-frp-to-rdp/

Regards,

David Barbour
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Text.CSV questions

2011-06-20 Thread Alejandro Serrano Mena
Maybe you can directly distinguish if the parser returned an error (Left) or
not (Right), instead of using lefts and rights:

import Text.CSV
import Data.Either
import System
import Data.List

main = do
 [inpFileName] <- getArgs
 putStrLn ("Parsing "++inpFileName++"...")
 result <- parseCSVFromFile inpFileName
 case result of
   Left error -> do print "Parse error: "
 print error
   Right csv -> print csvL
 putStrLn "All done."

2011/6/17 Dmitri O.Kondratiev 

>
>
> On Fri, Jun 17, 2011 at 1:04 PM, Vincent Hanquez  wrote:
>
>> On 06/17/2011 10:00 AM, Dmitri O.Kondratiev wrote:
>>
>>> Hi,
>>> I try to parse csv file with Text.CSV, like this:
>>>
>>> import Text.CSV
>>> import System
>>>
>>> main = do
>>> [inpFileName] <- getArgs
>>> putStrLn ("Parsing "++inpFileName++"...")
>>> let result = parseCSVFromFile inpFileName
>>> print result
>>>
>>>
>>> === As a result I get:
>>>
>>>  No instance for (Show
>>>(IO (Either Text.Parsec.Error.ParseError CSV)))
>>>   arising from a use of `print'
>>>  Possible fix:
>>>   add an instance declaration for
>>>   (Show (IO (Either Text.Parsec.Error.ParseError CSV)))
>>>
>>> === Question:
>>> How to add a Show instance for "(IO (Either Text.Parsec.Error.ParseError
>>> CSV)))" ?
>>>
>> Hi Dmitri,
>>
>> you don't add a show instance for IO, but you "unwrap" the IO Monad first
>> and then show the result.
>>
>> let result = parseCSVFromFile inpFileName
>>
>> should be:
>>
>> result <- parseCSVFromFile inpFileName
>>
>> --
>> Vincent
>>
>
> Thanks everybody!  This is how I solved it:
>
> import Text.CSV
> import Data.Either
> import System
> import Data.List
>
>
> main = do
>  [inpFileName] <- getArgs
>  putStrLn ("Parsing "++inpFileName++"...")
>  result <- parseCSVFromFile inpFileName
>  let errors = lefts [result]
>  let csvL = rights [result]
>  print "CSV list"
>  print csvL
>  print "Errors"
>  print errors
>  putStrLn "All done."
>
>
> ___
> 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] Data Flow Programming in FP

2011-06-20 Thread Richard Senington

Hi all,

I have recently become interested in Dataflow programming and how it 
related to functional languages.
I am wondering if the community has any advice on reading matter or 
other directions to look at.


So far I have been looking through the FRP libraries, using Haskell 
functions with lazy lists for co-routines and
the Essence of Dataflow Programming by Uustalu and Vene where they 
propose using co-monads.


It looks as though Iteratees are also relevant but I have not got round 
to looking at them in detail yet.


Have I missed anything?

Regards

RS

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Probably type checker error.

2011-06-20 Thread Serguey Zefirov
The fact is that (Num a) context works and (ToWires a, Num a) context
doesn't. At least in 6.12.1.

This still looks to me like a bug.

2011/6/19 Miguel Mitrofanov :
> Seems like let-generalization is at work here.
>
> Types of all values in the "where" section are inferred basically as if they 
> are declared at the top level. Therefore, inheritance fails without 
> NoMonomorphismRestriction.
>
> There is a proposal (from Big Simon) to remove let-generalization: 
> http://research.microsoft.com/en-us/um/people/simonpj/papers/constraints/let-gen.pdf
>
> On 19 Jun 2011, at 18:26, Serguey Zefirov wrote:
>
>> Right now I write a quite heavy transformation of Haskell source code
>> and found some strange behaviour of typechecker.
>>
>> Some prerequisites:
>> -- dummy class. My own class is much bigger, but I
>> -- could reproduce that behaviour with that class.
>> class ToWires a
>>
>> -- a type with phantom type arguments.
>> data E ins outs = E
>>
>> -- a function that relates E and its inputs.
>> projectInsType :: E ins outs -> ins
>> projectInsType = error "projectInsType gets evaluated."
>>
>> -- "register" function.
>> register :: a -> a -> a
>> register def a = def
>>
>> -- a simple addition.
>> add2 :: (ToWires a, Num a) => (a,a) -> a
>> add2 (a,b) = a+b
>>
>>
>> First I have a function:
>> func :: (ToWires a, Num a) => Maybe a -> a
>> func mbA = currentSum
>>       where
>>               x = case mbA of
>>                       Just a -> a
>>                       Nothing -> 0
>>               nextSum = add2 (x,currentSum)
>>               currentSum = register 0 nextSum
>>
>> It typechecks and works just fine after some transformation.
>>
>> The transformation I work on transform code into something like that:
>> func_E :: (ToWires a, Num a) => E (Maybe a) a
>> func_E = r
>>       where
>>               r = E
>>               -- here we relate mbA and r.
>>               mbA = projectInsType r
>>               x = case mbA of
>>                       Just a -> a
>>                       Nothing -> 0
>>               nextSum = add2 (x,currentSum)
>>               currentSum = register 0 nextSum
>>
>> Note the absence of input of func in transformed func_E. I relate mbA
>> with it's proper type using binding "mbA = projectInsType r".
>>
>> Then suddently ghc loses all of the context associated with mbA. And
>> find type error at the calling of add2.
>>
>> If I drop ToWires from contexts of func_E and add2 types, all works
>> fine. If I change add2 to simple addition (x + currentSum), all works
>> fine.
>>
>> Full source code is in attachment.
>>
>> I found it using ghc 6.12.1. I asked colleagues, they told me that the
>> same error manifests itself in ghc 7.0.3.
>>
>> Should I fill a bug report or maybe I misunderstood something?
>> ___
>> 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] Probably type checker error.

2011-06-20 Thread MigMit
Yeah, seems to work too.

Отправлено с iPhone

Jun 20, 2011, в 10:55, "Corey O'Connor"  написал(а):

> Not just a proposal any more. :-) GHC 7.0 does not generalize local let 
> bindings in some situations. See here for information: 
> http://hackage.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7
>  
> There is a proposal (from Big Simon) to remove let-generalization: 
> http://research.microsoft.com/en-us/um/people/simonpj/papers/constraints/let-gen.pdf
> 
> On 19 Jun 2011, at 18:26, Serguey Zefirov wrote:
> 
> > Right now I write a quite heavy transformation of Haskell source code
> > and found some strange behaviour of typechecker.
> >
> > Some prerequisites:
> > -- dummy class. My own class is much bigger, but I
> > -- could reproduce that behaviour with that class.
> > class ToWires a
> >
> > -- a type with phantom type arguments.
> > data E ins outs = E
> >
> > -- a function that relates E and its inputs.
> > projectInsType :: E ins outs -> ins
> > projectInsType = error "projectInsType gets evaluated."
> >
> > -- "register" function.
> > register :: a -> a -> a
> > register def a = def
> >
> > -- a simple addition.
> > add2 :: (ToWires a, Num a) => (a,a) -> a
> > add2 (a,b) = a+b
> >
> >
> > First I have a function:
> > func :: (ToWires a, Num a) => Maybe a -> a
> > func mbA = currentSum
> >   where
> >   x = case mbA of
> >   Just a -> a
> >   Nothing -> 0
> >   nextSum = add2 (x,currentSum)
> >   currentSum = register 0 nextSum
> >
> > It typechecks and works just fine after some transformation.
> >
> > The transformation I work on transform code into something like that:
> > func_E :: (ToWires a, Num a) => E (Maybe a) a
> > func_E = r
> >   where
> >   r = E
> >   -- here we relate mbA and r.
> >   mbA = projectInsType r
> >   x = case mbA of
> >   Just a -> a
> >   Nothing -> 0
> >   nextSum = add2 (x,currentSum)
> >   currentSum = register 0 nextSum
> >
> > Note the absence of input of func in transformed func_E. I relate mbA
> > with it's proper type using binding "mbA = projectInsType r".
> >
> > Then suddently ghc loses all of the context associated with mbA. And
> > find type error at the calling of add2.
> >
> > If I drop ToWires from contexts of func_E and add2 types, all works
> > fine. If I change add2 to simple addition (x + currentSum), all works
> > fine.
> >
> > Full source code is in attachment.
> >
> > I found it using ghc 6.12.1. I asked colleagues, they told me that the
> > same error manifests itself in ghc 7.0.3.
> >
> > Should I fill a bug report or maybe I misunderstood something?
> > ___
> > 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] Conditional IO ?

2011-06-20 Thread Dmitri O.Kondratiev
Thanks! Everything works, and 'when' is really nice.
( I still have only basic monad  knowledge, need more time to spend on
existing libraries)

On Mon, Jun 20, 2011 at 12:14 PM, Lyndon Maydwell wrote:

> Your errors branch has the type
>
> writeFile "parse-errors.txt" (show errors) :: IO ()
>
> This means that your otherwise branch should have the same type.
>
> You can use the return function that has the type
>
> return :: Monad m => a -> m a
>
> specialised to m = IO
>
> in conjunction with the value
>
> () :: ()
>
> giving
>
> return () :: IO ()
>
> There is also the when function that eliminates the else case for
> conditional IO:
>
> http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control-Monad.html#v:when
>
> On Mon, Jun 20, 2011 at 4:00 PM, Dmitri O.Kondratiev 
> wrote:
> > Hi,
> > What is right way to do conditional IO?
> > For example, I need to write to file errors only in case they exist,
> > otherwise my function should do nothing:
> >
> > handleParseErrors errors
> >   | (not . null) errors =  writeFile "parse-errors.txt" (show errors)
> >   | otherwise = ?
> >
> > What should be an 'otherwise' case ?
> >
> > Thanks!
> >
> > ___
> > 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] Conditional IO ?

2011-06-20 Thread Lyndon Maydwell
Your errors branch has the type

writeFile "parse-errors.txt" (show errors) :: IO ()

This means that your otherwise branch should have the same type.

You can use the return function that has the type

return :: Monad m => a -> m a

specialised to m = IO

in conjunction with the value

() :: ()

giving

return () :: IO ()

There is also the when function that eliminates the else case for
conditional IO:
http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control-Monad.html#v:when

On Mon, Jun 20, 2011 at 4:00 PM, Dmitri O.Kondratiev  wrote:
> Hi,
> What is right way to do conditional IO?
> For example, I need to write to file errors only in case they exist,
> otherwise my function should do nothing:
>
> handleParseErrors errors
>   | (not . null) errors =  writeFile "parse-errors.txt" (show errors)
>   | otherwise = ?
>
> What should be an 'otherwise' case ?
>
> Thanks!
>
> ___
> 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] Conditional IO ?

2011-06-20 Thread Arlen Cuss
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 20/06/11 18:00, Dmitri O.Kondratiev wrote:
> Hi,
> What is right way to do conditional IO?
> For example, I need to write to file errors only in case they exist,
> otherwise my function should do nothing:
> 
> handleParseErrors errors
>   | (not . null) errors =  writeFile "parse-errors.txt" (show errors)
>   | otherwise = ?
> 
> What should be an 'otherwise' case ?

How about `return ()'?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJN/v/hAAoJEDiWqExGnQ/Q7VQP/js4XZc92bHeM8f/ErQeQ4LT
UwINtt8WFtTWevQtwfO6wNc96CVcjnybb2SwPqnQMISnb4EPc9RvfFz24FTBneQ9
d7MD44uNnW1wAgY8VKaQQJ2v5VVrUd8Gq/m0toUKuefaT9yKMVIG/EeEPaLEUe3y
tJUyykCXcUpTzllDyk9kjb/1Og9CNWD+y4rdrWSldWCwgIPMHE2nwNOvs6RquPDQ
Om5eFdk2AFwAgDl1FIR2EiuWdQ3jUVPaDsHC0L24fvCeC/TA6AoHmC0panCYCchc
8nEruqwmiA/nU+Uh1Z6SWEicBeuWcXSk6iPuRYM7xU9dDLKFNEHAvCTLYdg2+zwR
sovOOYrOEnQ8FDwyZGXC7atxrNGl/nk09Q2RNkXryGo/nNdkUG0AuvoXI5gn8Q6v
7mZiXJr2AbUFqcDA4qXOj8IwddtU5hvwqkGj7xSqCck9sHWWXjZLrJqFH+mW8oMU
8rHVkSpMEFH0vbfvvgRMqzdcpnuDKa4/t+o8wvJy/lr9pdhP2o2azpxvb6NFlDpP
dgDwnOe/v8c9Mz7tqs41k94SYTVk2lNpsoXShVoB9tg0EttHKjDNM2ykGJl90Hcf
6vJUGEyNqE78s6qMxiAauxatlQdkw40j2ifcriElj5U7cogpZUGxnb/RODsl0rqn
BHPJVkHC/iEQ+t/4lfaT
=HGbC
-END PGP SIGNATURE-

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Conditional IO ?

2011-06-20 Thread Eugene Kirpichov
| otherwise = return ()

or:

handleParseErrors errors = when (not . null $ errors) $ writeFile .

2011/6/20 Dmitri O.Kondratiev :
> Hi,
> What is right way to do conditional IO?
> For example, I need to write to file errors only in case they exist,
> otherwise my function should do nothing:
>
> handleParseErrors errors
>   | (not . null) errors =  writeFile "parse-errors.txt" (show errors)
>   | otherwise = ?
>
> What should be an 'otherwise' case ?
>
> Thanks!
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>



-- 
Eugene Kirpichov
Principal Engineer, Mirantis Inc. http://www.mirantis.com/
Editor, http://fprog.ru/

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Conditional IO ?

2011-06-20 Thread Dmitri O.Kondratiev
Hi,
What is right way to do conditional IO?
For example, I need to write to file errors only in case they exist,
otherwise my function should do nothing:

handleParseErrors errors
  | (not . null) errors =  writeFile "parse-errors.txt" (show errors)
  | otherwise = ?

What should be an 'otherwise' case ?

Thanks!
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe