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
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
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
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 i
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 call
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 singl
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 pr
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
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
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
> > 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
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. Som
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
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
complex
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
> - 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 m
> 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 i
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. Comin
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
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 handl
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.see
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 y
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
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 da
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
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 (whi
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 concurr
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,
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
> multithread
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.
_
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
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
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
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
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
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
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 al
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 g
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
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 sho
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
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]> w
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,
an
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-
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 quest
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 supercla
* 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@hask
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
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
(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
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 ju
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
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:;<=
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”
> > s
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
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 t
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 jus
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,
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:
59 matches
Mail list logo
