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.
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.
The ZigZag tutorial descibes the idea this way:
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.
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.
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.
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.
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.
Active forum topics
New forum topics