Re: [Haskell-cafe] Why Not Haskell?

2006-08-04 Thread Kaveh Shahbazian

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 marketers for "the companies". Let all those guys
continue to bulk their noisy space!
But again "why not haskell?".
I think - this is my opinion according to my experiences and abilities
and I know they are not the best ones; I only try to participate in
this discussion which is important to me - the main reasons are two:
1 - monads : there must be something to make a clear tool for a
none-mathematician programmer. (I still have understanding problems
with them).
2 - there must be an easy way to include existing libraries. There are
many stable libraries in CPAN for perl, implemented in C for example.
And why not to have a system for writing C in haskell? Or an easy
interface for using these codes without reimplementing haskell
identities in C?
Thanks all
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Monad Imparative Usage Example

2006-08-04 Thread Kaveh Shahbazian

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, Kaveh Shahbazian wrote:
> Haskell is the most powerfull and interesting "thing" I'v ever
> encountered in IT world. But with an imparative background and lack of
> understanding (because of any thing include that maybe I am not that
> smart) has brought me problems. I know this is an old issue. But
> please help it.
> Question : Could anyone show me a sample of using a monad as a
> statefull variable?
> For example see this code in C# :
> //
> public class Test
> {
> int var;
> static void Fun1() { var = 0; Console.Write(var); }
> static void Fun2() { var = var + 4; Console.Write(var); }
> static void Main() { Fun1(); Fun2(); var = 10; Console.Write("var
> = " + var.ToString()); }
> }
> //
> I want to see this code in haskell.

As other people have noted, you probably don't want to to see this code
in Haskell. It's possible to translate stateful code in a 1-1 style but
that's not really the point. You'll not get much of the advantages of
the language if you do that.

You can certainly use console IO etc but for your object containing
mutable state, well in a functional style you'd simply not do that and
solve the problem in a different way.

That's why you see the code people have suggested as translations are
bigger than the code you started with, because the language is not
naturally imperative.

So the trick is to solve your problem in Haskell, not translate your
imperative solution to Haskell.

Duncan



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


Re: [Haskell-cafe] Monad Imparative Usage Example

2006-08-04 Thread Kaveh Shahbazian

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 Stewart wrote:
...
> Of course, if you're learning Haskell, you should probably try to
> /avoid/ mutable variables for a while.

Along the same line, I note that proposed solutions seem to use
features relatively recently added to the language, is that true?
StateT requires multi-parameter type class, for example, so it
can't have been there all along.  MVar is pretty new, isn't it?
IORef must be the oldest of them, but hardly there from the start,
I suspect.

To learn core concepts, maybe it's a good idea to stay away
from GHC in the beginning, and use Hugs or something that tends
not to be so much of a magnet for new features.  That forces you
to look for a solution on the terms of the basic language concepts.

Donn

___
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] Why Not Haskell?

2006-08-04 Thread ajb
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 10 years ago probably does, but the compiler will crash.

Even compiling a fully conforming ISO C++ standard library generally
requires a compiler from at most three years ago.

Generally speaking, any C++ application that was written 10 years ago
and hasn't been rewritten avoids large parts of the standard library
precisely because it was so poorly supported, and what was supported
was poorly implemented.  (That's why Qt looks like it does.)

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


Re: [Haskell-cafe] Why Not Haskell?

2006-08-04 Thread ajb
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 also well-understood to be inadequate for programming-
in-the-large.  100k lines, by the way, isn't "large".  1M lines is
"large".  10M+ lines is "very large".

Large or very large programs tend to use one or more varieties of
componentisation (e.g. higher-level scripting layer, plugins,
COM/CORBA/.NET), which is arguably at a strictly higher level than OO.

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


Re: [Haskell-cafe] Why shouldn't variable names be capitalized?

2006-08-04 Thread Lennart Augustsson
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 choice.  There are other ways to mark what is a variable and  
what is not.  I don't necessarily think that Haskell did it the best  
way, but then this is a minor syntactic issue.  Changing the case of  
variables is a pretty low price to pay to solve this problem.


-- Lennart


On Aug 4, 2006, at 13:12 , 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 belong in the language definition (it belongs in the user's  
coding standards). I get annoyed, for example, that when I write  
code that manipulates matrices and vectors, I can't refer to the  
matrices with capital letters as is common in the literature. And  
to anyone who says that it's good to enforce naming consistency, I  
have this to say: Any language that requires me to learn about  
category theory in order to write imperative code should treat me  
like an adult when it comes to the naming of variables as well. ;-)


2. It makes it easier to write the compiler. I don't think I need  
to explain why this is bad...


I imagine that someone is just itching to "sort me out". Do your  
worst! ;-)


Thx
Martin
___
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] Why shouldn't variable names be capitalized?

2006-08-04 Thread Brian Hulley

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 belong in the language definition (it belongs in the user's
coding standards).


If everyone uses the same coding standards it's easier to understand other 
people's code. Also, if you're working in a team you'd usually have to agree 
to adhere to someone else's idea of how to name identifiers which you might 
find really irritating, whereas with Haskell there is at least some global 
common ground that has already been established so there would be less 
reasons to get irritated with actual people! ;-)



I get annoyed, for example, that when I write code
that manipulates matrices and vectors, I can't refer to the matrices
with capital letters as is common in the literature.


But you also can't write things like:

  v' = M v

in a general purpose programming language and expect it to be interpreted as 
v' = M * v.



And to anyone
who says that it's good to enforce naming consistency, I have this to
say: Any language that requires me to learn about category theory in
order to write imperative code should treat me like an adult when it comes 
to

the naming of variables as well. ;-)


But it does! Haskell realises that as an adult you are more interested in 
getting as much feedback about the correctness of your program as possible, 
rather than glossing over possible errors to maintain an illusory world 
where the lure of extra choices magnifies childish whimsy! ;-)




2. It makes it easier to write the compiler. I don't think I need to
explain why this is bad...


Why would you say this? If it's easier to write the compiler the chances 
are:


a) The compiler will have a simpler and cleaner design
   a1) There will be less bugs in the compiler
   a2) It is easier to modify so more language improvements can be explored
b) More people will be motivated to write or modify compilers or other 
language-processing tools leading to improvements in the language and better 
development environments




I imagine that someone is just itching to "sort me out". Do your
worst! ;-)


The extra coding confidence you gain by having a fixed capitalisation rule 
probably allows you to feel more relaxed when coding so I would not be 
surprised if the capitalisation rule leads to health benefits and therefore 
a feeling of peace, well-being, and goodwill towards other coders because 
either one is in agreement or else there is a common enemy namely the rule 
that cannot be changed! ;-)


