Re: [Haskell-cafe] Why functional programming matters

[Jonathan Cast]

On 24 Jan 2008, at 3:04 PM, Evan Laforge wrote:


This takes an iterator over some collection of Foos and finds the one
with the highest value of updateTime.  9 lines of code, or 12 with  
the

closing curly brackets.

In Haskell this is so short and obvious you probably wouldn't bother
declaring it as a function, but if you did, here it is:

   -- Find the Foo that was most recently updated.
   latestUpdate :: [Foo] -> Foo
   latestUpdate foos = maximumBy (comparing updateTime) foos

Of course you could always write it in point-free format, but I think
that would be over-egging things.


Java's just wordy like that.  In python you'd say max(foos, key=lambda
x: x.update_time).  Python / perl / ruby / smalltalk have had first
class functions forever, so those are basically already in the
mainstream.


But, while Python/Perl/Ruby/Smalltalk may have borrowed such  
techniques already, the syntax still conspires against them.  If the  
audience knows one or more of these languages, I would suggest  
finding its syntactic infelicities and contrasting with Haskell  
(Haskell's syntax is its strongest point, IMHO).


jcc


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

Re: [Haskell-cafe] Evolutionary Computing

[Clifford Beshers]

On Jan 24, 2008 3:55 PM, PR Stanley <[EMAIL PROTECTED]> wrote:

> Hi
> What does the list think of EC? Genetic algorithm is apparently the
> latest thing.


They've been around for a while, actually.  See below for some work from the
early 1990's.


> Is EC mathematically reasonable?


I'm not sure what that means, but they can be useful, especially when you
are looking for something that is novel, rather than meeting specific,
pre-determined criteria.  Karl Sims made a business out of them for
generating graphics.  "Survival of the prettiest," he called it.

For more info:

http://www.genarts.com/karl/
http://www.genarts.com/karl/papers/siggraph91.html
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Evolutionary Computing

[Jon Harrop]

On Friday 25 January 2008 03:30:03 Paulo Tanimoto wrote:
> But I must say I don't have much practical experience with them
> myself.  Mostly reading other people's work.

Me too. I have read that EC is competitive when the fitness function is 
riddled with discontinuities though, so it may still be useful.

As an aside, I also found a lot of the folklore surrounding more conventional 
optimization algorithms to be completely wrong in practice (at least in the 
context of molecular dynamics).

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Evolutionary Computing

[Paulo Tanimoto]

There's also this theorem by Holland, but I've never read much about
it to know how sound it is:
http://en.wikipedia.org/wiki/Holland%27s_schema_theorem

Paulo


On Jan 24, 2008 8:30 PM, Paulo Tanimoto <[EMAIL PROTECTED]> wrote:
> Have you seen Koza's Genetic Programming as well?
>
> His original implementation was in Lisp, but I think it can be done
> elegantly in Haskell as well, perhaps with the advantage of static
> typing.
>
> Hmm, I just found this:
> http://www.haskell.org/haskellwiki/GPLib
>
> I also found a paper on something called PolyGP:
> http://www.cs.mun.ca/~tinayu/index_files/addr/public_html/pgp.new.pdf
>
> Whether mathematically reasonable or not, I think EC works well in
> practice but within some limits.  A few "inventions" and "discoveries"
> have been done through it, and there are certainly lots of interesting
> uses out there in optimization.  But after a few years it seems that
> EC is not the panacea that enthusiasts promised in the past.  It often
> involves quite a lot of work setting up, takes long time to converge
> to something, whereas other simpler methods can give similar/better
> results, just because you can apply your knowledge more directly.
>
> But I must say I don't have much practical experience with them
> myself.  Mostly reading other people's work.
>
> Paulo
>
> PS: Check this out too, mentioning Sean Luke's work:
> http://www.acm.org/crossroads/xrds4-3/robocup.html
>
>
>
>
>
> On Jan 24, 2008 4:55 PM, PR Stanley <[EMAIL PROTECTED]> wrote:
> > Hi
> > What does the list think of EC? Genetic algorithm is apparently the
> > latest thing.
> > Is EC mathematically reasonable?
> > Paul
> >
> > ___
> > 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] Evolutionary Computing

[Paulo Tanimoto]

Have you seen Koza's Genetic Programming as well?

His original implementation was in Lisp, but I think it can be done
elegantly in Haskell as well, perhaps with the advantage of static
typing.

Hmm, I just found this:
http://www.haskell.org/haskellwiki/GPLib

I also found a paper on something called PolyGP:
http://www.cs.mun.ca/~tinayu/index_files/addr/public_html/pgp.new.pdf

Whether mathematically reasonable or not, I think EC works well in
practice but within some limits.  A few "inventions" and "discoveries"
have been done through it, and there are certainly lots of interesting
uses out there in optimization.  But after a few years it seems that
EC is not the panacea that enthusiasts promised in the past.  It often
involves quite a lot of work setting up, takes long time to converge
to something, whereas other simpler methods can give similar/better
results, just because you can apply your knowledge more directly.

But I must say I don't have much practical experience with them
myself.  Mostly reading other people's work.

Paulo

PS: Check this out too, mentioning Sean Luke's work:
http://www.acm.org/crossroads/xrds4-3/robocup.html




On Jan 24, 2008 4:55 PM, PR Stanley <[EMAIL PROTECTED]> wrote:
> Hi
> What does the list think of EC? Genetic algorithm is apparently the
> latest thing.
> Is EC mathematically reasonable?
> Paul
>
> ___
> 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] Binary IO of a list of ints

[Jamie Love]

Thanks Jed,

That works (or at least it's taking ages to error :-) )


Jed Brown wrote:

On 24 Jan 2008, [EMAIL PROTECTED] wrote:

  

Hi there

I have a list of ints, with values between 0 and 255 and I need to print them
out in little endian form to a file.

I've been using Data.Binary for single values, e.g.

runPut $ do
put 'B'
put (0 :: Int32)



This will be big endian by default.  If it needs to be little endian,
use Data.Binary.Put.putWord32le and relatives.  With a list, you could
do something like:

  runPut $ mapM_ (putWord32le . fromIntegral) listOfInts

I hope this helps.

Jed
  


--
Jamie Love
Senior Consultant
Aviarc Australia
Mobile: +61 400 548 048



 

This message has been scanned for viruses and dangerous content 
by MailScanner and is believed to be clean.


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

Re: [Haskell-cafe] Why functional programming matters

[Sterling Clover]

On Jan 24, 2008, at 6:04 PM, Evan Laforge wrote:


Java's just wordy like that.  In python you'd say max(foos, key=lambda
x: x.update_time).  Python / perl / ruby / smalltalk have had first
class functions forever, so those are basically already in the
mainstream.  They may impress a java or C programmer who's never seen
a dynamic language.  It might reassure a python programmer that static
typing doesn't preclude using closures and doesn't mean c++ or java
style huge long declarations.

So you probably need some other examples to convince python
programmers that their language didn't just cherry pick all the great
ideas and that there are none left.



 Actually, citing the degree to which python, perl, ruby etc. have  
adopted some of the basics of functional programming seems like a  
clear win. The popularity of a book such as "Higher Order Perl"  
almost begs the question -- how much better would it be if folks were  
doing this in a language designed to make such things efficient from  
the get-go?
 While I'm not knowledgeable enough to give the inside scoop about  
Goldman, they're a good example in that they're doing some very  
functional stuff, especially frp-related for lots of their main  
worldwide pricing systems, but mainly doing this in languages that  
aren't purely functional. Here's one blog post that at least  
demonstrates that this is happening: http://www.kimbly.com/blog/ 
000505.html
  As I understand it, since they're working on a massively  
distributed architecture (literally worldwide), functional techniques  
are not only a huge win, but unavoidable.
  Along the lines of citing "Higher Order Perl" the popularity of C+ 
+ template metaprogramming might be a neat way to make the pitch as  
well. Drawing out how template metaprogramming is a form of  
functional programming might be a bit much for the talk. But, still,  
briefly mentioning that is widely recognized as helping to make  
things clean and efficient, although in a massively verbose and  
sometimes confusing way, and that more purely functional languages  
can do the same thing in a nicer way might again be a way to make the  
point.
   The neatest piece of simple Haskell code that I can think of, by  
the way, is the oft-cited Hamming sequence. There's so much going on  
in it, the manner it exploits laziness and infinite streams, and so  
forth.


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

Re: [Haskell-cafe] Draft chapters of "Real World Haskell" now publicly available

[Conal Elliott]

Afaik, you're right about Yampa not being event-driven.  I've been working
on alternatives for a while that are event-driven while still genuinely
functional (non-IO).  See http://haskell.org/haskellwiki/Reactive and
http://haskell.org/haskellwiki/TV .  I have some blog posts in the works
about the inner goings-on of Reactive.

  - Conal

2008/1/24 Peter Verswyvelen <[EMAIL PROTECTED]>:

>  [...]
> The main problem I could see is that Yampa is not really event driven in
> the imperative sense; I mean in an ideal event based system, the hardware
> triggers an interrupt when some sensor changes, and this then triggers other
> software events; only the code that is related to handling the event that
> occurred is executed. But the event that is handled could potentially not be
> needed for the current output (which could be considered as a programming
> bug...) I think Yampa does not do that, it kinda "pulls" the information out
> of the current signal function network, which has the advantage of only
> executing the code that is needed for the output, but the disadvantage is
> that it does a lot of routing and checking which event happened.
>
> Warning to newbies: the above is most likely incorrect information, this
> is just the way I experienced it ;-)
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Why functional programming matters

