Lambda the Ultimate

With always the same solution: use an appropriate library.

It is not just that that this answer sually tells you very little about the languages (there may be many possible libraries to choose from), but it doesn't tell you anything about the interesting features of the languages.

It is kind of funny, because these problems traget interesting language features in Perl (regexps etc.) - it is just that in non-scripting languages, these operations are simply not part of the language.

True. That's why a C++/STL version would be nice. A C/glib would be nice too. Maybe pleac description should make it clear that it aims at showing how to use the default library. Nowadays, most language do have a default library, because it is very important.

it is just that in non-scripting languages, these operations are simply not part of the language.

The language/library is getting blured nowadays. Is the silly java string class a language or a library problem? As you can't plug-in your own string class, it is a language problem. The cookbook reserves a complete chapter about string handling, because integers are no more the more manipulated data structure, strings are! The perl evaluation of <tt>$var</tt> in double quoted strings is important to know, just as is the <tt>"#{var}"</tt> ruby syntax.
In many languages, lists (aka arrays) are sugared and you can't tell that it's just a library. Haskell/Python have list comprehensions.

So it's more like library + syntactic sugar? Nope. You sure know the awful java limitation that makes containers accept everything. Here it's a language feature that is missing.
I don't think there is such a neat limitation between language and library of most commonly used data structure.

it doesn't tell you anything about the interesting features of the languages.

Let's compare PHP, Perl, Python and Ruby. The main differences are not the language features. Main differences are the syntax and the library, which is exactly what pleac aims at: showing the syntax differences and the default library :)

A good case in point: Compare the code used to do word wrap in Perl's CPAN (using regular expressions), the Haskell code to do this in Simon's "Haskell: The Craft of Functional Programming" (not lazy but compact, correct and readable) and the code in Knuth's TeX (supposedly optimally lazy).

Comparing such *existing bits of code* that other's have toiled over in the past might be more fruitful than creating fresh code.

Functional languages often seem to converge on single (or small sets of) provably natural best solutions. Unless you have a patent you can't really own a single natural best solution (Can you?). The fact that no-one can own would make seem to make them ideal candidates for a standard library open to all. (Please excuse this wandering thought.)

It is kind of funny, because these problems traget interesting language features in Perl (regexps etc.) - it is just that in non-scripting languages, these operations are simply not part of the language

There are regular expression libraries for Scheme, and Haskell and they are much more concise, principled, and thus ultimately easier to read, understand and rely on.

Between scripting and functional languages there are often analogous types of operations, e.g. recursive descent parsers and parsing combinators, symbolic pattern matching in Lisp and regular expressions in Perl.

Scripting languages tend to be string based with only efficient string operations and functional languages symbol based with only efficient symbolic operations, but they all share C in common as a "foreign function interface" and/or in their implementation.

It's strange that the cookbook idea came from Perl and not C that precedes it and is in some ways more basic.

truly agreed. Alas it's sometimes easier to rewrite the solution than search for the best one already written.

Functional languages often seem to converge on single (or small sets of) provably natural best solutions. Unless you have a patent you can't really own a single natural best solution (Can you?). The fact that no-one can own would make seem to make them ideal candidates for a standard library open to all. (Please excuse this wandering thought.)

The problem is that a standard library can't contain everything. There will some missing stuff in it. In that case it can be interesting to see how to resolve a not so far away problem.

Compare the code used to do word wrap in Perl's CPAN (using regular expressions), the Haskell code to do this in Simon's "Haskell: The Craft of Functional Programming" (not lazy but compact, correct and readable) and the code in Knuth's TeX (supposedly optimally lazy).

And the way to write word wrap changes quite a lot between languages:

• how to split in words
• how to join words
• how to manipulate lists
• is there a functional way of writing it
• efficiency: haskell's <tt>fill = unlines . unwords . splitLines . splitWords</tt> is quite GC hungry.

(as for Simon's splitLines, is "dropLine" is left as an exercice?)

There are regular expression libraries for Scheme, and Haskell and they are much more concise, principled, and thus ultimately easier to read, understand and rely on.

more concise, oh come on! The haskell RegexpLib is quite nice, being compile-time checked, but it's quite bothersome to use and to read: having double backslash doesn't help readability for sure, and stuffing your variable in the regexp is not always readable as well.
As for reliability, i would not rely on haskell strings until there is PackedString all over the place. See Doug's Shootout

And Haskell do accept the fact that string handling is not its strength:

pixel@no:~>file $(rpm -ql ghc) | grep perl
/usr/bin/ghcprof:                                         perl script text executable
/usr/bin/stat2resid:                                      perl script text executable
/usr/lib/ghc-5.00.2/ghc-asm:                              perl script text executable
/usr/lib/ghc-5.00.2/ghc-split:                            perl script text executable

As for the OCaml default regexp library (Str) it is a hell, you'd better install pcre. But you'll miss sugar as once again having it in a library is not enough (and unless you have Cayenne, you can't have compile time checks)

Scripting languages tend to be string based with only efficient string operations and functional languages symbol based with only efficient symbolic operations, but they all share C in common as a "foreign function interface" and/or in their implementation.

??

It's strange that the cookbook idea came from Perl and not C that precedes it and is in some ways more basic.

Last of expressivity? ;p

> more concise, oh come on! ....

OK, maybe I'm a little too exhuberant about functional languages. What I really meant is that regular expression *implementations* for functional languages (not the *interfaces*) are more concise and *understandable* because they are more *principled*.

Unlike the implementation of Henry Spencer's popular C regular expression package which isn't documented and explained anywhere and which many competent people find difficult to grasp there are many great *explanations* of how regular expressions can be implemented in a functional language in a principled fashion:

1. Cousineau and Mauny, The Functional Style of Programming (in CAML). 2. Regular Expressions and Automata using Haskell (Simon Thompson) The only readable explanation of implementing regular expressions in a non-functional language that I know of is: Building Parsers with Java, Metsker (2001)...uses design patterns.

Because the functional implementations are more principled and understandable, *ideas* rather than *little black software boxes* (most of source-forge) are passed around and *people educate themselves* (a primary virtue of open source) rather than own, rent, consume, whatever...the most recent Microsoft buzzwords.

The functional implementations are also *potentially more reliable* because they can be proven correct and *potentially more efficient* because optimizing program transformations and compilation can be applied to them. Many scripting languages seem to be perpetually stuck at the *inefficient interpreter stage*.

As for the *interface to the regular expression routines* why don't they just use the Perl/Python one? I know I sound like "Number 1 Intellectual Property Thief" here, but can open source people really afford to be so fragmented and reinvent the wheel so many times when streamlined profit-guided organizations like Microsoft are slowly dominating everything?

-------------------------------------------------------------

Recipes that could be used in *every language* ?

Write the cookbook in C. Then use the recipes as extensions (like Ousterhout advocates) (or via the "foreign function interface in the lisp world).

One problem in writing a cookbook is that C does not have those two fundamental scripting language data structures built-in: maps/hashes and lists, but .... David Hansen has provided good interfaces and definitions for these as well as patching up numerous other problems/holes/gaps in the C standard: C Interfaces and Implementations http://www.cs.princeton.edu/software/cii/

If you are going to write a C++ cookbook then you are also going to have to write a C-sharp cookbook, wouldn't it be better to start with a C cookbook and refactor it into C++ and C sharp, don't C++ and C sharp share a common C-like subset? I know that this completely ignores STL but the balkanization of computer languages has to be fought somehow or we will all eventually be feeding out of the same proprietary software trough. Getting back to basics and refocusing on where it all began (C, Lisp/Scheme) seems to be a good way to fight balakanization, make a stronger open source community, and convince business that open source ideas are better than proprietary buzzwords. ------------------------------------------------------------------

I don't understand why a *Guile cookbook* is proposed and not a *general Scheme cookbook*, all the bits and pieces are out there for one: pregexp (regexps), schelog (prolog), Indiana Scheme Repository: http://www.cs.indiana.edu/scheme-repository/SRhome.html

Scheme is like one of those see through anatomical dolls in which you can see all the organs and take the whole thing apart piece by piece if you so choose. (Or like in the army where they make you memorize how to take apart your gun and put it together again or like those car enthusiasts who take apart their car for the sole purpose of learning how to put it back together again.) Everyone in the Scheme world writes a Scheme interpreter, it's part of Scheme culture, so Guile-centric code is really not a good idea.

As in the C, C++, C-Sharp case it makes more sense to go as far as you can in a principled sort of way (cf Hansen) using the common subset of Scheme before vearing off into idiosyncratic dialects. Scheme SRFI's , Scsh Scheme with its AWK for file reformatting, and PLT Scheme (many platforms) all provide a lot of tools to do cookbooky sort of things with strings, files, directories, networking...etc.

------------------------------------------------------------------

IMHO the most urgent cookbook need is cross-language GUI programming:

Tk, Swing, Wxwindows (Python,Perl,PLT Scheme), Gtk, X, Motif (or Lesstif)

Tk is portable (Python,Perl,Haskell,ML,CAML....) and already has a two great GUI cookbooks: Bruce Welch's Practical Programming in Tcl and Tk and Harrison and McLennan's "Effective Tcl/Tk Programming" It's canvas and text widgets and event handling is great but still lacks a lot of things that companies deem essential.

The Adobe Acrobat reader is a wealth of potential recipes waiting to be cooked up (paging, zooming, thumbnails, annotations, bookmarks, the little hand). Tk is also constantly being used as the vehicle for innovative new GUI ideas:

1. Concepts, Techniques, and Models of Computer Programming. Peter Van Roy. (uses multiparadigm Oz) 2. Conal Elliott's "reactive animation" ("Fran" system written in Haskell).

------------------------------------------------------------------

>> Scripting languages tend to be string based with only efficient string >> operations and functional languages symbol based with only efficient symbolic operations... > ??

What I was referring to is: One reason why scripting languages left wonderful old languages like Scheme/Lisp/Prolog (+ functional languages) in the dust is because these older languages rely on lists of *symbols* (atoms) which are one step too far removed from the string data that computers have to deal with when processing data from files or GUI's. Standard Prolog is the most extreme. Either you stuff all string handling into the reader or you explode your symbols into component characters and process the list of characters, yuck!

When you rely on symbols you can do all sorts of efficient inference (cf Prolog, Oz) and pattern matching (see Norvig's "Paradigms of AI Programming"). Without symbols these sorts of things are simply beyond the pale of scripting languages.

Although it still mainly a research topic "natural language processing" relies on efficient inference, so higher order text processing (e.g. searching for ideas in a text rather than just words or phrases) will depend on this sort of inferencing.

Cheers,

Jon Fernquest