All we can do is pity those poor C++ souls locked in an abyss of inflated 
personality, case conflicts, chronic anxiety, and bug ridden code...


Best regards, Brian.

--
Logic empowers us and Love gives us purpose.
Yet still phantoms restless for eras long past,
congealed in the present in unthought forms,
strive mightily unseen to destroy us.

http://www.metamilk.com 


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


Re: [Haskell-cafe] fast image processing in haskell?

2006-08-04 Thread Chris Kuklewicz

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 are
all labelled 'unsafe'. The image is passed to Haskell as a Ptr Word8.

To blit this to the screen (via Gtk2Hs) I do the following:

data Cam = Cam { snap_width   :: !Int
  , snap_height  :: !Int
  , snap_bytespp :: !Int
  , snap_size:: !Int
  , cam_img  :: Ptr Word8
  , cam_obj  :: ForeignPtr ()
  }

do (PixbufData _ dst _) <- (pixbufGetPixels pixbuf :: IO (PixbufData Int 
Word8))

copyBytes dst (cam_img cam)

This achieves the desired throughput (25-29fps.) However, I am at a
bit of a loss how to do something similar for preprocessing the data
in Haskell before blitting the data (whilst also retaining some
semblance of functional programming...)

Currently, I have:

cam_snap cam f x
   = do let loop (r:g:b:rest) n x = f r g b n x >>= loop rest (n+3)
loop _ _ x= return x
px <- peekArray (snap_size cam) (cam_img cam)
loop px 0 x

cam_snap2 cam f x
   = let loop ptr n x
 | n >= snap_size cam
 = return x
 | otherwise
 = do let ptrs = scanl plusPtr ptr [1,1]
  [r,g,b] <- mapM peek ptrs
  f r g b n x >>= loop (ptr `plusPtr` 3) (n+3)
 in loop (cam_img cam) 0 x

do ...
   let sum_px r g b _ (sr,sg,sb) = return (sr+r,sg+g,sb+b)
   sum <- cam_snap (cam ui) sum_px (0.0,0.0,0.0)
   print sum

cam_snap only processes at 5 fps, whereas cam_snap2 operates at 6fps.

Any suggestions?



I suggest trying something, using "/usr/bin/ghc -O3 -optc-O3" like this:


{-# OPTIONS_GHC -funbox-strict-fields #-}

import Foreign
import Control.Monad

data Cam = Cam { snap_width   :: !Int
   , snap_height  :: !Int
   , snap_bytespp :: !Int
   , snap_size:: !Int
   , cam_img  :: Ptr Word8
   , cam_obj  :: ForeignPtr ()
   } 



type F = Word8 -> Word8 -> Word8 -> Int -> Int -> Int

{-# INLINE cam_snap_3 #-}
cam_snap_3 :: Cam -> F -> Int -> IO Int
cam_snap_3 cam f x =
  let end = snap_size cam
  loop ptr n x | ptr `seq` n `seq` x `seq` False = undefined
   | n >= end = return x
   | otherwise = do 
r <- peek ptr

g <- peek (advancePtr ptr 1)
b <- peek (advancePtr ptr 2)
loop (advancePtr ptr 3) (n+3) (f r g b n x)
  in loop (cam_img cam) 0 x

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


[Haskell-cafe] Type hackery help needed!

2006-08-04 Thread Niklas Broberg

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 unnecessary bits so the following
will be a bit abstract, but it shows the gist of the problem.

I have two overloaded functions - one I call 'build' that creates
values from subparts, and one I call 'embed' that turns values into a
form appropriate to call 'build' on. What they really represent is
creating values of some XML tree structure, with embed making sure
that the children are of the right type. Conceptually, we could
imagine that these two functions to be defined as


class Build x c | x -> c, c -> x where
 build :: String -> [c] -> x

class Embed a b where
embed :: a -> b


They would be used together as in e.g.


p c = build "p" [embed c]


This works pretty well, the fundep x -> c tells me what b should be,
assuming I infer a proper type for the result of the composition. The
type of p is then

 p :: (Embed a c, Build x c) => a -> x

where the c in the middle is determined by x via the fundep.

My problems arise because I want to start nesting these to form tree
structures, as in


tree = p (p "foo")


Expanding the definition of p, the argument to the outer call to build is now

 embed $ build "p" [embed "foo"] :: (Embed String c, Build x c, Embed
x x1) => x1

Through the fundep on the outer build I can infer what x1 should be,
but there's no way I can infer x (without inserting an explicit type
signature which is out of the question). This problem is probably
unsolvable in general, but for my particular problem there are some
restrictions that makes me feel there should be a clever way of
working with classes and fundeps to make this all work out. I just
can't seem to find one.

These are the rules that the setup must obey:

* A value of any type should be embeddable inside a build expression
of any result type, i.e. a -> b or b -> a cannot hold on Embed in
general.
* The exception to the above is that if an expression using 'build' is
embedded inside an outer 'build', as in 'tree' above, the inner build
should have the same result type as the outer build (in a sense
forming b -> a only for types instantiating Build). In other words,
children of an xml element must be of the same type as their parent,
even before the call to embed.
* However, it would be nice, but probably not crucial, if by using
explicit type signatures where I want to, I could actually embed
values of "other" xml types than the outer one I am embedding them in,
and letting embed convert them to xml of the correct type. I suspect
this cannot be.

The types of build and embed are negotiable, and certainly the type
classes, as long as the two can be used together in roughly the same
way as indicated above. The calls to build and embed will be
autogenerated by a preprocessor from a HSP-style XML syntax, e.g.

<% c %>  <==> build "p" [embed c]

and for this reason any solution *must* be syntactically expressible
as expressions on a form similar to the above, but those expressions
can be arbitrarily convoluted. For instance in my failed attempts so
far I have used let expressions around build to form self-recursive
versions to "pass a type" down through the evaluation, as in

p c = let x = build "p" [embed x c] in x

This is an ok solution syntactically, if only it solved the problem, I
still can't see how to propagate it to the next level of build. :-(

Is there anyone out there with the proper type class fu who can see a
way out for me? Is this even possible to do at all? If yes, tell me
please, and if not, I would be most interested in seeing why it cannot
work. Any and all comments are welcome.

Thanks for reading this long :-)

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


Re: [Haskell-cafe] Why shouldn't variable names be capitalized?

2006-08-04 Thread John Meacham
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 compile-time error.


