Hi,
(maybe I got the message to the community this time, Mark P ;-)
I would like to know if anyone (maybe Mark P) knows the status of
Cartesian classes in different Haskell implementations. I.e., does
anyone implement the suggested functional dependencies or the less
general parameterized type
(I am having problem with my lovely Outlook program, so here I send it
again, to the whole group; sorry, Frank...)
Frank Atanassow wrote:
David Bergman wrote (on 26-11-02 01:29 -0500):
I would like to know if anyone (maybe Mark P) knows the status of
Cartesian classes in different Haskell
Curly enough...
Thanks,
David
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On
Behalf Of Hal Daume III
Sent: Tuesday, November 26, 2002 1:40 PM
To: David Bergman
Cc: 'Haskell Mailing List'
Subject: RE: cartesian classes
A very concrete, but naïve, question
for the concrete usage info for functional dependencies
restricting these class relations.
David
-Original Message-
From: Frank Atanassow [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 27, 2002 10:15 AM
To: David Bergman
Subject: Re: cartesian classes
David Bergman wrote (on 26-11-02 13:18
Vincenzo,
I agree with your feeling of the expressive superiority of functional
programming compared to C and even C++, although I would not use the
word hell ;-)
Actually, there is a lot of advanced meta programming enabled in C++ due
to its rather powerful, but intricate, typing system in
Bernard James wrote:
In section 4.4.3 Function and Pattern Bindings of the Haskell 98
Report,
it gives the following translation:
[ the pattern lambda construction to case expression conversion from the
Report]
What does it mean by semantically equivalent. A rough approximation
is
has the
Just to add to what Zdenek wrote:
The linear complexity of string concatenation in a naïve implementation
(not having access to an extra-language end-of-list in the diff list
sense...) make the total complexity O(n^2), since the number of conses
generated is thus
sum [1 .. n]
which,
wanted people to not forget
that the do is just syntactic sugar...
Thanks,
David
-Original Message-
From: Richard Uhtenwoldt
Sent: Saturday, November 30, 2002 11:53 PM
To: David Bergman
Cc: [EMAIL PROTECTED]
Subject: RE: Running out of memory in a simple monad
David Bergman writes
. This does not make them useless.
/David
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On
Behalf Of Richard Uhtenwoldt
Sent: Saturday, November 30, 2002 11:53 PM
To: David Bergman
Cc: [EMAIL PROTECTED]
Subject: RE: Running out of memory in a simple monad
David Bergman
Richard wrote:
some are using Haskell for systems programming, as a better C
than C. some, including me, would like to see more of that,
with Haskell or another pure functional language with an IO monad
taking systems programmers away from the C and C++ communities.
That is good, I would
John Hughes wrote:
On Mon, 2 Dec 2002, Andrew J Bromage wrote:
... If you mention a term like design patterns,
well I love design patterns, it's just that in Haskell-land
they are
called higher-order functions, or polymorphic functions, etc.
-- Johannes Waldmann
Hi, Bill.
I agree 90% with you in your questioning the adequateness of trying to
incorporate design patterns in Haskell, and the actual productive use of
them in other languages as well.
But, I must defend design patterns, and Haskell, a bit...
William Lee Irwin III wrote:
On Mon, Dec 02, 2002
should be
using something else such as GHC.
As I see it the problem is basically that of tail recursion removal or
as David Bergman calls it last call optimisation.
Specifically:
David Bergman wrote
It is easy to get the feeling that the recursive call in
recurse = do { f x
should be using something else such as GHC.
As I see it the problem is basically that of tail recursion
removal or as David Bergman calls it last call optimisation.
Specifically:
David Bergman wrote
It is easy to get the feeling that the recursive call in
recurse = do { f x
16, 2002 9:18 AM
To: David Bergman
Cc: 'Richard Uhtenwoldt'; [EMAIL PROTECTED]
Subject: Re: Running out of memory in a simple monad
David Bergman [EMAIL PROTECTED] writes:
Note: In an unoptimized scenario, such as
with Hugs, you do indeed run out of memory in your loop
(after some
I seldom post things here, but Fritz, you are a genius!
/David
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Bernie Buddha wrote:
Announcing buddha version 1.0
-
www.cs.mu.oz.au/~bjpop/buddha
A declarative debugger for Haskell 98. It is based on program
transformation and works with GHC 5 and 6.
buddha offers a declarative debugging algorithm and a
I have not seen any Haskell metacatamorpishm library, for banana split
constructions.
Would it not be a good start for a Template Haskell-specific library? In
fact, is there a plan to create a Template Library for Template Haskell,
somewhat homologous to the STL in C++?
/David
Stefan wrote:
[snip]
Isn't it O(min(m,n))? You don't have to look at all
elements for the
intersection. Eg:
{0,1,10}
{0,3,98,183,398,1038,5319,7642,9811,13893,93123}
O(f) describes the worst case of the algorithm. It is O((m,n)-m+n).
The average cost may be lower, but it
Sebastian wrote:
Sean L. Palmer wrote:
Besides, the idea would be not to use nbsp, but rather
some indent
paragraph tag.
This is kind-of a cool idea. If I ever take a course involving writing
my own language I'll be sure to incorporate this idea.
This idea of an indent paragraph tag
Sean wrote:
Joking aside, surely you intelligent people realize that the internals
of a file format have nothing whatsoever to do with the user interface
of the editing tool. Something like this would be completely
transparent *if* you used the right tools.
But then you would be forced
Ben wrote:
I wrote:
Ben, it seems that you are having a quite fruitful discussion with yourself
;-)
I will just wait here for a more conclusive form of your
backward-propagating linear parameter.
/David
___
Haskell mailing list
[EMAIL PROTECTED]
Mr. Ozone wrote:
[snip]
So at the moment, many Haskellers will append the type name to the
function to indicate that it only works on that particular data type.
In this respect, Haskell is at a disadvantage vs most object-oriented
languages, because in them, you can write x.add, and the
Gabriel wrote:
| This overloading by namespace is usually called either ADL
| (Argument-Dependent Lookup) or Koenig Lookup (especially in C++.)
Actually in C++, it is called argument dependent name
lookup, and that is the way the C++ definition text calls
it. As Andy Koenig has himself
Andre Ozone wrote:
On 27/02/2004, at 9:51 AM, David Bergman wrote:
So at the moment, many Haskellers will append the type name to the
function to indicate that it only works on that particular
data type.
In this respect, Haskell is at a disadvantage vs most
object-oriented
Yaron,
This is probably out-of-topic, but: are you, or have you considered, using
the .NET implementation of OCaml. I managed - painstakingly - to integrate
it into a toy .NET project of mine, using .NET Direct3D, and see some virtue
in that combination.
If only we Haskellers would be as lucky:
Yaron wrote:
I've been following OCaml/.NET integration, and it does seem
potentially quite interesting, particularly in a business
environment like ours where all of the traders use Windows
machines. Which .NET implementation did you look at, OCamIL? Or F#?
F#
I wish there was an
27 matches
Mail list logo