[Conal Elliott]

On Jan 24, 2008 1:45 AM, Peter Hercek <[EMAIL PROTECTED]> wrote:

> [...]
> On the other side there are downsides like what to do instead of
>  reactive GUIs? GUI is a big part for a lot of applications. [...]


GUIs can be expressed in a *much* more direct and modular way in functional
programming than imperative programming.  See
http://haskell.org/haskellwiki/TV and
http://haskell.org/haskellwiki/Phooeyfor examples.  No inversion of
control is necessary.  And not just for GUIs,
but for reactive systems in general.  See
http://haskell.org/haskellwiki/Reactive and http://haskell.org/yampa/ .

I'd cite easy & modular GUIs as a strong advantage of functional
programming.

Just to be clear, I mean really *functional* programming, not imperative
programming in Haskell (IO).

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

Re: [darcs-devel] [Haskell-cafe] Re: announcing darcs 2.0.0pre3

[zooko]

It's mostly historical, but also supported by the assumption that  
Linus

thought about it when *he* decided to use sha1 for the same purpose.


With all due respect, "Because Linus did it." is a bad reason.  To  
think no further than that would be irresponsible, even if Linus had  
just now made his decision, and even if Linus were a security  
expert.  But in any case, there has been a significant new result  
making SHA-1 cracking practical *since* Linus made that decision, and  
Linus is not (and does not claim to be) a security expert.


Here are the comments from some people whose opinions about security  
you should trust -- Bruce Schneier and Jon Callas.  Note the  
timestamps.  Linus chose SHA-1 for git in 2005-04.


http://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html
http://article.gmane.org/gmane.linux.kernel/294596/match=git
http://www.schneier.com/blog/archives/2005/08/new_cryptanalyt.html

Regards,

Zooko

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

Re: [Haskell-cafe] Why functional programming matters

[Evan Laforge]

> > A real time incremental gc would be really cool.  Some people claim
> > they exist, but which languages have one?
>
> Define "real time".  I'll note that, after all the mud that's been
> slung at Java, you've been able to get low-pause-time parallel GC in
> Java for years and years, and can get "real time" GC for various of
> your favorite definitions of that term if you're willing to look a
> little.

I'd personally settle for soft real time, like "very rarely takes more
than n ms in a single gc run" so that if you are calculating samples
or something chances of getting a dropout are low.  I think most
people would be happy there.  So Java sounds like it would do for me
there.  Unfortunately it has all the rest of that language attached to
it :)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Why functional programming matters

[Jan-Willem Maessen]

On Jan 24, 2008, at 6:04 PM, Evan Laforge wrote:


Well... ghc still has a single-threaded garbage collector, so all the
"par" threads must stop for garbage collection.  So scaling to the
level of a cluster would be significantly sub-linear.


A real time incremental gc would be really cool.  Some people claim
they exist, but which languages have one?


Define "real time".  I'll note that, after all the mud that's been  
slung at Java, you've been able to get low-pause-time parallel GC in  
Java for years and years, and can get "real time" GC for various of  
your favorite definitions of that term if you're willing to look a  
little.


Relatively few other language implementations can claim the same.   
Writing a decent parallel GC (eg, faster than the tuned sequential GC  
it's replacing on 2 or more CPUs) is hard.  Sounds like GHC is nearly  
there, though.  GC implementors dream of systems where read barriers  
are nearly free.  Better still, everything that's been learned about  
and published in Java-land carries across to Haskell (though the  
tradeoffs in eg mutation behavior are often different).


-Jan-Willem Maessen



___
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] Evolutionary Computing

[PR Stanley]

Hi
What does the list think of EC? Genetic algorithm is apparently the 
latest thing.

Is EC mathematically reasonable?
Paul

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

[Haskell-cafe] Re: [darcs-devel] cryptographic hash functions in darcs (re: announcing darcs 2.0.0pre3)

[zooko]

On Jan 24, 2008, at 2:57 PM, Achim Schneider wrote:


And anyway, if your goal is security 'till 2015, SHA1 seems to be
secure enough(TM) for all practical purposes


This is true, only given several of assumptions: no further  
algorithmic improvements will arise that further reduce the  
complexity of cracking SHA-1, it will prove impossible to parallelize  
SHA-1 cracking or to build custom hardware to do it more quickly and  
cheaply, the global market for computing-on-demand will not cause the  
cost of distributed computation to fall too fast, quantum computation  
will not become sufficient, etc..


These are a lot of big "if"'s to place long-term bets on.



(that is, without using
par on a beowolf cluster on all ps3's in the world), as the
speed^H^H^H^H^Hcomplexity of a single CPU core won't obey Moore's law
anymore, for physical reasons.


Nobody says you have to use a single CPU to crack SHA-1.  Distributed  
efforts and custom hardware have cracked other crypto algorithms in  
the recent past.



\OTOH, when quantum computing arrives, you're fucked, anyway.


Quantum computing would not by itself render SHA-256 insecure.   
Unless, of course, there were a new improved kind of cryptanalysis  
against SHA-256 which puts it "within range" of quantum computation.



Excessive
paranoia in general doesn't pay off if the to protected data is
publicly accessible in any way whatsoever.


Agreed.  There is a reasonable case to be made for darcs: "If you use  
darcs to maintain your source code you are willing to be vulnerable  
to everyone with whom you transitively exchange patches, that such  
people might choose to subvert your repository.".  This is what darcs  
1 offers, and it has not deterred me from using darcs 1 for my open  
source projects with few contributors.


There is also a reasonable case to be made: "To the best of our  
current knowledge, you can for at least the near future rely on the  
property that a patch id can match at most one patch.".  SHA-1 does  
not offer this.


What I object to is false advertising -- telling people that darcs  
has the latter guarantee when the best minds who have studied the  
issue are in agreement that it does not currently offer that  
guarantee, and as time passes it will become increasingly likely that  
more and more unknown people gain the ability to violate that guarantee.




THEY would be much more cost-effective if THEY'd go for
physically hacking your system instead of paying N million € for
hardware to crack your codes.


This is a very good argument -- an economic argument.  Security gurus  
nowadays like to say "Amateurs study algorithms; professionals study  
economics.".


But it turns out, if you pay the cost to generate collisions in a  
widely used hash function like SHA-1, then you can use your results  
against all kinds of users of that function, without paying much  
marginal cost for each added target.  This includes targets whose  
physical security is high.


Put it this way: sure you can subvert *my* computer on the cheap.  It  
would probably cost you a few thousand dollars -- I have no idea how  
much really.  But then you would have to pay again to subvert someone  
else's computer.  Whereas if you build a SHA-1-cracking machine and  
rainbow tables of collisions, you can use this in many ways,  
targetting many different algorithms.



Another way to approach the issue is: why SHA-1?  SHA-256 would be  
slower and safer, including, probably, safe even if someone out there  
builds a quantum computer without telling us about.  Tiger would be  
faster and safer (although not safe against a quantum computer).   
SHA-1 is the worst of both worlds -- slow and unsafe.



Regards,

Zooko

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

Re: [Haskell-cafe] Draft chapters of "Real World Haskell" now publicly available

[Peter Verswyvelen]

Wolfgang Jeltsch wrote:
Indeed.  A functional approach to GUIs is nice but at the moment we don’t have 
anything that is suitable for solving real world problems (although this is 
being worked on).
Could you elaborate a bit on that? What are the current obstacles to be 
solved?


When I looked at Yampa, I didn't really see a problem with making a GUI 
or interactive application based on it (besides maybe performance and 
space/time leaks, the latter IMO being a general problem in Haskell that 
just occurs quicker in reactive programming). I could model state 
machines, dynamic collections, events and event handlers with it, all 
hierarchically. I just would have to practice much much more to get good 
at it. Of course, I'm way too new to functional programming to really 
judge Yampa, it's just the feeling I got from it.


The main problem I could see is that Yampa is not really event driven in 
the imperative sense; I mean in an ideal event based system, the 
hardware triggers an interrupt when some sensor changes, and this then 
triggers other software events; only the code that is related to 
handling the event that occurred is executed. But the event that is 
handled could potentially not be needed for the current output (which 
could be considered as a programming bug...) I think Yampa does not do 
that, it kinda "pulls" the information out of the current signal 
function network, which has the advantage of only executing the code 
that is needed for the output, but the disadvantage is that it does a 
lot of routing and checking which event happened.


Warning to newbies: the above is most likely incorrect information, this 
is just the way I experienced it ;-)


