On Mon, Dec 05, 2005 at 09:08:32PM -0500, Cale Gibbard wrote:

To your second question, I'd say that Haskell isn't bad at small things. One can write a great deal of useful one-or-two-line Haskell programs. I'd consider its use in shell-scripting like tasks perhaps a little bit odd, but not really awkward at all.

For me, it isn't odd at all. I often face the some problem with traditional shell scripting using tools like awk, cut, head, tail, sort, etc - these tools are most often used in a way that is very sensitive to formats of processed (text) files. This is a dangerous kind of sensitivity, which often results in silent errors. On the other hand in Haskell, with use of libraries like Parsec, it is very easy to create a precise parser for the intended file format. Almost every divergence from the assumed format will cause the program to fail with a nice error message pointing to the problem. Of course you can do similar things with regular expression provided by tools like awk, sed and perl, but regexps don't scale to more complicated formats (regular languages vs. context-free languages).

Haskell code is generally pretty fun to write, there's usually not a lot of framework cruft that you need to write to get started on code that works.

Some Haskell libraries, like Parsec, require a bit of constant boilerplate code to use - but you can write your own library to move some of boilerplate code to one place. Recently, I was very happy when I realized that I could reduce most of my small Parsec-using programs by 5-10 lines of code this way. If you wonder what kind of functions are these, below are their signatures. I would have to ask my boss to show the actual code, but they are really quite simple, and the types tell everything. parseFile :: CharParser () a -> FilePath -> IO a parseStdIn :: CharParser () a -> IO a parseOrFail :: Monad m => GenParser tok () a -> SourceName -> [tok] -> m a lazyMany :: CharParser () a -> SourceName -> [Char] -> [a] parserToMaybeFun :: GenParser tok () a -> ([tok] -> Maybe (a, [tok])) parseWithText :: CharParser st a -> CharParser st (a, String) With these some programs become really simple: import ... main = do x <- parseStdIn fileParser do something with x fileParser = do ... Best regards Tomasz -- I am searching for a programmer who is good at least in some of [Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland

Hello Jimmie, Tuesday, December 06, 2005, 9:14:37 AM, you wrote: JH> I would like to thank all who have replied to my inquiry. my two cents :) i'm not mathematician, but instead a professional programmer. i found that Haskell allow to write shorter, concise and robust programs. as Wirth says, "program = datastructures plus algorithms" and Haskell is excellent at expressing both data types and algorithms processing them the larger the project, the there is more meaning to use Haskell to implement it, because you get the possibility to construct language "dialect" which is better suits pecularities of this concrete project. just for example - even control structures i use in my program are written by me (and it is implemented very easy, just several lines each) but for the small projects real difference created not by general language features, but by features and environment, oriented toward this concrete field of application. and in area of scripting and web programming perl/ruby/python have much more specialization one time i tried to write Haskell and Ruby variants of small script that runs programs and bencmark its results. the main part of program was equally sized, but Haskell implementation required from me writing some small library of functions which are already present in all abovementioned languages - getFileSize, trimSpaces and so on so, for small scripting tasks you will not get benefits unless you are need to organize complex dataprocessing. and even to make par-to-par comparision with scripting languages, you are need to obtain libraries for RegEx matching, String processing, and filesystem operations i think, that the same applies to web programming - you need an additional libraries and even with them you will not get all benefits of Zope and RubyOnRails so, in my feel, Haskell is better in areas where there is no standard quick-and-dirty solutions and all languages are in equal conditions, but it can't compete with Visual Basic in user interfaces, Erlang in distributed processing, and Python in scripting JH> I've seen much of what OO provides, good and bad. I'm interested in a JH> good FP experience and it seems that Haskell can provide that. nevertheless, if you not only search for the faster way to create these scripts, but also to improve your programming skills, i recommend you to teach Haskell :) i even recommend you to spend just one day to read book about Python (or Ruby, which i love more :) just to get taste, and then go to teach Haskell seriously. these scripting languages are not very complex, nor very different from other languages. and in big contrast with Perl, they contains very little number of "special rules". so, reading the whole book about Python/Ruby in just one day is entirely possible to learn Haskell and run scripts i recommend to use Hugs (WinHugs to learn, if you are under Windows). my CMD instructed to run .hs files with "runhugs.exe +st.qkoOuI -98" i learned Haskell by "gentle introduction" but afair it had bad explanation of imperative programming in Haskell. if your book have a bad explanation of I/O in Haskell, try another book, or ask here. this area really not seriously more complicated than in other languages, despite its complex (but completelly hidden!) theoretical basis JH> Thanks again. We'll see if I can fit Haskell into my brain. Or at least JH> a sufficiently workable portion. :) to my taste, Haskell have the features from ususal languages (say, Java or Ruby) plus something more in areas of defining datastructures and algorithms. if you don't need to use more features in these areas than traditional languages provide, then there is no great meaning to learn Haskell -- Best regards, Bulat mailto:bulatz@HotPOP.com