This is a very important property that I wouldn't be willing to give up. 

also, it is nice for a human to not have to know what is imported to be
able to locally determine what a function does to some degree. this
would not be possible if you couldn't tell what was a constructor and
what was a variable locally. heck, you can't even tell what is being
defined. think of

x + y * z = ...


this could be declaring three top level names, x,y, and z  or the
function (+) or perhaps even just y and x and not z (or even a couple
more possibilities) depending on which were constructors and which were
variable names which you cannot determine without examining every
import. not even being able to tell what values an expression is
defining is a pretty bad quality :)


John


-- 
John Meacham - ⑆repetae.net⑆john⑈
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Why shouldn't variable names be capitalized?

2006-08-04 Thread Udo Stenzel
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 ambiguities.  Well, I suppose you know a
bit of C++.  So what do you think this is:

*> int *foo ;

It's the declaration of a pointer to 'int' named 'foo', isn't it?  now
what's this:

*> x * y ;

*Obviously* this mulplies x and y and throws the result away, doesn't
it?

Now look more closely.  Do you see it?  Or does it get more blurred the
closer you look?  We don't have this problem in Haskell, and in a sane
world, C++ shouldn't have it either.

If you find second-guessing the programmer funny, try to write a parser
for C++.  You will have so much fun, it's almost impossible to describe.


Udo.
-- 
Even if you're on the right track, you'll get run over if you just sit there.
-- Will Rogers


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


RE: [Haskell-cafe] REALLY simple STRef examples

2006-08-04 Thread Simon Peyton-Jones
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. ST s Int)
c   with Int

In H-M that's impossible, because you can't instantiate a type variable
(b) with a polytype (forall s. ST s Int).  GHC will now let you do that
(a rather recent change), but in this case it's hard to figure out that
it should do so.  Equally plausible is to instantiate b with (ST s'
Int), where s' is a unification variable.

One way to make this work is to look at $'s first argument first. Then
it's clear how to instantiate b.  Then look at the second argument.  But
if you look at the second argument first, matters are much less clear.
GHC uses an algorithm that is insensitive to argument order, so it can't
take advantage of the left-to-right bias of this example.

It's unfortunate that such a simple-looking piece of code actually
embodies a rather tricky typing problem!  Of course there is no problem
if you don' use the higher order function $.  Use parens instead

x = runST (return 1)

Simon


| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
| Chad Scherrer
| Sent: 19 July 2006 23:02
| To: haskell-cafe@haskell.org
| Subject: [Haskell-cafe] REALLY simple STRef examples
| 
| I've looked around at the various STRef examples out there, but still
| nothing I write myself using this will work. I'm trying to figure out
| how the s is escaping in really simple examples like
| 
| x = runST $ return 1
| 
| y = runST $ do {r <- newSTRef 1; readSTRef r}
| 
| Neither of these works in ghci - they both say
| 
| :1:0:
| Inferred type is less polymorphic than expected
|   Quantified type variable `s' escapes
|   Expected type: ST s a -> b
|   Inferred type: (forall s1. ST s1 a) -> a
| In the first argument of `($)', namely `runST'
| In the definition of `it':
|...
| 
| I thought maybe I needed to replace 1 with (1 :: Int) so the state
| representation didn't force the type, but it still gives the same
| result.
| 
| Can someone point me to the simplest possible runST example that
| actually works? Thanks!
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: Re[2]: [Haskell-cafe] a bunch of newbie questions

2006-08-04 Thread Brian Hulley

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 type of the form A -> B:



cool :: Int
cool :: Char -> String



class Cool -- Ooops! fundamental problem encountered ;-)


class Cool a where
   cool :: a

instance Cool Int
instance Cool (Char -> String)

?


Yes thanks - someone else pointed this out to me off-list as well.
I think that mental block must have been caused by watching too many 
episodes of Star Trek yesterday!

Ok I give up, there's just no excuse... ;-)

Brian.

--
Logic empowers us and Love gives us purpose.
Yet still phantoms restless for eras long past,
congealed in the present in unthought forms,
strive mightily unseen to destroy us.

http://www.metamilk.com 


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


[Haskell-cafe] fast image processing in haskell?

2006-08-04 Thread Jeff Briggs

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 'unsafe'. The image is passed to Haskell as a Ptr Word8.

To blit this to the screen (via Gtk2Hs) I do the following:

data Cam = Cam { snap_width   :: !Int
  , snap_height  :: !Int
  , snap_bytespp :: !Int
  , snap_size:: !Int
  , cam_img  :: Ptr Word8
  , cam_obj  :: ForeignPtr ()
  }

do (PixbufData _ dst _) <- (pixbufGetPixels pixbuf :: IO (PixbufData Int Word8))
copyBytes dst (cam_img cam)

This achieves the desired throughput (25-29fps.) However, I am at a
bit of a loss how to do something similar for preprocessing the data
in Haskell before blitting the data (whilst also retaining some
semblance of functional programming...)

Currently, I have:

cam_snap cam f x
   = do let loop (r:g:b:rest) n x = f r g b n x >>= loop rest (n+3)
loop _ _ x= return x
px <- peekArray (snap_size cam) (cam_img cam)
loop px 0 x

cam_snap2 cam f x
   = let loop ptr n x
 | n >= snap_size cam
 = return x
 | otherwise
 = do let ptrs = scanl plusPtr ptr [1,1]
  [r,g,b] <- mapM peek ptrs
  f r g b n x >>= loop (ptr `plusPtr` 3) (n+3)
 in loop (cam_img cam) 0 x

do ...
   let sum_px r g b _ (sr,sg,sb) = return (sr+r,sg+g,sb+b)
   sum <- cam_snap (cam ui) sum_px (0.0,0.0,0.0)
   print sum

cam_snap only processes at 5 fps, whereas cam_snap2 operates at 6fps.

Any suggestions?

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


Re[2]: [Haskell-cafe] Why Not Haskell?

2006-08-04 Thread Bulat Ziganshin
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,
 Bulatmailto:[EMAIL PROTECTED]

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


Re: [Haskell-cafe] Why Not Haskell?

2006-08-04 Thread Bulat Ziganshin
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 and/or data base interaction. But it seems there are
> several user interfaces and SQL and other data base interfaces for
> Haskell, even though the tutorials don't seem to cover this.

i've seen a paper which lists 7 (as i remember) causes of small
Haskell popularity, including teaching, libraries, IDEs and so on. may
be someone will give us the url

i personally think that Haskell in its current state is appropriate
for system programming

> 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 once analyzed why C++ and not Eiffel or Modula-2 becomes the
language of 90's. my conclusion was what C and C++ becomes a tandem at
the late 80's - C raised popularity because it had OOP successor while
C++ becomes popular because it had imperative predecessor. Pascal,
Modula-2 or Eiffel was great languages, but they don't form such
tandems. So, now we have 3 million of Java programmers just because C was
a great tool for writing DOS apps :)

> Now I'm trying to come up with a business model for my algorithm and to
> avoid the mistakes I made 10 years ago. There is a lot of difference
> between a prototype and a working tool, and then there is a lot of
> difference between a working tool and a successful commercial
> application. Probably it doesn't make much sense to try and develop a
> tool in C++ or even Java, but if I have to go on my own on this, maybe
> Haskell could be feasible, both for fun and profit.

if speed isn't critical, if you don't need to use many libs, don't
need help from RAD tools in developing UI of your program - you can
use Haskell, imho


-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

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


Re[2]: [Haskell-cafe] a bunch of newbie questions

2006-08-04 Thread Bulat Ziganshin
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 -> B:

> cool :: Int
> cool :: Char -> String

> class Cool -- Ooops! fundamental problem encountered ;-)

class Cool a where
cool :: a

instance Cool Int
instance Cool (Char -> String)

?


-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

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


Re: [Haskell-cafe] Why Not Haskell?

2006-08-04 Thread Udo Stenzel
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 ago support today's programs?
No.  C++ of 10 years ago probably does, but the compiler will crash.
Similar for C, similar for Perl, and the question cannot even be asked
for Java.  So no, that's *not* the reason for low acceptance.

The right question would be, does Haskell of today support the programs
from 15 years ago?  Mostly it does, with minor changes.  The bitrot
isn't worse than in other languages.

> 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.

Closer to reality is:  People know that *some* 100 kLoC OO programs in
C++ have not yet crumbled under their own weight.  However, most have.
Is that track record worth imitating?  Well, "decision makers" seem to
think so...  Anyway, *some* 10 kLoC Haskell programs are also still
standing upright (no, I didn't forget a zero).

 
> Yes, trying to meet deadlines with untrusted tools is scary business.

...and so is trying to meet deadlines with trusted tools.  Paraphrasing
Paul Graham: if you do what everyone does, you get average results.  The
average result is blowing your budget by a factor of 2 (or 3), missing
your deadline (twice) and delivering a broken product (if anything).

> Not everyone likes to gamble with their jobs :)

Yet everyone does...


Udo.
-- 
The most happy marriage I can imagine to myself would be the union of a
deaf man to a blind woman.  -- Samuel Taylor Coleridge


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


Re: [Haskell-cafe] Why Not Haskell?

2006-08-04 Thread Henning Thielemann

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 source (or
> source for whatever distro you're using) and looking in the directories for
> each package. For example the base package uses a BSD-style licence and HaXml
> uses LGPL with the exception to allow static linking.

A license which requires programmers to disclose their sources shouldn't
be a problem for a commercial application. Which C hacker would or could
steal code from it? :-)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Why Not Haskell?

2006-08-04 Thread Donn Cave
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 the internet and said,
> "Gee, I can't find any commercial Haskell applications on the Internet.
> There must be a reason for that, so I better use something else."

Or maybe they're more clever than you imagine, and they all have rooms
full of Haskell programmers sworn to secrecy, trying to get a jump on
the competition.  Wouldn't it be funny if it turned out that the Python
stuff at Google was just a side-show, and Haskell was really the big
development language all along?  (Not true, I'm sure - you could sort
of stand a chance of starting a secret Python development project, but
Haskell I doubt.)

Donn

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


Re: [Haskell-cafe] Why shouldn't variable names be capitalized?

2006-08-04 Thread Tony Finch
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 constructor/variable ambiguity introduces a nasty maintenance
headache: what if you upgrade to a new version of a library which
introduces a new constructor which happens to be the same as a variable
you have been using? Suddenly the meaning of your functions changes!

Tony.
-- 
f.a.n.finch  <[EMAIL PROTECTED]>  http://dotat.at/
FISHER: WEST OR NORTHWEST 4 OR 5 BECOMING VARIABLE 3 OR 4. FAIR. MODERATE OR
GOOD.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Why shouldn't variable names be capitalized?

2006-08-04 Thread Martin Percossi

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 Haskell
   Committee. We wanted the user to have as much freedom as possible,
   while avoiding any form of ambiguity. So we carefully defined
   a set of lexemes for each namespace that were orthogonal
   when they needed to be, and overlapped when context was sufficient
   to distinguish their meaning. As an example of overlap, capitalised
   names such as Foo can, in the same lexical scope, refer to a
   type constructor, a data constructor, and a module, since whenever
   the name Foo appears, it is clear from context to which entity it
   is referring. As an example of orthogonality, we designed normal
   variables, infix operators, normal data constructors, and infix data
   constructors to be mutually exclusive.

   We adopted from Miranda the convention that data constructors are
   capitalised while variables are not; and added a similar convention
   for infix constructors, which in Haskell must start with a colon. ...

The key point here is that we wanted data constructors to be 
orthogonal to formal parameters.  For example, in:


foo x y = ...

We know that x and y are formal parameters, whereas if they were 
capitalized we'd know that they were constructors.  Some of us had had 
experience with ML where this distinction is not made, and we didn't 
like that.  There are surely other ways to achieve this, but 
captilization was one of the least painful, as we saw it.


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!!! ;-)


2) Note that this is not a compiler issue -- the compiler won't have 
much problem either way -- but it is a readability issue.


Ok - that's what I suspected - contrary to some of the other replies 
which seem to imply that it would cause big problems in the compiler. 
While I have never written a compiler of anything near the complexity of 
haskell (I just about managed an awk-like language! ;-), you still feel 
that it shouldn't be that difficult to handle these cases.


3) I suspect that you are mostly kidding, but Haskell doesn't require 
you to know any category theory to write imperative code!


True again - but I think you understood the general gist.


I hope this helps,   -Paul


It does, thanks for your time. And now I will stop complaining! ;-)

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


Re: [Haskell-cafe] Why Not Haskell?

2006-08-04 Thread Brian Hulley

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 
a really solid collections library that's as well thought out as C++ STL 
because although there are several competing collections libraries, each 
allowing fast development of powerful code, they all have various faults and 
limitations and I hate the idea of my code resting on half-baked 
foundations. I'm also a rabid perfectionist (and extremely fussy with regard 
to code aesthetics) when it comes to these kind of things so perhaps it's my 
fault.


Perhaps it's also because Haskell raises your expectations regarding what a 
good program should be like, so it's easy to get lost in abstraction. Eg 
last week all I needed was an equivalent of the C++ std::vector but I've 
wasted the whole of this week trying to create the perfect factoring of 
collection classes to try and avoid having concrete types everywhere and to 
be a foundation for all the uses of collection types in my program, and now 
I'm totally lost in a miasma of undecidable instances and difficult 
decisions.



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.


I think it's fast enough. There's also a very good foreign function 
interface if you need to get the full speed of C for some inner loop. And a 
bonus is that as more and more people use it, it's likely that more effort 
will be done to make it faster.



2) Input and output are not good enough, in particular for graphical
user interfacing and/or data base interaction. But it seems there are
several user interfaces and SQL and other data base interfaces for
Haskell, even though the tutorials don't seem to cover this.


You just need to check the licences for the various bindings and also the 
licences for the C libs they're bound to so you don't end up with a GPL 
infested program. WxWidgets uses LGPL with the linking exception so it 
should be 100% safe and easy to use 
(http://wxhaskell.sourceforge.net/license.html ). Gtk2Hs uses the LGPL 
according to http://haskell.org/gtk2hs/overview/ but it does not appear to 
admit the linking exception though this is not insurmountable - it just 
means you need to supply an object file of your code along with your exe 
(and if you use Unix there's no trouble at all because the lib is linked 
dynamically iirc)



3) Haskell is not scaleable for commercial use. This looks unlikely to
me, but could this be a factor?


It can be difficult to know how to organise a large program in Haskell if 
you're used to OOP but I don't think there are any limits on scalability per 
se - GHC is itself an example of a very large Haskell program that's widely 
used on many platforms.



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 source (or 
source for whatever distro you're using) and looking in the directories for 
each package. For example the base package uses a BSD-style licence and 
HaXml uses LGPL with the exception to allow static linking.
It would be good if this info was also on the wiki somewhere but if it is I 
can't find it, or if there was a tool to identify or gather together the 
various licenses and create a composite license (eg including the list of 
the names of all contributors who want to be mentioned) to distribute with 
your app (a free lawyer implemented in Haskell together with its own 
self-generated license!!!).


If you're going to release your app on Windows using GHC you'll need to 
prepare an object file to distribute along with your exe to satisfy the 
annoying LGPL linking restriction imposed by the GMP library that's 
currently part of the statically linked runtime, but this shouldn't be an 
obstacle once you've written the appropriate batch file to generate it.


(There's a thread on the ghc users mailing list indicating that GMP might be 
removed from GHC at some point which would make life even easier - see 
http://www.haskell.org/pipermail/glasgow-haskell-users/2006-August/010665.html )


[snip]


Why hasn't Haskell made it into the business world (yet), after being
available for 15 years, or is this the wrong question?


This might just be because computers were too slow in the past to run 
programs written in such high level languages as Haskell, so everyone had to 
use low-level languages like C and C++ (people even now still spend 
sleepless nights debating whether or not to use a virtual function in a C++ 
class because of the extra indirection it requires).


Also, the bottom line imho is that Haskell is a difficult language to 
understan

Re: [Haskell-cafe] Why Not Haskell?

2006-08-04 Thread Udo Stenzel
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 commercial Haskell applications on the Internet.
There must be a reason for that, so I better use something else."


> 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?

Yah.  2.995 million programmer-wannabes were too lazy to think for
themselves and choose what everybody uses.

 
> Probably it doesn't make much sense to try and develop a
> tool in C++ or even Java, but if I have to go on my own on this, maybe
> Haskell could be feasible, both for fun and profit.

It never makes sense to limit yourself to only one programming language,
even if it happens to be Haskell.  There's always the FFI, should it
turn out that some part is better done in C or assembly or Fortran or
whatever comes to mind.


Udo.
-- 
The two most abundant things in the universe are hydrogen and
stupidity. -- Harlan Ellison 


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


Re: [Haskell-cafe] Why shouldn't variable names be capitalized?

2006-08-04 Thread Paul Hudak

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 carefully defined
   a set of lexemes for each namespace that were orthogonal
   when they needed to be, and overlapped when context was sufficient
   to distinguish their meaning. As an example of overlap, capitalised
   names such as Foo can, in the same lexical scope, refer to a
   type constructor, a data constructor, and a module, since whenever
   the name Foo appears, it is clear from context to which entity it
   is referring. As an example of orthogonality, we designed normal
   variables, infix operators, normal data constructors, and infix data
   constructors to be mutually exclusive.

   We adopted from Miranda the convention that data constructors are
   capitalised while variables are not; and added a similar convention
   for infix constructors, which in Haskell must start with a colon. ...

The key point here is that we wanted data constructors to be orthogonal 
to formal parameters.  For example, in:


foo x y = ...

We know that x and y are formal parameters, whereas if they were 
capitalized we'd know that they were constructors.  Some of us had had 
experience with ML where this distinction is not made, and we didn't 
like that.  There are surely other ways to achieve this, but 
captilization was one of the least painful, as we saw it.


2) Note that this is not a compiler issue -- the compiler won't have 
much problem either way -- but it is a readability issue.


3) I suspect that you are mostly kidding, but Haskell doesn't require 
you to know any category theory to write imperative code!


I hope this helps,   -Paul


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 belong in the language definition (it belongs in the user's 
coding standards). I get annoyed, for example, that when I write code 
that manipulates matrices and vectors, I can't refer to the matrices 
with capital letters as is common in the literature. And to anyone who 
says that it's good to enforce naming consistency, I have this to say: 
Any language that requires me to learn about category theory in order 
to write imperative code should treat me like an adult when it comes 
to the naming of variables as well. ;-)


2. It makes it easier to write the compiler. I don't think I need to 
explain why this is bad...


I imagine that someone is just itching to "sort me out". Do your 
worst! ;-)


Thx
Martin



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


Re: [Haskell-cafe] Why shouldn't variable names be capitalized?

2006-08-04 Thread Brandon Moore

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 
syntax just wouldn't work without a lexical distinction between type 
names and type variables. Is (Int -> Int) supposed to be polymorphic

with a type variable named "Int", or is it talking about a type "Int"?
Perhaps you'd be happier reserving names beginning with apostrophes for
variables? I think case is a bit easier to see - subattentive visual 
processing, and all that.


Mostly, case is used so you know what basic sort of thing some object
is, without reviewing everything in scope. Mathematicians
use typesetting similarly to tell basic kinds of things appart.

Imagine a mathematician complaining that he was forced to learn category 
theory to get a degree, and people still don't let him use letter with 
an arrow over it to denote a scalar quantity. It's just that ascii is 
more restricted, so we don't have things like fonts, greek letters, and 
accents.


Lexical syntax is the least important kind of linguistic freedom.

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


Re: [Haskell-cafe] Why Not Haskell?

2006-08-04 Thread Jason Dagit

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 think of several other possible reasons -
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?
7.  Some difficult concepts, at a level that goes way beyond the commonly
used languages.
8.  Problems with evaluation model and space that other languages don't
have to deal with.
9.  Missing libraries


10.  I think most commercial applications are developed for windows
users.  For the last 15 years this has primarily meant the application
ran in windows (this is starting to change but that's another story).
I'm currently using ghc to do windows development for a company I work
at.  I'm often running into "corner" cases where ghc has bugs on
windows or poor support for some MS technology that is assumed when
using other languages like .NET.  Both COM and dlls have problems
right now (but this is getting better monotonically).

11. If you read the History of Haskell paper
(http://haskell.org/haskellwiki/History_of_Haskell) you will see that
haskell was meant as a vehicle for research.  This BTW, would be a
highly relevant read for someone that wants more insight into why
Haskell is not a Java killer.

12. Chicken and the egg.  Having lots of users will attract more users.

13. Some industry programmers don't choose their tools based on
technical worth so much as who is backing them.  I'd like to think
this explains the popularity of C++ and now Java/C#.  I have 2nd hand
information that Bjarne never meant for C++ to escape AT&T or really
even go outside of the domain he was working in (which I recall was
something embedded) but when people found out AT&T had a new OO
capable language they jumped on.  I'm not sure if it's really true,
but watching Java/C# gain popularity it wouldn't surprise me.

14. I've heard arguments that a lot of the people who become industry
devs are really turned off from functional languages during typical CS
theory courses.  I have no idea how anyone could verify this claim,
plus I had the exact opposite reaction.  I was transformed into a fan
of FP by my theory courses.

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.

There also seems to be a lack of programs in the open source world
which are written in Haskell.  We have two big open source projects
that people outside of the haskell community may hear of, pugs and
darcs.I would say this reflects #6 but I'm relatively new to
haskell so I could be wrong.

Even with all this there are some people that are using haskell
commercially (or lobbying for it).

Joel Reymount
Tim Sweeny*
Galois Connections
Myself

* I think Tim is just wanting more of haskell's great features in the
languages he already uses
(http://www.st.cs.uni-sb.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf)

Also, check the Haskell Communities and Activities Report:
http://www.haskell.org/communities/

I'm sure I missed someone.


and more, I suppose.  I'm not saying any of these are necessarily compelling
reasons not to use Haskell, but altogether, maybe another way to look at it
is that it's really a strong statement when people decide to bet their
livelihood on Haskell software development - it isn't the safe choice, and
it means someone finds the reasons for it very compelling.


Yes, trying to meet deadlines with untrusted tools is scary business.
Not everyone likes to gamble with their jobs :)

I hope that helps,
Jason
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Why shouldn't variable names be capitalized?

2006-08-04 Thread Robert Dockins


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 - but my view is that this  
doesn't belong in the language definition (it belongs in the user's  
coding standards). I get annoyed, for example, that when I write  
code that manipulates matrices and vectors, I can't refer to the  
matrices with capital letters as is common in the literature.


This is occasionally irritating.

And to anyone who says that it's good to enforce naming  
consistency, I have this to say: Any language that requires me to  
learn about category theory in order to write imperative code  
should treat me like an adult when it comes to the naming of  
variables as well. ;-)


2. It makes it easier to write the compiler. I don't think I need  
to explain why this is bad...


Eh?  I'm not convinced this is a bad reason.  It obviously needs to  
be balanced against other competing factors, but ease of  
implementation should always a consideration when designing a language.



3. It removes a whole class of possible ambiguities from the  
language.  You the programmer (and the compiler, as an added bonus)  
can always identify the syntactic class of an identifier from _purely  
local_ context.


Suppose I remove the case restriction.  Is the following a pattern  
match or a function definition?  Is M a variable or a data constructor?


   let f x M = z M in 

You can't tell!  Worse, it could change depending on what identifiers  
are in scope.  It could happen that you import a module and it  
silently causes your function definition to change to a pattern  
match.  The situation is similar with type classes and type  
variables.  You could magically end up with an instance declaration  
that is less polymorphic than you expect (if you have extensions  
turned on).


I imagine that someone is just itching to "sort me out". Do your  
worst! ;-)


Thx
Martin



Rob Dockins

Speak softly and drive a Sherman tank.
Laugh hard; it's a long way to the bank.
  -- TMBG



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


Re: [Haskell-cafe] Why Not Haskell?

2006-08-04 Thread Brandon Moore

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) Input and output are not good enough, in particular for graphical
user interfacing and/or data base interaction. But it seems there are
several user interfaces and SQL and other data base interfaces for
Haskell, even though the tutorials don't seem to cover this.
3) Haskell is not scaleable for commercial use. This looks unlikely to
me, but could this be a factor?
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?


I wonder, how many languages have you seen commercial applications 
written in? I suppose you mean the sort of applications that might be 
sold in stores. I think a more interesting question around Haskell is 
what it takes to succeed in writing an application in a relatively 
uncommon language, what aspects of popularity are actually useful, and

how you can compensate.

What languages have gotten big without being the main language for a 
popular operating system, or pushed really hard by a big company?
Then there are moderately popular languages like perl and Python, but 
are there lots of commercial application even in those?


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


[Haskell-cafe] Why shouldn't variable names be capitalized?

2006-08-04 Thread Martin Percossi
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 language definition (it belongs in the user's coding 
standards). I get annoyed, for example, that when I write code that 
manipulates matrices and vectors, I can't refer to the matrices with 
capital letters as is common in the literature. And to anyone who says 
that it's good to enforce naming consistency, I have this to say: Any 
language that requires me to learn about category theory in order to 
write imperative code should treat me like an adult when it comes to the 
naming of variables as well. ;-)


2. It makes it easier to write the compiler. I don't think I need to 
explain why this is bad...


I imagine that someone is just itching to "sort me out". Do your worst! ;-)

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


Re: [Haskell-cafe] Why Not Haskell?

2006-08-04 Thread Donn Cave
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.  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?
7.  Some difficult concepts, at a level that goes way beyond the commonly
used languages.
8.  Problems with evaluation model and space that other languages don't
have to deal with.
9.  Missing libraries

and more, I suppose.  I'm not saying any of these are necessarily compelling
reasons not to use Haskell, but altogether, maybe another way to look at it
is that it's really a strong statement when people decide to bet their
livelihood on Haskell software development - it isn't the safe choice, and
it means someone finds the reasons for it very compelling.

Donn Cave, [EMAIL PROTECTED]

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


Re: [Haskell-cafe] a bunch of newbie questions

2006-08-04 Thread Brian Hulley

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 -> t
id x = x
b) Haskell supports ad-hoc polymorphism via type classes


Sometimes a distinction is made between ad-hoc polymorphism of the kind 
you'd get in C++ with method overloading, and "restricted parametric 
polymorphism" as in "Monad m =>" ie:


1) id :: t -> t -- Unrestricted parametric polymorphism

2) foo :: Monad m => m a -- Restricted parametric polymorphism for (m) and 
unrestricted for (a)


3) bar :: Int -> Int -> String
   bar :: Char -> Bool

   The only way to describe this is ad-hoc polymorphism, and the fact that 
any function is of the form A -> B means regardless of the arity of the 
overloaded functions it can also be supported by typeclasses (*) eg:


   class Bar a b where
   bar :: a -> b

   instance Bar Int (Int -> String) where ...
   instance Bar Char Bool where ...

And a function or value in scope can be making use of unrestricted, 
restricted, and ad-hoc polymorphism at the same time eg:


   zap :: Monad m => Char -> m a
   zap :: Int -> String -> a String

   class Zap a b where
zap :: a -> b

   instance Monad m => Zap Char (m a) where ...
   instance Zap Int (String -> a String) where ...

(*) 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 -> B:


   cool :: Int
   cool :: Char -> String

   class Cool -- Ooops! fundamental problem encountered ;-)

Regards, Brian.

--
Logic empowers us and Love gives us purpose.
Yet still phantoms restless for eras long past,
congealed in the present in unthought forms,
strive mightily unseen to destroy us.

http://www.metamilk.com 


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


[Haskell-cafe] Why Not Haskell?

2006-08-04 Thread Hans van Thiel
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 good enough, in particular for graphical
user interfacing and/or data base interaction. But it seems there are
several user interfaces and SQL and other data base interfaces for
Haskell, even though the tutorials don't seem to cover this.
3) Haskell is not scaleable for commercial use. This looks unlikely to
me, but could this be a factor?
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?

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?

The reason I ask is that in the early nineties I wrote a data mining
/machine learning program. This was not a commercial success and since
then I've been working as a free lance IT journalist. As such I covered
the O'Reilly European Open Source Convention in Amsterdam last year and
there I heard of Haskell. I became interested and started learning from
the available free tutorials and Hugs.

As an aside, I'd like to thank all those people. I really appreciate
their work and I'd like to single out Hal Daume III's 'Yet Another
Haskell Tutorial', while not diminishing the other authors in any way.

Meanwhile I kept working on a data mining algorithm in my spare time and
finally I came up with something that appears to work. While I was
learning Haskell, I thought, why not try this part of the algorithm as a
Haskell exercise. I could easily test it in Hugs.
To my own surprise, after only a few weeks of this, I had a working
prototype of my algorithm, printed out on less than 3 pages, using only
standard functions in the Prelude.

So, I'm really impressed by the power of Haskell, and I'm just a
beginner.

Now I'm trying to come up with a business model for my algorithm and to
avoid the mistakes I made 10 years ago. There is a lot of difference
between a prototype and a working tool, and then there is a lot of
difference between a working tool and a successful commercial
application. Probably it doesn't make much sense to try and develop a
tool in C++ or even Java, but if I have to go on my own on this, maybe
Haskell could be feasible, both for fun and profit.

So, that's the background of my question (while introducing myself to
the Cafe at the same time).

Why hasn't Haskell made it into the business world (yet), after being
available for 15 years, or is this the wrong question?

Many thanks for your comments,

Hans van Thiel





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


Re: [Haskell-cafe] a bunch of newbie questions

2006-08-04 Thread Martin Percossi

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 supports ad-hoc polymorphism via type classes

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


Re[2]: [Haskell-cafe] a bunch of newbie questions

2006-08-04 Thread Bulat Ziganshin
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 what (size x) is about once we've inferred, for
> other reasons, that x is an IntMap. Similarly with records, if we had

this is called ad-hoc polymorphism which is not supported by Haskell.
instead Haskell supports parametric polymorphism via type classes.
i'm not a language lawyer ;)  but thinks that difference between C++
which supports former and Haskell that supports later is the following:
C++ can infer only result type based on arguments type while Haskell
can infer in _both_ directions. i can imagine C++ type inferring
algorithm, with a little imagination i even can think about Haskell's
algorithm :)  but two-way type inferring together with ad-hoc
polymorphism make me a little nervous :)  how about, for example, two
ad-hoc-polymorphic functions: f (g x)? or dozens of such calls
enclosed? how error messages should be generated: "it may be Int::f
with Char::g or Char::f with Bool::g or ... or ... or ..." ? one more
cause is that Haskell was defined by scientists, not practical
programmers, and scientists prefer to use more systematic ways to do
the same things

nevertheless, there is no principal differences. in many cases you can
define type classes, include your ad-hoc polymorphic functions into
these classes and sleep easy. in particular, as Brian already said,
there is a proposal to use automatically generated type classes for
record fields


-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

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


Re: [Haskell-cafe] a bunch of newbie questions

2006-08-04 Thread Bulat Ziganshin
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
one. actually, in type inference algorithm, some types are already
known from context (function types if you given type declarations,
types of some results or parameters, types of global variables and
fields in datatypes) and compiler infer types of all other values
using this information

> theoretically is it possible to do a strictness
> analysis without any help from the programmer?

compiler contains such analyzer, it just not so smart as people
writing the program. in the definition

inc n = n+1

compiler infers that function is strict


-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

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


Re: [Haskell-cafe] a bunch of newbie questions

2006-08-04 Thread Brian Hulley

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 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 what (size x) is about once we've
inferred, for other reasons, that x is an IntMap. Similarly with
records, if we had field names that cause functions for extracting
the value of those fields, where we used the same field name in two
different record types, I figure that there's usually no ambiguity
because we can usually infer the type of the object to which the
'extractor' is being applied.

Am I just not seeing the big picture, or would people not find this
use of type information to resolve such ambiguities as nice as I
would, or is it harder to do that than I'm expecting?


I think this is because in Haskell the only way to overload function names 
is to use type classes and instances just as the one and only way to qualify 
an identifier is by using modules. This has the advantage that different 
concerns are clearly separated out and dealt with in exactly one place by 
one concern-specific mechanism.


Perhaps the basic problem is that (size) really belongs in a type class and 
IntMap, Set, Map etc were created before anyone bothered to try and factor 
their portions of common functionality into type classes. This factoring is 
a non-trivial problem however (as you can see from the various posts on the 
subject of sequences) since the design space is not nearly as well 
understood as basic mathematical objects like monoids, monads etc and 
without a mathematical foundation it is difficult to design a type class 
factoring with any confidence.


For record fields, I suggested a while back that the compiler could 
automatically create the relevant type classes and instances eg:


   data Point i = Point {x :: i}

would ensure that a global typeclass was created if not already present:

   class (.x) a b | a -> b where
   (.x) :: a -> b

and would also create an instance for that type:

   instance (.x) (Point i) i where
   (.x) (Point k) = k

where ".x" is parsed as a single lexeme and treated as a postfix operator 
ie:


   -- no space between '.' and fieldname
   exp .x or exp.x === (.x) exp

but
   exp . x === (.) exp x -- composition

To refer to a particular field name directly you could use:

   g = ((.x) :: Point a -> a)

but I also thought it might be nice to have a special syntax to make things 
less clunky eg:


   g = Point^x

(It could not be written as Point.x because Point is not a module name, 
unless you wanted to destroy the very simple rule that Foo.xyz qualifies xyz 
by the module Foo)


In any case with the trivial syntactic sugar above it would already be 
possible to use the same record names in multiple types simultaneously. I 
think the reason there was no positive feedback about this idea before is 
that unfortunately it looks as if the record system is to be extended to 
deal with subtyping or horrible anonymous records such as {x=5} that don't 
have an explicit value constructor in front of them instead of just 
concentrating on making the existing system (which I really like apart from 
the lack of field name overloading and dot access syntax) more usable as 
above.


For value constructors, a change in the type inference algorithm would be 
needed if they were to be resolved based on their types so you could write 
eg:


data Location = Left | Right | Up | Down
data Hand = Left | Right

foo :: Location -> Hand
foo Left = Left
foo Up = Left
foo Right = Right
foo Down = Right

and again there could be a syntax like Location^Left as a less clunky 
alternative to (Left::Location) in cases where ambiguity needs to be 
resolved explicitly eg if someone didn't want to write a top level type 
signature for their function.


Imho this would make life a lot easier because you could concentrate on 
names that are appropriate to the type without having to know about all the 
other types you'd want to use unqualified in the same scope.


Regards, Brian.
--
Logic empowers us and Love gives us purpose.
Yet still phantoms restless for eras long past,
congealed in the present in unthought forms,
strive mightily unseen to destroy us.

http://www.metamilk.com 


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


Re: [Haskell-cafe] a bunch of newbie questions

2006-08-04 Thread Mark T.B. Carroll
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 instance, when IntMap.size,
Map.size and Set.size (or whatever) are all in scope as "size", it
should be fairly obvious what (size x) is about once we've inferred, for
other reasons, that x is an IntMap. Similarly with records, if we had
field names that cause functions for extracting the value of those
fields, where we used the same field name in two different record types,
I figure that there's usually no ambiguity because we can usually infer
the type of the object to which the 'extractor' is being applied.

Am I just not seeing the big picture, or would people not find this use
of type information to resolve such ambiguities as nice as I would, or
is it harder to do that than I'm expecting?

-- Mark

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


Re: [Haskell-cafe] RE: ANN: System.FilePath 0.9

2006-08-04 Thread David Roundy
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 create the file
> > (I think, but I'm not sure).  However, what's the point in being
> > ambiguous when we can be explicit?  Sometimes there is a difference,
> > libraries and tools shouldn't gloss over that without consideration.
> 
> As I said, it's one of those line-drawing exercises.  But your points
> are well taken, and maybe the trailing delimiter should be part of the
> model.  (My criterion has been whether any filesystem operations require
> the trailing delimiter.  It sounds like with reiser4fs they might.)

Actually, I just read in LWN that that part of reiser4 has been dropped.
On the other hand, it was only dropped after considerable debate, and
people using an older version of reiser4 still have the strange
file-as-directory semantics.
-- 
David Roundy
http://www.darcs.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] a bunch of newbie questions

2006-08-04 Thread Janis Voigtlaender

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.


If there were a difference, that is, if we interpret Haskell minus 
general recursion in a somewhat simpler semantic setting, then data 
types would contain inly finite values, whereas codata types could also 
contain infinite values.



can you give me some
reference points that explain these?


Papers by Uustalu and Vene might be a good start. Watch out for 
corecursion and coalgebras.


(read "56")::Integer 



does it in fact pass the type (Integer) to the
function (read)?


No, it just says that the result of read should be an Integer.


I guess what we want is for the
(Integer) implementation of the (read) function to
evaluate, not really to cast the value of (read)
function to (Integer).


Exactly. And that's what is happening. Based on the information provided 
when giving the result type.



in the regex libraries, (~=)
cast this way results in completely different things
altogether, should type classes have namespaces
associated with them? somewhat like Integer.read "56"?


I don't think that we need this.


this way of selecting the intended implementation,
does it work without trouble with multiparameter type
classes as well?


Yes, as long as enough type information is provided for the typechecker 
to decide what is the correct instance to use. One way of reducing the 
amount of information needed is using functional dependencies.



theoretically is it possible to do a strictness
analysis without any help from the programmer?


Yes, such analyses exist, and are implemented in GHC, for example. They 
are just approximative, and cannot be exact by computability reasons.


Ciao, Janis.

--
Dr. Janis Voigtlaender
http://wwwtcs.inf.tu-dresden.de/~voigt/
mailto:[EMAIL PROTECTED]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] a bunch of newbie questions

2006-08-04 Thread Imam Tashdid ul Alam
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
(Integer) implementation of the (read) function to
evaluate, not really to cast the value of (read)
function to (Integer). in the regex libraries, (~=)
cast this way results in completely different things
altogether, should type classes have namespaces
associated with them? somewhat like Integer.read "56"?
this way of selecting the intended implementation,
does it work without trouble with multiparameter type
classes as well?

theoretically is it possible to do a strictness
analysis without any help from the programmer?

thanks a bunch in advance.

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe