I have started to love haskell and like these friends I am starting to
be annoying about "Why not haskell?" and realy realy why not haskell?
In commercial world there are buzz-oriented languages that do the
"barking to the picture" in their "communities" - which are in fact
groups of free marketer
Thanks All
This is about my tries to understand monads and handling state - as
you perfectly know - is one of them. I have understood a little about
monads but that knowledge does not satidfy me. Again Thankyou
On 8/2/06, Duncan Coutts <[EMAIL PROTECTED]> wrote:
On Wed, 2006-08-02 at 13:26 +0330
Thanks All
This is about my tries to understand monads and handling state - as
you perfectly know - is one of them. I have understood a little about
monads but that knowledge does not satidfy me. Again Thankyou
On 8/2/06, Donn Cave <[EMAIL PROTECTED]> wrote:
On Wed, 2 Aug 2006, Donald Bruce Stew
G'day all.
Quoting Udo Stenzel <[EMAIL PROTECTED]>:
> Uh, this one's wrong. Does C++ of 15 years ago support today's programs?
C++ of _today_ doesn't support today's programs in some cases. Just
ask the Boost developers about the various workarounds they still have
to deal with.
> No. C++ of
G'day all.
Quoting Jason Dagit <[EMAIL PROTECTED]>:
> 15. OO is now tried and true in industry. I would say it's far from
> optimal but people do know they can build large applications (say
> ~100k lines of C++). So naturally shifting to a new paradigm will
> meet resistance.
OO on its own is
There are two places where confusion could arise if you didn't have
the case distinction in Haskell: pattern matching (does a name refer
to a constructor or not) and type expressions (is it a type variable
or not).
In Haskell the distinction is made by case, but this is far from the
only
Martin Percossi wrote:
Hi, I'm wondering what the rationale was for not allowing capitalized
variable names (and uncapitalized type names and constructors). I can
only think of two arguments, and IMHO both of them are bad:
1. Enforces a naming convention. Fine - but my view is that this
doesn't
Jeff Briggs wrote:
Hello,
I am attempting to process images captured from a webcam. My aim is to
do so, in real time, at the frame rate of the camera. I'm using GHC
6.4.2 with -O3.
A frame consists of ~100k 24bit colour values.
The webcam is interfaced through FFI bindings to some C++ -- these
Hi fellow Haskelleers,
I have a tricky problem that I just can't seem to solve. The problem
is one of unresolved overloading, much like the (show . read) issue,
but unlike that particular problem I feel there should be a solution
to the one I'm wrestling with.
I've tried to strip away all the un
Haskell very specifically has the really vitally important property that
when you change the imports of a module in any way whatsoever, only one
of two possible results can occur
1) the module behaves identically to the way it did before.
or
2) the module fails to compile with an unambiguous compi
Martin Percossi wrote:
> Paul Hudak wrote:
> >foo x y = ...
> >
> >We know that x and y are formal parameters, whereas if they were
> >capitalized we'd know that they were constructors.
>
> I agree that naming can be abused. But I think it should be *me* ...
Oh, you like to decide lexical ambigu
Chad
| x = runST $ return (1::Int)
This code looks simple, but it isn't. Here are the types:
runST :: forall a. (forall s. ST s a) -> a
($) :: forall b c. (b->c) -> b -> c
return 1 :: forall s. ST s Int
To typecheck, we must instantiate
b with (forall s.
Bulat Ziganshin wrote:
Hello Brian,
Friday, August 4, 2006, 8:50:25 PM, you wrote:
class Bar a b where
bar :: a -> b
(*) But there's one exception: you can't use typeclasses to resolve
overloadings between values and functions because non-function
values don't have a typ
Hello,
I am attempting to process images captured from a webcam. My aim is to
do so, in real time, at the frame rate of the camera. I'm using GHC
6.4.2 with -O3.
A frame consists of ~100k 24bit colour values.
The webcam is interfaced through FFI bindings to some C++ -- these are
all labelled 'un
Hello Jason,
Friday, August 4, 2006, 10:01:31 PM, you wrote:
> 15. OO is now tried and true in industry. I would say it's far from
> optimal but people do know they can build large applications (say
> ~100k lines of C++).
it's medium size. GHC is larger :)
--
Best regards,
Bulat
Hello Hans,
Friday, August 4, 2006, 8:17:42 PM, you wrote:
> 1) Haskell is too slow for practical use, but the benchmarks I found
> appear to contradict this.
it's an advertisement :D just check yourself
> 2) Input and output are not good enough, in particular for graphical
> user interfacing
Hello Brian,
Friday, August 4, 2006, 8:50:25 PM, you wrote:
> class Bar a b where
> bar :: a -> b
> (*) But there's one exception: you can't use typeclasses to resolve
> overloadings between values and functions because non-function values don't
> have a type of the form A ->
Jason Dagit wrote:
> On 8/4/06, Donn Cave <[EMAIL PROTECTED]> wrote:
> >6. Instability - available for 15 years, you say, but does the Haskell
> >of 15 years ago support today's programs? Does standard Haskell
> >even support today's programs?
Uh, this one's wrong. Does C++ of 15 years
On Fri, 4 Aug 2006, Brian Hulley wrote:
> > 4) Haskell is open source and licensing restrictions forbid commercial
> > applications. I haven't seen any such restrictions, but is this a
> > problem for the standard modules?
>
> You can discover the licensing situation by downloading the GHC sourc
On Fri, 4 Aug 2006, Udo Stenzel wrote:
> Hans van Thiel wrote:
>> I'm wondering why I can't find any commercial Haskell applications on
>> the Internet. Is there any reason for this?
>
> Of course. Corporations are conservative to the point of being
> boneheaded. So to avoid risk, they all went
On Fri, 4 Aug 2006, Martin Percossi wrote:
>
> I agree that naming can be abused. But I think it should be *me*, the
> programmer, or in the limit ghc, the glorious compiler (but only because of
> unresolvable ambiguities), who decides it -- not *you*, the language
> implementor!!! ;-)
The ML cons
Paul Hudak wrote:
Ok, you asked for it, so here's my worst :-)
You're too gentle! I was expecting some serious community flagellation
for my heretical remarks!
1) Here's what the "History of Haskell" has to say about this:
Namespaces were a point of considerable discussion in the Haske
Hans van Thiel wrote:
Hello All,
I'm wondering why I can't find any commercial Haskell applications on
the Internet. Is there any reason for this?
I'm actually working on a Haskell program which I hope to release as a
commercial application. The biggest problem I'm encountering is the lack of
Hans van Thiel wrote:
> I'm wondering why I can't find any commercial Haskell applications on
> the Internet. Is there any reason for this?
Of course. Corporations are conservative to the point of being
boneheaded. So to avoid risk, they all went on the internet and said,
"Gee, I can't find any
Ok, you asked for it, so here's my worst :-)
1) Here's what the "History of Haskell" has to say about this:
Namespaces were a point of considerable discussion in the Haskell
Committee. We wanted the user to have as much freedom as possible,
while avoiding any form of ambiguity. So we ca
Martin Percossi wrote:
Hi, I'm wondering what the rationale was for not allowing capitalized
variable names (and uncapitalized type names and constructors). I can
only think of two arguments, and IMHO both of them are bad:
I'm not so sure about variable names and constructors, but the type
sy
On 8/4/06, Donn Cave <[EMAIL PROTECTED]> wrote:
On Fri, 4 Aug 2006, Hans van Thiel wrote:
...
> Are there other reasons why there seem to be just a few thousand
> (hundred?) Haskell programmers in the world, compared to the 3 million
> Java programmers and x million C/C++ programmers?
I can thin
On Aug 4, 2006, at 1:12 PM, Martin Percossi wrote:
Hi, I'm wondering what the rationale was for not allowing
capitalized variable names (and uncapitalized type names and
constructors). I can only think of two arguments, and IMHO both of
them are bad:
1. Enforces a naming convention. Fine
Hans van Thiel wrote:
Hello All,
I'm wondering why I can't find any commercial Haskell applications on
the Internet. Is there any reason for this?
I can think of the following possibilities only:
1) Haskell is too slow for practical use, but the benchmarks I found
appear to contradict this.
2) I
Hi, I'm wondering what the rationale was for not allowing capitalized
variable names (and uncapitalized type names and constructors). I can
only think of two arguments, and IMHO both of them are bad:
1. Enforces a naming convention. Fine - but my view is that this doesn't
belong in the languag
On Fri, 4 Aug 2006, Hans van Thiel wrote:
...
> Are there other reasons why there seem to be just a few thousand
> (hundred?) Haskell programmers in the world, compared to the 3 million
> Java programmers and x million C/C++ programmers?
I can think of several other possible reasons -
6. Instabil
Martin Percossi wrote:
Bulat Ziganshin wrote:
this is called ad-hoc polymorphism which is not supported by Haskell.
instead Haskell supports parametric polymorphism via type classes.
I think you are wrong here Bulat. In fact, I think
a) Haskell supports parametric polymorphism, e.g.
id :: t -
Hello All,
I'm wondering why I can't find any commercial Haskell applications on
the Internet. Is there any reason for this?
I can think of the following possibilities only:
1) Haskell is too slow for practical use, but the benchmarks I found
appear to contradict this.
2) Input and output are not
Bulat Ziganshin wrote:
this is called ad-hoc polymorphism which is not supported by Haskell.
instead Haskell supports parametric polymorphism via type classes.
I think you are wrong here Bulat. In fact, I think
a) Haskell supports parametric polymorphism, e.g.
id :: t -> t
id x = x
b) Haskell
Hello Mark,
Friday, August 4, 2006, 3:03:54 PM, you wrote:
> I've always been a little surprised when this doesn't happen more widely
> for things other than instances. For instance, when IntMap.size,
> Map.size and Set.size (or whatever) are all in scope as "size", it
> should be fairly obvious
Hello Imam,
Friday, August 4, 2006, 12:19:04 PM, you wrote:
>> (read "56")::Integer
> does it in fact pass the type (Integer) to the
> function (read)?
it tells the compiler that result should be of type Integer. this info
used by compiler to select among the different 'read' instances proper
o
Mark T.B. Carroll wrote:
Janis Voigtlaender <[EMAIL PROTECTED]> writes:
(snip)
Yes, as long as enough type information is provided for the
typechecker to decide what is the correct instance to use.
(snip)
I've always been a little surprised when this doesn't happen more
widely for things other
Janis Voigtlaender <[EMAIL PROTECTED]> writes:
(snip)
> Yes, as long as enough type information is provided for the
> typechecker to decide what is the correct instance to use.
(snip)
I've always been a little surprised when this doesn't happen more widely
for things other than instances. For inst
On Sat, Jul 29, 2006 at 05:35:30PM -0700, Andrew Pimlott wrote:
> On Sat, Jul 29, 2006 at 02:59:06AM +0200, Udo Stenzel wrote:
> > Andrew Pimlott wrote:
> > > Second, "foo" is just as good a directory
> > > as "foo/" to the system
> >
> > ...unless you have both (think Reiser4) or you want to crea
Imam Tashdid ul Alam wrote:
what's the difference between data and co-data
exactly? or between inductive data types and
co-inductive data types?
In Haskell there is no such difference, as inductive and coinductive
types coincide in the semantic setting in which Haskell is usually
interpreted
what's the difference between data and co-data
exactly? or between inductive data types and
co-inductive data types? can you give me some
reference points that explain these?
> (read "56")::Integer
does it in fact pass the type (Integer) to the
function (read)? I guess what we want is for the
(
41 matches
Mail list logo