Hello Wolfgang, Tuesday, December 06, 2005, 10:16:08 PM, you wrote:

...

so, in my feel, Haskell is better in areas where there is no standard quick-and-dirty solutions and all languages are in equal conditions, but it can't compete with Visual Basic in user interfaces, Erlang in distributed processing, and Python in scripting

WJ> Well, I would say that this has nothing to do with the language as such but WJ> with a current lack of certain libraries. I even think that with appropriate WJ> libraries, Haskell will often have advantages over the existing solutions. of course, the main problem is libraries. the second problem is frameworks (like Delphi, which i also love). the third-priority problem is language itself. in particular, i hate Haskell school of imperative manipulations: x' <- readIORef x y' <- readIORef y writeIORef z (x'*y') i already sayed about lacking of OOP features. another weakness against Erlang and scripting languages is their more dynamic character which sometimes is more appropriate, especially in scripting, web pages and other applets -- Best regards, Bulat mailto:bulatz@HotPOP.com

On Tue, Dec 06, 2005 at 10:58:45PM +0300, Bulat Ziganshin wrote:

the third-priority problem is language itself. in particular, i hate Haskell school of imperative manipulations:

x' <- readIORef x y' <- readIORef y writeIORef z (x'*y')

Some day you may thank for this verbosity, because it encourages you do program in a purely functional way making your program more friendly for SMP execution.

i already sayed about lacking of OOP features.

Besides Haskell I also write in C++, and there I haven't yet found a good use for deep subtyping hierarchies. Most of my class hierarchies consist of a single abstract root and a group of concrete children. These kind of OO is easily expressible even in Haskell 98.

another weakness against Erlang and scripting languages is their more dynamic character which sometimes is more appropriate,

