GvR: Rejecting the J2 decorators proposal

Yet another example of language design in action. The specific issues Guido is concerned about are perhaps of less importance than this concluding remark,

A warning: some people have shown examples of extreme uses of decorators. I've seen decorators proposed for argument and return type annotations, and even one that used a decorator to create an object that did a regular expression substitution. Those uses are cute, but I recommend being conservative when deciding between using a decorator or some other approach, especially in code that will see a large audience (like 3rd party library packages). Using decorators for type annotations in particular looks tedious, and this particular application is so important that I expect Python 3000 will have optional type declarations integrated into the argument list.

In Search of the Ideal Programming Language

The ever-enticing search for the ideal programming language produced this 1997 article from Sergey Polak. Although somewhat dated, I liked the article's comments about strings:

The discussion of arrays also brings to mind the subject of strings. No matter what anyone says, it is my firm belief that any language, regardless of its purpose, must have a powerful and flexible string-handling facility built-in. A program is very rare if it has no need for string handling, and I myself have had to write a great deal of programs, both at work and for my own uses, that depended heavily on strings. Some languages put strings in as an afterthought, and others put in some very basic features and leave the rest to library routines. That just can not be. The text string is a fundamentally important data type and can not be ignored, nor can it be relegated to blatant impersonation by some other type, such as array of characters. A string data type is required in a good language.

The very popular language C, and C++ as well, have horrendous string-handling facilities. Not only is the programmer required to declare his strings as character arrays, but there simply is no way to deal with strings as entities in the language.

Ouch. So true. That is not to endorse the specific string implementation recommendation from the article. (I have previously commented about implementation ideas, including communication buffers.)

Do the man a favor and save the article to disk for offline reading so as to minimize his bandwidth hits.

P.S. You're welcome, Ehud. I'll now be Internet-disabled for a week.

Ted Nelson's ZigZag

ZigZag has been mentioned on LtU only in passing. I think it merits a story, although no personal opinion is implied.

I have always tended to disagree, but there is more and more to disagree with as the computer field gets worse and worse.

The world is unanimous about "computer basics" and "computer literacy". They tell beginners: computers are built around hierarchical directories, word processing, the Desktop, databases, the one-way links of World Wide Web.

Lies. All lies.

These things are, of course, the present reality. But they are no more true and natural than hamburger being the true and natural form of cows, or Central Park being the true and natural form of uptown Manhattan.

The ZigZag tutorial descibes the idea this way:

The ZigZag system is very hard to explain, especially since it resembles nothing else in the computer field that we know of, except perhaps a spreadsheet cut into strips and glued into loops.


Lists and Spreadsheets are rational ways of connecting things, but they have shortcomings. Hierarchical directories are a standard way of connecting things, but they have extreme shortcomings.

The ZigZag structure...is extremely simple but has remarkable properties.

Nonsense Generator

Nonsense generates random (and sometimes humorous) text from datafiles and templates using a very simple, recursive grammar. It's like having a million monkeys sitting in front of a million typewriters, without having to feed or clean up after them.

The demo pages are quite nice. I liked the randomly generated laws. The Slashdot imitation is sure to please.

SRFI 40: A Library of Streams

The SRFI 40 document (now in "final" status) includes a very nice discussion of streams, especially as regards implementing them in strict languages (i.e, "even" vs. "odd" streams).

The code is in Scheme, of course, this being an SRFI, but basic knowledge of Scheme should be enough in order to read the highly readable SRFI document. Do check it out if you are interested in streams.


(via Gordon)

PLaneT is PLT Scheme's centralized package distribution system.

PLaneT provides automatic run-time module distribution and caching.

Cute, and be sure to check out the available packages on the PLaneT website, as well as the implemenetation details.

What's up guys?

LtU is becoming boring. Editors are urged to post ineteresting stuff. I can't do it alone.

More specifically. it has beeen awhile since we had any new items in the OOP, LP, and meta-programming departments.

Demonic Nondeterminacy: A Tribute to Edsger Wybe Dijkstra

Jayadev Misra's tribute to EWD at Europar-2003.

A short essay that may be relevant to the question whether language designers should make their languages more forgiving as regards programmer errors, or more stringent.

Higher-order module system of ML is actually possible in Haskell

A nice post from Oleg on the Haskell mailing list shows how to implement high order modules, and more specifically translucent applicative functors in idiomatic Haskell.

Thus different instantiations of the functor with respect to type-compatible arguments are type-compatible; and yet the functor hides the representation details behind the unbreakable abstraction barrier.

The work is inspired by (our own) Ken Shan's work that can be found here.

Oleg concludes,

The example illustrates that Haskell already has a higher-order module language integrated with the core language and with the module checking being a part of the regular typechecking.

"Types and Reflection" by Lauri Emil Alanko

Types and Reflection by Lauri Emil Alanko.
If you're interested in reflection or dynamic loading in statically typed languages, this is worth reading.

One of my favorite parts of this thesis is the dynamic loading section, along with discussion of the strengths and weaknesses of Haskell's Data.Dynamic, Template Haskell, and Don Stewart's hs-plugins.

Personally, I've been trying to figure out how to get elisp quality source evaluation with Haskell, and this thesis goes a long way towards answering my outstanding questions.