Now IMO the OO way of handling GUIs is also not carved in stone. OO and 
imperative programmers also seem to continue the search for "the best" 
GUI event system. For example, the first version of  the .NET GUI 
"borrowed" the Delphi approach, which was a direct link (through a 
delegate in .NET, called closure in Delphi) between the event source and 
the event listener (in C we know that as a list of (callback,userdata)  
;-) ). Same for QT's signal/slot system. Other systems use a 
producer/dispatcher/consumer pattern (or how is it called). Java AWT 
initially used a message based system, then switched to an interface 
based system. Other systems (like MFC) used a message based approach, 
where the message is routed to many components in a hierarchy. The 
latest version of .NET's GUI system (WPF) again uses such an "element 
tree" and the event can be routed through the whole tree in both 
directions. Some claim Smalltalk's model-view-controller is still the 
best pattern, others claim that the controller is too closely linked to 
the view to be really separate and stick to a document/view model, or 
just duplicate data by using some kind of data-binding... I tried all 
approaches over the last 20 years, and I still see no "best" way...


 :-) The working name for Grapefruit was Vegetables, by the way. ;-) 
LOL! I'll certainly look at it, I find it very fascinating (though 
confusing...) to compare all existing reactive solutions


Thank you,
Peter

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

Re: [Haskell-cafe] ANNOUNCE: Harpy 0.4 - Runtime code generation for x86 machine code

[Austin Seipp]

> - When using the high-level assembler in X86Assembler, the code buffer
>   is automatically protected from overflow.

This one update alone is worth the whole upgrade; while experimenting
with Harpy in several of my own personal compiler-related projects,
the necessity of ensureBufferSize was a major limitation in code
generation since I found it did nothing but litter the resulting asm and
distract from the actual code generation (considering I figure the
assembler could count the bytes a lot easier than I could.)

Great work on a great library. I have already installed it and
definitely will be putting it to use in the near future :)

-- 
"It was in the days of the rains that their prayers went up, 
not from the fingering of knotted prayer cords or the spinning 
of prayer wheels, but from the great pray-machine in the
monastery of Ratri, goddess of the Night."
 Roger Zelazny
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Why functional programming matters

[Evan Laforge]

> This takes an iterator over some collection of Foos and finds the one
> with the highest value of updateTime.  9 lines of code, or 12 with the
> closing curly brackets.
>
> In Haskell this is so short and obvious you probably wouldn't bother
> declaring it as a function, but if you did, here it is:
>
>-- Find the Foo that was most recently updated.
>latestUpdate :: [Foo] -> Foo
>latestUpdate foos = maximumBy (comparing updateTime) foos
>
> Of course you could always write it in point-free format, but I think
> that would be over-egging things.

Java's just wordy like that.  In python you'd say max(foos, key=lambda
x: x.update_time).  Python / perl / ruby / smalltalk have had first
class functions forever, so those are basically already in the
mainstream.  They may impress a java or C programmer who's never seen
a dynamic language.  It might reassure a python programmer that static
typing doesn't preclude using closures and doesn't mean c++ or java
style huge long declarations.

So you probably need some other examples to convince python
programmers that their language didn't just cherry pick all the great
ideas and that there are none left.

> Well... ghc still has a single-threaded garbage collector, so all the
> "par" threads must stop for garbage collection.  So scaling to the
> level of a cluster would be significantly sub-linear.

A real time incremental gc would be really cool.  Some people claim
they exist, but which languages have one?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Why functional programming matters

[Achim Schneider]

ChrisK <[EMAIL PROTECTED]> wrote:

> Achim Schneider wrote:
> > Don Stewart <[EMAIL PROTECTED]> wrote:
> > 
> >> jwlato:
> >>> In addition to STM, another item that should interest serious
> >>> programmers is forkIO.  Lightweight threads that (unlike in
> >>> Python) can use multiple cpu's.  Coming from Python, I personally
> >>> appreciate this.  Using STM to handle concurrency issues often
> >>> greatly simplifies multithreaded code.
> >> And further on this, the use of `par` in pure code to make it go 
> >> multicore is way beyond what most people think is possible.
> >>
> > I said _don't_ make me think of using par on a beowolf cluster of
> > ps3's. Don't you guys have any scruples?
> > 
> 
> Well... ghc still has a single-threaded garbage collector, so all the
> "par" threads must stop for garbage collection.  So scaling to the
> level of a cluster would be significantly sub-linear.
> 
"By the time you learnt how to write proper Haskell, that's most likely
implemented in an arcane one-liner using par."

-- 
/me aleady drank a bootle of vin and suggests that you don't answer
seriously if you want to get non-abstroose anwererse.

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

Re: [Haskell-cafe] Why functional programming matters

[Mattias Bengtsson]

On Thu, 2008-01-24 at 21:11 +, Paul Johnson wrote:
[snip]
>// Get the Foo that was most recently updated.
>Foo latestUpdate (Iterator  iterator) {
[...]
>}
> 
> This takes an iterator over some collection of Foos and finds the one 
> with the highest value of updateTime.  9 lines of code, or 12 with the 
> closing curly brackets.
> 
> In Haskell this is so short and obvious you probably wouldn't bother 
> declaring it as a function, but if you did, here it is:
> 
>-- Find the Foo that was most recently updated.
>latestUpdate :: [Foo] -> Foo
>latestUpdate foos = maximumBy (comparing updateTime) foos
> 
> Of course you could always write it in point-free format, but I think 
> that would be over-egging things.

To have a fair comparison you'd have to use some typeclass (Foldable
would be right?) that supports different types of collections.

> import Data.Foldable as F
> 
> latestUpdate :: Foldable a => [a] -> a
> latestUpdate = F.maximumBy (comparing updateTime)

But yeah your point is very very valid. I've programmed some Java in my
days and while i wouldn't call myself an expert i don't see any
immediate "unawkward" abstractions that can be performed in the java
code. 
If you have all Foo's implement a method "getProperty(String)" that
takes a String and returns the property of that class instance you
_could_ implement the static method (correct java-lingo?)
maximumBy(String s) that is roughly like this:

class MyClass {
  public static Foo maximumBy (Iterator  iterator, String s) {
 long max = 0;
 Foo maxFoo = Null;
 while (iterator.hasNext()) {
item = iterator.getNext();
if (item.getProperty(s).compareTo(max)) {
   max = item.updateTime;
   maxFoo = item;
}
 }
 return maxFoo;
  }
}

and then
Foo latestUpdate (Iterator  i) {
   return MyClass.maximumBy(i,"latestUpdate");
}

Totally untested code ofcourse...
The awkward part obviously comes from the fact that properties aren't
functions that you can pass to the maximumBy-method.

Anyhow, Haskell's nice Polymorphism is surely a good argument for it
(but not for functional programming per se right?)

Mattias

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

[Haskell-cafe] Re: Why functional programming matters

[ChrisK]

Achim Schneider wrote:

Don Stewart <[EMAIL PROTECTED]> wrote:


jwlato:

In addition to STM, another item that should interest serious
programmers is forkIO.  Lightweight threads that (unlike in Python)
can use multiple cpu's.  Coming from Python, I personally appreciate
this.  Using STM to handle concurrency issues often greatly
simplifies multithreaded code.
And further on this, the use of `par` in pure code to make it go 
multicore is way beyond what most people think is possible.



I said _don't_ make me think of using par on a beowolf cluster of
ps3's. Don't you guys have any scruples?



Well... ghc still has a single-threaded garbage collector, so all the "par" 
threads must stop for garbage collection.  So scaling to the level of a cluster 
would be significantly sub-linear.


--
Chris

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

Re: [Haskell-cafe] parsec and bytestring; was: hxt memory useage

[Clifford Beshers]

It well might.  I believe you can do this yourself.  Jeremy Shaw wrote a
parser for Debian control files, which was useless on the really large
package index files.  He switched it over to using bytestrings and that
solved the problem.  You can find the code in a darcs repository at:
http://src.seereason.com/haskell-debian.  It may reference other libraries
hosted at that URL, which you can browse from the base URL.


On Jan 24, 2008 1:34 PM, Matthew Pocock <[EMAIL PROTECTED]> wrote:

> Would a bytestring-backed implementation of parsec solve my problems? Is
> there
> such a beast out there?
>
> 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

[Haskell-cafe] Re: cryptographic hash functions in darcs (re: announcing darcs 2.0.0pre3)

[Achim Schneider]

zooko <[EMAIL PROTECTED]> wrote:


