Translated a bit:
With lazy evaluation, the order of evaluation is irrelevant as far as the
_correctness_ of the function is concerned. However, it's much easier to
reason about the _efficiency_ of functions when the language uses strict
evaluation; you never have to scratch your head and ask "I
On Tue, 2005-05-03 at 00:38 -0400, Daniel Carrera wrote:
> So, I'm tempted to conclude that FP is only applicable to situations
> where user interaction is a small part of the program. For example, for
> simulations.
Others have suggested this is not always true. If you dig around you
will find
On Tue, 3 May 2005 21:04:46 -0700
Andrew Pimlott <[EMAIL PROTECTED]> wrote:
> The advantage of lazy evaluation is that evaluation order becomes one
> less thing you have to think about.
Yes, but only if your functions are pure.
> The disadvantage of lazy evaluation
> is that evaluation order be
On Wed, May 04, 2005 at 12:40:13PM +1000, Erik de Castro Lopo wrote:
> That leaves one aspect of Haskell vs Ocaml I don't yet understand.
> What are the advantages of lazy evaluation?
The advantage of lazy evaluation is that evaluation order becomes one
less thing you have to think about. The dis
On Tue, 3 May 2005 15:41:22 -0700 (PDT)
Michael Vanier <[EMAIL PROTECTED]> wrote:
> I also learned ocaml before learning haskell,
I'm a long term C, Python and (yuck) C++ programmer who picked up Ocaml
about 9 months ago. I picked Ocaml over Haskell because I thought I
needed objects, but I ha
The first thing that I think I should mention is that lists are not
arrays. You should have a look at Data.Array
(http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data.Array.html)
and the other libraries in that bunch if you really want arrays (where
random access is O(1) rather than O(n)
Benjamin Franksen writes:
> On Wednesday 04 May 2005 01:32, Ben Rudiak-Gould wrote:
> > This doesn't work in Haskell because Haskell types aren't
> > constructed in this way. It's harder to prove properties of types
> > in Haskell (and fewer properties actually hold).
>
> Could you explain why th
> Date: Tue, 03 May 2005 19:56:00 -0400
> From: Daniel Carrera <[EMAIL PROTECTED]>
>
> Hi Ben,
>
> > Take a look at this one:
> >
> > http://www.haskell.org/onlinelibrary/standard-prelude.html
>
> Thanks.
>
> What's the "Prelude" ?
It's the repository of haskell code (functions, types, type c
On Wednesday 04 May 2005 01:32, Ben Rudiak-Gould wrote:
> This doesn't work in Haskell because Haskell types aren't constructed in
> this way. It's harder to prove properties of types in Haskell (and fewer
> properties actually hold).
Could you explain why this is so? Or rather, what the appropria
Hi Ben,
Take a look at this one:
http://www.haskell.org/onlinelibrary/standard-prelude.html
Thanks.
What's the "Prelude" ?
1) Is there a function to get the ith element from an array?
From your own implementations I gather you mean 'list', not 'array'.
What's the difference?
Now, if you happen to
On Wednesday 04 May 2005 01:26, Daniel Carrera wrote:
> Hello,
>
> I hope these don't turn out to be RTFM questions, but I can't find them
> in my FM :-)
Take a look at this one:
http://www.haskell.org/onlinelibrary/standard-prelude.html
> 1) Is there a function to get the ith element from an ar
Michael Vanier <[EMAIL PROTECTED]> writes:
> I also learned ocaml before learning haskell, and the biggest single
> difference I found is that haskell is a lazy, purely functional language
> and ocaml is a strict, "mostly functional" language.
Indeed.
In contrast to this one, my differences were
Echo Nolan wrote:
My copy of HS: The Craft Of FP just arrived and I was reading
section 8.5 about induction. On page 141, Simon Thompson gives a
method of proving properties of functions on lists:
1) Prove that the property holds for the null list
2) Prove that the property
Hello,
I hope these don't turn out to be RTFM questions, but I can't find them
in my FM :-)
1) Is there a function to get the ith element from an array?
2) Is there a function to get the "index" of an entry in an array?
I've implemented these two functions below:
1)
find 0 (x:xs) = x
find n (x:xs
Marcin gives a good capsule description of the differences between ocaml
and haskell. Let me add my two cents.
I also learned ocaml before learning haskell, and the biggest single
difference I found is that haskell is a lazy, purely functional language
and ocaml is a strict, "mostly functional"
On Tue, 3 May 2005, Marcin 'Qrczak' Kowalczyk wrote:
...
> Its type system has some interesting features: polymorphic variants,
> parametric modules, labeled and optional arguments, objects, variance
> annotations of type parameters used for explicit subtyping.
>
> It has more convenient exception
> Hi all!
> I'm trying to join to lists of lists. The problem is, i would like to
> get a new list of lists of tuples and not list of tuples of lists (that
> what zip makes).
>
> list1 = [[1,2],[3,4],[5,6]]
> list2 = [[a,b],[c,d],[e,f]]
>
> desiredlist = [[(1,a),(2,b)],[(3,c),(4,d)],[(5,e),(6,f)]]
On Tue, May 03, 2005 at 10:13:04PM +0200, Khrystyna Mandziy wrote:
> Hi all!
> I'm trying to join to lists of lists. The problem is, i would like to
> get a new list of lists of tuples and not list of tuples of lists (that
> what zip makes).
>
> list1 = [[1,2],[3,4],[5,6]]
> list2 = [[a,b],[c,d],[
On 5/3/05, Khrystyna Mandziy <[EMAIL PROTECTED]> wrote:
> Hi all!
> I'm trying to join to lists of lists. The problem is, i would like to
> get a new list of lists of tuples and not list of tuples of lists (that
> what zip makes).
>
> list1 = [[1,2],[3,4],[5,6]]
> list2 = [[a,b],[c,d],[e,f]]
>
>
Hi all!
I'm trying to join to lists of lists. The problem is, i would like to
get a new list of lists of tuples and not list of tuples of lists (that
what zip makes).
list1 = [[1,2],[3,4],[5,6]]
list2 = [[a,b],[c,d],[e,f]]
desiredlist = [[(1,a),(2,b)],[(3,c),(4,d)],[(5,e),(6,f)]]
Thanks for any hel
John Goerzen <[EMAIL PROTECTED]> writes:
> I'd say that there are probably no features OCaml has that Haskell
> lacks that are worth mentioning.
Its type system has some interesting features: polymorphic variants,
parametric modules, labeled and optional arguments, objects, variance
annotations o
On Tue, May 03, 2005 at 12:20:45PM -0400, Daniel Carrera wrote:
> Would that be correct? For computational work (e.g. a simulation,
> factoring primes, whatever) does it approach C speed?
>
> I would be happy to hear a comparison with any other language you find
> interesting.:-) As well as any
On 2005-05-03, Daniel Carrera <[EMAIL PROTECTED]> wrote:
> Greg Buchholz wrote:
>
>> You might find the "The Great Computer Language Shootout"
>> informative...
>>
>> http://shootout.alioth.debian.org/
>
> Thanks!
>
> That's a great resource. At first glance, Haskell seems to do well over
On 2005-05-03, Daniel Carrera <[EMAIL PROTECTED]> wrote:
> Marcin just mentioned OCaml as another functional programming language I
> should keep in mind.
>
> Can anyone offer an opinion on how Haskell and OCaml compare? Is OCaml
> as easy to learn as Haskell? Does it have much the same virtues?
Alright, in Haskell there are no side-effects when you call a function
twice on the same data you get the same result...
I just decided I'll try to write a good pseudo random number generator
in Haskell :-)
I'm off to class now, but I'll try it tonight.
Cheers,
Daniel.
_
My friend, you just proved that I only have but the fuzziest idea of
what functional programming is. :-)
Thanks for the info. I'll figure this out eventually.
Cheers,
Daniel.
Marcin 'Qrczak' Kowalczyk wrote:
Daniel Carrera <[EMAIL PROTECTED]> writes:
Marcin,
Are you sure that OCaml is similar to
Daniel Carrera <[EMAIL PROTECTED]> writes:
> Marcin,
>
> Are you sure that OCaml is similar to Haskell? At first glance, it
> doesn't even look functional. It looks like an imperative language.
It's not purely functional, but it supports algebraic types and
first-class functions, uses similar con
On 5/3/05, Daniel Carrera <[EMAIL PROTECTED]> wrote:
> Marcin,
>
> Are you sure that OCaml is similar to Haskell? At first glance, it
> doesn't even look functional. It looks like an imperative language.
>
It is functional, but it's not pure (ie it allows side effects) and
doesn't have as nice s
Marcin,
Are you sure that OCaml is similar to Haskell? At first glance, it
doesn't even look functional. It looks like an imperative language.
Cheers,
Daniel.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo
Hey,
Marcin just mentioned OCaml as another functional programming language I
should keep in mind.
Can anyone offer an opinion on how Haskell and OCaml compare? Is OCaml
as easy to learn as Haskell? Does it have much the same virtues?
I'll go take a look at it.
/daniel goes to Google.
Cheers,
D
Daniel Carrera <[EMAIL PROTECTED]> writes:
> My next question is about speed. How fast would you consider Haskell?
> (say, for computational work). How would you compare it to C, Python
> and Ruby?
>
> I suggest C, Python and Ruby as a basis of comparison because:
I suggest adding OCaml, because
Greg Buchholz wrote:
You might find the "The Great Computer Language Shootout"
informative...
http://shootout.alioth.debian.org/
Thanks!
That's a great resource. At first glance, Haskell seems to do well over-all.
Cheers,
Daniel.
___
Haskell-Caf
Hi all,
Thank you for all the information on my previous question. I learned a
lot, and good pointers to more info.
My next question is about speed. How fast would you consider Haskell?
(say, for computational work). How would you compare it to C, Python and
Ruby?
I suggest C, Python and Ruby
Daniel Carrera writes:
> So, I'm tempted to conclude that FP is only applicable to
> situations where user interaction is a small part of the
> program. For example, for simulations.
I can't confirm that. I've written several I/O-intensive
applications in Haskell, including full-blown network
On 5/3/05, Daniel Carrera <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Again, I'm the new guy slowly learning this "fuctional programming"
> thing. :-)
>
> I've been reading, and I'm really liking the elgance of Haskell, and FP
> as a whole. But I wonder about the range of applicability. You see, one
Hi all,
Again, I'm the new guy slowly learning this "fuctional programming"
thing. :-)
[snip]
So, I'm tempted to conclude that FP is only applicable to situations
where user interaction is a small part of the program. For example, for
simulations.
Now, I'm sure I'm not the first person to have
Am Dienstag, 3. Mai 2005 03:48 schrieben Sie:
> Daniel Fischer writes:
> > Due to lazyness, we can have infinite lists (and other infinite
> > structures) in Haskell (of course, in finite time, only a finite
> > portion of those can be evaluated), e.g. ns = [1 .. ] :: [Integer] is
> > an infinite l
On 01 May 2005 19:28, Sven Panne wrote:
> Gour wrote:
>> Simon Marlow ([EMAIL PROTECTED]) wrote:
>>> Great news, thanks John.
>>>
>>> Is it possible to set up a two-way synch so we can move over to
>>> darcs gradually? It's not really practical for us to move over in
>>> one go, we've simply acc
Ben Lippmeier wrote:
You might like to take a deep breath and start with:
"Tackling the awkward squad: monadic input/output, concurrency,
exceptions, and foreign-language calls in Haskell" - Simon Peyton Jones
http://research.microsoft.com/Users/simonpj/papers/marktoberdorf/
Ok. And I'll get to l
Tomasz Zielonka wrote:
In my experience, the amount of IO code in an average Haskell program
is from 1% to 20%, even in applications which have to do a fair amount
of interaction with the outside world (networking, CGI, system utils).
Ok, I can see that. Thanks.
Haskell's IO is not just a mimicry o
Simon Marlow wrote:
But what worries me is: if I just want to check out e.g. Haddock, I have
to get the entire fptools repo (350M+, wasn't it?). I can build a
source distribution with just the bits I want, but I can't get a darcs
tree with anything but the whole lot.
So, here's two potential solut
On Fri, Apr 29, 2005 at 08:38:05AM -0500, John Goerzen wrote:
> On Fri, Apr 29, 2005 at 10:39:13AM +0100, Simon Marlow wrote:
> > So, here's two potential solutions:
> >
> > 1. Make it possible to 'darcs get' just part of a tree. Patches
> > that don't touch any files in the "live" parts o
On Tue, May 03, 2005 at 12:38:25AM -0400, Daniel Carrera wrote:
> So, I figure that to do these tasks you heed that "do ... <-" work
> around. But that kills the whole point of using FP in the first place,
> right?
In my experience, the amount of IO code in an average Haskell program
is from 1%
Hello,
What if main had a function prototype like:
main :: String -> String
And you passed stdin to main as string, and you print the output of main
to stdout.
As long as you run the program with the same stdin, when main calls
'ask_user_name stdin', you will always get the same answer, right ?
44 matches
Mail list logo