Then use those scripting languages! I don't want Haskell's semantics to be "whatever is appropriate in this context". Best regards Tomasz -- I am searching for a programmer who is good at least in some of [Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland

On 12/7/05, Robin Green wrote:

On Wednesday 07 December 2005 19:35, Tomasz Zielonka wrote:

...

On Tue, Dec 06, 2005 at 10:58:45PM +0300, Bulat Ziganshin wrote:

...

the third-priority problem is language itself. in particular, i hate Haskell school of imperative manipulations:

x' <- readIORef x y' <- readIORef y writeIORef z (x'*y')

Some day you may thank for this verbosity, because it encourages you do program in a purely functional way making your program more friendly for SMP execution.

You are mistaken. The verbosity is necessary if you want "visual" referential transparency, but not necessary if you only want pure functional programming. Only the latter is helpful for optimisability. I am hoping to write a paper on this topic.

I probably wouldn't mind some syntax along the lines of -- x,y :: IOref a x := y translated to v <- readIORef y writeIORef x y and -- x :: IOref a , y :: a x := y translated to writeIORef x y Of course it should carry over to STM (TVar) and ST etc. Maybe even allow the right-hand-side to have type "IO a" and make "Num a => IORef a" instances in Num to allow expressions like x := y + z Where x, y and z are IORefs or regular values. As long as the result of := (or any numeric operators involving IORefs) is always an IO computation it's still safe. It may make it harder for people to grasp the difference between an IORef and a regular value though... /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862

On Wed, Dec 07, 2005 at 07:47:46PM +0000, Robin Green wrote:

...

Some day you may thank for this verbosity, because it encourages you do program in a purely functional way making your program more friendly for SMP execution.

You are mistaken. The verbosity is necessary if you want "visual" referential transparency, but not necessary if you only want pure functional programming. Only the latter is helpful for optimisability. I am hoping to write a paper on this topic.

I am afraid I don't understand. PS. "I am after two hot beers" warning :-) Best regards Tomasz -- I am searching for a programmer who is good at least in some of [Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland

On 12/7/05, Robin Green wrote:

Let's say you want to write a function

seqPair :: (Monad m) => (m a, m b) -> m (a, b)

which returns a computation which does the left computation followed by the right computation (i.e. it's like the sequence function, but for pairs instead of lists).

In this case, I believe it is as simple as import Control.Monad (liftM2) seqPair = liftM2 (,) /g -- We have lingered in the chambers of the sea By sea-girls wreathed with seaweed red and brown Till human voices wake us, and we drown.

On Wednesday 07 December 2005 21:11, Robin Green wrote:

seqPair :: (Monad m) => (m a, m b) -> m (a, b)

Sorry, that line should read: seqPair :: (Monad m) => m a -> m b -> m (a, b) -- Robin

On Thursday 08 December 2005 07:33, you wrote:

...

seqPair $= (,)

or (the slightly less cryptic version)

seqPair x y $= (x, y)

Wouldn't they be different, the first one forcing (,) to WHNF (NOP), and the second one forcing x and y to WHNF?

No. Oh, $= also breaks type inferencing :) So you have to specify the type of the function explicitly.

Would you want seqPair written with $= to still have a type involving the Monad class?

That's the idea, yes. The type of the function does not change, only the way you write it changes when you use $= (again, this is all just a proposal at present).

...

This is not referentially transparent because it is not equivalent to

seqPair x y $= swap (y, x) where swap (a, b) = (b, a)

(can you see why not?)

Only guessing, because I am not sure what $= is supposed to do, but is it because y would be evaluated before x?

Yup. Well, that's one possible semantics of $=. A better semantics might reject the above expression as ambiguous.

Anyway, I didn't think my initial statement was so controversial. I even said "may", not "will".

Sure, I take your point. But I just jumped on my latest hobby-horse: verbosity of imperative code is not that necessary. -- Robin

Jimmie Houchin writes: (snip)

I have been perusing the haskell.org site and reading some of the tutorials. I just didn't want to expend lots of time just to find out that my math skills were woefully inadequate. I am grateful to learn (snip)

Right. My math background isn't good enough for me to understand (without much effort) some of the list traffic here - there's a lot I'm still wrapping my head around. With much of the Haskell I've figured out, I've done so by studying examples of others' code. Still, the Haskell I do know is more than enough for me to do plenty of things with, and it certainly covers everything I'd normally have coming to mind from my use of other languages.

The reason I asked about programming in the small, was my desire to spend my time and energy in a single direction. The ability to move what I do in Python to Haskell aids in that goal. It also promotes my (snip)

Yes. I've ported a number of little Perl and bash scripts to Haskell with very pleasing results. (Most recently, a little script that does AUTHINFO GENERIC authentication by MD5 to an NNTP server.) It's even quite easy to slap together little one-off programs once you're comfortable with using "do" and the IO monad (which is pretty easy for single-threaded stuff, and forkProcess works nicely too IMLE). -- Mark

Jimmie Houchin wrote:

Haskell looks like a very interesting language. I am only so-so with Python and I thought that maybe if instead of spending sufficient time to get proficient with Python, I could invest a similar time (more or less) and get reasonably (pragmatically speaking) proficient with Haskell. I know I may never understand the theory and maths behind the design, but I believe I can appreciate the design and be a decent user of the tools it provides.

FWIW, I learned Haskell a couple of years ago, having previously programmed in Python and (many) other languages. Recently, I've been using Python for a project (the choice being determined by both technical and non-technical issues), and find my Python programming style is now heavily influenced (for the better, I hope ;-) by my Haskell programming experience. A drawback of using Haskell is the limited availability of support libraries, although many people here are working hard to improve that situation. I'm doing Python work with a web application framework (Turbogears - in the same general space as Ruby/Rails, but different), and as yet I don't see anything like it in Haskell. It would be great to see a lightweight "full stack" web application framework for Haskell: I believe many of the pieces exist, and Haskell could be a supremely effective language for tying them together. #g -- Graham Klyne For email: http://www.ninebynine.org/#Contact