> The basic choice is: (a) use an insecure function and simply state  
> that anyone with whom you (transitively) exchange patches has the  
> opportunity to subvert your repository, or (b) use a secure hash  
> function, i.e. SHA-256 or Tiger.
> 
And anyway, if your goal is security 'till 2015, SHA1 seems to be
secure enough(TM) for all practical purposes (that is, without using
par on a beowolf cluster on all ps3's in the world), as the
speed^H^H^H^H^Hcomplexity of a single CPU core won't obey Moore's law
anymore, for physical reasons.

OTOH, when quantum computing arrives, you're fucked, anyway. Excessive
paranoia in general doesn't pay off if the to protected data is
publicly accessible in any way whatsoever.

THEY would be much more cost-effective if THEY'd go for
physically hacking your system instead of paying N million € for
hardware to crack your codes.

In the end, I guess THEY finance quantum computing research, but I'm
going vastly OT here...

-- 
(c) this sig last receiving data processing entity. Inspect headers for
past copyright information. All rights reserved. Unauthorised copying,
hiring, renting, public performance and/or broadcasting of this
signature prohibited. 

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

Re: [Haskell-cafe] parsec and bytestring; was: hxt memory useage

[Matthew Pocock]

Would a bytestring-backed implementation of parsec solve my problems? Is there 
such a beast out there?

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

Re: [Haskell-cafe] Why functional programming matters

[Paul Johnson]

Simon Peyton-Jones wrote:
1. Small examples of actual code. The goal here is (a) to convey a visceral idea of what functional programming *is*, rather than just assume the audience knows (they don't), and (b) to convey an idea of why it might be good.  
Here is one I came across in the last few days.  I was reviewing some 
code in Java, and it contained a function that looked through a list of 
Foo instances for the latest update.  I don't actually speak Java, but 
it went something like this:


  // Get the Foo that was most recently updated.
  Foo latestUpdate (Iterator  iterator) {
 long latestTimeSoFar = 0;
 Foo latestFooSoFar = Null;

 while (iterator.hasNext()) {
item = iterator.getNext();
if (item.updateTime > latestTimeSoFar) {
   latestTimeSoFar = item.updateTime;
   latestFooSoFar = item;
}
 }
 return latestFooSoFar;
  }

This takes an iterator over some collection of Foos and finds the one 
with the highest value of updateTime.  9 lines of code, or 12 with the 
closing curly brackets.


In Haskell this is so short and obvious you probably wouldn't bother 
declaring it as a function, but if you did, here it is:


  -- Find the Foo that was most recently updated.
  latestUpdate :: [Foo] -> Foo
  latestUpdate foos = maximumBy (comparing updateTime) foos

Of course you could always write it in point-free format, but I think 
that would be over-egging things.


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

[Haskell-cafe] Re: cryptographic hash functions in darcs (re: announcing darcs 2.0.0pre3)

[zooko]

following-up to my own post:

On Jan 24, 2008, at 1:15 PM, zooko wrote:


So, let me see if I understand the issues here.

...
2.  It would be nice, but isn't currently used, if one could rely  
on the property that for a given patch id, nobody can come up with  
another patch that has the same id.  This would be nice because in  
the future we might use this to securely identify patches and  
entire repositories.  This property is called "second pre-image  
resistance".


3.  Likewise, it would be nice if it were impossible for someone to  
come up with two different patches that had the same patch id.   
This is called "collision resistance".


Actually, these properties *are* currently relied upon, whenever a  
darcs process uses a patch id without seeing the patch from which it  
was generated.


For example, if you have a patch which you received in e-mail, and  
the patch contains the ids of patches on which it depends but not the  
complete patches, and your darcs process matches up those ids with  
patches that it has locally, then you are relying on these two  
properties.  (The same thing happens when pushing and pulling patches  
over HTTP or SSH.)


If your patch-id-generation function doesn't have collision  
resistance, then you are vulnerable to the possibility that the  
original creator of the patch id (not necessarily the person who sent  
you this patch in e-mail) also created another patch which matched  
the same id.  Having done so, this person could subvert your  
repository, i.e. insert backdoors into the source code managed by  
your repository.


If your patch-id-generation function doesn't have second-pre-image  
resistance, then you are vulnerable to the possibility that someone  
else (not necessarily the original creator of the patch id) also  
created another patch which matched the same id.  Having done so,  
this person could subvert your repository.


This makes the choice of SHA-1 for the patch-id-generation function  
wholly inappropriate.  We already know that SHA-1 doesn't have  
collision resistance, and there is reason to suspect that in the near  
future it will turn out that it doesn't have second-pre-image  
resistance either.


The basic choice is: (a) use an insecure function and simply state  
that anyone with whom you (transitively) exchange patches has the  
opportunity to subvert your repository, or (b) use a secure hash  
function, i.e. SHA-256 or Tiger.


Regards,

Zooko

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

[Haskell-cafe] cryptographic hash functions in darcs (re: announcing darcs 2.0.0pre3)

[zooko]

On Jan 24, 2008, at 11:32 AM, David Roundy wrote:


All data in the hashed format is hashed.  Darcs doesn't implement any
checking of signatures, but you could (relatively) easily do so by
hand.  Just sign _darcs/hashed_inventory, and if the signature is
valid and the repository is consistent (which darcs automatically
checks for any portion of the repository that it accesses), then the
repository hasn't been tampered with (since it was signed, anyhow).

As far as what the guarantee is, all contents of the repository
(except _darcs/prefs/ and of course the working directory) are
accessed by hashes stored in that one file.



So, let me see if I understand the issues here.

1.  Darcs needs to have short identifiers for a patch.  Is it  
required, or merely tolerable that the same patch (contents and  
metadata) yield the same identifier?  Or is it a bug, in which the  
independent generation of an identical patch will result in undefined  
behavior?  Let's call this property "patch id determined by patch".


2.  It would be nice, but isn't currently used, if one could rely on  
the property that for a given patch id, nobody can come up with  
another patch that has the same id.  This would be nice because in  
the future we might use this to securely identify patches and entire  
repositories.  This property is called "second pre-image resistance".


3.  Likewise, it would be nice if it were impossible for someone to  
come up with two different patches that had the same patch id.  This  
is called "collision resistance".


4.  Someday, someone might want to expose their patch ids without  
also thus exposing information about their patches.  This is called  
"pre-image resistance".


5.  Inasmuch as anyone might want to rely on any of these properties,  
they might want to do so years down the road.  They might want to  
take darcs patches or darcs repositories that were generated in 2008,  
and rely on these properties in 2015 or even later.



Now it is important to note that SHA-1 does *not* have collision  
resistance today, and there is reason to suspect that it doesn't have  
other security properties either.  The more years into the future we  
look, the less likely it is that the user will be willing to rely on  
SHA-1.



Let's enumerate a few options for what darcs can do now:

1.  Use randomly generated patch identifiers.  This means that the  
identifiers don't have any of the properties described, but they are  
easy to implement, fast to produce (practically instantaneous), and  
at least we know that they don't have these properties so we don't  
accidentally rely on them.


2.  Use a CRC like ZFS does.  This means that identifiers have "patch  
id determined by patch", but don't have the other properties.  Again,  
this is easy to implement, fast to compute (let's say around 1 GiB/ 
sec), and has the virtue of not fooling us into thinking we have a  
security guarantee that we don't.


3.  Use MD5.  This is easy to implement (because MD5 is widely used),  
fast to compute (370 MiB/sec), and has the dubious virtue of being  
mostly well understood as being insecure.


4.  Use SHA-1.  This is easy to implement (because SHA-1 is widely  
used), a bit slower to compute (220 MiB/sec), and has the regrettable  
misfeature of being widely misunderstood (e.g. by Linus) as being  
secure.


5.  Use SHA-256.  This is hard to implement (I'm assuming there  
aren't already Haskell bindings for it), even slower to compute (110  
MiB/sec), but it is the first of these options has a chance of  
allowing people in the future to rely on the security properties.


6.  Use Tiger.  This is hard to implement (I'm assuming there aren't  
already Haskell bindings for it), relatively fast (320 MiB/sec), and  
might or might not offer security ten or twenty years from now.



I must say that option 4 is the worst of the bunch.  Except for the  
implementation difficulty (of which I know little), any other option  
would provide a better trade-off.



Regards,

Zooko

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

[Haskell-cafe] Re: Why functional programming matters

[Achim Schneider]

Don Stewart <[EMAIL PROTECTED]> wrote:

> jwlato:
> > In addition to STM, another item that should interest serious
> > programmers is forkIO.  Lightweight threads that (unlike in Python)
> > can use multiple cpu's.  Coming from Python, I personally appreciate
> > this.  Using STM to handle concurrency issues often greatly
> > simplifies multithreaded code.
> 
> And further on this, the use of `par` in pure code to make it go 
> multicore is way beyond what most people think is possible.
> 
I said _don't_ make me think of using par on a beowolf cluster of
ps3's. Don't you guys have any scruples?

-- 
(c) this sig last receiving data processing entity. Inspect headers for
past copyright information. All rights reserved. Unauthorised copying,
hiring, renting, public performance and/or broadcasting of this
signature prohibited. 

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

Re: [Haskell-cafe] OT: Isorecursive types and type abstraction

[Nicolas Frisby]

This paper, with a pdf available at Patricia Johann's publications page

  http://crab.rutgers.edu/~pjohann/

seems to be related.

  Initial Algebra Semantics is Enough! Patricia Johann and Neil Ghani.
Proceedings, Typed Lambda Calculus and Applications 2007 (TLCA'07)

Hope that helps.

On Jan 24, 2008 11:02 AM, Edsko de Vries <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 24, 2008 at 10:46:36AM -0600, Antoine Latter wrote:
> > Hmm ...
> >
> > How about:
> >
> > Perfect :: * -> * = Fix (L :: * -> *) . /\ A . (A + L (A,A))
> >
> > unfold Perfect = [L := Fix L . t] t where t = /\ A . (A + L (A,A))
> >  = /\ A . (A + (Fix L . /\ B . (B + L (B,B))) (A,A))
> >
> > assuming alpha-equality.  Because L and (Fix L . t)  are of kind (* ->
> > *), the substitution should be okay.  Am I missing something, again?
>
> The problem is not that Perfect as it stands cannot be unrolled; the
> problem is that without some hackery, I don't know how to unroll the
> type of a term if that type is of the form ((Fix ..) applied to some
> arguments rather than just (Fix ..) -- whether that is List or Perfect.
> The only reason I mention Perfect is that for List I can 'lift' the
> "/\A" over the "Fix", but I cannot do that with Perfect.
>
>
> Edsko
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Why functional programming matters

[Don Stewart]

jwlato:
> In addition to STM, another item that should interest serious
> programmers is forkIO.  Lightweight threads that (unlike in Python)
> can use multiple cpu's.  Coming from Python, I personally appreciate
> this.  Using STM to handle concurrency issues often greatly simplifies
> multithreaded code.

And further on this, the use of `par` in pure code to make it go 
multicore is way beyond what most people think is possible.

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

Re: [Haskell-cafe] Re: Why functional programming matters

[John Lato]

In addition to STM, another item that should interest serious
programmers is forkIO.  Lightweight threads that (unlike in Python)
can use multiple cpu's.  Coming from Python, I personally appreciate
this.  Using STM to handle concurrency issues often greatly simplifies
multithreaded code.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] hxt memory useage

[Matthew Pocock]

On Thursday 24 January 2008, Albert Y. C. Lai wrote:
> Matthew Pocock wrote:
> > I've been using hxt to process xml files. Now that my files are getting a
> > bit bigger (30m) I'm finding that hxt uses inordinate amounts of memory.
> > I have 8g on my box, and it's running out. As far as I can tell, this
> > memory is getting used up while parsing the text, rather than in any
> > down-stream processing by xpickle.
> >
> > Is this a known issue?
>
> Yes, hxt calls parsec, which is not incremental.
>
> haxml offers the choice of non-incremental parsers and incremental
> parsers. The incremental parsers offer finer control (and therefore also
> require finer control).

I've got a load of code using xpickle, which taken together are quite an 
investment in hxt. Moving to haxml may not be very practical, as I'll have to 
find some eqivalent of xpickle for haxml and port thousands of lines of code 
over. Is there likely to be a low-cost solution to convincing hxt to be 
incremental that would get me out of this mess?

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: [darcs-devel] [Haskell-cafe] Re: announcing darcs 2.0.0pre3

[David Roundy]

On Jan 23, 2008 5:47 PM, zooko <[EMAIL PROTECTED]> wrote:
> > In principle it is good to provide a cryptographically secure hash, as
> > this allows users to sign their repositories by signing a single file,
> > which seems like it's potentially quite a useful feature.
>
> Can you be more specific about this -- who can "sign" a repository?
> How is such a signature checked?  What guarantee can you rely on if
> the check passes?

All data in the hashed format is hashed.  Darcs doesn't implement any
checking of signatures, but you could (relatively) easily do so by
hand.  Just sign _darcs/hashed_inventory, and if the signature is
valid and the repository is consistent (which darcs automatically
checks for any portion of the repository that it accesses), then the
repository hasn't been tampered with (since it was signed, anyhow).

As far as what the guarantee is, all contents of the repository
(except _darcs/prefs/ and of course the working directory) are
accessed by hashes stored in that one file.

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

Re: [Haskell-cafe] Why functional programming matters

[Yaakov Nemoy]

On Jan 23, 2008 8:29 AM, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
> Friends
>
> Over the next few months I'm giving two or three talks to groups of *non* 
> functional programmers about why functional programming is interesting and 
> important.  If you like, it's the same general goal as John Hughes's famous 
> paper "Why functional programming matters".
>
> Audience: some are technical managers, some are professional programmers; but 
> my base assumption is that none already know anything much about functional 
> programming.
>
> Now, I can easily rant on about the glories of functional programming, but 
> I'm a biased witness -- I've been doing this stuff too long.  So this message 
> is ask your help, especially if you are someone who has a somewhat-recent 
> recollection of realising "wow, this fp stuff is so cool/useful/powerful/etc".
>
> I'm going to say some general things, of course, about purity and effects, 
> modularity, types, testing, reasoning, parallelism and so on. But I hate 
> general waffle, so I want to give concrete evidence, and that is what I 
> particularly want your help with.  I'm thinking of two sorts of "evidence":

I'm still very much a newbie, but the one thing that struck me as the
best feature coming from Python is the static typing.  Changing the
type of a function in Python will lead to strange runtime errors that
take some work to debug, whereas, when I tinker with a program in
Haskell, I already know it will work once it compiles.

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

Re: [Haskell-cafe] hxt memory useage

[Albert Y. C. Lai]

Matthew Pocock wrote:
I've been using hxt to process xml files. Now that my files are getting a bit 
bigger (30m) I'm finding that hxt uses inordinate amounts of memory. I have 
8g on my box, and it's running out. As far as I can tell, this memory is 
getting used up while parsing the text, rather than in any down-stream 
processing by xpickle.


Is this a known issue?


Yes, hxt calls parsec, which is not incremental.

haxml offers the choice of non-incremental parsers and incremental 
parsers. The incremental parsers offer finer control (and therefore also 
require finer control).

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

Re: [Haskell-cafe] Re: Why functional programming matters

[Robin Green]

On Thu, 24 Jan 2008 10:29:23 -0600
Derek Elkins <[EMAIL PROTECTED]> wrote:

> Doing it in the IDE would a) require much more from most IDEs and b)
> be almost entirely useless.  Most IDEs don't even get as far as
> parsing the code, even the the best rarely know much about the actual
> semantics of the language.  This would require a rather deep analysis
> and ultimately it is undecidable.  Practically speaking, having such
> a feature in the IDE would be useless unless the programming style of
> most "imperative" programmers changed dramatically.  The only
> functions such an analysis would say were pure are those that were
> rather trivial.  Either way, having such a feature in the IDE doesn't
> really help.  A purity checker in the IDE isn't going to help when
> the function/method is unknown, e.g. when I write a function/method
> that takes a function or an object.  A "purity annotation" would have
> to be at the language level, short of doing a whole-program analysis
> which would be infeasible.

Indeed - JML (Java Modelling Language) takes exactly this approach.
-- 
Robin
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Why functional programming matters

[Derek Elkins]

On Thu, 2008-01-24 at 10:45 +0100, Peter Hercek wrote:
> Tim Chevalier wrote:
> > On 1/23/08, Peter Hercek <[EMAIL PROTECTED]> wrote:
> >> Other things did not seem that great for me from the beginning. For
> >> example: referential transparency - just enforces what you can take care
> >> not to do yourself
> > 
> > ...if you never make mistakes, that is.
> > 
> >> (e.g. in C# you just cannot be sure some function is
> >> referentially transparent even when comment claims so - which of course
> >> sucks because programmers are not disciplined).
> > 
> > But if that's the point you're trying to make, I agree that a lot of
> > programmers seem to think they don't make mistakes, and thus might not
> > be receptive to the siren song of referential transparency :-)
> 
> What I wanted to say is that focusing on referential transparency
>   will not appeal that much to an imperative programmer especially
>   when he needs to overcome Haskell learning curve. What may appeal,
>   though, are the consequences of it like:
> * easier to repeat test cases for bugs
> * easier to do automated tests (like quickcheck) since state space
>is not that big (provided I count automatic vars on stack/heap
>as state)
> * makes laziness to work which allow easier and efficient expression
>of producer - consumer type of code
> * easy undo (no need for memento pattern etc)
> * allows monads to work which adds options like built-in user logging
>or error recovery
> * better changes for compilers to find parallelize automatically
> * safe STM
> ... and probably a lot of more goodies
> 
> On the other side there are downsides like what to do instead of
>   reactive GUIs? GUI is a big part for a lot of applications. A lot
>   of efficient algorithms we have are state based. And again probably
>   more.
> 
> If referential transparency by itself would be that important for
>   imperative languages then it would be already added to IDEs* in
>   some form like a popup menu item with name "check function purity".
>   In some cases you could actually decide that the function is pure
>   (especially if you would go deeper analyzing and annotating your
>   objects with purity flags in your IDE).

Doing it in the IDE would a) require much more from most IDEs and b) be
almost entirely useless.  Most IDEs don't even get as far as parsing the
code, even the the best rarely know much about the actual semantics of
the language.  This would require a rather deep analysis and ultimately
it is undecidable.  Practically speaking, having such a feature in the
IDE would be useless unless the programming style of most "imperative"
programmers changed dramatically.  The only functions such an analysis
would say were pure are those that were rather trivial.  Either way,
having such a feature in the IDE doesn't really help.  A purity checker
in the IDE isn't going to help when the function/method is unknown, e.g.
when I write a function/method that takes a function or an object.  A
"purity annotation" would have to be at the language level, short of
doing a whole-program analysis which would be infeasible.

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

Re: [Haskell-cafe] OT: Isorecursive types and type abstraction

[Edsko de Vries]

On Thu, Jan 24, 2008 at 10:46:36AM -0600, Antoine Latter wrote:
> Hmm ...
> 
> How about:
> 
> Perfect :: * -> * = Fix (L :: * -> *) . /\ A . (A + L (A,A))
> 
> unfold Perfect = [L := Fix L . t] t where t = /\ A . (A + L (A,A))
>  = /\ A . (A + (Fix L . /\ B . (B + L (B,B))) (A,A))
> 
> assuming alpha-equality.  Because L and (Fix L . t)  are of kind (* ->
> *), the substitution should be okay.  Am I missing something, again?

The problem is not that Perfect as it stands cannot be unrolled; the
problem is that without some hackery, I don't know how to unroll the
type of a term if that type is of the form ((Fix ..) applied to some
arguments rather than just (Fix ..) -- whether that is List or Perfect.
The only reason I mention Perfect is that for List I can 'lift' the
"/\A" over the "Fix", but I cannot do that with Perfect.

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

Re: [Haskell-cafe] OT: Isorecursive types and type abstraction

[Dan Licata]

On Jan24, Antoine Latter wrote:
> Can "Fix" be made to work with higher-kinded types?  If so, would the
> following work:

Yes, it can.  

For a particular A (e.g., Int), List A is a recursive type
Fix X. 1 + (A * X).

List :: type -> type is a family of recursive types: if you give it a
type, it gives you a recursive type.  So we can represent that by
\ a -> Fix X. 1 + (a * X).  

[As an aside, note that (\ a -> A) is the type-constructor-level
abstraction (i.e., the introduction form for the *kind* K1 -> K2).  This
is different from the polymorhpic type (\forall a.A), which has kind
type, and is introduced and eliminated by *term*-level type abstraction
and application.  So I'd say that list itself is parametrized, not
polymorphic.  On the other hand, 
cons :: \forall a . a -> list a -> list a
is a polymorphic function that instantiates the parametrized type list
with its type parameter.]

Now, as Edsko observed, families of recursive types aren't good enough
for non-uniform datatypes like perfect trees, lists indexed by their
length, etc.  One ingredient that GADTs give you is *recursive families
of types*.  In contrast to families of recursive types, recursive
families are a simultaneous recursive definition of all of the elements
of the family; this is important because it permits one instance of the
family to be defined in terms of another.  In syntax, you get a new type

Fix (C1, C2) 

where C1 :: (type -> type) -> (type -> type)
and   C2 :: type

The idea is that this takes the fixed point of C1 and applies it to C2.
The roll and unroll do what you suggest below.  

[This can be generalized to the fixed point of a constructor-level
function of kind (K -> type) -> K -> type as well, and then C2::K.
I.e., there's no reason the argument has to be a type.]

See 

Flexible Type Analysis
Karl Crary and Stephanie Weirich
ICFP 99

for an example of a type theory with this type.  

Make sense?
-Dan

> On Jan 24, 2008 9:52 AM, Edsko de Vries <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > This is rather off-topic but the audience of this list may be the right
> > one; if there is a more appropriate venue for this question, please let
> > me know.
> >
> > Most descriptions of recursive types state that iso-recursive types
> > (with explicit 'fold' and 'unfold' operators) are easy to typecheck,
> > and that equi-recursive types are much more difficult. My question
> > regards using iso-recursive types (explicitly, not implicitly using
> > algebraic data types) together with type abstraction and application.
> >
> > The usual typing rules for fold and unfold are
> >
> >  e :: Fix X. t
> >   -  Unfold
> >   unfold e :: [X := Fix X. t] t
> >
> >   e :: [X := Fix X. t] t
> >   - Fold
> >fold e : Fix X. t
> >
> > This works ok for the following type:
> >
> >   ListInt = Fix L. 1 + Int * L
> >
> > (where "1" is the unit type). If
> >
> >   x :: ListInt
> >
> > then
> >
> >   unfold x :: 1 + Int * ListInt
> >
> > using the Unfold typing rule. However, this breaks when using type
> > abstraction and application. Consider the polymorphic version of list:
> >
> >   List = Fix L. /\A. 1 + A * L A
> >
> > Now if we have
> >
> >   x :: List Int
> >
> > we can no longer type
> >
> >   unfold x
> >
> > because x does not have type (Fix ..), but ((Fix ..) Int) instead. Of
> > course, we can unroll List Int by first unrolling List, and then
> > re-applying the unrolled type to Int to get
> >
> >   (/\A. 1 + A * (Fix L. /\A. 1 * L A) A) Int
> >
> > which can be simplified to
> >
> >   1 + Int * List Int
> >
> > but this is not usually mentioned (that I could find; in particular, TAPL 
> > does not mention it) and I'm worried that there are subtleties here that 
> > I'm missing--nor do I have an exact definition of what this 'extended' 
> > unrolling rule should do.
> >
> > Any hints or pointers to relevant literature would be appreciated!
> >
> > Edsko
> >
> > PS. One way to simplify the problem is to redefine List as
> >
> >   List = /\A. Fix L. 1 + A * L
> >
> > so that List Int can easily be simplified to the right form (Fix ..);
> > but that can only be done for regular datatypes. For example, the nested
> > type
> >
> >   Perfect = Fix L. /\A. A + Perfect (A, A)
> >
> > cannot be so rewritten because the argument to Perfect in the recursive
> > call is different.
> > ___
> > 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] ghc and Red Hat 5 .rpm

[Galchin Vasili]

Hello,

I have searching on http://haskell.org/ghc/download_ghc_682.html ..  but
can't find a ghc .rpm so that I can install ghc. ?

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

Re: [Haskell-cafe] OT: Isorecursive types and type abstraction

[Antoine Latter]

Hmm ...

How about:

Perfect :: * -> * = Fix (L :: * -> *) . /\ A . (A + L (A,A))

unfold Perfect = [L := Fix L . t] t where t = /\ A . (A + L (A,A))
 = /\ A . (A + (Fix L . /\ B . (B + L (B,B))) (A,A))

assuming alpha-equality.  Because L and (Fix L . t)  are of kind (* ->
*), the substitution should be okay.  Am I missing something, again?

-Antoine

On Jan 24, 2008 10:31 AM, Edsko de Vries <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 24, 2008 at 10:06:04AM -0600, Antoine Latter wrote:
> > Can "Fix" be made to work with higher-kinded types?  If so, would the
> > following work:
> >
> > Perfect = /\ A . Fix (L :: * -> *) . (A + L (A,A))
>
> Hi,
>
> Thanks for your quick reply. Unfortunately, your solution does not work. For
>
>   Fix X. t
>
> to be well-defined, we must have that if 'X' has kind 'k', then 't' must
> also have kind 'k' (compare the type of 'fix' in Haskell: (a -> a) -> a).
>
> > Keep in mind I have no idea what the "Perfect" data structure is
> > supposed to look like.
>
> The Haskell equivalent would be
>
> data Perfect a = Leaf a | Branch (Perfect (a, a))
>
> and models perfect binary trees (I admit, slightly headwrecking datatype! :)
>
> Edsko
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] OT: Isorecursive types and type abstraction

[Edsko de Vries]

On Thu, Jan 24, 2008 at 10:06:04AM -0600, Antoine Latter wrote:
> Can "Fix" be made to work with higher-kinded types?  If so, would the
> following work:
> 
> Perfect = /\ A . Fix (L :: * -> *) . (A + L (A,A))

Hi,

Thanks for your quick reply. Unfortunately, your solution does not work. For

  Fix X. t

to be well-defined, we must have that if 'X' has kind 'k', then 't' must
also have kind 'k' (compare the type of 'fix' in Haskell: (a -> a) -> a).

> Keep in mind I have no idea what the "Perfect" data structure is
> supposed to look like.

The Haskell equivalent would be

data Perfect a = Leaf a | Branch (Perfect (a, a))

and models perfect binary trees (I admit, slightly headwrecking datatype! :)

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

Re: [Haskell-cafe] OT: Isorecursive types and type abstraction

[Antoine Latter]

Can "Fix" be made to work with higher-kinded types?  If so, would the
following work:

Perfect = /\ A . Fix (L :: * -> *) . (A + L (A,A))

Keep in mind I have no idea what the "Perfect" data structure is
supposed to look like.

-Antoine

On Jan 24, 2008 9:52 AM, Edsko de Vries <[EMAIL PROTECTED]> wrote:
> Hi,
>
> This is rather off-topic but the audience of this list may be the right
> one; if there is a more appropriate venue for this question, please let
> me know.
>
> Most descriptions of recursive types state that iso-recursive types
> (with explicit 'fold' and 'unfold' operators) are easy to typecheck,
> and that equi-recursive types are much more difficult. My question
> regards using iso-recursive types (explicitly, not implicitly using
> algebraic data types) together with type abstraction and application.
>
> The usual typing rules for fold and unfold are
>
>  e :: Fix X. t
>   -  Unfold
>   unfold e :: [X := Fix X. t] t
>
>   e :: [X := Fix X. t] t
>   - Fold
>fold e : Fix X. t
>
> This works ok for the following type:
>
>   ListInt = Fix L. 1 + Int * L
>
> (where "1" is the unit type). If
>
>   x :: ListInt
>
> then
>
>   unfold x :: 1 + Int * ListInt
>
> using the Unfold typing rule. However, this breaks when using type
> abstraction and application. Consider the polymorphic version of list:
>
>   List = Fix L. /\A. 1 + A * L A
>
> Now if we have
>
>   x :: List Int
>
> we can no longer type
>
>   unfold x
>
> because x does not have type (Fix ..), but ((Fix ..) Int) instead. Of
> course, we can unroll List Int by first unrolling List, and then
> re-applying the unrolled type to Int to get
>
>   (/\A. 1 + A * (Fix L. /\A. 1 * L A) A) Int
>
> which can be simplified to
>
>   1 + Int * List Int
>
> but this is not usually mentioned (that I could find; in particular, TAPL 
> does not mention it) and I'm worried that there are subtleties here that I'm 
> missing--nor do I have an exact definition of what this 'extended' unrolling 
> rule should do.
>
> Any hints or pointers to relevant literature would be appreciated!
>
> Edsko
>
> PS. One way to simplify the problem is to redefine List as
>
>   List = /\A. Fix L. 1 + A * L
>
> so that List Int can easily be simplified to the right form (Fix ..);
> but that can only be done for regular datatypes. For example, the nested
> type
>
>   Perfect = Fix L. /\A. A + Perfect (A, A)
>
> cannot be so rewritten because the argument to Perfect in the recursive
> call is different.
> ___
> 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] OT: Isorecursive types and type abstraction

[Edsko de Vries]

Hi,

This is rather off-topic but the audience of this list may be the right
one; if there is a more appropriate venue for this question, please let
me know. 

Most descriptions of recursive types state that iso-recursive types
(with explicit 'fold' and 'unfold' operators) are easy to typecheck,
and that equi-recursive types are much more difficult. My question
regards using iso-recursive types (explicitly, not implicitly using
algebraic data types) together with type abstraction and application.

The usual typing rules for fold and unfold are

 e :: Fix X. t
  -  Unfold
  unfold e :: [X := Fix X. t] t

  e :: [X := Fix X. t] t
  - Fold
   fold e : Fix X. t

This works ok for the following type:

  ListInt = Fix L. 1 + Int * L

(where "1" is the unit type). If
  
  x :: ListInt

then

  unfold x :: 1 + Int * ListInt

using the Unfold typing rule. However, this breaks when using type
abstraction and application. Consider the polymorphic version of list:

  List = Fix L. /\A. 1 + A * L A

Now if we have

  x :: List Int

we can no longer type

  unfold x 

because x does not have type (Fix ..), but ((Fix ..) Int) instead. Of
course, we can unroll List Int by first unrolling List, and then
re-applying the unrolled type to Int to get

  (/\A. 1 + A * (Fix L. /\A. 1 * L A) A) Int

which can be simplified to

  1 + Int * List Int

but this is not usually mentioned (that I could find; in particular, TAPL does 
not mention it) and I'm worried that there are subtleties here that I'm 
missing--nor do I have an exact definition of what this 'extended' unrolling 
rule should do. 

Any hints or pointers to relevant literature would be appreciated!

Edsko

PS. One way to simplify the problem is to redefine List as

  List = /\A. Fix L. 1 + A * L

so that List Int can easily be simplified to the right form (Fix ..);
but that can only be done for regular datatypes. For example, the nested
type 

  Perfect = Fix L. /\A. A + Perfect (A, A)

cannot be so rewritten because the argument to Perfect in the recursive
call is different.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] hxt memory useage

[Matthew Pocock]

Hi,

I've been using hxt to process xml files. Now that my files are getting a bit 
bigger (30m) I'm finding that hxt uses inordinate amounts of memory. I have 
8g on my box, and it's running out. As far as I can tell, this memory is 
getting used up while parsing the text, rather than in any down-stream 
processing by xpickle.

Is this a known issue?

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

[Haskell-cafe] Fwd: Arrow without `>>>'

[Valery V. Vorotyntsev]

The problem has been resolved.
Kudos to Ross Paterson.

-- Forwarded message --
From: Valery V. Vorotyntsev <[EMAIL PROTECTED]>
Date: Jan 24, 2008 3:34 PM
Subject: Re: Arrow without `>>>'
To: [EMAIL PROTECTED]

On 1/24/08, Ross Paterson <[EMAIL PROTECTED]> wrote:
> > The right question: how to build `arrows' in such circumstances?
>
> To build with the darcs version of the base library (built with GHC),
> you'll need the darcs version of the arrows library, which I think is
> right now:
>
> darcs get http://darcs.haskell.org/packages/arrows

Yes, after pulling the latest change from repo installation went smoothly.
Thank you very much, Ross!
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Arrow without `>>>'

[Valery V. Vorotyntsev]

On 1/23/08, David Menendez <[EMAIL PROTECTED]> wrote:
> On Jan 23, 2008 12:20 PM, Valery V. Vorotyntsev <[EMAIL PROTECTED]> wrote:
> > I've built GHC from darcs, and...
> > Could anybody tell me, what's the purpose of Arrow[1] not having `>>>'
> > method?
>
> It's derived from the Category superclass.

Yes, it is.

The right question: how to build `arrows' in such circumstances?

Here go 2 changes I made to `CoState.hs' accompanied by the
error messages. :) Unfortunately, I'm not arrow-capable enough to
make _proper_ changes to the code and satisfy GHC... Any help?

~~
Change #1:

$ darcs w Control/Arrow/Transformer/CoState.hs
What's new in "Control/Arrow/Transformer/CoState.hs":

{
hunk ./Control/Arrow/Transformer/CoState.hs 23
+import Control.Category ((>>>))
}

--
Error #1:

Control/Arrow/Transformer/CoState.hs:29:7:
`>>>' is not a (visible) method of class `Arrow'
Failed, modules loaded: Control.Arrow.Operations.

~~
Change #2:

$ darcs diff -u Control/Arrow/Transformer/CoState.hs
--- old-arrows/Control/Arrow/Transformer/CoState.hs 2008-01-24
14:54:29.852296559 +0200
+++ new-arrows/Control/Arrow/Transformer/CoState.hs 2008-01-24
14:54:29.852296559 +0200
@@ -20,12 +20,13 @@

 import Control.Arrow
 import Control.Arrow.Operations
+import Control.Category ((>>>))

  newtype CoStateArrow s a b c = CST (a (s -> b) (s -> c))

  instance Arrow a => Arrow (CoStateArrow s a) where
arr f = CST (arr (f .))
-   CST f >>> CST g = CST (f >>> g)
+-- CST f >>> CST g = CST (f >>> g)
first (CST f) = CST (arr unzipMap >>> first f >>> arr zipMap)

  zipMap :: (s -> a, s -> b) -> (s -> (a,b))

--
Error#2:

Control/Arrow/Transformer/CoState.hs:27:0:
Could not deduce (Control.Category.Category (CoStateArrow s a))
  from the context (Arrow a)
  arising from the superclasses of an instance declaration
   at Control/Arrow/Transformer/CoState.hs:27:0
Possible fix:
  add (Control.Category.Category
 (CoStateArrow s a)) to the context of
the instance declaration
  or add an instance declaration for
 (Control.Category.Category (CoStateArrow s a))
In the instance declaration for `Arrow (CoStateArrow s a)'
Failed, modules loaded: Control.Arrow.Operations.

Thank you.

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

Re: [Haskell-cafe] Re: Why functional programming matters

[Lutz Donnerhacke]

* Isaac Dupree wrote:
> fewer frustratingly unsolvable bugs down-the-road?

I personally like the refactoring speed. Due to pureness it's easy to
refactor and that's why I can generalize more and more often.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Why functional programming matters

[Isaac Dupree]

fewer frustratingly unsolvable bugs down-the-road?  When I have bugs in 
my Haskell programs (and usually I get type errors instead), I've always 
found them eventually and they're either a silly mistake or I realize 
that I misunderstood the problem I was trying to solve (it needs to be 
solved a different way)... which is great, being able to realize that 
and rewrite things!  Usually not everything has to be rewritten because 
Haskell is pretty modular (unless used poorly :-).


~Isaac

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

Re: [Haskell-cafe] Binary IO of a list of ints

[Jed Brown]

On 24 Jan 2008, [EMAIL PROTECTED] wrote:

> Hi there
>
> I have a list of ints, with values between 0 and 255 and I need to print them
> out in little endian form to a file.
>
> I've been using Data.Binary for single values, e.g.
>
> runPut $ do
> put 'B'
> put (0 :: Int32)

This will be big endian by default.  If it needs to be little endian,
use Data.Binary.Put.putWord32le and relatives.  With a list, you could
do something like:

  runPut $ mapM_ (putWord32le . fromIntegral) listOfInts

I hope this helps.

Jed


pgpTVWKLqyPdy.pgp
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Binary IO of a list of ints

[Fraser Wilson]

(untested)

> mapM_ runPut data

?

On Jan 24, 2008 12:14 PM, Jamie Love <[EMAIL PROTECTED]> wrote:

> Hi there
>
> I have a list of ints, with values between 0 and 255 and I need to print
> them out in little endian form to a file.
>
> I've been using Data.Binary for single values, e.g.
>
> runPut $ do
>put 'B'
>put (0 :: Int32)
>
>
> I'm wondering how I can go about writing a list of Ints out. My thought
> was to do something like:
>
> foldr (\x B.hPut output (runPut $ do put (x :: Word8))) data
>
> (where output is my file handle), but apart from giving me type errors,
> it seems a rather arduous way to do it.
>
> Could anyone suggest a better way to do this?
>
> --
> Jamie Love
> Senior Consultant
> Aviarc Australia
> Mobile: +61 400 548 048
>
>
>
> 
>
> This message has been scanned for viruses and dangerous content
> by MailScanner and is believed to be clean.
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Why functional programming matters

[Sebastian Sylvan]

On Jan 24, 2008 9:45 AM, Peter Hercek <[EMAIL PROTECTED]> wrote:

>  A lot
>  of efficient algorithms we have are state based. And again probably
>  more.
>
Yes, and we can write those using the ST monad in Haskell. I think it's
important to point this out, since some imperative programmers will just go
"but what about if I *need* mutable state?" and probably tune out if they
don't hear right away that Haskell can give it to them in a safe
encapsulated form.

-- 
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Binary IO of a list of ints

[Jamie Love]

Stephan Walter wrote:

Hi,

On 2008-01-24 12:14, Jamie Love wrote:
  
I have a list of ints, with values between 0 and 255 and I need to print 
them out in little endian form to a file.



How about just using Data.Char.chr ?
  


Essentially because I need to control the byte ordering, and it has to 
be in the current case the opposite to my computer's native ordering 
(the file is a binary file).

Prelude> let a = [32..64] :: [Int]
Prelude> map Data.Char.chr a
" !\"#$%&'()*+,-./0123456789:;<=>?@"


--Stephan

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


 

This message has been scanned for viruses and dangerous content 
by MailScanner and is believed to be clean.



  


--
Jamie Love
Senior Consultant
Aviarc Australia
Mobile: +61 400 548 048



 

This message has been scanned for viruses and dangerous content 
by MailScanner and is believed to be clean.


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

[Haskell-cafe] Re: Binary IO of a list of ints

[Stephan Walter]

Hi,

On 2008-01-24 12:14, Jamie Love wrote:
> I have a list of ints, with values between 0 and 255 and I need to print 
> them out in little endian form to a file.

How about just using Data.Char.chr ?

Prelude> let a = [32..64] :: [Int]
Prelude> map Data.Char.chr a
" !\"#$%&'()*+,-./0123456789:;<=>?@"


--Stephan

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

Re: [Haskell-cafe] Draft chapters of "Real World Haskell" now publicly available

[Wolfgang Jeltsch]

Am Mittwoch, 23. Januar 2008 10:53 schrieben Sie:
> Wolfgang Jeltsch wrote:
> > Covering reactive programming would indeed be interesting.
> >
> > I want to add that there is no single way for doing reactive programming
> > in Haskell.  There is Conal’s stuff, there is Yampa and there is “my”
> > stuff (Grapefruit [1]) whereby the pros and cons of these approaches
> > differ.  (And there is plenty of other stuff which doesn’t seem to be
> > actively developed, like, for example, FranTk.)
>
> Doesn't that count for everything? I've been doing imperative & OO
> programming for more than 2 decades, and every technique has its pros
> and cons, it's what makes the job hard, picking the right choices, which
> is (in my case) often more a matter of taste and "it worked before" than
> good reasoning.

Yes, of course.  I just hadn’t recognized that you had also mentioned Yampa, 
and wanted to point out that besides Conal’s stuff there are further 
approaches to reactive programming in Haskell.

> […]

> Gtk2HS can hardly be called pure functional programming can it? It is IO
> and monads everywhere.

Indeed.  A functional approach to GUIs is nice but at the moment we don’t have 
anything that is suitable for solving real world problems (although this is 
being worked on).

> […]

> I haven't looked at Grapefruit yet (actually I don't like fruit, but I
> like vegetables, so lucky me ;-).

The working name for Grapefruit was Vegetables, by the way. ;-) 

> I will certainly do so. Any interesting links?

The most interesting link is  at 
the moment—since it’s the only one. ;-)  Note that, in contrast to the last 
months, this page now links to an up-to-date API documentation.

> Cheers,
> Peter

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

[Haskell-cafe] Binary IO of a list of ints

[Jamie Love]

Hi there

I have a list of ints, with values between 0 and 255 and I need to print 
them out in little endian form to a file.


I've been using Data.Binary for single values, e.g.

runPut $ do
   put 'B'
   put (0 :: Int32)


I'm wondering how I can go about writing a list of Ints out. My thought 
was to do something like:


foldr (\x B.hPut output (runPut $ do put (x :: Word8))) data

(where output is my file handle), but apart from giving me type errors, 
it seems a rather arduous way to do it.


Could anyone suggest a better way to do this?

--
Jamie Love
Senior Consultant
Aviarc Australia
Mobile: +61 400 548 048



 

This message has been scanned for viruses and dangerous content 
by MailScanner and is believed to be clean.


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

Re: [Haskell-cafe] Re: Why functional programming matters

[Maarten Hazewinkel]

On 24 Jan 2008, at 10:45, Peter Hercek wrote:


* safe STM
... and probably a lot of more goodies


Especially STM would be a good point to elaborate on.
Most big systems have issues around concurrency and state modification  
being broken.
Anything that can reliably solve that problem is going to interest  
serious programmers.



Maarten

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

[Haskell-cafe] Re: Why functional programming matters

[Peter Hercek]

Tim Chevalier wrote:

On 1/23/08, Peter Hercek <[EMAIL PROTECTED]> wrote:

Other things did not seem that great for me from the beginning. For
example: referential transparency - just enforces what you can take care
not to do yourself


...if you never make mistakes, that is.


(e.g. in C# you just cannot be sure some function is
referentially transparent even when comment claims so - which of course
sucks because programmers are not disciplined).


But if that's the point you're trying to make, I agree that a lot of
programmers seem to think they don't make mistakes, and thus might not
be receptive to the siren song of referential transparency :-)


What I wanted to say is that focusing on referential transparency
 will not appeal that much to an imperative programmer especially
 when he needs to overcome Haskell learning curve. What may appeal,
 though, are the consequences of it like:
* easier to repeat test cases for bugs
* easier to do automated tests (like quickcheck) since state space
  is not that big (provided I count automatic vars on stack/heap
  as state)
* makes laziness to work which allow easier and efficient expression
  of producer - consumer type of code
* easy undo (no need for memento pattern etc)
* allows monads to work which adds options like built-in user logging
  or error recovery
* better changes for compilers to find parallelize automatically
* safe STM
... and probably a lot of more goodies

On the other side there are downsides like what to do instead of
 reactive GUIs? GUI is a big part for a lot of applications. A lot
 of efficient algorithms we have are state based. And again probably
 more.

If referential transparency by itself would be that important for
 imperative languages then it would be already added to IDEs* in
 some form like a popup menu item with name "check function purity".
 In some cases you could actually decide that the function is pure
 (especially if you would go deeper analyzing and annotating your
 objects with purity flags in your IDE).

* and IDEs like visual studio or eclipse are incredibly good compared
 to the stuff Haskell has; anyway IMHO all IDEs are not good enough
 - they could be much better

Anyway I'm not that qualified to discuss this (I hope this is my last
 post to this thread :) ). I just wanted to point out what could be
 a point of view of an imperative programmer based on what I remember
 from times I was getting more involved with functional programming.
 The reason I started with functional programming is sure not common
 - sometimes I may need to actually prove some program features.


Peter.

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

Re: [Haskell-cafe] SPJ on the radio (at .NET Rocks :)

[Magnus Therning]

Don Stewart wrote:
> Simon talks about laziness, purity and other FP concepts
> to some .NET guys. Simon starts 7minutes 20seconds in.
> 
> http://www.dotnetrocks.com/default.aspx?ShowNum=310
> 
> Good work Simon!

If you, like me, find that page to be utterly broken in your browser of
choice, then this is the URL of the episode:
http://perseus.franklins.net/dotnetrocks_0310_simon_peyton_jones.mp3

/M

-- 
Magnus Therning (OpenPGP: 0xAB4DFBA4)
magnus＠therning．org Jabber: magnus．therning＠gmail．com
http://therning.org/magnus

What if I don't want to obey the laws? Do they throw me in jail with
the other bad monads?
 -- Daveman



signature.asc
Description: OpenPGP digital signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] SPJ on the radio (at .NET Rocks :)

[Don Stewart]

Simon talks about laziness, purity and other FP concepts
to some .NET guys. Simon starts 7minutes 20seconds in.

http://www.dotnetrocks.com/default.aspx?ShowNum=310

Good work Simon!

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